Étude théorique et implantation matérielle d’unités de calcul en représentation modulaire des nombres pour la cryptographie sur courbes elliptiques - Thèse Informatique - Revenir à l'accueil

 APISENSE-a-distribut..> 05-Jan-2015 08:09  5.7M  

 APISENSE-terminaux-i..> 04-Jan-2015 21:53  5.4M  

 Addition-formulae-on..> 04-Jan-2015 21:26  3.0M  

 Algorithmique-distri..> 05-Jan-2015 23:00  4.2M  

 Approche-algorithmiq..> 05-Jan-2015 22:53  3.5M  

 Architecture-de-comm..> 05-Jan-2015 08:04  4.4M  

 Bornes-inferieures-e..> 05-Jan-2015 15:39  1.6M  

 CONTRIBUTION-A-LA-ST..> 05-Jan-2015 22:56  5.5M  

 Caracterisation-auto..> 05-Jan-2015 16:34  5.1M  

 Caracterisation-et-d..> 05-Jan-2015 22:51  4.5M  

 Catalogage-de-petits..> 05-Jan-2015 08:06  3.8M  

 Classification-et-ca..> 04-Jan-2015 11:58  1.3M  

 Collaboration-de-tec..> 04-Jan-2015 21:27  2.4M  

 Completion-combinato..> 05-Jan-2015 15:41  2.6M  

 Contribution-a-l-etu..> 05-Jan-2015 22:54  3.2M  

 Contribution-a-la-co..> 05-Jan-2015 16:10  3.5M  

 Contributions-a-la-v..> 04-Jan-2015 21:51  5.4M  

 Controle-de-la-puiss..> 05-Jan-2015 22:52  3.6M  

 Coordination-Modulai..> 05-Jan-2015 15:58  2.2M  

 Couplage-de-modeles-..> 05-Jan-2015 22:46  5.3M  

 Cryptographie-sur-le..> 05-Jan-2015 08:01  3.4M  

 De-l-auto-evaluation..> 05-Jan-2015 22:44  6.2M  

 Detection-de-rails-m..> 05-Jan-2015 08:04  5.1M  

 Dispositifs-spatiaux..> 05-Jan-2015 22:59  5.2M  

 Dynamique-des-graphe..> 05-Jan-2015 22:56  5.5M  

 Environnements-urbai..> 05-Jan-2015 08:03  6.3M  

 Equilibrage-de-charg..> 04-Jan-2015 21:25  3.2M  

 Etude-de-la-synchron..> 05-Jan-2015 15:58  2.4M  

 Etude-des-facteurs-d..> 05-Jan-2015 15:38  1.8M  

 Evaluation-analytiqu..> 05-Jan-2015 08:07  3.5M  

 Evaluation-de-la-sur..> 05-Jan-2015 15:39  1.4M  

 Execution-efficace-d..> 05-Jan-2015 15:39  1.4M  

 Faciliter-le-develop..> 04-Jan-2015 21:56  4.4M  

 Factorisation-matric..> 04-Jan-2015 11:59  2.7M  

 Formes-et-fonctions-..> 05-Jan-2015 22:49  4.5M  

 Generation-automatiq..> 03-Jan-2015 22:04  2.6M  

 Generation-de-modele..> 05-Jan-2015 15:41  3.2M  

 Gestion-de-la-variab..> 04-Jan-2015 21:55  4.8M  

 Idéalisation-d-asse..> 04-Jan-2015 11:57  2.1M  

 Inference-d-invarian..> 04-Jan-2015 11:58  1.5M  

 Influence-du-mapping..> 05-Jan-2015 22:49  4.6M  

 Integration-de l-inf..> 04-Jan-2015 21:25  3.4M  

 Integration-et-explo..> 05-Jan-2015 16:35  4.8M  

 Intelligence-en-essa..> 05-Jan-2015 08:03  5.6M  

 Interaction-entre-al..> 05-Jan-2015 22:51  4.1M  

 Interrogation-de-gra..> 03-Jan-2015 22:04  2.9M  

 L-architecture-du-di..> 05-Jan-2015 15:40  1.2M  

 La-gestion-du-trafic..> 03-Jan-2015 22:01  4.1M  

 Langage-de-mashup-Th..> 04-Jan-2015 21:24  4.1M  

 Les-logiciels-de-ges..> 03-Jan-2015 22:03  3.1M  

 Lh-rs-p2p-une-nouvel..> 04-Jan-2015 11:59  2.7M  

 Mesure-de-la-fragili..> 04-Jan-2015 21:24  3.8M  

 Meta-modelisation-du..> 04-Jan-2015 21:56  4.1M  

 Methode-de-classific..> 04-Jan-2015 11:58  1.3M  

 Methode-de-game-desi..> 05-Jan-2015 08:10  4.2M  

 Methodes-de-reconstr..> 05-Jan-2015 23:05  6.1M  

 Methodes-et-structur..> 05-Jan-2015 22:46  5.6M  

 Methodes-numeriques-..> 05-Jan-2015 22:52  3.9M  

 Methodes-sequentiell..> 04-Jan-2015 21:27  2.2M  

 Mise-en-oeuvre-appli..> 04-Jan-2015 21:54  4.4M  

 Mise-en-oeuvre-de-cr..> 05-Jan-2015 23:03  6.3M  

 Modele-de-comporteme..> 05-Jan-2015 16:10  3.2M  

 Modele-et-experience..> 05-Jan-2015 08:01  3.8M  

 Modelisation-d-un-re..> 05-Jan-2015 23:03  7.2M  

 Modelisation-d-une-a..> 04-Jan-2015 21:53  5.0M  

 Modelisation-de-la-p..> 05-Jan-2015 15:59  1.9M  

 Modelisation-et-dete..> 04-Jan-2015 11:57  1.6M  

 Modelisation-et-scor..> 05-Jan-2015 16:09  4.4M  

 Normalisation-et-App..> 03-Jan-2015 22:01  4.1M  

 Nouvelles-approches-..> 05-Jan-2015 08:09  2.3M  

 Periodes-d-integrale..> 05-Jan-2015 22:54  3.0M  

 Planification-d-une-..> 05-Jan-2015 08:06  4.1M  

 Positionnement-robus..> 05-Jan-2015 15:39  1.5M  

 Prise-en-compte-de-l..> 03-Jan-2015 22:04  2.8M  

 Proposition-d-approc..> 05-Jan-2015 22:58  5.2M  

 Proposition-d-une-ar..> 05-Jan-2015 22:48  5.0M  

 Protection-obligatoi..> 05-Jan-2015 22:44  6.0M  

 Qualification-system..> 04-Jan-2015 21:26  2.8M  

 Reconnaissance-de-co..> 03-Jan-2015 22:03  3.6M  

 Reseaux-urbains-de-c..> 05-Jan-2015 16:34  5.6M  

 Samsung-Telephone-Mo..> 05-Jan-2015 15:41  2.4M  

 Segmentation-par-cou..> 05-Jan-2015 23:01  3.9M  

 Segmentation-supervi..> 04-Jan-2015 11:58  1.3M  

 Services-de-repartit..> 03-Jan-2015 21:59  4.7M  

 Simulation-credible-..> 05-Jan-2015 22:58  5.2M  

 Simulations-numeriqu..> 05-Jan-2015 22:48  4.8M  

 Systeme-de-mesure-d-..> 05-Jan-2015 15:40  1.3M  

 Techniques-de-codage..> 05-Jan-2015 22:53  3.5M  

 Techniques-visuelles..> 04-Jan-2015 21:27  2.7M  

 The-Emergence-of-Mul..> 03-Jan-2015 22:05  2.5M  

 Thermoformage-du-ver..> 05-Jan-2015 22:59  4.4M  

 Trigraphes-de-Berge-..> 03-Jan-2015 22:02  3.9M  

 Typologies-textuelle..> 05-Jan-2015 23:05  6.1M  

 Un-ilot-formel-pour-..> 05-Jan-2015 08:07  3.1M  

 Une-approche-agile-f..> 05-Jan-2015 16:09  4.0M  

 Une-approche-d-align..> 05-Jan-2015 15:40  2.9M  

 Vers-une-capitalisat..> 03-Jan-2015 22:00  4.6M

 Analyse-numerique-Co..> 03-Jan-2015 17:33  3.0M  

 Approches-m-k-firm-p..> 03-Jan-2015 17:27  3.7M  

 COURS-LA-CULTURE-INF..> 03-Jan-2015 17:25  3.8M  

 CRYPTANALYSE-DE-RSA-..> 03-Jan-2015 17:33  3.0M  

 Cours-Interconnexion..> 03-Jan-2015 17:34  3.0M  

 Cours-d-Analyse-et-C..> 03-Jan-2015 17:22  3.9M  

 Efficient-C++finite-..> 03-Jan-2015 17:30  3.5M  

 Efficient-C++finite-..> 03-Jan-2015 17:31  3.2M  

 Fondements-de-l-Info..> 03-Jan-2015 17:22  4.0M  

 INTRODUCTION-A-L-INF..> 03-Jan-2015 17:24  3.8M  

 Informatique-et-Ling..> 03-Jan-2015 17:24  3.8M  

 Initiation-a-l-infor..> 03-Jan-2015 17:26  3.8M  

 Intelligence-Artific..> 03-Jan-2015 15:16  2.5M  

 Introduction-a-l-ana..> 03-Jan-2015 17:27  3.7M  

 Introduction-a-la-ge..> 03-Jan-2015 17:26  3.8M  

 Le-routage-externe-B..> 03-Jan-2015 17:32  3.1M  

 Le-systeme-d-informa..> 03-Jan-2015 17:32  3.1M  

 Lecture1_Linear_SVM_..> 03-Jan-2015 14:57  2.4M  

 Lecture2_Linear_SVM_..> 03-Jan-2015 14:56  2.4M  

 Lecture3_Linear_SVM_..> 03-Jan-2015 14:56  2.4M  

 Lecture4_Kenrels_Fun..> 03-Jan-2015 14:55  2.4M  

 Lecture5_Kernel_SVM...> 03-Jan-2015 14:55  2.4M  

 Lecture6_SVDD.pdf.htm   03-Jan-2015 14:54  2.4M  

 Lecture7_Cross_Valid..> 03-Jan-2015 14:54  2.4M  

 Lecture8_Multi_Class..> 03-Jan-2015 14:57  2.4M  

 Lecture9_Multi_Kerne..> 03-Jan-2015 14:53  2.5M  

 Lecture10_Outilier_L..> 03-Jan-2015 14:53  2.5M  

 Les-reseaux-sans-fil..> 03-Jan-2015 15:17  2.5M  

 NooJ-pour-l-Intellig..> 03-Jan-2015 17:30  3.2M  

 Outils-Logiques-pour..> 03-Jan-2015 15:15  2.8M  

 Presentation-de-la-r..> 03-Jan-2015 17:33  3.0M  

 Projet-IP-SIG-Signal..> 03-Jan-2015 15:16  2.5M  

 Robotique-Mobile-PDF..> 03-Jan-2015 15:16  2.6M  

 Systeme-informatique..> 03-Jan-2015 15:17  2.5M  

 Systemes-Multi-Agent..> 03-Jan-2015 17:28  3.5M  

 Tutoriel-Android-TP-..> 03-Jan-2015 14:57  2.3M  

 Understanding-SVM-th..> 03-Jan-2015 14:57  2.4M  

 Une-histoire-de-la-m..> 03-Jan-2015 17:28  3.5M  

 Une-introduction-aux..> 03-Jan-2015 17:31  3.1M  

 Vers-une-signalisati..> 03-Jan-2015 17:25  3.8M 

HAL Id: tel-01084254 https://tel.archives-ouvertes.fr/tel-01084254 Submitted on 19 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.ANNÉE 2014 THÈSE / UNIVERSITÉ DE RENNES 1 sous le sceau de l’Université Européenne de Bretagne pour le grade de DOCTEUR DE L’UNIVERSITÉ DE RENNES 1 Mention : Informatique Ecole doctorale MATISSE présentée par Karim Bigou préparée à l’unité de recherche IRISA (UMR6074) Institut de recherche en informatique et systèmes aléatoires École Nationale Supérieure des Sciences Appliquées et de Technologie (ENSSAT) - Équipe CAIRN Étude théorique et implantation matérielle d’unités de calcul en représentation modulaire des nombres pour la cryptographie sur courbes elliptiques Thèse soutenue à Lannion le 3 Novembre 2014 devant le jury composé de : Liam MARNANE Senior Lecturer, University College Cork rapporteur Jean-Michel MULLER Directeur de recherche CNRS, ENS Lyon, LIP rapporteur Jean-Claude BAJARD Professeur, Université de Paris 6, LIP6 examinateur Guy GOGNIAT Professeur, Université de Bretagne Sud, Lab-STICC examinateur Arnaud TISSERAND Chargé de recherche CNRS, IRISA directeur de thèse Nicolas GUILLERMIN Expert cryptographie DGA co-directeur de thèse23 Remerciements Je tiens tout d’abord à remercier mes directeurs de thèse, Arnaud Tisserand et Nicolas Guillermin, qui m’ont permis d’effectuer ce travail sur une problématique passionnante. Ils m’ont notamment mis le pied à l’étrier sur les aspects matériels, et Arnaud s’est montré extrêmement patient lorsqu’il a fallu rédiger les idées et les résultats pour les soumettre en conférence. Leurs précieux conseils m’ont permis d’aboutir au document que voici, dans les temps de mon financement de thèse (DGA-INRIA). Je remercie aussi les autres membres du jury : Guy Gogniat en tant que président du jury, Jean-Claude Bajard en tant qu’examinateur, et enfin les relecteurs Liam Marnane et Jean-Michel Muller, qui sont venus de toute la France, et même d’Irlande. Je tiens à remercier tous les membres de l’équipe CAIRN que j’ai pu côtoyer durant ma thèse. Cette équipe possède une formidable ambiance de travail, ce qui est très motivant et très encourageant dans les périodes difficiles qui juchent le chemin jusqu’à la soutenance de thèse. Je remercie plus particulièrement les secrétaires d’équipe Nadia et Angélique, mes anciens co-bureaux Thomas et Julien, les autres doctorants du groupe arithmétique/crypto Jérémy et Frank, et les doctorants qui ont démarré en même temps que moi, notamment Ganda-Stéphane et Hai. Je remercie aussi tous ceux qui m’ont beaucoup soutenu durant la rédaction. En vrac, merci à Cédric, Christophe, aux trois Nicolas et à Mélanie. Les conseils de Nicolas E., les légendaires pestos de Nicolas V., les délicieuses mousses au chocolat de Mélanie, les discussions endiablées sur le jeu vidéo avec Nicolas S., le rendez-vous hebdomadaire after work à « l’Atmo » animé par Christophe et les combos de blagues réalisés par Cédric m’ont aidé à surmonter le rythme soutenu de fin de thèse. Je remercie mes parents Gilles et Rachida et mes frères Nadjim et Jason pour tout leur soutien tout au long de ma thèse, et plus généralement, tout au long de ma scolarité. Je remercie mes parents d’avoir fait ces 20 heures de route en 3 jours pour pouvoir me soutenir encore une fois afin de conclure mes 8 années d’études. Pour terminer, je remercie Julie, qui m’accompagne depuis bientôt 10 ans, et qui s’est investie dans cette thèse, notamment en relisant l’intégralité du document ici présent. Elle a dû faire face à mes périodes de doute, et m’a soutenu quelles que soient les humeurs qui m’ont traversées durant ces 3 dernières années. Elle a été mon soutien le plus fondamental durant toute la durée de ces travaux, et l’est encore aujourd’hui.4Table des matières Introduction 9 Notations 21 1 État de l’art 25 1.1 La cryptographie asymétrique . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.1.1 Le cryptosystème RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.1.2 Le problème du logarithme discret, application dans les corps finis . 26 1.1.3 Le problème du logarithme discret sur les courbes elliptiques . . . . 28 1.1.4 Techniques classiques de multiplication scalaire et d’exponentiation . 33 1.1.5 Réduction du coût de la multiplication scalaire . . . . . . . . . . . . 34 1.1.6 Sécurité et attaques physiques . . . . . . . . . . . . . . . . . . . . . . 37 1.2 Arithmétique modulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 1.2.1 Définitions et rappels sur l’arithmétique modulaire . . . . . . . . . . 39 1.2.2 Réduction Modulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 1.2.3 Inversion Modulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 1.3 La représentation modulaire des nombres (RNS) . . . . . . . . . . . . . . . 46 1.3.1 Définition et premières propriétés . . . . . . . . . . . . . . . . . . . . 47 1.3.2 Extensions de base RNS . . . . . . . . . . . . . . . . . . . . . . . . . 49 1.3.3 Adaptation RNS de l’algorithme de Montgomery . . . . . . . . . . . 54 1.3.4 Autres algorithmes de réduction . . . . . . . . . . . . . . . . . . . . 57 1.3.5 Implantations RNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2 Inversion modulaire rapide en RNS 69 2.1 Inversion modulaire RNS dans l’état de l’art . . . . . . . . . . . . . . . . . . 69 2.2 Inversion modulaire plus-minus en RNS . . . . . . . . . . . . . . . . . . . . 72 2.3 Algorithme binaire-ternaire plus-minus en RNS . . . . . . . . . . . . . . . . 78 2.4 Comparaison avec l’état de l’art . . . . . . . . . . . . . . . . . . . . . . . . . 83 2.4.1 Complexité du FLT-MI . . . . . . . . . . . . . . . . . . . . . . . . . . 83 2.4.2 Complexité de PM-MI et BTPM-MI . . . . . . . . . . . . . . . . . . . . 84 2.5 Architecture et implantation FPGA . . . . . . . . . . . . . . . . . . . . . . 85 2.6 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3 Décomposition et réutilisation d’opérandes pour la multiplication modulaire RNS 99 3.1 Algorithme de multiplication modulaire RNS proposé . . . . . . . . . . . . . 99 3.1.1 L’étape de décomposition . . . . . . . . . . . . . . . . . . . . . . . . 100 3.1.2 Algorithme de multiplication modulaire SPRR . . . . . . . . . . . . . 102 56 TABLE DES MATIÈRES 3.1.3 Preuve des propositions 1 et 2 . . . . . . . . . . . . . . . . . . . . . . 105 3.1.4 Sélection des paramètres . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.2.1 Application au logarithme discret . . . . . . . . . . . . . . . . . . . . 110 3.2.2 Applications aux courbes elliptiques . . . . . . . . . . . . . . . . . . 112 3.3 Exponentiation rapide RNS sans hypothèse sur P . . . . . . . . . . . . . . . 116 3.3.1 Un nouvel algorithme d’exponentiation RNS . . . . . . . . . . . . . . 117 3.3.2 Autres algorithmes d’exponentiation . . . . . . . . . . . . . . . . . . 120 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4 Multiplication modulaire RNS mono-base 123 4.1 La multiplication modulaire RNS à base unique SBMM . . . . . . . . . . . . . 123 4.2 Analyse de l’algorithme SBMM . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.2.1 Généralisation du paramètre c . . . . . . . . . . . . . . . . . . . . . . 126 4.2.2 Utilisation de l’extension de base de Kawamura et al. . . . . . . . . . 127 4.2.3 Compression des sorties de l’algorithme . . . . . . . . . . . . . . . . 128 4.2.4 Analyse des coûts en EMM et EMW . . . . . . . . . . . . . . . . . . . . 130 4.3 Implantation FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 4.3.1 Architecture implantée . . . . . . . . . . . . . . . . . . . . . . . . . . 133 4.3.2 Résultats d’implantation . . . . . . . . . . . . . . . . . . . . . . . . . 135 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5 Tests de divisibilité multiples 139 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 5.2 Notations et hypothèses d’implantation matérielle . . . . . . . . . . . . . . . 140 5.3 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 5.4 Utilisation directe des rubans de Pascal en base 2 . . . . . . . . . . . . . . . 143 5.5 Amélioration via les rubans de Pascal en grande base 2 v . . . . . . . . . . . 144 5.6 Comparaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Conclusion 149 Bibliographie personnelle 153 Bibliographie 153Liste des Algorithmes 1 Protocole de chiffrement RSA [102]. . . . . . . . . . . . . . . . . . . . . . . . 26 2 Échange de clé de Diffie-Hellman [38]. . . . . . . . . . . . . . . . . . . . . . . 27 3 Protocole de chiffrement Elgamal simple [44]. . . . . . . . . . . . . . . . . . . 27 4 Chiffrement avec le cryptosystème Elgamal ECC simple (source [57]). . . . . 32 5 Multiplication scalaire doublement et addition poids faibles en tête (source [57], p. 96). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6 Multiplication scalaire doublement et addition poids forts en tête (source [57], p. 97). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7 Multiplication scalaire par fenêtre fixe de Yao [125]. . . . . . . . . . . . . . . 35 8 Réduction modulaire de Montgomery [82]. . . . . . . . . . . . . . . . . . . . 41 9 Réduction modulo un nombre pseudo-Mersenne [34]. . . . . . . . . . . . . . 42 10 Algorithme d’Euclide étendu (source [66]). . . . . . . . . . . . . . . . . . . . 44 11 Algorithme d’Euclide étendu binaire de [66]§ 4.5.2. . . . . . . . . . . . . . . . 45 12 Inversion modulaire plus-minus [37]. . . . . . . . . . . . . . . . . . . . . . . . 46 13 Conversion RNS vers MRS [120]. . . . . . . . . . . . . . . . . . . . . . . . . 50 14 Extension de base (BE) issue de [64]. . . . . . . . . . . . . . . . . . . . . . . . 53 15 Réduction de Montgomery RNS (MR) [99]. . . . . . . . . . . . . . . . . . . . . 54 16 Inversion modulaire FLT-MI basée sur le petit théorème de Fermat (version LSBF de [48]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 17 Inversion modulaire plus-minus proposée PM-MI (version binaire). . . . . . . 73 18 Inversion modulaire binaire-ternaire plus-minus proposée (BTPM-MI). . . . . . 80 19 Fonction Divup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 20 Étape de décomposition (Split). . . . . . . . . . . . . . . . . . . . . . . . . 101 21 Multiplication modulaire proposée SPRR. . . . . . . . . . . . . . . . . . . . . 102 22 Exponentiation « échelle de Montgomery » [62]. . . . . . . . . . . . . . . . . 111 23 Exponentiation carré et multiplication (source [51]). . . . . . . . . . . . . . . 117 24 Exponentiation RNS revisitée . . . . . . . . . . . . . . . . . . . . . . . . . . 119 25 Exponentiation RNS régulière revisitée. . . . . . . . . . . . . . . . . . . . . . 121 26 Multiplication modulaire RNS mono-base SBMM. . . . . . . . . . . . . . . . . . 124 27 Étape de décomposition compacte CSplit. . . . . . . . . . . . . . . . . . . . 125 28 Compression d’une valeur représentée par (K, R). . . . . . . . . . . . . . . . 128 78 LISTE DES ALGORITHMESIntroduction Contexte et motivations des travaux La sécurité des systèmes d’information et de communication est, de nos jours, une question primordiale dans un bon nombre d’applications, et son champ d’application va avoir tendance à encore s’accroître avec l’utilisation et l’intégration de plus en plus massive de systèmes intelligents. Cette sécurité intervient dans des domaines différents comme la défense, l’économie numérique ou encore les divertissements, ce qui impose des contraintes très différentes. Le secret militaire, les transactions bancaires ou encore les services de vidéo à la demande sont des exemples que l’on peut associer à ces domaines. D’autres domaines apparaissent avec, par exemple, l’utilisation de circuits électroniques directement intégrés dans le corps à des fins médicales. Un autre exemple est la domotique, c’est-à-dire la construction de « maisons intelligentes » avec un contrôle informatique. On peut aussi évoquer des concepts plus généraux qui ont des besoins de sécurité, comme l’informatique dans le nuage (cloud computing). Le principe est d’utiliser la puissance de serveurs distants et leur capacité de stockage pour en profiter sur des dispositifs bien moins puissants, via le réseau (internet principalement). Une telle application génère beaucoup de trafic sur le réseau, et notamment beaucoup d’informations à protéger, avec potentiellement un gros débit d’informations à garder confidentielles, et beaucoup d’utilisateurs à authentifier. Une des promesses de ce type de service est de fournir autant de confidentialité sur les données stockées de façon distante que si elles étaient enregistrées localement. La variété des contextes d’utilisation implique une variété de contraintes possibles : des contraintes de coût de mise en œuvre, de consommation d’énergie et de temps d’exécution ou de débit d’information doivent être prises en compte. Ces contraintes sont conditionnées par le niveau de sécurité que le concepteur cherche à obtenir ou à garantir. Par exemple, il n’est pas forcément nécessaire pour certaines applications d’avoir des protections qui ré- sistent à des attaques de plusieurs années. Par contre, d’autres applications requièrent une protection pour des dizaines d’années, comme cela peut être le cas d’informations classées « Confidentiel Défense » ou « Secret Défense », qui sont prévues pour rester confidentielles 50 ans dans la loi. Les systèmes d’information ayant des limites physiques, on ne peut pas obtenir une protection qui reste valable quelle que soit la puissance de calcul de l’attaquant. D’où une notion de niveau de sécurité, directement reliée à l’attaque la plus efficace que peut faire un attaquant, avec une certaine quantité de ressources. La sécurité repose sur différents types de protocoles, qui permettent par exemple d’authentifier les interlocuteurs et de garder secrète leurs communications. Ces protocoles utilisent des primitives cryptographiques pour assurer ces fonctions. La cryptographie classique, utilisée actuellement dans nos systèmes de communication, repose sur des problèmes mathématiques qui sont a priori impossibles 910 INTRODUCTION à résoudre à un coût raisonnable lorsqu’on ne possède pas un certain secret : la clé. La difficulté de ces problèmes est choisie pour être adaptée à la protection que l’on veut mettre en place et contre quel attaquant on veut se protéger : un particulier, une entreprise ou un état par exemple. Ces paramètres font que la mise en place de protections adaptées est un problème complexe. Il existe plusieurs types de cryptographie. Actuellement, dans les protocoles de sécurité, on utilise généralement deux types de cryptographie : la cryptographie asymétrique (ou à clé publique) et la cryptographie symétrique (ou à clé secrète). Ces deux catégories ont des caractéristiques différentes et sont utilisées généralement de façon complémentaire. La cryptographie à clé publique ne requiert pas de secret partagé entre les deux interlocuteurs, celui qui reçoit le message possède 2 clés, une publique qu’il diffuse, et un autre qu’il garde secrète. Ce type de cryptographie requiert des calculs compliqués sur des grands nombres, ce qui rend ces opérations coûteuses en temps. Les travaux de cette thèse s’intéresse exclusivement à ce type de cryptographie. Plus précisément, on va s’intéresser à l’accélération des calculs pour la cryptographie sur courbes elliptiques (ECC pour elliptic curve cryptography), qui a été introduite dans le milieu des années 1980 par Koblitz [67] et Miller [80]. D’autres primitives de cryptographie asymétrique seront plus brièvement étudiées, comme RSA [102] (du nom de ses auteurs Rivest, Shamir et Adleman) et Diffie-Hellman [38]. De l’autre côté, la cryptographie symétrique a comme contrainte forte que les deux interlocuteurs doivent partager une même clé secrète. Grâce à ce secret partagé, ils vont pouvoir utiliser un des algorithmes de chiffrement symétrique comme l’AES [90] par exemple, qui est un chiffrement symétrique très rapide. La complémentarité des deux types de cryptographie se dessine lorsque deux interlocuteurs cherchent à établir une communication via un canal sécurisé. Ces interlocuteurs devront d’abord s’authentifier mutuellement puis échanger une clé secrète grâce à la cryptographie asymétrique. Ensuite, ils pourront communiquer de manière sécurisée en utilisant un chiffrement symétrique avec la clé qu’ils ont partagée, de manière bien plus rapide que si tout était fait avec la cryptographie asymé- trique. Il existe aussi d’autres propositions en terme de cryptographie, mais qui ne sont pas utilisées car trop peu performantes pour des besoins actuels. Par exemple, la distribution de clé quantique est une méthode qui est basée sur des phénomènes physiques, à la diffé- rence de la cryptographie actuelle basée sur certains problèmes mathématiques. L’avantage principal de ce type de cryptographie est qu’elle est résistante aux attaques que l’on pourrait implanter si un véritable ordinateur quantique était mis au point un jour. Un exemple célèbre est l’algorithme de Shor [113] permettant de factoriser des entiers très rapidement sur un ordinateur quantique. Cette factorisation permettrait par exemple de casser très rapidement RSA. Actuellement, le plus grand nombre entier décomposé en ses facteurs premiers par un calculateur quantique est 21 [75]. L’utilisation massive, un jour, de ce type de cryptographie est extrêmement hypothétique, et est largement en dehors du cadre de cette thèse. Cette thèse porte principalement sur l’accélération de certaines opérations sur des nombres de plusieurs centaines à plusieurs milliers de bits pour les calculs nécessaires à la cryptographie asymétrique, en particulier ECC. Les courbes elliptiques sont très intéressantes parmi l’ensemble des primitives de cryptographie asymétrique car elles permettent d’utiliser des tailles de clé plus petites que les autres standards, pour une sécurité équivalente [57]. Il en va de même pour la taille des nombres traités et les performances en temps11 d’exécution. Par exemple, ECC définit avec des clés de 160 bits et des nombres représentés sur 160 bits, propose une sécurité équivalente à RSA sur 1024 bits (taille des clés et des éléments). Plus généralement, les tailles des valeurs pour ECC vont de 160 à 600 bits et pour RSA de 1024 à 3072 dans les standards. Les tables 1.1, 1.2, 1.3 et 1.4 aux pages 32 et 33 présentent des comparaisons sur la taille des clés, la vitesse d’exécution ou encore la consommation d’énergie. On trouve deux grandes catégories de courbes elliptiques dans l’état de l’art d’ECC : les courbes ayant comme corps de base F2m et celles définies sur Fp. Les courbes défi- nies sur F2m proposent une arithmétique généralement plus efficace, car le corps de base F2m possède plus de structure permettant l’accélération des calculs. Par exemple, on a (x + y) 2 = x 2 + y 2 dans F2m, ce qui permet d’accélérer certains calculs. Cependant, on ne sait pas si cette structure sur le corps de base peut aider un attaquant et réduit la sécurité du système. Les travaux de cette thèse porteront exclusivement sur ECC sur Fp. Ces courbes sont, par exemple, recommandées par l’agence américaine NSA (national security agency) pour l’échange de clé et la signature numérique des documents classés « Secret » et « Top Secret » avec des corps de 256 bits et 384 bits (voir [88, 89]). Les deux types de courbes sont intéressants car, premièrement, il est important en cryptographie de pouvoir disposer de différentes protections pour pallier l’éventuelle défaillance de l’une d’entre elles, et deuxièmement, il existe un bon nombre de brevets sur l’implantation efficace des 2 types de courbes qui peuvent guider le choix du type de corps (F2m ou Fp). Si les courbes elliptiques ont de si petites clés et de si petites tailles d’éléments par rapport à RSA et Diffie-Hellman, c’est grâce à leur meilleure résistance aux attaques mathématiques connues. Le champ de la cryptologie s’intéressant aux attaques mathématiques se nomme la cryptanalyse. Par exemple, c’est en partie parce que nous ne savons pas mettre en œuvre l’attaque du calcul d’indices [3] sur les courbes elliptiques qu’elles utilisent des entiers de centaines de bits, comparés aux milliers de bits pour RSA et Diffie-Hellman. Pour illustrer cette différence, on peut comparer les records des tailles maximales qui ont été cassées pour RSA et pour ECC dans la littérature. Ainsi, un module RSA de 768 bits a été factorisé dans [65] fin 2009, alors que le record pour ECC est seulement de 109 bits, pour les 2 types de corps F2m et Fp (2002 et 2004, voir [24]). Le prochain niveau du concours pour ECC est fixé à 131 bits par Certicom, qui est l’entreprise organisatrice du concours et détentrice de centaines de brevets sur les implantations ECC. Du côté de RSA, des équipes de recherche travaillent actuellement à la résolution de RSA sur 1024 bits. Malgré les bonnes propriétés mathématiques d’ECC, d’autres types d’attaques existent utilisant les fuites d’information des implantations, comme la consommation d’énergie [69] ou le rayonnement électromagnétique [4]. C’est d’autant plus vrai lorsque nous travaillons sur des implantations sur systèmes embarqués, où des protections spéciales doivent être mises en œuvre. On appelle celles-ci attaques par canaux cachés/auxiliaires (SCA pour side channel attack). Les travaux de la thèse sont effectués dans un contexte d’implantation circuit/systèmes embarqués, ce type d’attaques est donc à prendre en compte. L’objectif est d’avoir une implantation rapide et sûre. Nos travaux portent sur l’accélération des calculs ECC, tout en étant compatibles avec les protections habituelles de l’état de l’art. La taille des nombres avec lesquels on calcule en cryptographie asymétrique (160–521 bits pour ECC, 1024–3072 pour RSA/Diffie-Hellman) donne une importance capitale à l’arithmétique implantée pour effectuer les différentes opérations élémentaires. Ce qu’on12 INTRODUCTION entend ici par opérations élémentaires sont les additions/soustractions, les multiplications et les réductions modulaires dans le corps de base. Les implications des choix d’implantation de ces opérations sont diverses. De très gros opérateurs permettront de gagner un ordre de grandeur en temps d’exécution par exemple, mais consommeront plus d’énergie et peuvent être ainsi plus visibles sur une attaque d’analyse de consommation d’énergie. D’un autre côté, si la priorité n’est pas le temps d’exécution mais la consommation d’énergie ou la surface de silicium utilisée, un petit opérateur, lent, peut suffire. Plus généralement, les contraintes typiques que l’on retrouve pour de tels opérateurs sont la surface utilisée, que l’on peut relier aux moyens financiers nécessaires pour concevoir et faire le circuit, la vitesse d’exécution, le débit de traitement des données et la consommation d’énergie. Pour réaliser des opérateurs arithmétiques répondant aux contraintes fixées par l’application, diverses possibilités existent. Premièrement, on peut toujours doubler le débit si on s’autorise à doubler la surface de circuit, en utilisant deux instances du même opé- rateur. On peut aussi augmenter le nombre d’étages de pipeline, ce qui peut accroître la fréquence d’utilisation et le débit de données mais, en contrepartie, augmente la surface et la consommation d’énergie. Les choix arithmétiques influent aussi sur les performances de l’opérateur. Par exemple, la propagation de retenue dans l’addition ou la multiplication sont un frein à la parallélisation des opérateurs arithmétiques sans représentation adaptée. Certaines représentations des nombres permettent tout de même de paralléliser l’addition ou même la multiplication. C’est le cas de la représentation modulaire des nombres RNS (pour residue number system) qui est l’objet de cette thèse. Plus généralement, la repré- sentation des nombres dans une implantation de cryptographie asymétrique est un élément important à prendre en compte pour accélérer les calculs. Par exemple, certaines représentations, comme RNS, permettent de faire les additions et les multiplications en parallèle. De plus, à chaque représentation correspond des coûts de calcul différents pour les opérations élémentaires addition, multiplication et réduction modulaire, ce qui peut encourager son utilisation pour certaines applications. Certaines opérations spécifiques sont même extrêmement efficaces, et peuvent mener à repenser certains algorithmes. Par exemple, en numération simple de position en base 2, la division et la multiplication par 2 sont très efficaces : elles correspondent à de simples décalages. Le standard américain du NIST [91] propose l’utilisation de courbes elliptiques définies sur des corps qui permettent de tirer parti de la représentation en base 2. Il est proposé d’utiliser des nombres premiers très particuliers, les pseudo-Mersenne [79], permettant d’effectuer les réductions modulaires très efficacement lorsque les valeurs sont représentées en base 2. Par exemple, un des corps proposé est FP521 avec P521 = 2521 − 1, pour lequel 2 additions suffisent pour effectuer une réduction modulaire. Nous verrons dans les travaux de cette thèse qu’il est possible de trouver des nombres premiers qui sont eux adaptés à la représentation modulaire des nombres, que nous allons brièvement introduire ci-dessous. La représentation modulaire des nombres (RNS) Dans cette thèse, une segmentation va être faite entre la numération simple de position qui est de très bas niveau et la représentation finale des valeurs. Nous allons toujours représenter les nombres avec des « groupes de bits », mais organisés de façon bien différente de la représentation habituelle. Cette représentation, appelée représentation modulaire des nombres ou RNS [49, 119] (pour residue number system) a été proposée à l’origine pour des applications de traitement du signal [26, 60] et plus récemment pour des calculs cryp-13 canal 1 ±× mod m1 w z1 w y1 w x1 canal 2 ±× mod m2 w z2 w y2 w x2 . . . . . . . . . . . . canal n ±× mod mn w zn w yn w X xn Y Z Figure 1 – Addition et multiplication sur les canaux parallèles en RNS. tographiques [10, 52, 87]. Cette représentation permet d’effectuer des calculs rapides sur de très grands éléments, entiers ou éléments de grands corps finis, ce qui est très intéressant pour la cryptographie asymétrique. Dans cette représentation, les entiers de ` bits sont découpés en n morceaux bien plus petits, de w bits seulement. Typiquement, pour ECC, on a ` ∈ [160, 600] (pour les besoins de sécurité actuels) et w ∈ [16, 64] en pratique sur les circuits actuels, avec n × w > `. En RNS, un entier X sera représenté par −→ X = (x1, . . . , xn) = (X mod m1, . . . , X mod mn), où (m1, . . . , mn) sont des moduli de w bits. On dit alors que (m1, . . . , mn) est la base RNS et −→ X la représentation RNS de X. On appelle canal tous les traitements effectués modulo un des éléments de la base. L’originalité du RNS vient du fait que pour un certain nombre d’opérations, dont la multiplication et l’addition, les calculs sont fait indépendamment sur chacun des morceaux. En fait, on a : −→ X  −→ Y = (|x1  y1|m1 , . . . , |xn  yn|mn ) , avec  ∈ {+, −, ×}. Les multiplications et les additions/soustractions sont donc découpées en petites opérations indépendantes sur w bits. Ces petites opérations sont parallèles de façon naturelle, permettant d’obtenir très rapidement le résultat d’une somme ou d’un produit. La figure 1 illustre le parallélisme du RNS et l’indépendance des calculs sur les différents moduli/canaux. On a deux arithmétiques distinctes : l’arithmétique sur chacun des canaux et l’arithmétique combinant les canaux pour faire les opérations sur la totalité de l’entier qu’on appellera arithmétique RNS. L’arithmétique des canaux, c’est-à-dire modulo l’un des mi , est en fait l’arithmétique modulaire classique, sur w bits. On représente les valeurs en numération simple de position et on choisit les moduli pour que les calculs soient efficaces, en choisissant des pseudo-Mersenne. Un travail très récent déroge au choix des pseudo-Mersenne, proposé par Bajard et Merkiche [14], ce qui permet d’avoir plus de choix pour définir la base RNS. Ils effectuent des petites réductions de Montgomery [82]14 INTRODUCTION ±× ±, × sur un canal ±, × en RNS changement de base modulo P en RNS 1 n temps n ±× ±× ±× ±× • • • ±× ±× ±× ±× • • • ±× ±× ±× ±× • • • ±× ±× ±× ±× • • • • • • • • • • • • • • • ±× ±× ±× ±× • • • ±× ±× ±× ±× • • • ±× ±× ±× ±× • • • Figure 2 – Séquence de calcul typique en RNS pour la cryptographie : enchaînement de multiplications et d’additions RNS suivies d’une réduction modulo P en supposant les opérations sur les canaux parallélisées. sur les canaux de w bits. Les algorithmes de cette thèse porteront eux sur l’arithmétique RNS, c’est-à-dire sur la combinaison des valeurs dans les différents moduli pour effectuer nos calculs efficacement pour des opérations plus compliquées que la multiplication, comme la réduction modulaire et l’inversion modulaire. Au vu de la figure 1 seule, on pourrait croire qu’avec n unités arithmétiques, il suffit de prendre des moduli très petits, c.-à-d. avec w très petit, pour calculer le plus rapidement possible. Il est vrai qu’en réduisant w, on réduit la complexité des calculs sur chacun des canaux. Par contre, on va augmenter celle de la réduction modulaire, qui est une opération essentielle aux calculs cryptographiques. En effet, la multiplication et la réduction modulaire sont en contradiction en RNS pour le choix de la taille des moduli. La figure 2 illustre le coût d’une réduction modulaire et d’une multiplication ou addition RNS suivant n, le nombre de moduli. Alors qu’une multiplication ne demande que n multiplications de w bits, qui peuvent toutes être effectuées en parallèle, la réduction modulaire a un coût quadratique (≈ 2 n 2 ). En supposant que nous puissions effectuer n multiplications ou additions en parallèle sur une architecture, une multiplication sera effectuée en à peu près 2n fois moins de cycles que la réduction modulaire. Ceci est dû à l’utilisation de changements de base [120] pour la réduction modulaire, qui est une fonction permettant de passer d’une représentation RNS définie par une première base, à une seconde représentation RNS défi- nie par une deuxième base. Cette fonction est, actuellement, indispensable pour faire une réduction modulaire. Le côté quadratique du changement de base est illustré à la figure 2 : chacun des n moduli de la base d’arrivée va opérer sur les valeurs correspondant aux n moduli de la base de départ, ce qui donne bien n 2 opérations. Pour chaque moduli, n opé-15 rations sont effectuées, nous n’avons pas déroulé ces opérations dans la figure 2 par soucis de place. Comme nous le verrons dans le chapitre 1, le choix du nombre de canaux n’est pas une question facile, et n’a pas été très étudié pour des tailles cryptographiques. Une des subtilités de la représentation RNS est que nous devrions plutôt parler de représentations au pluriel. En effet, à la différence de la numération simple de position en base 2 qui est un objet très précis, une représentation RNS va être définie par un ensemble de moduli. C’est d’ailleurs ce qui d’une part, apporte la flexibilité de la représentation, et d’autre part, permet de trouver de nouvelles optimisations en jouant sur l’interaction entre la définition des moduli et l’arithmétique RNS. La plupart des algorithmes de l’état de l’art ne posent que de faibles contraintes sur le choix des moduli, généralement pour garantir une bonne arithmétique sur ceux-ci (on choisit des nombres pseudo-Mersenne). C’est un peu comme si on proposait des algorithmes pour la numération simple de position sans utiliser les spécificités de la base 2. Certaines propositions ont quand même été faites en contraignant plus fortement le choix des moduli, afin d’améliorer l’arithmétique RNS et seront présentées dans l’état de l’art. Par contre, le fait de ne pas trop contraindre le choix des moduli permet d’utiliser certaines protections contre les attaques par canaux cachés basées sur le RNS, comme la contre-mesure Leak Resistant Arithmetic (LRA [11]). Cette protection consiste à tirer au hasard une base avant d’effectuer le calcul cryptographique, ce qui a pour effet de changer la représentation des éléments, et permet de lutter contre des attaques statistiques sur plusieurs exécutions de ce calcul. Dans le cadre d’implantations matérielles pour la cryptographie, la représentation RNS n’a pas encore connu beaucoup d’évolutions. En effet, la plupart des implantations sont complètement parallélisées, c’est-à-dire avec autant d’unités de calcul que de canaux, afin d’obtenir un temps d’exécution le plus faible possible (cf. table 1.6 dans la section 1.3.5). Parfois, pour certaines implantations sur de grands paramètres, comme pour RSA, un grand diviseur du nombre de moduli a été choisi. On peut citer en exemple l’implantation de Nozaki et al. [87], qui intègre 11 unités arithmétiques parallèles, pour des bases de 22, 33 ou 66 moduli. Pourtant, la flexibilité du RNS devrait mener à toute une zoologie de types d’implantations différentes, que ce soit grâce à l’indépendance des canaux ou encore la flexibilité sur la paramétrisation des canaux. En effet, la modularité que permet naturellement la représentation peut sembler sous-exploitée au vue des références de l’état de l’art. En réalité, comme présenté au chapitre 1, le nombre de propositions est en train d’augmenter, bien que souvent basées sur le même modèle. La modularité a au moins deux avantages pour nos applications. Premièrement, elle permet de changer facilement la surface allouée à notre circuit, sans changer les opérateurs implantés : il suffit de retirer ou d’ajouter des unités arithmétiques de calcul sur les moduli. C’est un véritable atout lorsque l’on considère la conception d’un produit pour qui la cryptographie et la sécurité ne sont seulement que des fonctionnalités annexes, certes nécessaires, du cahier des charges, comme par exemple pour un service de vidéo à la demande. Deuxièmement, grâce à cette modularité, on peut de réduire le nombre d’unités arithmétiques, permettant de rendre aléatoire l’ordre des moduli sur lesquels on calcule, à l’intérieur d’une même base, pour protéger le circuit contre certaines attaques par canaux cachés. Outre une partie des possibilités d’implantation qui n’ont pas été exploitées, la représentation elle-même n’a subi que très peu de modifications pour fournir de meilleurs résultats. Les mises en œuvre du RNS ne s’éloignent finalement que très peu de la définition provenant du théorème des restes chinois. Par opposition, l’arithmétique sur la représentation16 INTRODUCTION classique binaire a subit toute sorte de modifications pour accélérer les calculs, que ce soit pour les additions ou les multiplications (par exemple en introduisant de la redondance dans la représentation). Dans le cas du RNS, le calcul modulaire utilise 2 bases de tailles égales depuis que les premières adaptations RNS de l’algorithme de réduction modulaire de Montgomery ont été proposées [6, 64, 99]. Les améliorations de la réduction modulaire en RNS sont depuis lors toujours restées sur cette approche, généralement en améliorant des sous-parties de l’algorithme. La représentation n’a été véritablement modifiée que ré- cemment, avec les travaux de Gandino et al. [48]. Les auteurs se sont autorisés à ne pas travailler exactement en représentation RNS dans la seconde base, mais cette modification leur a permis de réduire le nombre de calculs car celle-ci s’intègre parfaitement dans l’algorithme de réduction de Montgomery RNS. Même si dans les détails la proposition de Gandino et al. [48] reste très proche du RNS habituel, elle marque peut-être le début d’une évolution beaucoup plus profonde de l’arithmétique RNS. Le RNS est utilisé pour faire le lien entre les mathématiques et l’arithmétique d’un côté, et le matériel de l’autre : il y a donc deux directions vers lesquelles tendre pour améliorer les implantations. Le travail de Gandino et al. porte essentiellement sur la ré- duction du nombre d’opérations, leur travail tend donc à améliorer le côté arithmétique même si cela permet au final de réduire le nombre de cycles dans leur implantation RSA en RNS. Elle ne porte pas sur une évolution du RNS pour le matériel. Il n’y a pas encore eu, à notre connaissance, de véritables modifications de la représentation afin d’obtenir une architecture moins coûteuse par exemple. Il est quand même souvent considéré que w, la taille des moduli, est très proche de la taille des mots machines, ou des multiplieurs des blocs DSP pour les implantations FPGA. Malgré tout, cette considération est juste un choix plus ou moins astucieux des moduli, et non pas une transformation de la repré- sentation pour le matériel. On essaye généralement de faire une bonne implantation du RNS classique plutôt que d’essayer de modifier celui-ci pour avoir une bonne implantation. Après tout, la représentation RNS hérite naturellement d’un certain nombre de bonnes propriétés pour le matériel, comme la non propagation de retenue pour l’addition et la multiplication, et son haut niveau de parallélisme. C’est donc déjà un bon point de départ pour le matériel, mais ce potentiel là n’a peut-être pas, et même sûrement pas, atteint son maximum. Dans un futur proche, outre les améliorations arithmétiques, la représentation RNS gagnera sûrement aussi sur son implantation. Pour finir, les caractéristiques particulières du RNS permettent non seulement d’obtenir des implantations cryptographiques rapides, mais aussi de protéger le circuit. Nous avons évoqué l’existence de propositions contre les attaques statistiques sur la consommation de courant ou le rayonnement électromagnétique avec le tirage aléatoire de l’ordre des calculs ou de la base (protection LRA [11]). Il existe aussi des protections contre les attaques par injection de faute dans [9] et [53]. Des premières études d’implantations de telles protections ont récemment été publiées, par exemple [94], aboutissant à de bons résultats en terme de protection. Ces implantations sont par contre toujours proposées dans une architecture complètement parallèle, afin de se comparer à des résultats d’implantation sans protection en RNS. On pourrait aussi imaginer des architectures beaucoup plus orientées sécurité que performance, et utiliser la modularité que propose la représentation RNS pour avoir encore plus d’aléa que dans le cas complètement parallèle. C’est aussi un aspect important du RNS, mais qui n’a pas été traité dans cette thèse pour des raisons de temps. Les sujets de recherche sur la représentation RNS sont donc assez vastes, et beaucoup17 de travaux seront encore publiés sur le sujet. Pour conclure cette introduction, les travaux de cette thèse vont être rapidement introduit via la présentation du plan de la thèse. Objectifs et plan de la thèse Les objectifs de la thèse sont d’améliorer les performances des implantations cryptographiques utilisant le RNS, avec comme objectif particulier ECC. Ces améliorations doivent être raisonnables en terme de surface de circuit utilisée, nous avons donc gardé comme support architectural l’implantation proposée par Guillermin dans [52], qui est l’état de l’art des implantations ECC en RNS, et est elle-même basée sur l’architecture de Kawamura et al. [64]. Ces contributions gardent les bonnes propriétés du RNS (indépendance des canaux), mais vont parfois utiliser certaines contraintes pour plus d’efficacité. Le premier chapitre porte sur le contexte de mes travaux, et l’état de l’art dans lequel ils s’inscrivent. La cryptographie asymétrique y est présentée plus en détail, en introduisant les cryptosystèmes qui vont nous intéresser tout au long du document. Certaines techniques classiques de calcul pour la cryptographie seront présentées, ainsi que certaines notions sur la sécurité des implantations de celles-ci. Ensuite sont présentés certains algorithmes de l’arithmétique modulaire classique, en numération simple de position en base 2. Ceux-ci sont souvent à la base des algorithmes de l’état de l’art en RNS (ou du moins leurs idées fondatrices), et le travail présenté au chapitre 2 reprend par exemple des idées sur les algorithmes d’inversion. Enfin, le chapitre 1 se termine sur un état de l’art de l’arithmétique RNS pour la cryptographie. L’accent est notamment mis sur la réduction modulaire qui est l’opération élémentaire qui coûte le plus cher dans les implantations cryptographiques en RNS. Un état de l’art des implantations RNS est présenté et analysé, ainsi que les choix d’architecture. La première contribution de la thèse, présentée au chapitre 2, porte sur l’inversion modulaire en RNS. Cette opération difficile en RNS est effectuée généralement grâce à une exponentiation, en utilisant le petit théorème de Fermat. Cette opération est très longue en RNS, elle représente environ 10% du temps total de calcul d’une multiplication scalaire complète (qui est le calcul principal pour ECC). Le coût en RNS des comparaisons et des divisions nécessaires aux algorithmes de type « Euclide étendu » ont fait qu’il était préfé- rable de garder l’exponentiation de Fermat, notamment dans le cadre d’une implantation matérielle ou aucun matériel supplémentaire n’est requis. Notre proposition est une adaptation RNS de l’algorithme d’Euclide étendu binaire, utilisant une certaine astuce pour éviter les comparaisons et pouvant être utilisée sur l’architecture de l’état de l’art des courbes elliptiques en RNS avec quelques petites modifications. Il en résulte un algorithme bien plus rapide que l’état de l’art (de 5 à 12 fois plus rapide sur nos implantations FPGA) et coûtant bien moins d’opérations pour une surface de circuit similaire. Ce travail a fait l’objet d’une première publication à CHES 2013 [19], et sera soumis à un journal dans une version étendue avec les nouveaux résultats présentés dans le chapitre ainsi qu’un nouvel algorithme, qui n’a pas encore été implanté mais qui coûte moins d’opérations que notre première proposition [19]. Le chapitre 3 présente deux contributions. La première a été publiée à ASAP 2014 [20] sur la multiplication modulaire en RNS. La seconde contribution est un nouvel algorithme d’exponentiation, encore non publié. L’idée principale de ce chapitre est de séparer les multi-18 INTRODUCTION plications modulaires RNS en 2 parties, tout d’abord une étape de décomposition spécifique à chacun des opérandes, puis une deuxième étape dépendant des deux opérandes pour obtenir le résultat final. Ce qui va permettre de réduire le coût des calculs, c’est que l’on peut factoriser les étapes de décomposition entre plusieurs multiplications modulaires, à chaque réutilisation d’une des opérandes. Par exemple, dans l’état de l’art de l’arithmétique RNS, un carré ou une multiplication par une constante coûte aussi cher qu’une multiplication quelconque. Nous proposons un nouvel algorithme de multiplication qui, lui, va être capable de profiter de ces réutilisations. Notre proposition est cependant moins performante que l’algorithme de l’état de l’art sur les multiplications de deux opérandes quelconques, s’il n’y pas de réutilisation. Suivant les séquences de calcul effectuées, nous obtenons des coûts en nombre d’opérations meilleurs que l’algorithme de l’état de l’art sur des grands paramètres cryptographiques. On réduit aussi le nombre de pré-calculs à stocker vis à vis de l’algorithme de l’état de l’art [48]. Les résultats obtenus sont bons pour des exponentiations pour les applications du logarithme discret comme les protocoles de Diffie-Hellman [38] ou Elgamal [44]. Cet algorithme requiert par contre que le nombre premier p, qui définit le corps de base Fp, ait une forme particulière adaptée au RNS. Cette condition empêche son utilisation dans le cadre de RSA. Par contre, en reprenant certaines idées sur la réutilisation, un nouvel algorithme d’exponentiation est proposé, sans condition sur p. Ce dernier algorithme peut, lui, être utilisé avec RSA. Il permet de réduire le nombres d’opérations par rapport à l’exponentiation de l’état de l’art en RNS [48], mais demande plus de pré-calculs. La troisième contribution de la thèse, présentée au chapitre 4, porte sur un autre algorithme de multiplication modulaire en RNS. Dans cette proposition, nous ne représentons plus directement les valeurs en RNS. En fait nous découpons nos entiers en deux sousvaleurs qui, elles, sont représentées en RNS, en reprenant l’idée de décomposition du chapitre 3. Avec ce découpage, on casse un peu l’aspect non positionnel de la représentation car les deux sous-valeurs satisfont une relation pour retrouver la représentation RNS de notre valeur initiale. Grâce à cette nouvelle représentation et à l’introduction de l’équivalent des premiers de Mersenne pour le RNS, nous obtenons un algorithme qui divise presque par 2 le nombre d’opérations élémentaires par rapport à l’état de l’art, et qui est utilisable pour des implantations de cryptographie sur courbes elliptiques. De même, le nombre de moduli requis est divisé par 2 et le nombre de pré-calculs nécessaires par 4. Un peu à la façon de l’utilisation des premiers pseudo-Mersenne du standard NIST [91] spécialement adaptés à la numération simple de position en base 2, nous proposons une nouvelle façon de choisir le corps de base spécialement adapté au calcul en RNS. Une implantation FPGA de l’algorithme a été faite, presque deux fois plus petite que notre implantation de l’algorithme de l’état de l’art, avec un faible surcoût en temps. Cette contribution fera bientôt l’objet d’une soumission. Le chapitre 5 est un chapitre à part dans la thèse car il ne concerne pas directement le RNS, bien que traitant de tests de divisibilité et de calcul modulaire. Ce travail a été publié à ComPAS 2013 [18] et est issu d’une collaboration avec un autre doctorant (à l’époque), Thomas Chabrier. Ce travail s’intègre dans un contexte de recodage de clé appelé système de représentation des nombres à base multiple [25,73] (MBNS pour multi base number system) pour accélérer les calculs d’une multiplication scalaire d’une courbe elliptique. Cette accélération intervient au niveau de l’algorithme de multiplication scalaire, et non pas de l’arithmétique : elle est donc parfaitement compatible avec l’utilisation de la représentation RNS. Ce chapitre présente une méthode pour effectuer en matériel des tests de divisibilité de très grands nombres par de petites constantes, en parallèle. L’idée est de pouvoir effec-19 tuer à la volée le recodage, ce qui est nécessaire si par exemple on introduit un aléa dans le scalaire pour le protéger contre des attaques par canaux cachés. L’idée principale est de remarquer qu’un certain nombre de factorisations dans les calculs peuvent être effectuées, réduisant le coût de notre opérateur de test de divisibilité. Pour faire apparaître ces factorisations, il ne faut plus travailler seulement en base 2, mais dans une base plus grande de la forme 2 w. Grâce à ces factorisations, les parties qui sont propres à chacun des tests de divisibilité sont très réduites, ne prenant en entrée que w +  bits ( = 3, 4 ou 5) au lieu de travailler sur les centaines de bits en entrée. Pour finir, la conclusion propose une synthèse des idées principales qui ont mené aux différentes contributions de cette thèse et présente des perspectives à court terme de travaux dans la lignée de ceux-ci. Le plus long terme est aussi discuté, notamment sur certaines évolutions possibles du RNS et des architectures RNS au vu des résultats obtenus.20 INTRODUCTIONNotations Nous allons ici introduire un certain nombre de notations utilisées dans le reste du document. Tout d’abord, des sigles généraux sont présentés à la table 1 puis les notations utiles à la représentation RNS à la table 2. Les notations présentées pour le RNS ne sont utilisées qu’à partir de la section 1.3 et jusqu’à la fin du chapitre 4. Pour résumer, elles ne sont valables que pour les parties traitant du RNS. Les notations utilisées dans le début du chapitre 1 et dans le chapitre 5 sont détaillées localement car bien moins complexes que celles du RNS. La complexité des notations du RNS vient du fait que premièrement, il y a en fait une représentation RNS par base (il faut donc pouvoir les différencier) et deuxièmement, on rajoute un étage de détails dans les algorithmes. Par exemple, si nous prenons le cas des courbes elliptiques, un point de la courbe est défini par un ensemble de coordonnées sur un corps fini, par exemple FP . À ces éléments de FP vont être associés des représentations RNS, elles-mêmes constituées de petites composantes entières. De même, les opérations élémentaires comme l’addition sont déclinées en plusieurs niveaux : l’addition de points, d’éléments de FP , de leur représentation RNS et enfin des composantes d’une représentation RNS. Dans une tentative de hiérarchisation, les notations suivantes sont proposées. Les lettres majuscules en gras représenteront les points d’une courbe, les lettres majuscules fines seront des éléments de FP , les représentations RNS seront notées comme des vecteurs et enfin leurs composantes seront notées en minuscule (voir table 2). 2122 NOTATIONS ADD addition de deux points distincts d’une courbe elliptique bloc DSP unité de calcul contenant un multiplieur/accumulateur sur FPGA (DSP pour digital signal processing) BRAM bloc RAM dans un FPGA CRT théorème chinois des restes (chinese remainder theorem) DBL doublement d’un point d’une courbe elliptique DBNS système de numération à base double (double base number system) DH cryptosystème de Diffie-Hellman [38] DLP problème du logarithme discret (discrete logarithm problem) DPA analyse différentielle de la puissance consommée (differential power analysis) DSA standard du NIST de signature numérique [91] (digital signature algorithm) ECC cryptographie sur courbes elliptiques (elliptic curve cryptography) ECDH cryptosystème de Diffie-Hellman sur courbes elliptiques (elliptic curve DH ) ECDLP problème du logarithme discret sur les courbes elliptiques (elliptic curve DLP) ECDSA standard du NIST de signature numérique ECC (elliptic curve DSA) FF bascule (flip-flop) FFDLP problème du logarithme discret sur les corps finis (finite field DLP) FPGA circuit logique programmable (field programmable gate array) FLT petit théorème de Fermat (Fermat’s little theorem) LSBF bit de poids faibles en tête (least significant bits first) LUT table de correspondance (look-up table) mADD addition mixte de deux points distincts d’une courbe elliptique MBNS système de numération à base multiple (multi base number system) MRS représentation en base mixte (mixed radix system) MSBF bit de poids forts en tête (most significant bits first) NAF forme non adjacente d’un nombre (non adjacent form) NIST institut de standardisation américain (national institue of standards and technology) P, Q points d’une courbe elliptique pgcd plus grand commun diviseur ppcm plus petit commun multiple RSA cryptosystème de Rivest, Shamir et Adleman [102] RNS représentation modulaire des nombres (residue number system) SPA analyse simple de la puissance consommée (simple power analysis) TPL triplement d’un point d’une courbe elliptique VHDL langage de description matérielle (VHSIC hardware description language) VHSIC circuits intégrés très haute vitesse (very high speed integrated circuits) Table 1 – Notations générales valables pour tout le document23 X, Y éléments de FP ou grands entiers P un grand nombre premier définissant le corps de base ` taille de P, ` = dlog2 Pe et ` ≈ 160–550 bits pour ECC w taille d’un mot élémentaire ou d’un canal n nombre de mots nécessaires pour représenter une valeur de ` bits k scalaire de la multiplication scalaire, k ∈ N (p. ex. Q = [k]P) |X|P autre notation de X mod P, pour des besoins de concision Ba = (ma,1, . . . , ma,na ) une première base RNS de na moduli Bb = (mb,1, . . . , mb,nb ) une deuxième base RNS de nb moduli Bc = (mc,1, . . . , mc,nc ) une troisième base RNS de nc moduli ma,i, mb,i, mc,i entiers premiers entre eux 2 à 2, avec ms,i = 2w − hs,i et hs,i < 2 w/2 pour s ∈ {a, b, c} Ba|b = (ma,1, . . . , mb,nb ) concaténation des bases Ba et Bb −−−→ (X)s = (xs,1, . . . , xs,ns ) représente l’élément X en base Bs (p. ex. s = a ou s = b|c) avec xs,i = |X|ms,i , peut être abrégé en −→ Xs Ms produit des moduli de la base Bs : Qs i=1 Ms,i le produit de tous les moduli de Bs sauf ms,i : Ms ms,i −→ Ts  |Ms,i|ms,i , . . . , |Ms,n|ms,n  , défini pour le CRT Xb modification de la représentation RNS pour les sections 2.2 et 2.3 EMM multiplication élémentaire de w bits modulo un des ms,i EMA addition élémentaire de w bits modulo un des ms,i EMW mot mémoire élémentaire de w bits BE extension (ou changement) de base MR réduction de Montgomery RNS de l’état de l’art MM multiplication de Montgomery RNS de l’état de l’art FLT-MI inversion modulaire en RNS de l’état de l’art basée sur FLT PM-MI algorithme d’inversion modulaire plus-minus proposé chap. 2 BTPM-MI variante binaire-ternaire du PM-MI proposé chap. 2 SPRR algorithme de multiplication modulaire RNS proposé chap. 3 (split - partial reduction - reduction) SBMM algorithme de multiplication modulaire RNS proposé chap. 4 (single base modular multiplication) Cox-Rower architecture RNS de l’état de l’art pour la cryptographie Rower élément du Cox-Rower calculant modulo l’un des ms,i Cox élément permettant de détecter les dépassements lors des BE Table 2 – Notations spécifiques au RNS24 NOTATIONSChapitre 1 État de l’art 1.1 La cryptographie asymétrique La cryptographie asymétrique repose sur la notion de fonction à sens unique à trappe, c’est à dire une fonction facile à calculer dans un sens, mais dont l’inverse est très difficile à calculer sans avoir la clé correspondant à la trappe [38]. Une inversion de la fonction sans clé est censée être impossible, ou du moins à un coût « raisonnable » par rapport à l’application visée. On peut par exemple estimer que pour certaines applications, une résistance aux meilleures attaques connues nécessitant plusieurs années sur plusieurs centaines de machines est suffisante. D’un autre côté, pour certaines applications relevant du secret défense, des informations doivent rester confidentielles pour des dizaines d’années, ce qui est aujourd’hui difficile à garantir. Grâce aux fonctions à sens unique à trappe, on peut définir des protocoles tels que ceux de Diffie-Hellman [38], qui permettent à deux interlocuteurs d’échanger une clé commune. Une autre utilisation est la signature numérique, par exemple les standards Digital Signature Algorithm (DSA) et Elliptic Curve Digital Signature Algorithm (ECDSA) de l’institut américain National Institute of Standards and Technology (NIST) [91]. Ce type de cryptographie est aussi appelé à clé publique car elle ne nécessite pas de clé secrète partagée au préalable par les deux interlocuteurs. Les travaux de Diffie et Hellman [38], puis de Rivest, Shamir et Adleman [102] font parti des pionniers de la cryptographie asymétrique, et sont toujours très utilisés dans les systèmes de sécurité actuels. On compte aussi parmi ces pionniers Clifford Cocks, qui découvrit RSA [102] avant ses auteurs en 1973 mais dont l’algorithme avait été classifié par le gouvernement britannique puis déclassifié en 1997 [30]. 1.1.1 Le cryptosystème RSA Le cryptosystème RSA, du nom de ses auteurs Rivest, Shamir et Adleman [102], repose sur un problème qui lui est propre, que nous appellerons RSAP, et qui s’énonce ainsi : soient n un entier produit de deux nombres premiers p et q (distincts), et e un nombre premier avec (p − 1) et (q − 1). Étant donné c, résoudre le RSAP revient à trouver m tel que me ≡ c mod n ou, autrement dit, cela revient à trouver la racine e-ème d’un élément modulo n. Ce problème est proche du problème de la factorisation des grands entiers. Notamment, si on est capable de factoriser n en p et q, on peut alors calculer d l’inverse de e modulo (p−1)(q −1), et finalement on calcule (me ) d = m mod n ce qui résout le RSAP. On ne sait pas par contre si la résolution du RSAP permet de résoudre le problème de la factorisation. 2526 CHAPITRE 1. ÉTAT DE L’ART Le protocole de chiffrement RSA est présenté à l’algorithme 1. On considère que le message à chiffrer est un entier naturel inférieur ou égal à n − 1 (si besoin, découper les messages). Le principal calcul est l’exponentiation modulaire et peut être effectué à l’aide d’un des algorithmes présentés en section 1.1.4. À cause des algorithmes de factorisation des grands entiers tels que NFS [70] (number field sieve), le nombre d’opérations à effectuer pour casser RSA avec n = 1024 bits n’est que de 2 80. Ainsi, en 2009, un module RSA de 768 bits a été factorisé [65], ce qui a nécessité des centaines de machines en parallèle et plus de deux ans et demi de calcul. Différents chercheurs étudient sérieusement la possibilité de mettre en œuvre un système pour casser RSA 1024 bits. Algorithme 1: Protocole de chiffrement RSA [102]. Entrées : Alice diffuse sa clé publique (n, e) et garde secrète d sa clé privée Entrées : Bob veut chiffrer le message m pour Alice, un nombre dans [0, n − 1] Chiffrement 1) Bob récupère la clé publique de Alice, c’est à dire (n, e) 2) Bob calcule l’exponentiation modulaire c = me mod n 3) Bob envoie c à Alice Déchiffrement 1) Alice calcule m = c d mod n 1.1.2 Le problème du logarithme discret, application dans les corps finis Un autre problème célèbre est celui du logarithme discret (DLP). Il peut être vu comme une fonction à sens unique et est utilisé dans certains standards de cryptographie asymé- trique. Le problème est défini comme suit (voir [78], pages 103–113) : soient (G, ×) un groupe cyclique fini et g ∈ G un élément qui le génère. Calculer le logarithme discret de h revient à trouver d tel que h = g d dans G. Certains cryptosystèmes sont basés sur le DLP sur des groupes G pour lesquels le logarithme est difficilement calculable. Une idée naturelle de groupe est de choisir les éléments de F ∗ p , mais à cause de l’attaque du calcul d’indices sur F ∗ p (voir [3]), on l’utilise peu. Si on l’utilisait, l’attaque réduirait par exemple la sécurité d’un système à clé de 1024 bits à seulement 80 bits de sécurité (comme pour RSA). Dans les faits, on choisit plutôt un sousgroupe de F ∗ p , noté G, d’ordre premier q. Par exemple, un sous-groupe avec environ 2 160 éléments (log2 q ≈ 160) pour p de taille 1024 bits (voir par exemple [91]). Comme expliqué à la page 113 de [78], le calcul d’indices ne semble pas pouvoir s’appliquer directement sur ce sous-groupe, on doit alors l’appliquer sur tout F ∗ p , le passage de F ∗ p au sous-groupe n’impacte donc pas la sécurité du point de vue de cette attaque. Par contre, il faut faire attention à d’autres attaques sur le sous-groupe, comme celle de Pohlig-Hellman [96] et l’attaque rho de Pollard [97] qui sont en O( √q) opérations, donnant un nombre de bits de sécurité correspondant à (log2 q)/2 lorsque q est premier. Il faut choisir q premier car ces attaques dépendent seulement de la taille du plus gros facteur premier de q. La sécurité conférée par ce problème est donc le minimum des attaques sur F ∗ p et sur le sous-groupe sélectionné. Il est recommandé de choisir des paramètres tels que le système soit aussi ré- sistant aux deux types d’attaque. Par exemple, si blog2 qc = 160 bits, on a donc 80 bits de sécurité pour l’attaque Pohlig-Hellman, on prend alors blog2 pc = 1024 on a aussi 80 bits de sécurité pour le calcul d’indices [91]. Si on compare avec RSA, on se retrouve avec un même niveau de sécurité en traitant avec des éléments de même taille (1024 ou 2048 bits1.1. LA CRYPTOGRAPHIE ASYMÉTRIQUE 27 par exemple), mais le DLP dans les corps finis (FFDLP) offre des clés bien plus petites (160 bits contre 1024 par exemple). Le standard américain DSA [91] du NIST, l’échange de clés de Diffie et Hellman [38] (DH, présenté algorithme 2) et le chiffrement d’Elgamal [44] (algorithme 3) se basent sur le fait que le FFDLP n’est pas résoluble en pratique sur un groupe approprié. Les deux cryptosystèmes sont utilisés dans les conditions décrites dans le paragraphe précédent, c’est à dire q est l’ordre de g modulo p, et q est un grand nombre premier. Le problème utilisé pour ces deux protocoles est en réalité un peu plus faible que le FFDLP car il suffit de savoir forger g ab à partir de g a et g b pour casser ces deux protocoles (il est évident que si le FFDLP devient facile, ces cryptosystèmes n’apportent plus aucune sécurité). Algorithme 2: Échange de clé de Diffie-Hellman [38]. Entrées : Alice et Bob sont d’accord sur (p, q, g) où q et p sont premiers, et q est l’ordre de g dans F ∗ p 1) Alice (respectivement Bob) tire un nombre au hasard a (resp. b) dans [2, q − 2] 2) Alice (respectivement Bob) calcule u = g a mod p (resp. v = g b mod p) 3) Alice (respectivement Bob) envoie u (resp. v) à Bob (resp. Alice) 4) Alice (respectivement Bob) calcule la clé partagée g ab = v a mod p (resp. g ab = u b mod p) Algorithme 3: Protocole de chiffrement Elgamal simple [44]. Entrées : Alice garde secrète a sa clé privée et diffuse (p, q, g, ga ) sa clé publique Entrées : Bob veut chiffrer le message m pour Alice, un nombre dans [0, p − 1] Chiffrement 1) Bob récupère la clé publique de Alice, c’est à dire (p, q, g, ga ) 2) Bob choisi k au hasard tel que 1 6 k 6 p − 2 3) Bob calcule les exponentiations modulaires γ = |g k |p et δ = |m · (g a ) k |p 4) Bob envoie (γ, δ) à Alice Déchiffrement 1) Alice calcule γ −a mod p 2) Alice obtient m = δ · γ −a mod p28 CHAPITRE 1. ÉTAT DE L’ART −2 −1 0 1 2 0 1 2 −1 −2 Figure 1.1 – Courbe elliptique d’équation y 2 = x 3 − x sur R. 1.1.3 Le problème du logarithme discret sur les courbes elliptiques Nous allons maintenant nous intéresser à un autre groupe défini à l’aide d’une courbe elliptique et l’utiliser pour le DLP. On va définir ainsi l’ECDLP, le problème du logarithme discret sur les courbes elliptiques. L’idée d’utiliser les courbes elliptiques pour la cryptographie a été proposée indépendamment par Koblitz [67] et Miller [80] dans le milieu des années 1980. Cette section rappelle rapidement les définitions et outils nécessaires à la compréhension du cadre de mes travaux, mais son but n’est pas de détailler toutes les mathématiques sous-jacentes. Des ouvrages tels que [57] ou [31] apporteront au lecteur plus de détails sur la cryptographie sur courbes elliptiques (ECC) et les mathématiques sur lesquelles elle repose. Définition 1. Une courbe elliptique E/K est une courbe lisse définie sur un corps K par l’équation : E : y 2 + a1xy + a3y = x 3 + a2x 2 + a4x + a6 (1.1) où a1, a2, a3, a4, a5, a6 ∈ K. Le fait que la courbe soit lisse, c.-à-d. sans singularité, se traduit par le fait que δ 6= 0, où δ est le discriminant défini par :    δ = −d 2 2 d8 − 8 d 3 4 − 27 d 2 6 + 9 d2 d4 d6 d2 = a 2 1 + 4 a2 d4 = 2 a4 + a1 a2 d6 = a 2 3 + 4 a6 d8 = a 2 1 a6 + 4 a2 a6 − a1 a3 a4 + a2 a 2 3 − a 2 4 . L’équation 1.1 est communément appelée équation de Weierstrass. Les points de la courbe E/K sont tout simplement les couples (x, y) ∈ K2 qui satisfont l’équation 1.1. La figure 1.1 montre un exemple de courbe elliptique sur R alors que la figure 1.2 montre 3 exemples sur des corps finis Fp, pour des petits p non utilisables en pratique.1.1. LA CRYPTOGRAPHIE ASYMÉTRIQUE 29 Figure 1.2 – Points des courbes définies par y 2 = x 3 + 3x + 5 sur F113, F1223 et F11489. L’équation 1.1 peut être simplifiée sous certaines hypothèses sur le corps, en appliquant un certain changement de variable. Si K a une caractéristique différente de 2 ou 3 alors le changement de variable : (x, y) −→  x − 3a 2 1 − 12a2 36 , y − 3a1x 216 − a 3 1 + 4a1a2 − 12a3 24  permet de réécrire l’équation de E/K en : y 2 = x 3 + ax + b (1.2) où (a, b) ∈ K2 . Le discriminant devient alors δ = −16(4a 3 + 27b 2 ). On appelle forme de Weierstrass courte l’équation 1.2, dans le cas où la caractéristique est différente de 2 et 3. Nous allons plus précisément travailler sur le corps K = Fp, où p est un grand nombre premier de plusieurs centaines de bits. Dans le cadre de cette thèse, les corps en petite caractéristique (F2m) ne seront pas étudiés. En effet, l’arithmétique dans ces corps est très différente du cas Fp et le système RNS, sous sa forme actuelle, ne semble pas bien adapté à ces corps. Le lecteur curieux d’en savoir plus sur les courbes définies sur F2m pourra consulter par exemple [31, 57]. Loi de groupe et ECDLP Nous allons présenter le groupe sur lequel nous appliquerons le DLP. Une loi de groupe peut être définie sur l’ensemble des points de la courbe. Cette loi sera notée +, P+Q est donc l’addition des points P et Q. Ces points sont représentés par leurs coordonnées affines P = (x1, y1) et Q = (x2, y2). La loi + applique la règle de la corde et la tangente qui, à partir de 2 points P et Q de la courbe tels que P 6= ±Q, donne un troisième point R aussi sur la courbe. La corde reliant P à Q coupe en fait la courbe en un troisième point (S sur la figure 1.3), le résultat est ensuite obtenu en prenant le symétrique par rapport à l’axe des abscisses (illustration à la figure 1.3 (a)). Le doublement de point est le cas spécial de l’addition de point où l’on additionne un point à lui même c’est à dire [2] P = P+P. Dans ce cas, au lieu de prendre la corde on prend la tangente à la courbe passant par P (voir figure 1.3 (b)). Une différenciation va donc être faite suivant la nature des opérandes, pour effectuer soit une addition soit un doublement. Pour noter spécifiquement le doublement de la loi de groupe on utilisera DBL dans la suite de ce manuscrit et ADD pour l’addition de30 CHAPITRE 1. ÉTAT DE L’ART −2 −1 0 1 2 0 1 2 −1 −2 S R P Q (a) −2 −1 0 1 2 0 1 2 −1 −2 S R P (b) Figure 1.3 – Addition (a) et doublement (b) de points sur la courbe y 2 = x 3 − x sur R. 2 points distincts. La description de la loi est faite à la figure 1.3 de façon géométrique sur R, justifiant le nom « règle de la corde et la tangente ». On peut aussi la définir de façon algébrique, et l’adapter à des courbes sur Fp (illustrées à la figure 1.2). Afin de déterminer complètement la loi de groupe, l’élément neutre O est défini, aussi appelé point à l’infini. On ne peut pas lui attribuer de coordonnées affines, c’est ici une sorte de vue de l’esprit pour compléter la loi de groupe. On l’appelle point à l’infini car on peut l’imaginer comme un point qui serait à l’infini en coordonnée y, et pour lequel toutes les droites d’équation x = c (c constant) passerait (voir l’exemple sur R [31], page 269). Définition 2 (Loi de groupe en caractéristique 6= 2 et 3, pour une courbe d’équation 1.2). Soient P = (x1, y1), Q = (x2, y2) deux points de E/Fp. On définit la loi de groupe sur les points de la courbe comme suit : Élément neutre : P + O = O + P = P. Opposé d’un point : L’opposé de P est -P = (x1, −y1) (qui est aussi un point de la courbe), on a donc P + (- P) = O. Addition de points ADD : Si P 6= ±Q alors P+Q = (x3, y3) est un point de E/Fp où x3 = λ 2 − x1 − x2, y3 = λ(x1 − x3) − y1 avec λ =  y2−y1 x2−x1  . Doublement de point DBL : Si P 6= O alors [2]P = (x3, y3) est un point de E/Fp où x3 = λ 2 − 2x1, y3 = λ(x1 − x3) − y1 avec λ =  3x 2 1+a 2y1  . Cette loi de groupe va permettre de définir le problème du logarithme discret pour les courbes elliptiques : l’ECDLP. On peut vérifier que la loi présentée est bien interne : si R = P+Q, alors R ∈ E/Fp. Elle est aussi associative, car on a (P+Q)+R = P+(Q+R). L’opération principale des protocoles qui sont basés sur l’ECDLP est la multiplication sca-1.1. LA CRYPTOGRAPHIE ASYMÉTRIQUE 31 laire (l’équivalent de l’exponentiation pour le FFDLP). La multiplication scalaire [k]P revient à accumuler k fois le point P grâce à l’opération d’addition que nous venons de définir. Des techniques pour effectuer cette opération sont présentées en section 1.1.4. Le problème de l’ECDLP est donc le suivant. Soient (E/K, +) le groupe des points de la courbe et P un élément qui génère ce groupe, alors calculer le logarithme discret de Q revient à trouver k tel que Q = [k]P. Si on définit ce groupe là, avec une loi moins naturelle que celle de (Fp, ×), c’est parce qu’il n’y a pas d’autres attaques connues sur le groupe des points d’une courbe elliptique que les attaques génériques contre le problème du DLP, si certaines précautions sont prises. Ainsi, on ne sait actuellement pas faire d’attaques comme celle du calcul d’indice, alors que celle-ci fonctionne contre le FFDLP. Cependant, les attaques comme celles de Pollard [97] et de Pohlig-Hellman [96] sont toujours applicables, ce qui veut dire que l’ordre du groupe, c’est à dire le nombre de points de la courbe #E(Fp), doit toujours être divisible par un grand nombre premier. En pratique, on va choisir une courbe telle que #E(Fp) = lq avec l petit, par exemple l ∈ {1, 2, 3, 4} et q un grand nombre premier. On va donc travailler sur le sous-groupe d’ordre q. De plus, le théorème de Hasse [58] (théorème 1) nous garantit que #E(Fp) est de la même taille que p. On en conclut donc que pour 80 bits de sécurité, en prenant un p de 160 bits, on va générer des courbes d’environ 2 160 points. Il suffit de trouver une courbe telle que #E(Fp) = lq avec l petit et nous aurons un système offrant a priori une sécurité de 80 bits, pour des clés de 160 bits mais aussi des calculs sur des nombres de 160 bits (au lieu de 1024 pour l’application du FFDLP). Théorème 1 (Hasse [58]). Soit E une courbe elliptique définie sur Fp, alors p + 1 − 2 √ p 6 #E(Fp) 6 p + 1 + 2√ p . Lors de la sélection de la courbe, certaines précautions seront à prendre en plus sur le cardinal de la courbe. Si par exemple #E/K = p (la caractéristique du corps), alors on peut calculer un isomorphisme de la courbe vers (Fp, +) et calculer le DLP dans ce groupe trivialement [110,114]. De même, pour éviter l’attaque MOV [77], il faut vérifier que l’ordre l du point P (l’élément générateur du sous-groupe sur lequel on fait la multiplication scalaire) ne divise pas p k −1, pour k suffisamment grand (pour l > 2 160, il faut vérifier jusqu’à k = 20, voir page 173 de [57]). L’algorithme 4 présente la version courbes elliptiques du chiffrement Elgamal. On peut de même transposer le protocole de Diffie-Hellman, DSA ou tout autre algorithme basé sur le DLP. Dans la suite du document, lorsque sera évoqué la cryptographie sur courbes elliptiques ou ECC, il sera question des protocoles reposant sur l’ECDLP, utilisant la multiplication scalaire comme opération de base. Pour conclure, nous allons ici présenter certains éléments de comparaison entre ECC et RSA. Tout d’abord, la table 1.1 (issue de la page 19 de [57]) montre l’évolution prévue des tailles RSA/FFDLP et ECDLP, en se basant sur les temps requis pour les attaques NFS et rho de Pollard. L’écart déjà conséquent pour les niveaux de sécurité conseillés actuellement est amené à se creuser encore et de plus en plus vite (tant que de nouvelles attaques spécifiques aux courbes elliptiques ne seront pas trouvées).32 CHAPITRE 1. ÉTAT DE L’ART Algorithme 4: Chiffrement avec le cryptosystème Elgamal ECC simple (source [57]). Entrées : Alice diffuse (p, E/Fp, P, l) et sa clé publique Q, d est sa clef secrète Entrées : Bob veut chiffrer le message M pour Alice, un point de la courbe Chiffrement 1) Bob récupère la clé publique de Alice, c’est à dire Q et les paramètres (p, E/Fp, P, l) 2) Bob choisi k au hasard tel que 1 6 k 6 n − 1 3) Bob calcule les multiplications scalaires C1 = [k]P et C2 = M + [k]Q 4) Bob envoie (C1, C2) à Alice Déchiffrement 1) Alice calcule C3 = [d]C1 2) Alice obtient M = C2 − C3 Niveau de sécurité par algorithme symétrique (bits) SKIPJACK Triple-DES AES AES AES 80 112 128 192 256 Tailles des clés (bits) RSA 1024 2048 3072 8192 15360 FFDLP 160 224 256 384 512 ECDLP 160 224 256 384 512 Tailles des éléments (bits) RSA 1024 2048 3072 8192 15360 FFDLP 1024 2048 3072 8192 15360 ECDLP 160 224 256 384 512 Table 1.1 – Tailles de clés et de l’arithmétique pour les cryptosystèmes asymétriques RSA, FFDLP et ECDLP correspondant aux niveaux de sécurité des cryptosystèmes symétriques SKIPJACK, Triple-DES et AES (source [57]). Réf. Implémentation Slices DSP Fréq. Temps [56] Fp NIST 224 bits 1580 26 487 MHz 365 µs [118] RSA-1024 3937 17 400 MHz 1.71 ms Table 1.2 – Comparaison de performances ECC et RSA sur FPGA Virtex 4 XC4VFX12 issue de [56].1.1. LA CRYPTOGRAPHIE ASYMÉTRIQUE 33 Opération temps moyen mémoire données mémoire programme [k]P ECC-160 0.81 s 282 octets 3682 octets [k]P ECC-224 2.19 s 422 octets 4812 octets me mod n RSA-1024 0.43 s 542 octets 1073 octets c d mod n RSA-1024 10.99 s 930 octets 6292 octets me mod n RSA-2048 1.94 s 1332 octets 2854 octets c d mod n RSA-2048 83.26 s 1853 octets 7736 octets Table 1.3 – Comparaison en temps et en mémoire d’ECC et RSA-CRT sur ATmega128 issue de [55]. L’exposant public e est choisi e = 216 + 1. Implémentation Client Serveur ECC-160 bits 93.7 mJ 93.9 mJ RSA-1024 bits 397.7 mJ 390.3 mJ Table 1.4 – Consommation d’énergie issue de [123] pour une version simplifié de handshake SSL avec authentification mutuelle utilisant RSA ou ECC sur microcontrôleur basse consommation ATmega128. Les tables 1.2, 1.3 et 1.4 présentent des exemples de comparaison d’implantations matérielles et logicielles RSA et ECC. La table 1.2 issue de la contribution [56] compare ainsi RSA-1024 et ECC avec le premier du NIST P-224. On rappelle que d’après la table 1.1, ECC défini sur 224 bits fournit le même niveau de sécurité que RSA-2048. Les résultats présentés montrent une forte réduction du nombre de slices de Virtex 4 (qui sont les blocs de base du FPGA), contre une utilisation accrue du nombre de DSP blocs (qui sont des accélérateurs arithmétiques). De plus, en terme de vitesse l’implantation ECC est presque 5 fois plus rapide, pour un niveau de sécurité supérieur. La table 1.3 présente des résultats des auteurs de [55], qui ont comparé ECC et RSA sur des implantations sur microcontrôleur ATmega128. On remarque que pour un petit exposant public e = 216 + 1, l’exponentiation est plus rapide que la multiplication scalaire. Par contre, l’exponentiation utilisant l’exposant secret d est un ordre de grandeur fois plus lent que la multiplication scalaire. Les mêmes auteurs ont comparé dans [123] la consommation d’énergie d’un handshake SSL simplifié utilisant soit RSA-1024 soit ECC-160 toujours sur ATmega128. Ils ont observé une division par 4 de l’énergie consommée pour effectuer le handshake avec ECC-160, tout en gardant une sécurité équivalente. 1.1.4 Techniques classiques de multiplication scalaire et d’exponentiation Dans cette section sont présentés quelques algorithmes de multiplication scalaire. Ils sont présentés pour une loi de groupe notée additivement (notation pour ECC) mais la transformation en algorithme d’exponentiation est triviale (ainsi par exemple l’algorithme doublement et addition 5 peut se réécrire en carré et multiplication). Les algorithmes 5 et 6 sont deux variantes de l’algorithme dit doublement et addition (ou double-and-add en anglais), bits de poids faibles et bits de poids forts en tête, respectivement. Le principe est de parcourir le scalaire k bit à bit afin de calculer le schéma de Hörner correspondant. L’avantage de l’algorithme 5 provient du fait que ses lignes 3 et 4 sont parallélisables, alors que dans l’algorithme 6, ils travaillent sur la même donnée. Par contre l’algorithme 6 ne34 CHAPITRE 1. ÉTAT DE L’ART Algorithme 5: Multiplication scalaire doublement et addition poids faibles en tête (source [57], p. 96). Entrées : k = (k`−1, . . . , k1, k0)2, P ∈ E/Fp Sortie : [k]P 1 Q ←− O 2 pour i de 0 à ` − 1 faire 3 si ki = 1 alors Q ←− Q + P 4 P ←− [2]P 5 retourner Q travaillant que sur une seule valeur, il suffit de stocker un seul point durant le calcul. L’algorithme 7, issu de [125], permet d’accélérer les calculs en réduisant le nombre d’additions, au prix de pré-calculs. Le scalaire k est ici parcouru par fenêtre de w bits (par exemple w = 4). Un compromis est alors à faire entre la réduction du nombre d’additions de points et la quantité de points pré-calculés à stocker. En plus de la mémoire pour stocker ces points, le coût du calcul de ces points en début de multiplication scalaire doit être pris en compte si le point de base est régulièrement changé, par exemple pour protéger le circuit contre des attaques statistiques (cf. sous-section 1.1.6). Il existe beaucoup d’autres algorithmes d’exponentiation et de multiplication scalaire (un exemple de plus est donné au chapitre 3). Ces algorithmes proposent par exemple de recoder k dans une certaine repré- sentation pour réduire encore le nombre d’additions de points. Des exemples seront donnés dans la section 1.1.5. Pour plus de détails, le lecteur trouvera par exemple une étude des algorithmes d’exponentiation et de multiplication scalaire rapide dans l’article [51]. En- fin, d’autres algorithmes sont aussi utilisés pour protéger le circuit contre les attaques par canaux cachés, par exemple la multiplication scalaire dite échelle de Montgomery [62] (algorithme 22, chapitre 3). Algorithme 6: Multiplication scalaire doublement et addition poids forts en tête (source [57], p. 97). Entrées : k = (k`−1, . . . , k1, k0)2, P ∈ E/Fp Sortie : [k]P 1 Q ←− O 2 pour i de ` − 1 à 0 faire 3 Q ←− [2]Q 4 si ki = 1 alors Q ←− Q + P 5 retourner Q 1.1.5 Réduction du coût de la multiplication scalaire La figure 1.4 propose une vue sur la hiérarchie des opérations d’une multiplication scalaire. On considère généralement deux sous-niveaux : les opérations sur les points ADD et DBL et les opérations ±, ×, −1 sur le corps de base Fp (la plupart des études de l’état de l’art se consacre surtout à la réduction du nombre de multiplications). Afin d’améliorer l’efficacité de la cryptographie sur courbes elliptiques, de nombreuses approches ont été proposées dans la littérature, aux différents niveaux de la figure 1.4. Des améliorations ont aussi été proposées sur la réduction de l’arithmétique des courbes, c’est à dire la réduction1.1. LA CRYPTOGRAPHIE ASYMÉTRIQUE 35 Algorithme 7: Multiplication scalaire par fenêtre fixe de Yao [125]. Entrées : k = (km−1, . . . , k1, k0)2w avec ki ∈ [0, 2 w − 1], m =  ` w  et P ∈ E/Fp Pré-calculs : T = (O, P, [2]P, . . . , [2w − 1]P) Sortie : [k]P 1 début 2 Q ←− T(km−1) 3 pour i de m − 2 à 0 faire 4 pour j de 1 à w faire 5 Q ←− [2]Q 6 Q ←− Q + T(ki) 7 retourner Q temps [k]Q DBL ADD DBL . . . ±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1 FP E/FP Figure 1.4 – Hiérarchie des opérations dans une multiplication scalaire. du coût des opérations de base telles que l’addition et le doublement de point, ou la proposition de formules pour des opérations plus complexes pour le triplement, par exemple [39], ou le quintuplement avec par exemple [81]. Une façon d’améliorer les formules est de changer de système de coordonnées. En effet, les inversions modulaires étant très coûteuses vis à vis des autres opérations modulaires, l’utilisation de systèmes de coordonnées différents des coordonnées affines a été proposée dans la littérature [28, 32]. Ces systèmes rajoutent un certain nombre de coordonnées, notamment pour éviter de faire une inversion à chaque opération ADD ou DBL. Par exemple, dans [32] est évoqué un coût d’environ 30 multiplications pour une inversion, ou même 100 multiplications pour les auteurs de [17]. Le retour à une représentation normalisée affine demande une inversion, mais c’est la seule requise sur toute la multiplication scalaire. Par exemple, les coordonnées projectives Jacobiennes font correspondre le point (x, y) = (X/Z2 , Y /Z3 ) à (X, Y, Z) avec Z 6= 0 pour (x, y) 6= O (si Z = 0 alors (x, y) = O). L’équation 1.2 devient ainsi Y 2 = X3 + aXZ4 + bZ6 . Par exemple, les formules de la table 1.5, issues de [17] permettent de calculer l’addition et le doublement de point sans inversion. Le site web [17] recense un grand nombre de systèmes de coordonnées, et évalue leur coût en terme d’opérations élémentaires sur le corps en décomptant les opérations nécessaires aux additions, doublements, mais aussi triplements ou encore λ-doublements (formules spé- ciales lorsqu’on enchaîne les doublements). Une autre façon d’améliorer l’arithmétique de certaines courbes est de les choisir avec une forme particulière permettant des simplifications dans les calculs, autrement dit de changer l’équation de définition d’une courbe pour obtenir de nouvelles formules d’addition et doublement. Par exemple les courbes d’Edwards [43], définies par x 2 +y 2 = c 2 (1 +dx2y 2 ) avec cd(1−c 4d) 6= 0 mènent à des formules36 CHAPITRE 1. ÉTAT DE L’ART P1 + P2 2 P1 A1 = Z 2 1 A = X2 1 A2 = Z 2 2 B = Y 2 1 u1 = X1A2 C = B2 u2 = X2A1 D = Z 2 1 S1 = Y1Z2A2 S = 2 (X1 + B) 2 − A − C
S2 = Y2Z1A1 M = 3A + aD2 H = u2 − u1 T = M2 − 2S I = (2H) 2 X3 = T J = HI Y3 = M(S − T) − 8C R = 2(S2 − S1) Z3 = (Y1 + Z1) 2 − B − D V = u1I X3 = R2 − J − 2V Y3 = R(V − X3) − 2S1J Z3 = (Z1 + Z2) 2 − A1 − A2
H Table 1.5 – Formules pour courbe elliptique sous forme de Weierstrass courte en coordonnées Jacobiennes (source [17]). Note : P1 = (X1, Y1, Z1), P2 = (X2, Y2, Z2) et P3 = (X3, Y3, Z3). nécessitant peu d’opérations [16, 17]. On peut aussi accélérer les calculs au niveau de l’algorithme de multiplication scalaire lui même (voir des exemples en section 1.1.4). Des techniques de recodage de la clé ont par exemple été proposées afin de limiter le nombre d’additions de points (souvent plus coûteuses que les doublements). On peut citer par exemple le recodage en forme non adjacente [83] (NAF pournon-adjacent form) qui recode la clé avec un nombre limité de 1 (correspondants aux additions) dans la nouvelle représentation. Un autre exemple de recodage est la représentation à base double [39] (DBNS pour double-base number system), qui propose de réécrire la clé dans une base double 2 et 3. Ce dernier recodage suppose des formules de triplement de points, qui sont des formules plus efficaces que celles d’un doublement et d’une addition combinées. Pour finir, les travaux sur l’amélioration de l’arithmétique dans les grands nombres trouvent une application directe dans la cryptographie asymétrique. On notera par exemple les travaux d’implantations de [121] qui testent différentes façons d’implanter l’arithmétique ECC sur GPU, ou encore les travaux [5, 45, 52] qui utilisent la représentation RNS pour accélérer les calculs ECC. Les travaux de cette thèse se placent donc au plus bas niveau, dans l’implantation de l’arithmétique du corps de base. On verra, notamment dans le chapitre 3, que les différents niveaux de la hiérarchie d’une multiplication scalaire (algorithme de multiplication scalaire, opération sur les points et opérations sur le corps) ne peuvent pas être complètement dissociés afin d’être le plus efficace possible, chaque modification sur l’un des niveaux ayant un impact sur les autres.1.1. LA CRYPTOGRAPHIE ASYMÉTRIQUE 37 1.1.6 Sécurité et attaques physiques Quelques types d’attaques Les attaques par canaux cachés sont un type d’attaques important, notamment dans un contexte d’implantation matérielle. En effet, ces attaques sont extrêmement dangereuses car elles ne reposent pas sur la qualité du cryptosystème en terme de sécurité purement mathématique, mais sur son implantation. Une implantation matérielle peut être observée ou bien agressée, fautée et ainsi révéler des secrets à l’attaquant, tout en semblant parfaitement sûre mathématiquement. Une implantation cryptographique doit donc être aussi résistante aux deux types d’attaques. On peut globalement classer en 2 catégories les attaques physiques. D’une part les attaques par observation (ou attaques passives), qui demandent de pouvoir disposer d’un canal de mesure fuitant de l’information, classiquement la consommation de courant [33,69], le rayonnement électromagnétique [4, 100] ou bien le temps d’exécution [68]. D’autre part les attaques par perturbation (ou attaques actives), où l’attaquant va, par exemple, essayer d’introduire des fautes dans le circuit en modifiant un ensemble de bits à l’aide d’un laser. L’exemple probablement le plus simple d’attaque par observation est l’analyse simple de courant (SPA pour simple power analysis), proposée par Kocher et al. [69]. Comme présenté dans la section 1.1.4, certains algorithmes d’exponentiation ou de multiplication scalaire effectuent des calculs complètement différents suivant les bits de la clé secrète. Par exemple, l’algorithme 5 effectue dans un cas un simple doublement, et dans l’autre une addition et un doublement. Les additions étant des opérations bien différentes des doublements dans le cas standard (sans contre-mesure spécifique avec des formules unifiées comme dans [23, 61]), les différences de consommation entre les 2 opérations sont très facilement perceptibles. Toujours dans [69] sont proposées des attaques plus sophistiquées, qui à la suite d’un certain nombre de mesures appliquent un traitement statistique afin de retrouver une partie de la clé. On appelle ces attaques DPA, pour Differential Power Analysis attacks. Un exemple connu d’attaque active a été proposé par Boneh et al. dans [21]. La proposition est une attaque contre les implantations dites RSA-CRT, où le théorème chinois des restes (détaillé en 1.2.1) est appliqué directement sur la factorisation du module RSA. En injectant une faute dans le calcul effectué sur l’un des facteurs premiers du modulus, on peut retrouver directement la factorisation de celui-ci, et donc casser le système. Une autre exemple est l’attaque safe error, présentée dans [128,129], qui permet d’attaquer certaines implantations d’exponentiation ou de multiplication scalaire. Ces attaques révèlent des informations sur les branchements pris suivant les bits de clé. Cela permet notamment de différencier ces différents branchements, lorsqu’une analyse de courant simple SPA ne suffit pas. Le modèle d’attaquant est par contre ici plus fort que celui d’une SPA car il requiert de pouvoir attaquer avec une très bonne précision le circuit sans le détruire, comme par exemple attaquer un registre contenant une coordonnée d’un point à un moment précis. Des exemples de contre-mesure Pour lutter contre les attaques de type SPA, on va généralement chercher à briser le lien entre la consommation de courant et le côté du branchement choisi dans les algorithmes d’exponentiation et de multiplication scalaire. Il existe notamment plusieurs façons d’uniformiser les calculs effectués si le bit de clé ki vaut 1 ou 0.38 CHAPITRE 1. ÉTAT DE L’ART La contre-mesure présentée par Joye et Yen dans [62], appelée échelle de Montgomery permet d’effectuer une multiplication scalaire en effectuant pour chaque bit de k exactement une addition de points et un doublement. En utilisant cet algorithme (présenté plus en détail dans la section 3.2), on s’attend à ce que la consommation de courant varie très peu suivant que le bit ki soit à 1 ou 0. De même, la contre-mesure de Möller [86] propose une adaptation de l’algorithme de multiplication par fenêtre de Yao [125] qui effectue toujours w doublements puis une addition, quelque soit la valeur de la fenêtre (ki+m−1, . . . , ki). Cette contre-mesure nécessite donc le pré-calcul de constantes comme pour l’algorithme [125] et requiert en plus un recodage de la clé pour être sûr de ne pas effectuer des opérations irrégulières, comme une addition entre P et l’élément neutre O. Une autre contre-mesure visant à uniformiser les calculs est par exemple proposé par Brier et Joye dans [23]. Cette contre-mesure propose l’utilisation de formules unifiées pour l’addition et le doublement de point. Autrement dit, on effectue exactement de la même façon l’addition de points et le doublement de point, la consommation ne dépend alors plus des opérations effectuées. On remarque que contrairement aux deux premières contremesures [62, 86] qui proposent une protection au niveau algorithme de multiplication scalaire ou d’exponentiation, celle-ci propose une protection directement au niveau des formules pour ADD et DBL. Pour se protéger contre les attaques statistiques, on peut aussi citer les contre-mesures de Coron [33] qui sont des contre-mesures classiques pour les implantations ECC. Pour protéger le circuit d’une analyse statistique, l’idée est d’introduire de l’aléa à chaque exé- cution. Dans [33] est proposé par exemple de rendre aléatoire les coordonnées du point de base P en coordonnées projectives ou encore d’ajouter des bits d’aléa à la clé sans changer le résultat final. Une autre façon de se protéger contre les attaques statistiques, mais aussi des attaques de type SPA, est d’utiliser du matériel pour ne plus avoir de lien entre le canal observé et les données ou les calculs effectués. Par exemple, la logique WDDL pour wave dynamic differential logic est utilisée par Tiri et Verbauwhede [122] ou encore McEvoy et al. [76] pour protéger le système. Dans une implantation WDDL, tout signal s est implanté de paire avec son complémentaire s. Ainsi, un changement sur s implique un changement sur s, ce qui rend plus difficile l’analyse de la consommation de courant et le lien qui peut être fait avec les calculs effectués. Nous remarquons que cette contre-mesure est proposée au plus bas niveau en terme d’implantation, elle peut donc être implantée en complément d’autres contre-mesures. Enfin, pour se protéger contre certaines attaques en faute, Giraud [50] propose de tester le résultat de certains algorithmes de multiplication scalaire ou d’exponentiation avant de retourner un résultat qui donnerait potentiellement des informations à un attaquant. Ce type de contre-mesure doit être utilisé avec un algorithme adapté, comme l’échelle de Montgomery. En effet, certains types d’algorithmes protégés contre la SPA peuvent retourner un résultat juste, malgré qu’une faute ait été commise. Dans ce cas, le test final ne protège plus de la fuite d’information. Pour conclure sur cette section, ma thèse se plaçant dans un contexte d’implantations matérielles de cryptographie, il est important d’évoquer les attaques par canaux cachés.1.2. ARITHMÉTIQUE MODULAIRE 39 Les propositions que nous avons faites dans la thèse portent sur l’accélération des calculs du corps de base, elles sont pour la plupart compatibles avec les contre-mesures qui sont faites aux autres niveaux de la figure 1.4, que ce soit sur l’arithmétique de la courbe ou bien l’algorithme de multiplication scalaire. Par exemple, elles sont compatibles avec les contre-mesures classiques de Coron [33] contre la DPA ou celles de Joye et Yen [62] ou Möller [86] contre la SPA. 1.2 Arithmétique modulaire Dans cette section, nous allons présenter quelques rappels de base du calcul modulaire, ainsi que des techniques classiques utilisées dans le cadre de la représentation binaire standard de position. Comme nous le verrons dans la suite du document, ces techniques sont souvent à l’origine des techniques utilisées dans le cadre du RNS. Le calcul modulaire spécifique au RNS sera présenté dans la section 1.3, qui lui est consacrée. 1.2.1 Définitions et rappels sur l’arithmétique modulaire Sans définir dans l’absolu ce qu’est l’arithmétique modulaire, on peut la voir comme un type d’arithmétique ne s’intéressant pas directement aux valeurs de nombres sur lesquels on travaille, mais plutôt aux restes de leur division par un autre nombre. Le reste de a divisé par b sera écrit a mod b. L’arithmétique modulaire existe depuis l’antiquité, mais on attribue en général son développement en la version que nous connaissons aujourd’hui à Gauss pour son ouvrage Disquisitiones Arithmeticae de 1801. On rappelle maintenant quelques outils nécessaires au calcul modulaire. Définition 3 (congruences). Soient a, b, n ∈ N avec n > 0, alors a ≡ b mod n si et seulement si le reste de a divisé par n est égal au reste de b divisé par n. Ils sont alors représentés par la même classe de congruence modulo n. Si a ≡ b mod n et c ≡ d mod n alors : – a + c ≡ b + d mod n ; – a · c ≡ b · d mod n ; – a q ≡ b q mod n . On choisit généralement le représentant de la classe de congruence comme un élément supérieur ou égal à 0 et inférieur strictement à n (il existe d’autres façons de choisir, par exemple en ayant des représentants négatifs). On rappelle que l’inverse de a modulo n, noté a −1 , est, lorsqu’il existe, l’unique élément b ∈ [0, n − 1] tel que ab ≡ 1 mod n. Un tel élément existe si et seulement si a et n sont premiers entre eux. Enfin, on rappelle que si m divise n, alors a mod m = (a mod n) mod m. Nous présentons maintenant le théorème chinois des restes (qui sera souvent abrégé en CRT). Ce théorème est à la base de la représentation RNS et donc de la grande majorité des travaux de cette thèse. Ce théorème est très ancien (un premier sous-cas a été énoncé par Sun Tsˇu au IIIe siècle environ, d’après Knuth [66], page 287). L’exemple de Sun Tsˇu peut se traduire comme suit (voir [92]) : Soient des objets dont nous ne connaissons pas le nombre. Si nous les comptons par 3, il en reste 2. Si nous les comptons par 5, il en reste 3. Si nous les comptons par 7, il en reste 2. Combien y a-t-il d’objets ?40 CHAPITRE 1. ÉTAT DE L’ART La réponse à ce problème est 23. Cette solution est unique si on considère que le nombre d’objets est inférieur à 105 (3 × 5 × 7). Nous allons voir comment ce genre de problème se résout dans le cas général, avec l’énoncé du théorème. Théorème 2 (théorème chinois des restes CRT). Soient {m1, . . . , mn} un ensemble d’entiers premiers entre eux deux à deux et M = Qn i=1 mi. Soit (x1, . . . , xn) ∈ N n alors il existe un unique x ∈ [0, M − 1] tel que    x ≡ x1 mod m1 x ≡ x2 mod m2 . . . x ≡ xn mod mn . (1.3) Cet élément est défini par x =      Xn i=1  xi · T −1 i   mi · Ti      M (1.4) où Ti = M mi où | · |M représente la réduction modulo M. Démonstration. Nous allons d’abord prouver que l’équation 1.4 fourni bien une solution du système 1.3. Les éléments de {m1, . . . , mn} étant premiers entre eux 2 à 2, Ti = M mi est donc premier avec mi , son inverse |T −1 i |mi existe bien. De plus, on remarque que si i 6= j, alors Tj est un multiple de mi , c’est à dire |Tj |mi = 0. Pour résumer,        xi · T −1 i   mi · Ti    mi = xi     xi · T −1 i   mi · Ti    mj = 0 pour i 6= j . (1.5) On obtient bien |x|mi = xi pour chaque i ∈ [1, n]. Il ne reste plus qu’à prouver l’unicité de la solution. Soient x, y ∈ [0, M−1], deux solutions du système 1.3. Alors on a |x−y|mi = 0 pour tout i ∈ [1, n]. L’entier x − y est donc multiple de tous les mi , c’est à dire multiple de leur produit M. Or, puisque x − y ∈ [−M + 1, M − 1], le seul multiple de M possible est 0, on en conclut que x − y = 0. Ce théorème sera commenté plus en détail dans la section 1.3 consacrée au RNS. 1.2.2 Réduction Modulaire L’opération caractéristique de l’arithmétique modulaire est le calcul, à partir d’un entier, de sa représentation modulo un certain nombre n, c’est à dire de son reste divisé par n. Cette opération, appelée réduction modulaire, peut s’effectuer à l’aide d’une division Euclidienne par exemple, qui retourne quotient et reste. Nous allons voir maintenant quelques techniques utilisées habituellement pour effectuer le calcul du reste sans avoir à calculer le quotient, qui sont efficaces en numération simple de position (les algorithmes sont présentés pour la base 2).1.2. ARITHMÉTIQUE MODULAIRE 41 Réduction de Barrett La réduction de Barrett [15] est une méthode qui va chercher à approcher le quotient de la division de a par p pour obtenir a mod p. En effet, on rappelle que a mod p = a− j a p k p. La méthode de Barrett propose d’approcher j a p k par  a 2 l  µ 2 l  , où µ = j 2 2l p k et l le nombre de bits de p. En faisant une approximation de j a p k , nous sommes sûrs d’obtenir le bon résultat modulo p, à un certain nombre de soustractions par p près (dépendant directement de la précision de l’approximation). Dans la méthode proposée, il suffit de pré-calculer µ, les autres divisions étant en fait juste des décalages. Au final, la réduction calcule : a − jj a 2 l k µ 2 l k p . (1.6) L’algorithme coûte donc une multiplication de l × (l/2) bits ( µ 2 l  ne fait que l/2 bits) et une multiplication de l bits, en plus de la soustraction de l’équation 1.6 et de celles nécessaires à corriger le résultat. En utilisant la méthode de Barrett, on obtient un résultat inférieur à 3p (voir [15]), on effectue alors finalement une à deux soustractions par p en plus pour obtenir le résultat final. Réduction de Montgomery La réduction de Montgomery, initialement proposée en 1985 dans [82], est une méthode de réduction permettant d’éviter l’utilisation de divisions coûteuses, les remplaçant par des opérations très efficaces comme des décalages. Pour pouvoir utiliser ces décalages, la contrainte est d’autoriser la sortie à être un peu supérieure à p pour une réduction modulo p (généralement la sortie est inférieure à 2p, ce qui implique un bit supplémentaire pour représenter les valeurs). L’algorithme 8 décrit la méthode de Montgomery. Algorithme 8: Réduction modulaire de Montgomery [82]. Entrées : a < p2 , p < R avec pgcd(R, p) = 1 Pré-calcul : (−p −1 ) mod R Sortie : ω ≡ a · R−1 mod p , ω < 2p 1 s ←− a · (−p −1 ) mod R 2 t ←− a + sp 3 ω ←− t/R Cet algorithme prend en entrée un entier a < p2 , typiquement le résultat d’un produit de deux éléments inférieurs à p. Pour que cet algorithme soit efficace, il faut que les réductions modulo R et divisions par R soient efficaces. En représentation binaire classique, on prend généralement R = 2l , ainsi une réduction équivaut juste à garder les r derniers bits et les divisions sont de simples décalages. De plus, il est aisé de constater que t défini ligne 2 est un multiple de R en écrivant : t ≡ a + sP ≡ a + a · (−p −1 ) · p ≡ 0 mod R , de même que de retrouver la borne sur le résultat ω : ω = t R = a + sp R < p · p + s R < 2p .42 CHAPITRE 1. ÉTAT DE L’ART On peut remarquer que la sortie de l’algorithme n’est pas a mod p mais a · R−1 mod p, représentation qu’on appelle parfois domaine de Montgomery. Pour retrouver a mod p, il suffit de multiplier le résultat de l’algorithme par R2 mod p et réappliquer l’algorithme 8 une fois. Le coût de cette opération peut être négligée, car celle-ci n’intervient qu’une fois tous nos calculs modulaires effectués. De plus, on peut observer que le produit de deux sorties ω1 et ω2 de l’algorithme 8 donne un élément ω1 · ω2 < 4p 2 au lieu de p 2 . Pour pouvoir maîtriser la taille des entrées et sorties de l’algorithme lorsque les réductions modulaires s’enchaînent, on choisit un élément R > 2M, ce qui va permettre de retourner toujours un résultat ω < 2p, même avec une entrée entre p 2 et 4p 2 . Remarque. La réduction de Montgomery peut être vue comme une première application du théorème chinois des restes. En effet, puisque p et R sont premiers entre eux, si a < p2 < pR alors d’après le CRT (avec m1 = p et m2 = R) on a : a = |ap−1 |R · p + |aR−1 |p · R mod pR , et donc (a − |ap−1 |R · p)/R ≡ |aR−1 |p mod pR , ce qui nous donne la formule calculée par l’algorithme 8. Le cas des nombres de Mersenne et pseudo-Mersenne Les deux algorithmes précédents ne demandent aucune condition sur le modulus p. Dans certains cas, la réduction peut être grandement simplifiée, comme pour les nombres de Mersenne qui s’écrivent de la forme 2 `−1. Par exemple, le standard ECC du NIST [91] propose d’utiliser le corps FP521 où P521 = 2521 −1. Ainsi pour réduire x = x12 521 +x0 (x0, x1 < 2 ` ) un nombre de 1042 bits, modulo P521, il suffit de calculer x ≡ x1 + x0 mod P521. On note que x1 + x0 est un nombre de 522 bits, une soustraction peut être nécessaire pour obtenir le résultat final de la réduction. De même, on réduit en général un nombre de 2` bits en un nombre de ` bits. La même idée peut être généralisée en utilisant ce qu’on appelle les nombres pseudoMersenne, de la forme 2 ` − r, où 0 < r < √ `. L’idée de l’utilisation de tels premiers pour ECC a été introduite par Crandall [34]. Si x = x12 ` + x0 (toujours x0, x1 < 2 ` ) est un nombre de 2` bits, et p = 2` − r on a maintenant x ≡ x1r + x0 mod p. Si on pose s = x1r+x0, alors on peut remarquer que log2 s = 3`/2+ 1 (en effet x1r est de taille 3`/2). En appliquant cette méthode une nouvelle fois, sur s, on obtient à nouveau un nombre de ` + 1 bits auquel on soustrait une ou 2 fois P pour obtenir le bon résultat. L’algorithme 9 résume cette méthode. Algorithme 9: Réduction modulo un nombre pseudo-Mersenne [34]. Entrées : p = 2` − r, r < √p, x = x12 ` + x0 < p2 , x0, x1 < 2 ` Sortie : ω ≡ x mod p, ω < 2p 1 s ←− x1r + x0 /*s = s12 ` + s0*/ 2 t ←− s1r + s0 3 ω ←− |t|p Afin de réduire le coût des multiplications par r dans l’algorithme 9, Solinas [116] remarque que r peut être construit lui aussi de façon particulière, par exemple avec quelques1.2. ARITHMÉTIQUE MODULAIRE 43 puissances de 2. Ainsi, dans le standard du NIST est défini P192 = 2192 − 2 64 − 1, ce qui permet de remplacer les calculs de s et t par 3 additions. 1.2.3 Inversion Modulaire Dans cette section sont détaillées les techniques classiques pour effectuer l’inversion modulaire, c’est à dire étant donnés p et a, comment calculer l’élément b tel que ab ≡ 1 mod p. Cette opération est par exemple requise pour ECC, mais on en réduit le nombre au minimum car elle est très coûteuse vis à vis des autres opérations comme la multiplication. Il existe deux grandes familles d’algorithmes pour effectuer cette opération et qui sont présentées ci-dessous. Inversion avec le petit théorème de Fermat Le théorème porte le nom de Pierre de Fermat, qui semble-t-il a été le premier à énoncer le théorème qui suit dans une lettre à Frénicle de Bessy (voir [35], page 209) datant du 18 octobre 1640. Le théorème y est énoncé de la façon suivante : « Tout nombre premier mesure infailliblement une des puissances −1 de quelque progression que ce soit, et l’exposant de la dite puissance est sous-multiple du nombre premier donné −1 ». Ce qui peut se traduire par le théorème 3. Théorème 3 (Petit Théorème de Fermat ou FLT pour Fermat Little Theorem). Soit p un nombre premier et a un nombre qui n’est pas multiple de p. Alors a p−1 − 1 ≡ 0 mod p. De ce théorème découle directement le fait que si 0 < a < p alors a × a p−2 ≡ 1 mod p, et donc a p−2 ≡ a −1 mod p. Ainsi, le calcul de l’inverse modulaire peut se résumer à un grande exponentiation modulaire, implantée par exemple à l’aide de l’un des algorithmes présentés dans la section 1.1.4. Le nombre de tours de la boucle principale est donc en log p. Pour obtenir le coût total, il suffit de multiplier ce nombre par le coût des multiplications internes à la boucle. Les avantages de l’algorithme issu du petit théorème de Fermat (noté FLT) viennent de sa nature d’exponentiation. Ces algorithmes sont très réguliers, et ils demandent principalement de savoir faire des multiplications modulaires et de savoir compter le nombre (fixe) de tours de boucle. Dans un contexte de cryptographie matérielle pour les courbes elliptiques par exemple, les multiplieurs sont déjà implantés pour calculer les opérations nécessaires au doublement de point par exemple. De plus, le contrôle est très simple puisqu’il s’agit juste d’un compteur. Algorithmes d’Euclide étendus L’algorithme d’Euclide est à l’origine une méthode permettant de trouver le « plus grand diviseur commun » (pgcd) de deux entiers, proposé par Euclide dans son œuvre Les Éléments (livre 7, propositions 1 et 2, voir par exemple l’édition [46]). Cet algorithme permet notamment, dans une version étendue, de trouver les éléments u et v tels que ua + vb = pgcd(a, b) (identité de Bézout). Supposons que l’algorithme soit calculé pour 0 < a < p et p premier, on obtient alors ua+vp = 1. Ce qui est équivalent à ua ≡ 1 mod p, on a donc bien calculé l’inverse de a modulo p. La méthode est détaillée dans l’algorithme 10 (issu de [66]). L’idée principale de l’algorithme est d’utiliser l’égalité suivante : pgcd(a, p) = pgcd(p mod a, a) .44 CHAPITRE 1. ÉTAT DE L’ART Algorithme 10: Algorithme d’Euclide étendu (source [66]). Entrées : a, p ∈ N avec pgcd(a, p) = 1 Sortie : U = a −1 mod p 1 (u1, u2, u3) ←− (0, 1, p) 2 (v1, v2, v3) ←− (1, 0, a) 3 tant que v3 6= 0 faire 4 q ←− j u3 v3 k 5 (u1, u2, u3) ←− (u1, u2, u3) − q(v1, v2, v3) 6 (u1, u2, u3) ←→ (v1, v2, v3) 7 si u1 < 0 alors 8 u1 ←− u1 + p 9 retourner u1 Ainsi en prenant successivement l’opérande le plus grand, modulo le plus petit, on réduit leur taille à chaque tour de boucle, pour finalement arriver au pgcd final (qui vaut 1 dans notre cas). Les opérandes sont d’abord stockés dans les variables u1, u2, u3, v1, v2 et v3. Ces variables sont telles que u1 · a + u2 · p = u3 et v1 · a + v2 · p = v3 à la fin de chaque tour de boucle. À la fin de l’algorithme, u3 vaut 1, le résultat est donc bien u1. On peut remarquer qu’il n’est pas nécessaire de calculer u2 et v2, seuls u1 et v1 contiendront les valeurs pour arriver à l’inverse, u3 et v3 étant requis pour savoir quand arrêter l’algorithme. En moyenne, le nombre de tours de la boucle principale est environ 12 log 2 π2 ln p ≈ 0.58 log2 p, voir par exemple [41,59] si on considère en entrée p et a un élément de Fp. Cela est presque deux fois moins que pour l’algorithme de Fermat, mais il faut en contrepartie être capable de faire des divisions euclidiennes sur des grands nombres de façon efficace. Une variante célèbre de l’algorithme d’Euclide est sa version dite « binaire », proposée initialement par Stein dans [117]. Cette variante va permettre de s’affranchir du coût des divisions Euclidiennes, pour les remplacer par des divisions par 2 et des tests modulo 2. Ces deux opérations étant triviales en représentation binaire, cet algorithme va permettre une grosse réduction du coût d’une itération de la boucle principale. En contrepartie, plus de tours de boucle principale sont effectués, environ 0.71 log2 p. La version étendue est décrite dans l’algorithme 11 (issu de [66]§ 4.5.2). Tout au long de cet algorithme, on retrouve l’égalité u1 ·a ≡ u3 mod p, et la même chose pour les vi . La différence vient de la façon dont on fait évoluer ces valeurs intermédiaires. La propriété utilisée pour réduire les opérandes tout en gardant le même pgcd n’est plus pgcd(a, p) = pgcd(p mod a, a), mais on utilise le fait que    pgcd(u3, v3) = pgcd(u3/2, v3) si u3 pair et v3 impair pgcd(u3, v3) = 2 · pgcd(u3/2, v3/2) si u3 et v3 pairs pgcd(u3, v3) = pgcd((u3 − v3)/2, v3) si u3 et v3 impairs. (1.7) Ainsi, dans la boucle principale on commence par diviser les deux opérandes par 2 tant qu’ils sont pairs. Lorsqu’on divise par 2 la valeur v3 par exemple, il faut mettre à jour la valeur associée v1 pour conserver (v1/2) · a ≡ (v3/2) mod p, quitte à rajouter p à v1 si sa valeur est impaire. Après les deux boucles internes de parité, u3 et v3 sont impairs (on est dans le troisième cas de l’équation 1.7) : on fait donc la différence du plus grand et du plus1.2. ARITHMÉTIQUE MODULAIRE 45 Algorithme 11: Algorithme d’Euclide étendu binaire de [66]§ 4.5.2. Entrées : a, p ∈ N, p > 2 avec pgcd(a, p) = 1 Sortie : |a −1 |p 1 (u1, u3) ← (0, p), (v1, v3) ← (1, a) 2 tant que v3 6= 1 et u3 6= 1 faire 3 tant que |v3|2 = 0 faire 4 v3 ← v3 2 5 si |v1|2 = 0 alors 6 v1 ← v1 2 7 sinon 8 v1 ← v1+p 2 9 tant que |u3|2 = 0 faire 10 u3 ← u3 2 11 si |u1|2 = 0 alors 12 u1 ← u1 2 13 sinon 14 u1 ← u1+p 2 15 si v3 ≥ u3 alors 16 v3 ← v3 − u3 17 v1 ← v1 − u1 18 sinon 19 u3 ← u3 − v3 20 u1 ← u1 − v1 21 si v3 = 1 alors retourner |v1|p sinon retourner |u1|p petit, puis on applique à nouveau la règle 1.7. Pour finir est présentée ici une variante de l’algorithme binaire d’Euclide étendu, utilisant une astuce appelée plus-minus. Les auteurs de [22] ont proposé de remplacer la comparaison v3 > u3 par un test modulo 4 dans l’algorithme binaire du calcul du pgcd. Cette astuce est très intéressante pour les représentations dans lesquelles les comparaisons sont difficiles (comme RNS). Il faut surtout être capable de faire de façon efficace des réductions modulo 4. L’algorithme 12, proposé dans [37], est une version étendue de l’algorithme de calcul de pgcd de [22]. L’astuce est de remarquer que si deux entiers sont impairs, alors leur somme ou (exclusif) leur différence est un multiple de 4. Ainsi, au lieu d’effectuer une comparaison entre les valeurs u3 et v3 comme dans l’algorithme 11, on teste la valeur modulo 4 de leur somme. Si on obtient 0, on effectue ensuite une division par 4 de cette somme, sinon on divise par 4 la différence. Des petites comparaisons sont effectuées sur les valeurs de contrôle lu et lv, mais ces valeurs là sont très petites devant la taille des opérandes (elles sont de taille log2 log2 p). Dans l’algorithme 12, des fonctions div2 et div4 sont définies. La fonction div2 effectue en fait les lignes 5,6,7 et 8 de l’algorithme 11, c’est à dire elle divise par 2 modulo p son entrée. De même div4 divise par 4 modulo p, sa définition complète dépend de la valeur |p|4. Par exemple, si |p|4 = 3, alors    v1/4 si |v1|4 = 0 (v1 + p)/4 si |v1|4 = 1 (v1 + 2p)/4 si |v1|4 = 2 (v1 − p)/4 si |v1|4 = 3 ,46 CHAPITRE 1. ÉTAT DE L’ART ce qui correspond bien à la division par 4 modulo p. Autrement dit, on construit un multiple de 4, en ajoutant un certain nombre de fois p, qui est finalement divisé par 4. Algorithme 12: Inversion modulaire plus-minus [37]. Entrées : a, p ∈ N avec pgcd(a, p) = 1, ` = dlog2 pe Sortie : |a −1 |p 1 (u1, u3) ← (0, p), lu ← ` 2 (v1, v3) ← (1, a), lv ← ` 3 tant que lv > 0 faire 4 si |v3|4 = 0 alors 5 v3 ← v3/4 6 v1 ← div4(v1, p) 7 lv ← lv − 2 8 sinon si |v3|2 = 0 alors 9 v3 ← v3/2 10 v1 ← div2(v1, p) 11 lv ← lv − 1 12 sinon 13 v ∗ 3 ← v3, v ∗ 1 ← v1, l ∗ u ← lu, l ∗ v ← lv 14 si |u3 + v3|4 = 0 alors 15 v3 ← (v3 + u3)/4 16 v1 ← div4(v1 + u1, p) 17 sinon 18 v3 ← (v3 − u3)/4 19 v1 ← div4(v1 − u1, p) 20 si lv < lu alors 21 u3 ← v ∗ 3 , u1 ← v ∗ 1 , lu ← l ∗ v , lv ← l ∗ u − 1 22 sinon v ← v − 1 23 si u1 < 0 alors u1 ← u1 + p 24 si u3 = 1 alors retourner u1 sinon retourner p − u1 Les auteurs de [36] fournissent des résultats d’implantation FPGA Spartan 3 des diffé- rents algorithmes d’inversion présentés dans cette section (voir pages 113-116 de [36]). Pour leurs implantations, les algorithmes les plus efficaces sont clairement l’algorithme d’Euclide étendu binaire ainsi que sa variante plus-minus. Les deux implantations sont très proches en termes de temps, et la surface de la version plus-minus se révèle un peu plus petite. L’algorithme classique d’Euclide étendu et celui issu du FLT sont tous deux loin derrière (l’algorithme du FLT restant le plus lent). 1.3 La représentation modulaire des nombres (RNS) La représentation modulaire des nombres, ou RNS (residue number system) a été introduite indépendamment par Svodoba et Valach [119] d’un côté et Garner [49] dans les années 50. Proposée initialement pour des problèmes de vérification des calculs, elle a ensuite été utilisée pour des problèmes de traitement du signal [26, 60] puis plus récemment pour différentes implantations de cryptographie asymétrique. Par exemple des travaux sur l’implantation de RSA et FFDLP [10,71,87] (1024–4096 bits), d’autres sur ECC [52,72,104]1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 47 temps [k]Q DBL ADD DBL . . . ±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1±, ×, −1 ma,1 ma,2 ma,3 ma,1 ma,2 ma,3 ma,1 ma,2 ma,3 ma,1 ma,2 ma,3 ma,1 ma,2 ma,3 ma,1 ma,2 ma,3 ma,1 ma,2 ma,3 ma,1 ma,2 ma,3 ma,1 ma,2 ma,3 ma,1 ma,2 ma,3 ma,1 ma,2 { ma,3 RNS FP E/FP Figure 1.5 – Hiérarchie des opérations (fictives) dans une multiplication scalaire en utilisant la représentation RNS. (160–521 bits) et enfin sur les couplages [27,42] ont été implantés en RNS. Plus de références sont disponibles dans le tableau 1.6. Son intérêt réside dans le fait qu’on peut découper les opérandes et effectuer un certain nombre d’opérations indépendamment sur les diffé- rents morceaux, c’est-à-dire sans propagation de retenue. C’est le cas notamment pour la multiplication, les additions et les soustractions. Ces opérations peuvent donc être effectuées naturellement en parallèle et être implantées sur des architectures exploitant cette parallélisation. Cependant, certaines opérations sont difficiles en RNS comme la détection de signe/dépassement, la comparaison, la division Euclidienne ou encore la réduction modulaire. Certaines de ces opérations seront traitées particulièrement dans ce document de thèse. Enfin, une autre difficulté pour le RNS vient du fait que c’est une représentation non standard. Les langages de description de matériel (HDL) ainsi que les outils de conception assistés par ordinateur (CAD) ne supportent pas directement la représentation, impliquant un coût de développement important. La figure 1.5 illustre l’intégration du RNS dans la hiérarchie des opérations dans une multiplication scalaire. Dans cette figure, les calculs dans FP sont découpés en petits canaux parallèles ma,1, ma,2 et ma,3, afin d’accélérer les calculs. Le lecteur pourra se référer aux ouvrages [92, 115, 120] pour une introduction approfondie sur les différents aspects du RNS. 1.3.1 Définition et premières propriétés Le CRT, présenté théorème 2, permet de lier directement chacun des éléments de [0, M− 1] à un « vecteur » (x1, . . . , xn) (avec M = Qn i=1 mi et xi ∈ [0, mi − 1] pour tout i). Plus précisément, nous avons une bijection entre les éléments de Z/MZ et (Z/m1Z, . . . , Z/mnZ), c’est à dire une nouvelle façon de représenter les éléments modulo M. L’ensemble des mi permet alors de définir complètement cette représentation et on appelle (m1, . . . , mn) la base RNS. Définition 4. Soient Ba = (ma,1, . . . , ma,na ), où tous les ma,i sont des entiers naturels premiers 2 à 2, et X ∈ Z. Alors Ba est une base RNS et on définit la représentation RNS de X en base Ba par : −→ X = (xa,1, . . . , xa,na ) = (|X|ma,1 , . . . , |X|ma,na ) . (1.8) De plus, si X ∈ [0, Ma − 1] où Ma = Qna i=1 ma,i, et si on définit Ta,i = M ma,i alors X = |X|Ma =      Xna i=1    xa,i · T −1 a,i    ma,i × Ta,i      Ma (1.9)48 CHAPITRE 1. ÉTAT DE L’ART w w w xa,1 ya,1 za,1 mod ma,1 + − × (/) canal (a, 1) w w w xa,2 ya,2 za,2 mod ma,2 + − × (/) canal (a, 2) • • • w w w xa,na ya,na za,na mod ma,na + − × (/) canal (a, na) Figure 1.6 – Vue globale de la représentation RNS dans la base Ba. La notation (/) désigne la division exacte par un diviseur premier avec chacun des ma,i. permet de retrouver X à partir de −→ X . La notation · désigne ici une multiplication entre deux « petites » valeurs de w bits (la taille d’un modulo), alors que × désigne une multiplication où au moins l’un des deux opérandes est une grande valeur, de l’ordre de n × w bits ou (n − 1) × w bits. On a introduit dans cette définition une notation plus précise que lors de la définition du CRT en annotant d’un indice a toutes les valeurs correspondant à Ba. Comme on le verra par la suite, plusieurs bases seront définies et ces indices permettront de retrouver rapidement la base dans laquelle nous travaillons. Le détail des notations est présenté dans la section dédiée mais des rappels seront donnés tout au long du manuscrit. L’arithmétique de base est très simple en RNS, comme indiqué sur la figure 1.6. En fait, en utilisant les propriétés élémentaires du calcul modulaire présentés en section 1.2.1, on voit immédiatement que les additions/soustractions ou multiplications s’effectuent canal par canal avec −−→ Xa  −→ Ya =  |xa,1  ya,1|ma,1 , . . . , |xa,na  ya,na |ma,na  , (1.10) où  ∈ {+, −, ×}. Sur la figure 1.6, la division est notée entre parenthèse car cela ne concerne que la division exacte lorsque le diviseur est premier avec Ma. Dans ce cas précis, si on note Z le diviseur, la division revient juste à multiplier par l’inverse de Z modulo ma,i pour tout i, c’est à dire par −−→ Z −1 a = (|Z −1 a |ma,1 , . . . , |Z −1 a |ma,na ). On peut remarquer l’équation 1.9 est réduite modulo Ma. Cela signifie que si on calcule une valeur plus grande que Ma, un dépassement se produit et le résultat est réduit modulo Ma. Par exemple, pour éviter un dépassement, deux fois plus de moduli sont nécessaires pour stocker le ré- sultat d’un produit que pour ses opérandes. Par contre la réduction modulo Ma est faite automatiquement lors d’un dépassement, c’est donc une opération très efficace en RNS en base Ba. Nous verrons dans la sous-section 1.3.3 que cette propriété est utilisée pour adapter l’algorithme de Montgomery en RNS.1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 49 Les opérations sont faites indépendamment sur chaque canal, sans propagation de retenue (à la différence de la numération simple de position). Ainsi, ces opérations sont parallélisables si nous disposons de plusieurs unités de calcul modulaire. On observe notamment que la multiplication RNS ne coûte que na multiplications modulaires élémentaires EMM, toutes parallèles. Nous verrons que ce parallélisme est grandement mis à contribution dans les implantations cryptographiques pour son efficacité. De plus, le RNS est une représentation non-positionnelle, il n’y a pas de mot de poids fort ou faible, ils ont tous une place équivalente. Notamment l’ordre des moduli importe peu dans les calculs, on peut ainsi le rendre aléatoire par exemple. Cet aléa a notamment été expérimenté dans l’état de l’art en tant que protection contre certaines attaques par canaux cachés (voir dans la section 1.3.5). En contrepartie, certaines opérations sont plus difficiles en RNS qu’en numération simple de position. C’est le cas, entre autres, de la comparaison qui est complexe en RNS, car c’est un système non-positionnel. On peut par exemple convertir notre vecteur RNS en une représentation positionnelle comme la représentation MRS (présentée section 1.3.2) ou encore la représentation binaire standard, mais ces conversions sont coûteuses (conversion présentée section 1.3.2 pour le MRS, calcul du CRT pour la conversion vers la représentation binaire standard). Enfin, la réduction modulaire par une valeur différente de Ma est une opération difficile, de même que la division Euclidienne. La réduction étant aussi essentielle que la multiplication dans les calculs pour la cryptographie, nous allons voir dans la suite des techniques mises en œuvre pour réduire son coût, menant à une représentation très efficace dans les implantations cryptographiques. Un outil va d’abord être introduit, appelé extension de base (BE) qui permet d’effectuer des conversions entre 2 bases RNS. 1.3.2 Extensions de base RNS Les extensions de base ont été introduites par Szabo et Tanaka dans [120]. Une extension de base est une fonction permettant de passer de −−→ Xa représenté dans la base Ba à −→ Xb dans Bb, qui est première avec Ba (c’est à dire Ma et Mb sont premiers entre eux). Les extensions de base de l’état de l’art permettent d’éviter un retour à la représentation standard. Comme nous allons le voir, il existe deux grandes techniques pour les effectuer, une utilisant encore le CRT, l’autre passant par une représentation intermédiaire appelée mixed-radix system (abrégée MRS [49]). On nomme ces conversions « extensions de base » car une fois −→ Xb obtenu, puisque Ba et Bb sont premières entre elles, la concaténation des 2 vecteurs −−→ Xa|b est une représentation RNS de X étendue à na + nb restes, dans la base notée Ba|b . Dans tous les algorithmes de l’état de l’art, on a toujours na = nb = n, les coûts seront parfois donnés dans ce cas précis. Les extensions de base vont être utilisées dans les algorithmes de réduction modulaire de l’état de l’art (cf. section 1.3.3). Extensions de base RNS via la représentation MRS La première forme d’extension de base, introduite en [120], propose d’effectuer une conversion de la représentation RNS en base Ba à la représentation MRS [49] (définie pour la base Ba) puis enfin de convertir cette représentation en base Bb. Nous allons donc tout d’abord définir ce qu’est la représentation MRS en base Ba. Définition 5. Soit (ma,1, . . . , ma,na ) un ensemble de na entiers strictement positifs et soient Ma = Qna i=0 ma,i et X < Ma (on considère que ma,0 = 1). Alors la représentation MRS de X dans la base (ma,1, . . . , ma,na ) est l’unique n-uplet (x 0 a,1 , . . . , x0 a,na ) tel que 0 6 x 0 a,i < ma,i pour tout i ∈ [1, n] et50 CHAPITRE 1. ÉTAT DE L’ART X = Xna i=1 (x 0 a,i Y i−1 j=0 ma,j ) = x 0 a,1 + x 0 a,2 ma,1 + x 0 a,3 ma,1ma,2 + . . . + x 0 a,na nYa−1 j=0 ma,j . (1.11) On peut convertir (xa,1, . . . , xa,na ) en (x 0 a,1 , . . . , x0 a,na ) de façon efficace, c’est à dire passer du RNS en base Ba au MRS en base Ba. Tout d’abord, on peut remarquer que x 0 a,1 = xa,1 en réduisant l’équation 1.11 modulo ma,1. De même, en réduisant l’équation modulo ma,2, on obtient x 0 a,2 = |(xa,2−x 0 a,1 )·m−1 a,1 |ma,2 . L’algorithme 13 décrit complètement la conversion RNS vers MRS. Algorithme 13: Conversion RNS vers MRS [120]. Entrée : −→ X = (xa,1, . . . , xa,na ) en base Ba Pré-calculs : |m−1 a,i |ma,j pour i < j Sortie : (x 0 a,1 , . . . , x0 a,na ) 1 x 0 a,1 ←− x1 2 x 0 a,2 ←− |(xa,2 − x 0 a,1 ) · m−1 a,1 |ma,2 3 x 0 a,3 ←−     (xa,3 − x 0 a,1 ) · m−1 a,1 − x 0 a,2  · m−1 a,2    ma,3 4 · · · 5 x 0 a,na ←−     . . .  xa,na − x 0 a,1
m−1 a,1  − x 0 a,2  m−1 a,2  . . . − x 0 a,na−1  m−1 a,na−1    ma,na L’algorithme 13 requiert na(na−1) 2 pré-calculs et autant de multiplications modulaires élémentaires EMM. Pour finir l’extension de base, il suffit d’évaluer l’expression de X (équation 1.11) dans chacun des canaux de la seconde base. Autrement dit, on calcule xbk =  x 0 a,1 + x 0 a,2 ma,1 + x 0 a,3 ma,1ma,2 + . . . + x 0 a,na Ta,na   mbk , (1.12) pour tous les k ∈ [1, nb]. Si on suppose que les Qi−1 j=0 ma,j pour tout i ∈ [1, na] sont pré- calculés, cette dernière étape demande na × nb EMM. Des améliorations sur cette dernière partie ont été proposées par Bajard et al. dans [12], en choisissant bien les éléments de Ba et Bb. En effet, le coût des multiplications modulaires élémentaires EMM peut être réduit en prenant des moduli de la forme 2 w − c où c est une valeur avec un faible poids de Hamming. De plus, en choisissant bien Ba et Bb, il est possible de réduire les multiplications de l’équation 1.12 à des combinaisons de décalages et additions. Bien qu’évoqué ici, ce type d’extension de base ne sera pas utilisé dans nos travaux d’implantation. Tout d’abord le gain obtenu par Bajard et al. dans [12] dépend beaucoup de l’architecture. Nous verrons que l’architecture que nous avons choisi comme base de travail, qui est en fait l’architecture de l’état de l’art des implantations ECC en RNS, utilise des multiplieurs embarqués sur FPGA (ceux des blocs DSP). Dans cette architecture, l’addition se révèle même plus chère que la multiplication, comme expliqué dans la section 1.3.5. Remplacer ces multiplications par des additions et des décalages n’est donc pas intéressant dans ce cas. De plus, l’inconvénient de cette méthode est qu’il y a beaucoup de dépendances de données lors de l’algorithme 13, limitant fortement la parallélisation. Les architectures de l’état de l’art étant fortement parallélisées (le parallélisme naturel du RNS est l’un de ses plus gros points forts), cet algorithme n’est pas très adapté. Dans [8], Bajard et al. soulignent aussi ce fait, et estiment que la complexité temporelle de leur proposition, en supposant n unités de calcul parallèles, est moins bonne que celle des extensions basées sur le CRT, que nous allons maintenant présenter.1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 51 Extensions de base RNS utilisant le CRT Une autre façon d’évaluer la valeur de X dans la base Bb à partir −−→ Xa est d’évaluer le CRT en Ba et de le réduire dans la base Bb. On peut d’abord réécrire l’équation 1.9 : X = Xna i=1    xa,i · T −1 a,i    ma,i × Ta,i − qMa , (1.13) où q = Pna i=1    xa,i · T −1 a,i    ma,i × Ta,i /Ma  . L’idée des extensions basées sur le CRT est d’évaluer l’équation 1.13 modulo chacun des éléments de Bb. On remarque d’abord que la somme Pna i=1    xa,i · T −1 a,i    ma,i ×Ta,i coûte na multiplications pour le calcul de    xa,i · T −1 a,i    ma,i pour tout i, puis na multiplications par Ta,i pour chaque canal de Bb. Au total, on a donc nanb+na EMM. Dans les algorithmes utilisés pour la réduction modulaire dans l’état de l’art, on utilise des extensions de base avec na = nb = n, ce qui donne un coût de n 2 + n EMM. Il est aussi important de noter que si nous avons n unités arithmétiques (toujours avec na = nb = n) calculant les multiplications en 1 cycle, alors ce calcul seul demande n + 1 cycles. Maintenant, il reste à calculer q, qui est le résultat d’un quotient et qui semble difficile à évaluer. Le matériel de calcul modulaire sur les canaux n’étant pas adapté à ce calcul, nous allons voir comment calculer q en minimisant le coût des opérateurs nécessaires à cette nouvelle opération. Extensions de base CRT par extra modulo Une première méthode a été proposée par Shenoy et Kumaresan dans [112]. En fait, ils ont remarqué qu’en ajoutant un modulo supplémentaire ma,na+1, il était possible de retrouver q. Posons ξa,i =     xa,i  Ma ma,i −1     ma,i =    xa,i T −1 a,i    ma,i . D’après l’équation 1.13 on a : q Ma = Xna i=1 ξa,i · Ta,i! − X , (1.14) qui pris modulo ma,na+1 donne |q Ma|ma,na+1 =            Xna i=1 ξa,i · Ta,i      ma,na+1 − xma,na+1       ma,na+1 , aboutissant finalement à |q|ma,na+1 =        M−1   ma,na+1 ·      Xna i=1 ξa,i · Ta,i      ma,na+1 − xma,na+1       ma,na+1 . En choisissant ma,n+1 > q, on aura alors directement q = |q|ma,na+1 . Par définition, on a ξa,i < ma,i et donc ξa,i Ta,i < Ma. Finalement Pna i=1 ξa,i Ta,i < naMa, ce qui prouve que q < na. Dans les applications cryptographiques, na est bien plus petit que la largeur des canaux (typiquement de 2 à 7 bits, contre des canaux de 16 à 64 bits). Le modulo supplémentaire doit juste être supérieur à q, on le choisit donc tel que ma,na+1 > na. Cet52 CHAPITRE 1. ÉTAT DE L’ART algorithme n’est pas très cher, on peut allouer une petite ressource effectuant les calculs sur ce petit modulo supplémentaire qui effectuera les na+1 multiplications nécessaires. Les calculs sont seulement sur dlog2 nae bits contre w bits pour les calculs sur les canaux RNS. Il faut noter par contre qu’il faudra effectuer tous les autres calculs cryptographiques aussi sur ce petit canal supplémentaire, il y a donc un surcoût aussi sur les opérations basiques RNS comme la multiplication. Cependant, on verra dans la section 1.3.3 qu’on ne peut pas utiliser cette méthode dans certains cas. Extensions de base CRT avec approximation Une autre approche permet de calculer q de l’équation 1.13, ou du moins d’en calculer une bonne approximation. Dans leur travaux [98], Posch et Posch ont remarqué qu’en simplifiant l’expression de q on avait : q = $Xna i=1 ξa,i ma,i% , (1.15) avec ξa,i défini comme précédemment. En évaluant une approximation de ce rapport, on aurait donc une approximation du CRT, et donc de −→ Xb . Ils ont montré que si on peut limiter X à être 0 < X < (1 − εmax)Ma, alors on peut toujours s’arranger pour que le calcul approché donne le bon q. Kawamura et al. [64] ont proposé une méthode permettant d’approcher efficacement q en matériel, grâce à un accumulateur sur quelques bits, utilisé seulement lors de l’extension de base (à la différence de la proposition précédente de Shenoy et Kumaresan). Cette approche requiert d’avoir tous les éléments de la base sous la forme 2 w−ha,i avec ha,i < 2 w/2 (c’est-à-dire des pseudo-Mersenne de même taille). Cette condition n’est pas vraiment contraignante car les pseudo-Mersenne sont habituellement choisis pour l’efficacité de la réduction modulaire sur chacun des canaux. De plus, le fait que tous les éléments de la base soient de la même taille est aussi un argument matériel, car il permet d’avoir des unités arithmétiques identiques pour tous les canaux (aux pré-calculs près). Finalement l’approximation se traduit par le calcul de q 0 = $ σ0 + Xna i=1 trunc(ξa,i) 2 w % (1.16) où trunc(ξa,i) est une fonction qui approche ξa,i par ses t bits de poids forts suivis de w −t bits à 0. Si t est petit alors l’évaluation de q revient juste à sommer na valeurs de t bits, la division par 2 w sert juste à savoir où se trouve la virgule et borner l’erreur d’approximation (voir les détails dans [64]). Par exemple, les auteurs de [87] ont implanté cette approximation pour des calculs sur RSA 2048 bits, et t = 8 était suffisant. Ce calcul était effectué sur un petit accumulateur, en parallèle des calculs sur les unités arithmétiques des canaux. Avant d’expliquer plus en détail comment l’approximation fonctionne, nous allons pré- senter l’algorithme 14 d’extension de base, issu de [64]. On peut voir qu’il y a une boucle principale sur la première base (on compte jusqu’à na), puis une seconde interne sur la seconde base. Dans cet algorithme, on ne calcule pas d’abord la somme pour trouver q, mais on fait plutôt un calcul à la volée. Ainsi, plutôt que de soustraire q d’un seul coup, il va être soustrait progressivement, remplaçant la multiplication q(−Ma) par une succession1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 53 Algorithme 14: Extension de base (BE) issue de [64]. Entrées : −−→ Xa , Ba, Bb, σ0 (paramètre fixé du système) Pré-calculs : −−−−−→ T −1 a
a , −−−→ (Ta) b , −−−−−−→ (−Ma) b Sortie : −→ Xb 1 −→ ξa = −−→ Xa × −−−−−→ T −1 a
a , −→ Xb = −→ 0b , σ = σ0 2 for i = 1, . . . , na do 3 σ = σ + trunc(ξa,i) 4 q = bσc /* Commentaire : q vaut 0 ou 1 */ 5 σ = σ − q 6 for j = 1, . . . , nb do 7 xb,j = |xb,j + ξa,i · Ta,i + q · (−Ma)|mb,j 8 retourner −→ Xb de q soustractions de Ma. Le calcul du CRT sur les éléments de la base Bb est effectué dans la boucle interne (en matériel sur les unités de calcul modulaire). Pour le coût de l’algorithme, on compte généralement une multiplication RNS pour la ligne 1 (na EMM), et na × nb EMM pour la ligne 7. Le décompte de la multiplication q(−Ma) dépend des auteurs, on la compte soit comme na EMM en tant que produit (par exemple dans [48]), soit elle n’est pas comptabilisée comme une multiplication mais comme q × nb EMA, où EMA dénote les additions élémentaires sur chacun des canaux. Les contributions de l’état de l’art sont rares à prendre en compte les additions. Il est difficile d’estimer quelle est la meilleure façon de compter, sachant que q × nb dépend du système mais aussi de la valeur qu’on étend à une autre base. On peut cependant borner cette valeur à na ×nb EMA pour se situer dans le pire cas. Pour un décompte plus « mathématique », il sera plus simple de compter na EMM (c’est à dire une multiplication RNS sur la base Ba), alors que dans un cadre d’implantation tel que [52], la valeur na × nb EMA reflétera mieux ce qui est effectué en matériel, le matériel étant conçu pour le pire cas, c’est à dire na soustractions sur les nb canaux. Les deux théorèmes suivants, extraits de [64], définissent les cadres d’utilisation de l’approximation. Théorème 4 (issu de [64]). Soit σ0 tel que 0 6 εmax 6 σ0 < 1 et supposons X tel que 0 6 X < (1 − σ0)Ma alors q 0 = q. Théorème 5 (issu de [64]). Soient σ0 = 0 et X tel que 0 6 X < Ma alors q 0 = q ou q 0 = q − 1. Cela signifie que si X est suffisamment petit par rapport à Ma (le produit des éléments de Ba), on peut faire en sorte que q 0 = q en choisissant bien σ0 (qui est directement déterminé par t et les éléments de la base comme nous allons voir). Si ce n’est pas le cas, on obtient alors un résultat approché, mais on sait alors que soit q 0 = q soit q 0 = q − 1. Le résultat de l’extension de X dans la base Bb est alors −→ Xb si la conversion a bien fonctionné et −−−−−−−−→ (X + Ma)b s’il y a eu une erreur d’approximation. En fait, on commet 2 erreurs dans l’approximation. La première est due à l’utilisation de trunc et dépend donc directement de t. La seconde est due à l’approximation des éléments de la base par 2 w. D’après [64], on a τ = max  ξa,i−trunc(ξa,i) ma,i  qui est l’erreur maximale due à trunc et54 CHAPITRE 1. ÉTAT DE L’ART δ = max  2 w−ma,i 2 r  l’erreur maximale due à la division par 2 w. L’erreur maximale globale est alors εmax = na(τ + δ). Dans [64], il est prouvé que : Xna i=1 ξa,i ma,i − na(τ + δ) < Xna i=1 trunc(ξa,i) 2 w < Xna i=1 ξa,i ma,i , (1.17) ce qui permet de déduire le théorème 5. Pour le théorème 4, remarquons d’abord que d’après l’équation 1.14, on a : q + X Ma = Xna i=1 ξa,i ma,i , et si on rajoute σ0 tel que na(τ + δ) 6 σ0 < 1 de chaque côté dans l’équation 1.17 on obtient :  q + X Ma  − na(τ + δ) + σ0 < Xna i=1 trunc(ξa,i) 2 w + σ0 <  q + X Ma  + σ0 . (1.18) En se plaçant dans les conditions du théorème, on a X < (1 − σ0)Ma, on déduit finalement q 6 Xna i=1 trunc(ξa,i) 2 w + σ0 < q + 1 qui prouve qu’en prenant la partie entière on obtient bien exactement q. Nous allons maintenant voir comment ces extensions de base permettent une réduction modulaire efficace en RNS. 1.3.3 Adaptation RNS de l’algorithme de Montgomery L’algorithme de l’état de l’art de réduction modulaire en RNS est basé sur l’algorithme de Montgomery, présenté à la section 1.2.2. La première adaptation RNS a été proposée dans [99] et optimisée notamment dans [6,48,64]. L’algorithme 15 décrit l’algorithme dans sa version initiale, avec une généralisation sur les conditions sur les entrées de l’algorithme grâce à un paramètre α, proposée par Guillermin dans [52]. Algorithme 15: Réduction de Montgomery RNS (MR) [99]. Entrées : ( −−→ Xa , −→ Xb ) avec X < αP2 , Ma > αP et Mb > 2P Pré-calculs : ( −→ Pa , −→ Pb ), −−−−−−→ (−P −1 )a , −−−−−→ (M−1 a )b Sortie : −→ S = −−−−−−−−−→  X|M−1 |P   P + δ −→ P avec δ ∈ {0, 1} in Ba and Bb 1 −→ Qa ← −−→ Xa × −−−−−−→ (−P −1 )a /* Commentaire : réduction par Ma implicite */ 2 −→ Qb ← BE −→ Qa , Ba, Bb  3 −→ Rb ← −→ Xb + −→ Qb × −→ Pb 4 −→ Sb ← −→ Rb × −−−−−→ (M−1 a )b 5 −→ Sa ← BE −→ Sb , Bb, Ba  6 retourner ( −→ Sa , −→ Sb )1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 55 Les lignes 1, 3 et 4 correspondent aux 3 lignes de l’algorithme 8 où R = Ma, plutôt qu’à une puissance de 2. Dans l’algorithme original de Montgomery, on utilise le fait que les réductions modulo 2 w et les divisions par 2 w sont très faciles. Ici, grâce au CRT, calculer dans Ba opère une réduction implicite du produit Xa × (−P −1 )a par Ma. Par contre, pour pouvoir effectuer une division par Ma, il nous faut passer par une seconde base RNS Bb (première avec la base Ba), pour laquelle la division exacte par Ma devient triviale comme expliqué au début de la section 1.3. Dans chacune des bases, une seule des 2 opérations est facile, on doit donc avoir recours à des extensions de base pour pouvoir passer de l’une à l’autre. Dans l’algorithme 8, la sortie de l’algorithme est inférieure à 2P et l’entrée pouvait aller jusqu’à 4P 2 . Les travaux présentés dans [52] permettent de généraliser la condition sur l’entrée grâce à un paramètre α. Grâce à cette généralisation, on peut utiliser la technique de réduction paresseuse (ou lazy reduction), où on effectue une seule réduction pour calculer par exemple (AB + CD) mod P, et plus généralement une somme de produits ré- duite modulo P. Les multiplications et additions étant bien plus efficaces que les réductions en RNS, cette technique est utilisée par exemple en [8] pour proposer des formules ECC adaptées au RNS. En utilisant les mêmes arguments que pour l’algorithme 8, la taille de la sortie est majorée par 2P (voir [52] pour la démonstration). Quelques remarques avant de discuter des améliorations de cet algorithme qui ont été proposées dans la littérature. Tout d’abord, l’algorithme est toujours utilisé dans le cas na = nb = n. En effet, son cadre classique d’utilisation est la réduction après un produit de valeurs de FP (ou alors d’une somme de produits). L’entrée est de taille de 2 log2 P, il nous faut donc déjà 2n moduli pour la représenter (impliquant une seconde base Bb). De plus, pour obtenir un résultat de taille log2 P (ou plutôt log2 P + ), il faut que notre première base soit composée d’au moins n moduli (on a Ma > αP). C’est pourquoi on a toujours na = nb = n. Ensuite, il faut bien noter que le coût global de l’algorithme est largement dominé par les extensions de base. En effet 2 sont requises, et si on utilise une extension de base de type CRT, on a besoin de nanb + na EMM sinon via le MRS on obtient na(na−1) 2 + nanb EMM. Ces coûts sont donc bien plus élevés que les na ou nb EMM requises pour faire les lignes 1, 3 et 4. Il y a d’abord un choix à faire au niveau des algorithmes d’extension de base. Si nous nous considérons sur une architecture parallèle, nous excluons l’extension de base via MRS pour son manque de parallélisme. Ensuite, nous pouvons remarquer qu’il est impossible d’utiliser l’extension de Posch et Posch [98] pour la première extension de base de manière efficace. Cela vient du fait que l’on ne peut pas calculer   |X × (−P −1 )|Ma   ma,n+1 efficacement dans le modulo supplémentaire, puisqu’il ne divise pas Ma. On ne peut donc pas évaluer q dans ce cas. Par contre, la seconde extension de base n’inclut pas de réduction implicite, en effet, les calculs lignes 3 et 4 sont faits de telle sorte que le résultat soit borné par 2P et comme Mb > 2P, aucune réduction n’est opérée. S peut donc bien être calculé dans notre canal supplémentaire, ce qui nous permet d’utiliser l’extension avec extra modulo. L’extension de base de Kawamura et al. [64] peut, elle, être utilisée pour l’extension de base ligne 1 et celle ligne 5. En fait, en ligne 1, on va utiliser le théorème 5 car puisque Q est une valeur prise modulo Ma, on ne peut pas assurer qu’elle soit plus petite que (1−σ0)Ma avec σ0 > 0 (on peut avoir Q = Ma−1 par exemple). Le résultat de l’extension de base −→ Qb56 CHAPITRE 1. ÉTAT DE L’ART est alors soit Q soit Q+Ma dans la seconde base. Il se trouve que cela ne va pas changer le résultat modulo P car on calcule (ligne 3) −→ Qb × −→ Pb . L’impact de l’erreur d’approximation se retrouve dans la taille de S avec une borne S < 3P au lieu de S < 2P (il suffit de choisir la base Bb pour un Mb un peu plus grand). Par contre ligne 5, on se retrouve dans le cas d’utilisation du théorème 4 sans erreur d’approximation, car puisque l’on peut borner S suivant P, on peut choisir Bb et σ0 pour obtenir le bon résultat. Il est d’ailleurs nécessaire que cette extension de base soit exacte, car elle mène au résultat final (il n’y a pas l’effet de la multiplication par P comme après la première extension de base). Enfin, une méthode a été proposée par Bajard et al. [7] remarquant que, puisque l’erreur de l’approximation de l’extension de base de Kawamura et al. effectuée en ligne 1 n’a comme effet que de fournir une sortie S < 3P au lieu de S < 2P, alors ils ont proposé de ne même pas calculer q de l’équation 1.13. Ainsi, le résultat obtenu en base Bb est, au pire, Q + nMa menant à une sortie S < nP. La valeur n étant assez réduite même pour un RSA 2048 (par exemple si w = 32 alors n = 65) on peut considérer que ce surplus est acceptable. La sortie a donc quelques bits supplémentaires (on devra augmenter la taille de Ma). Par contre, on voit que cette méthode ne s’accorde pas très bien avec la technique de réduction paresseuse car si on calcule par exemple (AB + CD + EF) mod P alors la sortie sera de taille S < 3nP. Cette technique ne peut-être utilisée que sur la première extension de base, la seconde devant être exacte, elle est souvent combinée à la réduction de Posch et Posch [98] qui elle s’applique dans l’autre extension (voir par exemple [48]). Le coût de l’algorithme 15 est directement lié au choix des extensions de base. Nous n’allons pas considérer ici le cas d’une extension de base via MRS, pour les raisons déjà évoquées plus tôt. Nous allons utiliser une extension de base via le CRT. On va considérer une configuration avec deux extensions de base BE de Kawamura et al. [64] (que l’on notera KBE) et une autre avec la combinaison BE de Bajard et al. [7]/Posch et BE de Posch [98] (notée BPBE). En comptant les multiplications, et en négligeant la multiplication qMa (considérée comme des additions), on obtient un algorithme avec un coût de 2n 2 + 5n EMM (n 2 + n par extension de base, plus les lignes 1,3,4). Si on compte la multiplication qMa, on obtient 2n 2 + 7n pour KBE et 2n 2 + 6n pour BPBE. Dans leurs travaux (indépendants), Guillermin [52] et Gandino et al. [48] ont réduit le coût de l’algorithme MR en factorisant les calculs dans les extensions de base pour y intégrer directement les lignes 1, 3 et 4. Ainsi, la multiplication ligne 1 de l’algorithme 14 −−→ Xa × −−−−−→ T −1 a
a peut se combiner avec la multiplication ligne 1 de l’algorithme 15, −−→ Xa × −−−−−−→ (−P −1 )a en calculant directement −−→ Xa × −−−−−−−−−→ −P −1T −1 a
a. Il faut pour cela pré-calculer −−−−−−−−−→ −P −1T −1 a
a. En fait, on peut faire de même pour la seconde extension de base, en pré- calculant −−−−−−−−−→ M−1 a T −1 b
b . On peut appliquer cette méthode pour KBE et BPBE pour un gain de 2n EMM. En plus de ces gains, Gandino et al. ont prouvé que nous pouvions factoriser encore plus pour la seconde extension de base. En effet, ils proposent de modifier la représentation dans la seconde base en gardant les valeurs multipliées par −−−−−→ T −1 b
b , ce qui permet ensuite de fusionner les lignes 3, 4 et de directement les intégrer dans la ligne 7 de l’algorithme d’extension de base 14. La modification de la représentation requiert encore quelques pré-calculs. Dans les travaux [48] sont présentés les résultats pour KBE et BPBE. Nous obtenons finalement que le coût de l’algorithme 15 est 2n 2 + 2n EMM pour KBE et pour BPBE si on compte qMa comme q additions. Sinon on obtient 2n 2 + 4n EMM pour1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 57 KBE et 2n 2 + 3n EMM pour BPBE. 1.3.4 Autres algorithmes de réduction D’autres algorithmes non basés sur celui de Montgomery ont été proposés dans la littérature. L’algorithme de Montgomery semble toujours être la meilleure solution, mais peut-être que des avancées majeures de ces autres formes changeront la donne. Phillips et al. ont proposé dans [95] une façon originale d’effectuer la réduction modulaire, bien qu’elle soit bien moins performante (en théorie et sûrement en pratique) que l’algorithme RNS Montgomery MR. Cette méthode, appelée somme des restes, est quand même évoquée car elle propose une vision différente de l’algorithme RNS de l’état de l’art. La méthode ne va pas être présentée de façon aussi détaillée que l’algorithme 15, on pré- sentera ici l’idée utilisée et le coût global de l’algorithme. À notre connaissance, il n’y a pas d’implantation de cet algorithme dans la littérature RNS. Dans cette proposition, on considère la concaténation de Ba et Bb comme une seule et unique grande base. X est une valeur issue d’un produit d’éléments de FP et l’idée de cette réduction modulaire et d’évaluer directement le CRT modulo P, c’est à dire de calculer : |X|P ≡ X 2n i=1 ξa|b,i ×  Ta|b,i   P +  −q Ma|b   P , (1.19) où ξa|b,i =    xa|b,i · T −1 a|b,i    ma|b,i . On remarque qu’il faut en fait définir notre grande base Ba|b (concaténation de Ba et Bb), avec plus de bits que pour MR. En effet, si on évalue l’équation 1.19, on observe que la somme obtenue est seulement majorée par P × P2n i=1 ma|b,i qu’on peut simplifier en 2n2 wP. De plus, son principal défaut est que l’équation 1.19 né- cessite 4n 2 EMM, soit 2 fois plus que l’état de l’art. Enfin, le calcul de q est calculé avec l’approximation de Kawamura et al. [64]. L’avantage de cette méthode est que, du fait de sa simplicité, il y a moins de dépendances de données que dans l’algorithme 15. Enfin, une tentative de transcription de la réduction de Barrett en RNS a été proposée dans [106, 108]. Cette proposition étant récente, je n’ai pas encore pu étudier de façon approfondie la contribution, mais il semble qu’elle soit moins bonne que l’algorithme de Montgomery RNS. Cette méthode impose notamment de pouvoir effectuer des additions et multiplications en représentation standard sur des nombres de la taille de P, ce qui ne semble pas adapté à l’utilisation des architectures habituelles de l’état de l’art RNS. De plus, d’après [106, 108], cet algorithme requiert aussi 4n 2 EMM, soit deux fois plus que l’algorithme de Montgomery RNS. 1.3.5 Implantations RNS Depuis une quinzaine d’années, le RNS prend de plus en plus d’importance dans les implantations matérielles de cryptographie asymétrique. Dans le tableau 1.6, un bon nombre de ces contributions sont listées, incluant aussi des implantations sur GPU et microprocesseur. Nous allons commenter maintenant quelques unes de ces contributions, et des stratégies vis à vis des paramètres adoptés.58 CHAPITRE 1. ÉTAT DE L’ART ref. conf./journ. aa usage implant. ` et (n × w) [6] IEEE TC 98 RSA N 1024 (33 × 32) [64] EuroCrypt 00 RSA N 1024 (33 × 32) [87] CHES 01 RSA A 250 nm 672, 1024, 2048, 4096 (22 × 32), (33 × 32) (66 × 32), (66 × 32 ?) [29] MWSCAS 03 RSA F Virtex 2 1024 (9 × {58, . . . , 64} ?) [10] IEEE TC 04 RSA N 1024 (33 × 32) [109] MELECON 06 ECC Virtex2 Pro 160 (20 × 30) [84] IMA CC 07 RSA G 7800GTX 1024 (88 × 12 & 44 × 24) [71] ASSC 07 RSA P Xtensa 1024 (33 × 32), 1024 (17 × 32 ?) [121] CHES 08 RSA G 8800GTS 1024 (16 × 32 ?), 2048 (32 × 32 ?), ECC 224 (7 × 32) [104] IEEE TCAS I 09 ECC F Virtex E 160, 192, 224, 256 5 bases/FP size e.g. (30 × {23, 28, 30, 35}) [72] TenCon 09 ECC P Xtensa 192 (7 × 32) [52] CHES 10 ECC F Stratix 160 (5 × 34), 192 (6 × 33), 256 (8 × 33), I & II 384 (11 × 35), 521 (15 × 35) [27] CHES 11 Coupl. F Virtex 6 126, 128, 192 (courbes de Barreto-Naehrig) Stratix 3 (8 × 33), (8 × 33), (19 × 33) Cyclone 2 [53] ePrint IACR 11 RSA Stratix III 1024 (16 × 36 ?) (33 × 32) [105] ISCAS 11 RSA N 1024 (33 × 32) [127] Pairing 12 Coupl. F Virtex 6 126, 128 (courbes de Barreto-Naehrig) (4 × 67) [48] IEEE TC 12 RSA A 45 nm 1024 (33 × 32) [5] Comp. J. 12 ECC G 285GTX 224 (15 × 16) [9] Arith 13 RSA A 250 nm 1024 (33 × 32), 4096 (65 × 64) [94] DSD 13 RSA F Spartan 3 1024 (17 × 32 ?) [45] IEEE TVLSI 13 ECC F VirtexE 160, 192, 224, 256 Virtex 2 Pro 3 × 56, (3 × 66 & 4 × 50), Stratix II 4 × 58, 4 × 66 [107] IEEE TCAS 14 RSA F Virtex6 1024 (66 × 16, 33 × 32) F Virtex 2 1024 (18 × 64) [14] ePrint IACR 14 ECC F Kintex 7 256, 521 (16 × 17 , 31 × 17) Table 1.6 – Implantations de cryptographie asymétrique en RNS. Colonnes : 1 référence, 2 nom conférence/journal, 3 année (19aa/20aa), 4 usage (ECC, Couplages, RSA), 5 implantation (N pour des résultats Non reportés, FPGA, ASIC CMOS, GPU, Processeur), 6 paramètres généraux (taille de FP et caractéristiques des bases RNS). ? note une implantation RSA-CRT.1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 59 canal 1 rower 1 w w canal 2 rower 2 w w . . . canal n rower n w w cox . . . 1 t w w Sortie Entr´ee n × w w w w w w w CTRL Figure 1.7 – Architecture Cox-Rower pour le calcul ECC de [52] (adaptation de [64]). La première implantation matérielle complète de RSA en RNS se trouve dans la contribution [87], qui est une implantation de l’architecture dite Cox-Rower permettant le calcul modulaire efficace en RNS. Ce travail fait suite à la proposition d’architecture [64], ou était proposée l’astuce de Kawamura et al. et présenté le Cox-Rower. La figure 1.7 représente une version de l’architecture de Kawamura et al. utilisée dans le cas de calculs ECC dans [52]. Cette architecture Cox-Rower est composée d’unités chargées des calculs sur les diffé- rents canaux des bases Ba et Bb, appelés Rowers dans la figure 1.7, et d’un petit accumulateur Cox calculant q pour l’extension de base (présenté figure 1.8). Dans cette thèse, nous conserverons les termes anglais Cox et Rower pour garder la cohérence avec la notation de la littérature sur le sujet et ainsi faciliter la compréhension. On pourrait traduire ces termes par barreur pour le Cox et rameurs pour les Rowers. Comme me l’a expliqué le professeur Kawamura rencontré lors de CHES 2013, le nom vient du fait que le Cox rythme le travail des rameurs ou Rower durant l’extension de base (le signal passe à 1 pour ordonner la soustraction de Ma dans l’algorithme 14, ligne 7). Le Cox laisse le véritable effort de calcul aux Rowers, il ne doit donc pas être trop grand vis à vis de ceux-ci, mais il est indispensable pour arriver à destination (c.-à-d. avoir une approximation correcte). Dans l’architecture figure 1.7, les petits carrés indiquent de simples sélections de bits (par exemple pour le Cox, les t bits de poids forts) et les petits cercles ( ) sont des signaux de contrôle. Cette figure illustre le principe général des principales architectures de l’état de l’art, qui sont souvent avec n Rowers pour n canaux (c’est à dire autant de Rowers que d’éléments dans une base). Le Cox est illustré figure 1.8. Comme déjà expliqué précédemment, c’est une petite unité composée d’un accumulateur de t bits (t choisi afin60 CHAPITRE 1. ÉTAT DE L’ART de calculer de façon exacte q). Il y a eu différentes variations d’architectures Cox-Rower. Par exemple, dans la version originale de Kawamura et al. [64], une propagation de retenue entre les différents blocs est instanciée pour effectuer la conversion RNS/représentation binaire standard. Guillermin, dans ses travaux [52], montre qu’il n’est pas nécessaire d’avoir ces retenues entre les blocs en effectuant une conversion un peu plus lente. Ceci dit, les temps de conversion sont né- gligeables devant les temps de calcul de la multiplication scalaire ou d’une exponentiation. On peut trouver un autre exemple dans le papier de Nozaki et al. [87] où les auteurs ont choisi d’implanter un Cox par Rower (en fait un Cox est inclus dans chacun des Rowers), pour limiter la sortance (fanout en anglais) du Cox ainsi que le routage. De plus, pour cette implantation de RSA, 11 Rowers sont implantés permettant d’effectuer les calculs sur 22, 33 et 66 moduli. Cette contribution met donc aussi en valeur l’aspect modularité du RNS (leur architecture permet d’effectuer des calculs RSA de 672 à 2048 bits, et jusqu’à 4096 si on utilise une implantation de type RSA-CRT). Enfin, afin d’effectuer l’extension de base de Kawamura et al., les auteurs ont opté pour une structure en anneau pour les Rowers, c’est à dire que chaque Rower a sa sortie reliée à un Rower voisin. t t t + 1 1 Figure 1.8 – Cox présenté dans [64]. Du côté des contributions s’intéressant spécifiquement aux implantations ECC en RNS, la première implantation a été proposée en [109] en 2006. Celle-ci s’éloigne assez de ce qu’avaient proposé Nozaki et al. [87] et Kawamura et al. [64] car ils n’utilisent pas de ré- duction modulaire MM classique, mais utilisent un passage par la représentation standard binaire. Cette stratégie ne semble pas être efficace, car les performances obtenues sont bien inférieures aux propositions basées sur l’utilisation de l’algorithme de Montgomery RNS (comme celle [52]). Les mêmes auteurs ont d’ailleurs choisi d’utiliser les méthodes classiques d’extension de base pour leurs autres contributions par la suite [45, 105, 107]. La contribution [52] propose une des implantations ECC les plus rapides, et protégée contre certaines attaques (par exemple contre les attaques SPA grâce à l’utilisation de l’échelle de Montgomery [62]). Cette implantation ne nécessite pas de forme particulière pour P, à la différence d’une implantation du standard du NIST [91] par exemple. Les implantations faites dans cette thèse sont très similaires à cette implantation. En effet, dans le cadre des implantations RNS, cette contribution est la plus rapide en étant protégée. Elle obtient d’ailleurs des résultats assez proches de [45], qui est l’implantation RNS la plus1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 61 rapide à notre connaissance. Plus de détails seront donnés à propos de cette contribution qui a servi de base architecturale pour nos implantations. La contribution [45] propose une implantation encore plus rapide, toujours en RNS, mais ne peut être comparée équitablement avec la contribution [52] car elle ne propose aucune contre-mesure contre les attaques par canaux cachés. Ainsi, l’algorithme de multiplication scalaire utilisé est l’algorithme 6 doublement et addition. De plus, les formules d’addition et de doublement de points ne sont pas les mêmes que [52]. Il est donc impossible, ou très difficile, de comparer les choix portant uniquement sur l’arithmétique RNS. Choix des paramètres Les propositions de Guillermin [52] et Esmaeildoust et al. [45] dénotent des différences importantes dans les choix d’implantation et de la meilleure utilisation du RNS. Nous allons discuter ici ces choix, en commençant par comparer l’approche des ces 2 papiers. Guillermin a choisi d’utiliser des tailles de mots (c’est à dire de canaux) w 6 36 bits sur les FPGA Stratix pour utiliser au mieux leurs multiplieurs embarqués dans les blocs DSP. L’idée est donc d’avoir des canaux très rapides, une architecture très parallélisée avec des opérations sur des petits mots. De l’autre côté, Esmaeildoust et al. [45] choisissent de gros moduli de 50 à 66 bits sur la même architecture, limitant donc la parallélisation mais permettant de réduire le coût des réductions modulaires (on rappelle que chaque MM coûte 2n 2 + O(n) EMM). De plus, elle permet de choisir des canaux pour lesquels les opérations sont très efficaces, et permet aussi d’utiliser des bases très bien choisies, à la façon des travaux [12]. Par contre, une telle stratégie mène à des fréquences bien plus basses que celle de Guillermin (un facteur 3 au niveau des fréquences en faveur de Guillermin). Des résultats de comparaison sont disponibles dans [45], mais ne déterminent pas de vrai vainqueur. En effet, de prime abord les résultats fournis semblent un peu plus à l’avantage de Esmaeildoust et al.. Mais c’est sans compter que, premièrement, les travaux de [45] n’implantent que l’algorithme doublement et addition présenté algorithme 5, donc moralement un quart d’opérations en moins, et deuxièmement les temps ne sont comparés que pour les plus petites courbes, leur stratégie semble très peu adaptée aux hauts niveaux de sécurité. Ainsi les auteurs de [45] n’ont pas proposé leur solution pour des courbes plus grandes que 256 bits, là où Guillermin propose des résultats d’implantations couvrant toutes les tailles standards du NIST (c’est à dire jusqu’à 521 bits). Les compromis sur les choix de n (le nombre de canaux), et w (la taille d’un canal) n’ont pour le moment été que peu étudiés dans la littérature, mais, dans tous les cas, de telles études dépendraient très fortement de la plate-forme sur laquelle elles seraient menées. Un article très récent sur le choix de n est paru dans [126]. Dans ce papier est considérée une machine avec des mots de m bits (l’exemple de m = 16 est pris) et l’objectif est de compter les multiplications de m bits dans une multiplication modulaire RNS complète. Ici, m ne vaut pas forcément w (où w est toujours la taille des canaux). Dans leurs exemples, les meilleurs résultats suivant cette métrique montrent que les n optimaux, pour leurs modèles, sont assez petits pour une machine 16 bits (des bases de 4 moduli pour des corps de 256 ou 512 bits, 5 moduli pour 1024). Ce résultat met en évidence une certaine contradiction dans les calculs RNS. En prenant des bases avec plus d’éléments, c.-à-d. avec des w plus petits, on réduit le coût des multiplications. En effet, les multiplications sur les canaux EMM ont complexité de w 2 , et les multiplications RNS ont une complexité de n en EMM, ce qui donne un coût de nw2 . Sachant qu’on a toujours, pour un corps fixé de taille62 CHAPITRE 1. ÉTAT DE L’ART `, n × w = `, réduire w permet bien de réduire le coût total d’une multiplication RNS. En contrepartie, en réduisant w, on va augmenter le nombre d’opérations élémentaires pour faire nos réductions modulaires, il y a donc un équilibre à trouver entre les multiplications et les réductions modulaires. Ceci dit, dans les faits, un tel décompte ne s’applique pas directement à une architecture parallèle. En effet, réduire le nombre de multiplications n’implique pas nécessairement de réduire le temps de calcul, le niveau de parallélisme est aussi un facteur très important. Notamment les multiplications sur beaucoup de canaux sont indépendantes et donc parallélisables, mais les sous-produits d’une multiplication pour un grand w le sont beaucoup moins. De plus, choisir un petit n impliquant un grand w, la chute de la fréquence des opérateurs arithmétiques doit être prise en compte, mais n’est pas chiffrable sans avoir implanté effectivement de telles unités. Si on prend par exemple les multiplieurs des constructeurs de FPGA qui sont très optimisés, il y aura à un moment donné un effet de seuil en terme de chute de fréquence dû à un routage devenant d’un coup plus compliqué. Et si ces grosses unités sont pipelinées pour augmenter la fréquence, outre le matériel supplémentaire requis, cela implique une complexification du contrôle pour utiliser efficacement ces unités. Enfin, d’un point de vue attaques physiques, les variations de consommation d’énergie de grosses unités de calcul risquent de se démarquer beaucoup plus sur les traces de consommation que des petits canaux. De même, l’architecture perd du coup en modularité si on considère peu d’unités très grosses. Pour toutes ces raisons, il est très difficile d’évaluer les véritables conséquences de ce type de métrique, le plus sûr (mais aussi de loin ce qui consomme le plus de temps) est d’effectuer un grand nombre d’implantations avec beaucoup de paramètres. Ce genre d’étude sera tôt ou tard nécessaire pour qui veut obtenir les meilleures performances dans une architecture RNS, même si une telle étude serait limitée à un ensemble de circuits (par exemple une famille de FPGA). Architecture sélectionnée Les travaux de cette thèse portent sur des propositions algorithmiques, arithmétiques implantées sur le modèle de l’architecture [52, 54]. L’architecture a été considérée comme une contrainte ici, bien que peut-être, une recherche architecturale améliorerait les résultats que nous avons obtenus avec nos nouveaux algorithmes. C’est pourquoi on détaille ici un peu plus les éléments internes de ce Cox-Rower, adapté de [64]. Les parties modifiées seront directement présentées dans les sections sur les contributions. L’architecture implantée dans [52] (qu’on retrouve dans une version plus détaillée dans [54]) est très proche de celle de Kawamura et al., avec un Cox et n Rowers (l’architecture est donc complètement parallélisée), mais sans la propagation de retenue. Les Rowers ne sont pas directement reliés en anneau dans cette architecture : les sorties sont ici reliées à un grand multiplexeur pour les rediriger vers tous les autres Rowers, lorsqu’on effectue l’extension de base (voir figure 1.7). Les Rowers ont aussi été modifiés pour pouvoir faire des opérations plus complexes que des carrés ou des multiplications par des constantes (ce qui ne posait pas de problèmes pour l’implantation RSA [64, 87]). La figure 1.9, provenant de [54], présente l’unité arithmétique implantée dans cette contribution, avec 6 étages de pipeline. Sur la figure 1.9, ε correspond à ha,i dans les notations présentées précédemment. Cette unité a été spécialement conçue pour optimiser les calculs sur les courbes elliptiques et les réductions modulaires qu’ils requièrent. Cette1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 63 Figure 3.3 – Structure de Rower pour les courbes elliptiques Multiplieur Bus principal U(t) X0 ALU SC regS m C principale ROM ROM1 ROM2 X1 registres C X0 X1 U(t) ε Additionneur modulaire (algorithme 19) 55 tel-00674975, version 1 - 28 Feb 2012 Figure 1.9 – Unité arithmétique contenue dans un Rower pour ECC (source [54]). unité permet de calculer sur Ba la première base Ut = |x1 · x2 + b0(−Mb) + b1Ut−1|ma,i , où b0, b1 ∈ {0, 1} et Ut−1 est le résultat précédent (on définit de même les calculs sur Bb). On rappelle que ha,i permet de déduire le canal sur lequel nous calculons. Cette unité nous permet donc de multiplier ses deux entrées, puis d’ajouter éventuellement au résultat (−Mb) pour corriger l’extension de base avec la technique de Kawamura et al. [64]. Enfin, ce résultat peut être accumulé au résultat précédent, notamment afin de calculer efficacement la somme du CRT. On peut remarquer qu’avec une telle unité de calcul, une addition coûtera 2 cycles car il faudra calculer x1 · 1 + x2 · 1, alors qu’une multiplication ne prendra qu’un seul cycle. Par contre, les 2 cycles de l’addition seront transparents lorsque l’on fera des sommes de produits : faire x1 · x2 + x3 · x4 prendra autant de temps que de calculer indépendamment x1 · x2 puis x3 · x4. L’architecture est donc particulièrement efficace pour les sommes de produits (qui sont utilisées par les formules ECC pour le RNS par [8] ou encore pour le CRT). À notre connaissance, très peu d’implantations FPGA d’ECC se sont révélées plus rapides que celle de Guillermin [52]. En dehors de la contribution RNS [45] dont nous avons parlé précédemment, les contributions [56] et [74] proposent des implantations (non RNS) ECC en FPGA plus rapides que [52]. En fait, il est toujours assez difficile de tirer de vrais conclusions autrement qu’en terme de performance pure. En effet, le papier de Güneysu et Paar [56] propose une implantation double-and-add, en utilisant les premiers du NIST P-224 et P-256 et les coordonnées de Chudnovsky obtenant une multiplication scalaire un64 CHAPITRE 1. ÉTAT DE L’ART petit plus rapide (0.62 ms contre 0.68 ms pour 256 bits) que [52], mais en implantant une multiplication scalaire beaucoup moins coûteuse et avec un P très adapté à la représentation qu’ils utilisent. Enfin, à la différence de Guillermin qui a proposé une implantation générique pour 5 tailles du NIST, la proposition [56] est optimisée pour leur taille de corps. Ces faits sont juste exposés afin de justifier qu’il n’y a, pour le moment, pas de « meilleure » stratégie en terme de choix de l’arithmétique (surtout lorsque P est quelconque). De même, la contribution de Ma et al. [74] propose cette fois-ci une implantation pour un P quelconque, avec une protection SPA, mais cette protection (celle de Möller [86]) réduit en fait beaucoup le nombre d’additions de points à effectuer (c’est un calcul fenêtré divisant par 4 le nombre d’additions de points par rapport à une échelle de Montgomery, pour les paramètres de fenêtre qu’ils ont choisis). On ne peut donc pas comparer équitablement les opérateurs arithmétiques proposés dans [74] et dans [52]. Pour conclure sur cette question, il y a plusieurs façons d’implanter ECC sur FP avec des arithmétiques très différentes et de bonnes performances. De plus, des avancées autant sur l’arithmétique que sur l’utilisation des blocs FPGA étant régulièrement effectuées, il n’existe pour l’heure pas de meilleure solution. Le RNS en tant que protection contre certaines attaques physiques Les spécificités du RNS ont fait que plusieurs propositions de protection contre des attaques par canaux cachés ont été proposées. On a, premièrement, l’indépendance sur les canaux qui nous permet par exemple, d’effectuer les calculs d’un canal aléatoirement sur un Rower ou un autre, ou encore de rendre aléatoire l’ordre des calculs lorsque l’architecture n’est pas complètement parallélisée. Deuxièmement, d’autres choix d’introduction d’aléa sont possibles, comme le fait de choisir aléatoirement Ba parmi les 2n moduli nécessaires pour les réductions (ou plus), introduisant ainsi une représentation dans le domaine de Montgomery aléatoire (en effet, en RNS la valeur X, dans le domaine de Montgomery, est définie par XMa). Ainsi, la contribution [29] de Ciet et al. propose la randomisation des bases en tirant aléatoirement les 2n moduli dans un ensemble de moduli plus grand, avant de procéder à une exponentiation (logarithme discret ou RSA). Comme pointé dans [11], le calcul des constantes pour la réduction de Montgomery prend beaucoup de temps, et n’est pas envisageable (plusieurs To de pré-calculs, voir [11]). L’article [11] de Bajard et al. règle ce problème de pré-calculs, et propose d’effectuer le tirage aléatoire des bases soit avant l’exponentiation (ou multiplication scalaire), soit pendant l’exponentiation même, en utilisant simplement quelques appels à la multiplication de Montgomery RNS. Le terme de leak resistant arithmetic (LRA) est ainsi introduit pour désigner ces techniques. Dans le papier [53], Guillermin adapte la LRA pour les extensions de base de type CRT (dans [11] le MRS est utilisé), et les pré-calculs qui y sont associés. On y trouve aussi la première implantation de la LRA sur FPGA (menant à un surcoût de 15 % en surface et 6 % en temps). Enfin, l’article [94], de Perin et al., propose une implantation du tirage aléatoire des bases avant exponentiation LRA et une implantation d’une autre contre mesure, la permutation des éléments internes à chacune des bases Ba et Bb. Ces contre-mesures ont été ensuite attaquées par rayonnement électromagnétique afin d’évaluer leur sécurité pour ce type de canal caché. D’après leurs résultats, ces contre-mesures sont très peu coûteuses et améliorent significativement la résistance à certaines attaques sur le rayonnement électromagnétique.1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 65 CLB BRAM plot E/S DCM bloc DSP Figure 1.10 – Architecture générique d’un FPGA. Enfin, des propositions utilisant un modulo supplémentaire ou le Cox ont été proposées pour protéger les implantations RNS contre certaines attaques de type injection de faute. Ciet et al. [29] proposent l’utilisation d’un modulo supplémentaire pour vérifier si, à la fin de l’exponentiation, le résultat n’est pas plus grand que ce qui est attendu (par exemple inférieur à 3P). Guillermin [53] propose lui de détecter les fautes pour toutes les multiplications modulaires en transformant le Cox. La contribution de Bajard et al. [9] propose aussi une technique de détection de fautes pour chaque réduction modulaire, mais ne force pas l’utilisation d’une architecture Cox-Rower. De plus, un modèle de fautes plus fin est utilisé suivant le moment où la faute se produit. Les contributions de cette thèse portant surtout sur l’amélioration de l’efficacité des calculs en RNS, ces questions ne seront pas plus approfondies. On notera toutefois que ces contre-mesures ne sont qu’un arsenal de protections supplémentaires, en plus des protections au niveau de la multiplication scalaire comme celles de Coron [33] (randomisation du point de base en coordonnées projectives, masquage du point de base ou masquage de la clé) ou des protections matérielles comme des logiques avec moins de variation de consommation de courant [76, 122]. À propos des circuits FPGA Les implantations réalisées dans cette thèse ont été effectuées sur FPGA (pour field programmable gate array), comme bon nombre d’implantations cryptographiques de la littérature, notamment en RNS comme le montre la table 1.6. Dans cette dernière section consacrée aux implantations, nous rappelons ici quelques informations sur les FPGA. Les FPGA sont un type de circuit intégré complètement programmable après leur fabrication (ils ont une architecture dite configurable et souvent reconfigurable un grand66 CHAPITRE 1. ÉTAT DE L’ART nombre de fois). Ces technologies sont très avancées (finesse de gravure de 28 nm pour les Virtex 7 et Stratix V, introduits en 2010), et sont beaucoup plus accessibles que les ASIC (application-specific integrated circuit) qui demandent un énorme investissement dans la conception et la fabrication. Les délais de fabrication chez le fondeur pouvant être importants (plusieurs mois), la conception et le test sur FPGA sont beaucoup plus rapides à effectuer, et nécessitent beaucoup moins de personnel. Ces circuits sont fabriqués en grand volume et coûtent de quelques euros à plusieurs milliers d’euros. Ces prix font que les FPGA sont plus rentables que les ASIC pour les petites séries, les circuits ASIC ne deviennent rentables que pour de très grands volumes. Les FPGA sont aussi utilisés pour faire du prototypage. Les FPGA offrent donc une possibilité de mise sur le marché rapide, mais, en contrepartie, consomment plus d’énergie que les ASIC, pour des performances moins élevées. Ceci est dû aux mécanismes permettant la configuration du FPGA. Enfin, ces produits fournissent les très bonnes performances du matériel avec les avantages d’une configuration logicielle, on les retrouve donc dans de nombreuses applications (calcul hautes performances, réseaux sans fil, imagerie médicale, dispositifs de sécurité, etc). Une bonne introduction aux FPGA peut être trouvée dans [111]. Un FPGA peut être vu comme un tableau de portes logiques (d’où son nom). Une mémoire va être alors directement programmée par l’utilisateur, qui va définir les fonctionnalités des différents blocs ainsi que leurs interconnexions. La figure 1.10 présente l’architecture générique d’un FPGA. On y voit une large matrice composée de blocs logiques configurables (CLB pour configurable logic bloc), de blocs d’entrées/sorties et de blocs de génération d’horloge programmable (DCM pour digital clock manager ). Prenons l’exemple des FPGA Xilinx Virtex 5, sur lesquels les implantations de cette thèse ont été faites. Sur Virtex 5, un CLB est composé de deux slices, qui sont les blocs de base des FPGA Xilinx. Pour cette famille de FPGA, chaque slice est composé de 4 LUT à 6 entrées (ou table de correspondance, look-up table en anglais) et de 4 bascules. Très souvent, d’autres types de blocs spécifiques cassent l’homogénéité d’une telle architecture pour gagner en performance ou en consommation d’énergie. Par exemple, on trouve fréquemment des BRAM, blocs de mémoire RAM ou encore des blocs arithmétiques optimisés (généralement optimisés pour les calculs de traitement du signal, appelés blocs DSP). Chez Xilinx par exemple, les blocs DSP sur Virtex 5 contiennent un multiplieur-accumulateur, permettant d’effectuer des multiplications 18 × 25 bits et des les accumuler sur 48 bits, ou d’effectuer un simple multiplication ou addition (voir figure 1.11, issue de [2], page 14). Un exemple provenant du concurrent Altera est lui présenté dans la figure 1.12 issue de [1] (chapitre 7, page 5). Ce bloc là, présent dans les Stratix 3, contient 4 multiplieurs 18 × 18 bits sur chacune de ses moitiés, et toujours des fonctions d’additions et d’accumulations. Les Rowers vont en fait combiner ces blocs dans l’unité arithmétique qu’ils intègrent. Par contre, la possibilité de pouvoir configurer et reconfigurer tous ces blocs a un coût. Tous les composants d’interconnexion (ces nœuds ne sont pas représentés sur la fi- gure 1.10) sont ajoutés par rapport à un circuit non reconfigurable. Ceux-ci impliquent une perte de performances (en énergie et fréquence d’horloge) ainsi qu’une perte de surface. D’après [111], la surface totale occupée pour ce routage et la mémoire de configuration représente 90 % de la surface du FPGA. De plus, les fréquences de fonctionnement des FPGA ne dépassent pas quelques centaines de MHz, contre les GHz des microprocesseurs. Par contre, les FPGA peuvent contrebalancer cette différence de fréquence et être plus1.3. LA REPRÉSENTATION MODULAIRE DES NOMBRES (RNS) 67 14 www.xilinx.com Virtex-5 FPGA XtremeDSP Design Considerations UG193 (v3.5) January 26, 2012 Chapter 1: DSP48E Description and Specifics R Architectural Highlights The Virtex-5 FPGA DSP48E slice includes all Virtex-4 FPGA DSP48 features plus a variety of new features. Among the new features are a wider 25 x 18 multiplier and an add/subtract function that has been extended to function as a logic unit. This logic unit can perform a host of bitwise logical operations when the multiplier is not used. The DSP48E slice includes a pattern detector and a pattern bar detector that can be used for convergent rounding, overflow/underflow detection for saturation arithmetic, and auto-resetting counters/accumulators. The Single Instruction Multiple Data (SIMD) mode of the adder/subtracter/logic unit is also new to the DSP48E slice; this mode is available when the multiplier is not used. The Virtex-5 DSP48E slice also has new cascade paths. The new features are highlighted in Figure 1-2. Figure 1-1: Virtex-5 FPGA DSP48E Slice X 17-Bit Shift 17-Bit Shift 0 Y Z 1 0 0 48 48 18 4 3 48 25 30 BCOUT* BCIN* ACIN* OPMODE PCIN* MULTSIGNIN* PCOUT* CARRYCASCOUT* MULTSIGNOUT* CREG/C Bypass/Mask CARRYCASCIN* CARRYIN CARRYINSEL ACOUT* A:B ALUMODE B B A C B M P P P C 25 X 18 A A PATTERNDETECT PATTERNBDETECT CARRYOUT UG193_c1_01_032806 4 7 48 48 30 18 30 18 P P *These signals are dedicated routing paths internal to the DSP48E column. They are not accessible via fabric routing resources. Figure 1.11 – Schéma de bloc DSP Virtex 5 issu de [2]. rapides pour de nombreuses applications grâce au fait qu’ils permettent une implantation spécifique à l’application, souvent parallèle, et à grain fin (architecture au bit près). Les FPGA sont souvent présentés comme une solution intermédiaire entre une solution purement logicielle, peu chère en développement mais plus faible en performances, et une solution de type ASIC, très chère en développement mais très performante. La programmation d’un FPGA se fait par un grand nombre de configurations de mé- moires pour effectuer la fonction souhaitée. Cette configuration va permettre de programmer les LUT, les blocs arithmétiques (DSP), l’initialisation des mémoires et les connexions qui relient tous ces composants. Le concepteur va en fait utiliser des outils de CAO qui permettront de transformer une implantation en langage de description matérielle (HDL) en un flot binaire appelé bitsream qui sera chargé dans le FPGA pour le programmer. Dans cette thèse, les travaux d’implantation ont été effectués en langage VHDL. Ce langage permet de décrire au niveau RTL (register transfer level) l’architecture en cours de conception. Autrement dit, on programme en utilisant des fonctions combinatoires de base (fonctions arithmétiques, logiques, multiplexeur, etc), des fonctions synchrones (la mémoire, les registres, les bascules) et en décrivant les signaux qui les relient. Ce code est ensuite synthétisé par un outil tel que l’outil ISE de Xilinx ou Quartus d’Altera. Il sera analysé par l’outil qui extraira les blocs arithmétiques pour utiliser les ressources adéquates (avec une utilisation, ou non des blocs DSP par exemple), puis simplifiera les équations logiques suivant les options d’optimisation activées (optimisation temps ou surface). Cette analyse effectuée, l’outil passera à une étape de transformation technologique afin de faire correspondre les blocs à des instances matérielles existantes sur le FPGA, en essayant de tenir68 CHAPITRE 1. ÉTAT DE L’ART Chapter 5: DSP Blocks in Stratix III Devices 5–7 Simplified DSP Operation © March 2010 Altera Corporation Stratix III Device Handbook, Volume 1 Figure 5–5. Stratix III Full DSP Block Summary Input Register Bank Pipeline Register Bank Adder/Accumulator Output Multiplexer Output Multiplexer Round/Saturate Output Register Bank + + From Previous Half-Block DSP To Next Half-Block DSP 44 44 Input Data 144 + Input Register Bank Pipeline Register Bank Adder/Accumulator Round/Saturate Output Register Bank + + Input Data 144 + Top Half-DSP Block Bottom Half-DSP Block Result Result Figure 1.12 – Schéma de bloc DSP Stratix III issue de [1]. compte au mieux des contraintes imposées. Enfin le placement et le routage vont placer ces unités sur les blocs du FPGA et les relier en utilisant les différentes ressources de routage. Afin de simuler le comportement du code VHDL implanté, du code VHDL spécifique peut être utilisé (du code non synthétisable) pour écrire un banc d’essais. Le comportement est alors simulé par des logiciels tels que ModelSim ou Isim.Chapitre 2 Inversion modulaire rapide en RNS Dans certaines implantations matérielles cryptographiques utilisant le RNS, comme ECC [45, 52, 104] ou encore les couplages [27, 127] une ou des inversions modulaires sont nécessaires. Par exemple, dans le cas des courbes elliptiques, nous avons besoin d’au moins une inversion finale afin de normaliser en affine les coordonnées du point obtenu lors de la multiplication scalaire. Les unités de calcul modulaire sur de grands nombres étant implantées en RNS à des fins de performances, on les utilise aussi pour faire cette ou ces inversions. Cependant cette opération reste très coûteuse en RNS, même devant le coût d’une multiplication scalaire. En effet, nous allons voir que nous pouvons estimer que dans le cas du RNS, l’inversion coûte entre 10 et 20% du coût de la multiplication scalaire complète. Dans le cas des couplages, il est dit par exemple dans [27] « the remaining inversion in Fp is very expensive » à propos de l’inversion RNS. Dans ce chapitre sont présentés les résultats publiés dans [19], ainsi qu’une extension en cours de soumission à un journal. Un nouvel algorithme d’inversion RNS est présenté, permettant de réduire très significativement le nombre d’opérations élémentaires, aussi bien que le temps d’exécution sur nos implantations FPGA en section 2.2. Ensuite, une variante de cet algorithme menant à une réduction de 30 % de EMM (multiplication modulaire élémentaire de w bits) et de 20 % de EMA (addition modulaire élémentaire) est présentée en section 2.3. Les sections suivantes proposent une comparaison avec l’état de l’art en section 2.4 ainsi que les détails d’implantations et les résultats obtenus en section 2.5. 2.1 Inversion modulaire RNS dans l’état de l’art Dans quasiment toutes les implantations RNS de l’état de l’art (en tout cas en maté- riel), l’algorithme utilisé pour calculer l’inversion modulaire est une adaptation en RNS du calcul de l’exponentiation utilisant le petit théorème de Fermat. L’algorithme 16 présente une façon de faire cette inversion, que nous avons ici modifiée en une version bit de poids faible en premier (LSBF pour least significant bit first) de l’exponentiation RNS de l’état de l’art [48]. On rappelle que le but de l’algorithme est de calculer AP −2 mod P ce qui est égal à A−1 mod P d’après le FLT. L’algorithme met en œuvre les optimisations présentées dans la section 1.3.3 provenant de [48], on se place dans la représentation RNS modifiée sur la seconde base (ligne 1 de l’algorithme 16) puis on reconvertit à la fin en multipliant par −→ Tb (ligne 9). Cet algorithme, grâce à sa représentation RNS modifiée, permet d’être plus rapide en accélérant MM, comme expliqué dans la section 1.3.3. Mettre cet algorithme en version LSBF permet d’avoir la multiplication (ligne 5) et le carré (ligne 6) exécutés en parallèle. Cet algorithme sera utilisé par la suite afin de se comparer à l’état de l’art. 6970 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS Un défaut de cet algorithme d’inversion est qu’il y a beaucoup de dépendances entre les itérations de la boucle (comme dans tout algorithme d’exponentiation), ce qui limite fortement le remplissage du pipeline. Dans la suite, cette inversion modulaire RNS sera notée FLT-MI. Les auteurs de [127], qui ont obtenu parmi les meilleures performances pour une implantation FPGA de couplages et qui ont implanté FLT-MI (dans un algorithme très proche de l’algorithme 16), appuient ce constat en écrivant : « The problem with this exponentiation in Fp is that the computation cannot be pipelined [. . . ] causes low pipeline occupation rate and a huge waste. » Une exponentiation comme l’algorithme 16 représente environ 10 à 20% du coût d’une multiplication scalaire complète sur courbe elliptique (en terme d’effort de calcul). En effet, on peut approcher le coût global en ne considérant que les réductions modulaires, tant le déséquilibre est important en RNS entre cette opération et les autres opérations de base. Ainsi, FLT-MI coûte environ log2 P × 1.5 réductions modulaires. Dans la contribution [52], des formules adaptées pour le RNS sont utilisées avec moins de réductions modulaires, et avec l’algorithme de multiplication scalaire « échelle de Montgomery » (voir algorithme 22 protégé contre la SPA dans la section 3.2.1 par exemple). Pour chaque bit de clé, une addition et un doublement de points sont effectués, ce qui coûte 13 réductions modulaires. On a donc l’inversion qui coûte log2 P × 1.5 contre log2 P × 13 pour la multiplication scalaire, soit, ramené au système global « multiplication scalaire suivie d’une inversion », l’inversion coûte plus de 10% juste en terme d’opérations. Ce ratio peut même être plus élevé suivant le choix des formules ou de l’algorithme de multiplication scalaire. De plus, l’auteur de [52] indique que la multiplication scalaire ne contient pas ou quasiment pas de cycle d’attente (chaque ADD et DBL contient certaines opérations indépendantes, et l’utilisation d’une version LSBF de l’échelle de Montgomery fait que l’on peut réaliser en parallèle une ADD et un DBL). Comme déjà indiqué, l’inversion FLT-MI contient beaucoup de cycles d’attente, on peut donc estimer que l’inversion prend bien plus de 10% du temps total d’exécution de la séquence multiplication scalaire/inversion. Malgré tout, cet algorithme a l’avantage d’être très régulier et de n’utiliser que des ressources matérielles déjà présentes et déjà optimisées pour les autres calculs. De plus, le fait d’effectuer l’opération en RNS permet de ne pas avoir d’un côté tout le matériel dédié au calcul RNS inactif pendant l’inversion, et de l’autre de gros opérateurs arithmétiques de plusieurs centaines de bits en représentation standard juste pour le temps de l’inversion. En dehors de l’algorithme FLT-MI, peu d’alternatives s’offrent à ceux qui désirent implanter l’inversion modulaire en RNS. Les autres solutions dont nous disposons dans le cas standard, c’est à dire l’algorithme d’Euclide étendu et sa version binaire, ont souvent été mises de côté du fait de la difficulté des opérations telles que la division ou la comparaison, comme en témoigne par exemple N. Guillermin dans sa thèse [54], où il écrit : « En effet, la comparaison étant chère en RNS, l’inversion ne peut pas être réalisée par le classique algorithme d’Euclide étendu, mais par une exponentiation onéreuse par p − 2 ». Une alternative a été proposée dans [13], se basant sur l’algorithme d’Euclide. Les auteurs proposent une façon d’obtenir une approximation U3/V3 du quotient ligne 5 de l’algorithme 10, à partir d’approximations de U3/M et V3/M (M est le produit des moduli de la base). Malheureusement, cet algorithme n’a, à notre connaissance, jamais été implanté et sa complexité jamais évaluée. En effet, la fonction de base de l’algorithme permettant l’approximation de U3/M, appelée ApproxSup, n’a pas été évaluée. Cependant, elle est composée d’une accumulation de produits, qui est donc peu parallélisable,2.1. INVERSION MODULAIRE RNS DANS L’ÉTAT DE L’ART 71 Algorithme 16: Inversion modulaire FLT-MI basée sur le petit théorème de Fermat (version LSBF de [48]). Entrées : −−→ Aa|b , P − 2 = (1 p`−2 . . . p0)2 Pré-calculs : P, −−−−−−→ (|Ma|P )a , −−−−−−−−−→ (|Ma|P T −1 b )b , −−−−−−→ (|M2 a |P )a , −−−−−−−−−→ (|M2 a |P T −1 b )b , −→ Tb , −−−−→ (Tb) −1 Sortie : −−→ Sa|b = −−−−−−−→ (|AP −2 |P ) a|b 1 −−→ Ra|b ← ( −→ Aa , −−−−−−−−→ (Ab · T −1 b )b ) 2 −−→ Ra|b ← MM  −→ Ra , −→ Rb , −−−−−−→ (|M2 a |P )a , −−−−−−−−−→ (|M2 a |P T −1 b )b  3 −−→ Sa|b ← ( −−−−−−→ (|Ma|P )a , −−−−−−−−→ (|Ma|P Tb)b ) 4 pour i de 0 à ` − 2 faire 5 si pi = 1 alors −−→ Sa|b ← MM( −→ Sa , −→ Sb , −→ Ra , −→ Rb ) 6 −−→ Ra|b ← MM( −→ Ra , −→ Rb , −→ Ra , −→ Rb ) 7 −−→ Sa|b ← MM( −→ Sa , −→ Sb , −→ Ra , −→ Rb ) 8 −−→ Sa|b ← MM( −→ Sa , −→ Sb , −→ 1a , −−−−→ (Tb) −1 ) 9 −→ Sb ← −−−−→ Sb · Tb 10 retourner −−→ Sa|b notamment peu adaptée à une architecture complètement parallélisée comme souvent le cas dans les architectures RNS pour la cryptographie. De plus, cette accumulation est faite sur des mots de 2w bits, c’est à dire la taille de deux moduli (ce qui implique une unité spécialisée, ou alors créer des paires de modulo capables d’effectuer des opérations sur 2w bits). Une autre fonction, appelée NormalSup, fait ensuite plusieurs appels à ApproxSup. Ce nombre d’appels n’est pas clairement identifié dans la contribution (l’appel s’effectue dans une boucle while). Enfin, l’impact de telles approximations sur le nombre de tours de boucle principale de l’algorithme d’Euclide étendu n’a pas été évalué, les auteurs expliquant en conclusion qu’une évaluation de l’algorithme est nécessaire. Pour conclure, ces raisons laissent penser qu’une implantation de cet algorithme serait coûteuse, notamment en terme de temps d’exécution sur une architecture parallèle et en terme de matériel supplémentaire. Enfin, l’article [72] propose une implantation sur microprocesseur d’ECC en RNS. Dans cette contribution est évoquée une adaptation RNS de la variante binaire d’Euclide (algorithme 11). Aucun détail n’est fourni sur cette adaptation logicielle, hormis le fait qu’elle résulte en une inversion presque 2 fois plus rapide (réduction du temps d’exécution de 48%). Pour conclure sur cet état de l’art, l’algorithme de Fermat propose en matériel un algorithme facile à implanter, réutilisant directement les opérateurs présents, à la différence d’une implantation matérielle d’un algorithme d’Euclide étendu ou sa variante binaire (par exemple pour les comparaisons). De plus, ces algorithmes sont en O(log2 P) (c.-à-d. O(`)) itérations de la boucle principale, la différence se situe surtout dans le coût d’une itération de cette boucle. Cette différence ne semble pas forcément en défaveur du FLT-MI à cause du coût des comparaisons ou divisions en RNS. Pour toutes ces raisons, la seule vraie proposition matérielle de l’état de l’art est l’implantation du FLT-MI.72 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS 2.2 Inversion modulaire plus-minus en RNS Notre algorithme d’inversion modulaire en RNS est basé sur l’algorithme d’Euclide étendu en version binaire, avec l’utilisation de l’astuce plus-minus [22] (présentée section 1.2.3). Cette astuce va nous permettre d’éviter les comparaisons sur les valeurs RNS. L’algorithme obtenu est significativement plus rapide que les inversions basées sur le FLT. De plus, notre algorithme, comme les solutions basées sur le FLT, va principalement réutiliser les ressources matérielles qui sont requises pour les calculs sur les corps finis, comme l’addition, la soustraction ou la multiplication, menant à un très faible surcoût en surface, et donc à une haute efficacité architecturale ; il n’y a pas de grosses unités dédiées inactives pour les autres calculs. Nous allons voir que notre proposition ne nécessite qu’une seule base RNS, au lieu de deux dans l’état de l’art. Pour simplifier les notations, on considérera parfois de façon implicite que les valeurs sont dans la base Ba. L’algorithme 17 a été publié dans [19] (conférence CHES 2013). Le but de l’algorithme d’Euclide étendu binaire est d’utiliser le fait que l’on soit capable d’effectuer des divisions par 2 et des modulo 2 très efficacement (vu que l’on va utiliser le plus-minus, il faut savoir faire de même pour 4). Si c’est évident en représentation binaire de position, ceci l’est beaucoup moins dans la représentation RNS. En RNS, on peut se placer dans 3 stratégies. Première stratégie, on choisit un élément mγ premier avec la base Ba tel qu’il soit un multiple de 4 (par exemple mγ = 2w avec w > 1). Ainsi, la réduction modulo 4 devient très simple : il suffit de tester les 2 derniers bits du reste de la valeur testée en mγ. Cependant, dans ce cas, on ne peut pas diviser par 2 ou 4 modulo mγ. Pour récupérer le résultat d’une division par 4, on réalise d’abord la division dans la base Ba, qui est choisie impaire, en effectuant une multiplication par 4 −1 mod Ma. Ensuite, on envoie le résultat dans mγ grâce à une extension de base à partir de Ba. On doit donc calculer la formule du CRT pour mγ : |X|mγ =      Xn i=1 ξa,i ·     Ma ma,i     mγ − |q · Ma|mγ      mγ . Cette accumulation là n’est pas parallèle, elle prendra donc n cycles sur un Rower (bloc d’arithmétique modulaire de w bits, voir la figure 1.9 section 1.3.5). On peut paralléliser une partie de ces cycles avec les calculs sur la base Ba si un Rower dédié au modulo mγ est rajouté (engendrant un Rower qui ne sera utilisé que pour l’inversion). L’autre possibilité est de réserver un Rower d’un autre modulo lorsqu’on en a besoin, ce qui veut dire que toute l’architecture attend ces n cycles dans le cas d’une architecture complètement parallèle. Par soucis de simplicité du contrôle, on préfère garder les calculs sur les différents canaux de la base Ba synchronisés. La deuxième stratégie est de choisir directement un élément de Ba, par exemple ma,1, égal à 2 w. L’idée est que lorsque l’on calcule −→ U /2 dans Ba, on va faire notre multiplication par l’inverse de 2 dans tous les moduli de Ba sauf ma,1, dans lequel on va juste faire un décalage. Ce décalage est une division par 2 du reste de U modulo 2, mais n’est pas une division par 2 modulo 2 w. Pour bien expliquer le phénomène, posons U un entier pair et2.2. INVERSION MODULAIRE PLUS-MINUS EN RNS 73 Algorithme 17: Inversion modulaire plus-minus proposée PM-MI (version binaire). Entrées : −→ A , P > 2 avec pgcd(A, P) = 1 Pré-calculs : −→ C , −−→ C/2 , −−−−−→ (3 C/4) , −−−−−−−→ (P T −1 a )/4 , −−−−−−−−→ (−P T −1 a )/4 , −−−−−−−→ (P T −1 a )/2 , −→ Ta , −−→ T −1 a , |P|4 Sortie : −→ S = −−−−−→ |A−1 |P , 0 6 S < 2 P 1 lu ← 0, Uc1 ← −→ C /* Uc1 = b0 */ 2 Uc3 ← −→ P × −−→ T −1 a + −→ C /* Uc3 = Pb*/ 3 bU1 ← 0, bU3 ← |P|4 4 lv ← 0, Vc1 ← −−→ T −1 a + −→ C /* Vc1 = b1 */ 5 Vc3 ← −→ A × −−→ T −1 a + −→ C /* Vc3 = Ab */ 6 bV1 ← 1, bV3 ← mod4(Vc3) 7 tant que Vc3 6= b1 and Uc3 6= b1 and Vc3 6= −c1 and Uc3 6= −c1 faire 8 tant que |bV3 |2 = 0 faire 9 si bV3 = 0 alors r ← 2 sinon r ← 1 10 Vc3 ← div2r \(Vc3, r, bV3 ) 11 Vc1 ← div2r \(Vc1, r, bV1 ) 12 bV3 ← mod4(Vc3), bV1 ← mod4(Vc1), lv ← lv + r 13 Vc∗ 3 ← Vc3 , Vc∗ 1 ← Vc1 14 si |bV3 + bU3 |4 = 0 alors 15 Vc3 ← div2r \(Vc3 + Uc3 − −→ C , 2, 0), 16 Vc1 ← div2r \(Vc1 + Uc1 − −→ C , 2, |bV1 + bU1 |4) 17 sinon 18 Vc3 ← div2r \(Vc3 − Uc3 + −→ C , 2, 0), 19 Vc1 ← div2r \(Vc1 − Uc1 + −→ C , 2, |bV1 − bU1 |4) 20 si lv > lu alors 21 Uc3 ← Vc∗ 3 , bU3 ← bV3 22 Uc1 ← Vc∗ 1 , bU1 ← bV1 23 swap(lu, lv) 24 bV3 ← mod4(Vc3), bV1 ← mod4(Vc1) 25 lv ← lv + 1 26 si Vc3 = b1 alors retourner (Vc1 − −→ C ) −→ Ta + −→ P 27 sinon si Uc3 = b1 alors retourner (Uc1 − −→ C ) −→ Ta + −→ P 28 sinon si Vc3 = −c1 alors retourner −(Vc1 − −→ C ) −→ Ta + −→ P 29 sinon retourner −(Uc1 − −→ C ) −→ Ta + −→ P74 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS posons Ku et ru tels que U = Kuma,1 + ru = Ku2 w + ru. Nous obtenons :    U 2 = Ku 2 2 w + ru 2 = Ku 2 ma,1 + ru 2 si Ku pair , U 2 = Ku 2 w−1 + ru 2 = Ku ma,1 2 + ru 2 si Ku impair , (2.1) si nous divisons U par 2. Si Ku est pair alors on a bien ru 2 = | U 2 |ma,1 . Par contre, si Ku est impair ru 2 = | U 2 |ma,1/2 , il nous manque le bit de poids fort. Ce n’est pas forcé- ment un problème car si U est représentable dans Ba (c’est à dire pas de dépassement de la représentation en base Ba), alors U/2 est représentable dans cette nouvelle base Ba = (ma,1/2, ma,2, . . . , ma,n). À chaque division par 2, le premier modulo de la base Ba sera ainsi « divisé par 2 », jusqu’à ce que ma,1 = 1. Calculer Ku pour chaque division coû- terait trop cher, c’est pourquoi il faut diviser par 2 la valeur ma,1 pour considérer tout le temps le pire cas (impair) de l’équation 2.1. Lorsque ma,1 = 1, on doit faire une extension de base à partir des moduli « fixes » de la base Ba, c’est à dire (ma,2, . . . , ma,n), vers 2 w, ce qui permet de remettre ma,1 à sa valeur initiale. On peut remarquer qu’en réalité, si on divise par 2 une certaine valeur U et par une autre V alors ces 2 valeurs ne seront pas représentées tout à fait sur la même base : le premier élément de Ba sera ma,1/2 pour l’un et ma,1 pour l’autre. Il faut donc associer un compteur à chaque donnée traitée dans l’algorithme afin de savoir exactement dans quelle base elle est représentée. L’avantage de cette deuxième solution par rapport à la première vient du fait qu’elle nécessite beaucoup moins d’extensions de base vers le modulo valant 2 w. De plus, le modulo 2 w est directement inclus dans la base Ba, et n’est pas un modulo supplémentaire. Par contre, cette solution impose un contrôle complexe pour gérer le fait que ma,1 change suivant le nombre de divisions par 2. De plus, dans un algorithme d’Euclide étendu binaire, il faut effectuer des opérations du type (U + V )/2. Pour pouvoir faire la somme, il faut que U et V soient représentés de la même façon (c’est à dire après le même nombre de divisions par 2). Si ce n’est pas le cas, il faut que celui qui ait été le plus été divisé, disons U, soit étendu pour être représenté dans la même base que V . Cette extension arrive alors avant qu’on ait ma,1 = 1 pour la valeur U, elle est en quelque sorte « prématurée » car l’extension de base aurait pu arriver plus tard s’il n’y avait pas eu le calcul de l’opération (U + V )/2. Pour finir, la troisième stratégie est celle que nous avons retenue. Elle consiste à choisir une base sans aucun modulo pair, ainsi les divisions (exactes) par 2 et 4 sont très faciles. En contrepartie, il faut trouver un moyen d’obtenir efficacement nos valeurs modulo 2 et 4. L’algorithme 17 présente la méthode proposée. Avant de définir précisément les différentes fonctions et notations de l’algorithme, on peut remarquer tout de suite que l’on retrouve la structure de l’algorithme d’Euclide étendu binaire, avec le test plus-minus modulo 4 en ligne 14. Tout d’abord, notre algorithme prend en entrée la valeur à inverser −→ A , et retourne l’inverse de cette valeur dans [0, 2P] (comme pour les valeurs de sortie des multiplications de Montgomery). Il faut noter que notre inversion ne tient pas compte du fait que l’entrée est en représentation de Montgomery ou non. Si c’est le cas, il suffit de multiplier notre entrée par M−2 a modulo P avant d’appliquer notre algorithme, pour obtenir l’inverse dans la représentation de Montgomery. Ensuite, l’algorithme utilise des valeurs dans une repré- sentation Xb, que l’on peut voir comme une fonction affine appliquée à la représentation RNS habituelle de −→ X . Celle-ci sera définie dans les détails sur les fonctions mod4 et div2r \.2.2. INVERSION MODULAIRE PLUS-MINUS EN RNS 75 Avant le début de la boucle principale, on retrouve la même initialisation que pour l’algorithme 11 dans sa version RNS, avec quelques petits rajouts. Les variables lu et lv vont permettre de compter le nombre de fois que U3 et V3 respectivement ont été divisés par 2. C’est ce qui permet aux méthodes utilisant l’astuce plus-minus de faire en sorte que l’algorithme converge bien. Ensuite, les valeurs bU1 , bU3 , bV1 et bV3 stockent tout simplement leur valeur en indice modulo 4. La boucle principale se termine lorsque l’une des valeurs Uc3 ou Vc3 vaut 1 en valeur absolue. Comme pour l’algorithme d’Euclide étendu binaire, on a toujours |U1A|P = U3 et |V1A|P = V3, donc si par exemple Uc3 = −c1 alors −U1 est bien l’inverse de A modulo P. Après la boucle principale, suivant la raison de la terminaison de la boucle, on convertit la valeur Uc3 ou Uc3 en représentation RNS classique. Dans la suite, nous écrirons valeurs globales pour évoquer les valeurs Vc1, Vc1, Uc3 et Vc3. Pour détailler la boucle principale (lignes 7–25), nous allons maintenant définir nos fonctions de base mod4 et div2r \. Comme expliqué précédemment, dans le cas d’une base avec seulement des éléments impairs, la réduction modulo 4 n’est pas facile, à la différence d’une représentation binaire de position. Pour ce faire, on va repartir du théorème chinois des restes X = Pn i=1 ξa,i Ma ma,i − qMa toujours avec ξa,i =     xa,i  Ma ma,i −1     ma,i et q = Pn i=1 ξa,i Ma ma,i Ma  . Si nous prenons modulo 4 la formule du CRT, on obtient : |X|4 =      Xn i=1 |ξa,i|4 ·     Ma ma,i     4 − |q · Ma|4      4 . (2.2) Pour faciliter ce calcul, on va choisir une base Ba telle que |ma,i|4 = 1 pour tous les moduli. En fait, en dehors de l’unique modulo pair s’il y en a un, les éléments de la base valent 1 ou 3 modulo 4. Dans les implantations cryptographiques de l’état de l’art, deux bases sont toujours choisies pour pouvoir effectuer les réductions modulaires. On a donc déjà en moyenne n moduli tels que |ma,i|4 = 1, cette contrainte n’en est donc pas vraiment une, ou alors très faible. L’équation 2.2 devient : |X|4 =      Xn i=1 |ξa,i|4 − |q|4      4 . (2.3) La fonction mod4 va calculer l’équation 2.3, en évaluant les deux termes | Pn i=1 ξa,i| 4 et  |q|4 puis en les soustrayant modulo 4. Pour calculer le premier terme, les n EMM ξa,i =    xa,i  Ma ma,i −1     ma,i doivent être effectuées. En réalité, elles peuvent être effectuées une seule fois, au début de l’algorithme. Calculer ces n produits pour une valeur −→ X est en fait le calcul du produit RNS −→ X × −−→ T −1 a . Il se trouve qu’une fois cette multiplication faite pour toutes les valeurs globales, toutes les autres opérations faites sont des additions de valeurs globales (ou de pré-calculs) et des divisions par 2 et 4. Le facteur −−→ T −1 a est donc bien conservé tout au long de l’algorithme (on peut remarquer que c’est la première partie de la représentation Xb). Finalement, le calcul de ce premier terme se résume à une somme des n composantes de Xb modulo 4. Le calcul du second terme q se base, pour des raisons d’efficacité matérielle, sur l’approximation proposée par Kawamura et al. dans [64] et présentée en section 1.3.2. On76 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS calcule donc : q 0 = $ σ0 + Xn i=1 trunc(ξa,i) 2 w % , (2.4) toujours avec trunc qui approche son opérande par ses t bits de poids forts (les autres étant mis à 0). Comme expliqué précédemment, t dépend des bases et de P, mais dans nos implantations FPGA et tailles de corps, t sera fixé à 6. Nous n’allons pas détailler au cas par cas pour chacune des bases la raison qui fait que c’est une valeur suffisante, mais donner un argumentaire qui fonctionne pour toutes nos bases. Pour appliquer le théorème 5 présenté à la section 1.3.2, on doit avoir εmax < σ0 < 1. Généralement dans l’état de l’art, on a σ0 = 0.5 (voir [52, 64]). On rappelle que εmax est l’erreur maximale que peut causer l’utilisation de l’approximation de Kawamura et al. [64], définie par εmax = n(τ + δ). On rappelle aussi que τ représente l’erreur due à l’utilisation de la fonction trunc et δ représente l’erreur faite en approximant les moduli par 2 w. Dans nos implantations, (τ +δ) est proche de 1 2 t car les moduli ont été choisis très proches de 2 w. Ainsi, pour t = 6 on a (τ +δ) ≈ 1 64 . Le plus grand n implanté est n = 22 (voir la table 5.5), donc εmax ≈ 22 64 < 0.5, donc on peut appliquer le théorème 5 de Kawamura et al. même pour notre plus grand n. On peut maintenant remarquer que les valeurs ξa,i ont déjà été calculées grâce à la représentation Xb. De plus, les auteurs de [64] ont prouvé que q 0 = q lorsque 0 6 n · errmax 6 σ0 < 1 et 0 6 X 6 (1 − σ0)Ma avec errmax désignant l’erreur d’approximation maximale. Autrement dit, il faut que le produit Ma des éléments de la base soit suffisamment grand devant X, l’élément pour lequel on calcule le CRT, pour « contenir » l’erreur d’approximation. Il faut donc d’abord borner les valeurs qui sont traitées (classiquement par P où un petit multiple de P pour les besoins de la réduction modulaire ou les calculs sur les courbes), puis définir une base pour que le théorème soit satisfait. Dans le résultat [52] de l’état de l’art de l’implantation ECC en RNS, les paramètres choisis sont Ma > 45P, 0 6 X < 3P et σ0 = 0.5. Nous nous placerons dans ce cas pour nos implantations. Pour conclure, le calcul de q coûte n additions de t bits pour évaluer l’équation 2.4. Nous avons alors au total n additions de t bits et n additions de mots de 2 bits pour évaluer l’intégralité de l’équation 2.3. À la différence de l’algorithme d’Euclide étendu binaire, les valeurs globales peuvent être négatives à cause des soustractions lignes 18 et 19 de l’algorithme 12, dues à l’astuce plus-minus. Si S = V3 − U3 est négatif par exemple, alors puisque le CRT est pris modulo Ma, la représentation de S en RNS sera en réalité −−−−−→ Ma − S . Si par exemple S = −1 alors sa représentation est −−−−−→ Ma − 1 , on obtient donc un vecteur représentant un nombre arbitrairement proche de Ma. Or il nous faut garantir X 6 (1 − σ0)Ma pour garantir le résultat de l’approximation de Kawamura et al. équation 2.4. Nous avons donc introduit une constante additive dans la représentation Xb afin de résoudre ce problème. Toutes les valeurs globales de notre algorithme PM-MI sont assurées d’être supérieures à −P. L’idée est donc de choisir une constante C0 telle que |C0|4 = 0 et C0 > P, ainsi on a X +C0 > 0 et |X +C0| = |X|4. On peut par exemple choisir C0 = 4P, ainsi nos conditions sont réunies et le résultat est toujours juste modulo P. Plus exactement, si l’algorithme retourne X + C0, on a le bon résultat modulo P, mais dans l’intervalle [3P, 5P] au lieu de [0, 2P] (nous avons quand même effectué la correction à la fin de notre algorithme 12). Nous avons maintenant toutes les briques pour construire notre représentation : Xb = ( −→ X + −→ C0 ) × −−→ T −1 a = −→ X × −−→ T −1 a + −→ C ,2.2. INVERSION MODULAIRE PLUS-MINUS EN RNS 77 où −→ C = −→ C0 × −−→ T −1 a . Cette deuxième version de l’équation sera utilisée pour simplifier certaines explications futures. La représentation Xb permet finalement, d’une part, d’économiser les multiplications par −−→ T −1 a tout au long de l’algorithme et, d’autre part, de toujours être dans l’intervalle adéquat pour effectuer l’approximation de q et être efficace en matériel. Maintenant que nous avons réglé la question du calcul de mod4, il nous faut être capable de faire les divisions par 2 ou par 4 modulo P, tout en conservant la représentation Xb tout au long de l’algorithme. La définition de div2r \ dépend de la valeur |P|4. Nous allons considérer par exemple que |P|4 = 3. La fonction div2r \ a 3 entrées, Xb, r et bX. La donnée à diviser est Xb, r permet de choisir entre une division par 2 ou par 4 et enfin bX est la valeur modulo 4 de X. En fait, l’entrée r n’est utile que pour les applications de la fonction à Vc1 ou Vc1 ± Uc1. En effet, pour V3 par exemple, on divise par 2 (resp. par 4) exclusivement lorsqu’on est divisible par 2 (resp. 4), r pourrait donc être déduit directement de bV3 . Cependant, les opérations sur V1, elles, dépendent aussi bien de r (et donc de bV3 ) que de bV1 . Supposons que r = 1, alors : div2r \(X, b 1, bX) = Xb 2 + |bx|2 · −−−−→ P T −1 a 2 + −→ C 2 (2.5) permet d’effectuer la division par 2 tout en conservant la représentation Xb. Si X est impair, le deuxième terme de l’équation 2.5, c’est à dire −−−−→ P T −1 a 2 , corrige le premier terme pour obtenir (X + P)/2. La division par 4 modulo P est un peu plus complexe mais reprend exactement le même modèle. Maintenant suit la définition générale complète de div2r \ : div2r \(X, r, b b X) = Xb 2r + f(|bX|2r) · −−−−→ P T −1 a 2r + −−−−−−−→ (2r − 1)C 2r , (2.6) où f permet de sélectionner ce qu’il faut rajouter comme multiple de −−−−→ P T −1 a 2r pour obtenir le bon résultat modulo P. Si |bX|2r ∈ {0, 1, 2}, alors f(|bX|2r) = |bX|2r, si |bX|2r = 3 alors f(|bX|2r) = −1. Ainsi on a toujours X + f(|bX|2r) · P ≡ X mod P d’une part, et |X + f(|bX|2r) · P| 2r = 0 d’autre part, ce qui nous permet de faire la division exacte par 2r. Si on a |P|4 = 1, il suffit d’échanger les valeurs de f(1) et f(3). On remarque qu’on retrouve bien l’équation 2.5 si on pose r = 1. Pour vérifier que la représentation Xb est bien conservée, on obtient en développant : div2r \(X, r, b b X) = Xb 2r + f(|bX|2r) · −−−−→ P T −1 a 2r + −−−−−−−→ (2r − 1)C 2r = −−−−−−−−→ XT −1 a + C 2r + f(|bX|2r) · −−−−→ P T −1 a 2r + −−−−−−−→ (2r − 1)C 2r = −−−−−−−−−−−−−−−−→ (X + f(|bX|2r)P)T −1 a 2r + −→ C =  d  X 2r     P . Le coût de div2r \est d’une multiplication par canal et 2 additions, soient n EMM+2n EMA. Puisque l’on additionne à notre entrée des constantes, on peut pré-calculer ces sommes là78 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS pour descendre à n EMM + n EMA (6 sommes à pré-calculer). Pour finir, nous allons maintenant détailler la boucle principale (lignes 7–25) qui est le cœur de notre algorithme. Tout d’abord, comme pour les autres algorithmes d’Euclide étendus binaires, on effectue une boucle où on divise Vc3 tant qu’il est pair. Vu qu’on a la valeur modulo 4 de Vc3, on peut directement diviser par 4 pour réduire le nombre de tours. Pour chaque division par 2 ou 4, on reporte la même opération modulo P sur la valeur Vc1. On calcule ensuite les nouvelles valeurs modulo 2 ou 4 de Vc1 et Vc3, puis on met à jour le compteur du nombre de divisions par 2 qu’on a effectué sur Vc3, c’est à dire lv. Après cette boucle, on stocke les valeurs de Vc3 et Vc1 en prévision d’un échange avec les valeurs Uc3 et Uc1. Vient ensuite le test plus-minus, qui n’appelle pas la fonction mod4, il suffit de traiter avec les valeurs bV3 et bU3 directement. On divise la somme ou la différence en conséquence, en corrigeant les entrées pour qu’elles aient le bon format pour div2r \. Par exemple, lorsque l’on calcule Vc3 + Vc1, le terme additif C est compté 2 fois : on soustrait donc le terme en trop. Ces corrections peuvent aussi être incluses dans les pré-calculs, nécessitant 8 valeurs supplémentaires. On compare finalement lv et lu pour équilibrer le nombre de divisions entre les 2 opérandes. On rappelle que ce sont des petits nombres : lu, lv < log2 P. Remarque. Le but de l’utilisation du plus-minus est initialement d’éviter les comparaisons difficiles. On les évite en réalisant des modulo 4 efficacement. Il se trouve que lorsqu’on possède une telle fonction, on pourrait penser qu’on est forcément capable de comparer 2 nombres (et d’utiliser l’algorithme d’Euclide étendu binaire en RNS). Il est vrai que si X < Y , alors le CRT effectué sur −−−−→ X − Y retourne l’entier X −Y +Ma. Puisque tous les moduli ma,i sont impairs, Ma est impair donc |X − Y + Ma|2 6= |X − Y |2. On rappelle que |X − Y |2 peut être obtenu à partir de bX et bY . Inversement, si X > Y , |X − Y +Ma|2 = |X − Y |2, ce qui nous donne un test pour comparer X et Y . Le problème est que notre fonction mod4 utilise une approximation (celle de [64]), qui ne garantit plus un résultat juste quand on calcule |X − Y + Ma|2, on ne peut donc pas faire de comparaison avec notre proposition en utilisant [64]. Si par contre on est capable d’évaluer de façon exacte le modulo en utilisant une conversion vers la représentation MRS (en utilisant [120]), alors on a plus besoin de l’astuce plus-minus, mais la fonction mod4 coûterait alors bien plus cher que celle proposée car la conversion vers le MRS coûte n(n−1) 2 EMM, et est en plus dif- ficilement parallélisable et donc non adaptée à l’architecture Cox-Rower (voir section 1.3.2). Pour conclure cette section, on peut remarquer que tout l’algorithme s’effectue sur une seule base au lieu de 2 pour l’algorithme FLT-MI. Ceci est dû au fait que l’on n’a pas besoin d’extension de base. En fait, il y a quand même une évaluation du CRT, mais réduite modulo 4, avec un coût très faible par rapport à une véritable extension. Effectuer ce petit calcul dans le Cox revient à extraire l’information minimale pour faire l’algorithme, là où une extension dans un modulo pair (comme les premières stratégies proposées) complique les calculs sans accélérer l’algorithme. Dans la section 2.4 sera fournie une évaluation du coût à partir de statistiques sur le nombre de tours de boucle. 2.3 Algorithme binaire-ternaire plus-minus en RNS L’algorithme binaire d’Euclide est basé sur la facilité des divisions par 2 et des réductions modulo 2 dans la représentation binaire. Bien que nous ayons adapté cet algorithme pour le RNS de façon efficace dans la section précédente, cette section pose la question de la possibilité d’étendre un tel algorithme vers d’autres tests de divisibilité. Un nou-2.3. ALGORITHME BINAIRE-TERNAIRE PLUS-MINUS EN RNS 79 vel algorithme d’inversion modulaire, appelé algorithme binaire-ternaire plus-minus RNS (BTPM-MI), et qui utilise des réductions modulo 3, 6 et 12 en plus de celles par 2 et 4 de la section précédente, est proposé. L’algorithme complet est présenté algorithme 18. Il n’a pas encore été implanté sur FPGA, ce qui est une première perspective de travail. Avant de présenter le nouvel algorithme, nous allons nous demander ce que sont les divisons par 2 et 4 en RNS. Ce ne sont pas simplement des décalages à la manière de la représentation binaire standard. Elles peuvent être effectuées de 2 façons différentes. La première solution consiste à multiplier par 2 −1 mod ma,i et 4 −1 mod ma,i pour chacun des ma,i, afin d’utiliser une architecture similaire à celle de l’état de l’art [52]. En effet, cette architecture peut très bien effectuer des multiplications par des constantes, comme requis pour les calculs dans ECC, mais ne possède rien de particulier pour des divisions par 2. Dans une telle architecture, diviser par 2, 6, 12, 2 ou 4 est donc aussi dur : il faut juste multiplier par l’inverse du diviseur dans chacun des ma,i. Cela induit quand même d’avoir pré-calculé les différents inverses, et donc de les stocker. Une autre solution peut être utilisée, basée sur des décalages. En effet, même si un décalage sur toute la représentation RNS n’a pas de sens (ou en tout cas pas celui que l’on recherche), on peut comprendre ce qu’il se passe au niveau de chacun des moduli. Du fait que les valeurs sur chacun des canaux soient en représentation binaire classique, on sait ce qu’est un décalage. Par contre, les calculs sur les canaux sont des calculs modulaires, c’est pour ça qu’on ne peut pas simplement décaler sur toute la longueur du vecteur RNS. Par exemple, soit ma,i impair et xa,i une valeur du canal que l’on souhaite diviser par 2. Si xa,i est pair, un décalage suffit pour effectuer la division. Si xa,i est impair, l’opération à effectuer est s = xa,i+ma,i 2 car dans ce cas s ≡ xa,i/2 mod ma,i et on a bien 0 < s < ma,i (xa,i < ma,i). Les désavantages de cette méthode sont que, dans notre architecture actuelle, basée sur celle de l’état de l’art [52], une addition coûte autant qu’une multiplication (voire plus cher en temps). En effet, l’architecture est optimisée pour accélérer la réduction modulaire (ce qui est normal au vu du coût de celle-ci), les Rowers contiennent donc des multiplieurs-accumulateurs pour calculer rapidement l’extension de base. Une addition requiert donc 2 cycles (on calcule a×1+b×1 en réalité). Utiliser une multiplication est donc plus avantageux sur cette architecture. De plus, elle implique un contrôle interne à chacun des moduli, car les xa,i sur les différents canaux sont indépendamment pairs ou impairs. Ainsi, cette division par 2 impliquerait une addition uniquement sur une partie des moduli, ce qui complique par rapport au contrôle habituel où les calculs sur tous les Rowers sont synchronisés et de même nature. Pour une future implantation FPGA, les deux solutions doivent être évaluées en matériel. Bien qu’il soit immédiat d’utiliser la multiplication par l’inverse (et plus simple en terme de contrôle), il est difficile a priori de comparer les 2 approches. Si l’implantation de la division par 2 ou 4 avec décalage se révèle bien plus efficace, cela réduirait alors l’intérêt alors de l’utilisation de divisions par 3 (sauf si une technique peu coûteuse peut être utilisée pour diviser par 3). À partir de maintenant, pour l’évaluation de l’algorithme et les comparaisons, nous allons considérer que les divisions exactes par de petites constantes sont faites uniquement en multipliant par l’inverse pré-calculé, c’est à dire qu’une division par 2 ou par 4 vaut autant qu’une division par 3 ou 6. Avant de détailler l’algorithme 18, nous allons évaluer l’autre opération critique qu’est la réduction modulaire par 3. En effet, la réduction modulo 4 a déjà été traitée dans la section80 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS Algorithme 18: Inversion modulaire binaire-ternaire plus-minus proposée (BTPM-MI). Entrées : −→ A , P > 2 avec gcd(A, P) = 1 Pré-calculs : −→ Ta , −−→ T −1 a , |P|4 et l’ensemble de pré-calculs pour Divup Sortie : −→ S = −−−−−→ |A−1 |P , 0 6 S < 2 P 1 lu ← 0, lv ← 0, Uc1 ← b0 , Vc1 ← b1, Vc3 ← Ab 2 bU1 ← 0, tU1 ← 0, bU3 ← |P|4, tU3 ← |P|3 3 bV1 ← 1, tV1 ← 1, bV3 ← mod4(Vc3), tV3 ← mod3(Vc3) 4 tant que Vc3 6= b1 et Uc3 6= b1 et Vc3 6= −c1 et Uc3 6= −c1 faire 5 tant que |bV3 |2 = 0 ou tV3 = 0 faire 6 Divup  Vc3, bV3 , tV3 , Vc1, bV1 , tV1 , v 7 Vc∗ 3 ← Vc3 , Vc∗ 1 ← Vc1 8 si |tV3 + tU3 |3 = 0 alors 9 si |bV3 + bU3 |4 = 0 alors 10 r = 1 11 Vc3 ← div12 \(Vc3 + Uc3 − −→ C , 0, 0) 12 Vc1 ← div12 \(Vc1 + Uc1 − −→ C , |bV1 + bU1 |4, |tV1 + tU1 |3) 13 sinon 14 r = 0 15 Vc3 ← div6 [(Vc3 + Uc3 − −→ C , 2, 0) 16 Vc1 ← div6 [(Vc1 + Uc1 − −→ C , |bV1 + bU1 |4, |tV1 + tU1 |3) 17 sinon 18 si |bV3 − bU3 |4 = 0 alors 19 r = 1 20 Vc3 ← div12 \(Vc3 − Uc3 + −→ C , 0, 0) 21 Vc1 ← div12 \(Vc1 − Uc1 + −→ C , |bV1 − bU1 |4, |tV1 − tU1 |3) 22 sinon 23 r = 0 24 Vc3 ← div6 [(Vc3 − Uc3 + −→ C , 2, 0) 25 Vc1 ← div6 [(Vc1 − Uc1 + −→ C , |bV1 − bU1 |4, |tV1 − tU1 |3) 26 si lv > lu alors 27 Uc3 ← Vc∗ 3 , bU3 ← bV3 , tU3 ← tV3 28 Uc1 ← Vc∗ 1 , bU1 ← bV1 , tU1 ← tV1 29 swap(lu, lv) 30 bV3 ← mod4(Vc3), tV3 ← mod3(Vc3) 31 bV1 ← mod4(Vc1), tV1 ← mod4(Vc1) 32 lv ← lv + r + γ 33 si Vc3 = b1 alors retourner (Vc1 − −→ C ) −→ Ta + −→ P 34 sinon si Uc3 = b1 alors retourner (Uc1 − −→ C ) −→ Ta + −→ P 35 sinon si Vc3 = −c1 alors retourner −(Vc1 − −→ C ) −→ Ta + −→ P 36 sinon retourner −(Uc1 − −→ C ) −→ Ta + −→ P2.3. ALGORITHME BINAIRE-TERNAIRE PLUS-MINUS EN RNS 81 précédente, la combinaison avec une réduction modulo 3 nous permet automatiquement d’obtenir les valeurs modulo 6 et 12. En repartant encore de la formule du CRT que l’on prend modulo 3, on obtient : |X|3 =       Xn i=1 ξa,i − q       3 , (2.7) en choisissant Ba tel que |ma,i|3 = 1 pour tout i. Dans cette équation, une seule ré- duction modulo 3 est effectuée après la somme (à la différence de l’équation 2.3 où les réductions sont faites au fur et à mesure). En représentation binaire de position, la réduction modulo 3 de ξa,i va dépendre de tous les bits de ξa,i à la différence du modulo 4 qui ne dépend que des 2 derniers. Ainsi, effectuer la somme des ξa,i avant de réduire semble le meilleur choix, une future évaluation FPGA devra être effectuée. Le coût d’une réduction modulaire est donc de n EMA et 1 réduction modulo 3 de w + log2 n bits. Le calcul de q est déjà effectué par le modulo 4 lorsque modulo 4 et modulo 3 sont effectués conjointement. Le calcul efficace de valeurs modulo 3, et plus généralement modulo un petit nombre premier sera étudié dans le chapitre 5. Nous allons maintenant étudier la structure globale de l’algorithme 18 et détailler les sous-fonctions qui le composent. La structure est très similaire à celle du PM-MI. On retrouve en premier lieu la boucle sur la parité de Vc3, qui peut maintenant être effectuée aussi lorsque Vc3 est divisible par 3 (tX représente la valeur de X modulo 3 dans l’algorithme). Par soucis de clarté, les calculs de cette sous-boucle sont encapsulés dans la fonction Divup (détaillée dans la suite). Ensuite vient une nouvelle forme du plus-minus. Il se trouve que si X et Y ne sont ni multiples de 2, ni de 3 alors X + Y ou X − Y est un multiple de 6. Il suffit de remarquer que les seules valeurs possibles pour X et Y sont 1 et 5 modulo 6. On sait déjà que X + Y et X − Y sont tous deux pairs, il ne nous reste plus qu’à procéder à un test de la somme modulo 3 pour effectuer le nouveau plus-minus. Aux lignes 9 et 18 de l’algorithme 18, on teste si le chemin choisi par le plus-minus n’est pas seulement divisible par 6 mais aussi par 12. Puisque nous avons déjà les valeurs de U3 et V3 modulo 4, ce test en plus ne coûte rien. Par contre, la division par 12 engendrée demandera des pré-calculs supplémentaires (bien qu’une bonne partie des pré-calculs nécessaires à la division par 12 modulo P sont déjà pré-calculés pour les divisions par 4 et 6). Enfin, une dernière diffé- rence avec le PM-MI se trouve dans le contrôle de la taille des valeurs. Pour cette version binaire-ternaire, lu et lv comptabilisent le nombre de divisions par 2 et par 3 qui ont été effectuées sur Uc3 et Vc3. Ces compteurs permettent en fait d’approcher la taille de nos valeurs globales tout au long de l’algorithme, c’est d’autant plus vrai si A a un nombre de bits proche de log2 P, ce qui est le cas en pratique pour un élément de FP pris au hasard. Pour comptabiliser une division par 3 on va donc ajouter log2 3 à lu ou lv, ou plutôt une valeur approchée γ. Pour l’évaluation de notre algorithme section 2.4, γ = 1.5 permet d’obtenir de bons résultats. En pratique, l’augmentation de la précision de γ est négligeable. La fonction Divup est détaillée dans l’algorithme 19. Cette fonction est une adaptation des lignes 10, 11 et 12 de l’algorithme 12. On se retrouve maintenant avec 5 cas à traiter car Vc3 peut être divisé par 2, 3, 4, 6 ou 12. La fonction change directement la valeur de ses entrées : elle divise et effectue une mise à jour des valeurs nécessaires. Les différentes fonctions div2 [ à div12 \ sont construites exactement sur le modèle de div2r \, elles retournent les résultats des divisions modulo P dans la représentation Xb. D’ailleurs div2 [ et div4 [ sont les deux sous-cas de la fonction div2r \ définie pour le PM-MI. Les fonctions mod4 et mod3 ont82 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS Algorithme 19: Fonction Divup. Entrées : Vc3, bV3 , tV3 , Vc1, bV1 , tV1 ,v Pré-calculs : −−→ C/2 , −−−−−→ (2 C/3) , −−−−−→ (3 C/4) , −−−−−→ (5 C/6) , −−−−−−−→ (11 C/12) , −−−−−−−−→ (P T −1 a )/12 , −−−−−−−→ (P T −1 a )/6 , −−−−−−−→ (P T −1 a )/4 , −−−−−−−→ (P T −1 a )/3 −−−−−−−−−→ (5P T −1 a )/12 , −−−−−−−→ (P T −1 a )/2 , −−−−−−−−−→ (−P T −1 a )/12 , −−−−−−−−→ (−P T −1 a )/6 −−−−−−−−→ (−P T −1 a )/4 , −−−−−−−−→ (−P T −1 a )/3 , −−−−−−−−−−→ (−5P T −1 a )/12 Sorties : Vc3, bV3 , tV3 , Vc1, bV1 , tV1 , lv 1 cas où bV3 = 0 et tV3 = 0 2 Vc3 ← div12 \ Vc3, bV3 , tV3  3 Vc1 ← div12 \ Vc1, bV1 , tV1  4 bV3 ← mod4(Vc3), bV1 ← mod4(Vc1) 5 tV3 ← mod3(Vc3), tV1 ← mod3(Vc1) 6 v ← v + γ + 2 7 cas où bV3 = 2 et tV3 = 0 8 Vc3 ← div6 [  Vc3, bV3 , tV3  9 Vc1 ← div6 [  Vc1, bV1 , tV1  10 bV3 ← mod4(Vc3), bV1 ← mod4(Vc1) 11 tV3 ← mod3(Vc3), tV1 ← mod3(Vc1) 12 v ← v + γ + 1 13 cas où bV3 = 0 et tV3 6= 0 14 Vc3 ← div4 [  Vc3, bV3  , 15 Vc1 ← div4 [  Vc1, bV1  , 16 tV3 ← update3(tV3 , bV3 , bV3 ), tV1 ← update3(tV1 , bV1 , bV3 ) 17 bV3 ← mod4(Vc3), bV1 ← mod4(Vc1) 18 v ← v + 2 19 cas où bV3 6= 0, 2 et tV3 = 0 20 Vc3 ← div3 [  Vc3, tV3  21 Vc1 ← div3 [  Vc1, tV1  , 22 bV3 ← update4(bV3 , tV3 ), bV1 ← update4(bV1 , tV1 ) 23 tV3 ← mod3(Vc3), tV1 ← mod3(Vc1) 24 v ← v + γ 25 cas où bV3 = 2 et tV3 6= 0 26 Vc3 ← div2 [  Vc3, bV3  27 Vc1 ← div2 [  Vc1, bV1  28 tV3 ← update3(tV3 , bV3 , bV3 ), tV1 ← update3(tV1 , bV1 , bV3 ) 29 bV3 ← mod4(Vc3), bV1 ← mod4(Vc1) 30 v ← v + 1 31 retourner Vc3, bV3 , tV3 , Vc1, bV1 , tV1 , lv2.4. COMPARAISON AVEC L’ÉTAT DE L’ART 83 déjà été expliquées précédemment, il ne manque plus qu’à détailler les fonctions update3 et update4. Ces fonctions évaluent respectivement la nouvelle valeur modulo 3 ou modulo 4 lorsqu’on a pas besoin de faire tout le calcul mod3 ou mod4. Par exemple, ligne 13 de l’algorithme 19 commence le cas ou Vc3 doit être divisé par 4. Dans ce cas, nous n’avons pas besoin de mod3 pour calculer la nouvelle valeur tV3 . La fonction update3(tV3 , bV3 , bV3 ) en ligne 16 va retourner tV3 · 4 −1 mod 3 = tV3 et tV3 · 2 −1 mod 3 = 2tV3 mod 3 à la ligne 28. Les opérations sur Vc1 étant plus complexes que celles sur Vc3, la fonction update3 retourne un résultat de la forme (tV1 + cP) · 4 −1 mod 3. En effet, dans le cas de Vc1 on doit effectuer une division modulo P et non pas une simple division exacte. Le c est celui qui est calculé pour effectuer la division avec div4 [, par exemple si bV1 = 2, alors on calcule (tV1 + 2P)· 4 −1 mod 3 (la valeur de c est déterminée dans l’équation 2.6). Finalement, lorsqu’on calcule update3(tV1 , bV1 , bV3 ), la première entrée correspond à ce qu’on doit modifier, la seconde permet de déterminer le c qu’on doit ajouter et la troisième quelle division nous avons effectué sur Vc1. La fonction update4 effectue la même chose mais pour la mise à jour des valeurs modulo 4 lorsqu’on divise par 3. Il n’y a plus que 2 entrées pour update4 car elle est utilisée que dans un seul cas (ligne 19 de l’algorithme 19). Avec Divup défini, l’algorithme est maintenant complètement décrit. Pour résumer, l’algorithme utilise le fait que les divisions par 2 et par 3 sont aussi difficiles et que la réduction par 3 n’est pas très difficile. Ainsi, grâce à ces plus grandes divisions on va avancer plus vite dans l’algorithme et réduire le nombre d’itérations de la boucle principale. En fait, comme on le verra dans la partie comparaison, le nombre d’itérations de la boucle interne va augmenter un petit peu mais ce surcoût sera largement compensé par la réduction du nombre d’itérations de la boucle principale. On pourrait avoir dans l’idée d’utiliser d’autres diviseurs, plus grands (par exemple 5 ou 7) afin de réduire encore le nombre d’itérations. En effet, la division ne coûte pas plus cher et la réduction modulaire par 5 ou 7 serait même presque gratuite : en effet dans l’équation 2.7 de réduction modulo 3 on effectue la somme puis on réduit par 3 les w + log2 n bits obtenus. Cette somme est en fait commune aux réductions modulo 3, 5 et 7, le surcoût serait juste une réduction modulo 5 et une modulo 7 de ce petit nombre. Nous verrons dans le chapitre 5 comment factoriser ces réductions modulaires dans la numération simple de position pour d’autres applications. Le problème de cette approche pour l’inversion est qu’elle rajoute, en contrepartie, beaucoup de pré- calculs et beaucoup de cas pour la fonction Divup. La liste des pré-calculs est déjà bien rallongée entre ceux de l’algorithme 12 et ceux (cumulés) des algorithmes 18 et 19. Rajouter de plus grandes valeurs augmenterait grandement le nombre de pré-calculs. De plus, le gain en terme du nombre d’opérations s’amenuise : une valeur globale a une probabilité 1 5 d’être multiple de 5, 1 7 d’être multiple de 7 et ainsi de suite. Nous pensons donc qu’il est très probablement préférable de s’arrêter au modulo 3. 2.4 Comparaison avec l’état de l’art 2.4.1 Complexité du FLT-MI L’algorithme de l’état de l’art (FLT-MI) ainsi que les deux algorithmes proposés dans nos travaux (PM-MI et BTPM-MI) effectuent O(`) itérations de la boucle principale pour des opérandes en entrée de ` bits. La principale différence vient donc du coût des calculs internes à cette boucle. Pour l’évaluation de complexité on introduit certaines notations pour les opérations élémentaires : – cox-add est une addition de deux éléments de t bits (effectuée dans le Cox) ;84 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS – mod4-add est une addition de deux éléments de 2 bits modulo 4 (ces opérations sont comptées mais leur coût est très faible comparé aux EMA et EMM) ; – mod3 est une réduction modulo 3 sur w + log2 n bits. Dans le but d’évaluer le coût de la version FLT-MI présentée dans l’algorithme 16, on doit évaluer le coût de chaque itération de la boucle principale. En moyenne, MM est exécutée avec une probabilité 1/2 à la ligne 5 et celle présente à la ligne 6 est toujours effectuée. Chaque itération calcule donc 1.5 MM. Nous considérons ici qu’une MM coûte 2n 2 + 6n EMM, 2n 2 + n EMA et 2n cox-add, comme Gandino et al. [48] (voir section 1.3.3 pour l’évaluation de MM). Pour conclure, l’algorithme 16 a une complexité moyenne de O(` × n 2 ). On peut remarquer qu’à travers ce chapitre, nous avons exclusivement considéré le cas de l’extension de base utilisant le CRT (notée CRTBE) avec la méthode de Kawamura et al. [64]. L’autre méthode principale est d’utiliser les extensions de base en passant par le MRS (notée MRSBE [120]). Comme déjà mentionné, cette méthode est moins parallélisable et donc moins bien adaptée à notre implantation matérielle. Même en mettant de côté cet aspect implantation pour se concentrer uniquement sur le nombre d’opérations, la multiplication modulaire via MRS coûte 3n 2+ 4n EMM, donc plus cher que la CRTBE. Nous avons présenté dans l’état de l’art des optimisations proposées par Bajard et al. dans [12] pour réduire ce coût, grâce à des bases bien choisies. Même si ces optimisations réduisent le coût en EMM et EMA de MRSBE, elles ne sont toujours pas suffisamment parallélisables pour les considérer dans le cadre de l’architecture RNS ECC de l’état de l’art. On pourrait effectuer une étude plus fine, mais la complexité de FLT-MI en EMM et EMA ne varie pas énormément en choisissant l’une ou l’autre des extensions de base. Dans les deux cas, FLT-MI est en O(` × n 2 ) EMM et EMA. Nous allons voir que de toute façon, les gains obtenus grâce à nos algorithmes sont tels qu’il n’est pas nécessaire de faire différentes études de cas. Pour conclure, dans un contexte matériel, il suffit de se concentrer sur CRTBE pour effectuer notre comparaison. 2.4.2 Complexité de PM-MI et BTPM-MI Afin d’évaluer le coût de l’algorithme 17 PM-MI, on doit d’abord estimer le coût de mod4 et div2r \. Le calcul de mod4 comprend le calcul de q, qui requiert n cox-add et la somme modulo 4 finale, qui requiert n mod4-add (|q|4 + Pn i=1 |ξa,i|4). Comme expliqué dans la section 2.2, div2r \ coûte n EMM (la multiplication par 4 −1 ou 2 −1 ) et n EMA (grâce aux pré-calculs des sommes des constantes). Ensuite, il faut évaluer le nombre d’itérations de la boucle interne (lignes 8–12) ainsi que le coût de chacune de celles-ci. En fait, la probabilité qu’une première itération ait lieu est de 1 2 (on teste si |V3|2 = 0). Une seconde itération n’arrive que si V3 est un multiple de 8, puisque s’il était juste un multiple de 4, on aurait divisé par 4 durant la première itération. On a donc une probabilité 1 8 d’avoir 2 itérations. En continuant ainsi, la probabilité de faire une j e itération est de 1 2·4 j−1 . Finalement, en moyenne on obtient 1 2 P∞ j=0 1 4 j = 2 3 itérations de la boucle interne pour une itération de la boucle principale. Dans une itération de la boucle interne, 2 mod4 et 2 div2r \ sont effectués, menant à 2n cox-add, 2n + 2 mod4-add, 2n EMM et 2n EMA. Après la boucle interne, la fin de la boucle principale va calculer 2 div2r \ et 2 mod4 (lignes 14–25). On peut voir que les entrées de div2r \ sont de la forme Xb ± Yb ± −→ C , mais ces additions sont directement intégrées dans les pré-calculs. Aucun nouveau pré-calcul2.5. ARCHITECTURE ET IMPLANTATION FPGA 85 n’est nécessaire, juste un peu de contrôle sur le choix de la constante que l’on ajoute. Pour ne pas compliquer inutilement l’écriture mathématique de div2r \, nous avons préféré cette présentation dans l’algorithme. Finalement, le coût des lignes 14–25 est de 2n EMM, 4n EMA, 2n cox-add et 2n + 2 mod4-add. Une évaluation complète du nombre de tours de boucle de cet algorithme est complexe. Nous avons effectué des tests sur plus de 700 000 valeurs avec des tailles ` cryptographiques (voir les standards du NIST [91]). En moyenne nous obtenons 0.71` itérations de boucle principale par inversion. Dans [66, p. 348–353], ce nombre est évalué à environ 0.70597` pour l’algorithme d’Euclide étendu binaire classique, on est donc très proche de ce résultat théorique. Pour conclure sur notre premier algorithme, sa complexité moyenne est de O(` × n) EMM et EMA contre O(` × n 2 ) pour l’état de l’art FLT-MI. Pour chiffrer le coût de notre second algorithme 18, nous avons aussi effectué 700 000 tests pour avoir une moyenne du nombre de chacune des différentes opérations. Il y a moins d’itérations de boucle principale que dans le PM-MI simple, en moyenne 0.46` au lieu de 0.71`. En revanche, il y a plus d’itérations de la boucle interne, ce qui est normal puisqu’on a plus de diviseurs. En moyenne, on a observé 3/4 itérations de boucle interne pour 1 tour de boucle principale, contre 2/3 pour le PM-MI. Finalement le nombre d’opérations a été réduit avec le nouvel algorithme. Les tables 2.1 et 2.2 donnent le détail du nombre d’opérations pour certaines tailles de corps et certaines bases pour les 3 algorithmes (nos 2 propositions et l’état de l’art). Le nombre de multiplications et d’additions élémentaires a été très significativement réduit par rapport au FLT-MI avec nos deux algorithmes. Le nombre de multiplications élémentaires EMM (qui est la métrique classique utilisée pour comparer les algorithmes RNS) est divisé par 12 à 37 avec le PM-MI et par 18 à 54 par le BTPM-MI comparé au FLT-MI, suivant les différents paramètres ` et n choisis. Par exemple, pour un P tiré aléatoirement de 192 bits avec n = 12 et w = 17, alors FLT-MI requiert 103140 EMM contre seulement 5474 EMM pour PM-MI et 3744 pour BTPM-MI en moyenne. Bien sûr, à cause de la différence de complexité en n, plus la base a d’éléments, plus le rapport entre nos algorithmes et le FLT-MI est grand. Par exemple, pour une taille de mots élémentaires fixée w, n va croître avec ` = dlog2 Pe puisque par définition, n × w = `. Comme présenté finalement dans la figure 2.1, BTPM-MI permet de réduire le nombre de EMM de 30 % et celui des EMA de 20 %, quelle que soit la taille du corps ` et quel que soit le nombre d’éléments dans la base n par rapport à PM-MI, le rapport des complexités étant constant. 2.5 Architecture et implantation FPGA L’algorithme de l’état de l’art FLT-MI et notre inversion PM-MI ont été implantés en FPGA. La version binaire-ternaire BTPM-MI ne dispose pas encore d’implantation, mais les premiers éléments présentés dans la section 2.4 semblent prometteurs. Nous avons comme objectif final la conception complète d’un cryptoprocesseur RNS pour ECC. Nous avons donc implanté une architecture Cox-Rower très similaire à celle de Guillermin [52], qui est l’état de l’art en terme de performances pour un cryptoprocesseur ECC en RNS avec protection contre certaines attaques par canaux cachés.86 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS nombre d’opérations Algo. ` n × w EMM EMA cox-add mod4-add mod3 FLT-MI 192 12 × 17 103140 85950 6876 0 0 9 × 22 61884 48991 5157 0 0 7 × 29 40110 30083 4011 0 0 256 12 × 22 137700 114750 9180 0 0 9 × 29 82620 65407 6885 0 0 8 × 33 67320 52020 6120 0 0 384 18 × 22 434322 382617 20682 0 0 aléa. 14 × 29 273462 233247 16086 0 0 12 × 33 206820 172350 13788 0 0 521 19 × 29 652080 577980 29640 0 0 16 × 33 474240 411840 24960 0 0 15 × 36 421200 362700 23400 0 0 FLT-MI 192 12 × 17 137520 114600 9168 0 0 9 × 22 85512 65322 6876 0 0 7 × 29 53480 40110 5348 0 0 256 12 × 22 183600 153000 12240 0 0 9 × 29 110160 87210 9180 0 0 8 × 33 89760 69360 8160 0 0 384 18 × 22 579096 510156 27576 0 0 NIST 14 × 29 364616 310996 21448 0 0 12 × 33 275760 229800 18 384 0 0 521 19 × 29 869440 770640 39520 0 0 16 × 33 632320 549120 33280 0 0 15 × 36 561600 483600 31200 0 0 Table 2.1 – Nombre d’opérations pour l’algorithme FLT-MI appliqué aux P standardisés du NIST et à des P aléatoires. 0 5000 10000 15000 20000 25000 30000 150 200 250 300 350 400 450 500 550 log P n = 12 canaux PM−MI EMA BTPM−MI EMA PM−MI EMM BTPM−MI EMM 0 2000 4000 6000 8000 10000 12000 14000 16000 4 6 8 10 12 14 16 18 20 n log P = 192 bits PM−MI EMA BTPM−MI EMA PM−MI EMM BTPM−MI EMM Figure 2.1 – Comparaison du nombre d’opérations EMM et EMA entre PM-MI et BTPM-MI, en fonction de log2 P pour n fixé (à gauche) et en fonction de n pour log2 P fixé (à droite).2.5. ARCHITECTURE ET IMPLANTATION FPGA 87 nombre d’opérations Algo. ` n × w EMM EMA cox-add mod4-add mod3 PM-MI 192 12 × 17 5474 8750 5474 5474 0 9 × 22 4106 6562 4106 4106 0 7 × 29 3193 5104 3193 3193 0 256 12 × 22 7282 11656 7282 7282 0 9 × 29 5461 8742 5461 5461 0 8 × 33 4854 7771 4854 4854 0 384 18 × 22 16487 26376 16487 16487 0 14 × 29 12823 20514 12823 12823 0 12 × 33 10991 17584 10991 10991 0 521 19 × 29 23446 37522 23446 23446 0 16 × 33 19744 31597 19744 19744 0 15 × 36 18510 29622 18510 18510 0 BTPM-MI 192 12 × 17 3744 6994 2868 2868 269 9 × 22 2808 5245 2151 2151 269 7 × 29 2184 4079 1673 1673 269 256 12 × 22 4988 9313 3821 3821 359 9 × 29 3741 6985 2865 2865 359 8 × 33 3325 6208 2547 2547 359 384 18 × 22 11215 20928 8588 8588 538 14 × 29 8723 16277 6680 6680 538 12 × 33 7476 13952 5725 5725 538 521 19 × 29 16055 29951 12293 12293 730 16 × 33 13520 25222 10352 10352 730 15 × 36 12675 23646 9705 9705 730 Table 2.2 – Nombre moyen d’opérations pour les algorithmes proposés PM-MI et BTPM-MI appliqués aux tailles de corps standards du NIST.88 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS Rower 1 w w Rower 2 w w . . . . . . Rower n w w Cox s q . . . . . . . . . t + 2 . . . registres I/O w canal 1 w w canal 2 w w canal n w w . . . . . . CTRL Figure 2.2 – Architecture globale Cox-Rower implantée similaire à celle proposée dans [52], avec Cox adapté à l’inversion PM-MI.2.5. ARCHITECTURE ET IMPLANTATION FPGA 89 CTRL (partagé) reg. local {en, r/w} Unité arithmétique (pipeline 6 étages) {rst, mode, . . . } w w w w w ENTRÉE w SORTIE w cmp w = b1 = −c1 Mém. Mult. ≈ 2n × w w @1 Mém. Mod. ha,i, hb,i @2 dlog2 ha,ie Mém. Add. 17 × w @3 w Figure 2.3 – Architecture du Rower implanté pour l’inversion PM-MI. L’architecture globale est décrite dans la figure 2.2. En dehors du Cox, cette architecture globale est partagée par les 2 implantations, les autres composants étant ensuite spécialisés et optimisés en interne pour chacune des versions. Comme expliqué dans l’état de l’art 1.3.5, cette architecture Cox-Rower est complètement parallélisée, un Rower de w bits pour 2 canaux (un dans chaque base) pour effectuer des extensions de base. C’est aussi le cas pour notre algorithme car, même s’il n’utilise qu’une seule base, le reste des calculs pour ECC nécessitera 2 bases et des extensions de bases. Les signaux de contrôle, d’horloge et de reset ne sont représentés que partiellement dans la figure 2.2. Les lignes se terminant par les cercles blancs représentent des signaux de contrôle ( ). La figure 2.3 présente la structure d’un élément rower. Chacun contient une unité arithmétique (AU) pour les calculs sur les opérandes de w bits, des registres locaux et des mémoires contenant les valeurs pré-calculées. L’unité arithmétique implantée est la même que celle décrite dans [52], dans la version pipelinée à 6 étages spécialement conçue pour les calculs ECC (voir section 1.3.5 et figure 1.9). La mémoire « Mém. Mod. » contient l’élément de chacune des bases correspondant à notre Rower. Ils sont stockés sous la forme ha,i et hb,i tels que ma,i = 2w − ha,i et mb,i = 2w − hb,i. Notre implantation PM-MI utilise 21 valeurs pré-calculées stockées comme constantes dans les mémoires du Rower, et utilisées comme constantes multiplicatives (dans la mémoire « Mém. Mult. ») ou additives (dans « Mém. Add. »), en plus des valeurs stockées pour pouvoir effectuer une réduction modulaire de Montgomery RNS (nécessaires pour les calculs ECC). La principale différence dans les Rowers entre la version FLT-MI et la version PM-MI sont les comparaisons sur la sortie de l’unité arithmétique (la figure 2.3 montre la version PM-MI). Celles-ci sont rajoutées pour tester la condition de la boucle principale. L’unité Cox dans l’architecture originale est utilisée pour calculer la somme q définie90 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS dans l’équation 1.13. Le Cox original est présenté dans la figure 1.8 de la section 1.3.5. C’est la même unité qui est implantée pour l’algorithme FLT-MI, c’est à dire juste un accumulateur qui somme n termes de t bits. Pour l’algorithme PM-MI, on utilise le Cox de façon intensive pour nos calculs modulaires. On l’a donc modifié pour que cette somme soit faite en un cycle. Dans nos implantations, le Cox n’était pas sur le chemin critique (situé au niveau de l’unité arithmétique), mais il se peut que pour un plus grand n ou un plus grand t il le soit. Cette somme pourrait alors être effectuée en 2 cycles par exemple ou 3. Le fait que le calcul soit fait en un cycle a permis d’avoir un contrôle un peu plus simple. L’autre différence vient du fait que le nouveau Cox calcule aussi une somme modulo 4, et reçoit donc maintenant d’un côté les t bits de poids fort des différents restes et de l’autre leurs 2 bits de poids faible pour la somme s =    Pn i=1 |ξa,i|4    4 . Dans la figure 2.2, les petits carrés représentent juste l’extraction et le routage des t+2 bits en provenance des w bits en sortie des Rowers. Les sorties du Cox sont s et q, et sont envoyées au contrôle qui calculera l’adresse @3, que ce soit pour corriger l’extension de base, ou effectuer le calcul adéquat dans la fonction div2r \ de l’algorithme PM-MI. Les valeurs globales de l’algorithme sont stockées dans les 4 registres globaux (en haut de la figure 2.2), contenant donc les valeurs RNS de n mots de w bits. Ces mots sont assignés à travers les n canaux, chaque canal ayant une entrée et une sortie spécifique. Les communications avec l’hôte sont effectuées à travers le port I/O de w bits (en haut à gauche) via ces registres. Les deux versions de l’architecture ont été implantées sur un FPGA Virtex 5 à l’aide de l’outil Xilinx ISE 14.6. Pour ` = 192 bits, le FPGA XC5VLX50T a été utilisé (il fait partie des petits FPGA de la famille Virtex 5), un FPGA plus grand (XC5VLX220) ayant été utilisé pour les autres tailles de corps. Les processus de synthèse et placement/routage ont été effectués pour des efforts standards d’optimisation en vitesse. Deux variantes ont été implantées, avec et sans blocs dédiés activés, afin de mesurer l’impact des blocs matériels DSP et BRAM (36Kb pour les FPGA Virtex 5). Nous avons implanté un certain nombre de bases avec différents compromis (n, w) pour les différentes tailles de corps. Pour ` = 192, 256 et 521 bits, trois paires (n, w) ont été implantées. Pour avoir une courbe un peu plus précise sans avoir un temps de développement trop long, nous avons choisi d’implanter 4 paires en plus pour la taille 384, menant donc à un total de 7 pour ce corps. Les résultats complets d’implantation sont présentés dans la table 2.3 pour les implantations avec blocs DSP et BRAM. La table 2.4 présente les résultats obtenus en désactivant les BRAM et les blocs DSP dans l’outil Xilinx ISE 14.6. On peut remarquer que dans certains cas, l’outil a quand même forcé l’utilisation de quelques blocs DSP malgré leur désactivation. Les résultats en terme de temps d’exécution dans la figure 2.4 et les résultats en terme de surface sont résumés dans les figures 2.5 et 2.6.2.5. ARCHITECTURE ET IMPLANTATION FPGA 91 Surface Freq. Nombre Temps Algo. ` n × w slices (FF/LUT) DSP BRAM MHz de cycles µs FLT-MI 192 12 × 17 2473 (2995/7393) 26 0 186 13416 72.1 9 × 22 2426 (3001/7150) 29 0 185 11272 60.9 7 × 29 2430 (3182/6829) 48 0 107 9676 90.4 256 12 × 22 3303 (3960/9524) 38 0 190 15397 126.2 9 × 29 3181 (3845/9444) 63 9 114 13093 114.9 8 × 33 3065 (3838/8629) 56 8 105 12325 117.3 384 22 × 18 4839 (6479/14642) 66 0 162 39971 246.7 20 × 20 4972 (6037/15476) 62 0 180 37159 206.4 18 × 22 4782 (5920/14043) 56 0 178 34359 193.0 17 × 23 4818 (5830/14181) 53 0 180 32941 183.0 14 × 29 5554 (5910/16493) 98 14 110 28416 258.3 12 × 33 5236 (5710/15418) 84 12 107 25911 242.1 10 × 40 11536 (7230/36503) 84 19 103 23099 224.3 521 19 × 29 7344 (8113/21286) 128 19 120 51580 429.8 16 × 33 6960 (7578/21282) 112 16 115 45334 394.2 15 × 36 8006 (8550/27514) 128 15 90 43252 480.5 PM-MI 192 12 × 17 2332 (3371/6979) 26 0 187 1753 9.3 9 × 22 2223 (3217/6706) 29 0 187 1753 9.3 7 × 29 2265 (3336/6457) 48 0 120 1753 14.6 256 12 × 22 2660 (3970/8638) 38 0 155 2333 15.0 9 × 29 2934(4014/8117) 63 9 103 2333 22.6 8 × 33 2688 (3838/7779) 56 16 105 2333 22.1 384 22 × 18 5338 (6805/17620) 66 0 141 3518 25.0 20 × 20 4201 (5977/12472) 62 0 148 3518 23.8 18 × 22 4064 (5932/13600) 56 0 152 3518 23.1 17 × 23 3956 (5848/12902) 53 0 150 3518 23.4 14 × 29 4873 (6134/14347) 98 14 102 3518 34.4 12 × 33 4400 (5694/12764) 84 24 103 3518 34.1 10 × 40 9510 (7222/33451) 0 24 102 3518 34.5 521 19 × 29 8044(8295/25983) 128 19 106 4750 44.8 16 × 33 7275 (7553/22906) 112 32 108 4750 44.0 15 × 36 8315 (8550/28438) 128 30 92 4750 51.6 Table 2.3 – Résultats d’implantation FPGA post placement/routage des algorithmes FLT-MI et PM-MI sur Xilinx Virtex 5 avec blocs DSP et BRAM activés dans ISE 14.6.92 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS Surface Freq. Nombre Temps Algo. ` n × w slices (FF/LUT) DSP BRAM MHz de cycles µs FLT-MI 192 12 × 17 4071 (4043/12864) 4 0 128 13416 104.8 9 × 22 4155 (3816/13313) 4 0 122 11272 92.3 7 × 29 4575 (3952/15264) 0 0 126 9676 76.7 256 12 × 22 5334 (5092/17557) 4 0 122 15397 126.2 9 × 29 5940 (5073/20097) 0 0 126 13093 103.9 8 × 33 6416 (5116/20828) 0 0 104 12325 118.5 384 22 × 18 8325 (7783/27330) 4 0 121 39971 330.3 20 × 20 7826 (7847/27310) 4 0 120 37159 309.7 18 × 22 7559 (7831/27457) 0 0 163 34359 210.7 17 × 23 8104 (7547/27645) 4 0 123 32941 262.8 14 × 29 9393 (7818/30536) 0 0 126 28416 225.5 12 × 33 9888 (7640/31599) 0 0 107 25911 242.1 10 × 40 10314 (7630/33911) 0 0 106 23099 217.9 521 19 × 29 12072(10629/43347) 0 0 118 51580 437.1 16 × 33 12306(10169/43732) 0 0 100 45334 453.3 15 × 36 13438 (10324/45615) 0 0 87 43252 497.1 PM-MI 192 12 × 17 3899 (4212/12519) 4 0 150 1753 11.6 9 × 22 3809 (3986/12782) 4 0 146 1753 12.0 7 × 29 4341 (4107/14981) 0 0 141 1753 12.4 256 12 × 22 4970(5037/16926) 4 0 123 2333 19.0 9 × 29 5791 (5288/1966) 0 0 128 2333 18.2 8 × 33 6100 (5292/20512) 0 0 107 2333 21.8 384 22 × 18 9305 (8111/29280) 4 0 125 3518 28.1 20 × 20 9046 (8158/29605) 4 0 127 3518 27.7 18 × 22 7677 (8053/28306) 0 0 168 3518 20.9 17 × 23 7536 (7467/25493) 4 0 121 3518 29.1 14 × 29 9119(8113/30619) 0 0 127 3518 27.7 12 × 33 9780 (7908/31902) 0 0 108 3518 32.5 10 × 40 10111 (7495/33169) 0 0 100 3518 35.1 521 19 × 29 14089 (11010/48858) 0 0 115 4750 41.3 16 × 33 14397 (10489/48037) 0 0 105 4750 45.2 15 × 36 15181 (10704/51922) 0 0 92 4750 51.6 Table 2.4 – Résultats d’implantation FPGA post placement/routage des algorithmes FLT-MI et PM-MI sur Xilinx Virtex 5 avec blocs DSP et BRAM désactivés dans ISE 14.6.2.5. ARCHITECTURE ET IMPLANTATION FPGA 93 50 0 500 450 400 350 300 250 200 150 100 s] µ temps inversion [ 192 bits FLT−MI PM−MI 256 bits 384 bits 521 bits 9 8 7 6 5 4 10 facteur accel. 50 0 500 450 400 350 300 250 200 150 100 s] µ temps inversion [ FLT−MI PM−MI 12 11 10 9 8 7 6 5 7 8 9 10 11 12 facteur accel. n 8 9 10 11 12 n 10 12 14 16 18 20 22 n 15 16 17 18 19 n Figure 2.4 – Courbes des temps d’exécution et facteurs d’accélération des implantations FPGA des algorithmes FLT-MI et PM-MI, avec blocs DSP et BRAM activés (en haut) et désactivés (en bas) ; pour 4 tailles de corps du NIST et différentes paires (n, w).94 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS 0 500 1000 1500 2000 2500 3000 3500 4000 7 9 12 slices FLT−MI 192 bits 7 9 12 PM−MI 192 bits 8 9 12 FLT−MI 256 bits 8 9 12 PM−MI 256 bits 0 10 20 30 40 50 60 70 80 7 9 12 # blocks (DSP / BRAM) n DSP BRAM 7 9 12 n 8 9 12 n 8 9 12 n Figure 2.5 – Histogramme des surfaces occupées pour les implantations sur FPGA Virtex 5 pour les corps du NIST de 192 et 256 bits. Avant d’analyser ces figures, nous présentons des arguments pour expliquer pourquoi nos implantations FLT-MI peuvent être utilisées comme référence afin de se comparer à l’état de l’art. Premièrement, nous avons implanté le FLT-MI avec un algorithme LSBF comme dans l’implantation ECC de l’état de l’art [52], tout en utilisant les astuces proposées (après la publication de [52]) pour l’exponentiation dans [48] pour accélérer les exponentiations RNS. L’algorithme a été implanté dans la version poids faibles en tête (algorithme 16) comme expliqué précédemment, afin de paralléliser le carré et la multiplication. Ensuite, il est difficile d’estimer l’efficacité d’architectures parallèles pour l’inversion modulaire en RNS dans l’état de l’art. Guillermin dans [52] estime qu’il y a jusqu’à 10 % de cycles d’attente dans les Rowers pour une multiplication scalaire complète en RNS (en comptant l’inversion). Ces cycles d’attente arrivent durant l’inversion et les conversions RNS/binaire et binaire/RNS. Nous avons considéré que ces cycles d’attente provenaient de l’inversion modulaire. En réalité, les opérations de conversions sont négligeables comparées à la complexité de l’inversion. De plus, l’algorithme d’exponentiation RNS utilisé dans [52] génère de nombreux cycles d’attente à cause des dépendances entre chaque itération de la boucle principale de l’algorithme d’exponentiation. On peut donc estimer que la plupart de ces cycles d’attente proviennent de l’inversion. En partant de cette hypothèse, le nombre de cycles d’attente avec le FLT-MI dans l’architecture de l’état de l’art [52] est d’environ 60 à 65 % du nombre total de cycles pour l’inversion. Nos implantations du FLT-MI ont elles entre 25 et 40 % de cycles d’attente (cela peut être facilement expliqué par le fait que dans nos implantations, le contrôle est dédié à notre opération d’inversion). On peut donc considérer que notre implantation du FLT-MI est un bon point de comparaison avec l’état de l’art. La figure 2.4 permet de comparer les temps d’exécution obtenus et de mesurer l’écart entre les deux solutions en indiquant l’accélération obtenue entre le FLT-MI et le PM-MI. On peut donc voir que suivant les paramètres, on peut aller de 5 à 12 fois plus vite que la solution de l’état de l’art. On peut observer que le rapport des temps obtenus semble linéaire en n. C’est particulièrement clair sur le facteur d’accélération obtenu sur le corps2.5. ARCHITECTURE ET IMPLANTATION FPGA 95 0 2000 4000 6000 8000 10000 12000 10 12 14 17 18 20 22 slices FLT−MI 384 bits 10 12 14 17 18 20 22 PM−MI 384 bits 15 16 19 FLT−MI 521 bits 15 16 19 PM−MI 521 bits 0 20 40 60 80 100 120 10 12 14 17 18 20 22 # blocks (DSP / BRAM) n DSP BRAM 10 12 14 17 18 20 22 n 15 16 19 n 15 16 19 n Figure 2.6 – Histogramme des surfaces occupées pour les implantations sur FPGA Virtex 5 pour les corps du NIST de 384 et 521 bits. de 384 bits qui bénéficie de plus de points de mesure, en doublant n, on double quasiment le facteur d’accélération obtenu. C’est une conséquence directe des complexités des deux algorithmes détaillés en section 2.4. Pour rappel, la complexité du PM-MI est en O(` × n) contre O(` × n 2 ) pour le FLT-MI, le rapport des deux est bien en O(n) en nombre d’opé- rations élémentaires. On peut remarquer que pour le PM-MI, le nombre de cycles ne dépend pas des paramètres n ou w (on ne compte pas les cycles de lecture de l’opérande ou d’écriture de la sortie) mais seulement de la taille du corps. C’est tout simplement parce que l’on calcule sur une architecture complètement parallèle. Ainsi, il y a n unités arithmétiques pour O(`×n) opérations, on obtient bien alors un temps en O(`) constant lorsque ` est fixé. Les variations du temps d’exécution sont donc dues aux variations de la fréquence d’horloge données par l’outil ISE. A contrario, les implantations FLT-MI ont une complexité de O(` × n 2 ) opérations sur les canaux. Puisque nous avons implanté une architecture parallèle avec n Rowers pour autant de canaux, le nombre de cycles a une complexité de O(` × n), et dépend donc de n. Si nous choisissons un petit n, les éléments de la base seront grands (si n = 4 pour un corps de 384 bits par exemple, on se retrouve avec des moduli de presque une centaine de bits). Ce qui implique que les unités arithmétiques deviennent significativement plus lentes (la fréquence chute à cause d’aussi grandes unités). D’un autre côté, un grand n implique un plus grand nombre de cycles. Pour atteindre l’inversion FLT-MI la plus rapide possible, il faut réussir à trouver le meilleur compromis sur la taille des moduli. Cette taille dépend bien sûr du matériel sur lequel l’implantation est faite. Ce compromis ne s’applique pas simplement au FLT-MI, mais à tout algorithme RNS utilisant des extensions de base, notamment les calculs sur les courbes elliptiques. Un autre point positif du PM-MI est qu’il ne dépend pas directement de ce compromis, on peut donc concevoir les unités pour avoir la multiplication scalaire la plus rapide qui soit, sans se96 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNS soucier de l’impact qu’il pourrait avoir sur le temps d’exécution de notre algorithme d’inversion. En d’autres termes, notre algorithme est très flexible au niveau du choix de la base RNS. Pour conclure l’analyse de ces implantations, on peut observer que les deux algorithmes aboutissent à des coûts en surface proches pour presque tous les paramètres, comme on peut le voir sur les figures 2.5 et 2.6. On peut observer quelques petites différences, comme par exemple sur la figure 2.6 avec n = 12 et ` = 384, l’implantation PM-MI a consommé moins de slices mais plus de BRAM que le FLT-MI. Les implantations étant extrêmement proches (en dehors du contrôle), il est normal que nous obtenions des résultats proches. Pour finir, on peut observer qu’il y a une chute de fréquence dans la table 2.3 entre les cas où w < 25 et les cas où w ≥ 25. C’est dû au fait que les multiplieurs intégrés dans les blocs DSP soient des multiplieurs 25 × 18 bits pour entiers signés, ils permettent d’effectuer directement des multiplications de 24 × 17 bits sur les moduli. Le synthétiseur a réussi à mieux utiliser ces multiplieurs pour des tailles de mots w < 25, ce qui donne des fréquences plus élevées pour ces w là. Lorsque w ≥ 25, des combinaisons plus complexes des multiplieurs sont effectuées, ce qui explique cette chute de fréquence. 2.6 Validation Les algorithmes proposés ne sont pas ici prouvés en détail, mais de forts arguments sont présentés dans cette section pour leur validation. Premièrement, la structure globale de l’algorithme 17 est la même que celle de l’algorithme d’Euclide binaire pour le calcul du pgcd avec plus-minus présenté dans [22]. Cela implique que si les opérations internes au RNS sont correctement effectuées, alors l’algorithme est correct. De plus, presque toutes les opérations nécessaires à l’algorithme sont juste des opérations classiques du RNS, additions et multiplications par des constantes. La fonction mod4 détaillée précédemment est basée sur l’évaluation du CRT, utilisant la méthode de Kawamura et al. [64]. Nous nous assurons ensuite d’être dans le bon intervalle pour appliquer leur approximation, grâce à la représentation Xb. Finalement, un total de 700 000 valeurs aléatoires (entre 0 et 3P) ont été testées sur les modulo P-160, P-192, P-256, P-384 et P-521 (voir [91]) en utilisant Maple 15. Pour chacune des tailles implantées sur FPGA et chacun des deux algorithmes (FLT-MI et PM-MI), une paire (n, w) a été testée sur 10 000 valeurs aléatoires en simulation VHDL (les autres implantations ont été testées au travers de 1000 valeurs à inverser). Ces tests ont été effectués en générant des fichiers de test VHDL avec Sage 5.2, les simulations ont été effectuées avec ModelSim 6.6 et enfin la vérification des résultats effectuée par Sage elle aussi. Quant à la version BTPM-MI (algorithme 18), il n’a pas encore été implanté en FPGA, sa validation a donc été effectuée seulement sur Maple 15 aussi avec 700 000 valeurs générées aléatoirement. Du côté de la validation théorique, on peut observer que les opérations internes de cet algorithme sont des adaptations de l’algorithme 17, et utilisent donc les mêmes arguments. Dans cet algorithme, comme dans l’algorithme d’Euclide étendu et sa variante binaire, on a toujours V1A + V2P = V3 et U1A + U2P = U3. C’est juste qu’en plus de gérer les divisions par 2 comme en binaire, on reporte aussi les divisions par 3. C’est aussi toujours cette condition qui fait qu’à la fin de l’algorithme, on a bien calculé l’inverse. Les opérations modulo 3, 6 et 12 permettent juste d’atteindre le résultat avec moins de2.7. CONCLUSION 97 tours de boucles, puisqu’on divise plus rapidement que dans la version purement binaire. 2.7 Conclusion Dans ce chapitre ont été présentés deux nouveaux algorithmes permettant de calculer l’inversion modulaire en RNS. Ces algorithmes, comme la plupart des algorithmes RNS utilisés en cryptographie, sont basés sur des idées qui ont été proposées dans le cas standard, mais où certaines difficultés techniques empêchaient leur réalisation en RNS. Le premier (PM-MI) est basé sur la version binaire de l’algorithme d’Euclide étendu, le second (BTPM-MI) propose une variante binaire-ternaire. Ces algorithmes ont la particularité de ne nécessiter qu’une seule base RNS, aucune extension de base n’étant requise. Pour nos divers ensembles de paramètres cryptographiques, le nombre de multiplications élémentaires est réduit très significativement : on divise par un facteur 12 à 37 ce nombre pour le PM-MI et de 18 à 54 pour le BTPM-MI, comparé à l’algorithme basé sur le petit théorème de Fermat. Les algorithmes PM-MI et FLT-MI ont été implantés sur 32 ensembles de paramètres différents sur FPGA. Les résultats obtenus montrent des surfaces très similaires, et des implantations PM-MI qui sont 5 à 12 fois plus rapides que l’état de l’art. Enfin, nous prévoyons d’implanter le nouvel algorithme binaire-ternaire sur FPGA, et d’étudier son coût en temps et surface comparé au PM-MI et d’intégrer ces algorithmes dans une implantation complète d’une multiplication scalaire ECC en RNS.98 CHAPITRE 2. INVERSION MODULAIRE RAPIDE EN RNSChapitre 3 Décomposition et réutilisation d’opérandes pour la multiplication modulaire RNS Ce chapitre est basé sur un travail en partie présenté lors de la conférence ASAP 2014 [20] sur la multiplication modulaire. Cet algorithme est, à notre connaissance, le premier à proposer une réduction du coût de la multiplication pour certains cas particuliers, comme le carré modulaire ou une multiplication par une constante. Pour des opérandes de n moduli, on obtient pour ces cas particuliers une complexité inférieure à 2n en terme de multiplications élémentaires (EMM) en utilisant des extensions sur des bases réduites, c’est-à-dire sur moins de moduli que l’état de l’art. Nous verrons que ces cas ou motifs de calcul particuliers se retrouvent dans les algorithmes d’exponentiation et dans les formules de courbes elliptiques. 3.1 Algorithme de multiplication modulaire RNS proposé L’algorithme que nous avons proposé va décomposer le calcul de la multiplication modulaire en 2 parties. La première partie effectue des calculs indépendants pour chacun des deux opérandes, et la seconde combine les résultats de la première et, cette fois-ci, dépend des 2 opérandes. Lorsqu’on réutilise un des opérandes pour une nouvelle multiplication modulaire, la partie des calculs qui dépend uniquement de cette opérande va pouvoir être réutilisée, à la différence des algorithmes de l’état de l’art. En effet, dans l’état de l’art, un carré suivi d’une réduction modulaire en RNS coûte exactement le même prix qu’une multiplication modulaire. C’est la même chose si on multiplie par une constante ou plusieurs fois par la même valeur dans une séquence d’opérations. Plus précisément, l’idée de notre algorithme est de décomposer dans un premier temps chacun des opérandes en 2 sous-valeurs. Ces sous-valeurs sont ensuite utilisées pour fabriquer une valeur sur 3n/2 moduli au lieu de 2n, c’est-à-dire un nombre de taille 3 2 log2 P bits au lieu de 2 log2 P. Cette réduction du nombre total de moduli réduit le nombre de valeurs pré-calculées à stocker. Pour les motifs comme le carré ou la multiplication par une constante, l’étape de dé- composition est effectuée une seule fois, ce qui va permettre de gagner en terme de nombre d’opérations. Par exemple, lors d’une exponentiation avec l’algorithme « échelle de Mont- 99100CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS gomery » (voir l’algorithme 22), un motif très utile est A ← BC, D ← B2 . Dans un tel cas, on remarque que la décomposition de B n’est effectuée qu’une seule fois, pour la première multiplication et pour le carré. On gagne donc ici 2 étapes de décomposition, par rapport à un motif A ← BC, D ← EF. Nous allons maintenant détailler les différentes étapes de notre algorithme. Notre algorithme de multiplication (appelé SPRR, voir section 3.1.1) est divisé en 3 étapes : premiè- rement, la décomposition Split, ensuite la réduction partielle PR (pour partial reduction) pour obtenir des valeurs de 3 2 log2 P bits, et enfin la réduction finale correspondant au dernier R de SPRR. Cette réduction utilise l’algorithme MR (réduction de Montgomery RNS) de l’état de l’art [48] (algorithme 15), pour obtenir une valeur de log2 P +ε bits (typiquement ε = 1, 2 ou 3), c’est-à-dire une valeur inférieure à αP avec un petit α. L’algorithme complet est détaillé en section 3.1.2. 3.1.1 L’étape de décomposition Afin d’expliquer ce qui est réalisé, nous allons d’abord détailler le flot de calcul qui est effectué dans les entiers (c’est-à-dire sans prendre en compte les détails de la représentation RNS). Toujours à des fins de compréhension, on va directement considérer ici que nous avons 3 bases, Ba, Bb et Bc, de n/2 moduli (3 « demi-bases »). On pourrait choisir d’autres paramètres pour la taille des bases, mais dans les cas que nous allons étudier dans ce chapitre, les meilleurs résultats sont obtenus dans ce cas précis. Tout d’abord, durant l’étape de décomposition, les opérandes X et Y vont être décomposés en un couple reste/quotient par Ma. L’algorithme 20 présente comment est faite cette décomposition Split. Après l’algorithme Split, on obtient en sortie X = KxMa + Rx et Y = KyMa+Ry. La première extension de base BE (ligne 1) convertit le reste de l’entrée X modulo Ma (noté Rx) dans les bases Bb et Bc. Il y a ici une réduction implicite par Ma dans la base Ba. À partir du reste, il est facile de calculer le quotient Kx ligne 2 dans les bases Bb et Bc. Les lignes 3 à 5 ne sont utiles que si on utilise l’extension de base de Kawamura [64], et seront expliquées dans le paragraphe suivant. Si on utilise une extension de base via MRS [12,120], ces lignes sont inutiles. On remarque que X est une valeur de ` bits puisque c’est un élément modulo P, donc Kx est une valeur de `/2 bits. Kx peut ainsi être extrait à partir d’une seule des deux demi-bases Bb ou Bc (ligne 6). Dans l’algorithme présenté, on suppose qu’on fait l’extension de base à partir de Bb. Il se peut en fait que X soit de taille ` + ε bits en étant dans le domaine de Montgomery, mais ça ne va pas changer les résultats obtenus. À la fin de l’algorithme, nous avons donc Kx et Rx dans les 3 demi-bases. Si nous utilisons l’algorithme d’extension de base de Kawamura et al. [64], qui est plus efficace que l’extension de base via MRS [120], alors l’approximation qu’elle implique lors de la première extension de base ligne 1 de l’algorithme 20 peut retourner Rx, ou la valeur approchée R0 x = Rx + Ma. Ceci requiert d’agrandir un peu la valeur de Mb. Dans le cas d’une d’approximation de Rx par R0 x = Rx + Ma, on remarque que le calcul ligne 2 de l’algorithme 20 donne K0 x = Kx − 1. Si Kx ≥ 1, alors K0 x ≥ 0, et il n’y a aucun impact sur le reste de l’algorithme, car malgré l’approximation on a quand même X = K0 xMa + R0 x . Par contre, si Kx = 0 on obtient K0 x = −1, qui ne satisfait plus les hypothèses du théorème de Kawamura et al. (théorème 5). C’est le seul cas spécial à traiter ici. Pour pallier ce problème, il suffit de tester si K0 x = −1 dans Bb et si c’est le cas, de corriger avec K0 x = 03.1. ALGORITHME DE MULTIPLICATION MODULAIRE RNS PROPOSÉ 101 et R0 x = Rx − Ma (lignes 3-5 de l’algorithme 20). Si l’architecture implantée utilise l’inversion modulaire PM-MI présentée au chapitre 2, ce test d’égalité avec −1 est déjà présent en matériel en sortie des Rowers. Dans la suite de ce chapitre, sauf mention contraire, nous ne distinguerons plus Kx de K0 x (respectivement Rx de R0 x ). La seconde extension de base ligne 6, elle, doit être exacte, sous peine d’obtenir un résultat faux. Pour rappel, il faut pour cela que (1 − σ0)Mb > Kx, ce qui peut se traduire par (1 − σ0)Mb > αP Ma . Cela implique donc une contrainte sur la taille de Mb et sur la base Bb pour satisfaire le théorème 4 (cas exact de Kawamura et al.). Les propositions 1 et 2 de la section 3.1.2 intègrent ces contraintes, qui sont ensuite expliquées dans la section 3.1.3 de démonstration. Algorithme 20: Étape de décomposition (Split). Entrée : −−−→ Xa|b|c , X < αP Pré-calcul : −−−−−−−→ M−1 a
b|c Sorties : −−−−−−→ (Kx)a|b|c , −−−−−−→ (Rx)a|b|c avec −−−→ Xa|b|c = −−−−−−→ (Kx)a|b|c × −−−−−−→ (Ma)a|b|c + −−−−−−→ (Rx)a|b|c 1 −−−−−→ (Rx)b|c ← BE −−−−→ (Rx)a , Ba, Bb|c  2 −−−−−→ (Kx)b|c ← −−→ Xb|c − −−−−−→ (Rx)b|c  × −−−−−−−→ M−1 a
b|c 3 si −−−−−→ (Kx)b|c = −→ −1 alors 4 −−−−−→ (Kx)b|c ← −→ 0 /*correction de l’erreur d’extension de base */ 5 −−−−−→ (Rx)b|c ← −−−−−→ (Rx)b|c − −−−−−→ (Ma)b|c 6 −−−−→ (Kx)a ← BE −−−−→ (Kx)b , Bb, Ba  7 retourner −−−−−−→ (Kx)a|b|c , −−−−−−→ (Rx)a|b|c Pour réduire le nombre de calculs, on peut observer que la multiplication ligne 2 de l’algorithme 20 par −−−−−−−→ M−1 a
b|c peut être combinée avec celle par −−−−−→ T −1 b
b , dans la première ligne de l’algorithme 14 d’extension de base (pour la seconde extension de base de l’algorithme 20). Nous sauvons ainsi nb EMM. Comme indiqué dans la table 3.2, on pré-calcule alors −−−−−−−−−→ M−1 a T −1 b
b . Cette table inclut les pré-calculs des BE utilisées dans Split. Finalement, le coût de l’algorithme Split est (na + na(nb + nc))+(nb + nbna)+nc EMM, pour les deux extensions de base. Dans notre cas, c’est-à-dire avec na = nb = nc = n/2, le coût total est alors 3 4 n 2+ 3 2 n EMM. Pour conclure, on peut voir l’étape Split comme une sorte de décomposition à la manière de Karatsuba-Ofman [63]. Dans le cas de Karatsuba-Ofman, on effectue ensuite 3 multiplications au lieu de 4. Dans notre cas, nous allons voir que nous allons réduire une valeur représentée sur 3 2 n au lieu de 4 2 n = 2n moduli. L’analogie s’arrête ici, la multiplication de Karatsuba-Ofman ne semblant pas s’appliquer (de façon efficace) à la représentation RNS, car c’est une représentation des nombres non positionnelle.102CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS 3.1.2 Algorithme de multiplication modulaire SPRR Notre méthode complète est présentée dans l’algorithme 21 et illustrée sur la figure 3.1. On suppose que les entrées de la multiplication modulaire sont inférieures à αP. Algorithme 21: Multiplication modulaire proposée SPRR. Entrées : −−−→ Xa|b|c , −−−→ Ya|b|c , avec X, Y < αP Pré-calcul : D = |M−1 a |P Sortie : −−−→ Va|b|c avec V ≡  XY M−1 a M−1 b   P et V < αP 1 ( −−−−−−→ (Kx)a|b|c , −−−−−−→ (Rx)a|b|c ) ← Split( −−−→ Xa,b,c ) 2 ( −−−−−−→ (Ky)a|b|c , −−−−−−→ (Ry)a|b|c ) ← Split( −−−→ Ya,b,c ) 3 −−−→ Ua|b|c ← PR −−−−−−→ (Kx)a|b|c , −−−−−−→ (Rx)a|b|c , −−−−−−→ (Ky)a|b|c , −−−−−−→ (Ry)a|b|c , D 4 −−−→ Va|b|c ← MR( −→ Ub , −−→ Ua|c ) 5 retourner −−−→ Va|b|c Après les deux étapes Split aux lignes 1 et 2, une opération PR de réduction partielle est utilisée (et détaillée juste ensuite) qui permet d’obtenir une valeur sur 3 2 n moduli, c’est-à-dire de taille 3 2 log2 P. Enfin, ligne 4, on effectue une dernière réduction en utilisant l’algorithme 15 de réduction de Montgomery en RNS sur ces bases réduites. Après les décompositions lignes 1 et 2, on a : |X Y |P =  KxKyM2 a + (KxRy + KyRx)Ma + RxRy   P . (3.1) Afin de faire une réduction partielle à partir de l’équation 3.1, nous allons supposer la relation qui suit entre la base Ba et P. Hypothèse 1 (H1). Soit D = |M−1 a |P , c’est-à-dire l’inverse de Ma modulo P. On suppose alors qu’il existe µ, avec µ très petit (typiquement 1, 2 ou 3) tel que µP + 1 = Ma × D. Sous cette hypothèse H1, nous définissons U comme U = KxKyMa + (KxRy + KyRx) + RxRyD ≡ |X Y D|P . (3.2) En choisissant na = n/2, les tailles de Ma, Rx, Kx et D sont très proches de `/2 bits et on a log2 U ≈ 3 2 log2 P sous H1. Ainsi, puisque na = nb = nc = n/2, il suffit de calculer U sur les bases Ba, Bb et Bc ( 3n 2 moduli en tout). Plus précisément, en posant C(α, µ) = α 2 µ D + 4α + 4µMa, on a : 0 6 U < C(α, µ)P + 4Ma. (3.3) Ce résultat sera prouvé en section 3.1.3. Pour bien comprendre ce qu’implique cette inégalité, il faut tout d’abord voir qu’on peut négliger 4α dans l’expression de C(α, µ), car en pratique α est pris petit (typiquement α = 2 ou 3, cf. [10, 52, 64]). Ensuite, l’impact du terme 4Ma est très limité, car pour notre algorithme log2 Ma < ` 2 . Pour résumer, U est borné par un entier Γ de la forme Γ = (γ1D+γ2Ma)P, avec γ1 et γ2 des petits entiers. La première conclusion est que si log2 Ma ≈ ` 2 , on a log2 D ≈ ` 2 et donc log2 Γ ≈ 3` 2 (on rappelle que dlog2 Pe = `). La deuxième conclusion est que la taille de U est directement3.1. ALGORITHME DE MULTIPLICATION MODULAIRE RNS PROPOSÉ 103 extension de base BE calculs dans 1 base Split PR MR base Ba Xa Ya Ua Kx Ky Ry = Ya Rx = Xa Qa Sa base Bb Xb Yb Rx Kx Ry Ky Ub Qb Sb base Bc Xc Yc Rx Kx Ry Ky Uc Qc Sc Figure 3.1 – Flot de calcul dans l’algorithme SPRR. liée aux tailles de Ma et D, et plus précisément à max(dlog2 Mae , dlog2 De). Nous allons maintenant justifier le choix d’une base Ba avec n/2 moduli et la nécessité de la condition H1. Dans notre algorithme, nous voulons minimiser la taille de U, autrement dit avoir une réduction partielle la plus efficace possible. Ainsi, la réduction finale MR est effectuée sur le moins de moduli possibles, nous permettant de réduire le coût des extensions de bases. Il nous faut donc minimiser max(dlog2 Mae , dlog2 De). À cause du fait que D = |M−1 a |P , il est impossible que Ma et D aient une taille plus petite que `/2 tous les deux à la fois, tout simplement parce que MaD > P et donc log2 Ma + log2 D > `. Ainsi, la borne sur U est proche d’être minimale lorsque log2 Ma ≈ log2 D ≈ `/2, ce qui explique notre choix de départ sur le nombre de moduli de Ba et la nécessité de la condition H1. Remarque. Si on ne s’autorisait aucune condition liant la base Ba et P, alors D serait un élément quelconque de FP , de taille `. Dans ce cas, on aurait log2 U > 2` et la dernière étape de l’algorithme MR coûterait exactement une réduction modulaire de Montgomery en RNS de l’état de l’art. Avec en plus le coût des autres étapes, notre algorithme serait finalement bien plus coûteux que l’état de l’art. L’étape PR de l’algorithme 21 calcule U à partir de l’équation 3.2. Cette opération coûte au premier abord 6 multiplications RNS sur chacun des 3n 2 moduli (c.-à-d. 9n EMM). En utilisant la méthode de Karatsuba-Ofman sur l’équation 3.2, on obtient :104CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS U =KxKyMa + (KxKy + RxRy − (Kx − Rx)(Ky − Ry)) + RxRyD =KxKy(Ma + 1) + RxRy(D + 1) − (Kx − Rx)(Ky − Ry) . (3.4) On a donc plus que 5 multiplications par moduli menant à 7.5n EMM. On remarque que dans la première base Ba, la multiplication par (Ma + 1) n’en est pas vraiment une car cela revient à multiplier par 1. Cela réduit le coût d’une EMM par élément de Ba, on obtient 7n EMM en tout. Enfin, le calcul de U peut être réduit dans certains cas particuliers. Par exemple, si nous calculons un carré, alors l’équation 3.2 ne requiert plus que 3 multiplications dans Ba (KxRx et (RxRy)D), ce qui mène à un coût total de 6.5n pour PR. Dans la séquence d’opérations (|XY |P , |XZ|P ), les calculs Kx(Ma + 1) et Rx(D + 1) sont communs aux deux multiplications, ces calculs peuvent donc être factorisés. Dans ce cas, il ne reste plus que 3 EMM par canal sur Ba, Bb et Bc d’après l’équation 3.4, menant à un coût total de 4.5n pour PR. Dans le cas d’une multiplication par une constante C, le coût peut être réduit à 3n en calculant directement U = Kx|C|P + Rx|CD|P . Pour ce dernier cas, il n’y a plus que 2 multiplications par canal, on obtient bien 3n EMM au total. La dernière étape de l’algorithme applique la réduction modulaire RNS de l’état de l’art (algorithme 15), mais seulement sur 3 2 n moduli. La base de départ est la base Bb et celle d’arrivée est Ba|b , la concaténation de Ba et Bc. Le coût de cette dernière étape est 2nb(na + nc) + 2(na + nc) + nb = n 2 + 5 2 n EMM. Ce coût prend en compte les améliorations proposées par Guillermin [52] et Gandino et al. [48] qui sont basées sur la factorisation de certains pré-calculs. L’amélioration de Gandino et al. nécessitant un changement de la représentation RNS dans une des bases ne semble pas utilisable ici de façon efficace. La proposition 1 résume toutes les conditions requises pour appliquer notre multiplication. Sa preuve est donnée dans la section 3.1.3. Proposition 1 (sous l’hypothèse H1). Soit P un grand entier, premier avec les 3 bases RNS notées Ba, Bb et Bc. Si Mb > 1 α−2 (C(α, µ) + 1), Mc > (α−2)P Ma et X, Y < αP alors, en sortie de l’algorithme 21, on a −−−→ Va|b|c = |XY M−1 a M−1 b |P avec V < αP. Ce théorème peut être réécrit facilement pour une autre hypothèse H2, très proche de H1. Hypothèse 2 (H2). Soit D = | − M−1 a |P , c’est-à-dire l’inverse de (−Ma) modulo P. On suppose alors qu’il existe µ, avec µ très petit (typiquement 1, 2 ou 3) tel que µP − 1 = Ma × D. L’hypothèse H2 sera utilisée pour des applications du logarithme discret dans les corps finis comme les cryptosystèmes de type Diffie-Hellman. Sous l’hypothèse H2, nous redéfi- nissons U avec U = KxKyMa + (KxRy + KyRx) − RxRyD + MaP ≡ |X Y (−D)|P . On a rajouté le terme MaP à l’expression de U pour s’assurer qu’elle soit bien positive. Cette variation H2 de l’hypothèse H1 définit aussi une nouvelle version de la proposition. La seule différence provient de la condition sur la taille de Mb.3.1. ALGORITHME DE MULTIPLICATION MODULAIRE RNS PROPOSÉ 105 Proposition 2 (sous l’hypothèse H2). Soit P un grand entier, premier avec les 3 bases RNS notées Ba, Bb et Bc. Si Mb > 1 α−2 (C(α, µ) + Ma + 1), Mc > (α−2)P Ma et X, Y < αP alors, en sortie de l’algorithme 21, on a −−−→ Va|b|c = |XY M−1 a M−1 b |P avec V < αP. Nous ne traitons pas dans cette section du coût de l’algorithme complet car nous verrons dans la section 3.2 que ce coût dépend fortement de la séquence de calculs dans laquelle on l’utilise. Ceci est bien illustré dans la figure 3.1, où les étapes Split des 2 entrées sont complètement indépendantes. Ces étapes Split peuvent être factorisées avec d’autres appels de SPRR réutilisant l’un des opérandes. Dans le cas d’un carré, un seul Split est effectué. L’étude du coût de l’algorithme n’a d’intérêt que dans les motifs d’opérations utilisés dans les différentes applications. Pour conclure la présentation de notre algorithme, on peut remarquer que pour pouvoir enchaîner les multiplications, il nous faut convertir les entrées dans le domaine de Montgomery. Les entrées sont ainsi de la forme X0 = |XMaMb|P et Y 0 = |Y MaMb|P , et l’algorithme SPRR retourne alors |XY MaMb|P . On garde ainsi la même représentation que l’état de l’art, mais sur moins de moduli. 3.1.3 Preuve des propositions 1 et 2 Nous allons démontrer dans cette sous-section les bornes des propositions 1 et 2. Les dé- monstrations étant très similaires pour les deux propositions, on va tout d’abord se focaliser sur le cas de la proposition 1, c’est-à-dire en considérant H1. Pour commencer, nous allons étudier la taille de U, sortie du calcul de l’étape PR. Cette étape fait le lien entre les extensions de base de l’étape Split et celles de la réduction finale MR (ligne 4 de l’algorithme 21). Par définition du reste de la division euclidienne, on a 0 6 Rx, Ry < Ma. De plus, sous l’hypothèse H1 on a MaD = µP + 1, et puisque X < αP alors : 0 6 Kx 6 αP Ma 6 αP µP + 1 D < α µ D . Comme expliqué dans la section 3.1.1, si l’approximation de l’extension de base de Kawamura et al. [64] nous fait commettre une approximation dans le calcul, on obtiendra à la sortie de Split les valeurs R0 x = Rx + Ma et K0 x = Kx − 1. Nous n’avons ici pas de moyen de détecter si Kx ou K0 x a été calculé (sauf pour le cas précis où K0 x = −1), on va donc considérer des encadrements plus larges −1 6 Kx, Ky < α µ D et 0 6 Rx, Ry < 2Ma. On obtient alors la borne supérieure suivante sur U : U = Kx(KyMa) + KxRy + KyRx + Rx(RyD) < α µ D(αP) + 2αP + 2αP + 4Ma (µP + 1) <  α 2 µ D + 4α + 4µMa  P + 4Ma 6 C(α, µ)P + 4Ma , où C(α, µ) =  α 2 µ D + 4α + 4µMa  permet de simplifier l’écriture. On rappelle que l’on se place sous l’hypothèse H1, et que log2 U ≈ 3` 2 .106CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS Pour que U ≡ |XY D|P , il ne faut pas qu’une réduction implicite se produise. Tout d’abord, nous pouvons remarquer que U n’est jamais négatif car, en sortie de Split, Kx et Rx ne sont jamais négatifs. Nous rappelons que les effets générés par l’approximation due à l’utilisation de l’extension de base de Kawamura et al. sont gérés à l’intérieur de la fonction Split. Pour qu’il n’y ait pas de réduction implicite, il faut aussi que le produit de tous les moduli soit supérieur à U. Ceci explique que l’on ait besoin de 3 demi-bases, et pas seulement 2, afin de disposer des 3n 2 moduli nécessaires à la représentation de U. En effet, la troisième base Bc n’est en réalité pas nécessaire pour réaliser les étapes Split et PR. Par contre, elle est requise pour effectuer notre dernière étape, pour avoir le nombre minimal de moduli requis pour représenter U. C’est pourquoi il faut que les calculs soient aussi réalisés sur cette base. On choisit donc Mb et Mc tels que MaMbMc > C(α, µ)P +4Ma. On va tout d’abord fixer les conditions sur Mb, puis en déduire la condition sur Mc. Nous commençons par Mb car c’est Mb qui va jouer le rôle de la première base dans l’algorithme 15 MR et qui va impacter la taille de la sortie de l’algorithme SPRR. Nous souhaitons que les éléments retournés par l’algorithme SPRR soient inférieurs à αP pour être réutilisés ensuite comme une entrée dans un autre appel de SPRR. L’algorithme 15 MR est ici appliqué avec Bb comme première base et Ba|c comme seconde base. On rappelle que la base Ba|c est la concaténation des bases Ba et Bc, et a deux fois plus d’éléments que Bb. Le résultat de SPRR est le résultat de l’algorithme MR appliqué ligne 4, c’est-à-dire U+Qa|cP Mb (voir algorithme 15). En partant de U+Qa|cP Mb < αP on obtient : 0 6 U Mb <  α − Qa|c Mb  P < (α − 2) P , (3.5) car Qa|c < 2Mb. Cela vient du fait que Qa|c est la sortie de la première extension de base (ligne 2 de l’algorithme 15). On rappelle que dans le cas de la première extension de base de l’algorithme 15, la résultat n’est pas forcément exact, c’est pourquoi on considère Qa|c < 2Mb et non pas seulement Qa|c < Mb. On déduit finalement une condition suffisante sur Mb pour satisfaire l’équation 3.5, en utilisant la borne sur U. En remarquant que 4Ma P < 1, on peut choisir Mb tel que : Mb > 1 α − 2 (1 + C(α, µ)) > 1 α − 2  4Ma + C(α, µ)P P  > U (α − 2)P . (3.6) On remarque qu’en appliquant cette condition, Mb est forcément plus grand que 4Ma, ce qui permet de remplir directement la condition pour effectuer l’étape Split avec l’extension de base de Kawamura et al. [64]. Pour conclure, nous allons donner une version simplifiée de la condition sur Mc, en supposant l’équation 3.6. Il faut que le produit de tous les éléments des 3 demi-bases, c’est-à-dire MaMbMc soit supérieur à U. On peut donc transcrire cette condition par : MaMbMc > C(α, µ)P + 4Ma . Pour simplifier le choix de Bc et donc de Mc, on peut directement utiliser la condition sur Mb (équation 3.6) en lieu et place de Mb, nous menant à la condition M c > (α − 2) P Ma . On vérifie alors bien : MaMbMc > (α − 2)PMb > C(α, µ)P + 4Ma .3.1. ALGORITHME DE MULTIPLICATION MODULAIRE RNS PROPOSÉ 107 Nous avons ici démontré que les bornes sur Mb et Mc étaient suffisantes pour obtenir le résultat souhaité à la fin de l’algorithme SPRR, sous l’hypothèse H1. Si maintenant nous considérons H2, très peu de changements sont à effectuer. En effet, H2 implique une modification de la définition de U, qui pour rappel devient : U = KxKyMa + (KxRy + KyRx) − RxRyD + MaP ≡ |X Y (−D)|P . Pour que U soit toujours positif, nous avons rajouté un terme MaP car par définition MaP > RxRyD. Cet ajout est reporté sur la borne sur U qui devient U 6 (C(α, µ) + Ma) P + 4Ma . Finalement, la condition suivante est obtenue : Mb > 1 α − 2 (1 + Ma + C(α, µ)) > 1 α − 2  4Ma + PMa + C(α, µ)P P  > U (α − 2)P . Le passage de la condition H1 à H2 ne change par contre en rien la condition sur Mc. 3.1.4 Sélection des paramètres Pour utiliser efficacement l’algorithme SPRR, nous avons besoin des conditions H1 et H2 pour que U puisse être représenté sur seulement 3n 2 moduli (cf. section 3.1.3). Ainsi, on utilise MR sur une demi-base Bb et une base complète Ba|c (à la fin de l’algorithme SPRR) au lieu des 2 bases complètes que l’on a dans l’état de l’art [48, 52, 64]. Nous verrons dans la section 3.3.1 qu’il est possible de se passer des hypothèses H1 et H2 pour certains motifs de calcul très particuliers. Pour satisfaire les hypothèses H1 et H2, deux stratégies peuvent être adoptées. Premiè- rement, si nous supposons que P est fixe, il nous faut alors trouver une base Ba satisfaisant H1 ou H2. Ainsi, nous pourrions utiliser notre algorithme pour tous les cryptosystèmes, avec les paramètres standards pour P, comme ceux pour ECC [91]. Malheureusement, nous n’avons, jusqu’à présent, pas trouvé de bonne méthode de sélection des moduli pour parvenir à satisfaire l’une des 2 hypothèses. Si nous choisissions de façon aléatoire Ba pour un P fixé, alors U aurait une taille de 2` au lieu de 3` 2 . L’autre stratégie est de considérer le problème dans l’autre sens, et de trouver un P qui satisfasse l’hypothèse H1 ou H2 à partir d’une base Ba donnée. Par exemple, dans le cas de H2, on a P = MaD−1 µ avec µ petit. En pratique, on peut choisir µ = 1, tester des valeurs aléatoires pour D (de taille `/2 bits) et tester si MaD − 1 est un nombre premier. Cette stratégie fonctionne mais empêche l’utilisation des P des standards pour ECC. Bien sûr, on ne peut pas appliquer SPRR à RSA car sa sécurité est directement liée à la valeur du module RSA et à sa factorisation, on ne va donc pas utiliser ses propriétés pour accélérer les calculs. Pour le logarithme discret, le paramètre P est généré avec une certaine forme, dont H2 est un sous-cas (cf. section 3.2.1). Choisir de nouveaux P pour les courbes elliptiques n’est pas un problème. En effet, jusqu’à maintenant les attaques n’arrivent pas à exploiter les caractéristiques du corps de base, mais portent sur les propriétés de la courbe (notamment son cardinal). C’est pour cela que les standards du NIST [91] proposent des corps spécialement conçus pour être très efficaces en numération simple de position binaire (le binaire « classique »). Par exemple,108CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS le corps standardisé P521 = 2521 − 1 permet des réductions modulaires rapides, comme expliqué dans la section 1.2.2. De la même façon, des paramètres P peuvent être générés pour être favorables à une utilisation du RNS. De même, nous verrons dans la section 3.2.1 que l’hypothèse H2 peut être utilisée pour générer des paramètres pour les cryptosystèmes Elgamal et Diffie-Hellman. Nous allons maintenant discuter de l’utilisation des 3 bases Ba, Bb et Bc. Tout d’abord, nous soulignons que Ba a un statut particulier dû à son implication dans les deux hypothèses H1 et H2. Ceci étant dit, les deux autres bases pourraient voir leurs rôles échangés dans une des étapes. En fait, si la base Bb est utilisée pour effectuer la deuxième extension de base de l’étape Split et la première de la réduction MR finale, c’est pour factoriser certains pré-calculs, réutilisés pour ces 2 opérations. On sauve ainsi (n 2/4) + (n/2) mots élémentaires de w bits à stocker (EMW pour elementary memory word). Dans le cadre d’une analyse plus fine des paramètres, on peut noter que la taille de Mb est plus grande de quelques bits que celle de Ma. Par exemple, pour µ = 1 et α = 3, la condition de la proposition 1 devient Mb > 9D + 4Ma + 16. Ces quelques bits supplémentaires peuvent être facilement obtenus, en prenant par exemple un ou deux éléments de Ba avec w − 1 bits et un ou deux de Bb avec w + 1 bits. Ce genre d’effet a été ici négligé pour les décomptes d’opérations. Nous avons supposé que les multiplications de w, w + 1 et w − 1 bits ont toutes le même coût. C’est notamment le cas lorsqu’on utilise les blocs multiplieurs dans les FPGA, qui ont une taille fixée, tant que w + 1 est plus petit ou égal à la taille limite supportée par un bloc multiplieur. 3.2 Applications Les performances théoriques de notre méthode SPRR sont comparées ci-dessous à la multiplication de Montgomery RNS de l’état de l’art [48]. Nous allons analyser dans cette section le nombre de multiplications modulaires élémentaires de w bits (EMM) et le nombre de mots mémoire élémentaires (EMW). Le nombre d’EMM est la métrique utilisée pour effectuer les comparaisons dans l’état de l’art [12, 48, 95]. La plupart du temps en RNS, il y a, à peu près, autant de multiplications que d’additions élémentaires, car les parties les plus coûteuses du calcul modulaire en RNS sont les extensions de base. Ces extensions, que ce soit avec le CRT ou via le MRS, utilisent grossièrement le même nombre d’additions et de multiplications (succession de multiplications-additions). Les coûts ici seront donc exprimés en nombre de multiplications. Enfin, une dernière métrique globale sera proposée, le produit EMM × EMW. En RNS, le nombre de pré-calculs est important, c’est pourquoi cette métrique est prise en compte. Cette métrique permet, dans une certaine mesure, de donner une idée des améliorations que l’on peut espérer sur le compromis temps-surface pour une implantation matérielle du SPRR. On peut d’ailleurs noter que pour réduire le coût en surface d’une implantation RNS, on peut réduire le nombre de Rowers, mais par contre la quantité de pré-calculs à stocker, elle, ne change pas. La part de circuit allouée à la mémoire sera donc de plus en plus importante vis-à-vis de celle allouée aux Rowers lorsqu’on cherchera a obtenir une implantation compacte. La table 3.1 présente le coût théorique de certaines opérations (en EMM), classiques en cryptographie asymétrique, pour quelques motifs d’opérations dans le corps. Pour ces opé- rations, nous considérons directement la représentation de Montgomery en RNS afin de simplifier les notations, autrement dit |AB|P est en fait |ABMaMb|P . Nous verrons ensuite3.2. APPLICATIONS 109 Opérations |AB|P |A2 |P |Cst × A|P MM [EMM] 2n 2 + 4n 2n 2 + 4n 2n 2 + 4n SPRR [EMM] 2.5n 2 + 12.5n 1.75n 2 + 10.5n 1.75n 2 + 7n Table 3.1 – Comparaison du coût théorique d’opérations courantes en cryptographie, en nombre de multiplications élémentaires EMM (Cst est une constante). Split PR MR −−−−−→ T −1 a
a : n/2 −−−→ Da|b|c : 3n/2 −−−−−−−−−−→ −P −1T −1 b
b : n/2 −−−−−→ (Ta,i) b|c : n 2/2 −−−→ Pa|b|c : 3n/2 −−−−→ (Tb,i) c : n 2/4 −−−−−→ (Ma) b|c : n −−−−−→ (−Mb) c : n/2 −−−−−−→ M−1 a
c : n/2 −−−−−−−−−−→  M−1 b T −1 a|c  a|c : n −−−−−−−−−→ M−1 a T −1 b
b : n/2 −−−−−−→ Ta|c,i
b : n 2/2 −−−−→ (Tb,i) a : n 2/4 −−−−−→ Ma|c
b : n/2 −−−−−−→ (−Mb)a : n/2 Total : 3n 2/2 + 17n/2 Table 3.2 – Décompte du nombre de pré-calculs à stocker en mots de w bits (EMWs) pour notre algorithme SPRR. que grâce aux factorisations (notamment des Splits) et à la réutilisation d’opérandes, le coût total peut être bien plus réduit dans une séquence d’opérations que dans la somme des opérations individuelles. Dans la table 3.1, nous voyons notamment que la multiplication modulaire coûte moins cher avec l’algorithme de l’état de l’art dans le cas de 2 opérandes distinctes, c’est-à-dire |AB|P . Par contre, le carré modulaire et la multiplication par une constante coûtent moins cher (du moins asymptotiquement) que l’algorithme de l’état de l’art, et c’est là l’intérêt de la solution proposée. Pour parvenir à ce résultat, il nous faut d’abord compter pour chacune des opérations le nombre d’étapes Split requises, puis rajouter le coût de l’étape PR en utilisant les optimisations proposées dans la section 3.1 et enfin rajouter le coût d’une réduction finale MR sur bases réduites. Pour |AB|P , on a besoin de deux Split, de l’étape PR sans optimisation particulière (autre que l’utilisation de Karatsuba) et enfin d’une réduction MR, ce qui donne 2× 3 4 n 2 + 3 2 n
+ (7n) + n 2 + 5 2 n
= 5 2 n 2 + 25 2 n = 2.5n 2 + 12.5n EMM. Le carré |A2 |P ne né- cessite lui qu’un seul Split. De plus, on peut gagner un peu sur l’étape PR en économisant certains produits, ce qui nous donne 3 4 n 2 + 3 2 n
+ (6.5n) + n 2 + 5 2 n
= 1.75n 2 + 10.5n EMM. Enfin, en multipliant par une constante, on réduit le coût de PR à 3n au lieu de 6.5n pour le carré, ce qui donne 1.75n + 7n. La table 3.2 présente le décompte des valeurs à pré-calculer pour notre algorithme,110CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS étape par étape, en mots mémoire élémentaires EMW. Grâce à la réduction du nombre de moduli de 2n à 3 2 n et à l’utilisation d’extensions de base uniquement sur des bases réduites, le nombre d’EMW est réduit. En effet, dans l’article de Gandino et al. [48], le nombre de pré- calculs s’élève à 2n 2 + 10n contre 3 2 n 2 + 17 2 n pour notre algorithme SPRR. La figure 3.2 illustre le rapport SPRR / MM en terme de EMW. On peut observer jusqu’à 25 % de réduction du nombre d’EMM, avec au moins 20% de réduction dès que n est supérieur à 5. 0.7 0.8 0.9 1.0 10 20 30 40 50 60 70 SPRR / MM n MEMOIRE EMW Figure 3.2 – Rapport du nombre d’EMW pré-calculés de notre solution SPRR vis à vis de l’état de l’art MM, pour des nombres de moduli classiques en cryptographie asymétrique. 3.2.1 Application au logarithme discret Nous allons ici étudier l’application de l’algorithme SPRR au cas des exponentiations dans FP pour des cryptosystèmes comme Diffie-Hellman [38] et Elgamal [44]. Comme décrit dans le chapitre 1, pour ces cryptosystèmes basés sur le logarithme discret, on choisit un P premier de 1024 à 3072 bits avec P −1 = V Q et Q un premier de 160 à 256 bits. En fait, cette condition correspond à l’hypothèse H2, avec µ = 1 et D un multiple de Q : P − 1 = V Q = MaV 0Q = MaD. On peut alors générer P sous cette hypothèse, et l’utiliser pour les calculs de logarithme discret. On calcule ensuite des exponentiations de G où G est un générateur du sous-groupe d’ordre Q de F ∗ p . Une première application pour le SPRR est l’algorithme 22, la très utilisée « échelle de Montgomery » (voir [62]), utilisé comme protection contre certaines attaques par canaux cachés. Pour chacun des bits de l’exposant, deux multiplications sont effectuées. On remarque que pour ces 2 multiplications modulaires, on a seulement 2 opérandes différentes, R0 et R1, ce qui implique seulement 2 étapes Split. Dans ce motif de calcul, notre algorithme va donc être efficace, avec un coût de 3.5n 2 + 19n EMMs contre 4n 2 + 8n EMMs pour MM. Si on prend aussi en compte la mémoire pour le coût global, nous obtenons 5.25n 4 + 58.25n 3 + 161.5n 2 EMM × EMW pour SPRR contre 8n 4 + 56n 3 + 80n 2 EMM × EMW pour MM. La figure 3.3 illustre ces résultats théoriques pour l’échelle de Montgomery, mais aussi pour l’algorithme LSBF 5 présenté au chapitre 1 avec une notation additive de la loi de groupe. Dans cet algorithme, si le bit d’exposant vaut 1, on effectue le même motif d’opérations que dans le cas de l’échelle de Montgomery. Lorsque ce bit vaut 0, seul un carré est effectué, ce qui reste un bon motif d’opérations pour effectuer notre algorithme. Les résultats entre les deux exponentiations sont très similaires comme le montre la figure 3.3, que ce soit en terme de nombre d’opérations EMM ou en coût global EMM × EMW. Les tailles habituelles pour ces exponentiations sont 1024 et 2048 bits, et correspondent à n = 33 et n = 66 pour des mots de w = 32 bits (voir la table 1.6). Pour n = 33 et n = 66, on obtient respectivement une réduction de 4 % et 9 % du nombre d’EMM et jusqu’à 30 % de réduction sur le coût total EMM × EMW.3.2. APPLICATIONS 111 Algorithme 22: Exponentiation « échelle de Montgomery » [62]. Entrées : G, E = (et−1, . . . , e0)2 Sortie : S = GE mod P 1 R0 ← 1; R1 ← G 2 pour de j = t − 1 à 0 faire 3 si ej = 0 alors 4 R1 ← R0R1; R0 ← R2 0 5 sinon 6 R0 ← R0R1; R1 ← R2 1 7 retourner R0 0.7 0.8 0.9 1.0 1.1 1.2 10 20 30 40 50 60 70 SPRR / MM n Exponentiation LSBF [EMM] Exponentiation LSBF [EMM*EMW] 0.7 0.8 0.9 1.0 1.1 1.2 SPRR / MM Exponentiation de Montgomery [EMM] Exponentiation de Montgomery [EMM*EMW] Figure 3.3 – Comparaison théorique des performances (EMM) et du coût (EMM × EMW) des algorithmes SPRR et MM pour les algorithmes d’exponentiations 22 (échelle de Montgomery) et 5 (LSBF, poids faibles en tête).112CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS 3.2.2 Applications aux courbes elliptiques Nous allons maintenant présenter des exemples d’applications de notre algorithme sur des formules d’opérations sur les points d’une courbe elliptique, comme l’addition et le doublement. Nous présentons ici trois ensembles de formules. Afin d’évaluer les différents coûts, nous avons procédé de la même façon que pour le logarithme discret. Nous n’allons pas ici détailler ces calculs car, d’une part, dans le prochain chapitre nous présentons un bien meilleur algorithme de multiplication applicable uniquement pour les courbes elliptiques et d’autre part, la complexité des formules rend ce décompte fastidieux. Ces résultats sont présentés car ils montrent tout de même comment se comporte notre algorithme sur diverses applications d’additions ou de doublements de points. Pour le décompte des opé- rations en utilisant l’algorithme SPRR, nous avons d’abord compté le nombre d’éléments à décomposer en utilisant Split, puis le nombre d’appels à PR en adaptant le coût suivant que l’on effectue une multiplication, un carré ou un produit par une constante. Enfin, le nombre de MR sur base réduite est exactement le nombre de réductions MR de l’état de l’art. Ces décomptes mènent finalement aux résultats présentés dans les tables 3.3, 3.4 et 3.5. Ces tables fournissent des complexités dépendantes de n et sont illustrées graphiquement dans les figures 3.4 et 3.5. Le premier ensemble de formules est présenté dans la table 3.3. Ce sont les formules issues de [17] qui sont applicables pour le cas classique des courbes représentées par l’équation de Weierstrass courte en coordonnées Jacobiennes. On rappelle que les coordonnées Jacobiennes sont définies par (X, Y, Z) avec x = X/Z2 et y = Y /Z3 . D’après [17], ce sont celles qui requièrent le moins d’opérations pour ces courbes là avec ces coordonnées. Cette table propose les coûts pour 3 opérations de points : le doublement, le triplement et l’addition mixte. L’addition mixte est une addition où l’un des deux points en entrée est représenté en coordonnées affines (c.-à-d. Z = 1), elle est donc moins coûteuse qu’une addition avec deux points quelconques. Lorsqu’on utilise l’algorithme 5 pour effectuer la multiplication scalaire, alors le point P, fixe, va être représenté en coordonnées affines afin de pouvoir faire une addition mixte. Ces formules d’addition mixte sont d’autant plus intéressantes avec le SPRR car elles permettent plus de réutilisation qu’une addition de points quelconques. On fournit aussi les résultats pour le doublement de point et le triplement, utilisé pour accélérer la multiplication scalaire en utilisant le recodage de clé DBNS, voir par exemple [40]. On remarque que pour ces formules, notre algorithme est toujours asymptotiquement meilleur que MM, que ce soit en nombre d’opérations EMM ou en coût global EMM×EMW. Par contre, les constantes devant n étant plus grandes, nous verrons que ces formules ne sont meilleures que pour de hauts niveaux de sécurité. Un autre exemple de formules est fourni dans la table 3.4, issu de [8] et utilisé dans l’implantation ECC de l’état de l’art en RNS [52]. Ces formules ont été spécialement adaptées pour le RNS et pour l’utilisation de l’échelle de Montgomery en tant que contre-mesure. Ces formules ont été proposées afin de réduire le nombre de réductions modulaires RNS, notamment via l’utilisation de motifs de type « sommes de produits » avant de procéder à la réduction modulaire. Ces formules ont la particularité de proposer un doublement de point plus cher qu’une addition en RNS avec l’algorithme de l’état de l’art MM, comme le montre la table 3.4. Pour ces formules, on observe que l’addition de points est toujours meilleure avec l’algorithme de l’état de l’art MM, alors que le doublement est meilleur avec SPRR, toujours grâce à un plus haut taux de réutilisation. En tenant compte du fait que pour chaque bit de clé, on effectue une addition et un doublement dans l’algorithme échelle de Montgomery, on a alors une meilleure complexité asymptotique pour notre algorithme SPRR.3.2. APPLICATIONS 113 Formules MM SPRR A1 = Z2 1 U2 = X2A1 S2 = Y2Z1A1 H = U2 − X1 H2 = H2 EMM : EMM : P1 + P2 I = 4H2 20 n 2 + 50n 17.5 n 2 + 95 n J = HI (mADD) R = 2(S2 − Y1) EMM × EMW : EMM × EMW : V = X1I 40 n 4 + 300 n 3 + 500 n 2 26.25 n 4 + 291.25 n 3 + 807.5 n 2 X3 = R2 − J − 2V Y3 = R(V − X3) − 2Y1J Z3 = (Z1 + H) 2 − A1 − H2 A = X2 1 B = Y 2 1 C = B2 D = Z2 1 S = 2 (X1 + B) 2 − A − C
EMM : EMM : 2 P1 M = 3A + aD2 20 n 2 + 48 n 16 n 2 + 100.5 n T = M2 − 2S X3 = T EMM × EMW : EMM × EMW : Y3 = M(S − T) − 8C 40 n 4 + 296 n 3 + 480 n 2 24 n 4 + 286.75 n 3 + 854.25 n 2 Z3 = (Y1 + Z1) 2 − B − D A = X2 1 B = Y 2 1 C = Z2 1 D = B2 M = 3A + aC2 N = M2 EMM : EMM : 3 P1 E = 6 (X1 + B) 2 − A − D
− N 28 n 2 + 72 n 23 n 2 + 160 n F = E2 T = 16D EMM × EMW : EMM × EMW : U = (M + E) 2 − N − F − T 56 n 4 + 424 n 3 + 720 n 2 34.5 n 4 + 435.5 n 3 + 1360 n 2 X3 = 4(X1F − 4BU) Y3 = 8Y1 (U(T − U) − EF) Z3 = (Z1 + E) 2 − C − F Table 3.3 – Coûts en multiplications EMM et coûts globaux EMM × EMW des algorithmes MM et SPRR pour les formules efficaces issues de [17] pour courbes sous forme de Weierstrass courte (y 2 = x 3 + ax + b, avec a quelconque), en coordonnées Jacobiennes.114CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS Formules MM SPRR A = Z1X2 + Z2X1 B = 2X1X2 EMM : EMM : P1 + P2 C = 2Z1Z2 12n 2 + 34n 12.75n 2 + 67n D = aA + bC Z3 = A2 − BC EMM × EMW : EMM × EMW : X3 = BA + CD + 2XGZ3 24n 4 + 168n 3 + 340n 2 19.125n 4 + 209.375n 3 + 569.5n 2 E = Z2 1 F = 2X1Z1 EMM : EMM : G = X2 1 14n 2 + 32n 12.25n 2 + 75n 2 P1 H = −4bE I = aE EMM × EMW : EMM × EMW : X3 = F H + (G − I) 2 28n 4 + 204n 3 + 320n 2 18.375n 4 + 216.625n 3 + 637.5n 2 Z3 = 2F(G + I) − EH Table 3.4 – Coûts en multiplications EMM et coûts globaux EMM × EMW des algorithmes MM et SPRR pour les formules optimisées RNS issues de [8] pour les courbes sous forme de Weierstrass courte (y 2 = x 3 + ax + b, avec a quelconque), en coordonnées (X, Z) et adaptées à l’échelle de Montgomery. Le troisième ensemble de formules concerne les opérations de points sur les courbes d’Edwards [43], qui sont de la forme x 2 + y 2 = c 2 (1 + dx2y 2 ) avec d /∈ {0, 1}. Ces formules utilisent les coordonnées inversées proposées dans [16], où les points sont représentés par (Z/X, Z/Y ). Les formules présentées dans la table 3.5 sont une amélioration de celles disponibles dans [16], et présentées dans [17] comme les moins coûteuses pour ces courbes en nombre de multiplications modulaires. On constate dans ce cas aussi que le gain en terme de complexité dépend du niveau de réutilisation que les formules permettent, les gains se situent donc principalement dans les doublements et triplements. Pour finir, les figures 3.4 et 3.5 résument les gains théoriques que l’on obtient pour nos différents ensembles de formules. Dans ces figures, ADD représente l’addition, mADD l’addition mixte, DBL le doublement et TPL le triplement de points. La figure 3.4 détaille les résultats pour les formules utilisant les coordonnées Jacobiennes pour la forme de Weierstrass courte. La courbe inférieure représente exactement les résultats de complexité de la table 3.3, avec le coût en EMM de chacune des opérations de points. On remarque que le doublement est meilleur avec le SPRR à partir de n = 13 moduli, alors que le doublement et l’addition mixte ne le sont qu’à partir de 18. Les courbes présentées dans la partie supérieure de la figure 3.4 combinent ces coûts pour refléter le gain sur une multiplication scalaire. Le motif 2DBL+mADD correspond ainsi à un algorithme de doublement et addition, le motif 2DBL+mADD+TPL correspond lui à un algorithme de multiplication scalaire utilisant le recodage DBNS du scalaire (voir [40]). Ce dernier motif surestime un peu le nombre d’additions par rapport au nombre de doublements et triplements, afin de simplifier l’expression (ce qui désavantage un peu notre algorithme). Le coût en EMM des deux motifs sont très proches. On remarque que notre algorithme est meilleur que MM pour n > 16, en nombre d’opérations effectuées. C’est le cas si les calculs sont effectués sur un corps de 521 bits avec w = 32. Sur une plateforme avec une contrainte sur la taille des moduli, comme dans [5] où w = 16 pour du calcul sur GPU. Alors les courbes sur 384 et 521 bits correspondent respectivement à n = 24 et n = 34, où notre algorithme3.2. APPLICATIONS 115 Formules MM SPRR A = Z1Z2 B = dA2 C = X1X2 EMM : EMM : P1 + P2 D = Y1Y2 26n 2 + 60n 25.75n 2 + 131.5n E = CD (mADD) H = C − D I = (X1 + Y1) − C − D EMM × EMW : EMM × EMW : X3 = c(E + B)H 52n 4 + 380n 3 + 600n 2 38.625n 4 + 416.125n 3 + 1117.75n 2 Y3 = c(E − B)I Z3 = AHI A = X2 1 B = Y 2 1 C = A + B EMM : EMM : 2 P1 D = A − B 18n 2 + 36n 15.75n 2 + 86.5n E = (X1 + Y1) 2 − C
X3 = CD EMM × EMW : EMM × EMW : Y3 = E(C − u2Z2 1 ) ? 36n 4 + 252n 3 + 360n 2 23.625n 4 + 263.625n 3 + 367.625n 2 Z3 = cDE A = X2 1 B = Y 2 1 C = Z2 1 EMM : EMM : D = A + B 30n 2 + 60n 24.75n 2 + 144.5n F = D2 3 P1 E = 4(D − u1 C) ? H = 2D(B − A) EMM × EMW : EMM × EMW : S = F − AE 60n 4 + 420n 3 + 600n 2 37.125n 4 + 402.125n 3 + 614.125n 2 Q = F − BE T = Q2 X3 = (H + Q) (Q + X1) 2 − T − A
Y3 = 2(H − S)SY1 Z3 = S (Q + Z1) 2 − T − C
Table 3.5 – Coûts en multiplications EMM et coûts globaux EMM×EMW pour les algorithmes MM et SPRR des formules issues de [17] pour courbes d’Edwards, avec les coordonnées inversées. Note ? : u1 = c 2d and u2 = 2 u1 pour une courbe définie par x 2 + y 2 = c 2 (1 + dx2y 2 ).116CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS 0.8 0.9 1 1.1 1.2 1.3 1.4 5 10 15 20 25 30 35 40 SPRR / MM n mADD DBL TPL 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 SPRR / MM EMM | 2DBL+mADD+TPL EMM | 2DBL+mADD EMM*EMW | 2DBL+mADD+TPL EMM*EMW | 2DBL+mADD Figure 3.4 – Comparaison des performances et des coûts théoriques entre les algorithmes SPRR et MM pour les formules présentées à la table 3.3 (en bas) et pour des combinaisons classiques présentes dans les algorithmes de multiplication scalaire. est meilleur que MM de 4.5% et 9.5% respectivement. La figure supérieure propose aussi une métrique du coût global, avec le produit opérations EMM/mémoire EMW pour les deux motifs. Suivant cette métrique EMM × EMW, notre algorithme est moins coûteux que l’algorithme de l’état de l’art, même pour des petites valeurs de n > 5. Ainsi, pour une base n > 16, on obtient avec SPRR une réduction de plus de 25 % du coût global par rapport à MM. La figure 3.5 présente les résultats pour les deux autres ensembles de courbes. Ces résultats sont clairement moins bons que ceux obtenus avec les formules utilisant l’addition mixte. Sur la partie inférieure de la figure 3.5 sont présentés les résultats pour l’échelle de Montgomery et les formules de la table 3.4. Le coût global est réduit à partir de n = 9 mais le nombre d’opérations est toujours plus grand que pour l’algorithme de l’état de l’art. De même pour la partie supérieure représentant les calculs sur les courbes d’Edwards. Le coût global est cette fois-ci meilleur très rapidement, lorsque n > 5, mais le nombre d’opérations est tout juste équivalent lorsqu’on atteint n = 26. Ces courbes montrent clairement que le coût de l’algorithme SPRR dépend grandement de la séquence de calcul sur laquelle il est appliqué et des réutilisations qui sont faites. De plus, les gains étant sur des complexités asymptotiques, ils sont bien plus clairs et importants pour les algorithmes d’exponentiation que pour la cryptographie sur courbes elliptiques. Nous verrons dans le chapitre 4 un algorithme qui ne sera pas applicable pour les exponentiations mais bien plus adapté aux calculs sur courbes elliptiques. 3.3 Exponentiation rapide RNS sans hypothèse sur P Cette section va présenter de nouveaux algorithmes d’exponentiation rapide pour le RNS 1 , réduisant le nombre d’opérations par rapport à l’algorithme de l’état de l’art [48]. Ces algorithmes reprennent les idées qui sont à la base de la multiplication SPRR afin de profiter des réutilisations des opérandes dans certains algorithmes d’exponentiation. Si ces algorithmes sont présentés dans une section à part, c’est qu’ils n’utilisent pas directement 1. Ces résultats ne sont pas dans le papier d’ASAP 2014 [20]3.3. EXPONENTIATION RAPIDE RNS SANS HYPOTHÈSE SUR P 117 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 5 10 15 20 25 30 35 40 SPRR / MM n EMM | DBL+ADD EMM*MEM | DBL+ADD 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 SPRR / MM EMM | 2DBL+ADD EMM| TPL+2DBL+ADD EMM*MEM | 2DBL+ADD EMM*MEM | TPL+2DBL+ADD Figure 3.5 – Comparaison des performances et des coûts théoriques entre les algorithmes SPRR et MM pour des combinaisons classiques des formules présentées à la table 3.4 (en bas) et table 3.5 présentes dans les algorithmes de multiplication scalaire. le SPRR à la différence des exponentiations étudiées dans la section 3.2.1. En effet, ces nouveaux algorithmes vont accélérer les exponentiations sans aucune hypothèse sur P et réduisent encore le nombre de multiplications élémentaires EMM par rapport à l’utilisation de SPRR. En contrepartie, le nombre de moduli est 2n (comme pour l’algorithme de l’état de l’art). De plus, ils augmentent le nombre de pré-calculs à stocker par rapport au SPRR et à l’algorithme de l’état de l’art [48]. Enfin, ces algorithmes sont basés sur un motif d’opération particulier, certains algorithmes, comme par exemple l’échelle de Montgomery, ne calculent pas ce motif et ne sont donc pas accélérés par rapport au SPRR. 3.3.1 Un nouvel algorithme d’exponentiation RNS Algorithme 23: Exponentiation carré et multiplication (source [51]). Entrées : k = (k`−1, . . . , k1, k0)2, G ∈ Z/PZ Sortie : Gk mod P 1 S ← 1 2 pour i de ` − 1 à 0 faire 3 S ← S 2 mod P 4 si ki = 1 alors S ← S × G 5 retourner S Le calcul que nous allons étudier et accélérer dans cette partie est X2C mod P, où C est une constante pré-calculée. On retrouve ce motif dans l’algorithme 23, qui est l’exponentiation équivalente à la multiplication scalaire de l’algorithme 6 (présenté dans la section 1.1.4). L’algorithme 23 présenté suppose que l’on soit déjà en représentation de Montgomery RNS (ou dans la version améliorée de Gandino et al. [48]) et retourne le résultat dans cette même représentation. Ce n’est pas sur ces conversions que portent les améliorations, et ces conversions initiales et finales sont négligeables par rapport au coût de l’exponentiation. Avant d’analyser notre algorithme, nous allons d’abord expliquer l’idée,118CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS proche du SPRR, qui lui sert de base. On remarque que lorsque ki = 1 dans l’algorithme 23, on effectue la séquence de calcul S ← S 2 mod P puis S ← S × G mod P, c’est-à-dire S 2G mod P avec G constant. Pour accélérer ce calcul, nous allons décomposer S en (Ks, Rs) comme pour le SPRR. Pour ce faire, on va utiliser à nouveau l’algorithme 20 Split, toujours avec na = nb = n/2 mais par contre avec nc = n. Nous avons bien, comme annoncé, na + nb + nc = 2n moduli. On rappelle que le coût de cet algorithme est (na + na(nb + nc)) + (nb + nbna) + nc EMM, c’est-à-dire  n 2 + 3n 2 4  +  n 2 + n 2 4  + n = n 2 + 2n EMM dans notre cas. Après avoir obtenu (Ks, Rs), on remarque que : S 2G ≡ K2 sM2 a + 2KsRsMa + R 2 s
G mod P ≡ K2 s |M2 aG|P + KsRs|2MaG|P + R 2 s |G|P mod P ≡ Ks Ks|M2 aG|P + Rs|2MaG|P
+ R 2 s |G|P mod P . (3.7) Si on pose U2 = Ks Ks|M2 aG|P + Rs|2MaG|P
+ R2 s |G|P , alors log2 U2 ≈ 2`. Comme cela sera montré plus loin dans cette section, on peut borner U2 plus précisément par : U2 < 12P 2 + M2 aP , (3.8) en supposant que S < 3P. En calculant U2, nous avons obtenu une valeur telle que U2 ≡ S 2G mod P de taille 2` + ε bits. Il suffit alors de choisir la base Bc pour pouvoir effectuer une réduction modulaire de Montgomory RNS MR prenant en entrée cette valeur de 2` + ε et de réduire. Prenons l’exemple d’une exponentiation pour RSA 2048 bits, avec log2 P = 2048 (bien sûr ici P n’est pas premier). Supposons que S est représenté dans le domaine de Montgomery, avec S < 3P. Dans cet exemple, la valeur à réduire S 2G est de taille 6148 bits, le but est d’obtenir un résultat de 2050 bits (car inférieur à 3P). Supposons que n = 66 et w = 32, alors Ma est un nombre de 33 · 32 = 1056 bits. En appliquant la borne de l’équation 3.8, on obtient log2 U2 < 4161. En effet, log2 (M2 aP) = 2 log2 (Ma) + log2 (P) = 2112 + 2048 = 4160 et log2 (12P 2 ) = 4+2 log2 P = 4100. Pour résumer, on obtient U2 un peu plus grand que P 2 , en ayant seulement décomposé S puis calculé l’équation 3.7. Nous avons donc déjà parcouru la moitié du chemin pour passer de 6144 à 2049 bits, pour le coût du Split et de 5 multiplications RNS sur 2n moduli pour évaluer U2. On obtient n 2 + 2n+ 5 · 2 ·n = n 2 + 12n EMM pour cette première partie. Ensuite, on applique la réduction MR de l’état de l’art qui coûte 2n 2 + 2n EMM. Dans notre algorithme 24, les constantes pré-calculées pour le calcul de U2 sur la base Bc permettent d’inclure directement le calcul de la ligne 1 de l’algorithme 15 MR ainsi que la ligne 1 de l’algorithme 14 BE, réduisant le coût du MR final à 2n 2 +n. Le coût de l’opération S 2G mod P est donc de 3n 2 + 13n EMM, contre 4n 2 + 8n EMM pour l’état de l’art. Dans l’état de l’art, on effectue en fait 2 multiplications sur les 2n moduli suivies de 2 MR d’où 2(2n 2+2n)+2n EMM. Pour notre exemple avec n = 66, on obtient 13926 EMM au lieu de 17952 EMM pour effectuer le carré et la multiplication lorsque ki = 1 dans l’algorithme, soit environ une réduction de 22.5 %. Puisqu’on a en moyenne autant de 0 que de 1 dans ki , le rapport des complexités en EMM pour l’exponentiation complète entre notre algorithme et l’état de l’art est 2n 2+4n+3n 2+13n 3(2n2+4n) = 5n 2+17n 6n2+12n . Pour n = 66, on a une réduction du nombre d’EMM de 15.0 % et pour n = 34 (pour RSA-1024 par exemple) on a un gain de 13.4 %. La figure 3.6 illustre ce ratio pour n > 5. On remarque que la convergence vers 1 6 est rapide, on atteint un réduction de 10 % dès n > 15.3.3. EXPONENTIATION RAPIDE RNS SANS HYPOTHÈSE SUR P 119 Algorithme 24: Exponentiation RNS revisitée Entrées : k = (k`−1, . . . , k1, k0)2 Pré-calculs : −−−−−−−−−−−−−−−−→  M−1 c,i P −1 |GM2 a |P  c , −−−−−−−−−−−−−−−−→  M−1 c,i P −1 |2GMa|P  c , −−−−−−−−−−−→  M−1 c,i P −1G  c dans Bc Pré-calculs : −−−−−−−−−→ |GM2 a |P
a|b , −−−−−−−−−−→ (|2GMa|P )a|b , −−→ Ga|b dans Ba|b Sortie : −−−−→ |Gk |P dans Ba|b|c 1 −−−→ Sa|b|c ← −→ 1 2 pour i de ` − 1 à 0 faire 3 si ki = 0 alors 4 −−−→ Sa|b|c ← −−−→ Sa|b|c × −−−→ Sa|b|c 5 −−−→ Sa|b|c ← MR( −→ Sc , −−→ Sa|b ) 6 sinon 7 ( −→ Ks , −→ Rs ) ← Split( −→ S ) 8 −−→ Sa|b ← −−−−−→ (Ks)a|b × −−−−−→ (Ks)a|b × −−−−−−−−−→ |GM2 a |P
a|b + −−−−→ (Rs)a|b × −−−−−−−−−−→ (|2GMa|P )a|b  9 −−→ Sa|b ← −−→ Sa|b + −−−−→ (Rs)a|b × −−−−→ (Rs)a|b × −−→ Ga|b 10 −→ Sc ← −−−−→ (Ks)c × −−−−−−−−−−−−−−−−→  M−1 c,i P −1 |GM2 a |P  c + −−−−→ (Rs)a|b × −−−−−−−−−−−−−−−−→  M−1 c,i P −1 |2GMa|P  c 11 −→ Sc ← −−−−→ (Ks)c × −→ Sc + −−−→ (Rs)c × −−−→ (Rs)c × −−−−−−−−−−−→  M−1 c,i P −1G  c 12 −−−→ Sa|b|c ← MR( −→ Sc , −−→ Sa|b ) 13 retourner −−−→ Sa|b|c La proposition ci-dessous résume les conditions pour lesquelles l’algorithme 24 retournera un résultat exact. Proposition 3. Soient Ba, Bb et Bc trois bases RNS telles que MaMb > 3P, avec blog2 Mac = blog2 Mbc et Mc > 12P + M2 a . Alors la sortie −−−→ Sa|b|c de l’algorithme 24 est telle que Sa|b|c < 3P et Sa|b|c ≡ Gk mod P. Si nous revenons à l’exemple RSA 2048 bits avec n = 66 et w = 32, nous pouvons remarquer que nous avons déjà MaMb > 3P, puisque MaMb est un entier de 2112 bits, contre 2050 pour 3P. Ensuite, la condition Mc > 12P + M2 a implique, entre autres, que log2 Mc > 2113, on aura donc au moins un moduli de Bc avec un bit supplémentaire (2113 = 66 · 32 + 1). Pour conclure, on peut noter que la modification effectuée pour le cas ki = 1 n’altère pas la représentation de Montgomery. En effet, lorsque ki = 1, nous calculons la réduction modulaire MR sur la valeur U2, avec U2 ≡ S 2R2G mod P, le résultat est donc bien S 2RG mod P. Analyse détaillée de l’algorithme Nous allons ci-dessous montrer la borne présentée précédemment dans l’équation 3.8, et en déduire les conditions de la proposition 3. Ensuite nous discuterons du surcoût en terme de pré-calculs nécessaires.120CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS 0.7 0.8 0.9 1.0 1.1 1.2 10 20 30 40 50 60 70 Algo. 24 / RNS−ME n EMM Figure 3.6 – Rapport du nombre d’EMM entre notre algorithme 24 et l’algorithme de l’état de l’art [48]. On rappelle tout d’abord que l’on a toujours Ks <  3P Ma  et Rs < 2Ma (à cause de l’approximation dans l’extension de base de Kawamura et al. [64]). Ensuite, les bases Ba, Bb et Bc sont choisies pour satisfaire les conditions d’utilisation de l’algorithme MR, c’est-à-dire telles que Mc > 3P et MaMb > 3P. On obtient alors la borne suivante sur U2 : U2 = Ks Ks|M2 aG|P + Rs|2MaG|P
+ R 2 s |G|P 6 K2 sP + KsRsP + R 2 sP < 9P 3 M2 a + 6P 2 + M2 aP < P2  3MaMb M2 a + 6 + M2 aP < 12P 2 + M2 aP . De plus, on rappelle que Ba et Bb sont toutes deux composées de n/2 moduli de w bits, donc log2 Mb Ma < 1, autrement dit Mb Ma < 2. Nous allons maintenant déduire les différentes conditions sur les trois bases Ba, Bb et Bc. Tout d’abord, pour que la représentation de U2 soit exacte, il faut MaMbMc > U2. De plus, pour pouvoir effectuer une autre itération de la boucle de l’algorithme 24, il faut qu’en sortie de l’itération on ait S < 3P. Comme pour l’analyse du SPRR, on déduit la condition sur Mc à partir du calcul effectué dans la réduction finale MR. La contrainte est donc U2+QP Mc < 3P. De plus : U2 + QP 3P < U2 3P + 2Mc 3 < 4P + M2 a + 2Mc 3 , (3.9) car Q < 2Mc (Q est la sortie de l’extension de base de Kawamura et al. à partir de Mc). Il suffit donc de choisir Mc > 4P + M2 a+2Mc 3 , c’est-à-dire Mc > 12P + M2 a . L’utilisation de l’algorithme 24 impose de stocker plus de pré-calculs que l’exponentiation de l’état de l’art [48] tout simplement parce que les appels à MR dans l’algorithme sont les mêmes que ceux de l’état de l’art, et requièrent exactement le même nombre de pré- calculs, c’est-à-dire 2n 2 + 10n EMW. De plus, il faut compter les pré-calculs pour la fonction Split. Ceux-ci ont été détaillés dans la table 3.2 pour le cas où na = nb = nc = n/2. Dans notre cas nc = n, ce qui nous mène à n 2 + 4n EMW. Enfin, le calcul de U2 dans chacune des bases requiert 6n EMW pour les 3 valeurs pré-calculées dans chacune des bases. Nous obtenons donc un total de 3n 2 + 20n EMW contre 2n 2 + 10n EMW. 3.3.2 Autres algorithmes d’exponentiation Notre algorithme est basé sur le fait que le motif S 2G mod P se comporte très bien lorsqu’on le décompose avant de calculer la réduction, grâce au fait qu’il y a beaucoup de3.3. EXPONENTIATION RAPIDE RNS SANS HYPOTHÈSE SUR P 121 Algorithme 25: Exponentiation RNS régulière revisitée. Entrée : k = (k`−1, . . . , k1, k0)2 Pré-calculs : −−−−−−−−−−−−−−−−→  M−1 c,i P −1 |GM2 a |P  c , −−−−−−−−−−−−−−−−→  M−1 c,i P −1 |2GMa|P  c , −−−−−−−−−−−→  M−1 c,i P −1G  c dans Bc Pré-calculs : −−−−−−−−−→ |GM2 a |P
a|b , −−−−−−−−−−→ (|2GMa|P )a|b , −−→ Ga|b dans Ba|b Pré-calculs : −−−−−−−−−−−−−−→  M−1 c,i P −1 |M2 a |P  c , −−−−−−−−−−−−−−−→  M−1 c,i P −1 |2Ma|P  c , −−−−−−−−−→  M−1 c,i P −1  c dans Bc Pré-calculs : −−−−−−−−→ |M2 a |P
a|b , −−−−−−−−→ (|2Ma|P )a|b , −−→ 1a|b dans Ba|b Sortie : −−−−→ |Gk |P dans Ba|b|c 1 −−−→ Sa|b|c ← −→ 1 2 pour i de ` − 1 à 0 faire 3 ( −→ Ks , −→ Rs ) ← Split( −→ S ) 4 si ki = 0 alors 5 −−→ Sa|b ← −−−−−→ (Ks)a|b × −−−−−→ (Ks)a|b × −−−−−−−−→ |M2 a |P
a|b + −−−−→ (Rs)a|b × −−−−−−−−→ (|2Ma|P )a|b  6 −−→ Sa|b ← −−→ Sa|b + −−−−→ (Rs)a|b × −−−−→ (Rs)a|b × −−→ 1a|b 7 −→ Sc ← −−−−→ (Ks)c × −−−−−−−−−−−−−−→  M−1 c,i P −1 |M2 a |P  c + −−−−→ (Rs)a|b × −−−−−−−−−−−−−−−→  M−1 c,i P −1 |2Ma|P  c 8 −→ Sc ← −−−−→ (Ks)c × −→ Sc + −−−→ (Rs)c × −−−→ (Rs)c × −−−−−−−−−→  M−1 c,i P −1  c 9 sinon 10 −−→ Sa|b ← −−−−−→ (Ks)a|b × −−−−−→ (Ks)a|b × −−−−−−−−−→ |GM2 a |P
a|b + −−−−→ (Rs)a|b × −−−−−−−−−−→ (|2GMa|P )a|b  11 −−→ Sa|b ← −−→ Sa|b + −−−−→ (Rs)a|b × −−−−→ (Rs)a|b × −−→ Ga|b 12 −→ Sc ← −−−−→ (Ks)c × −−−−−−−−−−−−−−−−→  M−1 c,i P −1 |GM2 a |P  c + −−−−→ (Rs)a|b × −−−−−−−−−−−−−−−−→  M−1 c,i P −1 |2GMa|P  c 13 −→ Sc ← −−−−→ (Ks)c × −→ Sc + −−−→ (Rs)c × −−−→ (Rs)c × −−−−−−−−−−−→  M−1 c,i P −1G  c 14 −−−→ Sa|b|c ← MR( −→ Sc , −−→ Sa|b ) 15 retourner −−−→ Sa|b|c réutilisations (un carré et une multiplication par une constante). Pour d’autres algorithmes, comme l’algorithme 5 carré et multiplication poids faibles en tête, on ne multiplie pas par une constante ce qui, semble-t-il, rend inapplicable l’astuce que nous avons utilisé ici. Il en va de même pour l’échelle de Montgomery, qui peut profiter du SPRR pour l’accélérer mais pas du motif ici présent. On peut par contre adapter notre algorithme pour être régulier, en effectuant une multiplication et un carré à chaque fois. L’algorithme 25 présente un exemple d’adaptation de notre précédent algorithme 24, en version régulière. On utilise en fait la même méthode que pour calculer S 2G mod P pour calculer S 2 · 1 mod P. On remarque alors qu’un tel algorithme coûterait 4n 2 + 8n avec la multiplication RNS de l’état de l’art (coût de 2 MM) par itération de boucle, contre 3n 2 + 13n pour l’algorithme 25 (une réduction de 22.5 % pour RSA-2048 avec n = 66). L’algorithme 25 requiert 6n EMW de plus que sa version non régulière, c’est-à-dire 3n 2 + 26n EMW en tout. Enfin, il est aussi possible d’adapter les algorithmes fenêtrés qui utilisent S 2G mod P,122CHAPITRE 3. DÉCOMPOSITION ET RÉUTILISATION D’OPÉRANDES EN RNS comme la version exponentiation de l’algorithme 7 présenté dans la section 1.1.4. 3.4 Conclusion Dans ce chapitre a été proposée une nouvelle façon d’aborder la multiplication modulaire RNS, dont la caractéristique principale est de pouvoir accélérer les calculs lorsque les opérandes sont réutilisés plusieurs fois, grâce à des décompositions de ces opérandes. Les cas les plus simples de réutilisation sont les multiplications par une constante et les carrés. Nous avons tout d’abord proposé un algorithme de multiplication, permettant l’utilisation d’un nombre réduit de moduli (3n/2 au lieu de 2n pour l’état de l’art). Ainsi, l’algorithme de multiplication proposé réduit le nombre de pré-calculs de 20 % à 25 % pour les paramètres étudiés. De plus, le nombre d’opérations élémentaires peut être réduit jusqu’à 10 % pour des applications cryptographiques sur de grands corps ou entiers (ECC et DH). Ainsi, nous nous attendons à ce que le coût d’une implantation matérielle de l’algorithme soit réduit par rapport à la solution de l’état de l’art sur des applications cryptographiques sur de grands paramètres. La contrainte de cet algorithme est qu’il nécessite une certaine condition sur le corps de base. En reprenant certaines idées de l’algorithme de multiplication modulaire, il est possible de trouver certaines séquences de calcul très efficaces lorsqu’il y a des réutilisations d’opérandes. Nous avons alors proposé un algorithme d’exponentiation qui requiert moins de multiplications que l’algorithme de l’état de l’art. De plus, cet algorithme ne nécessite aucune condition sur le corps ou l’anneau sur lequel on calcule, il est donc utilisable pour les calculs RSA. Nous obtenons une réduction du nombre de multiplications élémentaires de 15 % pour RSA 2048 bits. Une version régulière de l’algorithme est aussi proposée, ré- duisant de 22 % le nombre de multiplications élémentaires, toujours pour RSA 2048 bits, par rapport à un algorithme de type double-and-add always ou échelle de Montgomery. De futurs travaux porteront sur une étude plus approfondie des motifs qui peuvent être accélérés en RNS et sur une implantation matérielle complète, pour étudier plus précisé- ment les gains et les surcoûts obtenus.Chapitre 4 Multiplication modulaire RNS mono-base Dans ce chapitre, un autre algorithme de multiplication modulaire RNS est proposé. Ce nouvel algorithme est applicable pour la multiplication modulo P, pour P bien choisi, dans un contexte de cryptographie sur courbes elliptiques. À notre connaissance, c’est le premier algorithme effectuant une multiplication modulaire sur seulement n moduli, c’est à dire sur une seule base dans les notations classiques. Le nombre d’opérations élémentaires est fortement réduit par rapport à la multiplication RNS de l’état de l’art et la multiplication SPRR du chapitre 3. On obtient de bons résultats même pour des petites valeurs de n. Ces travaux sont en cours, seuls des premiers résultats d’implantation matérielle sont fournis. 4.1 La multiplication modulaire RNS à base unique SBMM Le nouvel algorithme que nous proposons utilise une variation de la représentation RNS, où un élément de FP , noté X, n’est plus représenté par −→ X , mais par −−→ Kx et −→ Rx avec la relation −→ X = −−−−−−−−−→ KxMa + Rx . Nous retrouvons en quelque sorte la décomposition proposée dans le chapitre 3 pour la multiplication SPRR. Dans le chapitre 3, on utilisait cette décomposition pour factoriser certains calculs internes à la multiplication modulaire, les entrées et sorties étant en représentation RNS classique. Dans notre nouvelle proposition, nous représentons les éléments de FP uniquement grâce à ces décompositions. Un élément de FP , noté X, sera donc maintenant représenté par la paire de vecteurs RNS ( −−→ Kx , −→ Rx ). Chacun des vecteurs −−→ Kx et −→ Rx est défini sur n moduli, au lieu d’avoir un seul vecteur RNS, −→ X , sur 2n moduli comme dans l’état de l’art. Notre nouvel algorithme de multiplication modulaire, appelé SBMM pour single base modular multiplication, est présenté algorithme 26. Avant de détailler les conditions sur ses entrées, sorties et évaluer son coût, nous allons présenter les idées sous-jacentes. Tout d’abord, par soucis de clarté, nous allons découper la base RNS en deux demi-bases Ba et Bb de n/2 moduli (un peu comme pour le SPRR sauf qu’il n’y a maintenant plus que 2 demi-bases). Nous rappelons que Ma désigne le produit des éléments de Ba (ici produit de n/2 moduli). La première idée importante de l’algorithme est l’utilisation de cette représentation décomposée, nous allons voir ci-dessous comment l’algorithme tire parti de celle-ci. La deuxième idée de notre nouvel algorithme SBMM est de lier Ma et P via la condition M2 a = P + c, avec c très petit. Les meilleurs résultats sont obtenus avec M2 a = P + 2, nous allons nous tenir à ce cas pour la présentation de l’algorithme. Pour c quelconque, 123124 CHAPITRE 4. MULTIPLICATION MODULAIRE RNS MONO-BASE Algorithme 26: Multiplication modulaire RNS mono-base SBMM. Paramètres : Ba tel que M2 a = P + 2 et Bb tel que Mb > 6Ma Entrées : −−−−−→ (Kx)a|b , −−−−−→ (Rx)a|b , −−−−−→ (Ky)a|b , −−−−−→ (Ry)a|b avec Kx, Rx, Ky, Ry < Ma Sorties : −−−−−→ (Kz)a|b , −−−−−→ (Rz)a|b avec Kz < 5Ma et Rz < 6Ma 1 −−→ Ua|b ← −−−−−−−−−−−→ 2KxKy + RxRy 2 −−→ Va|b ← −−−−−−−−−−−→ KxRy + RxKy /*astuce de Karatsuba-Ofman utilisable ici*/ 3 −−−−−→ (Ku)a|b , −−−−−→ (Ru)a|b  ← CSplit( −−→ Ua|b ) 4 −−−−−→ (Kv)a|b , −−−−−→ (Rv)a|b  ← CSplit( −−→ Va|b ) 5 retourner −−−−−−−−−→ (Ku + Rv)a|b , −−−−−−−−−−−→ (2 · Kv + Ru)a|b  une démonstration générale sera proposée dans la section 4.2.1. Cette contrainte étant très forte, elle ne peut être appliquée que dans le cadre d’ECC, et pas sur le logarithme discret à la différence de SPRR. Nous allons voir que cette condition va permettre d’effectuer la multiplication modulaire RNS de manière analogue à ce qui est proposé dans les standards ECC du NIST [91] pour la représentation binaire classique, c’est-à-dire analogue à la multiplication modulo un nombre premier pseudo-Mersenne en base 2. L’algorithme SBMM vient du constat suivant. Supposons que X et Y soient deux éléments de FP , et soient (Kx,Rx) et (Ky,Ry) leurs décompositions en quotient/reste par Ma. On rappelle que Ma est le produit des éléments de Ba. Alors en calculant le produit XY , on obtient : XY = KxKyM2 a + (KxRy + KyRx)Ma + RxRy mod P (4.1) ≡ 2 KxKy + RxRy + (KxRy + KyRx)Ma mod P (4.2) ≡ 2 KxKy + RxRy + (KxKy + RxRy − (Kx − Rx)(Ky − Ry))Ma mod P (4.3) ≡ U + V Ma mod P (4.4) grâce au fait que M2 a mod P = 2. Ce résultat ressemble à l’équation 3.2 obtenue au chapitre 3, mais avec des contraintes différentes. Le passage de l’équation 4.2 à l’équation 4.3 est juste une application de l’astuce de Karatsuba-Ofman [63]. On remarque qu’on ne peut pas calculer l’équation 4.4 avec seulement n moduli car V Ma est un entier de 3` 2 bits (et nécessite donc 3n 2 moduli pour être représenté). Par contre, U et V sont eux représentables dans notre base Ba|b , on peut donc les calculer avec U = (2KxKy + RxRy) et V = (KxRy + KyRx). Cela vient du fait que Kx, Ky, Rx, Ry < Ma et Mb > 6Ma, on obtient donc U, V < 3M2 a < MaMb. Le calcul de U et V ne requiert que des opérations efficaces en RNS (multiplications et additions). Ensuite, on peut découper U et V grâce à l’algorithme 27, noté CSplit pour compact split, qui exécute en fait la même fonction que Split du chapitre 3, mais pour seulement 24.1. LA MULTIPLICATION MODULAIRE RNS À BASE UNIQUE SBMM 125 demi-bases. En utilisant une nouvelle fois la propriété M2 a = P + 2 on obtient finalement : XY ≡ U + V Ma mod P ≡ KuMa + Ru + KvM2 a + RvMa mod P ≡ (Ku + Rv)Ma + Ru + 2Kv mod P ≡ KzMa + Rz mod P. Dans cette équation, Kz < 4Ma et Rz < 5Ma, ce qui implique que KzMa + Rz < 5 P. Nous avons ainsi réduit le produit, ou presque, car quelques soustractions par P peuvent être requises. De même, Kz et Rz peuvent être un peu plus grands que les entrées Kx, Rx, Ky et Ry, à quelques soustractions par Ma près. La démonstration de ces bornes et les consé- quences de la différence entre les tailles des entrées et celles des sorties seront détaillées dans la section 4.2.3. Algorithme 27: Étape de décomposition compacte CSplit. Entrée : −−→ Xa|b Pré-calculs : −−−−−−→ M−1 a
b Sorties : −−−−−→ (Kx)a|b , −−−−−→ (Rx)a|b avec −−→ Xa|b = −−−−−→ (Kx)a|b × −−−−−→ (Ma)a|b + −−−−−→ (Rx)a|b 1 −−−−→ (Rx)b ← BE −−−−→ (Rx)a , Ba, Bb  2 −−−−→ (Kx)b ← −→ Xb − −−−−→ (Rx)b  × −−−−−−→ M−1 a
b 3 si −−−−→ (Kx)b = −→ −1 alors 4 −−−−→ (Kx)b ← −→ 0 /* correction d’une erreur avec la BE de Kawamura */ 5 −−−−→ (Rx)b ← −−−−→ (Rx)b − −−−−→ (Ma)b 6 −−−−→ (Kx)a ← BE −−−−→ (Kx)b , Bb, Ba  7 retourner −−−−−→ (Kx)a|b , −−−−−→ (Rx)a|b Pour résumer, on peut considérer que les valeurs sont représentées en numération de position de base Ma, avec une « partie haute » Kx et une « partie basse » Rx, Kx et Rx étant représentées en RNS en base Ba|b par −−−→ (Kx) a|b et −−−→ (Rx) a|b . On applique ensuite deux fois la propriété P+2 = M2 a , qu’on peut qualifier de propriété « à la Mersenne », pour réduire notre valeur. La similitude avec la réduction modulo un premier pseudo-Mersenne vient du fait que, dans les 2 cas, la multiplication modulaire se résume à découper le résultat du produit en utilisant la forme de P, puis à additionner les morceaux obtenus. Dans notre algorithme SBMM, deux découpages intermédiaires, pour U et V , en partie haute et partie basse sont nécessaires entre les deux applications de P + 2 = M2 a . Une grosse différence avec une multiplication modulo un premier pseudo-Mersenne en représentation classique est, qu’ici, ce n’est pas la partie multiplication qui est coûteuse, mais le découpage en partie haute et partie basse (alors qu’en représentation binaire classique, cette opération est gratuite). Dans l’algorithme 26, les lignes 1 et 2 calculent U et V : on applique une première fois M2 a = P + 2. Ensuite les lignes 3 et 4, découpent U et V grâce à la fonction CSplit, ce qui représente 4 extensions de base. Cependant, ces 4 extensions de bases ne portent que sur les deux demi-bases Ba et Bb. Puisque le coût d’une extension est quadratique en n, le coût126 CHAPITRE 4. MULTIPLICATION MODULAIRE RNS MONO-BASE de ces 4 petites extensions est équivalent au coût d’une seule grande entre deux bases de n moduli chacune. Nous allons voir dans la section 4.2.4 que notre algorithme coûte bien moins de multiplications élémentaires EMM que l’algorithme de l’état de l’art et qu’il en va de même pour le nombre de pré-calculs EMW. 4.2 Analyse de l’algorithme SBMM 4.2.1 Généralisation du paramètre c Dans l’analyse de cet algorithme 26, nous allons étudier le cas plus général P +c = M2 a , avec c un petit nombre positif, et démontrer les bornes que cela induit. Tout d’abord, on remarque que c ne doit pas être un carré, sinon P = M2 a − c = (Ma + √ c)(Ma − √ c) , c’est à dire P n’est pas premier. Le plus petit c possible est 2, avec Ma impair (c’est à dire Ba n’est composée que d’éléments impairs). Nous n’étudierons pas ici le cas c négatif, car il introduit un certain nombre de valeurs négatives qu’il faut pouvoir gérer correctement en RNS. Le cas c négatif semble donc moins intéressant. Pour commencer, nous allons dans un premier temps supposer que les extensions de base sont exactes, par exemple en utilisant les extensions de base via MRS. Les valeurs qui sont transférées d’une base à l’autre, comme Ru ou Ku, sont donc transférées sans erreur d’approximation. En suivant le même cheminement que dans la section précédente, mais pour un c quelconque, on obtient : XY ≡ c KxKy + RxRy + (KxRy + KyRx)Ma mod P ≡ U + V Ma mod P ≡ (Ku + Rv)Ma + Ru + cKv mod P ≡ KzMa + Rz mod P . Ici, seules les expressions de U et Rz changent, devenant U = c KxKy + RxRy et Rz = Ru + cKv. Nous allons maintenant démontrer les bornes sur Ma et Mb. Pour représenter U et V sur la base Ba|b , il faut que U, V < MaMb. On peut borner U et V par : U = c KxKy + RxRy < cM2 a + M2 a 6 (c + 1)M2 a V = KxRy + KyRx < 2M2 a . Il suffit donc que Mb > (c + 1)Ma pour représenter U et V (on rappelle que c > 2). Il nous faut maintenant être en mesure de représenter les valeurs en sortie, Kz et Rz. On rappelle que Ku est le quotient de U par Ma, et que U < (c + 1)M2 a , on a donc Ku < (c + 1)Ma. Par définition, Ru étant le reste de la division on a Ru < Ma. De même on a Kv < 2Ma et Rv < Ma. On en conclut : Kz = Ku + Rv < (c + 2)Ma Rz = Ru + cKv < (2c + 1)Ma .4.2. ANALYSE DE L’ALGORITHME SBMM 127 On va donc choisir Bb pour avoir Mb > (2c + 1)Ma. En prenant c = 2, on obtient Kz < 4Ma et Rz < 5Ma. On ne retrouve pas exactement les bornes du cas c = 2 de l’algorithme 26 pour les sorties Kz et Rz car celles-ci sont calculées pour l’extension de base de Kawamura et al. [64]. On remarque par contre que les éléments en sortie sont plus grands que ceux en entrée : pour limiter cette croissance on choisira c le plus petit possible. Avec une demi-base Ba ne contenant que des éléments impairs, on peut facilement trouver des bases avec M2 a = P + 2 et P premier. Si on préfère une base Ba avec un moduli pair, on ne peut alors pas avoir mieux que M2 a = P + 3. Avoir un peu de latitude sur c peut être intéressant pour avoir un plus grand choix de bases. On peut même encore augmenter ces choix en cherchant des bases avec M2 a = µP + c avec µ très petit. Bien sûr, en se donnant plus de choix pour P on est contraint d’agrandir encore la base Mb. 4.2.2 Utilisation de l’extension de base de Kawamura et al. Considérons maintenant l’utilisation de l’extension de base de Kawamura et al. [64]. Comme pour le SPRR et pour MM, on ne peut pas effectuer de manière exacte la première extension de base en utilisant l’extension de base de Kawamura et al. [64], nous sommes dans le cas du théorème 5. La stratégie sera ici la même que pour le SPRR. Si il y a une erreur, elle se produira lors du calcul de −−−−→ (Ru)b (respectivement −−−→ (Rv)b ) à la ligne 1 de l’algorithme 27. Supposons que l’extension de base produise par erreur −−−−→ (R0 u )b avec −−−−→ (R0 u )b = −−−−−−−−→ (Ru + Ma)b (resp. −−−→ (R0 v )b = −−−−−−−−→ (Rv + Ma)b ) dans la base Bb. Alors, le calcul à la ligne 2 de l’algorithme 27 donne : −−−−→ (K0 u )b = −→ Ub − −−−−→ (R 0 u )b  × −−−−−−→ M−1 a
b = −→ Ub − −−−−→ (Ru)b − −−−−→ (Ma)b  × −−−−−−→ M−1 a
b = −−−−−−−→ (Ku − 1)b . Le calcul ne change donc rien au fait que U = K0 uMa + R0 u dans la base Bb. Par contre, si Ku = 0, il est possible que l’on ait K0 u = −1, impliquant une réduction implicite par Mb dans la demi-base Bb, ce qui empêche de retourner le bon résultat lors de la deuxième extension de base à la ligne 3 de l’algorithme 27. Pour contrer ce problème, il suffit de vérifier que K0 u 6= −1 dans la base Bb. Si K0 u = −1 dans Bb, alors on corrige en effectuant −−−−→ (Ku)b = 0 et −−−−→ (Ru)b = −−−−−−−−→ (R0 u + Ma)b dans la seconde base après la ligne 2 de l’algorithme 27 et avant l’extension de base. Le comparateur utilisé pour K0 u 6= −1 est déjà présent en matériel si on utilise l’algorithme d’inversion PM-MI (cf. chapitre 2). Nous n’avons pas approfondi d’autres solutions pour régler ce cas spécial car il n’arrivera pas, en pratique, dans la plupart des applications. En effet, supposons que X soit un élément quelconque de FP d’au moins 160 bits, ce qui est le plus petit standard du NIST [91]. Alors, avoir Kx = 0 est équivalent à avoir X < Ma, avec log2 Ma ≈ 80 bits au minimum, plus généralement log2 Ma ≈ `/2. On a donc une probabilité 1 2 80 de tomber sur Kx = 0. En dehors de la gestion de ce cas très particulier, il est aussi à noter que les valeurs Kz et Rz sont potentiellement plus grandes en utilisant une extension de base approchée. Plus exactement, avec l’extension de base de Kawamura et al., on obtient les bornes Ru, Rv < 2Ma, ce qui implique : Kz = Ku + Rv < (c + 3)Ma Rz = Ru + cKv < (2c + 2)Ma . On retrouve bien les bornes présentées dans l’algorithme 26 sur Kz et Rz.128 CHAPITRE 4. MULTIPLICATION MODULAIRE RNS MONO-BASE 4.2.3 Compression des sorties de l’algorithme Nous allons maintenant discuter du problème de la taille des sorties de l’algorithme. En effet, par exemple si c = 2, les entrées de l’algorithme sont inférieures à Ma alors qu’en sortie on a Kz < 5Ma et Rz < 6Ma. Ainsi en réappliquant successivement SBMM, on obtient Kz,2 < 87Ma et Rz,2 < 121Ma puis Kz,3 < 29780Ma et Rz,2 < 42109Ma etc. La taille des opérandes va ainsi croître de façon exponentielle si on applique récursivement et sans contrôle l’algorithme SBMM. Une première façon de procéder pour ce contrôle est d’effectuer une nouvelle réduction après un certain nombre d’itérations. Nous verrons dans l’exemple proposé à la fin de cette sous-section que dans les calculs nécessaires aux doublements et additions de points d’ECC, un certain nombre de multiplications sont complètement indépendantes. Ainsi, si par exemple 4 multiplications indépendantes sont effectuées, leurs sorties ont toutes la même taille. On doit donc déduire du flot de calcul la taille maximale des sorties de l’algorithme SBMM afin de choisir Mb suffisamment grand pour garantir X = KxMa+Rx < MaMb. Comme la taille des sorties croît très vite, seulement 2 ou 3 multiplications successives peuvent être effectuées avant une réduction modulaire de contrôle. Pour effectuer cette réduction à partir de notre algorithme, il suffit de l’appliquer sur la valeur à réduire, par exemple (Kz,Rz), et la valeur 1, représentée par (0,1). Algorithme 28: Compression d’une valeur représentée par (K, R). Entrées : −−−−−→ Ka|b|mγ et −−−−−→ Ra|b|mγ avec K, R < mγ − 1 Pré-calcul :  M−1 a   mγ Sorties : −−−−−−−→ (Kc)a|b|mγ , −−−−−−−→ (Rc)a|b|mγ avec Kc, Rc < 2Ma + 6 1 |Rk|mγ ← BE −−→ Ka , Ba, mγ  /* −−−−→ (Rk)a = −−→ Ka */ 2 Kk ←  (K − Rk)M−1 a   mγ 3 −−−→ (Rk)b ← −→ Kb − −−−−→ (Kk)b × −−−−→ (Ma) b 4 |Rr|mγ ← BE −→ Ra , Ba, mγ  /* −−−−→ (Rr)a = −→ Ra */ 5 Kr ←  (R − Rr)M−1 a   mγ 6 −−−→ (Rr)b ← −→ Rb − −−−−→ (Kr)b × −−−−→ (Ma) b 7 return −−−−−−−−−−−−→ (Kr + Rk)a|b|mγ , −−−−−−−−−−−−→ (Rr + 2Kk)a|b|mγ Une autre méthode, plus rapide mais nécessitant un peu de matériel supplémentaire, est présentée dans l’algorithme 28. Il suffit de remarquer que les valeurs en sortie de l’algorithme Kz et Rz, sont proches de Ma. En effet, on a Kz < 5Ma et Rz < 6Ma. Soit ( −→ K a|b , −→ R a|b ) une valeur en sortie de l’algorithme 26. Supposons qu’on décompose K en K = KkMa + Rk et R en R = KrMa + Rr. On a alors Kk < 5 et Kr < 6. On peut donc calculer une extension de base à partir de Ba vers un modulo supplémentaire mγ, premier avec Ma, puis obtenir la valeur exacte de ces quotients, du moment que mγ > 6. Il faut quand même avoir K mod mγ et R mod mγ dans ce modulo supplémentaire avant de pouvoir faire la division. On peut choisir mγ comme une petite puissance de 2, et choisir un élément de Bb, disons mb,1, égal à 2 w. On peut ensuite déduire directement la valeur de K mod mγ et R mod mγ à partir des bits de poids faibles modulo mb,1. On remarque que puisque Kr et Kk sont très petits, nous n’avons pas besoin d’extension de base pour les représenter dans4.2. ANALYSE DE L’ALGORITHME SBMM 129 Opération P1 + P2 2 P1 A = Z1X2 + Z2X1 E = Z 2 1 B = 2X1X2 F = 2X1Z1 C = 2Z1Z2 G = X2 1 Formules D = aA + bC H = −4bE Z3 = A2 − BC I = aE X3 = BA + CD + 2XGZ3 X3 = F H + (G − I) 2 Z3 = 2F(G + I) − EH Table 4.1 – Formules optimisées RNS issues de [8] pour les courbes sous forme de Weierstrass courte, en coordonnées (X, Z) et adaptées à l’échelle de Montgomery. Ba et Bb. En effet, on a (kr)a,i = (kr)b,i = Kr et (kk)a,i = (kk)b,i = Kk pour tout i. Après avoir obtenu Kk et Kr, on peut utiliser le fait que M2 a = 2 mod P pour obtenir : X ≡ KMa + R mod P ≡ KkM2 a + RkMa + KrMa + Rr mod P ≡ (Rk + Kr)Ma + 2Kk + Rr mod P ≡ KcMa + Rc mod P . La valeur retournée par la compression est donc (Kc, Rc). On note que Rk et Rr sont tous deux inférieurs à 2Ma si on utilise l’extension de base de Kawamura et al., impliquant Kc < 2Ma + 6 et Rc < 2Ma + 10. Si deux valeurs (Kx, Rx) et (Ky, Ry) provenant d’une compression à l’aide de l’algorithme 28 sont utilisées en entrée de l’algorithme 26 de multiplication SBMM, on obtient alors en sortie Kz < 14Ma et Rz < 19Ma au lieu de Kz < 5Ma et Rz < 6Ma. Pour pouvoir réutiliser l’algorithme de compression, il suf- fit de prendre mγ > 19. Le plus simple est de prendre mγ = 32, en choisissant la base Ba sans modulo pair. Pour ne pas avoir besoin d’utiliser systématiquement la fonction de compression, on peut augmenter la valeur de mγ afin d’augmenter la correction maximale que l’on peut effectuer. Par exemple, si on enchaîne deux multiplications modulaires sans utiliser de compression, on obtient en sortie Kz < 753Ma et Rz < 1065Ma. En prenant mγ = 211 = 2048, on peut se permettre de n’effectuer qu’une compression toutes les 2 multiplications. Nous allons voir maintenant un exemple pour lequel il est utile de n’effectuer qu’une compression toutes les 2 multiplications. Un exemple d’utilisation de la fonction de compression est illustré à la figure 4.1. Dans cette exemple, on suppose l’exécution d’une addition de points suivie d’un doublement, avec les formules de la table 4.1 (issues de [8]). On utilise l’algorithme de multiplication SBMM pour calculer les différentes valeurs intermédiaires des formules, et le résultat est compressé en parallèle par la fonction de compression. Pour presque tous les calculs, l’algorithme SBMM reçoit en entrée des valeurs compressées. Il y a deux cas pour lesquels SBMM va recevoir en entrée des valeurs qui ne l’ont pas été. Le premier cas est le calcul de X3 dans l’opération ADD. En effet, le calcul de X3 dans ce cas requiert la valeur Z3, qui n’a pas encore eu le temps d’être compressée : on est donc obligé de prendre directement le résultat de la multiplication SBMM. On se retrouve donc dans le cas où mγ est choisi pour pouvoir enchaîner 2 multiplications SBMM, celle de Z3 et celle de X3. On compressera directement X3 ensuite. On retrouve un cas similaire pour le calcul de X3 dans le calcul DBL, où la130 CHAPITRE 4. MULTIPLICATION MODULAIRE RNS MONO-BASE A C B D Z3 X3 E F G H I X3 Z3 A C B D Z3 X3 E F G H I X3 Z3 · · · · · · ADD DBL SBMM Compression temps Figure 4.1 – Exemple fictif de flot d’exécution utilisant SBMM et la fonction de compression en parallèle, sur les formules d’addition et doublement de points définies à la table 4.1, avec 2 dépendances de données non satisfaites à temps entre la compression et SBMM. valeur I, qui n’a pas encore été compressée, est utilisée. Finalement, cet exemple présente une façon d’effectuer le SBMM et la fonction de compression en parallèle, qui pourra être implantée dans le futur pour une multiplication scalaire complète. 4.2.4 Analyse des coûts en EMM et EMW Pour commencer nous allons analyser le coût de l’algorithme 26 en nombre d’opé- rations. Nous allons nous contenter de compter ici les multiplications élémentaires EMM, comme sont faits habituellement les décomptes de l’état de l’art et comme ce qui a été fait pour le chapitre 3. Dans tous les cas, que ce soit pour notre algorithme ou pour l’état de l’art, les nombres d’EMM et d’EMA sont égaux (ou presque), car les deux algorithmes n’effectuent quasiment que des multiplications suivies d’accumulations. De plus, dans le cas de l’algorithme 26, nous n’allons pas compter les multiplications par 2 que l’on trouve aux lignes 1 et 5 car on peut les voir comme une simple addition. Les lignes 1, 2 et 5 de l’algorithme SBMM coûtent 4n EMM, qui peuvent être réduites à 3n EMM en utilisant l’astuce de Karatsuba-Ofman [63] pour calculer les lignes 1 et 2. Le choix de l’utilisation de cette astuce dépend de l’architecture implantée, car elle introduit notamment des dépendances de données entre les lignes 1 et 2, alors qu’elles sont indépendantes telles qu’écrites dans l’algorithme SBMM. En plus de ces opérations, on effectue deux appels à CSplit. Le coût de CSplit est en fait le même que celui de la fonction Split, en considérant que les 2 premières bases ont le même nombre d’éléments égal à n/2, et que la troisième base n’a aucun élément. On obtient, pour chacun des appels de CSplit, un nombre d’EMM de : na + na(nb + nc) + nb + nbna + nc = 2  n 2 4 + n 2  = n 2 2 + n . Le coût total de l’algorithme est donc n 2 + 5n EMM pour effectuer une multiplication modulo P, contre 2n 2 + 4n avec l’algorithme de l’état de l’art [48]. Par contre, ce coût ne prend pas en compte une éventuelle compression des données en sortie. La fonction de compression proposée dans l’algorithme 28 effectue 2 extensions de base de Ba vers mγ4.2. ANALYSE DE L’ALGORITHME SBMM 131 aux lignes 1 et 4, puis 2 multiplications sur mγ aux lignes 2 et 5, et finalement 2 multiplications sur Bb. Les extensions de base coûtent n/2 EMM sur Ba et n/2 multiplications sur mγ chacune. On compte ici les multiplications modulo mγ à part, car généralement ces multiplications seront sur 5, 6 ou 12 bits alors que les EMM correspondront à des multiplications sur w bits (16 ou 32 par exemple). De plus, une EMM est une multiplication modulo un nombre pseudo-Mersenne, alors que mγ est une puissance de 2 : la réduction modulaire est donc immédiate pour mγ. On notera γEMM ces multiplications modulo mγ. On obtient au total 2n EMM et (n + 2) γEMM. Le coût total de l’algorithme SBMM suivi de la fonction de compression est donc de n 2 + 7n EMM et (n + 2) γEMM contre 2n 2 + 4n EMM dans l’état de l’art. On a donc divisé par 2, environ, le nombre d’EMM par rapport à l’état de l’art. Nous allons maintenant analyser la parallélisation que propose l’algorithme SBMM et la fonction de compression, car c’est une caractéristique essentielle de la représentation RNS. Dans l’état de l’art, on utilise généralement n unités arithmétiques, par exemple n Rowers, qui correspondent à un élément pour chacune des bases. Dans l’algorithme de l’état de l’art, on utilise uniquement des opérations sur des bases complètes de n moduli, qui se parallélisent donc très bien sur les n Rowers. Notre algorithme 26 calcule, lui, sur les 2 « demi-bases » Ba et Bb de n/2 moduli. Plus précisément, on trouve 2 cas distincts. Soit l’algorithme 26 effectue la même opération sur les deux bases en même temps, comme aux lignes 1, 2 et 5. Dans ce cas, on peut voir Ba|b comme une base complète de n moduli, et paralléliser sur les n Rowers comme d’habitude. Soit, les 2 appels à CSplit, lignes 3 et 4, n’effectuent leurs calculs que sur l’une des 2 demi-bases à la fois. Chacun des CSplit va donc opérer sur seulement n/2 moduli. Ce n’est en réalité pas un problème car les 2 appels à la fonction CSplit sont complètement indépendants : on peut donc les effectuer en parallèle, chacun sur n/2 moduli. Toutes les opérations de l’algorithme 26 sont donc parallélisables sur n Rowers facilement, comme pour l’algorithme de l’état de l’art MM [99] et ses améliorations [6, 48, 64]. La fonction de compression, présentée algorithme 28, est proposée pour une architecture où les calculs sur mγ peuvent être effectués en parallèle des calculs sur les bases Ba et Bb. Par exemple, en ayant une sorte de petit Rower supplémentaire, calculant modulo 2 6 ou 2 12. Ainsi, les lignes 2, 5, et les opérations sur mγ à l’intérieur des extensions de base sont faites en parallèle des autres calculs sur les 2 bases Ba et Bb. Ensuite, les calculs aux lignes 3 et 6, effectués sur la base Bb, sont complètement indépendants : ils peuvent être effectués en même temps, chacun sur n/2 Rowers. Il en va de même pour les calculs sur Ba effectués par les deux BE aux lignes 1 et 4. La table 4.2 présente le décompte des pré-calculs pour notre nouvel algorithme. Les pré- calculs du SBMM viennent tous des pré-calculs nécessaires à la fonction CSplit, qui utilise exactement les mêmes astuces que Gandino et al. [48] pour effectuer les extensions de base. Par exemple, les valeurs dans Bb sont multipliées par le pré-calcul −−−−−→ T −1 b
b , de la même façon que Gandino et al. ont proposé dans [48]. La différence avec la contribution [48], c’est qu’ici on opère sur des demi-bases, et que nous ne faisons plus les calculs pour la réduction de Montgomery mais pour la fonction de décomposition CSplit. Les n/2 valeurs −−−−−→ T −1 a
a et les n 2/4 −−−−−−−−→  −1 ma,iMb,j  b permettent d’effectuer la première extension de base de CSplit, effectuée à la ligne 1 de l’algorithme CSplit, et permettent d’effectuer en même temps − −−−−→ (Rx)b × −−−−−−→ M−1 a
b de la ligne 2. Cette contraction d’opérations requiert le stockage de la valeur −−−−−−→ (−Ma) b pour obtenir −−−−→ (Rx)b , car on obtient − −−−−→ (Rx)b × −−−−−−→ M−1 a
b à la sortie132 CHAPITRE 4. MULTIPLICATION MODULAIRE RNS MONO-BASE SBMM Compression −−−−−→ T −1 a
a : n/2 −−−−−−−−−−−→ −Ma × T −1 b
b : n/2 −−−−−−−−→  −1 ma,iMb,j  b : n 2/4 |Ma,i|mγ : n/2* −−−−−−→  Mb,j Ma  b : n/2 |−Ma|mγ : 1* −−−−→ (Tb,i) a : n 2/4  M−1 a   mγ : 1* −−−−−−→ (−Ma) b : n/2 −−−−−→ T −1 b
b : n/2 −−−−−−→ (−Mb)a : n/2 −−−→ (Tb) b : n/2 Total : n 2/2 + 4n + 2 EMW Table 4.2 – Décompte du nombre de pré-calculs à stocker en mots de w bits (EMW) de notre algorithme SPRR. Note * : les valeurs notées * sont en réalité plus petites que w bits. Algorithme coût en multiplications coût en mémoire pré-calculée MM 2n 2 + 4n EMM 2n 2 + 10n EMW SBMM n 2 + 5n EMM n 2 2 + 3n EMW SBMM + compression (n 2 + 7n) EMM + (n + 2) γEMM n 2 2 + 4n + 2 EMW ÷2 ÷4 Table 4.3 – Comparaison du nombre de multiplications élémentaires et du nombre de mots mémoire élémentaires à stocker pour les algorithmes MM et SBMM, avec et sans compression des sorties. de la première extension de base. Le vecteur −−−−−−→  Mb,j Ma  b permet d’effectuer −→ Xb × −−−−−−→ M−1 a
b . Les valeurs −−−−→ (Tb,i) a et −−−−−−→ (−Mb)a sont utilisées pour la deuxième extension de base de la fonction CSplit. Pour la compression, −−−−−−−−−−−→ −Ma × T −1 b
b sert à calculer −−−→ (Rk)b et −−−→ (Rr)b aux lignes 3 et 6 de l’algorithme 28. Si on stocke −−−−−−−−−−−→ −Ma × T −1 b
b plutôt que −−−−−−→ (−Ma) b , c’est parce que dans la seconde demi-base Bb, les valeurs sont toutes multipliées par −−−−−→ T −1 b
b car on utilise la représentation de Gandino et al. [48]. Ensuite, les n/2 valeurs |Ma,i|mγ sont nécessaires pour calculer le CRT modulo mγ, et |−Ma|mγ permet de corriger le calcul du CRT avec l’astuce de Kawamura et al. [64]. Enfin,  M−1 a   mγ permet de calculer Kk et Kr dans l’algorithme 28. La table 4.3 résume et compare les coûts en calcul et en mémoire entre l’algorithme de l’état de l’art MM et l’algorithme SBMM, avec et sans compression des sorties de celui-ci.4.3. IMPLANTATION FPGA 133 4.3 Implantation FPGA Nous allons présenter dans cette section nos premiers résultats d’implantation. Ce sont des résultats partiels, car les implantations ont été effectuées durant la rédaction du document de thèse. Ils ne sont pas encore suffisamment optimisés, l’architecture devrait notamment être modifiée pour mieux profiter de notre algorithme. Nous nous sommes ici comparés aux multiplieurs modulaire RNS, tels qu’implantés pour le chapitre 2 sur l’inversion modulaire RNS PM-MI. Des premiers gains intéressants sont observés et présentés ci-dessous. 4.3.1 Architecture implantée Tout d’abord, afin d’effectuer une implantation matérielle, il faut générer les diffé- rents paramètres de notre représentation. Pour des paramètres w et n choisis, nous avons tiré au hasard n/2 éléments parmi les nombres pseudo-Mersenne impairs de la forme ma,i = 2w − ha,i, avec ha,i < 2 w 2 . Avant d’inclure un nouvel élément dans la base, on vérifie qu’il soit bien premier avec le produit des éléments déjà sélectionnés. Arrivé à n/2 éléments, on teste si P = M2 a + 2 est un nombre premier. La fonction de test utilisée est simplement la fonction isprime de Maple, qui n’effectue qu’un test probabiliste. Il est extrêmement probable que le P trouvé soit premier, mais un test déterministe de primalité devrait être effectué pour une réelle implantation cryptographique sur le P choisi. Générer les P pseudo-premiers est rapide, puisqu’en 15 secondes Maple génère plus de 10 000 P différents de 512 bits, correspondants à 10 000 bases Ba différentes. Une fois P et la base Ba déterminés, il ne manque plus qu’à choisir une base Bb qui soit composée de nombres premiers avec Ma, de sorte à remplir la condition Mb > 6Ma (au minimum). Pour pouvoir utiliser la fonction de compression, on rappelle que la condition est en fait Mb > 19Ma, on a donc Mb qui a 5 bits de plus que Ma. La figure 4.2 présente l’architecture implantée de notre algorithme SBMM. Notre implantation utilise ici n/2 Rowers « habituels », et un petit Rower supplémentaire. Le petit Rower supplémentaire est en fait dédié à la seconde base, car elle est doit être plus grande que la première comme expliqué précédemment. Dans nos implantations, la base Ba est constituée de n/2 moduli de w bits, et la base Bb est composée de n/2 moduli de w bits et d’un petit modulo de 6 bits. Le petit Rower est dédié à ce modulo de 6 bits, que l’on prend égal à 2 6 . On rappelle que Mb est plus long d’au moins 5 bits que Ma pour pouvoir utiliser la fonction de compression. Si dans nos résultats d’implantation le modulo supplémentaire est de 6 bits, c’est dû à une estimation de la condition d’utilisation grossière de la fonction de compression que nous avions faite dans un premier temps. La figure reprend les mêmes codes que la figure 2.2 présentée dans le chapitre 2. Les petits cercles sont toujours les signaux de contrôle et les carrés sont toujours la sélection des 6 bits de poids forts parmi les w bits entrant. On a rajouté ici des petits rectangles permettant de passer de 6 bits à w bits, tout simplement en concaténant w − 6 zéros devant les 6 bits entrant. Cela permet un contrôle plus simple, car on considère la sortie du petit Rower comme celle des autres Rowers pour les extensions de base. Les Rowers utilisés sont les mêmes que ceux implantés dans le chapitre 2 pour l’inversion PM-MI, et le petit Rower supplémentaire lui est très simple, car il calcule simplement des opérations modulo 2 6 . Comme les autres Rowers, il est doté de 6 étages de pipeline, afin de simplifier le contrôle. Ce modulo supplémentaire n’est pas obligatoire pour obtenir134 CHAPITRE 4. MULTIPLICATION MODULAIRE RNS MONO-BASE canal 1 rower 1 w w x1 y1 w canal 2 rower 2 w w x2 y2 w . . . canal n 2 rower n 2 w w x n 2 y n 2 w canal n 2 + 1 rower n 2 + 1 6 6 x n 2 +1 y n 2 +1 6 6 cox . . . 1 6 w Sortie w w w w CTRL Figure 4.2 – Architecture de la multiplication modulaire SBMM implantée, avec un modulo de 6 bits supplémentaire pour la base Bb. Mb plus grand de 5 bits que Ma. En effet, on peut aussi choisir la base Bb avec des moduli de w + 1 bits au lieu de w bits. L’avantage d’une telle solution est que, premièrement, elle peut être moins chère en surface que notre implantation si w + 1 est plus petit ou égal à la taille maximale supportée par les multiplieurs câblés du FPGA. Deuxièmement, le petit Rower supplémentaire implique 2 cycles supplémentaires dans notre implantation de l’algorithme SBMM, par rapport à cette solution. Mais pour implanter cette solution, il faut réaliser des Rowers et un Cox qui gèrent 2 tailles d’éléments, w et w + 1. Par manque de temps, nous avons décidé de garder les Rowers qui ne gèrent qu’une seule taille, et d’implanter un petit Rower supplémentaire. Notre implantation ne concerne pour le moment que l’algorithme SBMM, sans la fonction de compression. Même si nous avons pris une base Bb telle que la fonction de compression soit utilisable, notre implantation va juste calculer le résultat d’une multiplication modulaire. Le résultat n’est pas compressé, il est inférieur à 6P. La compression est censée être effectuée en parallèle sur un petit modulo supplémentaire mγ. Avec l’architecture illustrée figure 4.2, ces calculs peuvent être effectués sur le Rower supplémentaire qui n’est utilisé que la moitié du temps : lorsque l’on calcule sur la base Bb. Il suffira de s’occuper des compressions lorsque les calculs sur les autres Rowers seront faits sur la base Ba. Si on implante des Rowers gérant aussi des éléments de w + 1 bits, on est obligés de rajouter un petit Rower supplémentaire, qui dans ce cas pourra être utilisé en parallèle des calculs sur Ba, mais aussi en parallèle des calculs sur Bb. Nous avons choisi d’implanter une architecture sur n/2 Rowers plutôt que sur n Rowers4.3. IMPLANTATION FPGA 135 Slices nb. nb. nb. Fréq. temps Algo. ` n × w (FF/LUT) DSP BRAM cycles (MHz) (ns) 192 12 × 17 2011(2956/5906) 26 0 50 208 240 MM 384 12 × 33 3304(5692/10455) 84 12 50 118 424 512 16 × 33 6180(7557/15240) 112 16 58 116 500 192 12 × 16* 1476(1973/4604) 15 0 58 223 260 SBMM 384 12 × 32* 2256(3818/8415) 42 6 58 124 467 512 16 × 32* 3400(4960/10877) 57 8 66 123 535 Table 4.4 – Résultats d’implantation des deux algorithmes de multiplication modulaire sur FPGA Virtex 5 (XC5VLX50T pour 192 bits, XC5VLX220 pour 384 et 512 bits). Les temps sont donnés pour une exécution unique. Notation * : un modulo supplémentaire de 6 bits est rajouté à la seconde demi-base Bb. parce qu’il était plus simple d’adapter nos anciennes implantations à ce cas là. Une première façon d’obtenir une implantation sur n Rowers de notre algorithme est de doubler le nombre de total de Rowers (y compris le petit Rower), et d’effectuer les lignes 2 et 4 de l’algorithme 26 en parallèle. En effet, ces deux opérations sont complètement indépendantes. Les autres opérations de l’algorithme 26 sont effectuées sur les 2 demi-bases Ba et Bb, donc déjà sur n moduli. Dans tous les cas, ce nouvel algorithme opérant sur des demi-bases, il doit être évalué sur au moins deux architectures, une avec n/2 Rowers et une avec n Rowers. 4.3.2 Résultats d’implantation 0 1000 2000 3000 4000 5000 6000 192 384 512 log P nombre de slices MM SBMM 0 20 40 60 80 100 120 192 384 512 log P nombre de blocs DSP et BRAM BRAM(MM) DSP(MM) DSP(SBMM) BRAM(SBMM) Figure 4.3 – Comparaison en surface des implantations FPGA de MM et SBMM, en nombre de slices et en nombre de blocs dédiés (DSP et BRAM). Les résultats obtenus pour les deux algorithmes sont présentés dans la table 4.4 et sont illustrés par la figure 4.3 pour les résultats de surface et la figure 4.4 pour le temps d’exécution. Les tailles de corps implantées sont 192 et 384 bits, qui sont des tailles de corps standardisées par le NIST [91], et 512 bits. Le standard du NIST propose l’utilisation de courbes définies sur 521 bits car P = 2521 − 1 est premier, et permet d’avoir une136 CHAPITRE 4. MULTIPLICATION MODULAIRE RNS MONO-BASE 0 100 200 300 400 500 600 192 384 512 log P temps d’une multiplication [ns] MM SBMM Figure 4.4 – Comparaison du temps d’exécution des implantations FPGA de MM et SBMM. multiplication modulaire très efficace, en représentation binaire classique. Dans notre cas, nous avons pris un premier de 512 bits car il est facile d’en trouver tels que P = M2 a − 2. Les mots sont de taille 16 bits pour le corps de 192 bits et 32 bits pour les autres pour l’algorithme SBMM, alors que l’on a w = 17 et w = 33 bits pour l’algorithme MM de l’état de l’art. Cela est dû au fait que dans notre implantation, les bits supplémentaires nécessaires sont fournis par le petit Rower supplémentaire. Les résultats présentés à la table 4.4 ont été obtenus sur FPGA Virtex 5, XC5VLX50T pour 192 bits et XC5VLX220 pour 384 et 512 bits. Grâce à notre algorithme, avec l’architecture proposée, nous obtenons une implantation bien plus compacte, pour un faible surcoût en temps. Comme illustré dans la figure 4.3, pour 192, 384 et 512 bits nous obtenons respectivement une réduction du nombre de slices de 27 %, 32 % et 45 %. De plus, le nombre de blocs DSP est respectivement réduit de 43 %, 50 % et 50 % et nous avons divisé par 2 le nombre de BRAM pour les 3 corps. En contrepartie, nous obtenons un surcoût en temps d’exécution de 8 %, 10 % et 7 % respectivement pour les corps de 192, 384 et 512 bits, illustré dans la figure 4.4. Comme pour nos propositions des chapitres 2 et 3, nos gains sont plus importants lorsque n devient grand, c’est à dire lorsque nous travaillons sur des hauts niveaux de sécurité. Nous rappelons enfin que l’implantation de notre nouvel algorithme n’a pas encore été optimisée, faute de temps. 4.4 Conclusion Dans ce chapitre nous avons présenté des travaux introduisant un nouvel algorithme de multiplication modulaire RNS, appelé SBMM, utilisable pour la cryptographie sur courbes elliptiques. Grâce à des P bien choisis et à des décompositions semblables à celles présentées dans le chapitre 3 sur le SPRR, nous avons divisé par 2 le nombre de multiplications modulaires élémentaires et par 4 le nombre de pré-calculs par rapport à l’algorithme de l’état de l’art. Des premiers résultats d’implantation sur FPGA, partiels, permettent de calculer une multiplication modulaire RNS avec une surface jusqu’à 2 fois plus petite, pour un surcoût en temps d’exécution de seulement 10 % (au plus) pour nos implantations.4.4. CONCLUSION 137 Ces travaux étant en cours, des implantations plus poussées seront réalisées, avec notamment l’implantation d’un doublement et d’une addition de points utilisant notre algorithme, associée à une fonction de compression pour pouvoir enchaîner les multiplications SBMM. Une implantation orientée vitesse sera aussi réalisée, qui devrait être bien plus rapide que les implantations de l’état de l’art, pour un faible surcoût en surface. Enfin, ces travaux devront être valorisés via une implantation complète d’une multiplication scalaire, combinés avec les travaux sur l’inversion modulaire présentés dans le chapitre 2.138 CHAPITRE 4. MULTIPLICATION MODULAIRE RNS MONO-BASEChapitre 5 Tests de divisibilité multiples Dans cette section, issue de notre publication [18], nous présentons un opérateur arithmétique matériel dédié aux tests de divisibilité par plusieurs petites constantes sur des grands entiers (comme des scalaires ECC). Ces grands entiers, de plusieurs centaines de bits, sont représentés en multi-précision. La méthode proposée permet de n’effectuer qu’un très faible nombre de calculs pour chaque mot de la représentation multi-précision. Par exemple, elle permet de tester la divisibilité par (2a , 3, 5, 7, 9), où 1 ≤ a ≤ 12, beaucoup plus efficacement qu’en testant la divisibilité par chacune des petites constantes séparé- ment. La méthode proposée a été implantée et validée sur circuit FPGA. Ce chapitre ne traite pas spécifiquement du RNS, mais de calculs simultanés sur des petits moduli, ou bien de recodage à bases multiples de clés pendant la multiplication scalaire [25], ce qui est complémentaire au reste des travaux de la thèse. Enfin, ce chapitre n’utilise pas les notations utilisées pour le RNS, de nouvelles notations seront définies spécifiquement. 5.1 Introduction Dans certaines applications particulières, il est nécessaire de pouvoir tester rapidement si un entier est divisible par des constantes comme 2, 3, 5 ou d’autres petits premiers et des petites puissances de ces nombres comme 3 2 . Ceci se fait assez facilement, en logiciel et en matériel, pour une seule constante et sur un nombre à tester de taille modérée (de la taille d’un mot machine en logiciel ou de quelques dizaines de bits en circuit). Mais lorsqu’il s’agit d’effectuer ces tests sur de grands entiers de plusieurs centaines de bits ou plus (p. ex. pour des tailles de nombres utilisés en cryptographie asymétrique) et pour plusieurs constantes à la fois, ceci nécessite des calculs élémentaires bien plus nombreux et ainsi des opérateurs coûteux à implanter en matériel. Ceci limite considérablement l’application de méthodes utilisant des tests de divisibilité de grands entiers en matériel. Par exemple, en cryptographie sur courbes elliptiques, une façon d’accélérer la multiplication scalaire est de faire appel à des algorithmes de recodage en bases multiples. Ces recodages permettent de réduire significativement le nombre total d’opérations à effectuer sur les points de la courbe elliptique considérée. En base double (2, 3), on représente un nombre par une somme de termes de la forme ±2 e1 3 e2 , voir [40] par exemple. Pour des bases multiples comme (2, 3, 5, 7), la représentation se fait via la somme de termes de la forme ±2 e1 3 e2 5 e3 7 e4 , voir [73] par exemple. Notre équipe travaille sur de tels recodages qui nécessitent des tests de divisibilité efficaces par les différents éléments des bases multiples (et si possible des petites puissances de ces premiers). 139140 CHAPITRE 5. TESTS DE DIVISIBILITÉ MULTIPLES Dans ce chapitre, nous présentons une méthode permettant d’effectuer simultanément, rapidement, et sur des petits circuits, les tests de divisibilité par plusieurs petites constantes comme (2a , 3, 5, 7, 9), avec a petit, sur de très grands entiers de plusieurs centaines de bits et représentés en multi-précision (c.-à-d. sous forme de vecteurs de mots de taille modérée). La méthode proposée repose sur l’adaptation d’une très ancienne méthode décrite par Blaise Pascal [93, 103]. Nous l’avons adaptée au cas de la divisibilité par plusieurs constantes et en matériel. La section 5.2 présente les notations utilisées dans ce chapitre et quelques hypothèses qui seront utiles pour les implantations matérielles. L’état de l’art du domaine est présenté en section 5.3. La section 5.4 présente la version simple en base 2, directement issue de la méthode de Pascal, de l’opérateur de divisibilité et son implantation FPGA. La section 5.5 présente notre amélioration de la méthode en utilisant une base intermédiaire plus grande de type 2 v . Nous donnons aussi les résultats d’implantation FPGA pour cette amélioration. La section 5.6 décrit brièvement des comparaisons avec d’autres travaux proches. Enfin, la section 5.7 présente la conclusion et quelques perspectives. 5.2 Notations et hypothèses d’implantation matérielle L’entier naturel x est l’opérande dont la divisibilité doit être testée. Il est représenté en numération simple de position de base 2 (la notation binaire standard, cf. [85, p. 27] par exemple) sur n bits. On a donc : x = (xn−1xn−2 . . . x1x0)2 = nX−1 i=0 xi2 i . La notation ()2 signifie que les éléments entre parenthèses sont les bits de la représentation de base 2 avec les poids faibles à droite. Dans nos applications cibles — l’implantation matérielle de crypto-processeurs ECC — les nombres ont des tailles dans l’intervalle n ∈ [160, 600] bits, mais notre méthode fonctionne directement pour des tailles plus importantes. L’extension au cas des entiers relatifs est triviale et ne sera pas décrite dans ce chapitre (car peu utile dans nos applications en cryptographie). En pratique dans le circuit, un tel grand entier est représenté — et donc stocké — en multi-précision par un vecteur de t mots de taille w bits. Le nombre t de mots nécessaires pour représenter les entiers de n bits est donné par la relation : w · (t − 1) < n ≤ w · t. Si besoin, le mot de poids le plus fort est complété par des zéros (0-padding). On note x (j) , avec 0 ≤ j < t, le j-ième mot de la représentation multi-précision de x en partant des poids faibles. Le stockage de x en multi-précision est illustré au niveau architecture en figure 5.1. L’adresse du j-ième mot de x est entrée dans le bloc mémoire et le contenu de ce mot x (j) sort sur le port de lecture. Dans nos implantations matérielles en FPGA, ce bloc mémoire sera implanté en LUT (look-up table) afin de pouvoir mesurer l’impact de n et w sur la surface de circuit utilisée. Bien évidement, notre méthode s’applique directement aux implantations avec des blocs dédiés de mémoire câblée des FPGA modernes (p. ex. les BRAM des FPGA Xilinx). Nous noterons D l’ensemble des l diviseurs par lesquels on souhaite tester la divisibilité de x, on a ainsi D = (d1, d2, . . . , dl). Nous désignons par d un des éléments de D (quand sa position dans D n’a pas d’importance afin d’alléger les notations). Les diviseurs de D5.3. ÉTAT DE L’ART 141 x (0) = x (1) = x (t−1) = xt·w−1 xt·w−2 . . . x(t−1)·w+1 x(t−1)·w ✳ ✳ ✳ x2·w−1 x2·w−2 . . . xw+1 xw xw−1 xw−2 . . . x1 x0 w ❜✐ts t ♠♦ts x (j) w j dlog2 (t)e Figure 5.1 – Stockage de l’argument x sur t mots de w bits. envisagés pour les tests sont des petits nombres premiers comme 2, 3, 5 ou 7 ainsi que quelques puissances limitées de ces premiers comme 2 a (avec a ≤ w en pratique dans l’architecture) ou 3 2 . Les réalisations matérielles de ce chapitre ont été décrites en VHDL puis implantées sur un FPGA XC5VLX50T en utilisant l’environnement ISE 12.4, tous deux de la société Xilinx, avec des paramètres d’effort standard pour la synthèse et le placement/routage. Dans la suite, nous résumerons les résultats d’implantation, obtenus par les outils, en termes de nombre de cycles d’horloge, de surfaces exprimées en slices et de fréquences d’horloge. Les surfaces seront aussi indiquées en nombre de LUT (à 6 entrées dans Virtex 5) et nombre de bascules (FF pour flip-flop). Pour information, un XC5VLX50T contient 7 200 slices de 4 LUT-6 et 4 FF par slice. 5.3 État de l’art Il existe de nombreuses références qui présentent des tests de divisibilité. Par exemple, les tests élémentaires comme la divisibilité par 3, 5, 9 ou 10 en base 10 se trouvent dans les livres de mathématiques pour le collège. Des listes plus étoffées de tests de divisibilité en bases 10 et 2 se trouvent sur des sites comme Wikipédia. Enfin, des livres bien plus techniques comme [124] proposent des astuces logicielles pour effectuer certains tests très rapidement en utilisant de courtes séquences d’instructions arithmétiques et logiques. Mais il existe très peu de référence sur l’implantation matérielle de ces tests, en particulier pour des grands nombres (cf. section 5.6). Toutes ces méthodes utilisent, plus ou moins directement et avec des adaptations, l’idée de base présentée ci-dessous. Blaise Pascal (1623–1662) a proposé une méthode générale permettant de tester la divisibilité de x par d dans une représentation de base b quelconque (avec x en numération simple de position, c.-à-d. x = Pn−1 i=0 xib i ). Cette méthode est décrite dans une publication posthume, en latin, de 1819 [93] 1 . Une analyse moderne et en anglais de ce texte se trouve dans [103] (on trouve sur Internet une version équivalente de ce texte et en français sous le titre « La machine à diviser de Monsieur Pascal »). Cette méthode est souvent appelée ruban de Pascal. La méthode décrite par Pascal est peut-être encore plus ancienne, mais nous ne connaissons pas de texte antérieur présentant cette méthode en base b quelconque. Pascal a remarqué que les valeurs des restes b i mod d, avec i ∈ N et d premier avec la base b, forment une séquence périodique très simple dans certains cas. Dans la suite de ce 1. Nous remercions Christiane Frougny pour nous avoir fourni les références historiques sur le sujet.142 CHAPITRE 5. TESTS DE DIVISIBILITÉ MULTIPLES chapitre, nous nous limiterons au cas de la base b = 2 ou b = 2v avec v petit. La table 5.1 présente les restes 2 i mod d pour d ∈ {3, 5, 7} et i ≤ 16. Chaque ligne de la table 5.1 présente le ruban de Pascal correspondant à d. i d 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 3 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 5 1 3 4 2 1 3 4 2 1 3 4 2 1 3 4 2 1 7 2 1 4 2 1 4 2 1 4 2 1 4 2 1 4 2 1 Table 5.1 – Rubans de Pascal pour la divisibilité par d ∈ {3, 5, 7} (les valeurs sont 2 i mod d). À partir de la table 5.1, on peut utiliser le ruban de Pascal pour tester facilement la divisibilité par d = 3, pour lequel la séquence périodique est (2 1)∗ . Ce ruban indique que : x mod 3 = (. . . + 25x5 + 24x4 + 23x3 + 22x2 + 21x1 + x0) mod 3 = (. . . + 2 x5 + x4 + 2 x3 + x2 + 2 x1 + x0) mod 3 = X(2x2i+1 + x2i) | {z } α  mod 3 Cela signifie qu’il faut commencer par sommer les sous-mots de taille 2 bits de type (x2i+1 x2i)2 sur toute la largeur de l’opérande. La somme obtenue est alors congrue à 3 dans le cas où x est divisible par 3. En appliquant récursivement cette méthode sur l’écriture de la somme obtenue pour α (la taille de α dépend de t), comme illustré à la figure 5.2, on obtient une valeur pour laquelle il suffit de tester si elle est égale à 0 ou à 3. Si la valeur finale obtenue est différente de 0 et de 3 alors x n’est pas divisible par d = 3. x (j) 2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 9 . . . + + + + . . . application du ruban de Pascal pour d = 3 Figure 5.2 – Application récursive du ruban de Pascal pour d = 3. Cette méthode s’applique directement au cas d = 7 pour lequel la séquence périodique5.4. UTILISATION DIRECTE DES RUBANS DE PASCAL EN BASE 2 143 est (4 2 1)∗ . Ce qui signifie qu’il faut faire la somme α (spécifique à cette valeur de d) des sous-mots de taille 3 bits et de la forme (x3i+2 x3i+1 x3i)2 le plus possible (en appliquant la décomposition récursivement), puis enfin tester si la somme réduite finale est égale à 0 ou 7. Mais dans le cas d = 5, la séquence périodique est (3 4 2 1)∗ . On ne peut plus faire la somme par sous-mots de taille 4 bits du fait du facteur 3 (3 n’étant pas une puissance de 2). Pour résoudre ce problème, deux solutions s’offrent à nous : considérer 3 = 1+ 2 ou bien considérer 3 ≡ −2 mod 5. La première solution consiste à utiliser le bit de rang 4i+3 comme entrée de l’addition aux rangs 4i + 1 et 4i simultanément. La seconde nécessite d’utiliser la représentation en complément à deux pour effectuer toutes les sommes intermédiaires pour obtenir α. Le test de divisibilité par 2 a avec a ∈ N est trivial pour x représenté en base 2. Il suffit en effet de regarder si les a bits de poids faibles sont nuls ou non. 5.4 Utilisation directe des rubans de Pascal en base 2 Dans un premier temps, nous avons utilisé directement la méthode des rubans de Pascal en base 2, c.-à-d. en considérant les sommes de sous-mots de 2 bits pour d = 3 et 3 bits pour d = 7 par exemple. L’architecture correspondante est présentée en figure 5.3. Nous avons implanté une version pour D = (21...a , 3, 5, 7). Les blocs de somme « P » calculent la valeur de α propre à chaque diviseur d de D différent de 2 1...a. En plus, dans ces blocs, nous appliquons le ruban de Pascal pour chaque d afin de réduire la taille du registre d’accumulation. Donc, nous n’accumulons pas réellement la somme α, mais la somme α après application du ruban de Pascal. Lors de cette accumulation/réduction, il faut traiter les t mots de l’opérande x. Les blocs « R », quant à eux, effectuent les toutes dernières applications du ruban de Pascal ainsi que le test final (p. ex. tester si on a une valeur égale à 0 ou à d). Les signaux d’horloge et de contrôle ne sont pas représentés sur la figure 5.3. . . . t mots w bits mem. x x (j) CTRL j w P pour d = 3 3 reg. R pour d = 3 divisible par 3 1 w P pour d = 5 5 reg. R pour d = 5 divisible par 5 1 w P pour d = 7 4 reg. R pour d = 7 divisible par 7 1 w divisible par d = 21...a divisible par 2 1...a a Figure 5.3 – Architecture des tests de divisibilité par D = (21...a , 3, 5, 7) en utilisant directement les rubans de Pascal en base 2. Nous avons testé les deux solutions pour le test de divisibilité par d = 5 : considérer 3 = 1 + 2 ou bien considérer 3 ≡ −2 mod 5. C’est la version non signée, 3 = 1 + 2, qui s’avère être la plus efficace en vitesse et en surface. Ceci est très probablement lié au surcoût de l’extension de signe pour les additions/soustractions en complément à deux. L’architecture de la figure 5.3 permet de tester la divisibilité par chacun des éléments de D de façon simultanée et en un seul parcours des mots de la représentation de x. Le nombre de cycles d’horloge nécessaire est t+O(1) où la constante dépend de la taille w des mots. Le paramètre w influence grandement les performances et la taille de l’opérateur.144 CHAPITRE 5. TESTS DE DIVISIBILITÉ MULTIPLES Les longueurs des séquences périodiques de restes 2 i mod d pour d = 3, 5, 7 sont respectivement 2, 4, 3 (voir table 5.1). Afin d’éviter un décodage complexe, nous utilisons le plus petit commun multiple de ces longueurs pour la valeur de w. Dans notre cas particulier, on a donc w = ppcm(2, 4, 3) = 12. En pratique, on peut utiliser des multiples du ppcm. Nous avons testé w = 12 et w = 24 (de plus grandes valeurs réduisent beaucoup la fréquence d’horloge et nécessitent l’introduction d’étages de pipeline supplémentaires). Les résultats d’implantation en FPGA sont résumés dans la table 5.2 pour des opérandes de n = 160 bits (la plus petite taille utile pour nos applications ECC) et pour des tests de divisibilité par D = (21...a , 3, 5, 7). Nous avons utilisé a = 12 quelque soit la valeur w. Ce choix du paramètre a limité à 12 est justifié par des évaluations statistiques sur nos applications ECC. surface fréquence nombre w t slices (FF/LUT) MHz de cycles 12 14 37 (90/100) 418 t + 3 24 7 42 (100/105) 408 t + 4 Table 5.2 – Résultats d’implantation sur FPGA des tests de divisibilité par D = (21...a , 3, 5, 7) utilisant directement les rubans de Pascal en base 2 et pour n = 160 bits. Dans la table 5.2, nous exprimons le nombre de cycles d’horloge nécessaire pour effectuer les tests de divisibilité simultanés en fonction de t (le nombre de mots de x). En effet, il faut lire chaque mot pour accumuler sa contribution à α. La valeur de t utilisée est déterminée par les paramètres n et w (n pour l’application et w pour l’architecture). On rappelle que w · (t − 1) < n ≤ w · t. La fréquence de l’opérateur, quant à elle, dépend fortement des paramètres t et w (et donc indirectement aussi de n). Notre méthode fonctionne sans aucun problème pour des tailles plus importantes que n = 160. Le surcoût en surface de circuit est alors celui du stockage d’arguments de plus grande taille. Ces plus grands arguments nécessitent un compteur de boucle un peu plus large (la taille du compteur étant en dlog2 (t)e). Enfin, nous avons validé fonctionnellement nos opérateurs par des simulations aléatoires intensives. 5.5 Amélioration via les rubans de Pascal en grande base 2 v Appliquer directement la méthode des rubans de Pascal à des tests de divisibilité plus nombreux, comme D = (21...a , 3, 5, 7, 9, 11, 13), complique sensiblement le contrôle et augmente le nombre de registres internes utilisés pendant la boucle d’accumulation. La table 5.3 fournit les rubans de Pascal pour d ∈ {9, 11, 13} à partir des bits de x (c.-à-d. les restes sont les valeurs 2 i mod d). Elle montre clairement qu’avec des valeurs de d plus grandes, la longueur des séquences périodiques et leur « complexité » (forme des coefficients) croît de façon importante. Devoir organiser le décodage de ce qu’il convient de faire de chaque bit en fonction du ppcm de ces longueurs va engendrer un contrôle bien plus complexe. De plus, il faut accumuler les valeurs α propres à chaque diviseur d dans des registres distincts. Afin d’étudier les liens entre les longueurs et la forme des séquences périodiques dans les rubans de Pascal d’une part, et les performances et le coût des opérateurs nécessaires pour des tests plus complexes d’autre part, nous avons modifié différents paramètres arithmétiques et de l’architecture.5.5. AMÉLIORATION VIA LES RUBANS DE PASCAL EN GRANDE BASE 2 V 145 i d 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 9 2 1 5 7 8 4 2 1 5 7 8 4 2 1 5 7 8 4 2 1 11 6 3 7 9 10 5 8 4 2 1 6 3 7 9 10 5 8 4 2 1 13 11 12 6 3 8 4 2 1 7 10 5 9 11 12 6 3 8 4 2 1 Table 5.3 – Rubans de Pascal en base 2 pour d ∈ {9, 11, 13} (les valeurs sont 2 i mod d). En faisant varier ces paramètres, nous avons remarqué une propriété très intéressante si l’on considère les restes de sous-mots au lieu des restes des bits (au sens arithmétique) directement. Supposons que l’on découpe les mots de w bits en sous-mots de v bits avec v ≤ w, c.-à-d. que l’on lit les chiffres de x en base b = 2v . En considérant les restes 2 v
i mod d au lieu de 2 i mod d, on obtient des séquences périodiques très intéressantes pour certaines valeurs de v et de d. En particulier pour v = 12, on obtient les rubans de Pascal présentés à la table 5.4 pour d ∈ {3, 5, 7, 9, 11, 13, 16, 25}. Dans cette table, les valeurs sont les restes 2 12
i mod d pour 0 ≤ i ≤ 9. i d 9 8 7 6 5 4 3 2 1 0 3 1 1 1 1 1 1 1 1 1 1 5 1 1 1 1 1 1 1 1 1 1 7 1 1 1 1 1 1 1 1 1 1 9 1 1 1 1 1 1 1 1 1 1 11 3 9 5 4 1 3 9 5 4 1 13 1 1 1 1 1 1 1 1 1 1 17 16 1 16 1 16 1 16 1 16 1 25 6 11 16 21 1 6 11 16 21 1 Table 5.4 – Rubans de Pascal en base 2 12 pour d ∈ {3, 5, 7, 9, 11, 13, 16, 25} (les valeurs sont 2 12
i mod d). Les lignes qui correspondent aux diviseurs 3, 5, 7, 9 et 13 de la table 5.4 présentent la même séquence périodique (1)∗ . Ces lignes signifient que les tests correspondants peuvent être effectués en utilisant un unique registre d’accumulation. Le même accumulateur est alors partagé pendant les t cycles de l’accumulation, puis il faut effectuer une réduction finale propre à chaque diviseur dans notre nouvelle architecture illustrée en figure 5.4. L’optimisation provient de l’accumulation d’une seule valeur α partagée par tous les diviseurs ayant (1)∗ comme séquence périodique. Afin de tirer parti de cette propriété, il convient de choisir pour w un multiple de v (c.-à-d. w = v, w = 2 · v, w = 3 · v, . . . ). Dans notre cas, nous avons implanté la version améliorée pour v = 12 et w ∈ {12, 24}. Dans cette version, la sortie du registre d’accumulation est plus grande (w + dlog2 (t)e bits) que les sorties des registres de la figure 5.3. Les blocs de réduction « R0 » propres à chaque diviseur utilisent la technique spécifique de base b = 2 présentée en section 5.3 (figure 5.2). Les résultats d’implantation en FPGA pour notre méthode améliorée sont donnés dans la table 5.5 pour des opérandes de n = 160, 256 et 521 bits (qui correspondent à des tailles cryptographiques assez classiques pour ECC) et pour des divisibilités par D =146 CHAPITRE 5. TESTS DE DIVISIBILITÉ MULTIPLES . . . t mots w bits mem. x x (j) CTRL j w est un multiple de v w + w + dlog2 (t)e reg. R0 pour d = 3 divisible par 3 1 R0 pour d = 5 divisible par 5 1 R0 pour d = 7 divisible par 7 1 R0 pour d = 9 divisible par 9 1 R0 pour d = 13 divisible par 13 1 w divisible par d = 21...a divisible par 2 1...a a Figure 5.4 – Architecture des tests de divisibilité par D = (21...a , 3, 5, 7, 9, 13) en utilisant l’amélioration en base 2 v des rubans de Pascal. (21...a , 3, 5, 7, 9, 13). Ici aussi, nous avons utilisé a = 12 pour les différentes valeurs de w. surface fréquence nombre n w t slices (FF/LUT) MHz de cycles 160 12 14 49 (112/135) 454 t + 3 24 7 72 (176/198) 490 t + 4 256 12 22 54 (127/149) 460 t + 3 24 11 74 (188/205) 495 t + 4 521 12 44 56 (129/155) 424 t + 3 24 22 74 (192/208) 485 t + 4 Table 5.5 – Résultats d’implantation sur FPGA des tests de divisibilité par D = (21...a , 3, 5, 7, 9, 13) utilisant l’amélioration des rubans de Pascal en base 2 12 et pour n ∈ {160, 256, 521} bits. 5.6 Comparaisons On trouve dans [47] une application du RNS au test de divisibilité en matériel mais sans aucun résultat d’implantation. La méthode décrite dans [47] suppose que l’opérande x soit représenté en RNS ce qui n’a pas vraiment de sens pour les applications envisagées en cryptographie ECC. On peut représenter les coordonnées des points d’une courbe elliptique (éléments d’un corps fini) avantageusement en RNS, comme le montrent les premiers chapitres de ce document. Mais nous ne connaissons pas de proposition de cryptosystème dans lequel le scalaire k est représenté en RNS pour l’opération de multiplication scalaire [k]P. On trouve sur Internet le texte correspondant à un poster [101] prétendument publié à la conférence FCCM (Field-Programmable Custom Computing Machines) 2002 mais ce papier n’est pas dans la liste des posters ou papiers présentés à la conférence (ni pour les autres années à FCCM, ni sur DBLP et IEEEXplore qui stockent pourtant toutes les publications à FCCM, ni dans une autre conférence). Ce texte présente, sans aucun détail, des résultats d’implantation en FPGA de tests de divisibilité pour des nombres en multiprécision avec un temps de calcul qui semble quadratique (en tous cas non-linéaire). Notre méthode a un temps de calcul seulement linéaire en t+O(1) cycles et où le terme constant5.7. CONCLUSION 147 est tout petit (3 ou 4 selon les versions). Nous ne connaissons pas d’autre référence qui traite d’implantation matérielle de tests de divisibilité pour des grands entiers et qui en détaille les performances. Ceci est probablement lié au fait que l’utilisation de tels tests de divisibilité sur des grands nombres en matériel est rarissime. Nous espérons que ce travail permettra d’utiliser ces tests de divisibilité du fait de leur assez bonne efficacité. 5.7 Conclusion Nous avons proposé une architecture d’opérateur arithmétique matériel dédié aux tests de divisibilité par des petites constantes pour de grands entiers. La méthode proposée permet d’effectuer simultanément différents tests comme les divisibilités par (21...a , 3, 5, 7, 9, 13) avec a ≤ 12 en une seule lecture des chiffres de l’opérande à tester. Les résultats d’implantation FPGA montrent que ces tests s’effectuent très rapidement (tant au niveau de la fréquence de l’opérateur que du nombre de cycles d’horloge nécessaire) et enfin sur de petits circuits. Dans l’avenir, nous souhaitons pouvoir évaluer l’utilisation d’autres propriétés arithmétiques pour permettre les tests de divisibilité par encore plus de diviseurs.148 CHAPITRE 5. TESTS DE DIVISIBILITÉ MULTIPLESConclusion Pour conclure ce document de thèse, nous allons rappeler les différentes contributions proposées puis présenter certaines perspectives pour des travaux futurs sur le RNS. Tout d’abord, est présenté au chapitre 2, un nouvel algorithme d’inversion modulaire en RNS, appelé PM-MI, basé sur l’algorithme d’Euclide étendu classique, et une variante « binaire-ternaire ». Nous avons obtenu de très bons résultats, aussi bien théoriques que d’implantation sur FPGA. Notre algorithme PM-MI divise de 12 à 37 fois le nombre de multiplications modulaires élémentaires EMM par rapport à l’inversion RNS de l’état de l’art, et sa variante binaire-ternaire de 18 à 54 fois, pour les paramètres (standards) testés. De plus, l’implantation du PM-MI pour 4 tailles standardisées par le NIST [91] donne des inversions 5 à 12 fois plus rapides sur FPGA Virtex 5 que celle de l’état de l’art, avec un surcoût en surface très faible. Notre algorithme est d’ailleurs désavantagé par l’architecture, car nous nous sommes fixés comme contrainte de garder l’architecture ECC en RNS de l’état de l’art, et de n’apporter que de petites modifications. En effet, l’architecture doit en premier lieu être adaptée aux calculs pour ECC plutôt que pour l’inversion, car c’est la multiplication scalaire [k]P d’ECC qui prend la majorité du temps. Notre algorithme utilise bien plus d’additions que de multiplications, à la différence de l’algorithme de l’état de l’art. L’architecture implantée favorisant les multiplications au profit des additions, le temps d’exécution de notre algorithme pourrait être amélioré sur une architecture mieux adaptée. Deux pistes dans la lignée de ces travaux sont à exploiter pour les compléter. Premièrement, il faudra faire une implantation complète d’une multiplication scalaire, avec cette inversion pour mieux mesurer son impact en terme de surface sur la totalité du cryptoprocesseur ECC. Deuxièmement, les améliorations théoriques apportées par la variante binaire-ternaire devront être complétées via une implantation matérielle, qui sera comparée à l’implantation du PM-MI binaire. Le chapitre 3, lui, présente deux contributions, avec certaines idées en commun. La première contribution est un algorithme de multiplication modulaire en RNS, nommé SPRR, qui via des décompositions permet de tirer parti des réutilisations d’opérandes. Il permet, par exemple, de réduire le coût d’un carré par rapport à l’algorithme de l’état de l’art, mais nécessite que le corps dans lequel on travaille ait une forme particulière. Cette contrainte est compatible avec les exponentiations pour le logarithme discret, on obtient pour cellesci jusqu’à 10 % de réduction du nombre de EMM, et un nombre de pré-calculs réduit de 25 %. Pour ECC, les résultats obtenus dépendent fortement de la réutilisation d’opérandes que l’on retrouve dans les formules. Les résultats sont globalement moins bons que pour les exponentiations. Nous avons testé trois jeux de formules d’opérations sur les points, pour différents choix de courbes et de coordonnées. Le nombre de pré-calculs est toujours réduit de 25 % environ, mais le nombre de multiplications modulaires élémentaires EMM est plus élevé de 5 à 20 % pour 2 des jeux de formules testés. Par contre, Le dernier jeu de 149150 CONCLUSION formules permet de réduire jusqu’à 10 % le nombre d’EMM pour des grands paramètres ECC. Nous souhaitons étudier dans l’avenir l’impact de cet algorithme sur les possibilités d’aléa qu’offre le RNS pour protéger le circuit. En effet, une partie des moduli (n/2 précisément), sont fixés car ils sont liés au corps sur lequel on calcule. Ensuite, nous souhaitons implanter en FPGA l’algorithme afin de tester le réel impact de nos métriques dans un cas concret. Pour les exponentiations nécessaires au logarithme discret, nous avons réduit le nombre d’opérations et le nombre de pré-calculs, nous nous attendons à des résultats d’implantation un peu meilleurs que l’état de l’art. La seconde contribution du chapitre 3 est un nouvel algorithme d’exponentiation RNS, qui, cette fois, n’impose aucune contrainte sur le corps (ou l’anneau) sur lequel on calcule. Cet algorithme est utilisable pour RSA, à la différence du SPRR. On améliore le nombre d’EMM de plus de 15 % pour un algorithme de type carrés et multiplications par rapport à l’algorithme d’exponentiation RNS de l’état de l’art, et de 22 % pour un algorithme protégé SPA de type « échelle de Montgomery ». De plus, cet algorithme, à la différence du SPRR, est complètement compatible avec les protections basées sur le RNS du type LRA [11]. En contrepartie, on a un surcoût en mémoire de 50 %, cet algorithme est destiné à des implantations focalisées sur la vitesse d’exécution. Comme pour le SPRR, cette exponentiation devra être testée en matériel pour juger réellement du compromis temps surface qu’elle offre. La dernière contribution sur la représentation RNS et son utilisation pour ECC est présentée au chapitre 4. Ce chapitre traite d’un nouvel algorithme de multiplication modulaire en RNS, le SBMM, utilisable pour ECC mais pas pour les exponentiations RSA, ni pour celles du logarithme discret. Dans ce chapitre sont définis des nombres premiers P, qui ont une forme très particulière, et qui sont liés à une base RNS. Une des idées de ce chapitre est de générer des premiers P, qui sont au RNS ce que les nombres premiers pseudo-Mersenne sont à la représentation binaire classique. Notre algorithme de multiplication SBMM tire parti de cette forme particulière. On obtient un algorithme qui requiert 2 fois moins d’EMM, qui divise par 4 le nombre de pré-calculs, et qui requiert 2 fois moins de moduli que l’état de l’art. Des premiers résultats d’implantation sont fournis, avec des gains en surface de 30 à 50 % (en slices, blocs DSP et BRAM), pour un surcoût en temps de moins de 10 % (notre nouvelle implantation n’étant pas encore optimisée). Par contre, notre algorithme retourne des sorties un peu plus grandes que les entrées, ce qui contraint à utiliser une fonction de compression. Des solutions ont été proposées pour celle-ci, ne demandant a priori que peu de matériel, et pouvant être effectuées en parallèle des autres calculs. Il manque à implanter ces compressions, et à implanter une séquence d’opérations complète correspondant à une multiplication scalaire, pour étudier l’impact de celles-ci. De plus, une implantation orientée vitesse devra aussi être réalisée, où l’on espère diviser par 2 (ou presque), le temps d’exécution, pour un surcoût en surface très faible. Le chapitre 5 est consacré à une contribution à part dans les travaux de thèse, puisqu’il ne traite pas du RNS. Ce chapitre présente une proposition architecturale qui permet de factoriser certains calculs, lorsqu’on effectue des tests de divisibilité simultanés, par des petites constantes, sur de grands entiers (typiquement des tailles cryptographiques). Ces petites constantes sont soit des nombres premiers, soit des petites puissances de nombre premier, pour une application de notre opérateur à un recodage multi-bases, par exemple dans les travaux [25] effectués dans l’équipe. Un exemple d’ensemble de diviseurs est 2 a , 3, 5, 7, 9. Notre proposition permet notamment, à moindre coût, d’avoir plus de tests de divisibilité, avec des divisibilités plus compliquées à tester, grâce à l’étude des rubans de Pascal de ces diviseurs pour des grandes bases 2 w. Les premiers résultats FPGA sont intéressants, car ils151 donnent des opérateurs petits et très rapides, ce qui permet leur utilisation efficace pour un recodage multi-bases, en parallèle des calculs de la multiplication scalaire. Ces travaux devront être étendus, en particulier en définissant un modèle du coût de l’implantation matérielle sur FPGA de ces multi-tests, pour un ensemble de diviseurs donné. Une étude plus poussée avec beaucoup d’implantations devra être effectuée. Pour conclure, les travaux de cette thèse ont permis au RNS de bénéficier de nouvelles optimisations, analogues à celles que l’on trouvait en représentation classique, mais qui n’existait pas jusqu’à maintenant en RNS. La représentation RNS bénéficiait déjà d’une adaptation optimisée de l’algorithme de réduction de Montgomery. Nos travaux permettent de profiter aussi, maintenant, d’une adaptation de l’algorithme d’Euclide étendu, d’un équivalent aux multiplications modulo un nombre pseudo-Mersenne, et d’un carré modulaire moins cher qu’une multiplication modulaire quelconque. Certains de ces nouveaux outils restreignant l’utilisation des contre-mesures basées sur le RNS, du type LRA [11], on se retrouve face à deux voies possibles pour le RNS. D’un côté, une utilisation du RNS en tant que contre-mesure, de l’autre côté une utilisation du RNS en tant qu’arithmétique à hautes performances. Dans tous les cas, un premier travail qui pourrait faire suite à ces travaux est l’étude de nos nouveaux algorithmes, dans un cadre plus étendu que celui que nous nous sommes imposés. En effet, nous sommes restés sur la base de l’architecture Cox-Rower de l’état de l’art, permettant une extension de base de Kawamura et al. [64] efficace. Peut-être que pour mieux profiter de nos propositions, des nouveaux Rowers, une nouvelle architecture ou même d’autres choix pour les extensions de base seraient plus judicieux. Après un certain nombre d’améliorations, il est parfois nécessaire de remettre certaines choses à plat, c’est peut-être ce qui attend les implantations RNS. De plus, il sera important dans l’avenir de donner, à un moment donné, une description précise de quelques configurations complètes de paramètres pour ECC en RNS (corps, base RNS, extension de base et tout autre algorithme utilisé), afin de faciliter l’implantation du RNS pour ceux qui voudraient l’utiliser. En effet, le RNS permettait déjà d’avoir des implantations cryptographiques performantes. Avec les nouvelles propositions de cette thèse et les futurs travaux de recherche, il est possible que la représentation devienne si efficace qu’une standardisation des paramètres ECC favorisant le RNS devienne intéressante. La recherche autour du RNS étant actuellement active, et ses possibilités d’évolutions très nombreuses, le temps n’est sûrement pas encore venu pour une telle standardisation. Peut-être que dans quelques années, l’arithmétique RNS pour la cryptographie sera suffisamment mature pour franchir le cap de paramètres lui étant dédiés dans les standards.152 CONCLUSIONBibliographie personnelle Publications K. Bigou et A. Tisserand. RNS modular multiplication through reduced base extensions. Dans Proc. 25th IEEE International Conference on Application-specific Systems, Architectures and Processors (ASAP), pages 57–62. IEEE, juin 2014. K. Bigou et A. Tisserand. Improving modular inversion in RNS using the plusminus method. Dans Proc. Cryptographic Hardware and Embedded Systems (CHES), volume 8086 of LNCS, pages 233–249. Springer, août 2013. K. Bigou, T. Chabrier, et A. Tisserand. Opérateur matériel de tests de divisibilité par des petites constantes sur de très grands entiers. Dans Actes ComPAS’13 / SympA’15 - Symposium en Architectures nouvelles de machines, janvier 2013. Exposés IEEE International Conference on Application-specific Systems, Architectures and Processors (ASAP, juin 2014) : RNS modular multiplication through reduced base extensions. Conférence d’Informatique en Parallélisme, Architecture et Système (ComPAS, avril 2014) Track meilleures contributions scientifiques du GDR ASR : Improving modular inversion in RNS using the plus-minus method. Rencontres Arithmétiques de l’Informatique Mathématique (RAIM, novembre 2013) : Inversion modulaire RNS sur FPGA. Workshop on Cryptographic Hardware and Embedded Systems (CHES, août 2013) : Improving modular inversion in RNS using the plus-minus method. Crypto’Puces (avril 2013) : Avancées sur l’utilisation de la représentation RNS pour la cryptographie sur courbes elliptiques. Journées Codage et Cryptographie (C2, octobre 2012) : Cryptographie sur courbes elliptiques en représentation modulaire des nombres (RNS). Journées Thèses DGA-MI (septembre 2012) : Use of Residue Number System for ECC. 153154 BIBLIOGRAPHIEBibliographie [1] Stratix III Device Handbook, volume 1. March 2010. [2] Xilinx UG193 Virtex-5 FPGA XtremeDSP Design Considerations v3.5. January 2012. [3] L. Adleman. A subexponential algorithm for the discrete logarithm problem with applications to cryptography. In Proc. 20th Annual Symposium on Foundations of Computer Science (SFCS), pages 55–60, October 1979. [4] D. Agrawal, B. Archambeault, J.R. Rao, and P. Rohatgi. The EM side-channel(s). In Proc. Cryptographic Hardware and Embedded Systems (CHES), volume 2523 of LNCS, pages 29–45. Springer, August 2002. [5] S. Antao, J.-C. Bajard, and L. Sousa. RNS-based elliptic curve point multiplication for massive parallel architectures. The Computer Journal, 55(5):629–647, May 2012. [6] J.-C. Bajard, L.-S. Didier, and P. Kornerup. An RNS Montgomery modular multiplication algorithm. IEEE Transactions on Computers, 47(7):766–776, July 1998. [7] J.-C. Bajard, L.-S. Didier, and P. Kornerup. Modular multiplication and base extensions in residue number systems. In Proc. 15th Symposium on Computer Arithmetic (ARITH), pages 59–65. IEEE, April 2001. [8] J.-C. Bajard, S. Duquesne, and M. D. Ercegovac. Combining leak-resistant arithmetic for elliptic curves defined over Fp and RNS representation. Technical Report 311, IACR Cryptology ePrint Archive, May 2010. [9] J.-C. Bajard, J. Eynard, and F. Gandino. Fault detection in RNS Montgomery modular multiplication. In Proc. 21th Symposium on Computer Arithmetic (ARITH), pages 119–126. IEEE, April 2013. [10] J.-C. Bajard and L. Imbert. A full RNS implementation of RSA. IEEE Transactions on Computers, 53(6):769–774, June 2004. [11] J.-C. Bajard, L. Imbert, P.-Y. Liardet, and Y. Teglia. Leak resistant arithmetic. In Proc. Cryptographic Hardware and Embedded Systems (CHES), volume 3156 of LNCS, pages 62–75. Springer, 2004. [12] J.-C. Bajard, M. Kaihara, and T. Plantard. Selected RNS bases for modular multiplication. In Proc. 19th Symposium on Computer Arithmetic (ARITH), pages 25–32. IEEE, June 2009. [13] J.-C. Bajard, N. Meloni, and T. Plantard. Study of modular inversion in RNS. In Proc. Advanced Signal Processing Algorithms, Architectures, and Implementations XV, volume 5910, pages 247–255. SPIE, July 2005. [14] J.-C. Bajard and N. Merkiche. Double level montgomery Cox-Rower architecture, new bounds. Technical Report 440, IACR Cryptology ePrint Archive, June 2014. 155156 BIBLIOGRAPHIE [15] P. Barrett. Implementing the Rivest Shamir and Adleman public key encryption algorithm on a standard digital signal processor. In Proc. 6th International Cryptology Conference (CRYPTO), volume 263 of LNCS, pages 311–323. Springer, 1986. [16] D. J. Bernstein and T. Lange. Inverted edwards coordinates. In Proc. 17th International Symposium on Applied Algebra, Algebraic Algorithms and Error-Correcting Codes (AAECC), volume 4851 of LNCS, pages 20–27. Springer, December 2007. [17] D. J. Bernstein and T. Lange. Explicit-formulas database. http://www. hyperelliptic.org/EFD, 2014. April update. [18] K. Bigou, T. Chabrier, and A. Tisserand. Opérateur matériel de tests de divisibilité par des petites constantes sur de très grands entiers. In Proc. ComPAS’13 / SympA’15 - Symposium en Architectures nouvelles de machines, January 2013. [19] K. Bigou and A. Tisserand. Improving modular inversion in RNS using the plus-minus method. In Proc. 15th Cryptographic Hardware and Embedded Systems (CHES), volume 8086 of LNCS, pages 233–249. Springer, August 2013. [20] K. Bigou and A. Tisserand. RNS modular multiplication through reduced base extensions. In Proc. 25th IEEE International Conference on Application-specific Systems, Architectures and Processors (ASAP), pages 57–62. IEEE, June 2014. [21] D. Boneh, R. A. DeMillo, and R. J. Lipton. On the importance of checking cryptographic protocols for faults. In Proc. 16th International Conference on the Theory and Application of Cryptographic (EUROCRYPT), volume 1233 of LNCS, pages 37–51. Springer, May 1997. [22] R. P. Brent and H. T. Kung. Systolic VLSI arrays for polynomial GCD computation. IEEE Transactions on Computers, C-33(8):731–736, August 1984. [23] E. Brier and M. Joye. Weierstraß elliptic curves and side-channel attacks. In Proc. 5th International Workshop on Practice and Theory in Public Key Cryptosystems (PKC), volume 2274 of LNCS, pages 335–345. Springer, 2002. [24] Certicom Research. Certicom ECC challenge, 2009. [25] T. Chabrier and A Tisserand. On-the-fly multi-base recoding for ECC scalar multiplication without pre-computations. In Proc. 21th Symposium on Computer Arithmetic (ARITH), pages 219–228. IEEE, April 2013. [26] P. W. Cheney. A digital correlator based on the residue number system. IRE Transactions on Electronic Computers, EC-10(1):63–70, March 1961. [27] R. C. C. Cheung, S. Duquesne, J. Fan, N. Guillermin, I. Verbauwhede, and G. X. Yao. FPGA implementation of pairings using residue number system and lazy reduction. In Proc. 13th Cryptographic Hardware and Embedded Systems (CHES), volume 6917 of LNCS, pages 421–441. Springer, September 2011. [28] D. V. Chudnovsky and G. V. Chudnovsky. Sequences of numbers generated by addition in formal groups and new primality and factorization tests. Advances in Applied Mathematics, 7(4):385–434, 1986. [29] M. Ciet, M. Neve, E. Peeters, and J.-J. Quisquater. Parallel FPGA implementation of RSA with residue number systems - can side-channel threats be avoided? In Proc. 46th Midwest Symposium on Circuits and Systems (MWSCAS), volume 2, pages 806–810. IEEE, December 2003. [30] C. C. Cocks. A note on ‘non-secret encryption’. CESG Memo, 1973. [31] H. Cohen and G. Frey, editors. Handbook of Elliptic and Hyperelliptic Curve Cryptography. Chapman & Hall/CRC, 2005.BIBLIOGRAPHIE 157 [32] H. Cohen, A. Miyaji, and T. Ono. Efficient elliptic curve exponentiation using mixed coordinates. In Proc. 4th International Conference on the Theory and Application on Cryptology and Information Security (ASIACRYPT), volume 1514 of LNCS, pages 51–65. Springer, October 1998. [33] J.-S. Coron. Resistance against differential power analysis for elliptic curve cryptosystems. In Proc. 1st Cryptographic Hardware and Embedded Systems (CHES), volume 1717 of LNCS, pages 292–302. Springer, August 1999. [34] R. E. Crandall. Method and apparatus for public key exchange in a cryptographic system, October 1992. US Patent 5,159,632. [35] P. de Fermat. Œuvres de Fermat, tome II, Correspondance. Gauthier-Villars, 1894. [36] J.-P. Deschamps and J. L. Imana an G. D. Sutter. Hardware Implementation of Finite-Field Arithmetic. McGraw-Hill, 2009. [37] J.-P. Deschamps and G. Sutter. Hardware implementation of finite-field division. Acta Applicandae Mathematicae, 93(1-3):119–147, September 2006. [38] W. Diffie and M. E. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, 22(6):644–654, November 1976. [39] V. Dimitrov, L. Imbert, and P. K. Mishra. Efficient and secure elliptic curve point multiplication using double-base chains. In Proc. 11th International Conference on the Theory and Application on Cryptology and Information Security (ASIACRYPT), volume 3788 of LNCS, pages 59–78. Springer, December 2005. [40] V. Dimitrov, L. Imbert, and P. K. Mishra. The double-base number system and its application to elliptic curve cryptography. Mathematics of Computation, 77(262):1075– 1104, April 2008. [41] J. D. Dixon. The number of steps in the Euclidean algorithm. Journal of number theory, 2(4):414–422, 1970. [42] S. Duquesne. RNS arithmetic in F k p and application to fast pairing computation. Journal of Mathematical Cryptology, 5:51–88, June 2011. [43] H. M. Edwards. A normal form for elliptic curves. Bulletin of the American Mathematical Society, 44(3):393–422, July 2007. [44] T. Elgamal. A public key cryptosystem and a signature scheme based on discrete logarithms. IEEE Transactions on Information Theory, 31(4):469–472, July 1985. [45] M. Esmaeildoust, D. Schinianakis, H. Javashi, T. Stouraitis, and K. Navi. Efficient RNS implementation of elliptic curve point multiplication over GF(p). IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 21(8):1545–1549, August 2013. [46] Euclide. Les quinze livres des éléments géométriques d’Euclide. D. Henrion, 1632. [47] D. Gamberger. Incompletely specified numbers in the residue number systemdefinition and applications. In Proc. 9th IEEE Symposium on Computer Arithmetic (ARITH), pages 210–215. IEEE Computer Society, September 1999. [48] F. Gandino, F. Lamberti, G. Paravati, J.-C. Bajard, and P. Montuschi. An algorithmic and architectural study on Montgomery exponentiation in RNS. IEEE Transactions on Computers, 61(8):1071–1083, August 2012. [49] H. L. Garner. The residue number system. IRE Transactions on Electronic Computers, EC-8(2):140–147, June 1959.158 BIBLIOGRAPHIE [50] C. Giraud. An RSA implementation resistant to fault attacks and to simple power analysis. IEEE Transactions on Computers, 55(9):1116–1120, September 2006. [51] D. M. Gordon. A survey of fast exponentiation methods. Journal of algorithms, 27(1):129–146, 1998. [52] N. Guillermin. A high speed coprocessor for elliptic curve scalar multiplications over Fp. In Proc. 12th Cryptographic Hardware and Embedded Systems (CHES), volume 6225 of LNCS, pages 48–64. Springer, August 2010. [53] N. Guillermin. A coprocessor for secure and high speed modular arithmetic. Technical Report 354, IACR Cryptology ePrint Archive, 2011. [54] N. Guillermin. Implémentation matérielle de coprocesseurs haute performance pour la cryptographie asymétrique. PhD thesis, Université Rennes 1, January 2012. [55] N. Gura, A. Patel, A.S. Wander, H. Eberle, and S.C. Shantz. Comparing elliptic curve cryptography and RSA on 8-bit CPUs. In Proc. 6th Cryptographic Hardware and Embedded Systems (CHES), volume 3156 of LNCS, pages 119–132. Springer, August 2004. [56] T. Güneysu and C. Paar. Ultra high performance ECC over NIST primes on commercial FPGAs. In Proc. Cryptographic Hardware and Embedded Systems (CHES), volume 5154 of LNCS, pages 62–78. Springer, 2008. [57] D. Hankerson, A. J. Menezes, and S. Vanstone. Guide to Elliptic Curve Cryptography. Springer, 2004. [58] H. Hasse. Zur theorie der abstrakten elliptischen funktionenkörper i. die struktur der gruppe der divisorenklassen endlicher ordnung. Journal für die reine und angewandte Mathematik, 175:55–62, 1936. [59] H. Heilbronn. On the average length of a class of finite continued fractions. In Number Theory and Analysis, pages 87–96. Springer, 1969. [60] W. K. Jenkins and B. J. Leon. The use of residue number systems in the design of finite impulse response digital filters. IEEE Transactions on Circuits and Systems, 24(4):191–201, April 1977. [61] M. Joye and J.-J. Quisquater. Hessian elliptic curves and side-channel attacks. In Proc. Cryptographic Hardware and Embedded Systems (CHES), volume 2162 of LNCS, pages 402–410. Springer, May 2001. [62] M. Joye and S.-M. Yen. The Montgomery powering ladder. In Proc. 4th International Workshop on Cryptographic Hardware and Embedded Systems (CHES), volume 2523 of LNCS, pages 291–302. Springer, August 2002. [63] A. Karatsuba and Y. Ofman. Multiplication of multi-digit numbers on automata. Doklady Akad. Nauk SSSR, 145(2):293–294, 1962. Translation in Soviet PhysicsDoklady, 44(7), 1963, p. 595-596. [64] S. Kawamura, M. Koike, F. Sano, and A. Shimbo. Cox-Rower architecture for fast parallel Montgomery multiplication. In Proc. 19th International Conference on the Theory and Application of Cryptographic (EUROCRYPT), volume 1807 of LNCS, pages 523–538. Springer, May 2000. [65] T. Kleinjung, K. Aoki, J. Franke, A. K. Lenstra, E. Thomé, J. W. Bos, P. Gaudry, A. Kruppa, P. L. Montgomery, D. Osvik, H. te Riele, A. Timofeev, and P. Zimmermann. Factorization of a 768-bit RSA modulus. In Proc. 30th International Cryptology Conference (CRYPTO), volume 6223 of LNCS, pages 333–350. Springer, 2010.BIBLIOGRAPHIE 159 [66] D. E. Knuth. Seminumerical Algorithms, volume 2 of The Art of Computer Programming. Addison-Wesley, 3rd edition, 1997. [67] N. Koblitz. Elliptic curve cryptosystems. Mathematics of computation, 48(177):203– 209, 1987. [68] P. C. Kocher. Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems. In Proc. 16th International Cryptology Conference (CRYPTO), volume 1109 of LNCS, pages 104–113. Springer, August 1996. [69] P. C. Kocher, J. Jaffe, and B. Jun. Differential power analysis. In Proc. 19th International Cryptology Conference (CRYPTO), volume 1666 of LNCS, pages 388–397. Springer, 1999. [70] A. K. Lenstra and Lenstra H. Jr. (editors). The development of the number field sieve, volume 1554. Springer, 1993. [71] Z. Lim and B. J. Phillips. An RNS-enhanced microprocessor implementation of public key cryptography. In Proc. 41th Asilomar Conference on Signals, Systems and Computers, pages 1430–1434. IEEE, November 2007. [72] Z. Lim, B. J. Phillips, and M. Liebelt. Elliptic curve digital signature algorithm over GF(p) on a residue number system enabled microprocessor. In Proc. IEEE Region 10 Conference (TENCON), pages 1–6, January 2009. [73] P. Longa and C. Gebotys. Fast multibase methods and other several optimizations for elliptic curve scalar multiplication. In Proc. 12th International Conference on Practice and Theory in Public Key Cryptography (PKC), volume 5443 of LNCS, pages 443–462. Springer, March 2009. [74] Y. Ma, Z. Liu, W. Pan, and J. Jing. A high-speed elliptic curve cryptographic processor for generic curves over GF(p). In Proc. 20th Selected Areas in Cryptography(SAC), LNCS, pages 421–437. Springer, 2013. [75] E. Martín-López, A. Laing, T. Lawson, R. Alvarez, X.-Q. Zhou, and J. L. O’Brien. Experimental realization of Shor’s quantum factoring algorithm using qubit recycling. Nature Photonics, 6(11):773–776, 2012. [76] R. P. McEvoy, C. C. Murphy, W. P. Marnane, and M. Tunstall. Isolated WDDL: A hiding countermeasure for differential power analysis on FPGAs. ACM Transactions on Reconfigurable Technology and Systems, 2(1):3, March 2009. [77] A. J. Menezes, T. Okamoto, and S.A. Vanstone. Reducing elliptic curve logarithms to logarithms in a finite field. IEEE Transactions on Information Theory, 39(5):1639– 1646, Sep 1993. [78] A. J. Menezes, P. C. Van Oorschot, and S. A. Vanstone. Handbook of applied cryptography. CRC press, 1996. [79] M. Mersenne. Cogitata physico-mathematica , in quibus tam naturae quam artis effectus admirandi certissimis demonstrationibus explicantur. A. Bertier Parisiis, 1644. [80] V. Miller. Use of elliptic curves in cryptography. In Proc. 5th International Cryptology Conference (CRYPTO), volume 218 of LNCS, pages 417–426. Springer, 1985. [81] P. K. Mishra and V. Dimitrov. Efficient quintuple formulas for elliptic curves and efficient scalar multiplication using multibase number representation. In Proc. 10th International Conference on Information Security (ISC), volume 4779 of LNCS, pages 390–406. Springer, October 2007. [82] P. L. Montgomery. Modular multiplication without trial division. Mathematics of Computation, 44(170):519–521, April 1985.160 BIBLIOGRAPHIE [83] F. Morain and J. Olivos. Speeding up the computations on an elliptic curve using addition-subtraction chains. RAIRO Informatique Théorique et Applications, 24(6):531–543, 1990. [84] A. Moss, D. Page, and N. P. Smart. Toward acceleration of RSA using 3D graphics hardware. In Proc. 11th IMA International Conference on Cryptography and Coding, pages 364–383. Springer, December 2007. [85] J.-M. Muller. Arithmétique des ordinateurs. Masson, 1989. [86] B. Möller. Securing elliptic curve point multiplication against side-channel attacks. In Information Security, volume 2200 of LNCS, pages 324–334. Springer, 2001. [87] H. Nozaki, M. Motoyama, A. Shimbo, and S. Kawamura. Implementation of RSA algorithm based on RNS Montgomery multiplication. In Proc. 3rd Cryptographic Hardware and Embedded Systems (CHES), volume 2162 of LNCS, pages 364–376. Springer, May 2001. [88] National Security Agency/Central Security Service (NSA/CSS). Suite B implementer’s guide to NIST SP 800-56A, 2009. [89] National Security Agency/Central Security Service (NSA/CSS). Suite B implementer’s guide to FIPS 186-3(ECDSA), 2010. [90] National Institute of Standards and Technology (NIST). FIPS 197, advanced encryption standard (AES), 2001. [91] National Institute of Standards and Technology (NIST). FIPS 186-4, digital signature standard (DSS), 2013. [92] A. Omondi and B. Premkumar. Residue number systems: theory and implementation. Imperial College Press, 2007. [93] B. Pascal. Œuvres complètes, chapter De Numeribus Multiplicibus, vol. 5, pages 117–128. Librarie Lefèvre, 1819. [94] G. Perin, L. Imbert, L. Torres, and P. Maurine. Electromagnetic analysis on RSA algorithm based on RNS. In Proc. 16th Euromicro Conference on Digital System Design (DSD), pages 345–352. IEEE, September 2013. [95] B. J. Phillips, Y. Kong, and Z. Lim. Highly parallel modular multiplication in the residue number system using sum of residues reduction. Applicable Algebra in Engineering, Communication and Computing, 21(3):249–255, May 2010. [96] S.C. Pohlig and M.E. Hellman. An improved algorithm for computing logarithms over GF(p) and its cryptographic significance. IEEE Transactions on Information Theory, 24(1):106–110, Jan 1978. [97] J.M. Pollard. A Monte Carlo method for factorization. BIT Numerical Mathematics, 15(3):331–334, 1975. [98] K. C. Posch and R. Posch. Base extension using a convolution sum in residue number systems. Computing, 50(2):93–104, 1993. [99] K. C. Posch and R. Posch. Modulo reduction in residue number systems. IEEE Transactions on Parallel and Distributed Systems, 6(5):449–454, May 1995. [100] J.-J. Quisquater and D. Samyde. Electromagnetic analysis (EMA): Measures and counter-measures for smart cards. In Proc. International Conference on Research in Smart Cards (E-smart), volume 2140 of LNCS, pages 200–210. Springer, September 2001.BIBLIOGRAPHIE 161 [101] E. Raman, L. N. Chakrapani, K. Sankaranarayanan, and R. Parthasarathi. A scalable reconfigurable architecture for divisibility testing of variable long precision numbers. http://www.cs.virginia.edu/~ks4kk/pubs/ekadhika_fccm02.pdf. (personnal website from one author). [102] R. L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2):120–126, February 1978. [103] J. Sakarovitch. Elements of Automata Theory, chapter Prologue: M. Pascal’s Division Machine, pages 1–6. Cambridge, 2009. [104] D. M. Schinianaki, A. P. Fournaris, H. E. Michail, A. P. Kakarountas, and T. Stouraitis. An RNS implementation of an Fp elliptic curve point multiplier. IEEE Transactions on Circuits and Systems I: Regular Papers, 56(6):1202–1213, June 2009. [105] D. Schinianakis and T. Stouraitis. A RNS montgomery multiplication architecture. In Proc. IEEE International Symposium on Circuits and Systems (ISCAS), pages 1167–1170, May 2011. [106] D. Schinianakis and T. Stouraitis. An RNS modular multiplication algorithm. In Proc. 20th International Conference on Electronics, Circuits, and Systems (ICECS), pages 958–961. IEEE, Dec 2013. [107] D. Schinianakis and T. Stouraitis. Multifunction residue architectures for cryptography. IEEE Transactions on Circuits and Systems I: Regular Papers, 61(4):1156–1169, April 2014. [108] D. Schinianakis and T. Stouraitis. An RNS barrett modular multiplication architecture. In Proc. IEEE International Symposium on Circuits and Systems (ISCAS), pages 2229–2232, June 2014. [109] D.M. Schinianakis, A.P. Kakarountas, and T. Stouraitis. A new approach to elliptic curve cryptography: an RNS architecture. In Proc. 13th IEEE Mediterranean Electrotechnical Conference (MELECON), pages 1241–1245, May 2006. [110] I. Semaev. Evaluation of discrete logarithms in a group of p-torsion points of an elliptic curve in characteristic p. Mathematics of Computation, 67(221):353–356, 1998. [111] O. Sentieys and A. Tisserand. Architecture reconfigurables FPGA. In Technologies logicielles Architectures des systèmes, volume H 1 196, pages 1–22. Techniques de l’Ingénieur, August 2012. [112] A. P. Shenoy and R. Kumaresan. Fast base extension using a redundant modulus in RNS. IEEE Transactions on Computers, 38(2):292–297, February 1989. [113] P.W. Shor. Algorithms for quantum computation: discrete logarithms and factoring. In Proc. 35th Symposium on Foundations of Computer Science (FOCS), pages 124– 134. IEEE, November 1994. [114] N. P. Smart. The discrete logarithm problem on elliptic curves of trace one. Journal of Cryptology, 12(3):193–196, 1999. [115] M. Soderstrand, W. K. Jenkins, G. Jullien, and F. Taylor, editors. Residue Number System Arithmetic - Modern Applications in Digital Signal Processing. IEEE, 1986. [116] J. A. Solinas. Generalized mersenne numbers. Technical report, CORR-99-39 Center for Applied Cryptographic Research, University of Waterloo, 1999. [117] J. Stein. Computational problems associated with Racah algebra. Journal of Computational Physics, 1(3):397–405, February 1967.162 BIBLIOGRAPHIE [118] D. Suzuki. How to maximize the potential of FPGA resources for modular exponentiation. In Proc. 9th Cryptographic Hardware and Embedded Systems (CHES), volume 4727 of LNCS, pages 272–288. Springer, September 2007. [119] A. Svoboda and M. Valach. Operátorové obvody (operator circuits in czech). Stroje na Zpracování Informací (Information Processing Machines), 3:247–296, 1955. [120] N. S. Szabo and R. I. Tanaka. Residue arithmetic and its applications to computer technology. McGraw-Hill, 1967. [121] R. Szerwinski and T. Guneysu. Exploiting the power of GPUs for asymmetric cryptography. In Proc. 10th International Workshop on Cryptographic Hardware and Embedded Systems (CHES), volume 5154 of LNCS, pages 79–99. Springer, August 2008. [122] K. Tiri and I. Verbauwhede. A logic level design methodology for a secure DPA resistant ASIC or FPGA implementation. In Proc. Conference on Design, Automation and Test in Europe (DATE) - Volume 1, page 10246. IEEE, 2004. [123] A.S. Wander, N. Gura, H. Eberle, V. Gupta, and S.C. Shantz. Energy analysis of public-key cryptography for wireless sensor networks. In Proc. 3rd IEEE International Conference on Pervasive Computing and Communications (PerCom), pages 324–328. IEEE, March 2005. [124] H. S. Warren. Hacker’s Delight. Addison-Wesley, 2003. [125] A. C.-C. Yao. On the evaluation of powers. SIAM Journal on Computing, 5(1):100– 103, 1976. [126] G. Yao, J. Fan, R. Cheung, and I. Verbauwhede. Novel RNS parameter selection for fast modular multiplication. IEEE Transactions on Computers, 63(8):2099–2105, Aug 2014. [127] G. X. Yao, J. Fan, R. C. C. Cheung, and I. Verbauwhede. Faster pairing coprocessor architecture. In Proc. 5th Pairing-Based Cryptography (Pairing), volume 7708 of LNCS, pages 160–176. Springer, May 2012. [128] S.-M. Yen and M. Joye. Checking before output may not be enough against faultbased cryptanalysis. IEEE Transactions on Computers, 49(9):967–970, Sep 2000. [129] S.-M. Yen, S. Kim, S. Lim, and S. Moon. A countermeasure against one physical cryptanalysis may benefit another attack. In Proc. 3rd International Conference on Information Security and Cryptology (ICISC), volume 2288 of LNCS, pages 414–427. Springer, December 2001.Étude théorique et implantation matérielle d’unités de calcul en représentation modulaire des nombres pour la cryptographie sur courbes elliptiques Ces travaux de thèse portent sur l’accélération de calculs de la cryptographie sur courbes elliptiques (ECC) grâce à une représentation peu habituelle des nombres, appelée repré- sentation modulaire des nombres (ou RNS pour residue number system). Après un état de l’art de l’utilisation du RNS en cryptographie, plusieurs nouveaux algorithmes RNS, plus rapides que ceux de l’état de l’art, sont présentés. Premièrement, nous avons proposé un nouvel algorithme d’inversion modulaire en RNS. Les performances de notre algorithme ont été validées via une implantation FPGA, résultant en une inversion modulaire 5 à 12 fois plus rapide que l’état de l’art, pour les paramètres cryptographiques testés. Deuxiè- mement, un algorithme de multiplication modulaire RNS a été proposé. Cet algorithme décompose les valeurs en entrée et les calculs, afin de pouvoir réutiliser certaines parties lorsque c’est possible, par exemple lors du calcul d’un carré. Il permet de réduire de près de 25 % le nombre de pré-calculs à stocker et jusqu’à 10 % le nombre de multiplications élémentaires pour certaines applications cryptographiques (p. ex. le logarithme discret). Un algorithme d’exponentiation reprenant les mêmes idées est aussi présenté, réduisant le nombre de multiplications élémentaires de 15 à 22 %, contre un surcoût en pré-calculs à stocker. Troisièmement, un autre algorithme de multiplication modulaire RNS est proposé, ne nécessitant qu’une seule base RNS au lieu de 2 pour l’état de l’art, et utilisable uniquement dans le cadre ECC. Cet algorithme permet, pour certains corps bien spécifiques, de diviser par 2 le nombre de multiplications élémentaires et par 4 les pré-calculs à stocker. Les premiers résultats FPGA donnent des implantations de notre algorithme jusqu’à 2 fois plus petites que celles de l’algorithme de l’état de l’art, pour un surcoût en temps d’au plus 10 %. Finalement, une méthode permettant des tests de divisibilités multiples rapides est proposée, pouvant être utilisée en matériel pour un recodage de scalaire, accélérant certains calculs pour ECC. Theoretical Study and Hardware Implementation of Arithmetical Units in Residue Number System (RNS) for Elliptic Curve Cryptography The main objective of this PhD thesis is to speedup elliptic curve cryptography (ECC) computations, using the residue number system (RNS). A state-of-art of RNS for cryptographic computations is presented. Then, several new RNS algorithms, faster than state-of-art ones, are proposed. First, a new RNS modular inversion algorithm is presented. This algorithm leads to implementations from 5 to 12 times faster than state-of-art ones, for the standard cryptographic parameters evaluated. Second, a new algorithm for RNS modular multiplication is proposed. In this algorithm, computations are split into independant parts, which can be reused in some computations when operands are reused, for instance to perform a square. It reduces the number of precomputations by 25 % and the number of elementary multiplications up to 10 %, for some cryptographic applications (for example with the discrete logarithm). Using the same idea, an exponentiation algorithm is also proposed. It reduces from 15 % to 22 % the number of elementary multiplications, but requires more precomputations than state-of-art. Third, another modular multiplication algorithm is presented, requiring only one RNS base, instead of 2 for the state-of-art. This algorithm can be used for ECC and well-chosen fields, it divides by 2 the number of elementary multiplications, and by 4 the number of precomputations to store. Partial FPGA implementations of our algorithm halves the area, for a computation time overhead of, at worse, 10 %, compared to state-of-art algorithms. Finally, a method for fast multiple divisibility tests is presented, which can be used in hardware for scalar recoding to accelerate some ECC computations. De l’auto-´evaluation aux ´emotions : approche neuromim´etique et bay´esienne de l’apprentissage de comportements complexes impliquant des informations multimodales Adrien Jauffret To cite this version: Adrien Jauffret. De l’auto-´evaluation aux ´emotions : approche neuromim´etique et bay´esienne de l’apprentissage de comportements complexes impliquant des informations multimodales. Other. Universit´e Paris Sud - Paris XI, 2014. French. . HAL Id: tel-01082116 https://tel.archives-ouvertes.fr/tel-01082116 Submitted on 12 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Université Paris Sud - Ecole doctorale d’Informatique THÈSE présentée pour obtenir le titre de DOCTEUR en Informatique DE L’AUTO-ÉVALUATION AUX ÉMOTIONS - APPROCHE NEUROMIMÉTIQUE ET BAYESIENNE DE L’APPRENTISSAGE DE COMPORTEMENTS COMPLEXES IMPLIQUANT DES INFORMATIONS MULTIMODALES par Adrien Jauffret LIMSI - CNRS / Université Paris Sud 11 / UPR3251 ETIS - ENSEA / Université de Cergy-Pontoise / CNRS UMR 8051 Soutenue le 11 juillet 2014 devant le jury composé de : P. GAUSSIER, ETIS, ENSEA - Université de Cergy-Pontoise - CNRS Co-directeur de thèse P. TARROUX, LMSI-CNRS, Université Paris-Sud Co-directeur de thèse D. FILLIAT, INRIA/ENSTA ParisTech FLOWERS Rapporteur N. ROUGIER, Mnemosyne, INRIA Bordeaux Rapporteur P. BONNIFAIT, Heudiasyc, Université Technologique de Compiègne Examinateur B. POUCET, LNC, CNRS - Université Aix-Marseille Examinateur M. SEBAG, LRI, CNRS - Université Paris-Sud ExaminateurRemerciements Je tiens tout d’abord à remercier les membres de mon jury pour avoir accepté d’évaluer la valeur scientifique de mes travaux. J’aimerais exprimer toute mon estime à mes rapporteurs, David Filliat et Nicolas Rougier, pour avoir accepté de lire et commenter mon manuscrit ainsi que Philippe Bonnifait, Bruno Poucet et Michèle Sébag pour leur temps et pour les discussions intéressantes que nous avons eu lors de ma soutenance. Je remercie également mon encadrant, Nicolas Cuperlier, ainsi que mes directeurs de thèse, Philippe Gaussier et Philippe Tarroux, pour m’avoir guidé tout au long de ces années. J’ai pris plaisir à partager avec eux ma passion pour les créatures artificielles, la cybernétique et les neurosciences. Leurs enseignements ont largement contribué à faire de moi le Jedi que je suis devenu ainsi qu’à transformer peu à peu cette passion en une vocation. Je tiens à remercier Inbar Fijalkow et Mathias Quoy, respectivement ex-directrice et directeur du laboratoire ETIS, pour m’avoir accueilli pendant ces années de thèse. Merci également à Astrid et Nelly pour leur humour et bonne humeur ainsi que pour avoir su brillamment faire face avec moi à l’incroyable paperasse administrative que requiert une thèse co-encadrée par deux universités très différentes. Je remercie bien évidemment tous les membres du laboratoire pour l’indulgence dont ils ont fait preuve face à mes nombreuses pirouettes linguistiques ainsi que pour l’effervescence intellectuelle que nos débats éclectiques ont pu me procurer. Merci à Pierre A., Cyril, Arnaud, Ghilès, Julien, Frederic, Christophe, Matthieu et Sofiane pour m’avoir permis de m’intégrer au sein du laboratoire et me frotter au monde de la recherche alors que je n’étais encore que stagiaire. Merci également à la nouvelle génération : Abdelhak, Alexandre, David, Khursheed, Souheil, Ali, Raphael, Moeed et Artem ainsi qu’à mes jeunes padawans, Marwen et Caroline. Merci à Pierre D., Antoine, Sylvain, Joanna, Quang, Kasia, Loïc, Abdel, Rahima et bien sur Ramesh pour l’esprit d’équipe dont ils font preuve et avec qui je construis jour après jour l’avenir de Partnering-Robotics. Je tiens également à remercier mes collègues artificiels au même titre que mes collègues humains (bien que moins stimulants sur le plan conversationnel) : merci à Robulab, Roburoc, Berenson, Alvex et finalement Diya One pour leur patience et leur dévouement face aux nombreuses expériences que je leur ai fait subir. Enfin, comment ne pas remercier mes parents, Chantal et Daniel, ainsi que ma soeur, Mathilde, pour le soutien qu’ils m’ont offert tout au long de ces 27 années à leur côté. J’aimerais également remercier, et surtout m’excuser auprès de Fabien et Léo ainsi que toutes les personnes que je n’ai pas cité pour ces nombreuses soirées lors desquelles mon travail est passé au premier plan. Pour terminer, j’aimerais souligner le fait que cette thèse n’aurait sûrement pas été ce qu’elle est sans la présence et le soutien inconditionnel de Charlotte, mon affordance émotionnelle et ma moitié. - 3 -Synopsis Cette thèse a pour objectif la conception d’une architecture de contrôle bio-inspirée permettant à un robot de naviguer de manière autonome sur de grandes distances. Du point de vue des sciences cognitives, le modèle développé permet également d’améliorer la compréhension des mécanismes biologiques impliqués. De précédents travaux ont montré qu’un modèle de cellules de lieu, enregistrées chez le rat, permettait à un robot mobile d’apprendre des comportements de navigation robustes, tels qu’une ronde ou un retour au nid, à partir d’associations entre lieu et action. L’apprentissage et la reconnaissance d’un lieu ne reposaient alors que sur des informations visuelles. L’ambiguïté de certaines situations visuelles (e.g. un long couloir) ne permettait pas de naviguer dans de grands environnements. L’ajout d’autres modalités constitue une solution efficace pour augmenter la robustesse de la localisation dans des environnements complexes. Cette solution nous a permis d’identifier les briques minimales nécessaires à la fusion d’informations multimodales, d’abord par le biais d’un conditionnement simple entre 2 modalités sensorielles, puis par la formalisation d’un mod- èle, plus générique, de prédictions inter-modales. Ce modèle générique permet à un ensemble de modalités d’apprendre à s’inter-prédire dans des situations usuelles. C’est un mécanisme bas niveau qui permet de générer une cohérence perceptive, en ce sens que l’ensemble des modalités sensorielles s’entraident pour ne renvoyer qu’une perception claire et cohérente aux mécanismes décisionnels de plus haut niveau. Les modalités les plus corrélées sont ainsi capables de combler les informations manquantes d’une modalité défaillante (cas pathologique). Ce mod- èle implique la mise en place d’un système de prédiction et donc une capacité à détecter de la nouveauté dans ses perceptions. Ainsi, le modèle est également capable de détecter une situation inattendue ou anormale et possède donc une capacité d’auto-évaluation : l’évaluation de ses propres perceptions. Partant de ce modèle de prédictions inter-modales, capable d’une première auto-évaluation, nous nous sommes ensuite mis à la recherche des propriétés fondamentales à tout système pour l’évaluation de ses comportements. La première propriété essentielle a été de constater qu’évaluer un comportement sensorimoteur revient à reconnaître une dynamique entre sensation et action, plutôt que la simple reconnaissance d’un pattern sensoriel. La première brique du modèle encapsule donc ce couplage entre sensation et action, formant ainsi un modèle interne minimaliste des interactions du robot avec son environnement. Ce modèle interne de la dynamique du comportement est la base sur laquelle le système fera des prédictions. La seconde propriété essentielle est la capacité à extraire l’information importante de ce modèle interne par le biais de calculs statistiques. Il est nécessaire que le robot apprenne à capturer les invariants statistiques en supprimant l’information incohérente. Nous avons donc montré qu’il était possible d’estimer une densité de probabilité par le biais d’une réduction des erreurs quadratiques moyennes, c’est à dire un simple conditionnement. Cet apprentissage statistique permet de réaliser l’équivalent d’une inférence bayésienne, puisque le système estime la probabilité de reconnaître un comportement à partir de la reconnaissance d’informations statistiques apprises sur ce comportement. C’est donc par la mise en cascade de simples conditionnements que le système peut apprendre à estimer les moments statistiques d’une dynamique comportementale (moyenne, variance, asymétrie, etc...). La non-reconnaissance de cette dynamique lui permet de détecter qu’une situation est anormale. Mais détecter un comportement inhabituel ne nous renseigne pas pour autant sur son inefficacité. Le système doit également surveiller l’évolution de cette anomalie dans le temps pour pouvoir juger de la pertinence du comportement. Nous montrerons comment un contrôleur émotionnel - 5 -Synopsis peut faire usage de cette détection de nouveauté pour réguler le comportement et ainsi permettre au robot d’utiliser la stratégie la plus adaptée à la situation rencontrée. Pour finir, nous avons mis en place une procédure de frustration permettant au robot de lancer un appel à l’aide lorsqu’il détecte qu’il se retrouve dans une impasse. Ce réseau de neurones permet au robot d’identifier les situations qu’il ne maîtrise pas dans le but d’affiner son apprentissage, à l’instar de certains processus développementaux. Mots clés : robotique bio-inspirée, réseaux de neurones artificiels, navigation sensori-motrice, auto-évaluation, meta-apprentissage, sélection de l’action. - 6 -Abstract The goal of this thesis is to build a bio-inspired architecture allowing a robot to autonomously navigate over large distances. In a cognitive science point of view, the model also aim at improving the understanding of the underlying biological mechanisms. Previous works showed that a computational model of hippocampal place cells, based on neurobiological studies made on rodent, allows a robot to learn robust navigation behaviors. The robot can learn a round or a homing behavior from a few associations between places and actions. The learning and recognition of a place were only defined by visual information and shows limitations for navigating large environments. Adding other sensorial modalities is an effective solution for improving the robustness of places recognition in complex environments. This solution led us to the elementary blocks required when trying to perform multimodal information merging. Such merging has been done, first, by a simple conditioning between 2 modalities and next improved by a more generic model of inter-modal prediction. In this model, each modality learns to predict the others in usual situations, in order to be able to detect abnormal situations and to compensate missing information of the others. Such a low level mechanism allows to keep a coherent perception even if one modality is wrong. Moreover, the model can detect unexpected situations and thus exhibit some self-assessment capabilities: the assessment of its own perception. Following this model of selfassessment, we focus on the fundamental properties of a system for evaluating its behaviors. The first fundamental property that pops out is the statement that evaluating a behavior is an ability to recognize a dynamics between sensations and actions, rather than recognizing a simple sensorial pattern. A first step was thus to take into account the sensation/action coupling and build an internal minimalist model of the interaction between the agent and its environment. Such of model defines the basis on which the system will build predictions and expectations. The second fundamental property of self-assessment is the ability to extract relevant information by the use of statistical processes to perform predictions. We show how a neural network can estimate probability density functions through a simple conditioning rule. This probabilistic learning allows to achieve bayesian inferences since the system estimates the probability of observing a particular behavior from statistical information it recognizes about this behavior. The robot estimates the different statistical momentums (mean, variance, skewness, etc...) of a behavior dynamics by cascading few simple conditioning. Then, the non-recognition of such a dynamics is interpreted as an abnormal behavior. But detecting an abnormal behavior is not sufficient to conclude to its inefficiency. The system must also monitor the temporal evolution of such an abnormality to judge the relevance of the behavior. We show how an emotional meta-controller can use this novelty detection to regulate behaviors and so select the best appropriate strategy in a given context. Finally, we show how a simple frustration mechanism allows the robot to call for help when it detects potential deadlocks. Such a mechanism highlights situations where a skills improvement is possible, so as some developmental processes. Keywords : bio-inspired robotics, artificial neural-networks, sensory-motor navigation, selfassessment, metalearning, action selection. - 7 -Table des matières Introduction 13 1 Outils du cybernéticien 25 1.1 Une brève introduction aux réseaux de neurones artificiels . . . . . . . . . . . 26 1.2 Conditionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.3 Compétition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.3.1 Winner Takes All . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1.4 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.4.1 Champs de neurones dynamiques . . . . . . . . . . . . . . . . . . . . 33 1.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2 Modèles de navigation en robotique 41 2.1 Navigation nautique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.1.1 Navigation côtière . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.1.2 Navigation à l’estime . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.1.3 Navigation astronomique . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.2 Navigation en robotique classique . . . . . . . . . . . . . . . . . . . . . . . . 44 2.3 Navigation animale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.3.1 Intégration de chemin . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3.2 Région hippocampique et cellules de lieu . . . . . . . . . . . . . . . . 49 2.4 Navigation robotique bio-inspirée . . . . . . . . . . . . . . . . . . . . . . . . 53 2.4.1 Modèles inspirés des insectes . . . . . . . . . . . . . . . . . . . . . . 53 2.4.2 Modèles inspirés des mammifères . . . . . . . . . . . . . . . . . . . . 55 2.5 Per-Ac : un modèle de couplage sensori-moteur pour la perception . . . . . . . 56 2.5.1 Modèle de cellules de lieu visuelles . . . . . . . . . . . . . . . . . . . 56 2.5.2 Modèle d’intégration de chemin . . . . . . . . . . . . . . . . . . . . . 61 3 Un parallèle entre formalisme neuronal et bayésien 63 3.1 Limitations du modèle actuel . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.2 Approche bayésienne et notion d’inférence . . . . . . . . . . . . . . . . . . . 65 3.3 Notre modèle de cellules de lieu d’un point de vue bayésien . . . . . . . . . . . 68 3.3.1 Description générale du problème . . . . . . . . . . . . . . . . . . . . 69 3.3.2 Factorisation immédiate . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.3.3 Factorisation retardée . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 - 9 -TABLE DES MATIÈRES 3.4 Pondération statistique des amers . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.4.1 Un modèle neuronal de l’estimation de densité de probabilité . . . . . . 73 3.4.2 Expérience : estimons la dispersion de l’azimut de chaque amer : P(A/S) 75 3.4.3 Expérience : estimons la dispersion globale de l’azimut : P(A) . . . . . 76 3.5 Une approche statistique de la reconnaissance de lieu . . . . . . . . . . . . . . 79 3.5.1 Modèle de cellules de lieux probabilistes . . . . . . . . . . . . . . . . 79 3.5.2 Expérience : estimation de la probabilité d’être dans un lieu sachant les observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4 Localisation à partir d’informations idiothétiques 87 4.1 Les cellules de grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.2 Un modèle plausible de cellules de grille . . . . . . . . . . . . . . . . . . . . . 91 4.2.1 Description du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.2.2 Structure des expériences . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.3.1 Expérience 1 - exploration aléatoire, sans recalibration . . . . . . . . . 94 4.3.2 Expérience 2 - recalibration de l’intégration de chemin à l’aide d’un retour au nid périodique. . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.3.3 Expérience 3 - De la cellule de grille à la cellule de lieu . . . . . . . . . 99 4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5 Fusion d’informations multimodales 105 5.1 Cohérence et conflits sensoriels . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.1.1 Conflits bénins entre modalités externes . . . . . . . . . . . . . . . . . 106 5.1.2 Conflits majeurs et ruptures perceptives . . . . . . . . . . . . . . . . . 108 5.2 Un couplage bi-modale par simple conditionnement . . . . . . . . . . . . . . . 109 5.3 Robustesse de la localisation : une expérience sur robot réel . . . . . . . . . . . 110 5.3.1 A propos de la topologie des cellules de grille . . . . . . . . . . . . . . 112 5.3.2 Robustesse de la reconnaissance des lieux aux ambiguïtés visuelles . . 114 5.3.3 A propos du problème du kidnapping . . . . . . . . . . . . . . . . . . 114 5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.4.1 Vers un modèle générique de prédiction intermodale . . . . . . . . . . 117 6 Un modèle générique de détection de nouveauté pour l’auto-évaluation 119 6.1 Modèles computationnels de détection de nouveauté . . . . . . . . . . . . . . 121 6.2 Modèle des perceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.3 Modèle de détection de nouveauté . . . . . . . . . . . . . . . . . . . . . . . . 125 6.4 Expériences et résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 6.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 7 De l’évaluation à la régulation 135 7.1 Un modèle de contrôleur émotionnel au second-ordre . . . . . . . . . . . . . . 137 7.2 Sélection et coopération de stratégie . . . . . . . . . . . . . . . . . . . . . . . 138 7.3 Expérience : La frustration et son rôle communicatif dans le développement de l’autonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 - 10 -TABLE DES MATIÈRES 7.3.1 Résultats en simulations . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.3.2 Expérience sur robot réel . . . . . . . . . . . . . . . . . . . . . . . . . 140 7.4 Expérience : Le stress et son rôle actif dans la régulation des comportements . . 143 7.4.1 Résultats en simulations . . . . . . . . . . . . . . . . . . . . . . . . . 143 7.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Conclusion 149 A Strategie de suivi de route 181 A.1 Un algorithme minimaliste pour réaliser un comportement de suivi de route . . 181 B Outils de simulation de réseaux de neurones 185 B.1 Coeos : une interface graphique de conception d’architectures neuronales . . . 185 B.2 Promethe : un simulateur temps-réel et distribué de réseaux de neurones . . . . 186 C Plates-formes robotiques 189 C.1 Plate-forme d’intérieur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 C.2 Plate-forme d’extérieur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 C.3 Communication réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 - 11 -People say to me, "Are you looking for the ultimate laws of physics ?" No, I’m not. I’m just looking to find out more about the world. If it turns out there is a simple ultimate law that explains everything, so be it, that would be very nice to discover. If it turns out it’s like an onion with millions of layers... then that’s the way it is. But either way, Nature is there and she’s going to come out the way She is. So therefore when we go to investigate we shouldn’t predecide what it is we’re trying to do, except to find more about it. – R. Feynman Introduction Les premiers jalons historiques de l’intelligence artificielle (IA) remontent à l’antiquité et commencent avec "le vieux souhait de jouer à Dieu" [McCorduck, 2004]. Ainsi, les concepts de machines pensantes et de créatures artificielles apparaissent déjà dans la mythologie grecque, dont les légendes de Talos de Crete, le robot de bronze d’Héphaïstos ou encore Galatée de Pygmalion sont de bons exemples. Entre le 19ème et le 20ème siècle, les êtres artifi- ciels sont progressivement devenus des lieux communs de fiction comme en témoigne l’oeuvre "Frankenstein" de [Shelley, 1823] ou "R.U.R."(Rossum’s Universal Robots) de [Apek and Wyllie, 2010] puis les romans précurseurs d’Asimov [Asimov, 2004] ou d’Arthur C. Clarke [Clarke and Kubrick, 1999]. L’étude du raisonnement formel a lui aussi été développé par de nombreux philosophes et math- ématiciens depuis l’antiquité (parmis les plus notables : Aristote, Euclide, Al-Khawarizmi puis Leibniz). En se basant sur ces études, les fondateurs de l’IA ont proposé des algorithmes capables d’imiter, étape par étape, le raisonnement permettant à l’être humain de résoudre des puzzles et réaliser des déductions logiques [Hart et al., 1968; Poole et al., 1998; Nilsson, 1998]. Le champ de recherche de l’IA à été fondé en 1956 lors d’une conférence incluant notamment John McCarthy, Marvin Minsky, Allen Newell et Herbert Simon qui devinrent leaders de ce domaine plusieurs dizaines d’années durant [Crevier, 1993]. Ces pionniers étaient profondément optimistes à propos de l’avenir de ce nouveau domaine. Simon avaient même prédit : "les machines seront capables, d’ici une vingtaine d’années, d’accomplir toutes tâches qu’un humain peut réaliser" [Simon, 1965] et Minsky écrivit : "dans une génération ... le problème de l’intelligence artificielle sera globalement résolu" [Minsky, 1967]. Cette vision de l’intelligence a permis quelques avancées majeures dans la résolution automatique de problèmes d’algèbre, la preuve de théorèmes logiques, la réalisation de systèmes experts ou encore la création d’agents conversationnels. La victoire de Deep Blue contre le champion d’echec Garry Kasparov en 1997 a marqué les esprits [Newborn and Newborn, 1997]. Mais la capacité de cette approche a vite trouvé une limite dés lors qu’elle se confrontait au monde réel continu, dynamique et incertain. La puissance de calcul limitée des machines et l’explosion combinatoire engendrée par la résolution de tâches même triviales constituent les premières limitations de l’approche [Moravec, 1988]. La comprehension par la machine du sens commun associé aux concepts manipulés en est une autre. Ces programmes ne savent pas plus qu’ils effectuent des démonstrations géométriques ou algébriques que Deep Blue ne savait qu’il jouait aux échecs. Ces cas représentent plus des opérations intellectuelles assistées par ordinateur que de l’intelligence à proprement parler. La raison de cet echec est que la majeure partie des travaux effectués dans le domaine de l’IA 13INTRODUCTION reposent sur une représentation symbolique du monde. Les symboles représentent des étiquettes que l’on associe à des concepts, tel qu’une chaise ou un ballon. L’agent se voit attribuer une base prédéfinies de symboles avec lesquels il peut jongler. Selon ce point de vue, l’intelligence d’un agent se résume donc à la manipulation de symboles. Mais l’approche fait face à un problème fondamental (le “Symbol Grounding Problem”) [Harnad, 1990] puisque manipuler des symboles ne permet pas de comprendre pour autant leur sens dans le monde réel. [Searle, 1999] eu l’idée d’une expérience de pensée démontrant l’echec de l’approche symbolique : "Supposons que l’on soit dans une pièce fermée avec la possibilité de recevoir et d’envoyer des symboles (via un clavier et un écran, par exemple). On dispose de caractères chinois et de règles de travail (instructions) permettant de produire certaines suites de caractères en fonction des caractères introduits dans la pièce, sur le modèle des organismes de vente par correspondance qui traitent leur courrier client en plaçant des réponses préparées à l’avance, et déjà imprimées, dans des enveloppes. Si l’on fournit une histoire suivie d’une question, toutes deux écrites en chinois, l’application des règles ne peut que conduire à donner la bonne réponse, mais sans que l’opérateur ait compris quoi que ce soit, puisqu’il ne connaît pas le chinois. Il aura juste manipulé des symboles qui n’ont pour lui aucune signification." FIGURE 1 – Schéma extrait de [Bierre, 1985] repris par [Varela, 1996], illustrant les différentes complexités de représentation du monde en fonction des limites et des règles de ce monde : "Pour l’espace « échecs», il est possible de dessiner un réseau de relations dont les noeuds représentent chaque élément pertinent. Dans le cas de l’espace «conduite automobile», une semblable tentative montre bien qu’audelà de quelques éléments isolés, le réseau évolue rapidement vers une masse non-circonscrite de sens commun." Comment définir, en des termes interprétables par un programme, le concept communément associé au mot "chaise" ? De toute évidence, définir ce mot en associant le symbole "Chaise" à un ensemble d’images représentant toutes les chaises existantes n’est pas une bonne solution. En plus d’un apprentissage laborieux, l’agent n’est alors pas capable de reconnaitre une chaise qui ne lui a pas été présentée auparavant puisqu’il n’a pas saisi le sens de ce mot. - 14 -INTRODUCTION Robotique comportementale À la fin des années 1980, plusieurs chercheurs plaident pour une approche de l’intelligence artificielle complètement inédite, centrée sur la robotique. La théorie de l’énaction, proposée par [Mataruna and Varela, 1980] met ainsi en avant l’importance du corps physique pour acquérir une compréhension sensée du monde. La machine doit percevoir, bouger, survivre et évoluer dans un environnement réel pour parvenir à le comprendre. L’intelligence n’est plus vue comme un processus de réflexion détaché de l’environnement mais bien un processus de cognition "incarné" au sein d’un corps mobile à la morphologie particulière. On parle alors d’embodiment [J. Haugeland, 1995; Scheier and Pfeifer, 1997]. Ces capacités sensori-motrices sont essentielles aux capacités de plus haut niveau et le raisonnement abstrait est en fait la capacité humaine la moins importante (cf. le paradoxe de Moravec [Russell and Cohn, 2012]). Selon ce point de vue, reconnaître une chaise c’est avant tout reconnaître un objet sur lequel on peut s’asseoir. Le sens naît de l’interaction de l’agent avec son monde. Reconnaître un objet c’est reconnaître ce que l’on peut faire avec. On notera que le sens que l’on donne au mot "chaise" n’est valable que pour l’être humain et sa morphologie spécifique. Ce même objet n’a certainement pas le même sens pour l’éléphant ou pour la mouche par exemple. Dans le même temps, quelques chercheurs tentaient de reproduire les comportements élé- mentaires de certains animaux [Walter, 1953; Braitenberg, 1984]. Suivant la mouvance bioinspirée, les roboticiens s’intéressent alors aux modèles que pouvaient représenter les insectes dont la morphologie est particulièrement adaptée à une réalisation robotique. L’un des premiers à s’interesser aux insectes en tant que modèle fut Rodney Brooks qui suggéra que les robots devaient d’abord pouvoir se comporter comme le plus primitif des animaux, avant de prétendre à des capacités cognitives plus élaborées [Brooks, 1986; Arkin, 1998]. Ces études donnent naissance à l’approche animat introduite par [Wilson, 1991] et dont le but est la réalisation d’animaux artificiels en étudiant la cognition animale au niveau le plus simple pour grimper progressivement en complexité et atteindre un jour l’intelligence humaine par le bas. L’approche ravive des concepts nés de la cybernétique et de la régulation qui avaient perdu de leur impact depuis les années soixante. La cybernétique, popularisée en 1948 par [Wiener, 1948], est une science des systèmes autorégulés, qui étudie le concept de "feedback", ou boucle de retour. La discipline s’intéresse moins aux composantes d’un système qu’à leurs interactions. Le comportement globale du système est pris en compte avant tout le reste. Cette thèse s’inscrit dans cette démarche et considére le comportement émergeant du système comme un miroir de son intellect. Aussi, nous nous éloignerons d’une représentation symbolique pour adopter une approche dite "sensori-motrice". C’est le couplage entre sensation et action qui permettra au robot de se construire une représentation de son environnement. Nous implémenterons nos solutions sous la forme de réseaux de neurones artificiels. Ces derniers représentent un outil cadrant parfaitement avec l’approche de la cybernétique. L’intéraction d’un grand nombre de neurones modélisés par des équations simples peut faire émerger des capacités de catégorisation et des comportements complexes. L’une des propriétés essentielles de tels réseaux est la possibilité d’apprendre i.e. de modifier le comportement du système au fur et à mesure de ses expériences. Ces propriétés permettent d’obtenir de bonnes capacités de généralisation et facilite également l’adaptation du comportement du robot lorsque l’environnement change. Les solutions industrielles classiques s’appuient généralement sur la programmation spéci- - 15 -INTRODUCTION fique du robot pour réaliser les tâches désirées. Bien souvent, les robots ne sont programmés que pour réaliser une seule tâche de manière optimale. Les ingénieurs sont forcés de programmer entièrement le comportement du robot pour l’adapter à chaque nouvelle tâche. Cette opération nécessite des humains experts et se révèle très coûteuse en temps de développement. Selon l’approche que nous adopterons ici, la programmation spécifique de tâches est remplacée par l’apprentissage de celles-ci. Cependant, nous irons plus loin encore en concevant le robot non pas comme une machine introvertie mais comme un système capable d’intéragir naturellement avec un utilisateur pour affiner son apprentissage avec le temps. L’utilisateur n’a alors plus besoin d’être expert ni de programmer le système pour chaque nouvelle tâche à résoudre. Pour aboutir à ce type de solution, une démarche ascendante (bottom-up) et constructive est nécessaire [Mataruna and Varela, 1980; Varela et al., 1993]. Suivant cette démarche, il convient de développer progressivement la complexité du robot pour avoir la possibilité d’étudier ses capacités lorsque ce dernier est plongé dans son environnement. Cette démarche tente de faire émerger des théories de la pratique, et non l’inverse. Les modèles proposés s’inspirent de principes minimalistes que l’on trouve en biologie animale. A l’inverse d’approches descendantes (top-down) contraignant l’espace des possibles pour aboutir à la solution désirée, nous laisserons apparaitre des propriétés émergentes, que l’on ne saurait imaginer si le robot et l’environnement étaient considérés indépendamment. Problématique Cette thèse s’inscrit dans le câdre de la navigation robotique bio-inspirée en environnement réel et implique la capacité pour un système mobile à se déplacer de manière autonome dans un monde a priori dynamique et inconnu. Pour se localiser et naviguer, un robot autonome peut utiliser de multiples solutions. Mais que ce soit pour la modélisation des processus visuels ou pour la localisation, la cartographie, la navigation et la planification, les mesures nécessaires sont fortement bruitées, ce qui justifie le recours à des méthodes probabilistes. Les approches bayésiennes ont la faveur de la communauté robotique pour conserver le contrôle sur les incertitudes pesant sur les données. Les approches neuromimétiques fournissent des solutions robustes et originales pour résoudre le même problème. Des travaux récents suggèrent que des processus statistiques sont à l’oeuvre dans le cerveau et montrent comment certains codages par population de neurones implémentent les principes de bases de l’approche bayésienne [Deneve S, 2004]. L’équipe Neurocybernétique d’ETIS et l’équipe "Cognition, Perception et Usages" du LIMSI ont travaillé à la mise au point de modèles bio-inspirés neuronaux et de modèles bayésiens pour la localisation et la navigation en robotique autonome. Les travaux de [P. Gaussier, 1997] ont montré il y a maintenant plus d’une dizaine d’années qu’un système bio-inspiré pouvait par exemple apprendre à retourner vers un lieu en apprenant un nombre très réduit de couples lieu-action dans le voisinage de ce lieu-but. L’emploi de mé- canismes de compétition entre ces couples lieu-action permet la création d’un bassin d’attraction qui attire immanquablement le robot sur le lieu cible pour peu que le point de départ appartienne au même voisinage visuel. Le comportement du robot démontre ainsi sa reconnaissance du lieu cible alors même que ce lieu n’a pas été codé en temps que tel dans le réseau. D’autres travaux ont permis de montrer que ce type d’approche pouvait se généraliser à l’apprentissage de rondes [Giovannangeli and Gaussier, 2010] ou à la reconnaissance active d’objets - 16 -INTRODUCTION [S. Leprêtre, 1999]. Cependant, même si dans ces tâches la capacité de généralisation tenait la première place, on peut se poser la question de la capacité de ces approches à traiter des problèmes de très grande taille. Que se passe t’il lorsque le nombre d’amers visuels utilisés ne se compte plus en centaines mais en centaines de milliers voire millions ? Il est clair que la capacité d’un simple mécanisme de compétition à proposer une interprétation correcte s’effondre avec l’augmentation du nombre de vues apprises. De récents travaux [Cuperlier et al., 2008] ont montré qu’une information de contexte pouvait être apprise en ligne et utilisée à la fois pour limiter la compétition (augmenter le rapport signal à bruit) mais aussi pour limiter la puissance de calcul nécessaire en ne calculant que l’activité des neurones associés au bon contexte. Mais même avec ce genre de mécanisme, le robot peut se trouver trop loin des lieux appris pour être attiré dans le bassin d’attraction désiré. Il peut alors se mettre à errer indéfiniment sans rejoindre le lieu cible. Cependant, l’observation interne de l’évolution du niveau de reconnaissance des lieux traduit clairement cet échec. Un "observateur" interne pourrait donc qualifier le comportement du système. L’enjeu dans la construction d’un tel système complexe doté d’une autonomie comportementale est double. D’une part il est nécessaire que les futurs systèmes de traitement de l’information soient à la fois fiables et flexibles, capable d’extraire de manière active les informations de l’environnement qu’ils jugent pertinentes pour adapter leur comportement. D’autre part, ces systèmes devront être capables d’auto-évaluer leurs performances afin de détecter les situations d’échec ou de dead-lock (boucle sans fin). Ces situations peuvent se produire au cours d’interactions dynamiques complexes, alors même que les comportements élémentaires du système sont corrects. Pour un robot, l’autonomie peut alors se traduire par l’expression de comportements adaptatifs et non supervisés, lui permettant de détecter mais aussi de corriger des situations d’échec afin de mener à bien les tâches nécessaires à sa mission dans l’environnement dans lequel il se trouve. Rendre réellement utilisable les systèmes robotiques sophistiqués que l’on voit apparaître ces dernières années (cf la création de Cap robotique pour fédérer les nombreuses initiatives industrielles concernant les robots de services, les robots ludiques, les robots interactifs voire humanoïdes comme Asimo de Honda, HRP2, ICub ou Nao d’Aldebaran robotics à Paris) passe par la maitrise de systèmes informatiques complexes relevant le défi de l’autonomie et de l’adaptation comportementale nécessitant la capacité à détecter des situations critiques et la capacité à les résoudre. Ces compétences sont cruciales pour le développement de nouveaux produits robotiques destinés à évoluer de manière autonome dans des environnements dynamiques a priori inconnus. La robotique autonome se développe en particulier en direction de deux types d’applications : le véhicule autonome et la robotique d’assistance. Une amélioration du transport urbain pourrait passer par la mise au point de véhicules capables de se diriger de façon automatique d’un point à un autre en gérant les situations complexes et inattendues qu’il rencontrera lors de son parcours. Le fait de naviguer sur de longues distances est susceptible d’induire une instabilité de localisation si des informations de type GPS ne sont pas accessibles sur l’ensemble du trajet. Le système devra identifier ces situations d’erreur et y remédier. De la même façon, la robotique d’assistance supposera une capacité de navigation autonome, d’apprentissage des situations nouvelles et de reconnaissance de lieux et d’objets mais également la capacité à reconnaître les situations d’échec et à y remédier. Enfin, la maitrise du passage à l’échelle des mécanismes per- - 17 -INTRODUCTION mettant de reconnaître des milliers voire des millions de formes en temps réel et d’auto-adapter le comportement du robot en cas d’échec est un défi incontournable pour l’ingénierie des systèmes intelligents de demain. Ces questions sont aussi au centre des sciences cognitives avec notamment un nombre de plus en plus important de recherches sur le rôle des émotions dans nos processus cognitifs. Ces processus peuvent être assimilés à des contrôleurs au second ordre, capablent à la fois de remettre en cause la priorité de nos stratégies, ou de réaliser la fusion d’informations multimodales pour fabriquer une perception stable et robuste du monde. L’autonomie globale d’un système passe par 4 axes principaux que nous développerons progressivement tout au long de ces travaux, à savoir : - La sélection d’informations pertinentes par l’extraction de régularités statistiques. - L’intégration d’information multimodale pour obtenir une perception robuste et stable. - L’auto-évaluation des comportements sensori-moteurs exhibés par le robot, par l’ajout d’un méta-prédicteur générique. - La sélection et la régulation de ces comportements par le biais de processus émotionnels. Extraction de régularités statistiques Afin de se construire une perception robuste de son environnement, un système nécessite la capacité à extraire de celui-ci l’information importante pour la tâche à réaliser. Les approches statistiques fournissent des solutions efficaces pour filtrer l’espace des données que le système perçoit en mettant en avant les informations les plus stables. Il est nécessaire que le robot apprenne à capturer ces invariants statistiques en supprimant l’information instable ou trop bruitée. Dans l’architecture actuelle, tous les amers visuels sont traités de manière identique. Pourtant ces amers peuvent avoir des caractéristiques différentes (proximaux ou distaux) et être plus ou moins pertinents selon la tâche envisagée. Il est donc nécessaire d’introduire une capacité à prédire le déplacement de ceux-ci afin de les caractériser. Ceux dont la position angulaire reste invariante (sur une certaine distance) et dont la signature est unique peuvent servir à reconnaitre des lieux de manière robuste. Au contraire, un même amer perçu sous différentes positions angulaires reflète clairement la présence d’un objet ambigu, redondant ou encore mobile, et ne devrait pas être pris en compte par le système. Un mécanisme de méta-contrôle sera donc nécessaire ici pour apprendre à caractériser les amers visuels et moduler leur influence dans la reconnaissance des lieux. La constitution d’un tel mé- canisme sera abordée selon les deux paradigmes : neuronal et bayésien. L’exploitation de ces prédictions devrait permettre d’une part d’améliorer les performances du système (adaptation) et d’autre part de définir un détecteur de nouveauté (curiosité, surprise. . . ) réagissant à des données sortant de l’épure déterminée par un prédicteur neuronal (après apprentissage de la distribution des données). Intégration d’information multimodale Dans une deuxième phase, nous chercherons à utiliser ces mêmes techniques pour maitriser des tâches plus complexes telles que l’intégration d’informations proprioceptives dans le codage des lieux. La nature même de cette intégration étant méconnue, différentes stratégies de fusion entre ces informations seront explorées. D’un point de vue modèle neurobiologique, la fusion d’informations visuelles avec des informa- - 18 -INTRODUCTION tions idiothétiques devrait conduire à une amélioration notable de la stabilité des champs de lieu multimodaux en comparaison de champs issus d’une seule modalité. Cette fusion devra permettre la création de cellules de lieux plus robustes à des changements de l’environnement (variation de luminosité, perte d’amers lointains, fonctionnement épisodique de la modalité visuelle ...). La recalibration de l’odométrie par des informations visuelles devrait également permettre d’améliorer la fiabilité de ces informations lors de navigations dans de grands environnements (limitation de la dérive idiothétique, robustesse aux fermetures de boucles et au kidnapping...). L’impact des mécanismes de fusion/compétition entre modalités sur la stabilité et l’exactitude de l’information de position (lieux) sera étudiée dans le cadre de tâches de navigation sensorimotrices (ronde, retour à un lieu appris). Auto-évaluation Les travaux présentés dans cette thèse visent à doter nos systèmes robotiques de propriétés leur permettant de sélectionner les informations les plus pertinentes et d’adapter jusqu’à leurs comportements et leurs buts en fonction de l’évaluation de la situation rencontrée. Nous ferons l’hypothèse que les mécanismes de fusion impliquent la nécessité de prédire l’apport d’une modalité pour la reconnaissance d’un état de la même manière que juger le succès ou l’échec d’un comportement nécessite la prédiction de l’évolution d’un certain nombre de variables liées à la reconnaissance des états cibles. Il est donc légitime de supposer que ces différents problèmes pourraient reposer sur un système de prédiction générique capable de capturer rapidement les informations statistiques caractérisant une situation donnée pour faire des prédictions sur l’évolution de cet état. L’incapacité à prédire l’état courant pourrait alors être vue comme un signal de renforcement négatif impliquant la remise en cause du comportement en cours et l’apprentissage de nouveaux états [P. Andry, 2002]. Processus émotionnels Dans ce cadre, la modélisation des émotions semble indispensable à la fois au méta-contrôle de nos mécanismes cognitifs [Damasio, 1995; LeDoux, 1992; Panksepp, 1998] mais aussi pour communiquer de manière pré-verbale nos états internes. Les travaux en psychologie et neurobiologie montrent l’importance d’introduire des mécanismes émotionnels au coeur même des systèmes d’Intelligence Artificielle [Damasio, 1995; Picard, 1997; Canamero and Gaussier, 2004]. On retrouve ainsi toute une gamme de modèles permettant aux robots de détecter de la nouveauté, de prédire le rythme d’une interaction [Andry et al., 2001], de devenir curieux [Oudeyer et al., 2007] afin qu’ils puissent développer de manière autonome de nouvelles compétences dans un cadre "open ended" (à horizon temporel ouvert). L’approche bio-inspirée basée sur des modèles émotionnels pour le méta-contrôle est encore peu explorée [Balkenius et al., 2009; Canamero and Gaussier, 2004; Mannella et al., 2008]. Nous nous intéresserons ainsi à comprendre comment les émotions peuvent moduler les motivations ou les «drives» contrôlant un robot. Chez les mammifères, la régulation des comportements est liée aux interactions entre différentes structures dites limbiques. Nos émotions régulent nos comportements (ex. en cas de danger, arrêt des taches en cours et déclenchement d’un comportement de fuite ou d’agression) mais elles sont elles même régulées par d’autres processus cognitifs (la surprise liée à la détection d’une nouveauté par exemple). Différents courants théoriques s’affrontent et opposent des modèles d’émotions élémentaires [Ekman, 1984] à des modèles dimensionnels (passage continu - 19 -INTRODUCTION d’une émotion à une autre) [Spencer, 1870; Wundt and Judd, 1897] et discutent de la primauté des mécanismes cognitifs ou viscéraux dans la genèse des émotions. Dans ces travaux, nous ne tenterons pas de prendre parti au départ sur ces questions mais chercherons à utiliser dans un cadre restreint les données et modèles computationnels disponibles sur la détection de nouveauté et la gestion des comportements (modèles des ganglions de la bases, de l’hippocampe, de l’amygdale et du cortex préfrontal) pour en déduire les règles de régulation les plus simples possibles et tester leurs effets comportementaux dans des tâches de navigation autonome. Portrait-Robot Les travaux réalisés dans cette thèse ont été menés sur 2 robots mobiles : la plateforme mobile d’intérieur Robulab, et celle adpatée à la navigation en environnement extérieur Roburoc de Robosoft. FIGURE 2 – Plateforme robotique mobile Robulab de Robosoft. Le robot est composé d’une base mobile, d’un corps contenant le pc embarqué et d’une tête supportant la caméra sur servomoteur. La boussole est positionnée au sommet d’un mat afin d’empécher d’éventuelles interférences par l’électronique embarquée. Le système de localisation n’est jamais utilisé par le robot. Il permet seulement d’enregistrer la trajectoire de celui-ci. Les plateformes sont composées de 3 parties distinctes, à savoir une base mobile (Robulab PC/104) qui permet au robot de se mouvoir, un corps comprenant un coffre au sein duquel se trouve un ordinateur embarqué (Carte mini ITX i7), puis une "tête" composée d’une caméra montée sur servomoteur. Les robots sont également munies de microcontroleurs (Arduino) pour contrôler le matériel embarqué ainsi que d’un routeur WiFi pour communiquer avec une ma- - 20 -INTRODUCTION FIGURE 3 – Plateforme robotique mobile Roburoc de Robosoft. La base mobile est munie de 4 roues motrices tout terrain adaptées aux environnements extérieurs. Le corps contient le pc embarqué protégé à l’intérieur d’un coffre, un pc portable permettant un contrôle du robot. La caméra est soutenue par une plateforme stabilisatrice. L’électronique est recouverte d’un film transparent et l’ensemble est surmonté d’un parapluie dépliable afin de resister à l’humidité. Une bâche étanche est transporté dans le sac à dos du robot en cas d’averse. chine distante si besoin. Les 2 plateformes sont munies de capteurs de proximité utilisés pour l’évitement d’obstacle, d’une boussole magnétique ainsi que d’autres capteurs plus spécifiques. Nous classerons ces capteurs en deux catégories selon qu’ils mesurent un état interne au robot ou bien un état externe relatif à son environnement. Dans le premier cas, nous parlerons de proprioception ou de modalité sensorielle idiothétique (e.g odométrie, accéléromètre, gyroscope, indicateur de charge de la batterie). Dans le second cas, nous parlerons d’extéroception ou de modalité sensorielle allothétique (e.g. caméra, capteurs ultra-son, capteurs infra-rouges, capteur thermique, boussole magnétique). Pour une liste complète du matériel embarqué, on pourra se référer à l’annexe C. Les 2 plateformes que nous utiliserons sont des robots mobiles à roues non holonômes. Cette contrainte implique que le robot ne peut effectuer de translation omnidirectionelle. La locomotion à l’aide de roues exploite la friction de contact, dont la nature (régularité, matériaux) à une forte influence sur les propriétés du mouvement. Dans le cas du robot d’intérieur (fig. 2), les 2 roues sont pleines et disposées de part et d’autre de la base. Le centre instantané de rotation est donc situé au milieu des 2 roues ce qui permet un rayon de braquage nul (rotation sur place à vitesse nulle). En condition intérieure (sol plan), nous considèrerons qu’il y a roulement sans glissement de la roue sur le sol. Pour vérifier cette condition, il est nécessaire que le contact soit ponctuel et que les roues soit indéformables. Dans le cas du robot d’extérieur (fig. 3), les 4 roues tout terrain sont parallèles 2 à 2, ce qui ne permet pas un rayon de braquage nul. De plus, alors qu’il est raisonnable de dire que des roues pleines sont indéformables, cette hypothèse est fausse si l’on considère des roues équipées de pneus. Une telle contrainte, ajoutée a celle d’un sol accidenté en environnement extérieur, im- - 21 -INTRODUCTION plique des glissements qui ne sont cette fois plus négligeables. Plan de la thèse Ce manuscrit se décompose en 7 chapitres distincts. Dans le chapitre 1, j’essaierai d’aborder de manière didactique les outils nécessaires à la compréhension des modèles et méthodes que nous utiliserons tout au long de ces travaux. Nous aborderons les bases du formalisme neuronal, de l’apprentissage par conditionnement, de la catégorisation, de la décision ainsi que de l’importance de l’aspect dynamique dans les processus neuronaux. Dans le chapitre 2, nous passerons en revue un état de l’art des modèles permettant la navigation autonome d’un robot mobile. Après un bref rapprochement entre les méthodes historiques utilisées pour la navigation maritimes et celles utilisées en robotique mobile, nous comparerons les méthodes dites "classiques" avec d’autres modèles inspirés du comportement animal. Nous verrons que les techniques de SLAM (Simultaneous Localisation And Mapping) se basent principalement sur l’idée de la construction d’une carte interne détaillée de l’environnement. Cette carte doit permettre au système de naviguer de manière précise dans cet environnement. Ces méthodes classiques montrent leurs limites face à des environnements dynamiques et/ou de grandes tailles. Nous verrons comment des solutions simples et robustes, abordant le problème sous un autre angle, ont pu émerger de la nature. Dans le cadre de l’approche bio-inspiré, je présenterais le modèle de cellules de lieux hippocampiques que nous exploiterons comme base du modèle de navigation visuelle dans la suite de ces travaux. Dans le chapitre 3, je présenterai un parallèle entre l’approche neuronale et l’approche bayésienne en appliquant cette comparaison au modèle de navigation visuelle présenté précédemment. Après une description des limitations du modèle d’apprentissage figé précédent, nous procéderons à une ré-écriture du modèle sous une forme probabiliste. Je proposerai ensuite une reflexion et des solutions au problème de l’extraction de l’information pertinente pour la tâche. A partir de cette comparaison, je montrerai comment un robot est capable d’apprendre à prédire un amer visuel à partir de la perception de son azimut (sa position angulaire). De la même manière, je montrerai comment construire des cellules de lieu "probabilistes" en apprenant à prédire un lieu à partir de la perception d’une constellation d’amers-azimuts donnée. Pour cela, je proposerai un modèle neuronal capable d’estimer des densités de probabilités à partir d’observations statistiques de l’environnement. Ce modèle de prédiction uni-modal constituera la première brique d’auto-évaluation du système (l’évaluation de la pertinence des informations qu’il reçoit). Dans le chapitre 4, nous implémenterons une nouvelle stratégie de navigation basée sur une localisation idiothétique, c’est à dire une représentation des lieux construite à partir d’informations proprioceptives. En partant d’un mécanisme simple d’intégration de chemin (présenté au chapitre 2), nous proposerons un modèle de cellules de grille, enregistrées dans le cortex entorhinal dorso-médian des rats [Hafting et al., 2005]. Nous analyserons les possibilités et limitations de ces cellules pour la navigation. Nous proposerons un modèle permettant d’obtenir des cellules de lieu idiothétiques uniquement alimentées par l’information de ces cellules de grilles. Après avoir analysé en détails ce nouveau modèle de cellules de lieu idiothétiques, nous nous intéresserons dans le chapitre 5, à la manière dont peuvent être fusionnées les représentations issues du modèle visuel et du modèle idiothétique. Nous proposerons un modèle de fusion simple afin de générer des cellules de lieu multimodales, c’est à dire des cellules dont l’activation - 22 -INTRODUCTION dépend à la fois d’informations allothétiques et idiothétiques. Plusieurs expériences sur robot réel rendront compte de la capacité du modèle à conserver une reconnaissance cohérentes lors de perturbations extérieures (ambiguités visuelles, kidnapping et fermeture de boucle). Pour finir, nous ouvrirons la discussion sur la fusion de modalités en proposant un modèle générique pour l’intégration d’informations multi-modales (ne se limitant pas à 2 modalités). Ce modèle de prédictions intermodales constituera la seconde brique d’auto-évaluation du système (l’évaluation de l’adéquation existant entre ces différentes sensations). Le chapitre 6 se focalisera sur l’auto-évaluation des comportements exhibés par le système. En partant d’un état de l’art sur les modèles de détection de nouveauté et les théories de la perception, je proposerai un modèle capable d’apprendre à reconnaitre la dynamique résultante du couplage entre sensations et actions. L’apprentisssage de cette dynamique forme un mod- èle interne des interactions du robot avec son environnement : un modèle de ses perceptions. La surprise (erreur de prédiction) engendrée par une dynamique sensori-motrice inhabituelle renseigne alors le système sur d’éventuelles anomalies de son comportement. Ce modèle de dé- tection de nouveauté constituera la troisième brique d’auto-évaluation du système, l’évaluation de son comportement. Dans le chapitre 7, nous verrons que le fait de détecter un comportement inhabituel ne nous renseigne pas pour autant sur son inefficacité. Le système doit également surveiller l’évolution de la surprise dans le temps pour pouvoir juger de la pertinence de celle-ci. Je montrerais comment un contrôleur émotionnel au second ordre peut faire usage de cette détection de nouveauté pour réguler le comportement et ainsi permettre au robot d’utiliser la stratégie la plus adaptée à la situation rencontrée. Par ailleurs, un modèle simpliste de frustration poussera le robot à initier une intéraction avec son professeur lorsqu’il détecte qu’il se retrouve dans une impasse. Ce mécanisme permet au robot d’identifier les situations qu’il ne maitrise pas dans le but d’affiner son apprentissage par le biais d’une intéraction qu’il à lui même initié, à l’instar de certains processus développementaux. Pour finir, nous discuterons des différentes problématiques abordées ainsi que des apports de ces travaux relatifs à l’autonomie en robotique mobile. - 23 -Une chose est particulièrement frappante dans le cas de la colonie d’insectes : contrairement à ce qui se passe avec le cerveau, nous n’avons aucun mal à admettre deux choses : a) la colonie est composée d’individus ; b) il n’y a pas de centre ou de “moi” localisé. Pourtant, l’ensemble se comporte comme un tout unitaire et, vu de l’extérieur, c’est comme si un agent coordinateur était “virtuellement” présent au centre. C’est ce que j’entends lorsque je parle d’un moi dénudé de moi : une configuration globale et cohérente qui émerge grâce à de simples constituants locaux, qui semble avoir un centre alors qu’il n’y en a aucun [...] pp. 85-87 – F. Varela. “Quel savoir pour l’Éthique” CHAPITRE 1 Outils du cybernéticien Le but de ce chapitre est de fournir une vue d’ensemble des outils nécessaires à la compréhension des modèles et méthodes développé(e)s tout au long de ce manuscrit. Les notions présentées seront abordées de manière volontairement didactique afin de rendre la lecture de cette thèse accessible au lecteur non-initié. Nous aborderons brièvement les bases du formalisme neuronal en présentant le fonctionnement d’un neurone biologique et de son homologue, le neurone formel. Nous parlerons de groupe neuronal pour désigner une population de neurones partageant des caractéristiques communes : une fonction et/ou une règle d’apprentissage identique. Nous introduirons ensuite le concept d’apprentissage, concept clé pour l’ensemble des applications utilisant des réseaux de neurones artificiels. Un réseau de neurones peut apprendre en modifiant la valeur de ses poids synaptiques en fonction des entrées qu’il reçoit. La modification de ces poids autorise l’apprentissage d’associations et la catégorisation des signaux d’entrées en différentes classes. Un signal de neuromodulation permet de moduler la vitesse d’apprentissage du réseau. Ces capacités d’apprentissages sont cruciales pour rendre un agent autonome et capable de faire face aux aspects dynamiques, changeants et complexes du monde réel. Elles permettent de capturer les régularités statistiques du monde en filtrant naturellement le bruit présent. Elles permettent aussi à l’animal de s’adapter au mieux à son environnement, par la capacité à reconnaître des lieux pour se déplacer efficacement, la capacité d’apprendre de ses erreurs ou encore celle de détecter une situation anormale et fuir en cas de danger. Le signal de neuromodulation peut provenir de stimuli externes (renforcement positif ou négatif de la part de l’environnement ou d’un autre animal), mais il peut aussi être généré en interne par certains mécanismes compétitifs et l’usage de seuils liés aux niveaux physiologiques de l’animal (faim, soif, émotions, etc...). Ces mécanismes générant des signaux de modulation de l’apprentissage et/ou du comportement ne sont pas directement liés à l’environnement et sont principalement issus de décisions internes. Cela pose la question de comment fonctionnent ces processus décisionnels à l’oeuvre dans le cerveau. De tels mécanismes sont utilisés dans le cadre de l’apprentissage non-supervisé, c’est à dire un apprentissage autonome. L’agent prend la dé- cision d’apprendre ou non en fonction de ses propres motivations et non de facteurs extérieurs. L’apprentissage n’est pas la seule caractéristique intéressante de l’approche neuronale. Nous aborderons succinctement l’intérêt du codage en population et celui des réseaux récurrents. Plus particulièrement, nous nous attarderons sur les mécanismes de compétition, très utilisés dans 251.1. UNE BRÈVE INTRODUCTION AUX RÉSEAUX DE NEURONES ARTIFICIELS mes travaux. L’intérêt d’une compétition réside dans le fait que des neurones en rivalité réalisent un processus décisionnel doté de propriétés intéressantes. La décision, nous le verrons, est également une caractéristique essentielle pour la survie et l’autonomie d’un agent. 1.1 Une brève introduction aux réseaux de neurones artificiels Un réseau de neurones artificiels est un modèle computationnel utilisé pour réaliser un ensemble de traitements en certains points semblables à son homologue biologique. Le premier modèle mathématique du neurone biologique a été proposé par McCulloch et Pitts en 1943 [McCulloch et al., 1943] et a été repris en 1958 par Rosenblatt [Rosenblatt, 1958] dans son célèbre modèle du Perceptron. Le perceptron est un classifieur linéaire composé de couche de neurones formant un réseau. Chaque neurone du réseau est une unité computationnel effectuant une somme pondérée de ses entrées. L’information en entrée peut provenir d’un capteur (e.g. rétine) ou bien de la sortie d’autres neurones. Chaque entrée e est pondérée d’un poids synaptique w, modulant l’importance de certaines entrées par rapport à d’autres dans le résultat en sortie (voir fig. 1.1). Pour n entrées, le calcul de l’activité (ou potentiel) Pi d’un neurone i est donc défini tel que : Pi = Xn 1 xn.wn (1.1) Ce potentiel de sortie peut ensuite subir une transformation non-linéaire par le biais d’une fonction d’activation, usuellement un seuillage ou bien une base radiale (e.g. base sigmoïdale), prodiguant ainsi nombre de propriétés intéressantes. Il est important de bien choisir la fonction d’activation pour obtenir un modèle utile en pratique. Dans la suite de ces travaux, nous utiliserons principalement une fonction d’activation linéaire ou bien un seuillage binaire tel que : Seuillage binaire : Sb(P) =  1 si P > S 0 sinon. (1.2) Avec S, un seuil particulier. Bien que la réponse réelle d’un neurone biologique soit souvent impulsionnelle (spike), le mod- èle approxime l’activité de sortie par un potentiel d’activité, ou fréquence moyenne de décharge. Certains modèles plus fins prennent en compte cet aspect impulsionnel (spiking neurons) dont le premier a été introduit par [Hodgkin and Huxley, 1952]. Nous allons maintenant nous concentrer plus précisément sur les règles qui permettent à ces réseaux d’apprendre par association. 1.2 Conditionnement L’apprentissage associatif, ou apprentissage par conditionnement est une des techniques d’apprentissage les plus simples observée chez l’animal. C’est le physiologiste Pavlov qui, le premier, introduisit la notion de conditionnement classique [Pavlov, 1927] illustré dans sa fameuse expérience de conditionnement du chien (voir fig. 1.2). Pavlov avait remarqué que la vue ou l’odeur de la nourriture (stimulus inconditionnel (US)) activait de manière réflexe une - 26 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN FIGURE 1.1 – Comparaison entre neurone biologique et neurone formel. A - Le neurone biologique intègre l’activité présente sur ses dendrites (entrées). La fréquence (ou potentiel) de décharge de l’axone (sortie) dépend de cette activité dendritique. Les terminaisons neuronales viennent se connecter aux dendrites d’autres neurones via des synapses. B - Le fonctionnement du neurone formel est assez similaire : la sortie est fonction de la somme des entrées par les poids synaptiques. L’utilisation d’une fonction d’activation radiale permet de traiter des problèmes non-linéaires. salivation de la part du chien. Pavlov présentait ensuite, de manière répétée, le son d’une cloche (stimulus conditionnel (CS)) à chaque fois que la nourriture est présentée au chien. Au bout d’un certain temps, le son de la cloche est associé à la nourriture et active donc la salivation du chien, et ce même lorsque la nourriture n’est pas présentée. L’apprentissage consiste donc en l’association d’un stimulus nouveau à un stimulus réflexe (e.g. si une réaction réflexe R survient suite à la perception d’un stimulus particulier (e.g. une odeur), il est possible d’apprendre à déclencher cette même réaction R suite à la perception d’un son en faisant systématiquement précéder l’odeur par le son). Quelques années plus tard, Thorndike et Skinner ont introduit la notion de conditionnement instrumental (ou opérant) [Skinner, 1938] qui rend compte de l’aptitude des animaux à apprendre le lien entre 2 événements et ce quel que soit la nature de ces événements (stimulus externe, action, etc..). Skinner distingue le conditionnement opérant du conditionnement classique par le fait que la réponse ne soit pas une réaction réflexe de l’organisme. L’animal est donc capable d’apprendre une association entre 2 stimuli présentant un lien apparent. Ce lien apparent amène au concept clé de corrélation. 2 stimuli sont corrélés s’ils sont liés d’une manière ou d’une autre. Le type le plus simple de liaison est la relation affine. Dans le cas de deux variables, elle se calcule au travers d’une régression linéaire. La mesure de la corrélation linéaire entre les deux se fait alors par le calcul du coefficient de corrélation linéaire. Ce coefficient est égal au rapport de leur covariance et du produit de leurs écarts types. Le coefficient de corrélation est compris entre -1 (anti-corrélation) et 1 (corrélation maximum). Attention toutefois à ne pas confondre corrélation et causalité. Deux événements peuvent être corrélés sans pour autant impliquer un rapport de cause à effet. Par exemple, la probabilité de mourir n’augmente pas lorsque l’on se trouve dans un lit d’hôpital, mais on y est généralement pour soigner une maladie, et lorsque l’on est malade la probabilité de mourir est plus grande. Confondre ces 2 concepts peut amener à des raisonnements biaisés comme en joue l’humoriste Coluche : « 1/3 des accidents de la route étant dus à des conducteurs alcooliques, qu’attend-on pour punir les 2/3 de conducteurs sobres responsables de la majorité des accidents ? » L’un des algorithmes applicables pour modéliser un conditionnement classique est le principe de réduction des erreurs quadratiques moyennes (Least Mean Square (LMS)) proposé en 1960 par [Widrow and Hoff, 1960]. Cet algorithme permet un apprentissage supervisé d’un flux d’ac- - 27 -1.2. CONDITIONNEMENT FIGURE 1.2 – Conditionnement classique : A - La vue de la nourriture (stimulus inconditionnel) fait saliver le chien de façon réflexe (poids synaptique = 1). B - Le son d’une cloche (stimulus neutre) n’a au départ aucun effet sur la salivation (poids synaptique nul). C - Pendant la phase de conditionnement, on présente de façon répétée la nourriture et le son de cloche simultanément. Le poids synaptique liant la cloche et la salivation se renforce progressivement. D - Une fois le conditionnement terminé, le son de la cloche activera la salivation même en l’absence de nourriture. tivité d’entrée. C’est une méthode d’optimisation qui consiste en la modification des poids synaptiques w jusqu’à trouver l’erreur quadratique moyenne minimale entre l’entrée e et la sortie désirée Sd. Dans l’exemple suivant, nous considérons un réseau à 3 neurones. Un neurone code pour le signal d’entrée Ei , un autre pour la sortie désirée Sdj et enfin un troisième représente la sortie Sj du système. Ici il n’y a donc qu’un seul poids synaptique wij , reliant l’entrée Ei à la sortie Sj . Le système commence à apprendre lorsque qu’il existe une différence de potentiel entre la sortie réelle S et la sortie désirée Sd. Son unique but est de faire diminuer cette différence en modi- fiant la valeur du poids wij . L’adaptation du poids wij est d’autant plus forte que la différence Sdj − Sj est grande. Voici l’équation décrivant cette règle d’apprentissage : ∆wij = λEi .(Sdj − Sj ) (1.3) Le paramètre λ permet de contrôler la vitesse d’apprentissage (λ < 1). A chaque itération, l’algorithme calcule également la nouvelle valeur du poids wij et de la sortie Sj : - 28 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN wij (t + 1) = wij (t) + ∆wij (t) (1.4) Ces apprentissages par conditionnement ont été largement utilisés dans le cadre de recherches impliquant des réseaux de neurones artificiels [Grossberg and Morahan, 1971; Grossberg, 1972a; Rescorla, 1967]. Il existe également d’autres méthodes d’apprentissage associatif comme la rè- gle de Hebb [Hebb et al., 1949] ou encore la classe des apprentissages par renforcement initiée par [Klopf and Laboratory, 1972; Klopf, 1975] puis adapté par [Anderson et al., 1983]. L’apprentissage par renforcement fait référence à une classe de problèmes dont le but est d’apprendre à partir d’expériences, ce qu’il convient de faire en différentes situations de façon à optimiser une récompense au fil du temps. On peut par exemple considérer un agent autonome, plongé au sein d’un environnement, devant prendre des décisions en fonction de son état courant. En retour, l’environnement procure à l’agent des récompenses, qui peuvent être positives ou négatives. L’agent cherche un comportement décisionnel optimal appelé stratégie ou politique : une fonction associant à l’état courant l’action à exécuter. Cette politique est optimale si elle permet à l’agent de maximiser la somme des récompenses au cours du temps. Parmi les premiers algorithmes d’apprentissage par renforcement, on compte le TD-learning (Temporal Difference learning) initié par [Sutton, 1988] et une de ses variantes célèbre : le Q-learning (Quality learning) proposé par [Watkins and Dayan, 1992]. On pourra se référer à [Wiering and van Otterlo, 2012] pour un état de l’art sur les différentes méthodes d’apprentissage par renforcement. Formellement, la base du modèle d’apprentissage par renforcement consiste en : 1. un ensemble d’états S de l’agent dans l’environnement. 2. un ensemble d’actions A que l’agent peut effectuer. 3. un ensemble de valeurs scalaires "récompenses" R que l’agent peut obtenir. À chaque pas de temps t, l’agent perçoit son état St et l’ensemble des actions possibles dans cet état A(st). Il choisit une action qui implique un changement d’état et parfois une récompense. L’algorithme doit permettre à l’agent de développer une politique Π : S → A qui lui permette de maximiser le cumul de récompenses R = P t λt .rt (λt est un facteur compris entre 0 et 1 permettant de prendre en compte les récompenses plus ou moins loin dans le futur pour le choix des actions de l’agent). L’apprentissage par renforcement est particulièrement adaptée aux problèmes nécessitant un compromis entre la quête de récompenses à court terme et celle de récompenses à long terme. Nous allons nous intéresser maintenant aux mécanismes génériques de compétition qui seront utilisés tout au long de ces travaux. 1.3 Compétition Les mécanismes de compétition sont un type de réseaux dont la topologie caractéristique (la façon dont les neurones sont connectés à leur voisins) permet à chaque neurone de se mesurer aux autres pour le partage de l’activité neuronale. La compétition est le résultat d’une dynamique d’inhibition réalisée par le biais de connections latérales inhibitrices. Ces processus naturels de compétition permettent une prise de décision, à l’instar d’un système de vote. Prendre des décisions s’avère bien souvent être une caractéristique indispensable pour assurer la survie de l’animal. - 29 -1.3. COMPÉTITION 1.3.1 Winner Takes All L’idée de base du Winner Takes All (WTA) provient des modèles connexionistes [Grossberg, 1976, 1988; Kohonen, 1984; Feldman and Ballard, 1982]. Ils permettent de simuler les mécanismes de compétition existant au sein d’une population de neurones. Des liaisons inhibitrices latérales permettent de simuler le processus de compétition. Après convergence, seul le neurone ayant la plus grande activité reste actif et inhibe tous les autres [Rumelhart and Zipser, 1986; Lippmann, 1987; Carpenter and Grossberg, 1988; Lee et al., 1999]. Considérons deux neurones i et j possédant chacun une seule entrée et une seule sortie (voir fig. 1.3). Une excitation en entrée activera le neurone concerné qui déchargera à son tour (potentiel d’activité sur sa sortie). Supposons que les 2 neurones soit connecté entre eux par des connections inhibitrices, de telle sorte que lorsque i est activé, il tende à inhiber j, et réciproquement. Une liaison inhibitrice sera représentée par un poids synaptique négatif. Supposons maintenant FIGURE 1.3 – Principe d’un mécanisme de compétition. A - Réseau minimaliste de compétition entre 2 neurones i et j. Chaque neurone possède une seule entrée et une seule sortie. Chaque neurone est relié à l’autre par une connexion inhibitrice (-1). Au temps t1, i et j reçoivent une excitation très similaire (respectivement 0.6 et 0.5). Au fil du temps, le neurone le plus actif prend le dessus sur l’autre (t2, t3 puis t4). A régime permanent (t4), le réseau est parvenu à prendre une décision. B - Un réseau de compétition comportant plus de neurones fonctionne selon le même principe : chaque neurone tente d’inhiber les autres via des connections inhibitrices. Pour une prise de décision plus rapide, les neurones peuvent s’auto-exciter via une connexion récurrente. que les 2 neurones soient excités par une activité très similaire (e.g. 0.5 et 0.6), alors au fil du temps le réseau s’éloignera de cet état instable. L’unité la plus active au départ tendra vers une activité maximum et la moins active vers une activité minimum. Ce principe peut se généraliser à un plus grand nombre d’unités. Il suffit que chaque neurone inhibe l’ensemble des autres neu- - 30 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN rones par des connections latérales négatives/inhibitrices. En plus des connections inhibitrices, chaque neurone peut également s’auto-exciter par le biais d’un lien récurrent, ce qui accélére le processus de déséquilibre. La variation du potentiel d’action d’un neurone xi du groupe est définie par : dxi dt = αxi − β X K k6=i xk + Ii (1.5) Avec K le nombre de neurones du groupe, Ii l’activité entrante du neurone i, α ∈ 0, 1 le poids du lien récurrent autoexcitateur du neurone i et β ∈ 0, 1 le poids des liens inhibiteurs provenant des autres neurones du groupe. Un réseau possédant ce type de topologie inhibitrice assure qu’un seul et unique neurone possède tout le potentiel d’activité lorsque le réseau à atteint un régime permanent. Ce mécanisme très simple permet de faire émerger une fonction de prise de décision en utilisant un nombre minimum de règles rudimentaires impliquant un équilibre instable, sans besoin de prescrire une procédure complète. Le fait de jouer sur la fonction d’activation des neurones permet d’obtenir une compétition plus ou moins stricte. Plusieurs gagnants peuvent ainsi être conservés ("Soft WTA" ou "k-WTA") [Maass, 2000]. 1.4 Classification Pour reconnaître, apprendre et agir dans un environnement aussi complexe que celui que nous connaissons, un des aspects nécessaires est de recourir à des méthodes de classification. Ces méthodes permettent de capturer les caractéristiques importantes des signaux sensoriels pour en former des abstractions, c’est à dire des informations de plus haut niveau permettant à l’animal de généraliser. La classification est un domaine vaste qui propose des méthodes pour réaliser un partitionnement de données (data clustering). Elle permet de diviser un ensemble de données en différents ensembles homogènes, en ce sens que les données de chaque sous-ensemble partagent des caractéristiques communes, qui correspondent le plus souvent à des critères de proximité que l’on définit en introduisant des mesures de distances ou de similarités entre objets. La classification peut être supervisée ou non. Ici nous nous limiterons au cas non-supervisé. L’algorithme des k-moyennes (k-means) [MacQueen, 1967] est l’une des méthodes d’apprentissage non-supervisé les plus simples qui illustre bien la façon dont il est possible de classifier des données. Cette méthode propose de catégoriser un ensemble de données au sein d’un certain nombre de classes (clusters), dont le nombre est fixé à priori. L’idée maîtresse est de définir k centroïdes, un par classe. Ces centroïdes sont placés aléatoirement dans l’espace des données tout en s’assurant qu’ils soient autant que possible loin les uns des autres (voir fig. 1.4). Chacune des données est associée au centroïde le plus proche. A chaque itération, la position de chaque centroïde est mise à jour en calculant le barycentre des données qui lui sont associées. L’opération est répétée jusqu’a atteindre un état de convergence à partir duquel les positions des centroïdes se sont stabilisées. Le but de l’algorithme est de minimiser la fonction de l’erreur quadratique J. - 31 -1.4. CLASSIFICATION FIGURE 1.4 – Classification par la méthode des k-moyennes (k-means) : illustration du principe pour 5 classes (k=5). A - A l’initialisation, k=5 classes (points noirs) sont réparties de manière aléatoire dans l’espace des données (points colorés). 5 catégories (zones colorés) sont créées en associant chaque donnée à la classe la plus proche. Les partitions représentent un diagramme de Voronoï [Voronoi, 1908]. B, C - A chaque itération, le centroïde de chaque catégorie devient la nouvelle moyenne de la classe. Cette opération est répétée jusqu’a atteindre convergence. D - Après convergence, les moyennes de chaque classe ne sont plus modifiées. Le système à atteint une catégorisation optimale des données. J = X k j=1 Xn i=1 ||x (j) i − cj ||2 (1.6) Où ||x (j) i − cj ||2 est une mesure de distance entre une donnée x (j) i et le centroïde cj . Le résultat est un partitionnement de l’espace des données en cellule de Voronoï [Voronoi, 1908]. Cet algorithme réalise la discrétisation de l’espace d’entrée en ne modifiant à chaque cycle d’adaptation qu’un seul vecteur référent. Le processus d’apprentissage est donc très long. L’algorithme de [Kohonen, 1984] propose une amélioration de la méthode des k-moyennes en tirant profit des relations de voisinage pour réaliser une discrétisation dans un temps beaucoup plus court. Dans nos travaux, certains groupes de neurones seront utilisés en tant que groupe de caté- gorisation, au sein desquels chaque neurone peut représenter une catégorie. Au départ, les poids synaptiques sont initialisés avec des valeurs aléatoires permettant l’émergence d’un neurone gagnant, élu représentant de la première catégorie codant pour l’entrée perçue. Un paramètre de vigilance permet de définir la granularité des catégories. Lorsque l’entrée change, le groupe peut être amené à recruter un nouveau neurone (nouvelle catégorie) si l’activité du neurone gagnant devient inférieure à un paramètre de "vigilance". La modulation du seuil de vigilance par un signal de neuromodulation permettra de modifier, à la volée, la granulatité des catégories apprises. Une vigilance faible impliquera une granularité grossière, et réciproquement. L’apprentissage est là aussi réalisé au sein des poids, dont la modification au fil du temps est définie par : ∆wij = δ k j (aj (t).Ei) (1.7) avec k l’indice du neurone le plus actif (k = ArgM ax(Cj )), δ k j la fonction de Kronecker 1 1. Le symbole de Kronecker est une fonction à deux variables égale à 1 si celles-ci sont égales, et 0 sinon. δ k i =  1 si i = k 0 sinon. (1.8) - 32 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN utilisée pour ne modifier les poids des liens que vers la catégorie gagnante. aj (t) est une fonction qui vaut 1 lorsque le neurone j est recruté et 0 sinon. Afin d’éviter un désapprentissage, le neurone est recruté aléatoirement mais seulement s’il ne code pas déjà pour une catégorie. Au moment du recrutement, on suppose qu’un mécanisme de compétition permet de mettre à 1 son activité (et les autres à 0), ce qui permet de ne modifier ensuite que les poids synaptiques des liens entre la couche d’entrée et le neurone recruté. Les poids des liens entrant du neurone recruté sont modifiés pour correspondre au motif présent en entrée (voir fig. 1.5). Intuitivement, la forme d’entrée est imprimée (copiée) dans les poids, ce qui permet au neurone recruté de "se souvenir" de cette forme ultérieurement. L’activité de ce neurone est ensuite directement dépendante de la nouvelle entrée qu’il perçoit. Si la forme perçue (en entrée) est identique à la forme apprise précédemment (dans les poids), alors l’activité du neurone est maximale (Ck = 1) : le neurone reconnaît la forme. Au contraire, si la forme perçue est complètement différente de celle apprise, l’activité du neurone est minimale (Cj = 0) : le neurone ne reconnaît en rien cette nouvelle forme. A chaque itération, l’activité Cj du neurone j d’un groupe de catégorisation est définie par : Cj = 1 − 1 N X N i=1 |wij − Ei | (1.9) avec N le nombre de neurones du groupe, Ei l’entrée et wij le poids synaptique du lien entre Ei et Cj . 1.4.1 Champs de neurones dynamiques S’inspirant des mêmes principes, beaucoup de recherches se sont consacrées à l’étude d’une population de neurones (champ de neurones) plutôt qu’à celle du neurone particulier. Le nombre de neurones présents dans ne serait-ce qu’une petite portion du cortex est immense. Partant de ce constat, une nouvelle approche est apparue pour étudier des réseaux de neurones au sein desquels l’espace est considéré comme continu. La topologie est telle que des neurones voisins partagent des caractéristiques et activités semblables et donc que l’espace neuronal possède une certaine continuité. Cette notion de continuité peut être approximée par un codage en population, par opposition au concept de neurone grand mère. Le neurone grand mère est un concept populaire qui consiste à considérer chaque neurone comme susceptible d’encoder une idée abstraite à lui tout seul. Selon ce principe, il existerait un neurone précis dans notre cerveau qui s’active uniquement lorsque nous pensons à notre grand mère. De la même manière, un autre neurone s’activerait lorsque l’on pense a un objet particulier ou un concept donné. Au vue du caractère extrêmement distribué et redondant du cerveau, cette théorie est en fait peu plausible même si elle présente l’intérêt certain d’être intuitive et accessible. Le codage en population est, quant à lui, un moyen de coder l’information de manière distribuée justement, au sein d’un groupe de neurones. Dans un tel codage, chaque neurone possède une portion de l’information, mais l’information complète est uniquement accessible lorsque l’on considère la réponse combinée d’un grand nombre de ces neurones. Un avantage de ce type de codage pour la survie d’un animal est son caractère extrêmement redondant. Le réseau peut alors se permettre la perte de quelques neurones sans que cela n’influe de manière dramatique sur l’information globale traitée. Dans les chapitres suivants, nous utiliserons l’une ou l’autre de - 33 -1.4. CLASSIFICATION FIGURE 1.5 – Principe d’apprentissage et reconnaissance de formes. A - Suite à un signal de neuromodulation, un neurone est choisi pour coder une nouvelle catégorie. La forme présente en entrée (la lettre A) est apprise en étant mémorisée dans les poids synaptiques des liens entre la couche d’entrée et le neurone recruté. B - Un nouveau motif est présent en entrée (la lettre C). De la même façon, la catégorie est apprise par un nouveau neurone dont les poids se modifient. C - Après apprentissage, chaque neurone de sortie tente de reconnaître sa catégorie dans le nouveau motif présent en entrée. Ici, le motif présenté est une version dégradée de la lettre A. Le neurone codant pour la catégorie A est donc plus fortement activé que celui codant pour C. ces représentations en fonction du problème à traiter. A priori, la première tentative pour développer une théorie du continuum dans un champ neuronal peut être attribuée à Beurle en 1956 [Beurle, 1956] qui observe des bulles d’activité dans un tissu cérébrale. La théorie est reprise plus tard par Griffith [Griffith, 1963], puis par Wilson et Cowan [Wilson and Cowan, 1973] qui ajoutent les concepts d’inhibitions et excitations du voisinage ainsi que la notion de récurrence. Finalement, le modèle le plus utilisé actuellement nous vient d’Amari [Amari, 1977] qui proposa sa théorie des champs de neurones dynamiques quelques années plus tard. Selon cette théorie, les excitations sont locales tandis que les inhibitions ne sont que distales. Le noyau d’interaction est un laplacien de gaussienne dont la forme particulière rappelle celle d’un Chapeau Mexicain. Le modèle d’Amari L’intérêt du modèle d’Amari est qu’il possède quelques propriétés intéressantes de filtrage, de stabilité ainsi qu’un compromis entre compétition et coopération, là ou un réseau de type WTA reste sensible et seulement compétitif. Considérons un champ de neurones (une population de neurones liés de proche en proche, formant une carte de dimension x). Chaque neurone est connecté à ses voisins suivant une rè- gle définie par le noyau d’interaction. Ce noyau est ici construit à l’aide d’une différence de - 34 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN gaussiennes (DoG), ce qui lui confère cet aspect reconnaissable de chapeau mexicain. Le centre du noyau est excitateur, tandis que les bords sont inhibiteurs (voir fig. 1.6). La dynamique du champ est modélisée par l’équation suivante : FIGURE 1.6 – Principe du codage en population. 1 : Le noyau d’interaction est obtenu à partir d’une différence de gaussiennes (DoG) centre-ON, donnant un profil en chapeau mexicain excitateur (+) en son centre et inhibiteur (-) sur ses bords. 2 : Champ de neurones avec interactions latérales correspondantes. Chaque neurone excite ses voisins proches et inhibe le voisinage lointain. L’information n’est pas encodée dans un unique neurone, mais est distribuée au sein d’une population, formant ainsi une bulle d’activité. τ. u(x, t) dt = −u(x, t) + I(x, t) + h + Z zǫVx w(z).f(x − z, t)dz (1.10) Où u(x, t) représente l’activité d’un neurone x au temps t. I(x, t) est l’entrée du système. h est une constante négative qui assure la stabilité du réseau. τ est le taux de relaxation du système. w est le noyau d’interaction utilisé pour l’activation du champ. Vx est l’intervalle d’interaction qui définit le voisinage. Cette équation confère à l’ensemble de la population des propriétés d’attracteurs qui correspondent à des maxima locaux du champ d’activité. Le réseau réalise également un compromis entre compétition et coopération qui nous sera utile par la suite. Par exemple, imaginons que 2 bulles d’activité soient présentes en entrée (voir fig. 1.7). Si les 2 bulles sont suffisamment éloignées, la dynamique du champ tendra à en sélectionner une seule (mode compétition). Par contre, si les 2 entrées sont suffisamment proches (dépendant de la largeur du noyau), le champ convergera vers une seule et unique bulle en sortie. Cette bulle résulte de la moyenne des 2 entrées (mode coopération), et son amplitude est supérieure à celle des entrées (se référer à [Schöner et al., 1995] pour une démonstration mathématique). La forme du noyau d’interaction est importante et doit être paramétrée en fonction de la tâche désirée. La largeur de la bulle d’excitation (partie positive du noyau) peut être modulée par exemple. Notons qu’un réseau de type "Winner Takes All" est un cas particulier de champ de neurones pour lequel la bulle d’excitation du noyau est réduite au minimum (1 seul neurone). Le réseau comprend également des liens récurrents (un pour chaque neurone), qui ne sont pas illustrés sur les figures. Cette récurrence permet un lissage temporel et donc un filtrage efficace contre le bruit ou les oscillations présentes en entrée. Par exemple, si une entrée apparaît de manière épisodique suite au disfonctionnement d’un capteur, la dynamique temporelle du réseau ne lui laissera pas le temps de s’imposer. Il est nécessaire qu’une entrée reste stable et immobile - 35 -1.4. CLASSIFICATION pendant un certain temps pour être considérée comme digne de confiance et ainsi faire émerger une bulle d’activité en sortie. FIGURE 1.7 – Compromis sélection/coopération. A - 2 entrées distantes à t0 tentent de s’inhiber l’une l’autre puisque les bords du noyau d’interaction sont inhibiteurs. Le réseau converge vers une unique bulle d’activité à t1. Le champ se comporte alors comme un réseau de compétition (WTA). B - 2 entrées proches viennent à fusionner grâce au centre excitateur du noyau d’interaction. La bulle résultante est une moyenne des bulles d’entrée. Le contrôle moteur dynamique de Schöner Les champs de neurones d’Amari ont été utilisés pour résoudre le problème du contrôle moteur, notamment grâce à la théorie des champs dynamiques (Dynamic Neural Fields - DNF) de [Schöner et al., 1995]. En conservant les propriétés intéressantes des champs de neurones citées plus haut, Schöner propose un moyen d’utiliser la continuité des bulles d’activités comme un gradient que le système peut remonter, en considérant comme sortie motrice la dérivée locale du champ d’activité. Nous utiliserons cette théorie comme référence pour le contrôle moteur de nos robots dans la suite de ces travaux, c’est pourquoi il convient d’entrer plus en détails dans la manière dont nous faisons usage de celle-ci. Prenons l’exemple d’un robot, à la morphologie minimaliste, constitué d’un corps circulaire et de 2 roues motrices centrées de part et d’autre de ce corps. Les rotations sur place sont donc possibles. Le robot est muni de capteurs divers (caméra(s), détecteurs ultra-son, capteurs infrarouge, etc...) lui permettant de percevoir l’environnement tout autour de lui. Nous nous intéressons à la manière idéale de représenter les informations provenant de ses capteurs dans le but de réaliser une tâche de navigation. On partira de l’a priori que le robot est non-holonome, naviguant dans un espace à 2 dimensions seulement (translation avant-arrière, rotation gauche-droite). La troisième dimension spatiale sera négligée. Le comportement de notre robot est donc soumis à 2 variables, qui sont la vitesse linéaire et la vitesse de rotation. La vitesse linéaire pourra être constante (dans le cas le plus simple), ou bien modulée par la proximité des obstacles alentours (plus l’obstacle est proche, plus le robot ralentit). La vitesse de rotation devra être modulée par les motivations du robot. Par motivations nous entendrons les objectifs internes du robot permettant de contrôler son comportement (drives). Ceux-ci pourront être, par exemple, un cap à suivre pour rejoindre un but ou bien un obstacle à éviter. L’utilisation de champs de neurones monodimensionnels semble tout indiquée pour encoder les différentes motivations dans l’espace pericorporel du robot (voir fig.1.8). Par soucis de simplicité, considérons un champ de 360 neurones encodant les motivations à va- - 36 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN FIGURE 1.8 – Contrôle moteur utilisant les principes des champs de neurones dynamiques. A - L’espace pericorporel du robot est représenté par un champ d’attraction (1) et un champ de répulsion (2). Chaque neurone code pour un angle particulier. La soustraction des 2 donne un champ Φ (3) contenant les valences motivationnelles de l’agent (attraction pour les bulles positives, répulsion pour les négatives). Une dérivée du champ (4) forme des points attracteurs et répulseurs. Une activité positive entraîne une rotation à droite tandis qu’une négative entraîne une rotation à gauche. L’agent converge naturellement vers les attracteurs et diverge des répulseurs. Une lecture de valeur analogique (5) permet de transformer le champ 4 en ordres moteurs. B - Vue de haut schématique du robot dans son environnement. Chaque neurone du champ pericorporel code pour un angle particulier. Un but est perçu comme une bulle positive (rouge) et un obstacle par une bulle négative (bleue). lence positive (une source de nourriture, un chemin à suivre, une personne avec qui l’agent veut interagir, etc...). Chacun des neurones de ce champ est le représentant d’une portion angulaire de 1° autour du robot, de sorte que l’ensemble du champ couvre un panorama à 360 degrés. Une bulle d’activité dans ce champ représente donc le cap à suivre vers un but, cap que le robot doit essayer de maintenir. De la même façon, un second champ similaire (360 neurones) représente les motivations à valence négative (un obstacle, un danger, une zone interdite, etc...). Une bulle dans ce champ représente un cap que le robot devra éviter. Par la soustraction de ces 2 champs, nous obtenons un 3ème champ (que l’on nommera Φ). Ce champ résume l’ensemble des motivations de l’agent, appétitives et aversives. Les activités de Φ peuvent être positives (appétitives) comme négatives (aversives). Une simple dérivée du champ Φ est réalisée au sein d’un 4ème champ. Elle permet de convertir ces potentiels de motivation en potentiels de rotation, exploitable par le robot pour produire des mouvements. Une valeur négative déclenchera une rotation à gauche tandis qu’une valeur positive déclenchera une rotation à droite. La vitesse de rotation est directement proportionnelle à l’amplitude de la motivation. - 37 -1.5. DISCUSSION Ainsi la dérivée d’une bulle positive donne un point attracteur (en terme de rotation), et celle d’une bulle négative donne un répulseur (voir [Cuperlier et al., 2006] pour plus de détails). La dérivée de Φ est définie telle que : dΦ dt = fatt(Φ) + frep(Φ) (1.11) Force attractive : fatt(Φ) = −λatt.sin(Φ − Φatt) (1.12) Force répulsive : frep(Φ) = λrep.sin(Φ − Φrep) (1.13) avec fatt(Φ) (respectivement frep(Φ)) la force de rotation correspondant à une motivation appétitive (respectivement une motivation aversive). Et λatt (respectivement λrep) un coeffi- cient d’amplitude associé à l’appétit (respectivement l’aversion). On notera que l’éventualité d’un équilibre parfait n’est pas impossible. Si l’on imagine un obstacle séparant le robot de son but dans un alignement parfait, alors les 2 bulles d’attraction et de répulsion s’annihileraient mutuellement. En pratique, ce cas est peu probable dans un monde réel en raison du bruit résultant de l’imperfection des capteurs et effecteurs (point d’équilibre instable). L’intérêt d’adopter un codage par champ de neurones dynamique est triple. Il permet de bénéficier des propriétés de filtrage et du compromis compétition/coopération. Le contrôle moteur devient très intuitif et correspond à la dérivée du champ à la position considérée. Enfin, le DNF prodigue une base au sein de laquelle peuvent être fusionnées les actions de stratégies de natures très différentes, pourvu que ces actions adoptent le même codage et le même référentiel. Nous utiliserons par la suite un champ de neurone dynamique de façon similaire pour représenter l’espace pericorporel du robot et ainsi fusionner de manière efficace les orientations proposées par différentes stratégies. Malgré toutes leurs qualités indéniables, les champs de neurones dynamiques possèdent un inconvénient de taille. Ils possèdent un nombre important de paramètres qui doivent être adaptés pour chaque nouveau problème. En d’autres termes, les champs de neurones dynamiques sont difficiles à paramétrer et peu enclins à s’adapter au changement, mais ils permettent toutefois d’obtenir une solution efficace pour la fusion/sélection de stratégie, tout en proposant un cadre directement adapté au contrôle moteur. 1.5 Discussion Les outils et notions présentés dans ce chapitre ont été abordé(e)s de manière volontairement didactique pour rendre la lecture de cette thèse accessible au lecteur non-initié. Nous avons abordé brièvement le fonctionnement du neurone formel, lequel sera l’unité de calcul élémentaire de ses travaux. Nous avons pu voir que de telles unités sont capables d’apprendre un stimulus d’entrée par la modification de leurs poids synaptiques. Même si le fonctionnement physique reste le même, nous avons réalisé une distinction sémantique entre apprentissage par association et apprentissage par catégorisation. Ainsi, nous parlerons de groupe de catégorisation pour désigner une population de neurones entraînés à reconnaître des formes à partir de stimuli présents sur leurs entrées. Nous parlerons également de conditionnement pour désigner - 38 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN un apprentissage de type conditionnement pavlovien. Au delà de la notion d’apprentissage, nous avons pu voir le fonctionnement d’un codage en population et son intérêt pour les processus de coopération et compétition dynamiques. Nous exploiterons un tel codage au sein de champs de neurones dynamiques. Enfin nous avons présenté les 2 plate-formes robotiques mobiles avec lesquels nous réaliserons les différentes expériences. La plate-forme d’intérieur sera la plus utilisée. Tout ces outils seront utilisés abondamment dans ces travaux et constituent donc une base nécessaire à la compréhension de l’ensemble des chapitres qui vont suivre. Dans le chapitre suivant, nous tenterons de situer notre approche dans la littérature existante sur les modèles de navigation robotiques. - 39 -The ability to navigate in a complex environment is one of the most challenging skills for every animal on this planet. It is crucial for survival, and is even seen as the evolutionary pressure to develop brains. The reason why plants do not have a brain is that they do not have to move. – Wolpert - Love is a many-moleculed thing. CHAPITRE 2 Modèles de navigation en robotique De manière générale, on regroupe sous l’appellation robots mobiles l’ensemble des robots à base mobile, par opposition aux robots manipulateurs. En pratique, le terme robot mobile désigne principalement les robots munies de roues. Ceux n’utilisant pas de roue sont généralement désignés par leur type de locomotion (marcheurs, rampants, aériens ou sous-marins). Historiquement, les robots mobiles autonomes à roues ont été étudiés dés le début des années 50 [Walter, 1953]. Leur faible complexité en fait de bons sujets pour l’étude des systèmes autonomes. Cependant, malgré leur simplicité apparente (mécanisme plan, actionneurs linéaires), ces plate-formes ont soulevé un grand nombre de problèmes difficiles, dont la plupart ne sont toujours pas résolus. Ainsi, alors que les robots manipulateurs se sont aujourd’hui généralisés dans l’industrie, rares sont les applications industrielles qui utilisent des robots pour résoudre des tâches de navigation en totale autonomie. On a vu apparaître, au début des années 2000, quelques plate-formes mobiles autonomes dans l’industrie (chariot guidés) et destinées au grand public (aspirateurs autonomes), mais l’industrialisation de systèmes plus complexes dotés de capacités d’apprentissage bute sur certains problèmes délicats. Contrairement aux robots manipulateurs dont l’espace de travail est restreint et dont les tâches restent connues et répétitives, les robots mobiles sont souvent destinés à évoluer de manière autonome dans des environnements dynamiques, inconnus et peu ou pas structurés (les contrastes et la luminosité peuvent varier fortement, certains objets sont mobiles et enfin la géométrie du monde physique n’est pas connue à priori et peut être complexe). Savoir se localiser et se déplacer de façon cohérente au sein d’un environnement à priori totalement inconnu fait partie des compétences essentielles pour parvenir à naviguer de manière autonome. Selon le point de vue "classique" en robotique, le principal défi provient du fait qu’il soit complexe de construire un modèle interne du monde suffisamment précis pour permettre au système d’opérer en temps réel de façon cohérente. L’un des problèmes majeurs bien connu des roboticiens sous le nom de SLAM (Simultaneous Localization and Mapping) [Smith et al., 1987; Leonard and Durrant-Whyte, 1991] est qu’il semble nécessaire de posséder une carte de l’environnement afin de pouvoir se localiser alors même que cette carte doit être construite au fur et à mesure des déplacements. Sans carte, pas d’estimation de position possible. Sans estimation de position, pas de construction de carte possible. Le paradoxe est similaire à celui de l’oeuf et de la poule. Nous aurons l’occasion de voir que la construction d’une carte n’est pas l’unique solution, ni la meilleure, pour résoudre une grande part des problèmes de navigation autonome. 412.1. NAVIGATION NAUTIQUE Dans ce chapitre nous aurons l’occasion d’appréhender un état de l’art non-exhaustif des stratégies de navigation existantes. Les premières solutions envisagées pour résoudre ce problème de manière générale nous viennent de la navigation maritime. Nous ferons donc un bref parallèle avec ces méthodes historiques et nous noterons que la plupart d’entre elles restent valables et très utilisées en robotique mobile encore de nos jours. Nous passerons ensuite en revue les méthodes de navigation dites "classiques" et leur limitation face à des environnements inconnus et dont les contraintes ne sont pas maîtrisées. Nous verrons comment les animaux sont parvenus à proposer des solutions simples et robustes en abordant le problème sous un autre angle. Le maintien d’invariants sensorimoteurs et la navigation topologique sont des méthodes qui permettent de s’affranchir de manière élégante de problèmes qui semblent difficiles à résoudre vus sous le prisme des méthodes classiques. Nous nous attarderons finalement sur les modèles computationnels existants de la navigation animale. Notre démarche fait partie intégrante de cette approche bio-inspirée de la navigation. 2.1 Navigation nautique Au 15ème siècle, la carte du monde est encore en grande partie muette 1 . Les navigateurs se lancent souvent dans l’inconnu tout en souhaitant à la fois reporter d’éventuelles découvertes sur une carte mais également parvenir à revenir à bon port en fin de voyage. Pour cela, ils devaient estimer leur position au cours de l’excursion. A l’époque, la navigation astronomique est encore peu fiable par manque d’instruments précis (une erreur de mesure de seulement 1 degré induit une différence de position d’environ 100km en Europe). Les navigateurs ont alors eut à résoudre un problème de localisation et de cartographie simultanée, problème encore d’actualité en robotique aujourd’hui (SLAM). Selon Gallistel, la navigation est un processus par lequel on détermine et maintien une trajectoire vers un but [Gallistel and Gelman, 1990]. Selon Levitt et Lawton [Levitt and Lawton, 1990], ce processus se décompose en 3 étapes, ou plutôt 3 questions auxquelles répondre : "Où suis-je ?", "Où se situent les autres lieux vis à vis de moi ?" et "Comment faire pour me rendre dans tel lieu à partir de ma position ?". 2.1.1 Navigation côtière Dans le cas le plus simple, le vaisseau navigue en bordure de côte, ce qui lui permet de se localiser assez précisément grâce aux indices visuels environnants (voir fig. 2.1 - B). La base de la navigation "observée" est le point par triangulation ou trilatération. Les marins utilisent les points remarquables invariants de l’environnement pour pouvoir trianguler leur position, après quoi ils peuvent estimer le cap à suivre vers un but à l’aide d’une carte de cet environnement. Ces points invariants sont nommés des "amers" et l’angle sous lequel ils sont perçus correspond à leur "azimut". La méthode d’estimation par triangulation [Haasbroek, 1968] consiste à mesurer les azimuts de 3 amers. On reporte ensuite l’azimut depuis chacune des positions des amers correspondants. L’intersection des 3 droites obtenues définie un triangle, plus ou moins grand en fonction de la précision des relevés. La position du navire est estimée à l’intérieur de ce triangle. La trilatération est une méthode similaire pour laquelle la position est estimée en fonction de la distance aux amers en lieu et place de leur azimut. Dans la cadre de la navigation visuelle 1. http ://expositions.bnf.fr/lamer/bornes/feuilletoirs/conquete/32.htm - 42 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE monoculaire, on préférera souvent une mesure par triangulation, puisque la mesure de l’azimut est alors plus précise qu’une estimation de distance aux amers (qui ne peut s’estimer visuellement que par la hauteur apparente des amers lorsque les distances sont importantes). FIGURE 2.1 – Principe de la navigation maritime. A - Sans repère visuel, la navigation est réalisée à l’estime. La vitesse et le cap permettent d’estimer sa position, mais cette estimation est soumise au cumul d’erreurs. A chaque nouvelle mesure, les incertitudes s’accumulent, ce qui limite ce type de navigation à des trajets cours. B - La richesse des amers visuels aux abords d’une côte permet une localisation précise par triangulation. La mesure de l’azimut (l’angle) perçu de 3 amers permet de déterminer un triangle virtuel au sein duquel se trouve la position réelle. C - Au large des côtes, les seuls amers disponibles sont les astres. La connaissance de la position terrestre pour laquelle un astre donné est au zénith permet de se localiser : le relevé de son azimut permet de définir un cercle de positions possibles. La mesure de l’azimut de 3 astres permet de déterminer la position exacte par triangulation (à l’intersection des 3 cercles). 2.1.2 Navigation à l’estime Lorsque les explorateurs quittèrent la côte pour s’aventurer en pleine mer, la méthode de localisation par triangulation d’amers devenait impossible par manque d’indices visuels. Ils avaient alors recours à la méthode de navigation à l’estime (voir fig. 2.1 - A). Celle-ci consiste à déduire la position du navire à partir de son cap et de la distance parcourue depuis sa dernière position connue. Le trajet est donc estimé par l’intégrale des vecteurs de mouvements élémentaires au cours du temps. Ces vecteurs sont déduits, à chaque point de mesure, par la vitesse et le cap du navire. Le problème inhérent à ce type de méthode récursive est son cumul d’erreurs progressif. Même si la méthode est très précise localement (sur de petites distances), elle intègre les petites erreurs de mesure et devient vite problématique. En effet, en plus d’une dérive propre au bateau et aux courants marins, chaque nouvelle estimation de position introduit une erreur de mesure du cap due à la précision angulaire ainsi qu’une erreur de mesure de la vitesse. Ces limitations rendaient la méthode inefficace lors de voyages sur de longues distances. L’amélioration de la - 43 -2.2. NAVIGATION EN ROBOTIQUE CLASSIQUE précision des instruments de mesure à permis de ralentir ce cumul d’erreur mais sans repères externes fixes l’utilisation de la navigation à l’estime restait limitée. 2.1.3 Navigation astronomique Pour parvenir à se localiser en pleine mer sans accumulation d’erreur, les explorateurs ont dû prendre en compte les seules informations visuelles disponibles loin des côtes : les étoiles (voir fig. 2.1 - C). Avec l’invention d’outils de mesure beaucoup plus précis, la navigation astronomique est devenue exploitable (deuxième moitié du 19ème siècle). Celle-ci consiste à déterminer sa position à l’aide de l’observation des astres et la mesure de leur azimut (c’est-à- dire l’angle entre l’astre et l’horizon) [Jean, 1990]. La connaissance de la position terrestre pour laquelle un astre donné est au zénith permet de se localiser : le relevé de son azimut permet de définir un cercle représentant l’ensemble des positions terrestres pour lesquels l’astre en question est perçu sous cet azimut. La mesure de l’azimut de 3 astres distincts permet de déterminer la position exacte par triangulation. L’intersection des 3 cercles se trouve être la seule position garantissant les 3 observations. Cette méthode est appelée méthode par interception 2 . Finalement la méthode de navigation la plus fiable consiste à cumuler navigation à l’estime et navigation observée. La navigation à l’estime fournie une localisation plus précise mais est soumise au cumul d’erreurs sur de longue distance. La position devait donc subir une recalibration périodique par le biais d’une estimation de position sur la base d’indices astronomiques afin de limiter cette dérive. Nous allons voir que ces principes sont toujours utilisées en robotique mobile aujourd’hui. 2.2 Navigation en robotique classique Selon le point de vue de l’approche classique de la navigation robotique, la construction d’une carte précise de l’environnement est nécessaire pour qu’un agent parvienne à planifier ses actions et puisse naviguer de manière autonome dans cet environnement. Selon Newman, cette capacité est considérée comme primordiale pour la durée de vie d’agents mobiles autonomes [Leonard and Newman, 2003] La cartographie d’un environnement inconnu est généralement considérée comme l’un des problèmes les plus importants pour atteindre une réelle autonomie en robotique mobile [Thrun, 2002b; Leonard and Newman, 2003]. Les premiers modèles internes de l’environnement ont été proposé par [Nilsson, 1984] puis [Moravec and Elfes, 1985] dans les années 80. Le modèle est basé sur une grille représentant l’espace libre et occupé par les obstacles (occupancy grid). Une méthode alternative basée sur une représentation métrique à ensuite été proposée par Chatila et Laumond [Chatila and Laumond, 1985]. D’autres approches proposent une cartographie topologique (décrivant les connections entre lieux) [Kuipers and Byun, 1991; Mataric, 1992]. A partir des années 90, le domaine est dominé par l’approche probabiliste, dont les travaux de Smith, Self, et Cheeseman [Smith et al., 1987] introduisent un câdre statistique pour répondre au problème du SLAM (c’est à dire, parvenir à cartographier l’environnement tout en s’y localisant dans le même temps). Ces approches probabilistes sont principalement représentées par 2 grandes familles : l’une d’elle utilise la méthode du filtrage de Kalman [Kalman, 1960], tandis que l’autre se base sur l’algorithme Expectation Maximization [Dempster et al., 1977] pour réaliser ces estimations. 2. http ://en.wikipedia.org/wiki/Celestial_navigation - 44 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE Le filtre de Kalman permet d’estimer les états d’un système linéaire dynamique à partir d’une série de mesures incomplètes ou bruitées. Il est utilisé dans une large gamme de domaines technologiques (radar, vision électronique, communication ...). Ce filtre fait l’hypothèse que le bruit est purement gaussien, ce qui est une approximation insuffisante dans de nombreux cas. De plus, il ne permet de traiter que des problèmes impliquant des dépendances linéaires entre les différentes variables [Thrun, 2002b]. Une variante, le filtrage de Kalman étendu permet de traiter les problèmes non-linéaires [Julier and Uhlmann, 2004]. Le filtrage particulaire est une méthode permettant de ne pas se limiter à de telles hypothèses de bruit gaussien et de linéarité, mais cette technique présente un coût computationnel important [Gordon et al., 1993]. Cette technique est utilisée pour la localisation de robot mobile par Thrun et al. [Thrun, 2002a]. De nombreuses variantes de ces méthodes existent, mais leur description et comparaison est en dehors du champ de cet état de l’art. Ces méthodes probabilistes tentent de résoudre 5 problèmes majeurs liés à la cartographie autonome [Thrun, 2002b] : (1) les bruits de mesures ne sont pas statistiquement indépendants. La nature de ces bruits dépend fortement du contexte. Par exemple, l’utilisation d’une caméra panoramique non calibrée crée une erreur de localisation des amers dépendante de l’orientation. S’affranchir d’un bruit non-centré (biaisé) s’avère extrêmement compliqué. De même, pour une navigation à l’estime, le cumul d’erreurs affecte la manière dont les futures mesures seront interprétées (voir fig. 2.2 - a). (2) La dimensionnalité de la représentation augmente considérablement avec la taille de l’environnement et la précision du modèle, ce qui implique une quantité de mé- moire importante. (3) Le problème le plus dur à résoudre est celui de la correspondance qui survient lors de la clôture d’une boucle au sein d’une trajectoire (correspondence ou loop closing problem) [Williams et al., 2009]. La difficulté réside dans le fait de déterminer si plusieurs mesures, enregistrées à des moments différents, correspondent à la même entité physique dans l’environnement. Ce phénomène provient de la nature ambiguë de la perception, phénomène bien connu en psychologie et expliqué par la théorie de la "Gestalt" [Smith, 1988b]. (4) L’aspect dynamique du monde réel peut rendre inopérant le système si des éléments essentiels à la localisation viennent à disparaître. Il est alors nécessaire d’effectuer un réapprentissage pour s’adapter à ces changements. Enfin (5), le système doit pouvoir planifier son chemin au sein d’un environnement partiellement connu. Les solutions doivent bien souvent faire face à un compromis entre réactivité et fiabilité. L’utilisation de méthodes statistiques [Thrun, 2002b] permet de s’affranchir du problème de la navigation en environnement inconnu mais implique de nombreux passages dans chaque lieu, ce qui reste incompatible avec le besoin d’une grande réactivité au stade initial. En restant dans le cadre de l’approche classique de la robotique, les méthodes basées sur la construction de modèles internes du monde sans a priori sont finalement celles qui donnent les meilleurs résultats. Assez récemment une telle méthode à permis des performances impressionnantes de navigation en intérieur sur le long terme (plusieurs semaines) avec changements environnementaux [Andreasson et al., 2005]. Cependant, le passage à l’échelle à des environnements plus larges et moins structurés (extérieurs) pose encore de nombreux problèmes tels que l’explosion de la taille mémoire du modèle interne, l’odométrie non fiables sur terrains accidentés ou encore le recollement de cartes. D’autres méthodes plus ad-hocs donnent de bons résultats en réponse à des problèmes spéci- fiques. Les travaux de Leonard et Newman [Leonard and Newman, 2003] montrent, par exemple, qu’il est possible de développer un algorithme dont le temps de convergence est constant - 45 -2.3. NAVIGATION ANIMALE FIGURE 2.2 – Figure extraite de [Thrun, 2002b]. a - Exemple de trajectoire obtenue à l’aide d’information odométrique uniquement. La figure montre l’impact du cumul d’erreur sur la trajectoire. De petites erreurs peuvent avoir un effet important sur de grandes distances. b - Exemple de cartographie d’un environnement intérieur cyclique. La figure montre le problème de correspondance qui survient lorsque le robot achève une boucle au cours de sa trajectoire. Parvenir à établir cette correspondance est un des plus importants défis dans le domaine du SLAM. dans le cas ou le robot est autorisé à faire des visites répétées de toutes les régions de l’environnement. Steux et Hamzaoui [Steux and Hamzaoui, 2010] sont parvenus à développer un algorithme léger et très simplifié de SLAM dont le code ne dépasse pas 200 lignes. Cet algorithme permet au robot d’atteindre une vitesse de 2.5m/s en embarquant l’ensemble des calculs sur un processeur ARM9. Nguyen et al [Nguyen et al., 2006] propose un modèle également très léger basé sur l’hypothèse d’un environnement formé de plans orthogonaux (ce qui est souvent le cas en intérieur) permettant ainsi de simplifier considérablement la complexité des calculs. Bien que très utilisées dans certains domaines précis, ces méthodes requièrent la plupart du temps un scanner laser précis et donc très coûteux. De plus, elles sont fortement dépendantes du modèle a priori du monde. Des travaux récents visent justement à s’adapter aux déplacements et à l’occlusion d’amers visuels et à se remettre à jour dynamiquement [Lee et al., 2006]. D’autres méthodes donnent de bons résultats dans des environnements fortement dynamiques comme l’algorithme développé par Foka et Trahanias [Foka and Trahanias, 2010]. L’algorithme permet à un robot mobile de se localiser et naviguer dans un milieu encombré (une foule d’êtres humains par exemple). Des approches ensemblistes sont également utilisées pour la robotique sous-marine [Jaulin, 2009, 2011] pour s’affranchir des conditions données par l’environnement (Les fonds marins sableux sont des lieux très pauvres en amers et présentant de fortes redondances). Malgré de nombreux progrès réalisés dans ce domaine, le SLAM présente tout de même des défis importants. Aujourd’hui, il existe de nombreuses méthodes pour cartographier et se localiser simultanément dans un environnement si celui-ci est statique, structuré et de taille limitée. La navigation au sein d’environnements complexes, dynamiques, non-structurés et de grandes tailles restent encore un problème de recherche largement ouvert [Thrun, 2002b]. 2.3 Navigation animale La plupart des animaux possèdent des capacités à trouver leur chemin sans l’aide d’aucune carte ou d’instruments particuliers. Les sternes arctiques (espèce d’oiseaux), les papillons monarques ou encore les saumons migrent régulièrement sur des milliers de kilomètres et parvi- - 46 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE ennent à trouver leur site de reproduction [Dingle Hugh and Drake, 2007]. Selon Wolpert, la capacité à naviguer dans un environnement complexe est l’une des compétences les plus diffi- ciles à réaliser pour les animaux : cette compétence est cruciale pour leur survie et à certainement été un moteur pour le développement du cerveau au cours de l’évolution [Wolpert, 2002]. Cette théorie ne vaut cependant que pour certains animaux, comme les mammifères, et pour des tâches de navigation sophistiquées, comme la reconnaissance de lieux et la planification de trajectoire. Nous allons voir que la plupart des insectes sont tout à fait capables d’exhiber certains comportements de navigation simples et robustes sans besoin d’un système nerveux complexe [Srinivasan and Zhang, 2003; Wystrach et al., 2013]. De nombreux travaux en éthologie se sont intéressés à l’étude des stratégies utilisées dans la nature pour pouvoir naviguer. Von Frisch a montré que les abeilles peuvent naviguer à l’aide du soleil, de la polarisation de la lumière ou du champ magnétique terrestre, bien qu’elles préfèrent s’en référer au soleil lorsque celui-ci est disponible [Von Frisch, 1955]. Keeton a montré que les pigeons voyageurs pourraient même faire usage d’un éventail d’indices aidants à la navigation, comprenant le soleil, le champ magnétique terrestre, l’olfaction et la vision [Keeton, 1971]. Lockley a démontré qu’une espèce de petit oiseau marin, le Puffin des Anglais, peut s’orienter et revenir à son nid très rapidement à condition que le soleil ou les étoiles soient visibles [D. Lack, 1938]. La caractéristique importante à noter ici est qu’une partie des solutions utilisées chez les animaux ne semblent pas recourir à une carte de l’environnement ni à l’utilisation de connaissances à priori. Bien souvent, le maintien d’invariants dans les perceptions suffit à faire émerger un comportement cohérent et robuste. Les animaux semblent prendre des décisions en se basant sur une mesure de corrélation entre l’information actuelle et l’information mémorisée. Leur développement semble basé sur des réflexes et conditionnements relativement simples [Piaget, 1936]. De plus, il semble que l’information extraite et mémorisée se limite à l’information utile pour la tâche. Par exemple, dans le cadre d’une tâche de navigation vers un but, la reconnaissance d’un objet est codé de telle manière que celui-ci puisse être utile pour rejoindre le but [Gaussier and Zrehen, 1995]. Ce point de vue, adopté par de nombreuses espèces, permet à l’inverse des techniques d’intelligence artificielle classiques, de résoudre des tâches complexes avec la seule aide d’un cerveau minimaliste. Les insectes sont des exemples intéressants pour illustrer ce principe. Certaines espèces de fourmis n’utilisent que l’information visuelle directement accessible sur un lieu important afin d’apprendre à retrouver ce lieu [Wehner and Räber, 1979]. Une expérience permet de montrer ce phénomène : un bâton décoré de 2 anneaux noirs est placé à la sortie du nid (voir fig. 2.3 - A et B). La fourmi apprend la position de son nid en mémorisant l’angle sous lequel elle perçoit le motif du bâton. Lorsque ce dernier est remplacé par un bâton 2 fois plus haut, la fourmi se met à chercher son nid à la position pour laquelle les motifs du bâton sont perçus sous le même angle que ceux appris. De la même manière, les guêpes parviennent à retrouver leur nid en apprenant sa position relative aux amers environnants. Tinbergen a réalisé une expérience qui met en évidence cette méthode [Tinbergen, 1969]. La guêpe apprend à reconnaître la position de son nid vis à vis de pommes de pins disposées autour de celui-ci. Elle tourne systématiquement autour de ces pommes de pins pendant plusieurs secondes avant de s’éloigner. Lorsqu’elle revient, les pommes de pins ont été volontairement déplacées de quelques mètres du nid. La guêpe tente alors de retrouver son nid au centre des pommes de pins (voir fig. 2.3 - C et D). - 47 -2.3. NAVIGATION ANIMALE FIGURE 2.3 – Figure extraire de [Gaussier and Zrehen, 1995]. A - La fourmi apprend la position de son nid en mémorisant l’aspect visuel d’un bâton. B - Si le bâton est remplacé par un objet similaire 2 fois plus grand, la fourmi cherche son nid plus loin et ne parvient pas à le retrouver [Wehner and Räber, 1979]. C - Avant de s’éloigner de son nid, la guêpe tourne autour de pommes de pins, disposées tout autour du nid, afin d’apprendre la position de celui-ci. D - Si la position des pommes de pins est déplacée (translation) alors la guêpe ne parvient pas à retrouver son nid [Tinbergen, 1969]. 2.3.1 Intégration de chemin De nombreux animaux ont la capacité d’évaluer en permanence la distance les séparant de leur nid ainsi que l’orientation à prendre pour le rejoindre, comme si un mécanisme de mémorisation du chemin parcouru leur permettait l’accès à tout moment au vecteur de retour au nid (homing vector) où bien à une position ultérieure [Etienne and Jeffery, 2004]. Pour certains animaux, ce vecteur permet un retour direct au nid même après plusieurs heures d’exploration de l’environnement. En 1873, Darwin citait un explorateur de la Sibérie du Nord, Von Wrangell, qui avait observé que les natifs de cette contrée étaient capables de garder un cap en direction d’un point particulier sur de longues distances, malgré des changements de direction incessants et la totale absence de repères célestes ou terrestres [Darwin, 1873]. Le point crucial, relevé par Darwin, est qu’aucun des repères directionnels lointains, comme les repères célestes, ou les autres indices purement directionnels comme le champ géomagnétique, ne peut diriger le déplacement vers un point particulier de l’espace. Ces indices fournissent, au mieux, la direction d’un point unique de l’espace. La détermination d’une position ne peut résulter que d’un processus d’inté- gration de chemin : une navigation à l’estime (dead reckoning). Là encore, la fourmi est un bon exemple pour illustrer un tel processus. Cette dernière quitte généralement le nid à la recherche de nourriture en ayant principalement recours à une stratégie d’exploration aléatoire [Müller and Wehner, 1988; Wittlinger et al., 2006; Grah et al., 2005]. - 48 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE Lorsqu’elle tombe sur une source de nourriture, il a été observé qu’au lieu de parcourir la trajectoire en sens inverse, la fourmi est capable de rejoindre son nid en ligne droite en empruntant le chemin le plus court. Les fourmis forestières pourraient utiliser des indices visuels ou olfactifs pour retrouver le chemin du nid. Les fourmis du désert, quant à elles, n’ont pas accès à de tels indices visuels et les vents puissants empêchent l’utilisation d’indices olfactifs. Ces fourmis ont recours à un mécanisme d’intégration de chemin basé sur des informations idiothétiques : elles comptent leurs pas (voir fig. 2.4). La fourmi du désert "cataglyphis fortis" est ainsi capable de retourner à son nid après une exploration sur plusieurs centaines de mètres [Wehner and Srinivasan, 1981]. FIGURE 2.4 – Mécanisme d’intégration de chemin chez la fourmi. Figures extraites de [Müller and Wehner, 1988; Wittlinger et al., 2006; Grah et al., 2005]. A - Trajectoire d’une fourmi s’éloignant de son nid jusqu’à tomber sur une source de nourriture (F). Malgré une trajectoire complexe et hasardeuse, la fourmi est ensuite capable de retourner à son nid en ligne droite. B - Lorsque la taille des pattes de la fourmi est modifiée (prolongement ou amputation) après qu’elle ait trouvé la source de nourriture, cette dernière sur-estime ou sous-estime la distance au nid. C - Illustration d’une fourmi dont les pattes ont été allongées artificiellement. Une fois la source de nourriture découverte par la fourmi, les chercheurs procèdent à une modification de la taille de ses pattes : un allongement artificiel par le biais d’échasses, ou bien un raccourcissement par amputation. Lors du retour au nid, les fourmis amputées sous-estiment la distance au nid, tandis que celles dotées d’échasses la sur-estiment. Les insectes volants comme l’abeille sont également capables d’intégrer leur chemin en utilisant principalement le flot optique, l’azimut du soleil ou le champ magnétique du ciel [Srinivasan and Zhang, 2003; Wehner, 1994]. Même si ce mécanisme a été principalement étudié chez les rats et les insectes, il semble aussi faire partie intégrante de la navigation spatiale chez l’humain [Maguire et al., 1998]. Les chiens, les hamsters et les humains utilisent principalement leur proprioception [Seguinot et al., 1998; Loomis et al., 1993]. Le choix de la modalité sensorielle varie d’une espèce à l’autre et dépend également de la confiance en cette stratégie dans une situation donnée [Jeffery, 1998] (voir fig. 2.5). 2.3.2 Région hippocampique et cellules de lieu L’hippocampe est une structure majeure du cerveau des mammifères appartenant au système limbique (voir fig. 2.6). Il joue un rôle très important dans la navigation spatiale, la mémorisation à court terme et la consolidation de la mémoire à long terme. Chez l’Homme et le primate, il se situe dans le lobe temporal médian, sous la surface du cortex avec lequel il est en étroite collaboration. Il se compose de trois sous-structures : le subiculum, la corne d’Ammon (composée des - 49 -2.3. NAVIGATION ANIMALE FIGURE 2.5 – Figure extraite et modifiée de [Etienne and Jeffery, 2004]. Comparaison inter-espèce de l’erreur d’intégration de chemin au cours d’une expérience de privation d’information allothétique. Les sujets effectuent un parcours en forme de "L", de (S) à (P) en étant privés de stimuli externes. Une fois en (P), ils tentent de retourner au point de départ par le chemin qu’ils estiment le plus court. Araignées, hamsters et humains sont privés des sens visuel, auditif, olfactif et tactil. Fourmis et abeilles sont privées de références comme le soleil. Les chiens sont privés de vision et d’audition à l’aller mais pas lors du trajet retour. Le trait en pointillés désigne le vecteur de retour réel, tandis que la flèche représente le vecteur emprunté par le sujet. aires CA1, CA2 et CA3) et le gyrus denté. Le système limbique, quant à lui, est un groupement de structures contrôlant les émotions primaires comme la colère, la peur ou le plaisir, la modulation du comportement et la formation de la mémoire [Broca, 1871]. L’hippocampe ferait office de mémoire à court terme et participerait à la consolidation de souvenirs récents dans le cortex, siège de la mémoire à long terme. Au cours de cette consolidation, l’hippocampe se désengage progressivement de la mémorisation et récupération des souvenirs. Le caractère progressif des amnésies rétrogrades à notamment été observé par Scoville et Milner [Scoville and Milner, 2000]. Chez le rat, la région hippocampique a été identifiée comme responsable de la mémoire spatiale [O’Keefe and Dostrovsky, 1971]. FIGURE 2.6 – A - L’hippocampe est situé dans le lobe temporal médian. C’est une structure paire, présente de manière symétrique dans chaque hémisphère. B - Représentation d’une coupe transversale de la région hippocampique du rat ainsi que des principales structures et connexions excitatrices les liants. On retrouve notamment le gyrus denté (DG) et la corne d’Ammon (CA1-3) qui forme l’hippocampe proprement dit. On trouve également la structure para-hippocampique constituée notamment du cortex enthorinal (EC) et du subiculum (Sub). De nombreuses cellules situées dans les régions CA1 et CA3 de l’hippocampe présentent des activités, en terme de fréquence de décharge, correspondant à des positions spatiales précises de l’animal dans l’environnement [O’Keefe and Dostrovsky, 1971]. Ces neurones sont communé- - 50 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE ment appelés "cellules de lieux" puisqu’ils répondent pour des endroits précis de l’espace. Leur activité est caractérisée par une réponse maximale en un point de l’environnement. Cette projection de la réponse neuronale sur l’environnement est appelée "champ de lieu" de la cellule [Rédei, 2008]. Le protocole standard d’enregistrement de ces cellules consiste à implanter des électrodes dans le cerveau d’un rat puis de le placer dans un enclos fermé. La position du rat et la fréquence moyenne de décharge des cellules de lieu sont enregistrées simultanément, après quoi il est possible de tracer l’activité d’une cellule donnée superposée à la trajectoire obtenue. Les champs de lieu se recouvrent entre cellules codant pour des lieux proches. La taille des champs semble principalement dépendre de la taille de l’enclos. Les activités des cellules apparaissent quelques minutes après la première entrée du rat dans l’enclos et peuvent parfois mettre plusieurs semaines pour converger vers une représentation stable [Wilson and McNaughton, 1993]. Après que les champs aient convergés vers une activité invariante, ils restent stables durant des semaines, voire des mois [Thompson and Best, 1990]. On sait également que l’hippocampe possède, avec le septum, un rôle important pour la détection de la nouveauté et la neuromodulation pour permettre l’apprentissage de nouveaux motifs [Hasselmo and Fehlau, 2001]. L’acétylcholine sécrétée dans le septum permettrait d’inhiber l’activation de motifs anciens afin de faciliter l’acquisition des nouveaux [Hasselmo and Schnell, 1994]. Dans la suite de ces travaux nous adopterons la représentation de la fig. 2.7-B pour parler de la réponse (en rouge) d’une cellule unique superposée à la trajectoire (en noir) de l’agent. D’autres part, nous préférerons la représentation de la fig. 2.7-C pour présenter les zones pour lesquels différentes cellules impliquées sont gagnantes (une couleur différente pour chaque cellule). FIGURE 2.7 – A - Figure extraite de [Bird and Burgess, 2008]. champ de lieu d’une cellule hippocampique dans un environnement bi-dimensionnel. Des électrodes, implantée dans le cerveau d’un rat, permettent d’enregistrer l’activité des cellules de lieu pendant que celui-ci explore un enclos de 1m2 . L’activité (en rouge) est superposée à la trajectoire (en noir). B - Figure issue d’internet sous licence libre. Champs de lieu de plusieurs cellules hippocampiques dans un environnement mono-dimensionnel. Chaque couleur correspond à l’activité d’une cellule de lieu différente. On observe des recouvrements entre champs de cellules proches. Bien que les signaux qui permettent d’activer ces cellules soient encore difficiles à caractériser, il apparaît que leur activité est fortement liée aux indices visuels présents dans le milieu. La vision joue un rôle primordial dans l’activation des cellules de lieu puisqu’une rotation de ces points d’intérêt en bordure de l’environnement entraîne une rotation des champs de lieu associés. De même, les champs sont homothétiques de la taille de l’environnement [Muller and Kubie, 1987]. Cependant, d’autres modalités peuvent venir compléter le code spatial. De nom- - 51 -2.3. NAVIGATION ANIMALE breuses expériences montrent, par exemple, le rôle du système vestibulaire et des mécanismes d’intégration de chemin [Foster et al., 1989; Kelemen and Fenton, 2010], des informations olfactives [Zhang and Manahan-Vaughan, 2013], auditives [O’Keefe and Nadel, 1978] et tactiles [Save et al., 1998] dans la construction de ce code. Des études montrent également que les cellules de lieu répondent lorsque l’animal est plongé dans le noir complet et ne peut plus utiliser de repères visuels [Quirk et al., 1990] bien que la précision de la réponse se dégrade au fil du temps. Ces travaux montrent l’importance de certaines informations idiothétiques dans l’activation des cellules de lieu. Certaines études suggèrent que cette intégration d’information multimodale aurait lieu en amont de l’hippocampe, dans le cortex entorhinal (EC), qui constitue la principale entrée de l’hippocampe [Gothard et al., 2001]. Une étude montre qu’en cas de conflits entre modalités idiothé- tique et visuelle, les champs de lieu peuvent devenir instables [Knierim et al., 1998]. Des activités de cellules de lieu ont également été observées dans d’autres régions cérébrales proches de l’hippocampe, notamment dans le cortex entorhinal. Ces cellules de lieu ont la particularité d’exhiber des champs beaucoup plus diffus [Quirk et al., 1992; Sharp, 1999b]. Le gyrus denté (DG) constitue une voie isolée de communication entre EC et le reste de l’hippocampe. D’autres structures comme le subiculum, le cortex retrosplénial, le thalamus, le striatum ou encore le cortex entorhinal jouent également un rôle très important dans la localisation de l’animal puisqu’elles hébergent des cellules de direction de la tête (head direction cells). Ces cellules codent chacune pour une certaine orientation de la tête, agissant de ce fait comme une boussole relative [Sargolini et al., 2006]. Récemment, d’autres cellules particulières ont été découvertes lors d’enregistrement dans le cortex entorhinal dorso-caudal médian (dMEC). Ces cellules, nommées "cellules de grille" (grid cells), ont la particularité de présenter des champs de lieu étroits et multiples. Leur réponse est périodique dans l’environnement, formant ainsi un pavage régulier de l’espace, à l’instar d’une grille [Hafting et al., 2005]. Les cellules de grille pourraient être à l’origine d’un système de localisation spatial basé majoritairement sur des informations idiothétiques. Nous reviendrons plus en détail sur leur fonctionnement dans le chapitre 4. La découverte des cellules de lieu a stimulé la compréhension du fonctionnement de la navigation spatiale chez l’animal. Ces cellules constituent alors la première preuve de l’implication de l’hippocampe dans des tâches de navigation et a réactualisé l’idée de l’utilisation de "cartes cognitives" [O’Keefe and Nadel, 1978]. La notion de carte cognitive correspondrait à une représentation interne de l’environnement permettant à l’agent d’inférer son chemin parmi plusieurs. Elle se base sur l’apprentissage de la topologie existante entre différents états. Ainsi l’animal pourrait remettre en cause la planification de son chemin lors de l’apparition d’un raccourci ou encore sélectionner le chemin optimal vers un but particulier. Le concept de carte cognitive avait déjà été proposée par Tolman 40 ans plus tôt [Tolman and Honzik, 1930]. La navigation vers un but unique n’implique pas nécessairement la construction d’une carte topologique de l’environnement. Dans ce cas, il peut suffire d’utiliser une stratégie purement sensori-motrice en associant simplement une action (une direction à suivre) à un lieu. Dans la suite de mes travaux, nous n’utiliserons pas de carte cognitive mais seulement des associations entre lieux et actions à réaliser. Ce choix nous permettra, dans un premier temps, de pouvoir présenter des solutions dans le cas, plus simple, de la navigation sensori-motrice. - 52 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE 2.4 Navigation robotique bio-inspirée Basée sur les nombreuses études des solutions utilisées chez l’animal pour naviguer, une approche concurrente de la navigation robotique classique s’est développée en proposant des modèles inspirés de la biologie. Cette approche a permis l’apparition de robots réactifs, rapides et capables de comportements simples et robustes. A l’inverse de l’intelligence artificielle classique, les solutions obtenues sont souvent sous-optimales mais adaptatives et se prêtent particulièrement bien aux environnements inconnus. Certaines approches bio-inspirées se veulent également biologiquement plausible et, de ce fait, permettent un enrichissement mutuel des disciplines de la robotique et des sciences du vivant. Les expériences robotiques permettent de confirmer ou d’infirmer certaines hypothèses sur les modèles. A partir des classifications proposés par les ethologues [Gould, 1986], différents modèles d’architectures de contrôle pour la navigation ont été proposés [Trullier and Meyer, 1997]. [Mallot and Franz, 2000] proposent de faire une distinction hierarchique entre stratégies locales de retour au nid (fig. 2.8) et stratégies de recherche de chemin (fig. 2.9). Un classement hiérarchique existe également au sein de chacune des 2 catégories. Parmi les stratégies locales : l’agent a recours à une exploration aléatoire en l’absence d’indice sensoriel. Il peut suivre un sentier si celui-ci existe (dépôt de phéromones ou traces visuelles par exemple). Il peut viser le nid par remontée de gradient si un indice sensoriel saillant y est présent. Enfin, l’agent peut rejoindre le nid par l’apprentissage de relations spatiales entre celui-ci et des amers proches, sans codage de la position du nid lui-même. FIGURE 2.8 – Hierarchie des stratégies locales de retour au nid (homing) selon Franz et Mallot. Figure extraite de [Mallot and Franz, 2000]. a - Exploration aléatoire. b - Suivi de piste ou de sentier. c - Visée du nid (nécessite un indice sensoriel saillant sur le nid). d - Guidage vers le nid par le biais de relations spatiales entre amers environnants. Parmi les stratégies de recherche de chemin : Si l’environnement est relativement statique, un chemin peut être appris par une séquence simple d’associations entre états (lieux) et actions (direction à suivre). Dans le cas d’apparition d’obstacles, des chemins multiples peuvent être appris par la construction d’une topologie entre lieux proches. L’agent connaît ainsi une autre route en cas d’échec sur la première (navigation topologique). Enfin, l’exploration des alentours permet de découvrir des raccourcis (navigation métrique). 2.4.1 Modèles inspirés des insectes L’une des premières constatations de l’approche bio-inspirée a été de dire que, dans de nombreux cas, la construction d’une carte précise du monde n’est pas nécessaire pour résoudre la tâche. Cette constatation est particulièrement vraie dans le cas de l’insecte, dont les ressources - 53 -2.4. NAVIGATION ROBOTIQUE BIO-INSPIRÉE FIGURE 2.9 – Hierarchie des stratégies de planification de chemin selon Franz et Mallot. Figure extraite de [Mallot and Franz, 2000]. a - Chemin simple défini par une séquence d’associations état/action. La stratégie ne s’adapte pas à l’apparition de nouveaux obstacles (e.g porte fermée). b - Des chemins multiples sont envisageables après la construction d’une topologie entre états. L’agent peut choisir une autre route en cas d’échec. c - Explorer les alentours permet à l’agent de découvrir des raccourcis (pointillés) aux travers de lieux inexplorés. cérébrales sont limitées. Dans de nombreux cas, l’animal n’a pas besoin de maintenir un modèle interne du monde, le monde lui-même est son meilleur modèle [Brooks, 1991]. Probablement, la première solution bio-inspirée proposée pour la navigation d’un robot mobile remonte aux années 50 avec le modèle de la "tortue" de Walter [Walter, 1953]. Le robot, doté de roues, de capteurs photosensibles et de lampes à vide, était capable de remonter un gradient de lumière, de déclencher un arrêt sur obstacles, de se recharger en totale autonomie et même de mimer un apprentissage par conditionnement pavlovien (association entre vision et son) jusqu’alors réservé aux systèmes vivants. Plus tard, Braitenberg améliora ce principe en montrant comment des véhicules à l’architecture minimaliste (2 neurones) pouvaient exhiber des comportements complexes [Braitenberg, 1984]. Inspirés de l’abeille, les véhicules étaient capable d’évitement d’obstacles et de phototaxie (suivi de lumière). Un panel de comportements complexes émergeait de la dynamique de la boucle entre agent et environnement, et ce, en ne modifiant que le poids des synapses (comportement peureux, amoureux, agressif, etc...). Les travaux de Brooks au début des années 90 ont permis l’apparition de contrôleurs réactifs [Brooks, 1991]. Son architecture de "Subsumption" a permis le contrôle et l’arbitrage en temps réel d’un ensemble de comportements en parallèle, ce qui restait jusque là impossible avec des contrôleurs basés sur un modèle du monde. Franceschini puis Floreano ont travaillé sur des modèles, inspirés de la mouche, capablent de maintenir le flot optique constant (à partir de la théorie écologique de Gibson [Gibson, 1978]). Ces modèles permettent à un drone volant d’atterrir en toute sécurité sans besoin d’une estimation complexe de la distance ou de la géométrie du sol. La vitesse du drône est proportionnelle à sa distance aux obstacles [Ruffier and Franceschini, 2005; Floreano et al., 2009]. Cartwright et Collet proposent un modèle inspiré des abeilles pour la mémorisation du but [Cartwright and Collett, 1983]. Le modèle réalise une détection panoramique d’amers (snapshot) et permet l’estimation de la direction au but en sommant les contributions des déplacements angulaires de chaque amer. Ce modèle précède les premiers modèles de cellules de lieu. L’association d’amers est difficile et nécessite de connaître l’orientation de l’agent. Une variante améliorée et basée sur la couleur à été proposé par Gourichon et al. [Gourichon et al., 2002]. Gaussier et Zrehen propose un modèle minimaliste, inspiré des insectes, supposant que ces derniers peuvent reconnaître individuellement les amers pour accéder à leur azimut. Ce modèle permet un - 54 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE retour au nid par l’apprentissage des relations spatiales entre les amers environnants et le lieu but [Gaussier and Zrehen, 1995]. 2.4.2 Modèles inspirés des mammifères L’implémentation d’algorithmes copiant le comportement des insectes a donné de très bons résultats mais le passage à des mécanismes cognitifs plus complexes tels que ceux utilisés par les mammifères reste encore un challenge dans les systèmes actuels. Le début des années 1990 à vu naître les premiers modèles computationnels de cellules de lieu hippocampiques. En 1994, Burgess propose un premier modèle basé sur la hauteur apparente de 2 amers visuels (les murs de l’enceinte) [Burgess et al., 1994]. Dans le même temps, Gaussier et Zrehen aboutissent à l’architecture PerAc qui servira de base à nos travaux (l’architecture est présentée en détails dans la section 2.5) [Gaussier and Zrehen, 1995]. Quelques années plus tard, Redish et Touretzky proposent un modèle théorique des processus de navigation à l’oeuvre dans la région hippocampique [Redish and Touretzky, 1997]. Dans ce modèle, le code spatial des cellules de lieu est créé à partir d’informations visuelles (vues locales) et d’informations idiothétiques par le biais du subiculum (intégration de chemin). La sélection de l’action serait réalisée en partie par les ganglions de la base (nucleus accumbens) à partir d’informations spatiales fournies par l’hippocampe. Arléo et al. propose ensuite un modèle de l’hippocampe basé sur des cellules de lieu et de direction de la tête combinant des informations allothétiques (visuelles) et idiothétiques (proprioceptives) [Arleo and Gerstner, 2000; Arleo and Rondi-Reig, 2007] Le système visuel projette dans le cortex entorhinal superficiel, tandis que le système idiothétique (intégration de chemin) projette dans EC profond. L’apprentissage non supervisé de cellules de lieu est réalisé dans les couches superficielles de EC par une règle de Hebb. Le processus d’intégration de chemin est modélisé par des cellules dont l’activité est une fonction gaussienne de la position et de la direction du robot et fait abstraction de la plausibilité biologique. Finalement le recrutement de cellules de lieu multimodales est réalisé de manière autonome à partir d’un seuil de reconnaissance. L’environnement des expériences est réel mais contrôlé et très simplifié : les murs sont striés afin de faciliter la détection de fréquences (amers artificiels) pour la reconnaissance des cellules de vue. Le pavage automatique génère quelques 800 cellules de lieu pour un petit environnement (80x80cm). Les cellules de lieu obtenues servent de base pour un apprentissage par renforcement de l’environnement, mais cette méthode requiert un temps trop important pour des environnements de grandes tailles. D’autres travaux se basent également sur des modèles de cellules de lieu pour étudier des solutions intéressantes de sélection de l’action mais se contentent d’une modélisation en simulation [Foster et al., 2000; Dollé et al., 2008]. De plus, l’activité des cellules est une fonction gaussienne de la position connue du robot. Assez récemment, Milford et Wyeth ont proposé un modèle bio-inspiré, nommé "RatSLAM", pour la cartographie d’un environnement de très grande taille [Milford and Wyeth, 2008]. Le modèle s’inspire de la structure hippocampique du rat et permet à un véhicule mobile de construire en temps réel une carte d’une taille conséquente à partir d’une simple webcam (un quartier urbain complet pour un trajet de 66 km et la catégorisation de 12000 lieux). Une recalibration de la position est effectuée lorsque le système reconnaît visuellement un lieu et un mécanisme de maintien de cohérence permet de corriger la carte à partir de l’odométrie et d’une compéti- - 55 -2.5. PER-AC : UN MODÈLE DE COUPLAGE SENSORI-MOTEUR POUR LA PERCEPTION tion entre de nombreuses poses caméra. Néanmoins, le système est testé en passif d’une part et se veut également "biologiquement inspiré" sans pour autant présenter une grande plausibilité biologique. La navigation au travers de grands environnements intéresse également Cummins et Newman [Newman and Cummins, 2008] qui utilise une méthode dite d’"apparence seule". Le système assigne à chaque nouveau panorama un lieu rencontré précédemment, ou bien un nouveau lieu si la différence constatée est trop importante. Cette méthode ne nécessite aucune estimation de la position métrique du robot et a permis de naviguer sur plus de 1000 kilomètres en milieu urbain. 2.5 Per-Ac : un modèle de couplage sensori-moteur pour la perception Dans de précédents travaux datant du début des années 90, Gaussier et Zrehen ont développé un modèle générique de couplage permettant à un robot d’apprendre des conditionnements entre informations sensorielles (la reconnaissance d’un lieu spatial, d’une position particulière d’un membre, d’une expression faciale, etc...) et action (une direction à suivre, une configuration motrice) [Gaussier and Zrehen, 1995] (voir fig. 2.10). L’élégance du modèle est de proposer une architecture générique de bas niveau et qui ne requiert aucune représentation symbolique du but. Pour la navigation spatiale, l’équipe Neurocybernetique du laboratoire ETIS a proposé un modèle de l’hippocampe et des boucles corticales permettant de contrôler un robot mobile lors de tâche de navigation visuelle [Gaussier et al., 2002; Giovannangeli and Gaussier, 2010; Banquet et al., 2005] et proprioceptive [Gaussier et al., 2007]. FIGURE 2.10 – Per-Ac : Une architecture générique de couplage entre Sensation et Action. Une voie inconditionnelle (en bas) déclenche des actions de manière réflexe. Une autre voie non-réflexe (en haut) apprend à reconnaître une situation sensorielle par le bais d’une compétition (WTA), puis à associer cette situation à l’action déclenchée par la voie réflexe. Une fois l’apprentissage terminé, la reconnaissance de la situation déclenchera l’action correspondante, même lorsque la voie réflexe est inactive. 2.5.1 Modèle de cellules de lieu visuelles Une image panoramique est analysée séquentiellement pour en extraire un ensemble de points d’intérêt qu’une cellule de lieu sera amenée à reconnaître. - 56 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE La caméra monoculaire embarquée, montée sur servomoteur pan-tilt, permet la capture de 15 images successives, correspondant à un panorama à 360 degrés 3 . Le système réalise ensuite un traitement d’images qui consiste en (1) le calcul de l’image du gradient (faisant apparaître les contours des objets à fort contraste dans la scène), puis (2) une convolution avec un filtre DoG (différence de gaussienne) qui permet de faire ressortir les points de forte courbure des contours. Ces points de courbure sont intéressants puisqu’ils sont robustes et invariants aux changements d’échelle. Ils correspondent la plupart du temps à des coins d’objets ou des éléments saillants anguleux (e.g. les 4 coins d’un tableaux sombre sur fond clair constituent des points d’intérêt robustes). Ces traitements permettent, à partir d’images brutes, de mettre en évidence une constellation de points d’intérêt dans le panorama. Afin de reconnaître ces points particuliers, le système apprend de petites imagettes circulaires centrées sur chacun d’eux. Une transformation log-polaire est réalisée sur chaque imagette afin de rendre la reconnaissance plus robuste aux petites rotations et aux changements d’échelle. Chaque imagette (32*32 pixels) est apprise par un neurone codant pour un amer (landmark). Autrement dit, une "cellule d’amer" apprend à reconnaître une imagette particulière. L’activité d’une cellule d’amer dépend de la différence entre l’imagette perçue et l’imagette apprise par cette même cellule. De la même façon, une "cellule de lieu" (place cell) apprend à reconnaître une constellation d’amers associés à leurs azimuts (voir fig. 2.11). L’activité d’une cellule de lieu dépend de la différence entre la constellation amers/azimuts perçue et celle apprise par la cellule. Selon ce modèle, un lieu dans l’environnement est donc représenté par un agencement particulier d’imagettes dans le panorama. Chaque cellule est capable de reconnaître un lieu particulier de manière robuste. Cette robustesse provient en partie du grand nombre d’imagettes extraites (75 par panorama), ce qui permet de reconnaître un lieu même lorsque des objets ont été déplacés ou bien qu’une partie du panorama est occultée. La robustesse provient également de l’utilisation d’un mécanisme de compétition (WTA) qui sélectionne la cellule de lieu la plus active au temps t, c’est à dire le lieu le mieux reconnu. De cette manière, la reconnaissance d’un lieu ne dépend pas d’un niveau absolu de reconnaissance, mais bien d’un niveau relatif entre l’activation des différents lieux. Dans ce modèle, les imagettes locales extraites correspondraient à l’information "What" (Quoi) codée dans le cortex perirhinal ou dans d’autres aires du chemin visuel ventral du cortex temporal du rat [Kolb and Tees., 1990]. Les angles sous lesquels sont vu les amers correspondraient à l’information "Where" (Où), fournie par le cortex parietal par le biais de la région parahippocampique. La fusion des informations "What" et "Where" serait réalisée dans la couche superficielle du cortex entorhinal ou dans le cortex postrhinal [Suzuki et al., 1997; Burwell and Hafeman, 2003]. Dans ce modèle, cette fusion est réalisée par un réseau nommé PrPh (Perirhinal & Parahippocampique). Un neurone du groupe PrPh ne s’active que lorsqu’un amer est reconnu sous un azimut particulier appris pour cet amer. L’azimut absolu est obtenu par la somme entre la position relative de l’amer dans l’image, l’angle relatif de la caméra (tête) et la direction absolue du robot. Le système de cellules de direction de la tête fourni des informations sur l’orientation du robot. Ce système est alimenté par des données provenant d’une boussole magnétique, mais peut se baser uniquement sur une boussole visuelle [Leprêtre et al., 2000; Giovannangeli and Gaussier, 2007] et être complété par des informations proprioceptives. Un système de recrutement permet d’encoder de nouveaux amers si ceux-ci n’avaient jamais été appris. L’activité de cette population de neurones permet donc d’identifier un amer perçu. 3. Le modèle n’a pas besoin de réaliser un panorama complet et peut se contenter de mettre à jour une mémoire dynamique. Il fonctionne également si le robot se déplace pendant la prise de panorama - 57 -2.5. PER-AC : UN MODÈLE DE COUPLAGE SENSORI-MOTEUR POUR LA PERCEPTION ... ... ... ... ... ... ... ... ... ... Azimuths PC WTA ... Action Orientation ... ... ... ... ... ... ... ... ... ... landmarks azimuth landmarks PCv * azimuth PCmultimodal Context Joystick ... ... path integration PCg Grid Cells ... Action orientation ... ... ... Gradient extraction DOG convolution Focus Points Landmarks One to All modifiable connections One to one connections ... ... ... ... ... ... ... ... ... ... amers azimuths PC WTA ... Action orientation ... Grayscale image Gradient extraction DOG convolution Focus Points Local Views (log polar) One to All modifiable connections One to one connections -180 +180 Grayscale image -180 +180 FIGURE 2.11 – Modèle de cellules de lieu : architecture Per-Ac pour la navigation visuelle. A chaque instant, la caméra du robot prend un panorama visuel de l’environnement à 360 degrés. L’image du gradient de ce panorama est convoluée avec un filtre par différence de gaussiènne (DoG) pour en extraire une constellation de points saillants. Le système apprend ensuite des imagettes locales centrées sur les points plus saillants. Ces imagettes sont apprises par des cellules d’amer (landmarks). Un réseau PrPh fusionne les amers et leur azimuts respectifs. Chaque cellule de lieu (PC) apprend ensuite à reconnaître une constellation amers-azimuts particulière. Un mécanisme de compétition (WTA ou softWTA) sélectionne la (ou les) cellule(s) de lieu la (les) plus active(s) au temps t. Enfin, une association est apprise entre la cellule de lieu gagnante et l’orientation actuelle du robot, après quoi le robot s’orientera dans la direction apprise lorsque la cellule correspondante est de nouveau gagnante. L’équation pour l’apprentissage des amers en fonction des imagettes locales est la suivante : dWV A ij (t) dt = R A i (t).XV j (t) (2.1) Où WV A ij représente le poids synaptique entre un neurone de vue locale j et un neurone d’amers i. RA i (t) est un signal de type échelon binaire permettant le recrutement d’un neurone lorsque l’activité du gagnant de la population de neurones passe en dessous du seuil de vigilance ν A. XV est l’activité d’une cellule ayant appris à reconnaître un amer (vue locale), après transformation log-polaire (un neurone par pixel). L’équation pour le calcul de l’activité XA i d’un neurone i recruté correspondant à un amer visuel est la suivante : XA i (t) = 1 − P j |WV A ij (t) − XV j (t)|.Hǫ(WV A ij (t)) P j Hǫ(WV A ij (t)) (2.2) avec Hǫ la fonction de Heavyside telle que Hǫ(x) =  0 si x < ǫ 1 si x ≥ ǫ L’activité XA i (t) d’un neurone non recruté est aléatoire (sa valeur est comprise entre 0 et B, B représentant le niveau de bruit neuronal maximal). La fonction Hǫ permet de détecter les poids ayant appris (ǫ est une valeur positive, proche de 0). L’apprentissage du groupe PrPh est contrôlé par les équations suivantes : dWφP ij (t) dt = R P i (t) · Hγ(X φ j (t)) (2.3) dWAP ij (t) dt = R P i (t) · Hγ(XA j (t)) (2.4) RP i (t) est un signal de recrutement de type échelon binaire, déclenché lorsque l’activité du gagnant de la population de neurones passe sous un seuil de vigilance ν P . La fonction Hγ - 58 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE FIGURE 2.12 – Activité de 4 cellules de lieu enregistrées sur une trajectoire rectiligne de 25m en environnement extérieur. Les 4 maxima correspondent aux endroits précis où les lieux ont été appris. Les points de croisement correspondent aux frontières entre lieux gagnants. Le modèle montre de bonnes capacités de généralisation puisque le champ de lieu d’une cellule (champ pour lequel l’activité de la cellule est au dessus du bruit) est plus large que la zone pour laquelle cette cellule est gagnante. La cellule n°5 correspond à un lieu appris en dehors de l’enregistrement présenté. La cellule n°6 n’a pas été recrutée et son activité est donc nulle. détecte les neurones fortement activés en entrée du PrPh (γ étant proche de 1). L’équation pour le calcul de l’activité XP i du neurone i du groupe PrPh est la suivante : XP i (t) = max(λi(t) · XP i (t − dt), f(max j W φP ij · X φ i · max k WAP ik · XA k − θ)) (2.5) avec f une fonction de seuil telle que f(x) =    0 si x < 0 x si 0 ≤ x < 1 1 si x ≥ 1 θ est le seuil d’activation des neurones du PrPh. XA représente l’activité de l’amer reconnu et Xφ l’azimut sous lequel il est perçu. Un seul amer est traité à chaque itération ce qui implique que le PrPh fonctionne comme une mémoire à court terme, dont le facteur d’oubli est λi(t). Il permet de conserver en mémoire les amers perçus pendant les prises de vue d’un panorama. La mémoire d’un amer est remise à jour par une meilleure reconnaissance et également après un temps défini arbitrairement (après un ou plusieurs panoramas) [Giovannangeli, 2007]. - 59 -2.5. PER-AC : UN MODÈLE DE COUPLAGE SENSORI-MOTEUR POUR LA PERCEPTION L’activité des cellules de lieu, même en condition extérieure, montre un pic d’activité sur le lieu appris et généralise assez bien sur de grandes distances (2 à 3m en intérieur et 20 à 30m en extérieur) (voir fig. 2.12). Ces profils d’activité large ne correspondent pas aux enregistrements hippocampiques (CA1 et CA3) mais plutôt aux profils de cellules enregistrées dans le subiculum ou le cortex entorhinal [Quirk et al., 1992; Sharp, 1999b]. FIGURE 2.13 – Principe de l’apprentissage de comportements simples à base de quelques associations Lieu/Action. Une action est associée à la cellule de lieu gagnante. Chaque lieu est ainsi associé à une direction à suivre (flèche rouge). Chaque fois que le robot se trouve dans un lieu, il se tourne automatiquement dans la direction apprise dans ce même lieu. Ce mécanisme permet au robot d’apprendre des comportements de type ronde (a), ou encore de type retour au nid (homing)(b) à partir de quelques associations Lieu/Action seulement. L’idée maîtresse ici est que la trajectoire n’est pas prescrite mais émerge de la dynamique sensorimotrice en créant des bassins d’attractions (c). A titre d’exemple, le comportement appris en (b) permet au robot de converger vers un lieu but au centre. Pourtant ce lieu n’est pas codé dans la mémoire du robot, mais émerge naturellement comme le fond du bassin d’attraction généré par la dynamique de reconnaissance des lieux A, B, C et D. Dans un monde réel bruité, ce type d’apprentissage est plus robuste qu’une simple remontée de gradient et permet au robot de converger vers le but en "tombant" dans un bassin d’attraction. Chaque cellule de lieu peut ensuite être associée à une action particulière (une orientation à suivre dans notre cas) et peut servir de base à des stratégies sensori-motrices simples. Dans le cadre de l’apprentissage d’une tâche de navigation supervisée, l’humain peut donner la direction à suivre comme signal désiré. Le robot apprendra alors à associer l’état courant (la cellule de lieu gagnante) à la direction désirée. On parlera d’association Lieu/Action. A partir de 3 cellules (ou plus) dont les actions associées pointent vers un but virtuel, il est possible de construire un bassin d’attraction autour de ce but (fig. 2.13-b). La dynamique de reconnaissance des lieux permet au robot de converger naturellement vers le but, sans que celui-ci ne soit explicitement codé [Gaussier and Zrehen, 1995; Gaussier et al., 2000]. Cette stratégie permet également l’apprentissage de ronde (voir fig.2.13-a) [Giovannangeli and Gaussier, 2010]. Ce sont ces rondes sensori-motrices que l’on étudiera abondamment dans la suite de ces travaux. Cette stratégie d’association Lieu/Action se limite cependant à un environnement simple dans - 60 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE lequel un choix entre plusieurs chemins possibles n’est pas nécessaire. Si plusieurs chemins sont possibles, ou que de nouveaux obstacles induisent des minima locaux, on peut avoir recours à une stratégie de planification basée sur la construction d’une carte cognitive [Gaussier et al., 1997]. Atteindre plusieurs buts reste cependant possible avec une stratégie sensorimotrice simple si un bassin d’attraction différent est créé pour chaque but [Gaussier et al., 2000]. 2.5.2 Modèle d’intégration de chemin Outre ce modèle de cellules de lieu permettant une stratégie de navigation visuelle, l’équipe a également développé un modèle d’intégration de chemin à partir d’informations idiothétiques [Gaussier et al., 2007] basé sur les travaux de [Mittelstaedt, 2000]. Une telle stratégie se révèle essentielle dans certaines conditions de privation sensorielle (lorsque l’agent est plongé dans le noir par exemple) et peut être mise en place sur une plate-forme robotique possédant des capteurs odométriques. La stratégie se base sur 2 informations codant pour un mouvement élémentaire du système : la vitesse linéaire ainsi que la vitesse de rotation instantanée (voir fig. 2.14). Les mouvements élémentaires du robot définissent à chaque itération des vecteurs unitaires dans un champ d’entrée Vi . Un champ de sortie Di somme simplement l’activité de Vi au cours du temps. Dans ce modèle, les champs Vi et Di sont des champs neuronaux simplifiés (sans interactions latérales) et supposés de même taille (121 neurones). Chaque neurone code pour une portion angulaire du panorama total à 360° (codage en population). Un nombre impair de neurones est préférable pour des raisons de symétrie, et le nombre de neurones utilisés est un multiple de 360. Par la suite, nous parlerons de champ d’intégration de chemin pour désigner le champ de sortie Di . Un masque sinusoïdal non-négatif 4 est convolué autour de la direction de chaque mouvement élémentaire dans le champ de neurone d’entrée Vi : Vi(t) = 1 + cos(Θ(t)) − θi) (2.6) Avec θi = −2π i N FIGURE 2.14 – Modèle neuronal utilisé dans notre architecture pour le calcul de l’intégration de chemin. Un champ neuronal avec liens récurrents représente une mémoire du chemin parcouru. Le champ intègre les mouvement élémentaires du robot à chaque itération. L’index du neurone le plus actif représente l’orientation du vecteur de mouvement global et son amplitude, la distance globale parcourue. Les mouvements élémentaires sont représentés au sein d’un vecteur de neurones alimenté par l’orientation absolue du robot et sa vitesse linéaire instantanée. Le champ de sortie Di réalise simplement une intégration temporelle de l’activité du champ d’entrée Vi . L’amplitude d’un mouvement élémentaire est modulée par la vitesse linéaire du 4. Une fonction gaussienne ou triangulaire peuvent en pratique faire l’affaire mais la démonstration implique l’usage du cosinus - 61 -2.5. PER-AC : UN MODÈLE DE COUPLAGE SENSORI-MOTEUR POUR LA PERCEPTION robot. L’orientation du robot au temps t sera noté Θ(t). L’activité du champ d’intégration de chemin est définit telle que : Di(t) = [Di(t − dt) + αVi(Θ(t)) − r(t)]+ (2.7) Avec r(t) un signal de remise à zéro de type échelon binaire, utilisé pour la recalibration du champ d’intégration de chemin. [x] + = x si x > 0 et 0 sinon. α représente le gain du système permettant d’empêcher la saturation du champ (0 < α < 1). Sans connections latérales, chaque neurone Di réalise simplement la somme de toutes ses activités passées depuis la dernière remise à zéro. Le champ D encode le chemin total parcouru depuis le point de départ et conserve une forme sinusoïdale (voir fig. 2.15). L’amplitude du neurone gagnant reflète la distance parcouru en ligne droite (à vol d’oiseaux) et son abscisse représente la direction du mouvement global (voir [Gaussier et al., 2007] pour une description complète). FIGURE 2.15 – Principe de l’intégration de chemin. A - Les animaux ont cette capacité d’évaluer la distance les séparant de leur nid ainsi que l’orientation à prendre pour le rejoindre (homing vector), et ce simplement en intégrant leurs mouvements au fil de leur déplacement. B - De la même manière, un robot peut estimer en temps-réel son vecteur-retour en cumulant angle et norme de chacun de ses vecteurs mouvements élémentaires. C - Dans notre modèle, ces vecteurs sont représentés par des sinusoïdes dont l’amplitude correspond à la distance et la phase à l’orientation. On montre que la résultante de la somme de ces sinusoïdes n’est autre qu’une sinusoïde correspondant au vecteur-mouvement global. Cette stratégie se trouve être plus précise localement en comparaison d’une stratégie basée sur des informations allothétiques (externes) telle que la navigation visuelle. Néanmoins l’intégration de chemin possède l’inconvénient d’introduire une erreur cumulative d’autant plus grande que l’on navigue depuis longtemps. Par la suite, il sera nécessaire de recourir à un mé- canisme de recalibration pour limiter cette dérive. Nous reviendrons sur ce mécanisme de recalibration dans le chapitre 4. Dans le chapitre suivant, nous allons nous intéresser à l’analyse du modèle de navigation sensori-moteur PerAc en adoptant un point de vue probabiliste. Nous verrons les liens existants entre ce modèle réactif et d’autres modèles statistiques de reconnaissance de lieu, basés sur une approche bayésienne. - 62 -CHAPITRE 3 Un parallèle entre formalisme neuronal et bayésien La navigation robotique autonome en environnement réel repose sur des mesures bruitées. C’est la raison pour laquelle la plupart des travaux robotique de localisation, de cartographie ou encore de planification sont basés sur des algorithmes probabilistes. La nature statistique de ces méthodes permet de prendre en compte les incertitudes présentes sur les données mesurées au détriment d’une faible réactivité. Pourtant, la nature nous montre que la plupart des animaux sont tout à fait capables d’extraire l’information utile à partir de signaux bruités, tout en conservant cet aspect réactif. Les approches neuromimétiques peuvent donc nous fournir des solutions robustes et innovantes pour aborder ce genre de problème. Par ailleurs, de récents travaux ont dé- montré que le cerveau était capable de réaliser des calculs très similaires aux processus bayésiens [Deneve S, 2004]. De même qu’il est connu depuis longtemps que l’apprentissage d’un conditionnement classique est équivalent au calcul d’une probabilité conditionnelle [Rescorla, 1988]. Les approches bayésiennes et neuromimétiques tendent donc à se rapprocher. Nous proposons, dans ce chapitre, de comparer ces 2 approches dans le cadre de l’auto-évaluation et de la navigation sur de grandes distances. En prenant inspiration de travaux en psychologie et neurobiologie, nous avons d’ores et déjà proposé des solutions pour permettre à un robot de naviguer dans de petits environnements (typiquement 1 salle) et pour de courtes durées (quelques heures) : se référer à la section 2.5 du chapitre précédent. Cependant, plusieurs questions restent ouvertes si l’on désire réaliser le même type de tâches dans des environnements fortement dynamiques et sur de longues périodes temporelles. Les systèmes de navigation robotique autonomes font face à des problèmes d’imprécisions des mesures liées au capteurs et d’incertitudes liées à la contrainte d’un environnement dynamique. L’exploration et la navigation sur le long terme sont des tâches assez ardues. Le changement d’échelle dans la taille de l’environnement implique un apprentissage et une gestion d’un volume de données conséquent qui ouvre certaines interrogations. Comment outrepasser le problème du rapport signal à bruit qui tend à décroître avec le volume d’information ? Comment lever l’ambiguïté présente sur les informations visuelles et réduire l’incertitude de la localisation ? Les systèmes robotiques visant un comportement autonome doivent faire face à 2 principaux défis. Premièrement, le système doit être capable d’extraire et apprendre de manière active l’information pertinente en ignorant celle inutile à la tâche. Deuxièmement, le système doit être capable d’évaluer la qualité de son comportement et l’adapter en fonction de la situation. - 63 -3.1. LIMITATIONS DU MODÈLE ACTUEL Dans ce chapitre nous nous intéressons au premier point en proposant une réflexion et des solutions au problème de l’extraction de l’information pertinente pour la tâche. On notera qu’une telle capacité à sélectionner l’information pertinente implique en elle même une certaine capacité d’évaluation. Nous commencerons par décrire les limitations du modèle d’apprentissage figé précédent. Adopter une approche probabiliste permet de réduire l’ambiguïté inhérente à toute perception visuelle en donnant au système une capacité à inférer sa position par l’apprentissage de la pertinence des amers dans un lieu donné. Nous ferons un rapide tour des méthodes existantes dans la littérature traitant ce type de problème avant d’analyser notre propre modèle de cellules de lieu hippocampiques sous le prisme de l’approche probabiliste. Nous n’essaierons pas de comprendre le fonctionnement de ce réseau neuronal en termes probabilistes, mais plutôt de proposer deux modèles probabilistes équivalents au modèle neuronal. Ces 2 modèles probabilistes correspondent à 2 façons différentes d’aborder le problème. Ils utiliseront simplement les mêmes entrées et viseront à fournir des sorties équivalentes en empruntant finalement au modèle neuronal que les notions que ce dernier manipule. A partir de cette comparaison entre approche neuronale et bayésienne, nous montrerons comment un robot est capable d’apprendre à inférer la reconnaissance d’un amer à partir de la perception de son azimut. Nous montrerons, de la même manière, comment construire des cellules de lieu "probabilistes" en apprenant à inférer la reconnaissance d’un lieu à partir de la perception d’une constellation d’amers-azimuts donnée. 3.1 Limitations du modèle actuel Comme nous l’avons vu précédemment, notre architecture de reconnaissance de lieu a donné de bons résultats lors de tâches de navigation dans de petits environnements et sur de courtes durées. Les capacités de généralisation du système tenaient la première place, et l’usage d’une simple compétition permettait de bonnes performances comportementales lors de tâches de navigation typiquement limitées à une pièce et sur une période temporelle restreinte à quelques heures. On peut se poser la question de la capacité de l’architecture à traiter des problèmes de plus grande taille (plusieurs salles, environnements extérieurs) et à maintenir des performances identiques à long terme (plusieurs jours, semaines, mois). Le système fait alors face à plusieurs problèmes majeurs : 1. La nature ambiguë des informations visuelles amène à des interprétations multiples des vues locales extraites. Lors d’une navigation dans un environnement complexe, une cellule de lieu peut ainsi présenter des champs multiples, c’est à dire répondre à plusieurs endroits dans l’environnement (voir fig. 3.1). La capacité d’un simple mécanisme de compétition à proposer une interprétation cohérente diminue avec l’augmentation du nombre de vues apprises (le rapport signal à bruit tend vers 0). La distance entre les prototypes appris diminue avec le nombre d’amers et la probabilité de fausses alarmes augmente fatalement [Giovannangeli, 2007]. Ce problème est bien connu en robotique mobile sous le nom d’aliasing perceptif (perceptual aliasing) lorsque différentes portions de l’environnement se ressemblent fortement [Marsland et al., 2001]. De précédents travaux ont montré qu’une information de contexte apprise à la volée pouvait constituer une première solution à ce problème en permettant à la fois de limiter la compétition (augmenter le rapport signal à bruit) mais aussi de limiter la puissance de calcul nécessaire en ne calculant - 64 -CHAPITRE 3. UN PARALLÈLE ENTRE FORMALISME NEURONAL ET BAYÉSIEN globalement que l’activité des neurones associés au bon contexte [Cuperlier et al., 2008]. 2. Dans l’architecture actuelle, tous les amers sont traités de manière identique. Le système est incapable de procéder à un tri. Pourtant les amers peuvent avoir des caractéristiques différentes (proximaux ou distaux, mobiles ou immobiles) et être plus ou moins pertinents selon la tâche envisagée. Il est donc nécessaire d’introduire une capacité à prédire la position ou le déplacement de ces amers afin de les caractériser. Ceux dont la position angulaire reste invariante (sur une certaine distance) devraient avoir plus de poids dans la reconnaissance que les amers mobiles, intermittents, redondants ou ambigus. Par ailleurs, le temps de calcul évolue de façon linéaire (compléxité en O(N)) du nombres de lieux appris [Giovannangeli, 2007]). L’ajout d’un mécanisme attentionnel de sélection des amers pertinents permettrait non seulement de réduire les ambiguïtés mais également d’obtenir une complexité asymptotique (bornée) ou logarithmique. 3. L’environnement réel est souvent fortement dynamique. Des amers stables sont amenés à disparaître, tandis que d’autres se révèlent être mobiles et ne devraient donc pas être pris en compte. L’apprentissage actuel "en un coup" ne permet pas de rendre compte de cet aspect dynamique. Même si l’on considère le cas où de tels changements environnementaux ne se produisent que rarement, le cumul de petites modifications et les variations de luminosité posent le problème du maintien de l’activité des cellules de lieu dans le temps. En effet, les tests actuels se limitent à des expériences de quelques heures et le système est incapable de s’adapter à des reconfigurations lentes de l’environnement ou aux changements saisonniers. L’apprentissage ne peut donc être statique, il doit lui aussi être dynamique et adaptatif. Ce problème est connu sous le nom de dérive des concepts (concept drift) [Tsymbal, 2004; Widmer and Kubat, 1996]. Les propriétés statistiques de la variable que le modèle essaie de prédire évoluent au cours du temps d’une manière a priori imprévisible. Ceci pose problème puisque les prédictions deviennent moins exactes au fur et à mesure que le temps passe. Pour permettre au système de traiter ce problème de dérive, celui-ci doit être capable de mettre à jour son modèle régulièrement en prenant en compte les nouvelles observations. Parmi les différentes approches proposées par la communauté du "machine learning" [Miroslav Kubat, 2004; Tsymbal, 2004; Witten and Frank, 2005], l’apprentissage incrémental est considéré comme la méthode la plus adaptée à la résolution de ce problème. Jusqu’à présent, la question de savoir si un amer est pertinent ou non pour la navigation a été largement ignorée ou remplacée par la préselection de modèle a priori servant à définir ce qu’est un "bon" amer [Marsland et al., 2001]. Le risque est double : le superviseur humain peut sélectionner des amers difficilement reconnaissables par la machine, ou bien, au contraire, négliger des amers qu’il juge sans intérêt mais qui pourtant seraient pertinents pour le robot. 3.2 Approche bayésienne et notion d’inférence L’inférence statistique consiste à déduire les caractéristiques statistiques inconnues d’une population à partir d’un échantillon de cette population. Les caractéristiques de l’échantillon, une fois connues, reflètent avec une certaine marge d’erreur celles de la population. Cette méthode de réflexion est souvent attribuée à l’homme et serait fonctionnelle dès la naissance. Pourtant - 65 -3.2. APPROCHE BAYÉSIENNE ET NOTION D’INFÉRENCE FIGURE 3.1 – Expérience mettant en évidence la présence de nombreuses ambiguïtés visuelles au sein d’un couloir. Le robot a appris 4 lieux régulièrement espacés (A,B,C et D) dans le couloir. Le niveau de reconnaissance de ces lieux est ensuite enregistré lors d’une navigation de A vers D à vitesse constante. Chaque panorama à 180° correspond à la vue subjective du robot au moment de l’apprentissage du lieu correspondant. L’environnement est ici particulièrement ambigu avec des lieux qui se ressemble fortement. Le tracé des niveaux d’activité montre de nombreux faux positifs. la vision dominante du XXème siècle est celle de la confusion du bébé : selon W. James, le bébé est un organisme soumis à des entrées sensorielles et incapable pendant une très longue période de les organiser convenablement [James, 1950]. Ce point de vue est partagé par la pédiatrie de l’époque qui considère alors le très jeune enfant comme dépourvu de capacité de structurer ses sensations. Cette vision a également guidé l’oeuvre de Piaget [Piaget, 1967] qui considérait l’enfant de moins de 4 ans comme "précausal", c’est à dire incapable de remonter aux causes de ce qu’il percevait. Durant la première année de vie, selon lui, l’enfant ne vivrait que dans le présent, incapable de saisir la permanence des objets, incapable de se représenter un objet disparu et encore moins de créer des modèles mentaux abstraits de ses connaissances. Plus récemment (2004), de nouvelles visions réfutent la théorie piagetienne en proposant l’idée d’une rationalité précoce chez l’enfant. Les enfants semblent posséder des théories intuitives du monde physique, biologique, psychologique et de sa structure causale [Schulz and Gopnik, 2004]. Une première théorie propose que le bébé dispose dès la naissance d’un noyau de connaissances fondamentales et innées (core knowledge). Ces connaissances comprendraient les concepts d’objet [Kellman and Spelke, 1983], de nombre [Mehler and Bever, 1967], d’espace [Landau et al., 1981] et même de ce que les auteurs appellent une "grammaire universelle" [Chomsky, 1961; Gleitman et al., 1995; Komarova et al., 2001]. Selon une seconde théorie, quand l’enfant joue, il réaliserait en réalité des expériences permettant de tester des modèles comme le ferait un scientifique. Le bébé serait capable de ma- - 66 -CHAPITRE 3. UN PARALLÈLE ENTRE FORMALISME NEURONAL ET BAYÉSIEN nipuler des probabilités, de sélectionner les variables pertinentes, d’éliminer les variables nonpertinentes, de repérer des ambiguïtés ou interprétations multiples et enfin de lever ces ambiguïtés par le jeu [Gopnik, 2001; Gopnik and Rosati, 2001; Oudeyer et al., 2005]. Certains principes, même très abstrait, peuvent ainsi être sélectionnés par apprentissage bayésien. Il n’est alors plus nécessaire de supposer qu’ils soient innés comme le postule la théorie précédente et l’on peut supposer que le bébé découvre par lui même les concepts d’objet, d’espace et de grammaire. L’approche bayésienne permet en fait un compromis entre connaissances innées et acquises. La théorie de l’inférence bayésienne est une théorie mathématique simple qui peut être vue comme une extension de la logique en ce sens qu’elle permet de raisonner en présence d’incertitude. Le raisonnement peut ainsi s’étendre à un continuum de plausibilité plutôt que de se limiter à des conclusions binaires. A l’inverse de l’approche statistique, nécessitant un grand nombre d’observations, l’approche bayésienne permet des inférences rapides et sophistiquées en seulement quelques exemples. Cette particularité expliquerait, par exemple, la capacité des jeunes enfants à tirer des conclusions correctes à partir d’un petit nombre d’expériences [Gopnik et al., 2001]. Les inférences bayésiennes rendent aussi bien compte des processus de perception en proposant l’interprétation la plus probable à partir d’entrées ambiguës. Une expérience de Xu et Garcia montre que les enfants sont capables de telles inférences dès l’age de 8 mois [Xu and Garcia, 2008]. De récents travaux suggèrent que des processus statistiques sont à l’oeuvre dans le cerveau et montrent comment certains codages en population implémentent les principes de bases de l’approche bayésienne. Afin de pouvoir réaliser ces inférences, l’enfant serait donc contraint de raisonner en termes de probabilités et serait également capable de se représenter les distributions de ces probabilités [Pouget et al., 2013]. Par ailleurs de nombreux travaux ont montré que les processus sensori-moteurs à l’oeuvre dans le système nerveux étaient bien modélisés par une approche bayésienne, aussi bien pour réduire les ambiguïtés de la perception [Kersten et al., 2004], combiner informations a priori et observations [Mamassian et al., 2002], lier les informations provenant de plusieurs modalités [Körding et al., 2004] et modéliser des raisonnements complexes [Doya, 2007]. Pratiquement toutes les méthodes de localisation robotique partagent la caractéristique commune d’aborder le problème de la navigation selon une approche probabiliste. Ces méthodes ont recours aux inférences bayésiennes afin de transformer les données brutes, extraites des capteurs, en information exploitable pour la localisation. Certains travaux font usage explicitement de méthodes d’inférences probabilistes, tandis que d’autres ne semblent pas, à première vue, reposer sur de telles méthodes mais celles-ci peuvent en réalité être interprétées comme telles sous certains aspects [Thrun, 2002b]. La raison de ce succès provient du fait que la robotique est caractérisée par des incertitudes et du bruit de mesure important. Les algorithmes probabilistes traitent le problème en modélisant explicitement différentes sources de bruit et leurs effets sur les mesures. Ce problème est sans doute le problème le plus complexe en robotique mobile et a contraint la communauté à adopter une vision singulière en utilisant une méthodologie math- ématique unique pour le résoudre. Le principe de base qui sous-tend la plupart des algorithmes de SLAM est la règle de Bayes [Bayes, 1763]. Supposons que nous voulions en savoir plus sur une quantité X (e.g. un lieu), à partir de données de mesure D (e.g. données issues de capteurs ultrasons, odométrie, vision). La règle de Bayes nous dit que l’on peut déterminer la probabilité de X sachant D, si l’on connaît les probabilités de X, de D et de D sachant X : - 67 -3.3. NOTRE MODÈLE DE CELLULES DE LIEU D’UN POINT DE VUE BAYÉSIEN p(X|D) = p(D|X)p(X) p(D) (3.1) Le terme p(X) est appelé probabilité à priori de X. Il représente l’état des connaissances sur X à un instant donné. De même, le terme p(D) représente la probabilité à priori de D. Cette probabilité est un terme de normalisation de l’équation. Elle assure que la somme des probabilités soit égale à 1. Le terme p(X|D) est appelé probabilité a posteriori de X sachant D. Cette probabilité représente l’inférence ou la "conclusion" que l’on peut tirer sur la variable X à partir des observations D. Le terme p(D|X), pour un D connu, est appelé fonction de vraisemblance (likelihood) de X. Il spécifie la probabilité d’observer la mesure D sous l’hypothèse X. On peut comprendre la règle de Bayes comme : P osteriori = V raissemblance.Apriori Normalisation (3.2) Autrement dit, si l’on connaît dans le détail les causes possibles d’une conséquence observée, l’observation des effets permet de remonter aux causes. A titre d’exemple, la simple observation de la tour Eiffel permet avec une grande probabilité d’en déduire que l’on se situe à Paris, puisque l’expérience nous aura appris que (1) Paris est une ville unique, (2) la tour Eiffel est également unique et enfin (3) la tour Eiffel n’est visible qu’a Paris (en omettant les copies présentes à Tokyo et Las Vegas !). Les travaux de [Khatib, 1986; Thrun, 1995; Lebeltel et al., 2004] ont permis de développer l’approche bayésienne standard pour la navigation robotique (autour de Thrun dont le livre "Probabilistic robotics" fait autorité [Thrun, 2002a]). D’autres travaux proposent une comparaison entre approche neuronale et probabiliste [Ma et al., 2006; Rao et al., 2002; Pfister et al., 2003]. Ces travaux visent à comprendre le fonctionnement d’un réseau neuronal en termes probabilistes. Les travaux de [Filliat and Meyer, 2002] évoquent les relations entre SLAM et construction de carte cognitive. D’autres travaux [Torralba, 1999; Ullah et al., 2008] utilisent une approche probabiliste pour la reconnaissance sémantique de lieux. Il n’y a cependant pas de lien direct entre cellules de lieu et lieu sémantique, ces derniers ne faisant pas partie du cadre de la localisation. De manière générale, on dénote peu de travaux sur une modélisation neuronale des mécanismes d’inférences. La plupart des auteurs réalisent en réalité l’inverse en montrant que leur modèle neuronal possède bien des propriétés probabilistes afin de pouvoir appliquer la règle de Bayes. 3.3 Notre modèle de cellules de lieu d’un point de vue bayésien Nous présentons ici deux modèles probabilistes manipulant les mêmes notions que le modèle neuronal. Tout deux utilisent les mêmes entrées et visent à fournir des sorties équivalentes. Les modèles probabilistes de localisation ou de SLAM partent de l’hypothèse d’existence d’amers et d’une mesure de position. Nous partons de l’existence d’amers (caractérisés dans le modèle par la conjonction d’une signature et d’un azimut) et de lieux. Notons : - 68 -CHAPITRE 3. UN PARALLÈLE ENTRE FORMALISME NEURONAL ET BAYÉSIEN – {s k , θk}k∈{1..K} : l’ensemble des vues locales extraites des images aux positions k. Ce sont des variables aléatoires continues. – s (1..K) : la collection de toutes les signatures de 1 à K et s k : la signature k. – a i l =< wl , si > : la valeur d’activation de la cellule l pour la vignette i du vecteur d’amers. – a i θ =< θ, θi > : l’activation de la cellule θ (les crochets ne décrivant pas un produit scalaire mais simplement une distance). – a i Θ, a i L et a i Y représentent les vecteurs {aθ}θ∈[1..M] , {al}l∈[1..N] et {ay}y∈[1..N][1..M] . De façon générale, nous utiliserons les indices pour désigner les variables aléatoires et les exposants pour désigner une observation. Les variables aléatoires seront représentées en majuscule, leurs valeurs en minuscule. On fera une exception pour les variables d’entrée où variables et valeurs seront confondues afin de simplifier les notations. 3.3.1 Description générale du problème Les entrées du système sont organisées autour d’un vecteur d’amers (landmarks) et d’un vecteur d’azimuts qui se combinent au sein d’une carte bidimensionnelle dont les sorties sont utilisées pour activer un vecteur de cellules de lieu (voir fig. 3.2). Les variables aléatoires associées à ces différents vecteurs ou cartes sont respectivement L, A, Y et X. Dans la suite de cette section, nous aurons recours au terme anglais "landmark" pour désigner un amer visuel. Les entrées sont constituées d’une collection de vignettes vues selon différents azimuts. Elles sont représentées par la collection de variables s (1..K) , θ(1..K) . Les variables L et A sont assimilées aux valeurs des indices des cartes de landmarks et d’azimuts. Ce sont donc des variables discrètes. Il est alors possible d’utiliser P(L = l|s k ), la probabilité que la variable L prenne la valeur l lorsque l’on sélectionne la signature s k , c’est à dire la probabilité que la cellule l soit sélectionnée (ou activée) par la signature s k . Dans le cas de l’azimut, la variable A peut prendre des valeurs d’angle θ en présence de la signature k vue sous l’azimut θ k . La probabilité qu’elle prenne une valeur θ donnée est P(A = θ|θ k ). Ces deux variables L et A se combinent en une carte bidimensionnelle Y correspondant au groupe ΣΠ (voir PrPh : 2.5.1). Y est ensuite utilisée pour produire une variable aléatoire X correspondant aux cellules de lieu. Ces variables sont également discrètes. Y désigne donc les cellules de la carte ΣΠ et ses valeurs les indices de cette carte. Il est possible d’envisager deux approches du traitement des observations successives. La première conduit à factoriser dans un premier temps en fonction des observations puis de tenter d’évaluer les termes intermédiaires. La seconde reporte la factorisation dans une étape ultérieure. 3.3.2 Factorisation immédiate Nous proposons de déterminer la probabilité P(X = x|{S = s k , Θ = θ k}k∈[1..K] ) d’être dans un lieu x, connaissant un ensemble de signatures s k et leur azimut θ k , que nous simpli- fierons par l’expression P(x, {s k , θk}k∈[1..K] ). Afin de calculer cette probabilité, nous utiliserons un estimateur MAP (Maximum A Posteriori) [Duda et al., 2001] : x ∗ = argmax x P(x|{s k , θk }k∈[1..K] ).P({s k , θk }k∈[1..K] ) (3.3) - 69 -3.3. NOTRE MODÈLE DE CELLULES DE LIEU D’UN POINT DE VUE BAYÉSIEN FIGURE 3.2 – Description du modèle de cellules de lieu. Le système prend comme entrées un vecteur d’amers (landmarks) L et un vecteur d’azimuts A. Les 2 vecteurs se combinent au sein d’une carte Sigma-Pi Y (PrPh) dont les sorties servent à activer un vecteur de cellules de lieu X. L’activité d’un neurone de landmark peut être interprétée comme le reflet de la probabilité P(l k /si ) de percevoir le landmark l k sachant la signature s i . Cette probabilité est donnée par une mesure de distance entre la signature apprise s 0 et la signature perçue s i . De même pour l’azimut θ k de ce landmark, l’activité d’un neurone d’azimut reflète la probabilité P(θ k /si ) de percevoir l’azimut θ k sachant la signature s i . Les neurones de la carte Y peuvent être interprétée comme la probabilité P(y/lk , θk ) d’obtenir la conjonction du landmark l k et de l’azimut a k . Finalement l’activité d’une cellule de lieu est définie comme la probabilité P(x/l1..K, θ1..K). La question générale à résoudre est de calculer la probabilité P(x|{s k , θk}k∈[1..K] ). On consid- ère dans un premier temps que les observations sont indépendantes. La règle de Bayes donne : P(x|{s k , θk }k∈[1..K] ) = P({s k , θk}k∈[1..K] |x) P({s k, θk}k∈[1..K] ) P(x) (3.4) Si l’on fait l’hypothèse d’indépendance statistique des données, nous pouvons écrire : P(x|{s k , θk }k∈[1..K] ) = Y K k=1 P(s k , θk |x) P(s k, θk) P(x) (3.5) Soit en appliquant à nouveau la règle de Bayes : P(x|{s k , θk }k∈[1..K] ) = Y K k=1  P(x|s k , θk ).P(s k , θk ) P(s k, θk).P(x)  P(x) (3.6) = Y K k=1  P(x|s k , θk ) P(x)  P(x) =  P(x) P(x)K  Y K k=1 P(x|s k , θk ) =  1 P(x) K−1 Y K k=1 P(x|s k , θk ) (3.7) - 70 -CHAPITRE 3. UN PARALLÈLE ENTRE FORMALISME NEURONAL ET BAYÉSIEN On notera le terme ℓ s k , θk pour désigner la vraissemblance des observations : ℓ h s k , θk i = Y K k=1 P(s k , θk |x) P(s k, θk) (3.8) Distributions intermédiaires : Nous pouvons désormais nous intéresser aux termes du produit QK k=1 P(X = x|s (k) , θ(k) ). En introduisant pour chaque terme de ce produit les variables intermédiaires Lk et Ak : P(x|s k , θk ) = X l,θ P(x|Lk = l, Ak = θ)P(Lk = l, Ak = θ|s k , θk ) (3.9) Dans ce modèle les variable Lk et Ak désignent les index des cartes de landmarks et d’azimuts. Moyennant l’indépendance de Ak et Lk : = X l,θ P(x|Lk = l, Ak = θ)P(Lk = l|s k )P(Ak = θ|θ k ) (3.10) L’équation générale du modèle s’écrit alors (voir fig. 3.3) : P(x|{s k , θk }k∈[1..K] ) =  1 P(x) K−1 Y K k=1   X l,θ P(x|Lk = l, Ak = θ)P(Lk = l|s k )P(Ak = θ|θ k )   (3.11) FIGURE 3.3 – Graphe de dépendance entre les différentes variables du modèle. la signature Sk d’un amer physique donne lieu à la mesure de son identité Lk et de son azimut Ak. Les variables intermédiaires Yk de la carte Sigma-Pi dépendent de la co-activation (produit) du couple Lk et Ak. Un lieu Xk est définit comme la somme d’un ensemble de variables intermédiaires Yk. Nous allons considérer séparément les trois termes de l’équation 3.11. - 71 - Protection obligatoire r´epartie : usage pour le calcul intensif et les postes de travail Damien Gros To cite this version: Damien Gros. Protection obligatoire r´epartie : usage pour le calcul intensif et les postes de travail. Other. Universit´e d’Orl´eans, 2014. French. . HAL Id: tel-01080544 https://tel.archives-ouvertes.fr/tel-01080544 Submitted on 5 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.UNIVERSITÉ D’ORLÉANS ÉCOLE DOCTORALE MATHEMATIQUES, INFORMATIQUE, PHYSIQUE THEORIQUE et INGENIERIE DES SYSTEMES LABORATOIRE D’INFORMATIQUE FONDAMENTALE D’ORLÉANS THÈSE présentée par : Damien GROS soutenue le : 30 JUIN 2014 pour obtenir le grade de : Docteur de l’université d’Orléans Discipline/ Spécialité : Informatique Protection obligatoire répartie Usage pour le calcul intensif et les postes de travail THÈSE DIRIGÉE PAR : Christian TOINARD Professeur des universités, INSA Val de Loire RAPPORTEURS : Ludovic APVRILLE Professeur Assistant, Telecom ParisTech Christian PEREZ Directeur de recherche INRIA, LIP, ENS Lyon JURY : Sébastien LIMET Professeur des universités, Université d’orléans, Président du jury Ludovic APVRILLE Professeur Assistant, Telecom ParisTech Mathieu BLANC Docteur, CEA/DAM/Ile de France Jérémy BRIFFAUT Maître de conférences, INSA Val de Loire Christian PEREZ Directeur de recherche INRIA, LIP, ENS Lyon Christian TOINARD Professeur des universités, INSA Val de LoireRemerciements Je remercie MM. Ludovic Apvrille et Christian Pérez pour avoir accepté d’évaluer mes travaux en étant rapporteurs de cette thèse. Je remercie M. Sébastien Limet pour avoir accepté de participer à mon jury. Je tiens à remercier mon directeur de thèse, Christian Toinard, pour son soutien et son aide durant mes recherches, et de m’avoir offert la possibilité de réaliser cette thèse. Je remercie aussi Mathieu Blanc pour m’avoir accueilli au sein de l’équipe SSI du CEA et m’avoir conseillé tout au long de mes 3 années de thèse, et Jérémy Briffaut pour toute l’aide qu’il m’a apporté dans mes travaux. Je remercie le CEA/DAM/DIF de m’avoir accueilli pendant ces 3 années et de m’avoir fourni les moyens de réaliser toutes les expérimentations nécessaires au cours de mes travaux. Je tiens à remercier Pierre Clairet, Aurélie Leday et Maxime Fonda de m’avoir accueilli chez eux lors de mes déplacements à Bourges. Je remercie aussi Sandrine pour sa relecture minutieuse de ce mémoire ; Matthieu, Frédéric, Thierry, Pascal et Romain pour les nombreuses discussions enrichissantes et pour toute l’aide qu’ils m’ont fourni durant cette thèse ; les membres de l’équipe SDS du LIFO, permanents et non-permanents pour leur accueil durant mes séjours à Bourges. Et enfin, je tiens à remercier mes parents, ma famille et mes amis pour leur soutien tout au long de ces 3 années de thèse. 34Table des matières Table des figures 9 1 Introduction 15 1.1 Contexte de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.2 Observateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3 Exemples d’attaques visant les systèmes d’exploitation Linux et Windows . . . . 17 1.3.1 Exemple d’attaque pour les systèmes Linux . . . . . . . . . . . . . . . . 17 1.3.2 Exemple d’attaque pour les systèmes Windows . . . . . . . . . . . . . . 18 1.3.3 Analyse des deux attaques . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.4 Objectif de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.5 Apports de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.6 Plan du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2 État de l’art 25 2.1 Propriétés de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1.1 Propriétés générales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1.1.1 Confidentialité . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.1.1.2 Intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.1.1.3 Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.1.2 Propriétés dérivées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.1.2.1 Confinement de processus . . . . . . . . . . . . . . . . . . . . 27 2.1.2.2 Moindre privilège . . . . . . . . . . . . . . . . . . . . . . . . 27 2.1.2.3 Séparation des privilèges . . . . . . . . . . . . . . . . . . . . 28 2.1.2.4 Non-interférence . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.1.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2 Modèles de contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.1 Le contrôle d’accès discrétionnaire . . . . . . . . . . . . . . . . . . . . 29 2.2.1.1 Lampson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.2.1.2 HRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.2.1.3 TAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.2.1.4 DTAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.2.2 Le contrôle d’accès obligatoire . . . . . . . . . . . . . . . . . . . . . . . 32 2.2.2.1 Bell-LaPadula . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2.2.2 Biba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.2.2.3 Role Based Access Control . . . . . . . . . . . . . . . . . . . 35 2.2.2.4 Domain and Type Enforcement . . . . . . . . . . . . . . . . . 36 2.2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.3 Implantation des mécanismes de contrôle d’accès . . . . . . . . . . . . . . . . . 38 2.3.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5TABLE DES MATIÈRES 2.3.1.1 SELinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.3.1.2 grsecurity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.3.1.3 Tomoyo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.3.1.4 Policy Interaction Graph Analysis . . . . . . . . . . . . . . . . 43 2.3.1.5 Politique et règle de contrôle d’accès . . . . . . . . . . . . . . 45 2.3.2 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.3.2.1 Mandatory Integrity Control . . . . . . . . . . . . . . . . . . . 46 2.3.2.2 PRECIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3.2.3 Core Force . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3.3 Distributed Security Infrastructure . . . . . . . . . . . . . . . . . . . . . 49 2.3.4 Impact sur les performances . . . . . . . . . . . . . . . . . . . . . . . . 50 2.3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3 Modélisation et répartition d’observateurs 55 3.1 Définition d’un observateur pour les systèmes d’exploitation Linux et Windows . 56 3.1.1 Éléments de base de la protection système . . . . . . . . . . . . . . . . . 57 3.1.1.1 Modélisation du système observé . . . . . . . . . . . . . . . . 61 3.1.1.2 Mode de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.1.2 Définition d’un observateur : le moniteur de référence . . . . . . . . . . 64 3.1.2.1 Phase de pré-décision . . . . . . . . . . . . . . . . . . . . . . 65 3.1.2.2 Phase de décision . . . . . . . . . . . . . . . . . . . . . . . . 68 3.1.2.3 Phase de post-décision . . . . . . . . . . . . . . . . . . . . . . 68 3.1.3 Répartition des observateurs . . . . . . . . . . . . . . . . . . . . . . . . 69 3.1.3.1 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.1.3.2 Localisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.1.3.3 Redondance . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.1.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3.2 Modélisation d’une politique de contrôle d’accès direct . . . . . . . . . . . . . . 73 3.2.1 Grammaire de la politique . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.2.1.1 La portabilité des noms utilisés pour les contextes . . . . . . . 76 3.2.1.2 Modélisation de la problématique des noms . . . . . . . . . . 77 3.2.2 Application de la grammaire sur deux modèles de protection pour les systèmes Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.2.2.1 Policy-Based Access Control . . . . . . . . . . . . . . . . . . 81 3.2.2.2 Domain and Type Enforcement . . . . . . . . . . . . . . . . . 84 3.2.2.3 Lien entre la politique d’accès direct et le moniteur de référence 86 3.3 Les techniques de détournement sur les systèmes Windows . . . . . . . . . . . . 87 3.3.1 Explications des techniques . . . . . . . . . . . . . . . . . . . . . . . . 87 3.3.1.1 Détournement de la table des appels système . . . . . . . . . . 87 3.3.1.2 Inline-Hook . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 3.3.1.3 filter-driver . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 3.3.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.3.2.1 Place de l’observateur dans le contrôle d’accès de Windows . . 91 3.3.2.2 Contrôle des driver . . . . . . . . . . . . . . . . . . . . . . . 92 3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 6TABLE DES MATIÈRES 4 Répartition d’observateurs en environnement HPC et analyse des performances 97 4.1 Méthode de mesure des performances d’un système réparti d’observateurs . . . . 98 4.1.1 Mesures globales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.1.1.1 Mode colocalisé . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.1.1.2 Mode distant . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.1.2 Comparaison des performances . . . . . . . . . . . . . . . . . . . . . . 102 4.1.2.1 Combinatoire . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.1.2.2 Un seul observateur . . . . . . . . . . . . . . . . . . . . . . . 102 4.1.2.3 Deux observateurs . . . . . . . . . . . . . . . . . . . . . . . . 102 4.1.3 Mesures détaillées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.1.3.1 Résultats déduits . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.2 Solution pour répartir les observateurs dans un environnement HPC . . . . . . . . 107 4.2.1 Architecture avec deux observateurs en mode distant . . . . . . . . . . . 107 4.2.2 Choix des observateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.2.2.1 SELinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.2.2.2 PIGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.2.2.3 Infiniband . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 4.2.3 Déport du mécanisme de prise de décision . . . . . . . . . . . . . . . . . 111 4.2.3.1 Le nœud client . . . . . . . . . . . . . . . . . . . . . . . . . . 111 4.2.3.2 Le proxy serveur . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.3 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.3.1 Les moyens de mesure . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.3.2 Résultats sur les performances . . . . . . . . . . . . . . . . . . . . . . . 115 4.3.2.1 Architecture d’expérimentation . . . . . . . . . . . . . . . . . 115 4.3.2.2 Mesures globales . . . . . . . . . . . . . . . . . . . . . . . . 116 4.3.2.3 Mesures détaillées . . . . . . . . . . . . . . . . . . . . . . . . 118 4.3.2.4 Synthèse des mesures . . . . . . . . . . . . . . . . . . . . . . 120 4.4 Amélioration de la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.4.1 Propriété de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.4.2 Application de la propriété de sécurité . . . . . . . . . . . . . . . . . . . 124 4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 5 Contrôle d’accès obligatoire pour Windows et Expérimentations 127 5.1 Politique de contrôle d’accès direct . . . . . . . . . . . . . . . . . . . . . . . . . 128 5.1.1 Path-Based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . 128 5.1.2 Domain and Type Enforcement . . . . . . . . . . . . . . . . . . . . . . 130 5.1.3 Modes de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.1.4 Définition des politiques . . . . . . . . . . . . . . . . . . . . . . . . . . 135 5.1.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 5.2 Implantation des mécanismes de contrôle d’accès obligatoire . . . . . . . . . . . 138 5.2.1 Modification de la table des appels système . . . . . . . . . . . . . . . . 138 5.2.1.1 Architecture fonctionnelle . . . . . . . . . . . . . . . . . . . . 139 5.2.1.2 Détournement de la table des appels système . . . . . . . . . . 139 5.2.2 Architecture basée sur les filter-driver et les Kernel Callback . . . . . . . 142 5.2.2.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . 142 5.2.2.2 Détournement des flux d’exécution . . . . . . . . . . . . . . . 143 5.3 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 5.3.1 Violation d’une propriété de confidentialité . . . . . . . . . . . . . . . . 145 5.3.1.1 Environnement des expérimentations . . . . . . . . . . . . . . 145 7TABLE DES MATIÈRES 5.3.1.2 Scénario des attaques . . . . . . . . . . . . . . . . . . . . . . 146 5.3.1.3 Violation directe . . . . . . . . . . . . . . . . . . . . . . . . . 146 5.3.1.4 Violation indirecte . . . . . . . . . . . . . . . . . . . . . . . . 146 5.3.2 Étude de logiciels malveillants . . . . . . . . . . . . . . . . . . . . . . . 147 5.3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 5.3.2.2 Architecture décentralisée . . . . . . . . . . . . . . . . . . . . 149 5.3.2.3 Protocoles des expérimentations . . . . . . . . . . . . . . . . 152 5.3.2.4 Visualisation des résultats et définition des propriétés de sécurité 153 5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 5.4.1 Pertinence/complétude de la solution . . . . . . . . . . . . . . . . . . . 159 5.4.2 Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 6 Conclusion 161 6.1 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 7 Bibliographie 165 I Annexes 169 A Configuration pour le logiciel linpack et utilisation 171 B Code utilisé pour la réalisation des tests de performances 173 C Les techniques de détournements 175 C.1 Détournement de la table des appels système . . . . . . . . . . . . . . . . . . . . 175 C.2 Inline Hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 C.3 Filter-driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8Table des figures 1.1 Schéma présentant la place de l’observateur avec une politique de sécurité vis-à- vis d’une interaction faite par un processus . . . . . . . . . . . . . . . . . . . . . 17 1.2 Schéma résumant les étapes de l’attaque pour l’exploitation d’une faille noyau sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Schéma résumant les étapes de l’installation d’un rootkit nommé ZeroAccess . . 19 1.4 Représentation sous la forme de liste des interactions directes . . . . . . . . . . . 20 1.5 Association d’observateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1 Couverture des propriétés dérivées vis-à-vis des propriétés générales de sécurité . 29 2.2 Représentation de Lampson d’une matrice d’accès . . . . . . . . . . . . . . . . . 30 2.3 Lois d’application des propriétés de BLP . . . . . . . . . . . . . . . . . . . . . . 33 2.4 Lois d’application des propriétés de BLP-restrictives . . . . . . . . . . . . . . . . 33 2.5 Modèle No Read Up/No Write Down . . . . . . . . . . . . . . . . . . . . . . . 34 2.6 Lois d’application des propriétés de Biba . . . . . . . . . . . . . . . . . . . . . 34 2.7 Modèle de protection des données : Biba . . . . . . . . . . . . . . . . . . . . . . 35 2.8 Schéma d’héritage du modèle RBAC1 . . . . . . . . . . . . . . . . . . . . . . . 36 2.9 Schéma du modèle DTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.10 Implantation des modèles RBAC et DTE par SELinux . . . . . . . . . . . . . . . 40 2.11 Fonctionnement de PIGA-CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.12 Lois d’application des propriétés du MIC . . . . . . . . . . . . . . . . . . . . . . 46 2.13 Modèle de protection des données : MIC . . . . . . . . . . . . . . . . . . . . . . 47 3.1 Schéma du placement de l’observateur . . . . . . . . . . . . . . . . . . . . . . . 57 3.2 Écriture d’un fichier malveillant par Firefox : Windows et Linux . . . . . . . 57 3.3 Écriture détaillée d’un fichier malveillant par un navigateur web . . . . . . . . . 59 3.4 Placement de l’observateur pour détourner le flux d’exécution . . . . . . . . . . 59 3.5 Schéma global de détournement des flux pour les deux systèmes . . . . . . . . . 60 3.6 Mode de sécurité : requête/réponse de l’observateur . . . . . . . . . . . . . . . . 63 3.7 Mode de sécurité : évidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.8 Mode de sécurité : notification . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.9 Schéma du moniteur de référence . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.10 Construction de la trace par le moniteur de référence : ajout de l’horodatage . . . 65 3.11 Construction de la trace par le moniteur de référence : ajout d’information pour l’historique des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.12 Construction de la trace par le moniteur de référence : translation en une interaction 66 3.13 Construction de la trace par le moniteur de référence : schéma global . . . . . . . 67 3.14 Mode d’association : cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.15 Mode d’association : continuation . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.16 Mode de localisation : colocalisé . . . . . . . . . . . . . . . . . . . . . . . . . . 70 9TABLE DES FIGURES 3.17 Mode de localisation : distant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.18 Mode de localisation : distant avec plusieurs nœuds et plusieurs observateurs . . 71 3.19 Mode de localisation : distant avec plusieurs nœuds et un seul observateur . . . . 71 3.20 Mode de redondance : diffusion des requêtes par le nœud . . . . . . . . . . . . . 72 3.21 Mode de redondance : architecture de la forme maître-esclave . . . . . . . . . . 72 3.22 Nommage des ressources au format PBAC . . . . . . . . . . . . . . . . . . . . . 75 3.23 Nommage des ressources au format DTE . . . . . . . . . . . . . . . . . . . . . . 75 3.24 Transition de rôle modifiant les accès possibles à certaines ressources du système 76 3.25 Correspondance entre une ressource et les emplacements physiques . . . . . . . 78 3.26 Correspondance entre une ressource et les emplacements logiques . . . . . . . . 79 3.27 Représentation de la fonction Nabs . . . . . . . . . . . . . . . . . . . . . . . . . 79 3.28 Mécanisme de prise de décision du moniteur de référence . . . . . . . . . . . . . 87 3.29 Fonctionnement régulier d’un appel système présent dans la table des appels système 88 3.30 Mécanisme de détournement de la table des appels système . . . . . . . . . . . . 88 3.31 Mécanisme d’inline hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 3.32 Architecture des filter-driver en prétraitement . . . . . . . . . . . . . . . . . . . 89 3.33 Place de l’observateur en prétraitement . . . . . . . . . . . . . . . . . . . . . . . 90 3.34 Architecture des filter-driver en post-traitement . . . . . . . . . . . . . . . . . . 90 3.35 Empilement de driver modifiant la table des appels système . . . . . . . . . . . . 93 3.36 Schéma détaillant la situation de concurrence sur la table des appels système . . . 93 4.1 Prise du temps de référence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.2 Prise du temps avec ajout du premier observateur . . . . . . . . . . . . . . . . . 99 4.3 Diagramme de séquence illustrant les temps mesurés lors l’ajout d’un seul observateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.4 Prise du temps global avec deux observateurs en mode colocalisé . . . . . . . . . 100 4.5 Diagramme de séquence illustrant les temps mesurés lors l’ajout de deux observateurs en mode colocalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.6 Prise du temps global avec un observateur en mode distant . . . . . . . . . . . . 101 4.7 Diagramme de séquence illustrant le temps global distant lors du déport du second observateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.8 Prise du temps avec une communication et un observateur en mode distant . . . . 103 4.9 Diagramme de séquence illustrant les temps mesurés lors d’une communication complète avec le second observateur en mode distant . . . . . . . . . . . . . . . 104 4.10 Prise du temps pour l’observateur 2 en mode distant . . . . . . . . . . . . . . . . 104 4.11 Diagramme de séquence illustrant les temps mesurés lors de la prise de décision du second observateur en mode distant . . . . . . . . . . . . . . . . . . . . . . . 105 4.12 Architecture décentralisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4.13 Architecture de prise de décision de SELinux . . . . . . . . . . . . . . . . . . . 109 4.14 Insertion de PIGA dans l’architecture en mode colocalisé . . . . . . . . . . . . . 110 4.15 Schéma d’une communication RDMA sur un lien InfiniBand . . . . . . . . . . . 111 4.16 Architecture de protection sur un nœud client . . . . . . . . . . . . . . . . . . . 112 4.17 Architecture détaillée du contrôle d’accès sur un nœud client . . . . . . . . . . . 113 4.18 Architecture sur le serveur de sécurité . . . . . . . . . . . . . . . . . . . . . . . 113 4.19 Diagramme de séquence illustrant la mesure faite au niveau du proxy coté nœud de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.20 Diagramme de séquence illustrant la mesure faite au niveau du proxy serveur pour calculer le temps de prise de décision de PIGA . . . . . . . . . . . . . . . . . . 120 10TABLE DES FIGURES 4.21 Diagramme de séquence résumant les différentes mesures effectuées au sein de l’architecture distribuée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.1 Schéma décrivant l’apprentissage d’une politique . . . . . . . . . . . . . . . . . 136 5.2 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 5.3 Flux d’exécution classique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 5.4 Flux d’exécution détourné par la modification de la SSDT . . . . . . . . . . . . . 142 5.5 Architecture de détournement basée sur l’utilisation de filter-driver et de kernel callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 5.6 Statistiques sur la politique de contrôle d’accès pour le premier scénario . . . . . 145 5.7 Schéma du flux indirect conduisant à la violation de la propriété de confidentialité 147 5.8 Instrumentation du système pour l’analyse de logiciel malveillant . . . . . . . . . 150 5.9 Logiciel malveillant écrivant des fichiers dans la corbeille de Windows . . . . . . 154 5.10 Flash player écrit dans la Corbeille de Windows . . . . . . . . . . . . . . . 155 5.11 services.exe chargeant les fichiers écrits par les logiciels malveillants. . . . 155 5.12 Automate complet des interactions réalisées par le logiciel malveillant . . . . . . 156 5.13 Diagramme d’activité sur l’installation de l’infection . . . . . . . . . . . . . . . 157 11TABLE DES FIGURES 12Liste des symboles ACL Access Control List : Ensemble des droits d’accès sur une ressource du système, page 30 BLP Bell-LaPadula : Modèle de protection basée sur la confidentialité des données, page 32 DAC Discretionary Access Control : Modèle de contrôle d’accès utilisé par la plupart des systèmes d’exploitation laissant la gestion des droits à la discrétion de l’utilisateur, page 29 DTE Domain and Type Enforcement : Modèle de protection de haut niveau utilisant les notions de domaine et de type pour abstraire les ressources, page 36 IRP I/O Request Packets : Structure en partie opaque du noyau Windows permettant la communication entre les driver , page 89 LSM Linux Security Modules : Interface au sein des appels système sous Linux autorisant le contrôle des actions, page 39 MAC Mandatory Access Control : Contrôle d’accès obligatoire imposant une politique de contrôle d’accès aux utilisateurs du système, page 32 MIC Mandatory Integrity Control : Contrôle d’accès obligatoire basé sur les niveaux d’intégrité, page 46 PBAC Path-Based Access Control : Modèle de protection basé sur les chemins complets des ressources, page 41 RBAC Role-Based Access Control : Modèle de protection reposant sur les rôles des utilisateurs pour donner les autorisations d’accession aux ressources, page 35 SSDT System Service Dispatch Table : Table des appels système sur les systèmes Windows, page 140 NTFS New Technology File System : Système de fichiers propriétaire utilisé sur les systèmes d’exploitation Windows, page 131 13TABLE DES FIGURES 14Chapitre 1 Introduction 1.1 Contexte de l’étude L’actualité montre que les systèmes d’information et plus spécifiquement les systèmes d’exploitation sont la source de vulnérabilités. Le premier système d’exploitation visé est Windows, système le plus utilisé dans le monde pour les ordinateurs personnels et professionnels 1 . Ses principales faiblesses résident dans les applications installées sur le système, qu’elles soient fournies par l’éditeur du système d’exploitation ou par des éditeurs tiers. Ceci est confirmé par les rapports annuels des éditeurs de logiciels antivirus 2 . Nous pouvons ainsi citer des attaques ciblant les logiciels Adobe Reader 3 ou Adobe Flash Player 4 , particulièrement visés par les failles récentes. Ces logiciels sont utilisés par les attaquants pour entrer sur le système d’exploitation afin d’en modifier le comportement, de voler de l’information ou de contribuer à des attaques à grande échelle (botnet, déni de service, etc.). Les systèmes basés sur Linux font aussi l’objet d’attaques. Ces systèmes sont maintenant largement répandus dans le monde des téléphones mobiles, et de plus en plus présents sur les ordinateurs des professionnels et des particuliers, ce qui en fait une nouvelle cible pour les attaquants. De plus, avec le développement des nouvelles technologies comme l’informatique en nuage (cloud computing) ou les grilles de calcul, les menaces se font aussi présentes sur les systèmes distribués. Auparavant, les attaques visaient essentiellement les serveurs pour y récupérer l’information qu’ils hébergeaient. Maintenant, les systèmes répartis offrent des moyens d’attaque supplémentaires et génèrent, par conséquent, des nouvelles problématiques de sécurité. La protection des systèmes est devenue un enjeu majeur pour les sociétés actuelles, non seulement pour protéger l’intégrité et la confidentialité des données qu’elles possèdent, mais aussi, et c’est de plus en plus le cas, des données ou des services qu’elles hébergent pour le compte de tiers. De plus, la fourniture de ses services est généralement contractuelle, leurs dysfonctionnement entraîne donc des conséquences financières. Les sociétés proposant ce type de service se doivent donc de proposer des moyens de sécurisation efficaces pour protéger les données de leurs clients. Cette sécurisation du système et des données hébergées passe par la mise en place d’un mécanisme de confiance capable de contrôler les interactions se déroulant au sein même du système. De plus, la confidentialité et l’intégrité des données peuvent être assurées par l’utilisation de moyens cryptographiques forts, que ce soit pour leur stockage ou pour leur transmission sur les réseaux. 1. Statistiques de l’entreprise NetMarketShare : http://www.netmarketshare.com/operatingsystem-market-share.aspx 2. Rapports 2014 de Symantec (http://www.symantec.com/fr/fr/security_response/ publications/threatreport.jsp) et Sophos (http://www.sophos.com/en-us/threatcenter/security-threat-report.aspx) 3. CVE-2014-0502 :http://www.cvedetails.com/cve/CVE-2014-0502/ 4. CVE-2014-0497 : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0497 151.2. OBSERVATEUR Les systèmes d’exploitation courants sont vulnérables à deux grands vecteurs d’attaque. Le premier vecteur est l’utilisateur. Que ce soit de manière intentionnelle ou non, il peut faire sortir ou modifier de l’information. Par conséquent, il faut contrôler de manière précise ses accès. Dans un contexte de défense, cette vérification passe par la validation du niveau d’habilitation de l’utilisateur, lorsque celui-ci souhaite accéder à une ressource classifiée. La gestion fine des accès aux ressources du système donne l’assurance qu’un utilisateur ne peut accéder qu’aux ressources qui lui sont destinées. Le second vecteur est l’utilisation de logiciels tiers possédant des failles de sécurité. Les véri- fications par l’analyse du code source de l’application ou par le reverse code engineering sont en pratique complexes. En plus des logiciels tiers, le système lui-même possède des failles (applicatives ainsi que noyau) qui sont corrigées régulièrement par les développeurs de ces systèmes. Les systèmes d’exploitation classiques ne sont pas capables de se protéger contre ces deux grands axes d’attaque. Il faut donc proposer d’autres approches. La première méthode concerne les mécanismes cryptographiques capables de chiffrer les données ainsi que d’en vérifier leur intégrité. La seconde méthode concerne les mécanismes de contrôle d’accès, qui vont garantir que les opérations faites par les processus sur le système ne compromettent pas l’intégrité ou la confidentialité. Nous pouvons ainsi citer les antivirus, les antimalwares, les mécanismes de contrôle d’accès obligatoire, etc. Notre étude va se concentrer sur l’analyse des mécanismes de contrôle d’accès limitant les privilèges des processus, puisque, comme nous le montrerons au cours de cette thèse, c’est ce point qui est la principale source de compromission. En effet, il manque des solutions efficaces, performantes et extensibles capables de limiter et de contrôler les privilèges des processus. Quel que soit le mécanisme de contrôle d’accès étudié (antivirus, antimalware, etc.), ils possèdent tous une architecture commune composée de deux éléments : le premier élément est un observateur et le second est une politique de sécurité. Nous nous attacherons à définir ces deux éléments au cours de notre étude. 1.2 Observateur Le contrôle des accès au sein même du système passe par la mise en place d’un observateur. Un observateur est un mécanisme système détournant le flux d’exécution et réalisant des traitements spécifiques vis-à-vis d’une politique de sécurité. Classiquement, ces traitements peuvent être : auditer, interdire, autoriser, vérifier l’intégrité, etc. L’observateur se place généralement en espace privilégié (noyau) afin de contrôler la totalité du système et offrir une confiance dans les décisions qu’il prend. Le schéma 1.1 illustre le placement de l’observateur au sein du système. Un observateur, contrôlant les interactions faites par les processus sur le système, doit commencer par détourner le flux d’exécution régulier des processus afin de l’étudier. Ce détournement doit être sûr car la protection ne doit pas pouvoir être supprimée par un utilisateur. De plus, il est important que ce détournement n’introduise pas un surcoût prohibitif qui dégraderait les performances du système. On peut notamment prendre pour exemple les antivirus qui consomment une grande partie du temps processeur lors de leur analyse. Dans le cadre d’un observateur contrôlant les accès au sein du système, il doit a minima analyser les interactions directes. Une interaction directe est une représentation de l’activité observée sous la forme d’un triplet (sujet, operation_elementaire, objet), qui se représente aussi de la manière suivante : sujet −−−−−−−−−−−−−−→ operation_elementaire objet 161.3. EXEMPLES D’ATTAQUES VISANT LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS Espace utilisateur Espace noyau Observateur Processus Fichier Ecriture Politique de sécurité noyau FIGURE 1.1 – Schéma présentant la place de l’observateur avec une politique de sécurité vis-à-vis d’une interaction faite par un processus Lorsqu’une interaction directe est interceptée, l’observateur recherche le triplet correspondant à une règle dans la politique afin d’exécuter le traitement spécifique associé (autoriser, interdire, auditer, etc.). Sinon il effectue un traitement par défaut, comme lever une alerte. Voyons dans ce qui suit les limites du contrôle des interactions directes. 1.3 Exemples d’attaques visant les systèmes d’exploitation Linux et Windows À partir de deux exemples concrets pris pour les systèmes d’exploitation Linux et Windows, nous allons illustrer le comportement des attaques pour en déduire les manques dans notre étude. 1.3.1 Exemple d’attaque pour les systèmes Linux Les systèmes d’exploitation Linux sont aussi exposés aux attaques. On retrouve des attaques exploitant des failles dans des logiciels tiers comme sur les systèmes Windows, mais aussi des attaques réalisées volontairement ou involontairement par les utilisateurs dans le but d’obtenir des privilèges supplémentaires. Dans les deux cas, le but est d’obtenir un accès administrateur (root) sur le système pour réaliser des tâches privilégiées. Il existe des moyens de protection efficaces sur les systèmes Linux. Ces mécanismes permettent de contrôler les interactions directes faites entre les processus et les ressources du système. Cependant, ils ne sont pas capables de contrer les attaques avancées correspondant à l’enchaînement de plusieurs interactions directes, qui prises individuellement peuvent être légitimes, mais qui constituent un scénario complet d’attaque. Nous allons détailler un scénario d’attaque correspondant à l’exploitation d’une faille noyau sur l’appel système perf_event_open 5 . Cette vulnérabilité permet d’obtenir un shell avec 5. CVE-2013-2094 :https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2094 171.3. EXEMPLES D’ATTAQUES VISANT LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS un accès root. La figure 1.2 illustre un exemple de 9 étapes constituant un ensemble d’interactions directes définissant le scénario complet d’attaque permettant d’obtenir un terminal avec les droits administrateur (un shell root). FIGURE 1.2 – Schéma résumant les étapes de l’attaque pour l’exploitation d’une faille noyau sous Linux Cette attaque se déroule en plusieurs étapes. Nous avons tout d’abord une connexion de la part de l’utilisateur, par exemple via ssh (0), l’utilisation d’un navigateur web tel que Firefox (1), le téléchargement du logiciel malveillant (2-4) et son exécution (5-8). Comme l’illustre la figure 1.2, le scénario complet d’attaque comporte 9 étapes composées d’interactions "système" (création de fichier, exécution de programme), mais aussi d’interactions "réseau" (connexion Internet, téléchargement, etc). Ce scénario met donc en jeu plusieurs types d’interactions directes qui prises indépendamment ne constituent pas un risque. Cette attaque illustre l’exploitation d’une faille du noyau Linux. 1.3.2 Exemple d’attaque pour les systèmes Windows Les logiciels malveillants (malware) ciblant les systèmes d’exploitation Windows sont de plus en plus complexes. Ils utilisent des techniques assez évoluées pour se dissimuler au sein même du système. Il est donc nécessaire de mettre en place des mécanismes de protection avancés contrôlant les processus. Les attaques actuelles contre les systèmes Windows passent souvent par les navigateurs web et les plugins installés. Les plugins sont des modules additionnels pour les navigateurs qui apportent des fonctionnalités supplémentaires, comme lire des fichiers pdf ou exécuter du code en flash. La figure 1.3 montre le cheminement d’une attaque d’un rootkit nommé ZeroAccess [McAfee, 2013]. 181.3. EXEMPLES D’ATTAQUES VISANT LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS FIGURE 1.3 – Schéma résumant les étapes de l’installation d’un rootkit nommé ZeroAccess Afin de compromettre le système, le malware va effectuer une suite d’interactions directes. Par l’exploitation d’une faille dans un navigateur ou dans un plugin du navigateur, le navigateur va télécharger le malware sur le système (1,2). Le payload, c’est-à-dire la charge active installant le rootkit s’exécute (3) via un installateur modifié de FlashPlayer (4-10). Le rootkit exploite une faille dans un service système pour finaliser son installation (11, 12). Ce scénario complet est ainsi constitué de 12 interactions directes. 1.3.3 Analyse des deux attaques Ces deux scénarios complets d’attaque sont proches dans leur construction. Ils sont tous les deux basés sur l’enchaînement de plusieurs interactions directes, c’est-à-dire une succession d’interactions réalisées les unes à la suite des autres de manière logique, menant à la compromission du système. Pour contrer ce type d’attaque, il est nécessaire d’avoir un observateur capable d’intercepter et de contrôler les interactions directes. Ainsi, l’analyse de ces interactions directes permet de reconstruire le scénario complet sous la forme d’une liste de n interactions directes (figure 1.4). Par exemple, pour l’attaque concernant le système Windows (figure 1.3), l’interaction numé- rotée 3 peut se voir sous la forme : Sujet3 : Firefox −−−−−−−−−−−−−−−−−→ operation_elementaire:open Object3 : malware.exe 191.4. OBJECTIF DE LA THÈSE FIGURE 1.4 – Représentation sous la forme de liste des interactions directes Pour prévenir ce genre d’attaque, on pourrait supprimer (interdire dans la politique de contrôle d’accès) une interaction directe de cette liste. Cependant, certaines interactions sont légitimes comme l’écriture d’un fichier par Firefox. On ne peut donc pas interdire une des interactions sans risquer de nuire au fonctionnement du système. Par conséquent, plutôt que d’interdire une des n − 1 interactions intermédiaires, il est nécessaire d’analyser le scénario complet. Pour pouvoir contrôler un scénario complet, il faut avoir un observateur réalisant des calculs spécifiques. L’implantation d’un tel observateur, capable à la fois de gérer les interactions directes et de reconstruire temporellement l’activité des processus est difficile à réaliser. En pratique, il est préférable de pouvoir associer différents observateurs. Citons par exemple le défi [ANR, 2009] dans lequel les développeurs ont mis en place deux associations d’observateurs : une première composée de SELinux (mécanisme de contrôle d’accès obligatoire) et iptables (pare-feu) pour contrôler les interactions directes, et une seconde composée de SELinux et de PIGA (voir la section 2.3.1.4) pour le contrôle des scénarios complets. Afin qu’un observateur, tel que PIGA, puisse analyser le scénario complet, il faut qu’un premier observateur lui communique chaque interaction directe horodatée. Il sera ainsi capable de reconstruire et de contrôler les scénarios complets (figure 1.5). 1.4 Objectif de la thèse Le travail réalisé au cours de cette thèse vise à améliorer la protection proposée par les systèmes d’exploitation grâce à des approches avancées de contrôle d’accès. Les mécanismes de protection, qu’ils soient système ou réseau, passent par la mise en place d’un observateur. Cet observateur doit détourner le flux d’exécution et garantir sa conformité vis- à-vis d’une politique de sécurité. Notre étude concerne les observateurs pour les systèmes d’exploitation, leurs répartitions, leurs efficacités et leurs impacts sur les performances du système. Nous définissons quatre objectifs majeurs pour cette thèse : 1. Définir un modèle d’observateur générique pour les systèmes d’exploitation. — Pour mettre en place ce modèle, il faut définir de manière abstraite la notion d’observateur pour les systèmes d’exploitation. Cette notion d’observateur doit être générale et indépendante du système d’exploitation (Linux ou Windows). — À partir de cette définition, nous proposerons une implantation fonctionnelle pour les systèmes Windows d’un observateur capable de gérer les interactions directes car c’est sur ce système qu’il y a les manques les plus importants. 2. Nous avons montré au cours de cette introduction qu’il était nécessaire de pouvoir associer et répartir les observateurs pour prévenir efficacement les nouvelles menaces. Il nous faut donc proposer un modèle général de répartition d’observateurs. Cependant, dans des mi- 201.5. APPORTS DE LA THÈSE FIGURE 1.5 – Association d’observateurs lieux où la contrainte en termes de performances est grande, il faut pouvoir évaluer l’impact du modèle de répartition. 3. Il nous faut par conséquent, définir un protocole pour analyser les surcoûts engendrés par l’association d’un ou plusieurs observateurs au sein d’un système et proposer des solutions efficaces pour les réduire. 4. Afin de valider l’efficacité en termes de sécurité, nous développerons deux cas d’usage, l’un pour les systèmes à haute performance sur Linux et l’autre par l’étude des malware sur Windows. 1.5 Apports de la thèse Nous indiquons, au travers de l’état de l’art, qu’il y a un manque de formalisation pour la notion d’observateur. La protection du système passe par la possibilité de pouvoir répartir plusieurs types d’observateurs, réalisant chacun des calculs spécifiques. Dans cette optique, nous proposons une définition générique de la notion d’observateur pour les systèmes d’exploitation. Nous présenterons au travers de notre modélisation, que cette définition ne dépend pas du système d’exploitation sous-jacent. Ainsi, dans le but d’illustrer notre propos, nous montrerons que cette définition s’applique aussi bien aux systèmes Linux qu’aux systèmes Windows. Afin d’écrire la politique de sécurité d’un observateur, il est nécessaire d’avoir une grammaire. Nous proposons donc une grammaire générique permettant l’écriture des règles de contrôle d’accès directes pour tout type de système. Nous expliquerons comment cette grammaire supporte deux modèles de protection différents s’appliquant à un large ensemble de systèmes différents. 211.5. APPORTS DE LA THÈSE Cette partie répond à la problématique de définition de politique de sécurité générique pour les systèmes. L’écriture d’une politique de sécurité nécessite d’identifier de manière précise les ressources du système. Nous retrouverons dans la littérature deux méthodes principales de désignation des ressources. La première se base sur le chemin complet de la ressource dans le système de fichiers. Cette méthode, qui a comme principal avantage d’être très usuelle, empêche d’avoir une politique de sécurité parfaitement portable entre les systèmes. La seconde méthode pour désigner les ressources se base sur la définition de types et de domaines. Cette méthode a le principal avantage d’être beaucoup plus portable. Cependant, il est nécessaire d’assurer une correspondance entre les ressources et la définition des types. Nous proposons donc une approche de désignation des ressources applicable à Windows et à Linux et qui rend la politique portable. Il existe des implantations d’association de plusieurs observateurs : SELinux et PIGA, SELinux et iptables, etc. Néanmoins, il n’existe aucun modèle clair de répartition d’observateurs. Nous définissons donc un modèle exploitable de répartition d’observateurs. Ce modèle permet de définir l’association entre observateurs, mais décrit aussi un modèle pour spécifier la localisation ainsi que le mode de redondance de chaque observateur. L’intégration et la répartition des observateurs ne doivent pas nuire aux performances du système observé. Mais pour connaître l’impact de l’ajout d’un mécanisme de sécurité sur le système, il faut pouvoir le mesurer. Nous proposons donc une solution pour mesurer l’impact sur les performances de l’ajout et de la répartition d’observateurs. Nous expliquerons comment nous sommes capables d’identifier avec précision les éléments qui nuisent aux performances du système. Nous décrivons donc un modèle pour mesurer le surcoût engendré par la mise en place d’un ou plusieurs observateurs. Ce modèle est détaillé pour des observateurs colocalisés et distants. Nous proposons l’implantation d’une association de deux observateurs au sein d’un environnement HPC. Afin de réduire les temps de communication entre observateurs, nous déportons le second moniteur en utilisant les technologies spécifiques présentes dans les environnements HPC. Nous illustrons cette partie avec deux observateurs : SELinux pour le contrôle des interactions directes et PIGA pour le contrôle des scénarios complets. Nous montrons ainsi que le déport du second observateur permet de générer moins de latence par rapport à une architecture colocalisée. Enfin, à partir de la définition générique d’observateur ainsi que de la formalisation de la création d’une politique de sécurité, nous proposons une implantation d’un mécanisme de contrôle d’accès obligatoire pour les systèmes Windows. Nous décrivons l’implantation des deux modèles de politiques de sécurité supportées par notre langage et nous détaillerons les outils que nous avons mis en place pour faciliter l’administration des politiques. Nous détaillerons les mécanismes permettant de détourner de manière efficace les interactions directes sur les systèmes Windows. Nous montrerons que ce mécanisme est capable de contrer les attaques simples, c’est-à-dire en contrô- lant les interactions directes, et que, associé avec un second observateur, nous sommes capables de contrôler les scénarios complets. De plus, nous expliquerons qu’il est possible de modifier cet observateur dans le but d’analyser des logiciels malveillants pour en extraire des comportements spécifiques. Cette partie répond à la problématique de manque de mécanisme de contrôle d’accès obligatoire pour les systèmes Windows. Le tableau 1.1 récapitule les apports de cette thèse. — couleur verte : les solutions existantes ; — couleur rouge : les éléments actuellement non satisfaisants que nous développerons dans ce mémoire de thèse ; 221.6. PLAN DU MÉMOIRE Linux Windows Concept d’observateur - Définition commune Manque une définition générique Implantation d’observateurs - Interactions directes SELinux, grsecurity SEWindows AppArmor, Tomoyo, SMACK Répartition des observateurs - Modèle Modèle abstrait de répartition - Implantation HPC Solution pour les systèmes répartis Impact sur les performances - Analyse des performances Solutions pour analyser les performances des observateurs - Réduction du surcoût Solutions pour réduire le surcoût des observateurs TABLE 1.1 – Tableau présentant les apports de la thèse 1.6 Plan du mémoire Le chapitre 2 fait l’état de l’art des propriétés de sécurité et des principaux modèles de contrôle d’accès. Ensuite, nous traitons des implantations de contrôle d’accès obligatoire existantes sur les systèmes Linux et Windows, en nous focalisant sur les implantations de référence pour chaque système. Cette section se conclut par une synthèse listant les propriétés de sécurité que sont capables de garantir les mécanismes que nous présentons. Enfin, nous nous intéressons à l’impact des mécanismes de contrôle d’accès sur les performances du système. Ce chapitre se conclut en exprimant tout d’abord, les manques des implantations de contrôle d’accès obligatoire existants sur les systèmes Windows et ensuite, en exprimant le manque de formalisme quant à la répartition de plusieurs observateurs au sein des systèmes. Le chapitre 3 propose une formalisation de la notion d’observateur. Cette formalisation s’appuie sur la modélisation d’un observateur système et sur la définition d’une politique de contrôle d’accès directe. En formalisant la notion d’observateur, nous pourrons spécifier un certain type d’observateur nommé moniteur de référence. De plus, nous nous attacherons à détailler des mécanismes de détournement d’interactions directes pour les systèmes Windows. Nous proposons un modèle de répartitions des observateurs prenant en compte les modes d’association, de localisation et de redondance. La définition d’une politique de contrôle d’accès directe passe par la réalisation d’une grammaire générique spécifiant les traitements de l’observateur lors du détournement d’une interaction. Cependant, la création de règles d’accès passe par une méthode précise pour identi- fier de manière unique les ressources du système. Pour cela, nous proposerons l’utilisation des noms symboliques absolus indépendants de la localisation. Cette grammaire générique est ensuite appliquée à deux modèles de contrôle d’accès directs, PBAC (path based access control) et DTE (domain and type enforcement). Dans le chapitre 4, nous proposons une approche permettant d’analyser le surcoût dû à l’association d’observateur au sein d’un système. Pour cela, nous définissons des points de mesure ainsi qu’une modélisation permettant de connaître le temps pris par chaque élément de l’association. Puis nous implantons une répartition d’observateurs dans un environnement HPC. Nous pré- senterons une répartition colocalisée et distante pour l’association de SELinux avec PIGA. Nous détaillerons notre architecture permettant de déporter le second observateur, tout en utilisant les technologies spécifiques du HPC pour réduire l’impact d’une telle association sur les performances du système. Enfin, nous appliquerons notre méthode pour mesurer le surcoût de la répartition des observateurs à notre approche HPC. Nous discuterons ainsi la faisabilité d’une répartition d’obser- 231.6. PLAN DU MÉMOIRE vateurs dans les environnements à haute performance sur la base de notre méthode d’évaluation des performances. Dans le chapitre 5, nous proposons une implantation d’un mécanisme de contrôle d’accès obligatoire pour les systèmes Windows nommé SEWINDOWS basée sur les deux modèles de protection considérés au chapitre 3. Dans une première section, nous définirons deux politiques de contrôle d’accès directes, basées sur les deux modèles de protection que nous avons définis dans le chapitre 3. Nous expliquerons les choix techniques que nous avons dûs faire et notre approche pour implanter une désignation adaptée des ressources. Puis nous détaillerons les deux mécanismes de détournement des flux que nous avons implantés, le premier détournant les appels système en modifiant une table système et le second par l’intégration d’un filter-driver. Enfin, nous détaillerons les expérimentations que nous avons faites sur les systèmes Windows. Les premiers tests nous ont permis de valider notre mécanisme de contrôle d’accès en bloquant des attaques. Nous montrons par la suite, qu’en l’associant avec PIGA, nous pouvons gérer des scénarios complets. Puis, nous utilisons notre mécanisme de contrôle d’accès dans le but de pouvoir étudier les logiciels malveillants. Pour cela, nous expliquerons l’architecture et les outils permettant d’exploiter les résultats obtenus. Enfin le chapitre 6 résume les apports de cette thèse ainsi que les perspectives possibles autour des travaux que nous avons présentés tout au long de ce mémoire. 24Chapitre 2 État de l’art Les problématiques de contrôle d’accès sont présentes sur tous les systèmes d’information. Cette thèse s’intéresse plus spécifiquement aux problématiques de confidentialité et d’intégrité qui font partie intégrante des critères d’évaluation de la sécurité, que ce soit au niveau international [TCSEC, 1985] qu’au niveau européen [ITSEC, 1991]. Ce chapitre présente les travaux de référence en lien avec cette thèse, c’est-à-dire les travaux portant sur les problématiques de contrôle d’accès dans des systèmes hétérogènes. Ce chapitre s’organise de la manière suivante. Une première partie propose une définition gé- nérale des propriétés de sécurité que nous souhaitons garantir au sein d’un système d’information. Cette partie détaille les fondements de la sécurité informatique concernant le contrôle d’accès. La seconde partie s’attache à décrire les différents modèles de contrôle d’accès. Ces modèles ont été définis pour répondre aux problématiques mises en jeu par la définition des propriétés de sécurité. La troisième partie traite de la mise en œuvre de ces modèles de contrôle d’accès. Nous avons séparé cette partie en deux : une première section traite des mécanismes présents sur les systèmes d’exploitation Linux tandis que la seconde s’attache aux systèmes Windows. Enfin, une section traitera de l’impact sur les performances de tels mécanismes. Au sein de la discussion, nous ré- sumerons les faiblesses constatées et nous décrirons le contexte dans lequel nos travaux prennent place. 2.1 Propriétés de sécurité Les besoins en sécurité s’expriment grâce à des propriétés de sécurité au sein d’une politique. La littérature définit trois grands types de propriétés de référence. Ces propositions sont dépendantes du contexte, des besoins ou encore des utilisateurs. Nous donnons ici une synthèse des défi- nitions exprimées dans les documents de références [TCSEC, 1985, ITSEC, 1991, Bishop, 2003]. Nous avons divisé l’expression des propriétés de sécurité en deux parties : la première partie donne des définitions des trois grands types de propriétés de sécurité, dites générales, alors que la seconde partie exprime les propriétés dérivées de celles-ci. 2.1.1 Propriétés générales Les trois propriétés de sécurité que nous décrivons dans cette partie sont à la base de la définition des objectifs de sécurité. Ces objectifs de sécurité expriment les besoins des entreprises et des systèmes en termes de sécurité. 252.1. PROPRIÉTÉS DE SÉCURITÉ 2.1.1.1 Confidentialité La propriété de confidentialité exprime le besoin de prévention des accès non autorisés à l’information. Elle prévient la divulgation de l’information non autorisée comme le défi- nit [Bishop, 2003]. Elle peut être exprimée de la manière suivante : Définition 2.1.1 Confidentialité La confidentialité est la prévention des accès non autorisés à une information. La propriété de confidentialité implique que seules les entités autorisées peuvent accéder à l’information. Cette propriété est le plus souvent appliquée dans les milieux de défense assujettis à la classification de l’information. Cette information ne doit être accessible qu’aux personnes disposant de l’habilitation nécessaire. 2.1.1.2 Intégrité La propriété d’intégrité exprime la prévention de toute modification non autorisée d’une information. Aucun traitement non autorisé ne doit modifier les données que ce soit lors de leur stockage ou lors de leur transmission. Cette propriété implique aussi que les données ne doivent être modifiées ni de manière volontaire ni de manière accidentelle. Définition 2.1.2 Intégrité L’intégrité est la prévention des modifications non autorisées d’une information. Tout comme la propriété de confidentialité, la propriété d’intégrité implique que seules les entités autorisées du système ont le droit de modifier l’information. 2.1.1.3 Disponibilité La propriété de disponibilité repose sur la possibilité d’accès à une donnée ou à un service à tout instant. Cette notion est à rapprocher de la fiabilité d’un système puisque si un service n’est pas accessible, il est considéré comme défaillant. En matière de sécurité informatique, cette défaillance peut se traduire par l’épuisement d’une ressource partagée entre plusieurs entités du système. Définition 2.1.3 Disponibilité La disponibilité est la prévention de la rétention d’information ou d’un service. Le contexte d’application peut faire varier le sens de cette définition. En effet, les systèmes critiques ont des besoins très forts en termes de disponibilité alors qu’un site internet aura des besoins moindres. Cette propriété de sécurité se rapprochant plus de la sûreté de fonctionnement que de la sécurité, elle sort du cadre de notre étude. 2.1.2 Propriétés dérivées Les propriétés générales de sécurité sont extrêmement difficiles à mettre en place. En effet, en pratique, un système est parfaitement intègre et respecte la propriété de confidentialité s’il ne rend aucun service. C’est pour cette raison qu’à partir des propriétés de confidentialité, d’intégrité et de disponibilité, il est possible de dériver de nouvelles propriétés de sécurité plus spécifiques qui sont applicables sur les systèmes actuels. Ces propriétés dérivées sont des cas particuliers des 3 types précédents. 262.1. PROPRIÉTÉS DE SÉCURITÉ 2.1.2.1 Confinement de processus La problématique du confinement des processus a été écrite par Lampson [Lampson, 1973]. Définition 2.1.4 Confinement de processus Le problème du confinement concerne la prévention de la divulgation, par un service (ou un processus), d’informations considérées comme confidentielles par les utilisateurs de ce service. Dans la résolution de cette problématique, Lampson énonce les caractéristiques nécessaires à un processus pour qu’il ne puisse pas divulguer d’information. Une des caractéristiques principales est qu’un processus observable ne doit pas stocker d’informations. Si un processus stocke de l’information jugée confidentielle et qu’un utilisateur peut observer ce processus, alors il existe un risque d’échange d’information entre le processus observé et l’observateur. Cette propriété est impérativement transitive par nature. Si un processus lance un nouveau processus, et qu’il n’est pas possible d’avoir confiance en ce dernier, alors il est nécessaire que ce nouveau processus soit confiné lui aussi. Le modèle de Lampson décrit dans la pratique la propriété d’isolation totale, c’est-à-dire qu’un processus ne peut pas échanger d’information par quelque moyen que ce soit avec d’autres processus. Cette propriété est pratiquement inapplicable dans les systèmes d’exploitation classiques, puisque les processus partagent des ressources comme le processeur, le matériel, etc. Il existe, de plus, des moyens de communication entre processus appelés les canaux cachés. Définition 2.1.5 Canaux cachés Les canaux cachés sont des moyens de communication entre deux entités actives du système. Ce moyen de communication n’est pas un moyen légitime de communication dans la conception du système. Prenons comme un exemple deux processus p1 et p2 qui ne peuvent pas communiquer entre eux. Le processus p1 souhaite envoyer de l’information au processus p2, pour cela, il va trouver une ressource que les deux peuvent partager, comme un élément du système de fichiers. Il va ainsi pouvoir jouer soit sur le nom du fichier pour transmettre une information, soit sur le contenu du fichier. Par exemple, en créant des fichiers nommés 0, 1 et end, il va pouvoir transmettre, sous la forme d’un code défini entre les deux processus, un message chiffré à destination du second processus. 2.1.2.2 Moindre privilège Le principe de moindre privilège a été défini par [Saltzer et Schroeder, 1975]. Il établit qu’une entité active du système ne devrait s’exécuter sur le système qu’avec les privilèges nécessaires à la réalisation de sa tâche. Ce principe s’applique aussi bien aux processus qu’aux utilisateurs du système. Définition 2.1.6 Moindre privilège Le principe de moindre privilège est la réduction des droits accordés à une entité active du système. Ce nouvel ensemble de droits doit être suffisant pour que l’entité puisse réaliser sa tâche. Cette propriété permet de réduire le nombre d’interactions entre les processus privilégiés et ainsi réduire les comportements potentiellement non désirés sur le système. 272.1. PROPRIÉTÉS DE SÉCURITÉ 2.1.2.3 Séparation des privilèges Le principe de la séparation des privilèges établit que des actions privilégiées (modification de la configuration, mises à jour, etc.) doivent être réalisées par des utilisateurs ou processus diffé- rents. Une première définition a été donnée par [Clark et Wilson, 1987]. Ils proposent d’assurer la cohérence des objets du système en faisant une représentation fidèle des objets du système vis-à- vis de la réalité. Or, il n’est cependant pas possible que cette cohérence soit assurée par un système informatique car les systèmes d’information n’ont pas des senseurs leur permettant d’analyser l’environnement extérieur. Ils proposent donc de séparer les opérations en différentes sous-parties et que chaque partie soit exécutée par des utilisateurs différents, en prenant l’exemple d’un processus d’achat, qui est divisé en plusieurs parties réalisées par des personnes différentes : la personne qui fait la demande, celle qui fait la commande, celle qui paye, etc. Il est possible d’assurer la cohérence des objets avec la réalité. Définition 2.1.7 Séparation des privilèges La séparation des privilèges implique que les privilèges soient distribués sur l’ensemble des utilisateurs. Dans un système d’exploitation, ce principe est généralement appliqué au niveau des processus système. Les processus privilégiés qui créent des fichiers n’ont généralement pas le droit de les exécuter par la suite. On peut aussi étendre cette définition en l’appliquant directement aux utilisateurs. 2.1.2.4 Non-interférence Le principe de non-interférence [Focardi et Gorrieri, 2001] implique que plusieurs processus puissent s’exécuter simultanément sans interférer, c’est-à-dire sans modifier la vision des données ou le comportement des autres processus. Définition 2.1.8 Non-interférence La non-interférence est la possibilité pour une entité de s’exé- cuter sur un système sans être influencée par une autre entité du système. Cette propriété se caractérise par le fait que pour deux ensembles d’objets donnés, les données du premier ensemble ne sont pas affectées par les actions faites sur le second ensemble. 2.1.3 Discussion Les propriétés générales de sécurité permettent d’exprimer de manière informelle des objectifs de sécurité précis. Dans le cas d’un système d’exploitation, ces propriétés sont, suivant les situations, soient trop expressives et conduisent à un blocage du système, soient pas assez. Il a donc été nécessaire de définir des propriétés de sécurité adressant des objectifs de sécurité plus spécifiques. Ce sont ces raisons qui ont conduits les auteurs à définir des raffinements aux propriétés générales. Elles sont plus précises et permettent de gérer des cas visant à compromettre la confidentialité ou l’intégrité, voir des deux. Nous illustrons, dans la figure 2.1, comment se positionnent les propriétés dérivées vis-à-vis des propriétés générales. On peut ainsi noter que la propriété de non-interférence couvre à la fois la disponibilité, l’intégrité et la confidentialité. La propriété de moindre privilège couvre, quant à elle, les propriétés d’intégrité et de confidentialité. Ces propriétés de sécurité, qu’elles soient générales ou dérivées, sont difficilement applicables à l’ensemble d’un système d’information. En effet, il est difficile d’assurer par exemple, l’isolation total d’un processus au sein d’un système sans en bloquer le fonctionnement. C’est pour cela que nous allons maintenant voir les modèles de protections qui permettant en pratique de garantir la confidentialité ou l’intégrité en spécialisant le contrôle pour certains éléments (processus, ressources) du système. 282.2. MODÈLES DE CONTRÔLE D’ACCÈS FIGURE 2.1 – Couverture des propriétés dérivées vis-à-vis des propriétés générales de sécurité 2.2 Modèles de contrôle d’accès La mise en œuvre des propriétés de sécurité que nous venons de définir peut se faire soit en utilisant des mécanismes cryptographiques soit en utilisant des mécanismes de contrôle d’accès. Nous nous intéressons ici exclusivement aux mécanismes de contrôle d’accès des systèmes. Les systèmes d’exploitation se basent sur divers éléments : — un ensemble de sujets : ce sont les entités actives sur le système, essentiellement les processus ; — un ensemble d’objets : ce sont les entités passives du système. Ces entités subissent les interactions effectuées par les sujets. Cet ensemble regroupe toutes les ressources du système (fichiers, socket, etc.). — un ensemble de permissions : ce sont les interactions autorisées des sujets sur les objets (lecture, écriture, etc.) ou entre sujets (envoi d’un signal). Le contrôle d’accès est l’ensemble des règles qui associent à un sujet un ensemble de permissions sur un objet. Des règles d’accès peuvent aussi exister entre deux sujets. La manière la plus naturelle de représenter les règles d’accès est d’utiliser une matrice d’accès, comme le montre la table 2.1. Dans cette matrice, les lignes contiennent les sujets, les colonnes correspondent aux objets et l’intersection des deux contient l’ensemble des permissions du sujet sur l’objet. Objets F ichier1 F ichier2 Repertoire1 Sujet3 Sujet1 Lecture, écriture Lecture Lecture, exécution Signaux Sujet2 Lecture Lecture, écriture, exécution Sujet3 Exécution Ecriture TABLE 2.1 – Représentation règles d’accès sous la forme d’une matrice d’accès 2.2.1 Le contrôle d’accès discrétionnaire Le contrôle d’accès discrétionnaire DAC est le contrôle d’accès que l’on retrouve sur la majorité des systèmes d’exploitation (Linux, Windows et MacOS). Il laisse à la discrétion de l’utilisateur le soin de gérer les accès sur les fichiers qu’il possède. Dans la pratique, les utilisateurs disposent de commandes système leur permettant de définir les accès sur ces fichiers. 292.2. MODÈLES DE CONTRÔLE D’ACCÈS 2.2.1.1 Lampson Le premier à avoir formalisé ce modèle de contrôle d’accès est Lampson. Il commence par donner deux définitions : la première concerne les capacités et la seconde concerne les listes de contrôle d’accès (Access Control List, ACL ). Ces deux définitions sont décrites dans [Lampson, 1969]. [Lampson, 1971] affine ces définitions grâce à la modélisation de la notion de matrice d’accès. Il propose de placer dans une matrice A, l’ensemble D des domaines de protection qui représentent des contextes d’exécution pour les programmes (les sujets) sur les lignes, et en colonnes l’ensemble X des objets (incluant les domaines). Lampson donne des définitions de chaque terme. Un objet est une "chose" du système qui doit être protégée. Cela peut être, par exemple, les processus, les domaines, les fichiers, etc. Les domaines sont les entités du système qui ont accès aux objets. La propriété essentielle d’un domaine est qu’il a des permissions différentes des autres domaines. De part cette définition, les domaines sont donc aussi des objets. Les capacités (capabilities) sont des privilèges accordés aux domaines. Sous Linux, ces privilèges scindent ceux du super-utilisateur en capacité que l’on peut accorder ou interdire à chaque utilisateur. Définition 2.2.1 Liste des capacités Étant donné un domaine d ∈ D, la liste des capacités pour le domaine d est l’ensemble des couples (o, A[d, o]), ∀o ∈ X. Définition 2.2.2 Liste de Contrôle d’Accès Étant donné un objet o ∈ X, la liste de contrôle d’accès pour l’objet o est l’ensemble des couples (d, A[d, o]), ∀d ∈ D. Lampson ajoute deux nouvelles capacités : le droit propriétaire et le droit de copie symbolisé par *. Dans la table 2.2, le droit propriétaire ajouté au Domaine1 l’autorise à contrôler les droits sur le F ichier1 pour l’ensemble des domaines. D’un point de vue de la matrice, il est capable de modifier les droits sur l’ensemble de la colonne. Le droit de copie *, s’applique sur une permission spécifique, autorisant le domaine qui possède cette capacité à recopier la permission sur toute la colonne correspondante. Objets F ichier1 F ichier2 Repertoire1 P rocess1 Domaine1 Lecture, écriture, propriétaire Lecture Lecture, exécution Signaux Domaine2 Lecture Lecture, écriture, exécution Domaine3 Exécution *Ecriture FIGURE 2.2 – Représentation de Lampson d’une matrice d’accès Ce modèle a ensuite évolué vers le modèle HRU [Harrison et al., 1976]. 2.2.1.2 HRU Dans le modèle HRU [Harrison et al., 1976], les auteurs modélisent le contrôle d’accès discré- tionnaire à partir d’une matrice P, qui représente l’ensemble des droits d’accès des sujets sur les objets. Les sujets peuvent créer des sujets, des objets et modifier les permissions. Les auteurs du modèle HRU proposent de modéliser le contrôle d’accès de la manière suivante : — l’ensemble des sujets S et l’ensemble des objets O ; — l’ensemble des droits génériques R tels que possession, lecture, écriture, exécution ; — une configuration de protection système repose sur le triplet (S, O, P); — une matrice de contrôle d’accès P ; — un ensemble fini C de commandes c1, ... , cn, représente l’ensemble des opérations fournies par le système d’exploitation (création de fichier, modification des droits...) ; 302.2. MODÈLES DE CONTRÔLE D’ACCÈS — un ensemble d’opérations élémentaires E : enter et delete pour l’ajout et la suppression de droits, create subject et create object pour la création de nouveaux sujets et objets et enfin destroy subject et destroy object pour la destruction de sujets et objets. Afin d’étudier le problème de la sûreté d’un système de protection, HRU s’intéresse au transfert de privilège (droit), qui se produit lorsqu’une commande insère un droit particulier r, dans une case de la matrice P où il était précédemment absent. La problématique de sûreté d’un système de protection se définit ainsi : étant donné une configuration initiale de la politique de sécurité, un système est considéré comme sûr pour un droit r si aucune des commandes de ce système ne provoque le transfert du droit r. Les auteurs prouvent que lorsque les commandes ne contiennent qu’une seule action élémentaire, le problème de sûreté est décidable mais l’algorithme de vérification est NP-Complet. Ce modèle mono-opérationnel n’est pas du tout représentatif des systèmes courants. Dans le cas gé- néral, le problème de la protection d’un système est indécidable. Le problème est néanmoins de taille polynomiale si on retire les opérations de création de sujet et d’objet du modèle de protection. Dans le cas d’un système d’exploitation, le problème de la vérification d’un contrôle d’accès discrétionnaire est indécidable. Ce résultat prouve qu’il n’est pas possible de garantir des propriétés de sécurité avec un contrôle d’accès discrétionnaire. 2.2.1.3 TAM Le modèle TAM (Typed Access Matrix) exprimé par [Sandhu, 1992], propose une extension du modèle HRU en intégrant la notion de typage fort. Cette notion provient de travaux plus anciens de SPM (Sandhu’s Schematic Protection Model) [Sandhu, 1988] et se traduit par l’attachement de types de sécurité immuables à tous les sujets et objets du système. Le modèle HRU est enrichi d’un nouvel ensemble T des types de sécurité. Cet ensemble est un ensemble fini, c’est-à-dire qu’il n’est pas possible de créer de nouveaux types. La gestion des types est prise en compte dans les opérations élémentaires décrites pour le modèle HRU. L’auteur s’intéresse ensuite à la version monotone du modèle TAM, MTAM (Monotonic Typed Access Matrix) qui se caractérise par la suppression des opérations de suppression (droits, sujets et objets). À partir du modèle MTAM, il démontre que le problème de sûreté de fonctionnement est décidable car le graphe de création des sujets et des objets est acyclique. Cependant, la complexité du problème reste NP. C’est pourquoi Sandhu définit le modèle MTAM ternaire, dans lequel toutes les commandes ont au maximum trois arguments. Au prix d’une perte d’expressivité, le problème de sûreté voit sa complexité ramenée à un degré polynomial. En pratique, ce modèle théorique est difficilement applicable car il revient à ne jamais modifier la politique de contrôle d’accès. 2.2.1.4 DTAM La modèle DTAM (Dynamic-Typed Access Matrix) est exprimé par [Soshi et al., 2004]. Ils proposent une extension du modèle TAM. Le but de ce modèle est d’autoriser les types des objets à être changé de façon dynamique, à la différence du modèle TAM où ils sont statiques. De plus, ce modèle permet de décrire les systèmes de protection non-monotonique pour lesquels la problématique de sûreté est décidable. Le modèle se base sur le modèle TAM à l’exception que les objets peuvent changer de types de façon dynamique et que l’ensemble des types est un fini. Les auteurs ajoutent donc des commandes supplémentaires aux commandes définies par HRU telles que change type of subject et change type of object. Les auteurs du modèle DTAM démontrent que la sûreté du système de protection est décidable en s’appuyant sur le fait que la commande create génère des changements irréversibles sur les 312.2. MODÈLES DE CONTRÔLE D’ACCÈS types des objets parents. Cela signifie que lorsqu’un domaine crée un objet via la commande create, le domaine change aussi de types. De plus, un objet ne peut avoir un type qu’il a possédé auparavant, donc le nombre de changements de types pour un objet est fini puisque le nombre de types est fini. Par conséquence, le problème de sûreté devient décidable dans ce modèle. Il est à noter que dans ce modèle, il est possible que le système atteigne un état dans lequel il ne puisse plus créer de nouveaux objets lorsque tous les objets du système ont utilisés tous les types possibles. Cela revient à avoir une politique figée où l’on ne peut définir de nouveaux types. Ce modèle théorique est donc aussi difficilement utilisable en pratique. 2.2.2 Le contrôle d’accès obligatoire Le contrôle d’accès discrétionnaire laisse l’utilisateur final décider des permissions sur les objets qu’il possède. Les différents modèles de contrôle d’accès discrétionnaire ne permettent pas d’avoir un système sûr. [Anderson, 1972] détaille le fait qu’il est possible de se protéger des attaques extérieures par l’ajout d’outils, mais qu’il n’est pas possible de se protéger des attaques venant de l’intérieur. Ces attaques peuvent être malicieuses ou accidentelles. Il est donc nécessaire d’imposer une politique de contrôle d’accès aux utilisateurs du système, en utilisant un modèle de contrôle d’accès obligatoire (MAC, Mandatory Access Control). Cette politique ne doit pas pouvoir être modifiée par les utilisateurs finaux. [Anderson, 1980] propose l’utilisation d’un Moniteur de Référence. Ce moniteur de référence propose une base de confiance associée à une matrice d’accès qui précise de manière explicite tous les accès autorisés ou refusés au sein du système. De part son caractère non-modifiable par les utilisateurs finaux, le moniteur permet de garantir des propriétés associées à la matrice d’accès. Cette thèse ayant pour objectifs de permettre aux systèmes d’exploitation de garantir des propriétés de sécurité, nous nous focaliserons uniquement sur les modèles de contrôle d’accès obligatoire proches de nos objectifs. D’autres modèles tels que le modèle de Clark-Wilson, de la muraille de chine, sont décrits dans [Rouzaud-Cornabas, 2010]. 2.2.2.1 Bell-LaPadula Le modèle de Bell-LaPadula (BLP ), défini par [Bell et La Padula, 1973], formalise la propriété de confidentialité des données dans les milieux de défense. En plus des notions classiques de sujet, d’objet et de permissions, ce modèle introduit la notion de label. Ce label est un niveau de sécurité, qui va contenir deux types d’identifiant de sécurité. Le premier élément est le niveau hiérarchique, qui renseigne sur le niveau de classification de l’objet ou sur le niveau d’habilitation du sujet. Le second élément est un identifiant de catégories, qui renseigne sur le type de population capable de manipuler les informations comme public, privé ou militaire. Ces identifiants sont indépendants de la hiérarchie de confidentialité. À partir de ces niveaux de sécurité, il est possible de définir deux règles qui régissent le système en plus des mécanismes de contrôles d’accès classiques. — ss-property : simple security property. Cette propriété assure qu’un sujet qui demande un accès en lecture sur un objet du système possède un niveau de sécurité supérieur ou égal à celui de l’objet. — *-property : star property. Seuls les transferts d’informations depuis des objets de classification inférieure vers des objets de classification supérieure sont autorisés. Cette règle assure donc la prévention contre la divulgation d’informations. Le système est modélisé de la façon suivante : — un ensemble de sujet S ; — un ensemble d’objets O ; 322.2. MODÈLES DE CONTRÔLE D’ACCÈS — une matrice d’accès M ; — une fonction donnant le niveau f. On dispose également d’un ensemble de permissions d’accès A = {e, r, a, w}. Elles sont classées suivant leur capacité d’observation (lecture) et d’altération (écriture) de l’information : — execute : e Ni observation ni altération ; — read : r Observation sans altération ; — append : a Altération sans observation ; — write : w Observation et altération. On obtient ainsi les deux lois suivantes : ss-property :r ∈ M[s, o] → f(s) ≥ f(o) *-property :r ∈ M[s, o1] ∧ w ∈ M[s, o2] → f(o2) ≥ f(o1) FIGURE 2.3 – Lois d’application des propriétés de BLP Cependant, la propriété *-property peut être contournée en exploitant les canaux cachés pré- sents sur le système. Ces canaux cachés échappent complètement au mécanisme de contrôle d’accès présent sur le système. Afin de prévenir ce genre de problème, une version plus restrictive de la politique de BLP utilise les règles suivantes : — No Read Up : cette propriété assure qu’un sujet qui demande un accès en lecture sur un objet du système possède un niveau de sécurité supérieur ou égal à celui de l’objet. — No Write Down : cette propriété assure qu’un sujet qui demande à modifier un objet possède bien un niveau de sécurité inférieur ou égal à celui de l’objet. Les trois lois sur les niveaux, illustrées par la figure 2.5, s’écrivent ainsi : r ∈ M[s, o] → f(s) ≥ f(o) a ∈ M[s, o] → f(s) ≤ f(o) w ∈ M[s, o] → f(s) = f(o) FIGURE 2.4 – Lois d’application des propriétés de BLP-restrictives Ces lois signifient que : 1. un sujet s a accès en lecture à un objet o si et seulement si son niveau d’habilitation f(s) est supérieur ou égal au niveau de classification f(o) de l’objet ; 2. un sujet s a accès en écriture seul (ajout) à un objet o si et seulement si son niveau d’habilitation est inférieur ou égal au niveau de classification de l’objet ; 3. un sujet s a accès en lecture/écriture à un objet o si et seulement si son niveau d’habilitation est égal au niveau de classification de l’objet. La figure 2.5 illustre comment se caractérise l’application de ce modèle de protection pour les utilisateurs. Pour qu’un utilisateur puisse accéder à une information, c’est-à-dire puisse la lire, il doit posséder un niveau d’habilitation supérieur ou égal à celui de l’objet. Si un utilisateur veut modifier une information, il doit posséder un niveau d’habilitation inférieur ou égal à celui de l’objet. Ce modèle est difficilement intégrable dans les systèmes d’exploitation courant. En effet, il est difficile de définir des labels pour certains objets du système qui doivent être partagés entre les différents utilisateurs et le système. On peut ainsi citer les répertoires temporaires. Il existe des mécanismes d’aménagement de ce modèle pour le rendre utilisable. Ces mécanismes (trusted subjects) font transiter les objets vers un niveau de sécurité suffisant pour qu’ils puissent être modifiés par les sujets ayant un niveau de sécurité plus élevé. Ainsi la propriété de No Write Down n’est pas enfreinte. Cependant, ces mécanismes conduisent à faire monter l’information au 332.2. MODÈLES DE CONTRÔLE D’ACCÈS niveau de la confidentialité la plus élevée, ce qui oblige alors à des déclassifications complexes. Actuellement, peu de systèmes d’exploitation adoptent ces approches pour l’ensemble du système même si certaines solutions utilisent la classification sous un autre angle. No Read Up Top Secret Secret Confidentiel No Write Down FIGURE 2.5 – Modèle No Read Up/No Write Down 2.2.2.2 Biba Le modèle de BLP traite le problème de la confidentialité des données du système, mais ne propose pas de solution pour protéger l’intégrité de ces données et du système. C’est pour cette raison que Biba a défini un modèle dual à celui de BLP qui formalise les besoins en intégrité d’un système [Biba, 1975]. Tous les sujets et les objets possèdent un niveau d’intégrité. C’est à partir de ce niveau d’intégrité que de nouvelles restrictions sont mises en place sur le système. De manière similaire au modèle de BLP, il propose aussi deux propriétés. — No Read Down : cette propriété assure qu’un sujet qui demande un accès en lecture sur un objet du système possède un niveau d’intégrité inférieur ou égal à celui de l’objet. — No Write Up : cette propriété assure qu’un sujet qui demande un accès en écriture sur un objet du système possède un niveau d’intégrité supérieur ou égal à celui de l’objet. Les lois s’écrivent donc : r ∈ M[s, o] → f(s) ≤ f(o) a ∈ M[s, o] → f(s) ≥ f(o) w ∈ M[s, o] → f(s) = f(o) FIGURE 2.6 – Lois d’application des propriétés de Biba Ces lois signifient que : 1. un sujet s a accès en lecture à un objet o si et seulement si son niveau d’intégrité f(s) est inférieur ou égal au niveau d’intégrité f(o) de l’objet ; 2. un sujet s a accès en écriture à un objet o si et seulement si son niveau d’intégrité est supérieur ou égal au niveau d’intégrité de l’objet ; 3. un sujet s a accès en lecture/écriture à un objet o si et seulement si son niveau d’intégrité est égal au niveau d’intégrité de l’objet. 342.2. MODÈLES DE CONTRÔLE D’ACCÈS Ces règles évitent que se produise un transfert d’information d’un niveau d’intégrité bas vers un niveau d’intégrité haut, ce qui signifierait une compromission de l’intégrité du niveau haut. La figure 2.7 illustre l’application du modèle de protection de Biba. Tout comme le modèle proposé par BLP, le modèle de Biba est difficilement intégrable sur un système d’exploitation courant. En effet, pour que le système soit fonctionnel, il est nécessaire de définir des mécanismes modifiant les niveaux d’intégrité de certains sujets du système. Par cette modification de leur niveau d’intégrité, les sujets sont naturellement descendus vers le niveau d’intégrité le plus bas. De plus, le modèle de Biba interdit les accès non autorisés aux ressources mais pas les mauvaises modifications réalisées par des utilisateurs autorisés [Clark et Wilson, 1987]. No Read Down Niveau d’intégrité haut Niveau d’intégrité moyen Niveau d’intégrité bas No Write Up FIGURE 2.7 – Modèle de protection des données : Biba 2.2.2.3 Role Based Access Control L’administration d’un mécanisme de contrôle d’accès obligatoire est difficile pour un administrateur. Cela implique l’écriture et la gestion d’un grand nombre de règles. L’écriture des politiques de contrôle d’accès peut se révéler extrêmement difficile et coûteuse en termes de temps. Le modèle de contrôle d’accès basé sur les rôles (RBAC ) propose une solution pour diminuer cette complexité d’écriture. Dans la majorité des cas, les permissions d’accès ne sont pas accordées directement en fonction des utilisateurs mais plutôt par rapport à leur activité dans l’entreprise comme le montre [Ferraiolo et Kuhn, 1992]. Ce modèle représente les activités par des rôles. Par la suite, un modèle plus formel a été défini par [Sandhu et al., 1996], qui se nomme RBAC0. Les utilisateurs peuvent accéder à un ensemble de rôles. Puis, ce sont ces rôles qui sont associés à des permissions dans le but d’effectuer des actions sur le système d’exploitation. Enfin, l’utilisateur exerce son activité dans le cadre de sessions, durant lesquelles il peut activer un sousensemble des rôles auxquels il appartient. Ainsi, les politiques de contrôle d’accès s’établissent à partir des autorisations données aux rôles plutôt qu’aux utilisateurs. A partir de ce modèle, une notion de hiérarchie des rôles a été mise en place dans [Sandhu et al., 1996], modèle nommé RBAC1. Cette hiérarchie permet d’avoir un héritage des permissions dans les rôles, suivant la place de la personne dans l’entreprise. Comme le montre la figure 2.8, on retrouve le junior en bas du diagramme et il ne possède que peu de permissions. Alors que le senior est lui placé en haut du diagramme et hérite de toutes les permissions des rôles intermédiaires entre le junior et le senior. 352.2. MODÈLES DE CONTRÔLE D’ACCÈS Junior Senior Rôle intermédiaire Rôle intermédiaire FIGURE 2.8 – Schéma d’héritage du modèle RBAC1 À partir du modèle RBAC0, [Sandhu et al., 1996] définit un troisième modèle nommé RBAC2 qui introduit le support des contraintes. L’objectif de ce support est de modéliser les contraintes des rôles qui peuvent être totalement disjoints. Les types de contraintes supportés dans RBAC2 sont généralement des considérations simples. Elles portent soit sur l’attribution des rôles aux utilisateurs, soit sur l’attribution des permissions aux rôles. Les principaux types de contraintes sont les suivants : — rôles mutuellement exclusifs : un utilisateur ne peut être affecté qu’à un seul rôle dans un ensemble de rôles mutuellement exclusifs. Il s’agit d’une propriété de séparation des privilèges ; — cardinalité : contrainte sur le nombre maximal d’utilisateurs affectés à un rôle ; — rôles prérequis : contrainte qui impose un prérequis pour l’ajout d’un utilisateur dans un rôle. Par exemple, un utilisateur doit faire partie d’un certain rôle pour pouvoir être ajouté dans le nouveau. Le modèle RBAC3 [Sandhu et al., 1996] permet de consolider les trois modèles précédents. Il supporte donc à la fois les hiérarchies de rôles et les contraintes sur l’assignation des rôles et des permissions. L’objectif de ce dernier modèle est de résoudre les problèmes soulevés par la cohabitation de ces deux concepts : support des contraintes sur la hiérarchie de rôles, résolution de conflits entre l’héritage et les contraintes (par exemple quand un rôle hérite de deux rôles mutuellement exclusifs). En pratique, les systèmes d’exploitation utilisent la notion de rôle de façon simplifiée. L’utilité est alors une factorisation d’un ensemble de règles pour différents utilisateurs en une règle associée à un rôle. L’objectif est de regrouper les utilisateurs dans des rôles pour ensuite établir les règles par rapport à ces rôles et non plus par rapport aux utilisateurs. 2.2.2.4 Domain and Type Enforcement Le modèle de protection Domain and Type Enforcement(DTE ) [Boebert et Kain, 1985] est un modèle basé sur une abstraction des ressources du système, créé spécifiquement pour écrire des politiques MAC. Ce modèle ne s’appuie pas sur les notions de sujets et d’objets mais sur celles de domain et de type pour distinguer les entités actives et passives du système. Un type est une chaîne de caractères qui caractérise une ressource du système. La figure 2.9 montre que ce modèle autorise les interactions d’un domaine sur un type, mais aussi les interactions entre les domaines. Le modèle de protection établit par DTE diffère de BLP ou Biba. Alors que ces deux modèles implantent une des propriétés générales de sécurité, le modèle DTE répond à la problématique de 362.2. MODÈLES DE CONTRÔLE D’ACCÈS domaine 1 domaine 2 domaine 3 type 1 type 2 type 3 domaine 4 FIGURE 2.9 – Schéma du modèle DTE contrôle des activités des processus. En effet, ce modèle permet de définir précisément les accès autorisés aux domaines. Le modèle DTE permet donc de répondre à deux objectifs de sécurité : — restreindre les ressources accessibles par un processus : ce modèle s’applique à l’ensemble du système, même aux processus tournant avec des privilèges élevés. C’est aussi une approche de moindre privilège telle que définie précédemment ; — établir un contrôle strict des processus ayant accès aux ressources jugées sensibles et empêcher tout programme non autorisé à y accéder. Les entités actives du système s’exécutent dans un domaine précis alors que les objets du système possèdent tous un type. Ainsi, les lois d’accès opèrent entre les domaines et les types. Ce modèle se base aussi sur la notion de matrice d’accès. Le modèle DTE détermine trois tables : — la table de typages, qui associe un type à chaque objet du système ; — la table de définition des domaines qui détermine les droits d’accès (lecture, écriture, exé- cution, ajout, suppression) de chaque domaine sur les différents types ; — la table d’interaction des domaines qui établit les droits d’accès entre domaines (création, destruction, envoi de signal). La table de définitions des domaines détermine aussi le type d’un programme. L’exécution d’un programme binaire fait entrer le processus dans un domaine précis. Ce modèle a le mérite d’être facile à mettre en œuvre et correspond à la notion de moniteur de référence et de confiance. Il permet de garantir un large ensemble de cas particuliers de confidentialité et d’intégrité. Le principal problème concerne les propriétés incluses dans la politique qui ne sont pas définies au moyen d’un formalisme de haut niveau, ce qui peut rendre leur écriture difficile. 2.2.3 Discussion Nous venons de détailler dans les deux premières parties de cet état de l’art les moyens d’expression d’objectifs de sécurité et des modèles d’application. Les propriétés de sécurité exprimées ici sont des synthèses des définitions que nous pouvons retrouver dans les documents [ITSEC, 1991, TCSEC, 1985]. Les modèles de contrôle d’accès que nous avons présentés offrent des modélisations des objectifs de sécurité. La première remarque que nous pouvons faire est qu’aucun modèle de protection n’implante toutes les propriétés de sécurité que nous avons évoquées. Dans les systèmes d’exploitation courants tels que Linux, MacOs et Windows, nous retrouvons le DAC. Ce modèle de protection ne permet ni de protéger le système, ni les données qu’il héberge. [Harrison et al., 1976] a démontré que la problématique de sûreté de fonctionnement pour un sys- 372.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS tème se reposant sur le contrôle d’accès discrétionnaire n’était décidable qu’au prix de grandes simplifications qui ne correspondent pas à la réalité des systèmes. Dans le cas des systèmes courants, le problème de sûreté n’est donc pas décidable. Les modèles de contrôle d’accès obligatoire offrent des réponses à la problématique de garantie par le système d’exploitation de propriétés de sécurité. La plupart de ces modèles ont été établis pour répondre à des problématiques du monde de défense, c’est-à-dire extrêmement spécifiques et contraignantes. L’implantation réelle de ces modèles dans des systèmes existent, par exemple le modèle de BLP dans MULTICS, on le trouve également dans certaines versions de Solaris, HPUX ou autres systèmes UNIX. Cependant, pour les systèmes d’exploitation courants, ils sont difficilement intégrables car il est nécessaire de créer des exceptions qui mettent le modèle de protection à mal. De plus, ces systèmes ne traitent que d’un cas particuliers des propriétés de sécurité qui est la confidentialité. Le modèle RBAC offre peu d’application pratique en termes de systèmes d’exploitation et sert essentiellement à la factorisation des règles de contrôle d’accès. Enfin, le modèle DTE est le plus flexible. S’il n’est pas dédié à une propriété particulière, il permet d’écrire des politiques incluant un large ensemble de propriétés de confidentialité et d’intégrité entre les processus et les ressources, tout en minimisant les privilèges des processus. 2.3 Implantation des mécanismes de contrôle d’accès Dans cette section, nous allons nous intéresser à l’implantation des mécanismes de contrôle d’accès obligatoire présents à la fois sous Linux et sous Windows. Il existe d’autres implantations présentes sur les systèmes Android, Solaris, etc, mais ces systèmes sortent du cadre de notre étude. Sur les systèmes d’exploitation Linux, il existe un plus grand nombre d’implantations de mécanismes de contrôle d’accès obligatoire que sous Windows car son code source est ouvert. Comme l’objet de cette étude n’est pas de décrire l’implantation de chaque mécanisme présent sous Linux, nous nous restreindrons à quatre implantations de références. Nous avons choisi de décrire SELinux, grsecurity, Tomoyo et PIGA. SELinux et grsecurity font partis des mécanismes les plus anciens et les plus matures sur les systèmes Linux. Leur intégration au sein du système d’exploitation est aussi différente. Nous détaillons aussi Tomoyo et PIGA qui sont deux mécanismes différents des deux premiers et qui ne réalisent pas le même type de contrôle. Une description des projets MEDUSA, RSBAC et LIDS, offrant d’autres implantations de contrôle d’accès obligatoire, est présente dans la thèse [Blanc, 2006]. Sur les systèmes d’exploitation Windows, nous nous attacherons à détailler le mécanisme de contrôle d’intégrité (Mandatory Integrity Control, MIC) mis en place par Microsoft à partir des systèmes d’exploitation Windows Vista. Nous avons aussi choisi de décrire PRECIP, qui est une implantation restrictive du modèle de BLP ainsi que Core Force, le premier mécanisme MAC apparu sous Windows XP. 2.3.1 Linux Dans cette partie, nous allons traiter des mécanismes de contrôle d’accès obligatoire sur les systèmes Linux. 2.3.1.1 SELinux SELinux(Security-Enhanced Linux) est un mécanisme de contrôle d’accès obligatoire créé par la NSA et intégré nativement dans les noyaux Linux. Il est proposé sous la forme de module 382.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS de sécurité s’interfaçant avec les crochets de sécurité (Security Hooks) du noyau (Linux Security Module (LSM ) [Wright et al., 2002]). Basé sur le modèle de DTE, SELinux implante les propriétés de moindre privilège et de confi- nement des processus pour garantir la confidentialité et l’intégrité. Son architecture est basée sur FLASK [Spencer et al., 1998], une architecture spécifiquement créée pour SELinux, qui offre une couche d’abstraction entre le système et le mécanisme de contrôle d’accès sous-jacent, transformant les ressources du système en contexte de sécurité. Ainsi les ressources du système ne sont pas identifiées par leur nom ou par leur chemin, mais par des contextes de sécurité. L’écriture d’une politique SELinux étant complexe, SELinux utilise également le modèle RBAC pour réduire la taille de la politique. Ainsi, les utilisateurs sont associés à des rôles qui peuvent ensuite accéder à des domaines, et ce sont les domaines qui agissent sur les types. Modèle général Chaque utilisateur du système (utilisateur standard, mais aussi administrateur) est associé à une identité SELinux unique. Cette identité SELinux peut être partagée par plusieurs utilisateurs. L’identité SELinux est associée à un rôle par défaut, mais elle peut aussi accéder à un ensemble de rôles. Les utilisateurs ont la possibilité de changer de rôle sans changer de session ou de compte utilisateur. Les rôles accèdent ensuite aux domaines. Chaque ressource du système possède un contexte de sécurité qui la caractérise. Le contexte de sécurité est considéré comme une couche d’abstraction entre les ressources et le mécanisme de contrôle d’accès. Il contient les informations nécessaires au modèle DTE (domaines ou types). Contextes de sécurité L’architecture FLASK crée une couche d’abstraction pour la représentation du système qui lui permet de n’être qu’une interface entre le système d’exploitation et le mécanisme de contrôle d’accès sous-jacent. Cette abstraction permet l’association de contextes de sécurité avec les ressources du système. Les contextes de sécurité sont définis par le serveur de sécurité qui constitue un moniteur de référence au sens d’Anderson. Pour SELinux, un contexte de sécurité est constitué de plusieurs attributs : — une identité qui est liée aux identités des utilisateurs Linux présents sur le système. Ainsi, plusieurs utilisateurs standards peuvent avoir la même identité SELinux. Cette identité SELinux a la particularité de ne pas pouvoir être modifiée aux cours des interactions réalisées. Seuls certains programmes d’authentification ont la capacité de pouvoir changer les identités SELinux ; — un rôle : un utilisateur SELinux a accès à un ensemble de rôles. Ce sont ces rôles qui déterminent les interactions autorisées pour l’utilisateur ; — un domaine, qui est le domaine d’exécution du processus ; — un type, qui est le type d’un objet du système autre qu’un processus ; — une catégorie : cet attribut est la représentation de l’implantation du modèle MultiCategorie Security de SELinux. Il permet de définir des conteneurs pour les utilisateurs dans le but de les isoler les uns des autres. Les catégories permettent d’isoler des populations ayant la même identité SELinux. Il est possible d’avoir plusieurs catégories pour un même contexte de sécurité. — un niveau d’habilitation : cet attribut est l’application du modèle de BLP. Les niveaux d’habilitation peuvent être une valeur unique ou une plage de niveaux. C’est l’implantation du modèle Multi-Level Security de SELinux. 392.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS Un contexte de sécurité est représenté au niveau du système de fichiers par une chaîne de caractères de la manière suivante : id:rôle:type:catégories:sensibilités. Un utilisateur possède une identité SELinux de part son identité standard Linux. Cette identité SELinux lui permet d’accéder à certains nombres de rôles SELinux. Ces rôles peuvent accéder à des domaines. Les domaines peuvent à leur tour accéder à d’autres domaines ou à des types. Ce modèle est illustré par la figure 2.10. Identité SELinux Domaine Rôle SELinux Type Domaine Domaine Type Type Rôle SELinux Changement de rôle Transition FIGURE 2.10 – Implantation des modèles RBAC et DTE par SELinux Pour les objets du système, les contextes de sécurité sont stockés dans le système de fichiers au niveau des attributs étendus. Politique et règle de contrôle d’accès Les domaines effectuent des interactions sur les objets du système qui possèdent tous un type. Une interaction se caractérise par la règle suivante D − (P)− > T, ou D est le domaine, P les permissions et T le type. Le cas spécifique d’une interaction entre deux domaines se traduit de manière similaire D1 − (P)− > D2. La politique de contrôle d’accès de SELinux se divise en deux. D’un côté, nous trouvons les règles faisant la correspondance entre les ressources du système et leur contexte de sécurité spécifique. De l’autre, nous trouvons les règles d’accès et de transition. Les règles d’accès définissent de manière explicite les interactions autorisées par des domaines sur des types du système. Les règles de transition sont les règles qui autorisent la création de nouveau domaine à partir de type spécifique. La définition d’une règle d’accès dans la politique SELinux se fait donc de la manière suivante 2.1. ✞ ☎ 1 allow linpack_t etc_t:file { read open getattr }; ✝ ✆ Listing 2.1 – Règle d’accès dans une politique SELinux Cette règle autorise (allow) le domaine linpack_t à lire, ouvrir et récupérer les attributs des fichiers file { read open getattr } ayant pour type etc_t. Concrètement, cette règle autorise un processus ayant pour domaine linpack_t à aller lire des fichiers de configurations présents dans /etc. Pour autoriser le rôle staff_r à accéder au domaine linpack_t, il suffit d’ajouter la règle 2.2. ✞ ☎ 1 role staff_r types linpack_t; ✝ ✆ Listing 2.2 – Règle d’autorisation pour un rôle pour accéder à un type dans une politique SELinux 402.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS Le dernier type de règle concerne les transitions. Ce sont des opérations spécifiques qui surviennent lors de la création d’un nouveau domaine. La définition d’une règle de transition se définit de la manière suivante 2.3 : ✞ ☎ 1 type_transition staff_t mozilla_exec_t:process mozilla_t; ✝ ✆ Listing 2.3 – Règle de transition dans une politique SELinux Cette règle autorise le domaine staff_t à faire transiter un type mozilla_exec_t vers le domaine mozilla_t. Cette règle est par exemple, appliquée lorsqu’un utilisateur du staff exécute le programme Firefox. 2.3.1.2 grsecurity grsecurity [Spengler, 2002] est un mécanisme de contrôle d’accès obligatoire présent sur les systèmes d’exploitation Linux. À la différence de SELinux, il n’est pas inclus dans la version courante du noyau car il n’utilise pas les LSM comme le préconise les développeurs du noyau. Il est donc disponible sous la forme d’un correctif noyau. En plus d’un mécanisme de contrôle d’accès, grsecurity fournit un second correctif noyau nommé PaX, qui offre des protections contre les attaques de type buffer overflow[Team, 2012]. Modèle général Comme pour SELinux, grsecurity permet de définir des ensembles de règles puis d’affecter ces ensembles à des rôles. En effet, sans cette notion de rôles, tous les utilisateurs auraient les mêmes droits. Un utilisateur peut changer de rôle au sein d’une même session. À la différence de SELinux qui associe un contexte de sécurité à chaque ressource du système, grsecurity identifie les ressources en utilisant leur chemin complet dans l’arborescence du système de fichiers. Ce modèle de protection se nomme Path-Based Access Control (PBAC ). Les interactions sont représentées par les ACL définies sur les objets pour chaque sujet. Par défaut, un nouveau processus hérite des permissions de son père, à part s’il possède un jeu de permissions spécifiques. Politique et règle de contrôle d’accès La politique de contrôle d’accès de grsecurity s’appuie donc sur les chemins complets des sujets (binaires exécutés correspondant à l’application) et des objets pour établir les règles de contrôle d’accès. Chaque règle associe à un sujet, un objet ainsi que les ACL autorisées sur cet objet. grsecurity permet aussi de gérer les capabilities POSIX [ Alexander Kjeldaas, 1998] ainsi que les quantités de ressources utilisables [Spender, 2003]. Par défaut, chaque sujet et objet hérite des droits de son père. Ainsi, un fichier créé héritera des permissions du répertoire dans lequel il est. Il est naturellement possible de briser cet héritage pour définir des permissions spécifiques à ces nouveaux objets. Un règle d’accès dans une politique grsecurity se définit de la manière suivante 2.4. ✞ ☎ 1 subject /usr/bin/sudo 2 /dev/log rw ✝ ✆ Listing 2.4 – Règle d’accès dans une politique grsecurity Cette règle autorise le sujet ayant pour chemin complet /usr/bin/sudo à lire et écrire (rw) l’objet ayant pour chemin /dev/log. grsecurity est aussi capable de gérer les capacités des programmes. Il est donc possible d’ajouter ou d’enlever des capacités aux programmes, comme l’illustre le listing 2.5. 412.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS ✞ ☎ 1 subject /sbin/syslog-ng 2 +CAP_SYS_ADMIN 3 4 subject /usr/sbin/sshd dpo 5 -CAP_ALL 6 +CAP_CHOWN ✝ ✆ Listing 2.5 – Règle de modification de capabilities dans une politique grsecurity 2.3.1.3 Tomoyo Tomoyo [Corporation, 2003, Takeda, 2009] est un mécanisme de contrôle d’accès obligatoire apparu en 2003. Depuis la version 2 de Tomoyo sortie en 2007, il utilise les LSM pour réaliser ses contrôles. Modèle général Tomoyo reprend la notion de domaine énoncée par [Lampson, 1971], c’est-à-dire qu’un domaine regroupe un ensemble d’entités actives du système qui ont les mêmes capacités. Ainsi Tomoyo construit un domaine en gardant traces des précédents processus impliqués dans la création du processus, qui réalise l’action. Par conséquent, Tomoyo n’utilise pas de label ou de contexte de sécurité pour représenter les ressources du système, mais il se base sur les chemins complets des sujets et des objets, donc sur le modèle PBAC. Le listing 2.6 donne un exemple de domaine. ✞ ☎ 1 /usr/sbin/sshd /bin/bash /usr/bin/man /bin/sh ✝ ✆ Listing 2.6 – Définition d’un domaine dans une politique Tomoyo À chaque domaine est associé un ensemble de sujet et d’objet identifiés par leurs chemins complets. La gestion des accès se fait grâce au triplet (r,w,x) sur les objets. Lorsqu’un processus exécute un fichier binaire créant un nouveau processus, cela entraîne une transition vers un nouveau domaine. L’implantation de Tomoyo permet de représenter, sous la forme d’un graphe, l’évolution de chaque domaine en cours sur le système. À la différence des mécanismes comme SELinux et grsecurity, il est capable de gérer les connexions réseaux et l’administrateur peut donc définir au niveau de la politique de contrôle d’accès, les plages d’adresses IP autorisées pour un domaine donné. Politique et règles de contrôle d’accès La politique de contrôle d’accès de Tomoyo s’appuie donc sur deux éléments : les chemins complets des ressources du système et la définition des domaines. La politique associe, à chaque domaine, un ensemble de fichiers binaires que le domaine a le droit d’exécuter dans le but de créer un nouveau domaine. Elle associe aussi un ensemble d’objets (fichier, socket, etc.) auxquels sont associés le triplet de permissions (r,w,x). La politique se base sur les droits (r,w,x) présents sous Linux. Chaque permission possède une valeur numérique unique. Il est possible d’ajouter ces valeurs pour combiner plusieurs permissions. Ainsi, on fait correspondre au triplet (r,w,x) le triplet (4,2,1). Dans cette représentation, r a pour valeur 4, w 2 et x 1. Pour donner le droit à un domaine d’écriture et de lecture sur un objet, il suffit de donner la valeur 4 + 2 = 6 sur l’objet pour le domaine concerné. Le listing 2.7 montre un exemple de politique pour Tomoyo. 422.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS ✞ ☎ 1 /sbin/mingetty /bin/login 2 1 /bin/bash 3 4 /etc/passwd 4 4 /etc/shadow ✝ ✆ Listing 2.7 – Règle d’accès dans une politique Tomoyo Cette politique correspond à un domaine représenté par la trace /sbin/mingetty /bin/login. Ce domaine est autorisé à exécuter (1) le fichier /bin/bash et il est autorisé à lire les fichiers /etc/passwd et /etc/shadow. Lorsque le domaine exécutera le fichier /bin/bash un nouveau domaine sera créé. Ce domaine sera composé des éléments suivants : /sbin/mingetty /bin/login /bin/bash. Tomoyo étend les ACL par l’utilisation de mots clés dans sa politique de contrôle d’accès. Ainsi, il est possible, grâce à des expressions régulières, d’autoriser un domaine à accéder à une ressource qui n’est pas encore présente sur le système. L’extension des ACL se traduit aussi par des permissions supplémentaires telles que la possibilité de supprimer une ressource. Le listing 2.8 montre un exemple d’utilisation de l’extension des ACL. Ainsi le langage de configuration supporte à la fois les valeurs numériques des droits classiques mais aussi des mots clés permettant une lecture plus simple des politiques. ✞ ☎ 1 /usr/sbin/httpd 2 allow_read /var/www/html/\* 3 allow_read /etc/httpd/\*.conf 4 allow_read /usr/lib/httpd/modules/\*.so 5 allow_write /var/log/httpd/\*_log 6 allow_create /var/run/httpd.pid 7 allow_unlink /var/run/httpd.pid ✝ ✆ Listing 2.8 – Règle d’accès dans une politique Tomoyo La politique offre aussi la possibilité de gérer des capacités spécifiques aux domaines. Ainsi, il est possible de spécifier, par exemple, les plages d’IP sur lesquelles le domaine est autorisé à se connecter comme le montre le listing 2.9. ✞ ☎ 1 allow_network 2 TCP accept 3 10.0.0.0-10.255.255.255 4 1024-65535 ✝ ✆ Listing 2.9 – Règle d’accès dans une politique Tomoyo 2.3.1.4 Policy Interaction Graph Analysis PIGA [Briffaut, 2007] est un mécanisme de contrôle d’accès obligatoire proposé sous deux formes : — un correctif noyau qui est le Policy Enforcement Point (PEP), c’est-à-dire le point d’application de la politique ; — une implémentation d’un moniteur de référence, qui est donc le Policy Decision Point (PDP), c’est-à-dire le moniteur qui prend la décision. À la différence des mécanismes précédemment présentés comme SELinux et grsecurity, PIGA est capable de gérer à la fois les interactions entre un sujet et un objet ou entre deux sujets, mais aussi des compositions d’interactions (flux entre plusieurs interactions, enchaînement temporel entre les interactions, opérateurs logiques entre interactions, etc.). 432.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS PIGA se base sur un langage de spécification de propriétés de sécurité (Security Property Language, SPL) de haut niveau, en comparaison de DTE, qui offre la possibilité d’exprimer des propriétés de sécurité 2.1. Ces propriétés de sécurité sont par la suite garanties par le moniteur PIGA. Modèle général Dans [Briffaut et al., 2009], les auteurs détaillent le langage d’expression des propriétés de sécurité (SPL). Ce langage indépendant du mécanisme de contrôle d’accès permet d’exprimer des propriétés combinant plusieurs types de flux. La représentation du système utilise les contextes de sécurité définis par SELinux. Il distingue donc l’ensemble des contextes sujets SCs et l’ensemble des contextes objets SCo. Lorsqu’une interaction est effectuée sur le système, il peut y avoir deux effets : un transfert d’information ou une transition. Le transfert d’information se fait du contexte sujet vers le contexte objet lorsque l’opération associée est une écriture. Il se fait dans le sens inverse lors d’une opération de lecture. Une transition est un changement de domaine. À partir de ces éléments, les auteurs donnent une définition de la dépendance causale entre deux interactions. Ainsi, deux interactions sont causalement dépendantes si : — elle partage un même contexte de sécurité ; — la première interaction intervient avant la fin de la seconde ; — la première interaction modifie l’état du contexte de sécurité partagé ; — la seconde interaction modifie l’état du contexte de sécurité final. Cette définition permet ensuite de formaliser les notions d’interactions et de séquences. Une interaction directe, notée >, est une opération élémentaire (lecture, écriture, etc.), qui induit un transfert d’information direct entre un processus et une ressource. Une séquence, notée >> correspond à une suite d’interactions causalement dépendantes et induit un flux d’information indirect mettant en jeu au moins 3 contextes, le second servant d’intermédiaire. Grâce à ces opérateurs de base, les auteurs peuvent exprimer des propriétés de sécurité comme la confidentialité et l’intégrité dans un langage de haut niveau. Ces propriétés de sécurité peuvent être exprimées en utilisant la notion d’interaction, c’est-à-dire de flux d’information direct, ou de séquence, c’est-à-dire de flux d’information indirect, de suite temporelle, d’expression logique, etc. PIGA est proposé sous la forme de plusieurs outils : PIGA-CC, qui énumère les activités autorisées par une politique MAC contrôlant les interactions directes qui violent les propriétés PIGA exprimées en SPL, PIGA-UM, qui est le moteur de prise de décision et PIGA-Kernel, qui est le hook noyau interceptant les accès autorisés par SELinux. PIGA-CC, dont le fonctionnement est illustré par la figure 2.11 prend en entrée les propriétés de sécurité écrites en SPL et la politique de contrôle d’accès directe MAC (par exemple : une politique SELinux). Il recherche, dans la politique de contrôle d’accès directe, les activités susceptibles de contourner les propriétés de sécurité. Cette opération se fait en mode hors ligne, c’est-à-dire avant que PIGA ne soit déployé sur un système. Les activités illégitimes calculées sont ensuite utilisées par PIGA-UM. Lorsque PIGA-UM reconstruit l’activité du système, il va vérifier que cette activité ne correspond pas à une activité illégitime. La partie prise de décision s’effectue en espace utilisateur par PIGA-UM. C’est l’implantation du moniteur de référence définie par [Anderson, 1972]. À partir de chaque interaction capturée en espace noyau, il reconstruit l’activité du système. Cette reconstruction lui permet de vérifier la validité des interactions vis-à-vis des activités qu’il a pré-calculées. Lors de ce calcul, PIGA génère les activités réelles susceptibles de violer les propriétés de sécurité. Par conséquent, si l’interaction 442.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS FIGURE 2.11 – Fonctionnement de PIGA-CC courante fait partie d’une activité réelle qui correspond à une activité illégitime, cette interaction (appel système) est bloquée. PIGA-Kernel permet de détourner le flux d’exécution des interactions directes. PIGA-Kernel transmet les interactions autorisées à PIGA-UM afin qu’il contrôle les activités correspondant aux scénarios complets. Lorsqu’un processus effectue un appel système, il est intercepté par SELinux. Si l’appel est autorisé au niveau de SELinux, alors PIGA-Kernel va l’intercepter. Il va ensuite l’envoyer à PIGAUM. PIGA-UM va ajouter cet appel pour reconstruire l’activité du système, puis il va rechercher dans les signatures qui ont été pré-calculées si cette interaction ne fait pas partie d’une activité illégitime. Si c’est le cas, PIGA-UM a deux possibilités : soit il est en mode en détection et dans ce cas, il se contente de lever une alerte de sécurité sans que l’interaction ne soit bloquée, soit il est en mode protection et par conséquence, l’interaction illégitime échouera c’est-à-dire que le scénario malveillant ne se terminera pas. 2.3.1.5 Politique et règle de contrôle d’accès Le listing 2.10 montre un exemple de propriété de sécurité exprimée en SPL qui garantit la confidentialité. Ainsi, la propriété 2.10 s’interprète ainsi : à partir de deux contextes de sécurité cibles, sc1 qui le contexte sujet et sc2 qui est le contexte objet, PIGA va contrôler qu’il n’existe aucun flux d’information indirect >> partant de sc2. ✞ ☎ 1 define confidentiality( $sc1 IN SCS, $sc2 IN SCO ) [ 2 SA { $sc2 >> $sc1 }, 3 { not(exist()) }; 4 ]; ✝ ✆ Listing 2.10 – Propriété de confidentialité exprimée en SPL Les résultats fournis par PIGA sont dans ce cas des activités autorisées par la politique de contrôle d’accès directe qui conduisent à un flux indirect (en effet, dans la pratique, les flux directs sont déjà traités par le MAC, comme SELinux). On voit que PIGA améliore la sécurité par rapport à SELinux et permet de formaliser des propriétés de sécurité, ce que ne permet pas SELinux qui est de plus bas niveau. 2.3.2 Windows Dans cette section, nous allons maintenant détailler des implantations de mécanismes de contrôle d’accès obligatoire pour les systèmes d’exploitation Windows. 452.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS 2.3.2.1 Mandatory Integrity Control MIC (Mandatory Integrity Control) est un mécanisme de contrôle d’accès obligatoire breveté par Microsoft [Richard Ward, 2006]. Ce modèle, plus récent que les implantations de SELinux et de grsecurity, a été mis en place à partir des systèmes d’exploitation Windows Vista. À la différence des implantations présentes sous Linux, qui doivent être activées pour SELinux, et où il est nécessaire de modifier le noyau pour grsecurity, l’implantation de Microsoft est imposée. Son principal objectif est de protéger le système des attaques, qu’elles viennent de l’extérieur ou de l’intérieur. Modèle général Le modèle de protection s’inspire des modèles de Biba et de BLP que nous avons détaillé dans la section 2.2.2.2. Chaque entité du système, que ce soit les sujets ou les objets, possède un niveau d’intégrité [Microsoft, 2013]. Pour qu’un sujet puisse modifier un objet, il doit nécessairement posséder un niveau d’intégrité supérieur ou égal à celui de l’objet. Cependant, nous avons vu que le modèle de protection défini par Biba était difficilement applicable à un système d’exploitation. Pour résoudre ce problème, Microsoft n’offre que la propriété de non modification des objets ayant une intégrité supérieure (No Write Up). Politique et règle de contrôle d’accès Par défaut, il existe cinq niveaux d’intégrité. — le niveau de non confiance (Untrusted) qui concerne les processus appartenant aux sessions invitées et qui ne peuvent faire aucune interaction privilégiée sur le système ; — le niveau d’intégrité bas est utilisé pour les processus ayant une forte exposition aux attaques et qui possèdent souvent des failles de sécurité permettant d’entrer sur le système ; — le niveau d’intégrité moyen qui est le niveau d’intégrité par défaut de l’utilisateur qui s’est connecté. C’est aussi le niveau d’intégrité sous lequel tourne la majorité des programmes lancés par l’utilisateur ; — le niveau d’intégrité haut, qui est réservé à l’administrateur du système ; — enfin, le niveau d’intégrité système réservé au système. Tout comme le définit le modèle basé sur les niveaux d’intégrité de Biba 2.2.2.2, les sujets ayant une intégrité inférieure à celle de l’objet ne peuvent pas le modifier (No Write Up qui s’applique spécifiquement aux objets du système). Mais à la différence du modèle théorique, la politique de contrôle d’accès sous Windows n’empêche pas un sujet ayant une intégrité plus élevée que l’objet de le lire (principe du No Read Down). Les lois s’écrivent de la façon suivante : a ∈ M[s, o] → f(s) ≥ f(o) w ∈ M[s, o] → f(s) = f(o) FIGURE 2.12 – Lois d’application des propriétés du MIC Pour renforcer son implantation, Microsoft a mis en place, en plus des niveaux d’intégrité, des labels s’appliquant sur les sujets du système. Ces labels agissent en complément des niveaux d’intégrité. Ils permettent de renforcer le contrôle d’accès présent sur les systèmes Windows. Par défaut, trois labels de sécurité sont définis : — No Read Up : les sujets ayant une intégrité strictement inférieure à celle du sujet cible ne peuvent pas lire le contenu du sujet. Ce label empêche les processus d’intégrité basse d’ob- 462.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS server les processus ayant une intégrité plus haute. Ce label de sécurité est une application restreinte du modèle de BLP ; — No Write Up, s’applique ici sur les sujets du système : les sujets ayant une intégrité strictement inférieure à celle des sujets ne peuvent pas les modifier, c’est l’application d’une des deux propriétés énoncées par Biba ; — No Execute Up : restreint la permission d’exécution sur les objets par les sujets ayant un niveau d’intégrité bas. La figure 2.13 illustre l’application du modèle de protection MIC. Niveau d’intégrité haut Niveau d’intégrité moyen Niveau d’intégrité bas No Write Up No Read Up No Execute Up FIGURE 2.13 – Modèle de protection des données : MIC Cependant, dans le but d’assurer le fonctionnement du système, il existe des exceptions possibles. Les utilisateurs autorisés à effectuer des tâches d’administration ont la possibilité de modifier leur niveau d’intégrité. L’objectif étant d’augmenter le niveau d’intégrité d’un processus pour qu’ils puissent réaliser les tâches privilégiées. Cette augmentation de privilège s’opère, par exemple, lorsqu’un utilisateur veut installer un nouveau logiciel ou réaliser une mise à jour. Cette autorisation d’augmentation du niveau d’intégrité est représentée par le jeton d’accès Administrateur. Il autorise ainsi les processus à écrire dans les répertoires modifiables uniquement par l’administrateur. Depuis Windows Vista, il n’existe plus de compte Administrateur sous Windows. On peut rapprocher la possibilité d’augmentation du niveau d’intégrité pour un utilisateur de la commande sudo sous Linux, qui permet de changer l’environnement de l’utilisateur, généralement dans le but d’effectuer des tâches d’administration. Ce modèle de contrôle d’accès est mis en place pour protéger le système et les fichiers systèmes des attaques qui pourraient modifier leur intégrité. À la différence des implantations de mécanisme de contrôle d’accès sous Linux utilisant les LSM, le contrôle du MIC est fait avant le contrôle des droits d’accès discrétionnaire. Cela entraîne la possibilité pour l’utilisateur élevant son niveau d’intégrité par le jeton d’accès Administrateur de contourner les droits d’accès classiques. En effet, une fois son intégrité modifiée, il se retrouve avec des privilèges administrateur ce qui lui permet de contourner les droits d’accès discrétionnaire et lui offre presque tous les droits. Cette implantation d’un mécanisme de contrôle d’accès obligatoire est la première réalisée par Microsoft. Elle a l’avantage de proposer une approche plus simple que SELinux ou grsecurity puisqu’il n’est pas nécessaire d’écrire une politique énumérant tous les privilèges. En pratique, il 472.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS ne protège pas les données des utilisateurs accessibles via le jeton d’accès Administrateur. Ainsi, MIC ne permet pas de minimiser les privilèges, ce qui autorise de nombreuses violations de confi- dentialité et d’intégrité car il n’implante qu’une partie du modèle de protection de Biba. 2.3.2.2 PRECIP PRECIP (Practical and Retrofittable Confidential Information Protection) [Wang et al., 2008] est un mécanisme de gestion des flux d’information directs développé pour Windows XP. Il implante une simplification du modèle de BLP. En plus d’un mécanisme de contrôle, il est fourni avec une suite d’outils aidant à son administration. Modèle général PRECIP associe deux niveaux de sécurité aux objets du système. Ces niveaux sont "haut" et "bas". Les sujets possèdent aussi deux niveaux de sécurité trust et untrusted. Pour qu’un sujet puisse accéder à un objet ayant un niveau haut, il doit être considéré comme "de confiance". Cette modélisation est une implantation sur un système réel, ici testée sur Windows XP, du modèle de BLP. L’objectif de cette implantation est de respectée la confidentialité du système, même en cas d’attaque. Cette implantation d’un mécanisme de contrôle d’accès obligatoire est l’une des premières présente sur les systèmes d’exploitation Windows. Elle implante une simplification de modèle de confidentialité définie par BLP. Cette implantation se base sur le suivi des flux implicites et explicites et sur l’utilisation de l’étiquette dynamique des données. Cependant, le modèle est limité à seulement deux niveaux de confidentialité. De plus, les règles sont limitées et ne protègent pas le système complet, juste les fichiers considérés comme sensibles. Les règles ne sont pas applicables à tout le système et elle ne sont pas extensibles. Enfin, les résultats montrent un impact non négligeable sur les performances du système d’exploitation ainsi que sur le fonctionnement des applications [Wang et al., 2008]. Politique et règle de contrôle d’accès PRECIP définit deux niveaux de confidentialité pour les objets du système : high et low. Ces informations sont stockées dans les flux NTFS des objets. Les sujets peuvent avoir deux niveaux de sécurité : trust et untrusted. Ces niveaux sont stockés dans une structure du noyau. La détermination de ces niveaux est faite sur l’établissement d’une base de données fournie par l’outil. Un sujet est considéré comme de confiance si l’outil a pleinement conscience de toutes les entrées et toutes les sorties possibles de l’exécutable. Si ce n’est pas le cas, il sera alors marqué comme de non confiance. Les niveaux de confidentialité des objets du système sont dérivés des droits d’accès discrétionnaire. Par exemple, un fichier dont le propriétaire est l’administrateur est considéré comme sensible. La définition des niveaux de confidentialité peut aussi être faite par le propriétaire des fichiers grâce aux outils fournis par PRECIP. Des outils spécifiques, permettant de faire transiter des processus en mode sensible comme les navigateurs Internet qui vont sur les sites sensibles, ont aussi été mis en place. 2.3.2.3 Core Force Core Force [Labs, 2005] est une suite d’outils divisée en deux parties : un pare-feu et un mécanisme de contrôle d’accès. Core Force permet de confiner les processus et contrôler leurs privilèges. 482.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS ✞ ☎ 1 2 ✝ ✆ Listing 2.11 – Extrait d’un fichier de configuration de Core Force pour un programme ✞ ☎ 1 2 3 A Policy includes previously defined configuration parameters. 4 5 6 7 8 ✝ ✆ Listing 2.12 – Extrait d’un fichier de configuration de Core Force pour un programme spécifiant les permissions Modèle général Core Force se base sur le modèle de grsecurity pour faire du contrôle d’accès, c’est-à-dire qu’il va appliquer le triplet (r,w,x) pour chaque objet du système. Comme grsecurity ou SELinux, il est nécessaire de définir explicitement les interactions autorisées pour chaque application du système. Core Force est fourni sous la forme d’un logiciel, installable uniquement Windows 2000 et sur Windows XP. Il est composé de deux driver noyau, un qui contrôle des interactions sur le système de fichiers et sur le registre, et le second pour contrôler les interactions du réseau. La configuration par défaut définie des profils de sécurité pour les applications. Ces profils sont des templates de sécurité, qui proposent des politiques de sécurité par défaut vis-à-vis du profil sélectionné. Il est cependant possible de créer des profils spécifiques pour les applications. Politique et règle d’accès La politique de contrôle d’accès s’appuie sur le chemin complet des sujets et des objets. Tout comme grsecurity, une règle de contrôle d’accès associe un sujet à un objet avec un ensemble de permission qui se définissent grâce aux ACL. Pour configurer les permissions pour les applications, Core Force propose une interface graphique facilitant la configuration du contrôle d’accès. Les permissions sont ensuite stockées dans des fichiers au format XML. Nous allons détailler un exemple de politique. Tout d’abord, le fichier XML spécifie pour quel programme s’applique cette politique 2.11. Ensuite, le fichier de configuration spécifie les interactions autorisées par le programme 2.12. Nous pouvons noter ici que le programme Firefox a le droit de lecture et d’écriture sur le fichier pluginreg.dat dans le dossier Mozilla. L’approche Core Force a été abandonnée depuis l’arrivée de Windows Vista, 7 et 8. 2.3.3 Distributed Security Infrastructure Distributed Security Infrastructure (DSI) [Pourzandi et al., 2002] est un framework de dé- ploiement et d’administration d’une politique de contrôle d’accès pour un environnement HPC. C’est la première implantation d’un framework de gestion d’une politique de sécurité orienté 492.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS système distribué. Le projet a ensuite évolué pour être intégré dans un framework nommé HAOSCAR [Leangsuksun et Haddad, 2004]. Les auteurs de DSI ont mis en place une architecture distribuée pour répondre à la problématique de déploiement et de gestion d’une politique de sécurité dans un environnement distribué. L’intégration de DSI dans HA-OSCAR avait pour objectif de cibler les environnements HPC. Cette intégration a entraîné le changement de nom pour devenir RASS [Darivemula et al., 2006] (Reliability, Availability, Serviceability and Security). Cette architecture se base sur la définition de deux éléments clés : le Security Server et Security Manager. Le Security Server est le point d’entrée du système pour la gestion de l’infrastructure. Il est chargé du déploiement de la politique de sécurité sur tous les nœuds. Il doit aussi distribuer les mises à jour de la politique. Il s’occupe enfin de remonter les alertes de sécurité en provenance des nœuds. Les Security Manager sont déployés sur les nœuds du cluster. Ce sont les agents locaux chargés d’appliquer la politique de sécurité qu’ils ont reçue du serveur de sécurité. Dans [Pourzandi et al., 2002], les auteurs appliquent une politique de sécurité pour SELinux. Les communications entre le serveur de sécurité et les managers se font sur des canaux authentifiés et chiffrés. Ces canaux de communication sont utilisés pour remonter les alarmes et les alertes de sécurité ainsi que pour la distribution de la politique de sécurité. La politique de sécurité, appelée Distributed Security Policy (DSP) par les auteurs, définit explicitement les accès autorisés sur chaque système. Elle est gérée sur le SS par un administrateur. Grâce aux canaux de communication chiffrés, les agents locaux autorisent des mises à jour de la politique. Les règles d’accès définissent les accès autorisés sur le système mais aussi sur les échanges entre les systèmes. Pour contrôler les interactions entre les systèmes, DSI ajoute un security node ID (SNID). En plus de ce SNID, DSI définit des secure ID(SID) pour chaque sujet (SSID) et chaque objet d’un système (TSID). Grâce à ces deux ID, les auteurs établissent le cluster security ID (CSID). Ce CSID est ajouté aux options des paquets IP. Ce sont enfin les Security Manager qui réalisent le contrôle d’accès en vérifiant les CSID présents dans chaque paquet IP. Il est ainsi possible de contrôler les communications établies entre les nœuds du cluster. Cependant, cette approche est très proche de SELinux et peu extensible, elle n’offre en pratique aucun couplage possible avec d’autres mécanismes de sécurité. 2.3.4 Impact sur les performances Nous allons traiter dans cette partie de l’impact sur les performances des mécanismes de contrôle d’accès. En vue de l’intégration d’un mécanisme de contrôle d’accès obligatoire, il est nécessaire de connaître son impact sur le système d’exploitation, spécialement pour le HPC. Dans l’article [M. Fox et Thomas, 2003], les auteurs opposent SELinux à grsecurity. Ils pré- sentent dans une première partie le fonctionnement de chaque mécanisme de contrôle d’accès obligatoire. Puis ils exécutent différents benchmarks : lmbench et unixbench. Ces benchmarks réalisent des séries d’opérations sur le système de fichiers comme des lectures et écritures de fichiers de différentes tailles mais aussi des opérations spécifiques comme des exécutions de processus, etc. Ces benchmarks sont exécutés suivant différentes configurations (par un utilisateur standard, un administrateur, puis en mode protection). La conclusion de cet article est que ces mécanismes de contrôle d’accès influencent différemment les performances du système d’exploitation. Cette influence va dépendre de l’action réalisée : écriture, changement de contexte, etc. Il n’est donc pas possible de dire avec précision si un mécanisme de contrôle d’accès est plus adapté qu’un autre aux environnements HPC. La principale limite de cet article est que les auteurs ne font que comparer SELinux avec grsecurity sans proposer les résultats pour un système sans contrôle d’accès obligatoire. 502.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS Les auteurs de RASS [Leangsuksun et al., 2005] proposent aussi une étude sur l’impact sur les performances du mécanisme de contrôle d’accès obligatoire qu’ils ont mis en place dans un milieu HPC. Les résultats portent sur des versions du noyau Linux assez anciennes puisque la version du noyau est 2.4.17. L’impact sur le système de fichiers est compris entre 0% et 2% suivant les opérations par rapport à un système sans le système RASS. Les opérations les plus impactées sont les exécutions de nouveau processus. Par contre, une latence comprise 20% et 30% a été mesurée pour les messages envoyés et reçus en UDP. Cette latence est due aux modifications des paquets IP faites par les Security Manager dans le but d’y ajouter les CSID. Sans le contrôle réseau, la latence est de l’ordre de 5%. Cette première étude montre que l’intégration d’un mécanisme de contrôle d’accès obligatoire dans un environnement ayant de fortes contraintes en termes de performances est possible. Cependant, les latences réseaux générées à cause des modifications des paquets IP ne sont pas encore intégrables dans les environnements HPC. Dans une seconde étude [Blanc et Lalande, 2012], les auteurs montrent que l’intégration d’un MAC peut être faite dans un environnement HPC. Dans une première partie, les auteurs proposent la mise en place de propriétés de sécurité pour confiner les utilisateurs et protéger les services critiques présents sur le système. Pour cela, ils utilisent SELinux. Le confinement des utilisateurs se fait par l’utilisation des catégories présentes dans SELinux. Ils concluent par des tests de performance sur le système de fichiers Lustre. Il en résulte que l’ajout de SELinux, associé à ce système de fichiers spécifiques, engendre un surcoût de 10% sur les entrées/sorties. Cependant, il s’agit uniquement d’une expérimentation avec SELinux qui n’offre pas de cadre général pour évaluer les performances. 2.3.5 Discussion Nous venons de détailler les implantations des mécanismes de contrôle d’accès obligatoire présents sur les systèmes d’exploitation Linux et Windows. Pour chaque implantation, nous avons détaillé les propriétés de sécurité que le mécanisme est capable de garantir. Le tableau 2.2 récapitule, pour chaque système d’exploitation étudié, la liste des propriétés de sécurité supportées. Nous pouvons tirer deux constats de ce tableau. Le premier est que les mécanismes de contrôle d’accès obligatoire présents sous Linux sont assez complets et permettent de couvrir un large panel de propriétés de sécurité que nous avions exprimés. Il n’est donc pas nécessaire de rajouter un nouveau mécanisme pour ce système d’exploitation. Cependant, nous avons aussi montré un manque d’intégration de ces mécanismes dans les environnements distribués et plus particulièrement dans les environnements HPC. Seul le projet DSI propose une intégration d’un MAC dans les clusters, mais sans pour autant juger avec précision de l’impact sur les performances du système. De plus, les travaux proposés sont maintenant assez anciens par rapport aux noyaux Linux actuels. Le second constat que nous pouvons faire, est le manque de mécanismes capables d’appliquer des propriétés de sécurité sur les systèmes Windows. Le plus complet est le MIC, le mécanisme mis en place par Microsoft, mais ce dernier souffre de quelques faiblesses qui peuvent se révéler dangereuses pour le système. Comme nous l’avons détaillé, ce mécanisme n’est pas capable de protéger efficacement tout le système puisqu’il s’attache à vérifier l’intégrité des fichiers du système. Il ne contrôle pas, par défaut, les actions effectuées sur les fichiers des utilisateurs. Certains mécanismes tels que Core Force ou PRECIP existent, mais ils ne sont, soit plus maintenus pour les systèmes actuels (Windows 7 et Windows 8) soit ne permettent pas un contrôle précis de toutes les activités. 512.4. CONCLUSION Linux Windows MAC SELinux grsecurity Tomoyo PIGA MIC PRECIP Core Force Confidentialité - des objets oui oui oui oui x oui x - des sujets x x oui oui oui x x Intégrité - des objets oui oui oui oui oui x x - des sujets x x x oui oui x x Propriétés spécifiques - BLP oui oui x oui x oui x - Biba oui x x oui oui x x Propriétés dérivées - Conf de processus oui oui oui oui x oui oui - Moindre privilège oui oui oui oui x x oui - Séparation de privilèges oui oui x oui x x x - Non-interférence x x x oui x x x - Nouvelles propriétés oui oui oui oui x x oui TABLE 2.2 – Tableau récapitulatif des propriétés de sécurité appliquées par les implantations de contrôle d’accès obligatoire 2.4 Conclusion La problématique du contrôle d’accès s’avère différente à traiter suivant les systèmes d’exploitation. D’un côté, nous avons plusieurs implantations matures et éprouvées, de l’autre, il n’existe que très peu de choses. Sur les systèmes d’exploitation Linux, nous avons choisi de détailler l’implantation de quatre mécanismes de contrôle d’accès obligatoire. Il en existe cependant d’autres proposant leurs propres implantations. Nous pouvons par exemple citer SMACK [Casey Schaufler , 2008] (Simplified Mandatory Access Control Kernel) qui se base sur la définition de labels de sécurité et qui propose une implantation du modèle de BLP. Comme son nom l’indique, c’est un mécanisme qui se veut simple à configurer et à utiliser puisqu’il ne propose que peu de labels (trois par défaut). Il est notamment utilisé dans le système d’exploitation de Samsung pour ses téléphones portables, appelé Tizen. Tous ces mécanismes se basent sur la définition de politique de sécurité qui peuvent être ré- digées soit à la main, soit générées de manière plus ou moins automatiques facilitant ainsi grandement leur intégration dans les systèmes Linux. La mise à disposition d’outils d’administration et d’aide à la gestion des politiques permet d’avoir des systèmes qui peuvent être maintenus facilement. De plus, il est facile de noter que sur les systèmes d’exploitation Linux, nous avons le choix dans le mécanisme de contrôle d’accès à utiliser. Ce choix est en partie dû à la possibilité de s’intégrer au noyau facilement en utilisant les LSM, hormis grsecurity qui continue de proposer un patch noyau. Sur les systèmes d’exploitation Windows, il n’existe pas autant de choix. Les premiers projets sur le renforcement du contrôle d’accès ne proposent que d’étudier les faiblesses de configuration du contrôle d’accès discrétionnaire, par exemple Netra [Naldurg et al., 2006]. Ces outils, qui fournissent des rapports et des graphiques présentant les attaques possibles à partir d’un état du système, ne sont que des moyens de détection hors ligne et n’offrent pas de réelles solutions pour renforcer la sécurité des systèmes d’exploitation Windows. D’autres projets proposent des mécanismes pour faire de la protection du système. Ces implantations se focalisent sur certains points précis du système : gestion des exécutables ou protection des fichiers considérés comme sensibles. Ces outils sont issus de phase d’expérimentation sur des 522.4. CONCLUSION logiciels malveillants, ils ne sont pas capables de contrer les comportements qu’ils ne connaissent pas. Le mécanisme de contrôle d’accès obligatoire proposé par Microsoft, le MIC, vise essentiellement à protéger le système de toute modification malveillante, mais ce mécanisme ne protège en aucun cas les données des utilisateurs (protection en intégrité ou en confidentialité). De plus, dans la pratique, l’utilisation de ce mécanisme se révèle difficile pour l’ensemble du système et fragile puisque l’utilisateur peut autoriser l’élévation de privilèges. Nous pouvons aussi ajouter que Microsoft propose, sur les versions Enterprise et Ultimate de Windows 7, un outil qui se nomme AppLocker [Microsoft, 2009]. Il permet de configurer les droits d’accès sur les ressources du système. Cette configuration peut se faire de manière graphique. Nous nous sommes aussi intéressés à l’intégration dans les environnements distribués, et plus particulièrement dans les milieux HPC, des mécanismes de contrôle d’accès obligatoire. Il existe des projets visant à renforcer la sécurité des grilles, notamment les échanges entre les différents services par exemple en utilisant les langages de type XACML [OASIS, 2013]. Néanmoins, si le projet DSI s’intéresse à l’intégration d’un MAC dans les milieux HPC, il traite de façon incomplète l’impact d’un tel mécanisme sur les performances du système d’exploitation. D’une part, nous avons donc vu que sur les systèmes d’exploitation Linux, il existait un certain nombre de modèles de protection obligatoire. Tous ces modèles ont été développés pour être inté- grés dans les systèmes pour les stations de travail. Avec le développement des systèmes distribués, mais aussi des environnements de calcul à haute performance, le renforcement du contrôle d’accès sur les grilles devient une nécessité. Peu de projets se sont intéressés à l’intégration de ce type de mécanisme de contrôle d’accès dans les environnements distribués et l’impact d’un tel mécanisme sur les performances des systèmes d’exploitation est peu évoqué. On manque notamment de modèles et de protocoles précis d’évaluation des performances. Enfin, nous considérons qu’il n’est pas envisageable de faire reposer le contrôle d’accès sur un seul mécanisme et là encore, les approches et les modèles permettant d’associer différents mécanismes de contrôle d’accès manquent. De plus, les modèles de répartition de ces mécanismes sont quasiment inexistants. Enfin, si déjà les protocoles d’évaluation des performances manquent pour les systèmes de protection homogènes (par exemple basés exclusivement sur SELinux), ils sont encore plus inexistants dans le cadre des systèmes répartis de contrôle d’accès hétérogènes où l’on voudra associer et répartir différents mécanismes. D’autre part, nous avons noté le manque de mécanisme de contrôle d’accès obligatoire sur les systèmes Windows capable d’appliquer des propriétés de sécurité que nous avons définies au début de ce chapitre. La nécessité de l’implantation d’un tel mécanisme dans les systèmes Windows est extrêmement grande puisque c’est, encore à ce jour, le système le plus utilisé en tant que station de travail. Les chapitres suivant traitent de façon uniforme de ces différents points en s’intéressant à la fois à la protection des systèmes d’exploitation hétérogènes, à l’association des différents mécanismes de protection, à leurs répartitions et aux méthodes et protocoles d’évaluation des performances dans ces systèmes répartis de protection. 532.4. CONCLUSION 54Chapitre 3 Modélisation et répartition d’observateurs Les exemples que nous avons détaillés dans l’introduction de notre étude (voir la section 1.3), ont mis en avant que les attaques sur les systèmes d’exploitation sont de plus en plus complexes. Pour les prévenir de manière efficace, c’est-à-dire sans nuire au fonctionnement du système, il faut connaître le scénario complet de ces attaques. La connaissance de ce scénario complet passe par le contrôle des interactions directes au sein du système. Pour contrôler ces interactions, la mise en place d’un observateur, capable de détourner le flux d’exécution régulier et de prendre des décisions en fonction d’une politique de sécurité, est essentielle. Ce modèle de protection, basé sur deux éléments complémentaires, s’appuie pleinement sur la définition d’un Policy Enforcement Point et d’un Policy Decision Point. Le PEP est le moyen utilisé par l’observateur pour détourner le flux d’exécution. On peut citer par exemple les LSM, présents nativement sur les systèmes Linux, qui offrent la possibilité au module de sécurité de détourner les flux d’exécution réguliers. Le PDP est la partie de l’observateur qui prend les décisions. Dans le cadre d’un mécanisme contrôlant les accès, [Anderson, 1980] a défini un observateur particulier : le moniteur de référence. Le moniteur de référence est donc un observateur prenant des décisions d’accès au regard d’une politique de sécurité. Mais le seul contrôle des interactions directes ne suffit pas à protéger le système contre les scé- narios complets. En effet, un observateur ne traitant que les interactions directes n’est pas capable de traiter un scénario complet d’attaque. Il faut pour cela utiliser d’autres observateurs capables de reconstruire le scénario complet. Pour ce faire, un premier type d’observateur doit être capable d’horodater chaque interaction directe dans le but de les situer les unes par rapport aux autres. Ensuite, il faut être capable d’associer les différents observateurs nécessaires à la reconstruction du scénario pour qu’ils puissent s’échanger non seulement les requêtes, mais aussi les décisions d’accès qu’ils prennent. Pour prendre sa décision, un observateur s’appuie sur une politique de sécurité. Cette politique peut être une base de données contenant les éléments à bloquer, des signatures à détecter, ainsi que les interactions directes à contrôler. Comme nous avons besoin en premier lieu d’un observateur capable de gérer les interactions directes, nous allons proposer un modèle de politique de sécurité générique pour contrôler les accès directs des processus sur les ressources. Nous appliquerons plus spécifiquement cette politique pour les systèmes Windows car, comme nous l’avons montré au cours de l’état de l’art 2.4, c’est sur ce système qu’il y a le plus de manque. Dans le but d’obtenir une politique de sécurité générique pour les systèmes Windows, nous proposons une désignation des ressources pour ces systèmes. Le langage pour la politique directe supporte à la fois PBAC et DTE. Dans le modèle PBAC, les ressources sont identifiées par leur chemin complet dans l’arborescence du système de fichiers, 553.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS comme le fait grsecurity. Pour PBAC, notre désignation des ressources permet une politique portable car indépendante de la localisation des ressources. Dans le modèle DTE, les ressources sont identifiées par des types et des domaines. Cette méthode supporte mieux l’hétérogénéité puisque la politique pourrait aisément être projetée sur Linux comme sur Windows. Nous étudierons ensuite comment mettre en œuvre un PEP pour Windows. Ainsi grâce à ce PEP et à la politique générique, nous pouvons proposer un PDP qui gère les interactions directes et offre ainsi un moniteur de référence pour les versions récentes de Windows, à savoir Windows 7. 3.1 Définition d’un observateur pour les systèmes d’exploitation Linux et Windows Cette section s’intéresse à la définition générique de la notion d’observateur. Pour que l’observateur puisse fonctionner sur le système, cela passe par la mise en place de deux éléments : — un PEP (Policy Enforcement Point, point d’application de la politique) : c’est-à-dire un moyen pour détourner le flux d’exécution régulier du système ainsi que pour appliquer les décisions prises par l’observateur ; — une politique de sécurité utilisée par le PDP (Policy Decision Point, un point de décision), qui définit les traitements à effectuer. Dans le cadre d’un observateur contrôlant les accès au sein d’un système, l’application de la politique de sécurité se fait par un observateur particulier nommé moniteur de référence. Mais pour que ce contrôle soit efficace, il est nécessaire que le moniteur puisse observer l’ensemble du système. Pour cela, l’observateur se place de manière naturelle en espace noyau. L’espace noyau est une protection matérielle qui a été mise en place au niveau des processeurs. Cette protection se nomme anneau de protection (ou rings). L’objectif de cette protection est d’établir des niveaux de confiance pour l’exécution de code. Les systèmes d’exploitation modernes n’utilisent que deux anneaux de protection : l’anneau 0 et l’anneau 3. L’anneau 0 est un anneau de protection considéré de confiance, c’est-à-dire que le code qui s’exécute n’est pas supervisé. Cela se traduit par la possibilité de réaliser des tâches privilégiées et de pouvoir utiliser toutes les instructions du processeur. C’est dans cet anneau de protection que s’exécute le noyau du système d’exploitation. L’anneau de protection 3 est un anneau de protection où s’exécute du code qui n’est pas considéré comme sûr. Cela se traduit par la possibilité d’utiliser un jeu d’instructions plus restreintes au niveau du processeur. Les systèmes d’exploitation modernes utilisent l’anneau de protection 3 pour exécuter les applications. Dans ce mode, les interactions des applications sont supervisées et, par conséquent, pour réaliser une opération spécifique, l’application doit passer par un appel système, qui lui sera contrôlé et exécuté par le noyau. C’est dans le but de pouvoir réaliser des tâches privilégiées que nous plaçons l’observateur en espace noyau. Il pourra ainsi contrôler tout le système sans restriction. Les opérations d’entrée/- sortie n’étant possibles que par les appels système, le détournement des appels systèmes permet de contrôler toutes les interactions entre des processus sur les ressources. Sur les systèmes d’exploitation Windows, pour exécuter du code en espace noyau, il faut que ce code soit directement dans le noyau ou soit exécuté par un pilote de périphérique (un driver). Dans le cas de Windows, comme il n’est pas possible de recompiler le noyau pour y inclure nos modifications, nous sommes contraints de mettre en place un driver. Sur les systèmes d’exploitation Linux, ce contrôle peut être effectué soit par un module noyau, soit par une modification du code du noyau, puisque ce dernier est modifiable. La figure 3.1 illustre le placement de l’observateur de manière générale vis-à-vis d’un appel système fait par un processus. Lorsqu’un processus effectue une interaction sur une ressource, celle-ci passe par un appel système (flèche 0). Dans un premier temps, l’observateur doit détourner 563.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS le flux d’exécution (flèche 1). Il prend ensuite une décision au regard de sa politique de sécurité (flèche 2). Dans le cas où l’interaction est autorisée, il va exécuter l’appel système et récupérer le retour de celui-ci (flèche 3). L’observateur peut aussi réaliser des traitements spécifiques sur le retour de l’appel. Pour finir, et quelle que soit le traitement que l’observateur a réalisé, il renvoie une réponse au processus ayant réalisé l’interaction (flèche 4). Un observateur est donc composé d’un mécanisme de détournement appelé Policy Enforcement Point et d’un mécanisme de prise de décision nommé Policy Decision Point. FIGURE 3.1 – Schéma du placement de l’observateur 3.1.1 Éléments de base de la protection système Pour définir de façon générique la notion d’observateur, nous allons nous appuyer sur les deux scénarios d’attaque que nous avons présentés en introduction de ce mémoire (voir les figures 1.2 et 1.3). De plus, nous allons préciser les éléments de base de la protection système, non seulement pour un observateur mais aussi pour l’écriture de la politique de sécurité. Dans ces deux scénarios, nous observons une interaction directe commune : l’écriture par un navigateur web d’un fichier malveillant comme décrit par la figure 3.2. FIGURE 3.2 – Écriture d’un fichier malveillant par Firefox : Windows et Linux Cette interaction est composée de trois éléments. Le premier élément est le sujet, correspondant au processus Firefox, le second élément est l’objet, le fichier malware.exe sur Windows et exploit.sh sur Linux, et une opération élémentaire write. Cette interaction directe est représentée de la manière suivante : F irefox −−−→ write malware.exe 573.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS Définition 3.1.1 Un sujet Un sujet s est une entité active du système qui réalise une opération élémentaire. Sur les systèmes Windows, l’ensemble des sujets S est composé des processus, des services, des services système et des drivers. Sur les systèmes Linux, ce sont exclusivement les processus. En nous appuyant sur la figure 3.2, le processus nommé Firefox.exe est le sujet pour les systèmes Windows alors qu’il est nommé /usr/bin/firefox sur Linux. Sur les systèmes Windows, les processus sont représentés par leur nom relatif et non par leur chemin complet. Définition 3.1.2 Un objet Un objet o est une entité du système qui est la cible d’une opération élémentaire. L’ensemble des objets O est composé des ressources classiques (fichiers, répertoires, socket, etc.), des éléments du registre (les ruches, les clés, les valeurs et des données) ainsi que de l’ensemble S des sujets. Dans la figure 3.2, le fichier malware.exe est un exemple d’objet pour Windows et le fichier exploit.sh l’est pour Linux. Définition 3.1.3 Une classe Une classe class est utilisée pour caractériser un objet. Elle permet de spécifier le type d’objet, et par conséquent, les opérations élémentaires possibles sur cet objet. L’ensemble Class constitue l’ensemble des classes autorisées sur le système. La classe permet ainsi de différencier les opérations élémentaires réalisées sur un fichier des opérations réalisées sur un tube. Les objets malware.exe et exploit.sh sont de la classe fichier. Définition 3.1.4 Une opération élémentaire Une opération élémentaire oe est une opération de base effectuée par un sujet sur un objet (ou sur un sujet) lors de l’exécution d’un appel système. Par exemple sur Linux, l’ouverture d’un fichier met en œuvre deux opérations élémentaires. L’opération élémentaire getattr vérifie les droits sur le fichier et l’opération élémentaire open retourne un descripteur de fichier. Définition 3.1.5 Un appel système Un appel système est une fonction du noyau permettant d’effectuer des opérations d’entrée/sortie, de communication, etc. Toutes ces opérations sont considé- rées comme sensibles au niveau du système d’exploitation. C’est pour cette raison qu’elles sont réalisées par le noyau. Lors d’un appel système, une opération élémentaire est réalisée. Pour pouvoir réaliser l’opération élémentaire write, le processus Firefox.exe utilise une fonction nommée WriteFile(), présente en espace utilisateur. Elle correspond à un appel système en espace noyau qui se nomme NtWriteFile(). C’est cette fonction qui réalise l’opération d’entrée/sortie sur le fichier. Nous obtenons la même chose sous Linux de manière complètement analogue, seuls les noms des fonctions sont différents. La figure 3.3 détaille ce cheminement d’une écriture dans un fichier. La définition des notions de sujets, d’objets et d’opérations élémentaires, nous permettent de formaliser la notion d’interaction. Définition 3.1.6 Une interaction Une interaction it, s −→oe o est un triplet composé d’un sujet, d’un objet et d’une opération élémentaire. Elle est notée it = (s, o, oe) Dans notre exemple 3.2, l’interaction est composée du sujet Firefox.exe, de l’opération élémentaire écriture et de l’objet malware.exe. Nous pouvons affiner cette définition d’interaction par l’ajout de la notion directe. Cela signifie que le sujet exécute directement un appel système sur l’objet. 583.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS FIGURE 3.3 – Écriture détaillée d’un fichier malveillant par un navigateur web Définition 3.1.7 L’observateur Pour observer une interaction directe, il est nécessaire de mettre en place un mécanisme capable d’intercepter les opérations élémentaires. Pour cela, cette interception est réalisée par un observateur au niveau des appels système. Cet observateur doit détourner le flux d’exécution. La figure 3.4 montre le placement de l’observateur en amont de l’appel système, donc en espace noyau. En se plaçant en amont de l’appel système, l’observateur est capable de bloquer le flux d’exécution dans le cadre de l’application d’une politique de protection. Il peut aussi traiter le retour de l’appel système. Il existe différents types d’observateurs : les moniteurs de référence, qui contrôlent les interactions, les auditeurs, qui génèrent des traces en fonction des interactions, les vérificateurs d’inté- grité, etc. FIGURE 3.4 – Placement de l’observateur pour détourner le flux d’exécution Nous proposons le placement d’un observateur en espace noyau car nous voulons avoir un observateur capable de contrôler toutes les interactions qui se passent sur le système, tout en se protégeant des potentielles attaques des processus. 593.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS Définition 3.1.8 Détournement de flux d’exécution Le détournement du flux d’exécution est une opération réalisée le plus souvent en espace noyau dans le but de contrôler les interactions réalisées par le système. Pour réaliser cela, il faut, soit utiliser un mécanisme prévu dans le système d’exploitation comme les LSM, soit modifier directement le noyau. Lors de sa prise de décision, l’observateur a la possibilité d’enregistrer sa décision dans le but d’assurer la traçabilité des interactions qu’il observe. Pour cela, il génère une trace. Définition 3.1.9 Trace Une trace tr est générée par l’observateur lors d’une observation, elle contient l’interaction it décrivant l’opération. Elle peut aussi contenir d’autres informations renseignant sur l’état du système comme un identifiant de trace ou un horodatage que l’on peut noter d. tr = (d, s, o, oe). Pour réaliser un traitement spécifique vis-à-vis d’une observation, l’observateur s’appuie sur une politique de sécurité. Définition 3.1.10 La politique de sécurité Un observateur a besoin d’une politique de sécurité dans le but de réaliser des traitements spécifiques. Une politique de sécurité peut être de la forme : politique d’audit, politique de détection, politique de protection, etc. Une politique est constituée d’un ensemble de règles. Une règle permet à l’observateur d’exécuter un traitement spécifique lorsqu’il intercepte une interaction. Il existe plusieurs types de règles : règles d’audit, règles de détection, règles de protection, etc. Dans le cas d’une politique de protection, le traitement est le suivant : si l’interaction courante ne correspond pas à une règle d’autorisation dans la politique de sécurité, alors l’observateur l’interdira. La figure 3.5 illustre le fonctionnement du système avec la mise en place d’un observateur ainsi que d’une politique de sécurité. Nous avons vu que les deux systèmes d’exploitation étudiés, Windows et Linux, possèdent une symétrie au niveau de leur fonctionnement. Grâce à cette symétrie, nous pouvons obtenir un placement générique pour notre observateur commun au deux systèmes. FIGURE 3.5 – Schéma global de détournement des flux pour les deux systèmes Chaque interaction est détournée par l’observateur en espace noyau qui exécute un traitement conforme à sa politique de sécurité. Dans le cas où l’interaction n’est pas bloquée, l’appel système se poursuit. 603.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS 3.1.1.1 Modélisation du système observé Nous venons de définir les éléments clés d’un système : les sujets, les objets, les opérations élémentaires, etc. Grâce à ces définitions, nous allons pouvoir modéliser l’observation du système d’exploitation. Le système est constitué d’un ensemble S de sujets et d’objets O. Les sujets réalisent des opérations élémentaires sur les objets. Ces opérations se traduisent par la définition d’une interaction it = (s, o, oe). L’ensemble des interactions possibles sur un système est représenté par l’ensemble IT. Nous pouvons noter que lors d’un appel système, une opération élémentaire oe est réalisée entre l’appelant (le sujet) et la cible (l’objet ou le sujet). Ainsi lors d’un appel système, l’observateur reconstruit une interaction directe. Un observateur détourne un appel système pour prendre une décision et reconstruit une interaction. Cette décision s’appuie sur une politique de sécurité P ol, qui est composée d’un ensemble de couples : traitement_observateur et it formant les règles d’accès. On obtient alors, pour une politique P ol donnée, P ol = P(traitement_observateur, it). À partir de l’interaction observée et d’une politique de sécurité, l’observateur prend une décision en utilisant la fonction Dec : Dec(it, P ol) 7→ (decision, tr) où tr est une trace générée par l’observateur comme le détaille l’algorithme 1. Algorithm 1 Prise de décision de l’observateur Require: P ol Require: it d ← Horodatage() decision ← RechercheDansP olitique(it, P ol) tr ← GenererT race(d, decision, it) return decision, tr L’observateur s’appuie sur deux fonctions : RechercheDansP olitique, fonction qui recherche l’interaction observée dans la politique pour en extraire une décision et GenererT race, qui construit une trace. L’algorithme 2 détaille le mécanisme de recherche d’une interaction it dans une politique P ol de sécurité. Une politique P ol est composée d’un ensemble de couples : interaction it et traitement traitement_observateur. Lorsque l’interaction n’existe pas dans la politique, la fonction retourne un traitement par défaut traitement_def ault qui sera spécifié en fonction du type d’observateur voulu. 613.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS Algorithm 2 Recherche dans la politique Require: P ol Require: it trouve ← F alse for all r ∈ P ol ET trouve == F alse do if Satisf ait(it, r) then trouve ← T rue end if end for if trouve == T rue then decison ← r.traitement_observateur else decision ← traitement_def ault end if return decision Enfin, la deuxième fonction sur laquelle s’appuie l’observateur est la fonction générant une trace tr, détaillée par l’algorithme 3. Elle prend en paramètre l’horodatage, la décision ainsi que l’interaction. Elle ajoute à ces trois éléments un identifiant unique de trace. Algorithm 3 Génération d’une trace Require: d (horodatage) Require: decision Require: it id ← CurrentId() tr ← (d, id, it, decision) return tr On peut, à partir de tous ces éléments, modéliser le système observé, comme l’ensemble des sujets, des objets, des interactions auxquels on ajoute une politique de sécurité et un observateur : Systemobserve = (S, O, IT, P ol, Observateur) 3.1.1.2 Mode de sécurité Un observateur possède 3 modes de sécurité. Un mode de sécurité est le comportement de l’observateur vis-à-vis d’une requête qu’il reçoit. Par construction, ces 3 modes de sécurité sont mutuellement exclusifs, c’est-à-dire qu’un observateur ne peut pas être simultanément dans deux de ces modes. Requête/Réponse Le premier mode de sécurité est le mode requête/réponse. Ce mode est illustré par la fi- gure 3.6. Classiquement, lorsque l’observateur reçoit une requête, il va fournir une réponse. Dans ce mode, l’observateur peut refuser l’appel, retranscrit sur le schéma par les pointillés. Il observe l’appel système et transmet la réponse de l’appel au système. On peut ajouter un comportement facultatif à ce mode qui est l’émission d’une alerte. Classiquement, ce mode est le mode protection (ou enforcing) que l’on retrouve dans les implantations telles que SELinux ou grsecurity. Lorsque l’observateur reçoit une requête, il autorise ou non l’interaction et répond à l’appelant (c’est-à-dire : l’observateur se comporte comme un 623.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS FIGURE 3.6 – Mode de sécurité : requête/réponse de l’observateur intermédiaire entre le processus et l’appel système). Si l’interaction est refusée, une alerte sera enregistrée dans un fichier d’audit. Évidence Le second mode de sécurité est le mode évidence. Ce mode est illustré par la figure 3.7. Le fonctionnement se base sur deux étapes : lorsque l’observateur reçoit une requête, il transmet la requête à l’appel système et peut éventuellement émettre une alerte. Dans ce mode de fonctionnement, l’observateur exécute toujours l’appel système. FIGURE 3.7 – Mode de sécurité : évidence On retrouve ce comportement dans les systèmes de détection d’intrusion (Intrusion Detection System). Lorsque l’observateur reçoit une requête qui correspond à une des règles, il va lever une alerte (ou générer une trace), sinon il ne fait rien. On retrouve aussi ce comportement pour les mécanismes de protection qui sont placés en mode détection aussi appelé permissif. Notification Le troisième mode de sécurité est le mode notification. Ce mode est illustré par la figure 3.8. Le fonctionnement de ce mode repose sur le fait que l’observateur va envoyer une notification sans avoir reçu d’évènement spécifique. FIGURE 3.8 – Mode de sécurité : notification Il peut s’agir d’un observateur qui par exemple envoie un signal à un processus qui consomme trop de temps processeur. 633.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS 3.1.2 Définition d’un observateur : le moniteur de référence Nous allons, dans cette partie, décrire plus en détail notre modèle de moniteur de référence. Ce modèle est assez générique pour être appliqué sur les différents systèmes. Le moniteur de référence est chargé d’appliquer le traitement présent dans la politique de sécurité au regard de l’interaction courante. Dans le cadre de notre moniteur de référence, les traitements possibles sont : autoriser, refuser et auditer. Si ce modèle couvre les approches Unix existantes, nous montrerons qu’il peut être implanté sur différents systèmes. Nous proposons plus spécifiquement une mise en œuvre pour Windows puisque le manque se situe à ce niveau. Le moniteur de référence est un observateur particulier qui peut empêcher l’interaction, il est donc en mode de sécurité requête/réponse. Cela se traduit de la manière suivante : — la requête : c’est une demande d’accès d’un sujet sur un objet du système ; — la réponse : c’est la décision du moniteur de référence pour la demande d’accès. Elle peut être de deux types : autorisation ou refus. À la différence des moniteurs existants sur Linux, notre moniteur de référence est plus gé- nérique en supportant des politiques de sécurité de type PBAC et des politiques DTE, que nous détaillerons par la suite. Notre moniteur de référence propose 3 modes d’utilisation : — désactivé : aucun contrôle n’est réalisé et le flux d’exécution n’est pas détourné ; — actif : le flux d’exécution est détourné et les décisions permettent d’empêcher les interactions. En cas de refus, une alerte est levée par la génération d’une trace. C’est le mode protection ; — permissif : le flux d’exécution est détourné, le moniteur de référence cherche dans la politique et prend une décision, mais il n’empêche pas l’interaction. Ce mode permet de créer plus facilement la politique de contrôle d’accès et de la valider sans nuire au fonctionnement du système. Dans ce mode, par défaut, tous les accès, qu’ils soient autorisés ou non, peuvent être enregistrés dans un fichier d’audit. C’est le mode évidence. La figure 3.9 illustre les différents traitements que réalise notre moniteur de référence. Pour décrire cette architecture logicielle, nous allons dérouler un cas pratique en détaillant chacune des étapes réalisées au sein du moniteur de référence. Nous séparerons en trois parties ce cheminement : les opérations réalisées durant une phase de pré-décision, c’est-à-dire avant de prendre une décision pour savoir si l’appel système sera exécuté ou non, une phase de décision, et les opérations réalisées en post-décision, c’est-à-dire une fois que la décision a été prise. 643.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS FIGURE 3.9 – Schéma du moniteur de référence 3.1.2.1 Phase de pré-décision La première opération, qui n’est pas directement du ressort du moniteur de référence et qui consiste à détourner le flux d’exécution régulier, correspond à la flèche 1. Nous décrirons diffé- rentes méthodes de détournement pour les systèmes Windows dans la section 3.3. Cette partie agit comme les LSM et propose des interfaces de connexion à notre moniteur de référence. Ainsi, ce dernier n’a pas besoin de savoir comment est réalisé le détournement du flux d’exécution. Prétraitement Une première phase notée 2.1 regroupe un ensemble d’opérations de prétraitement. Dans cette phase, le moniteur attribue un identifiant unique de trace et ajoute un horodatage. Nous simplifierons les notations en considérant que l’élément d contient à la fois l’horodatage et un identifiant unique. Ces deux informations serviront à reconstruire l’activité globale du système pour trouver les scénarios complets d’attaque. La figure 3.10 illustre ce mécanisme. FIGURE 3.10 – Construction de la trace par le moniteur de référence : ajout de l’horodatage 653.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS Le moniteur ajoute ainsi des informations qui ne serviront pas directement à la prise de décision mais qui se révèlent utiles pour construire/analyser les activités du système. Dans notre cas, nous avons choisi de prendre les PID et PPID du sujet, illustré par la figure 3.11. FIGURE 3.11 – Construction de la trace par le moniteur de référence : ajout d’information pour l’historique des processus Notre moniteur de référence doit ensuite calculer les éléments qui vont lui servir à la prise de décision. Pour cela, il doit récupérer le sujet, l’objet, la classe de l’objet et l’opération élémentaire demandée par le sujet sur l’objet, illustré par la figure 3.12. FIGURE 3.12 – Construction de la trace par le moniteur de référence : translation en une interaction Nous calculons dans cette première phase l’interaction requise qui permettra au moniteur d’autoriser ou de refuser l’appel système. Dans le cas du modèle de protection PBAC, le moniteur translate les sujets et objets vers leurs noms absolus (voir les détails ultérieurs). Les opérations élémentaires sont calculées sous la forme d’ACL étendues comme définies dans la politique. Pour le modèle de protection DTE, il est nécessaire d’obtenir les contextes de sécurité incluant les types pour les sujets et objets. Ils sont donc calculés dans cette phase. Les opérations élémentaires sont elles directement dérivées des appels système. A la fin de cette phase, le moniteur possède une interaction it décrivant l’interaction à contrôler. Tout le cheminement de la construction de la trace effectuée en phase de prétraitement est illustré par la figure 3.13. 663.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS FIGURE 3.13 – Construction de la trace par le moniteur de référence : schéma global L’algorithme de construction de la trace par le moniteur de référence est défini par l’algorithme 4. Il prend en entrée l’appel système composé d’un processus et d’un objet. Il commence par horodater la trace puis l’enrichit en ajoutant les PID et PPID. Enfin, il transforme l’appel système en une interaction directe. Algorithm 4 Construction de la trace par le moniteur de référence Require: AS : processusobjet tr ← processus, objet d ← horodatage() tr ← d, tr pid, ppid ← enrichissement() tr ← pid, ppid, tr it ← translation(as) tr ← modif ication_trace(tr, it) return tr L’algorithme de translation de l’appel système en une interaction directe est illustré par l’algorithme 5. Il prend en entrée l’appel système et commence par modifier le processus et l’objet pour coller au modèle de protection (PBAC ou DTE). Puis, il va faire correspondre l’appel système à une opération élémentaire pour construire une interaction directe. La fonction ObtenirOE() retourne l’opération élémentaire associée à l’appel système. 673.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS Algorithm 5 Translation de l’appel système en interaction Require: AS : processusobjet s ← Sujet(processus) o ← Objet(objet) oe ← ObtenirOE(AS) it ← (s, oe, o) return it 3.1.2.2 Phase de décision Une fois que le moniteur de référence a toutes les informations nécessaires, il est capable de prendre une décision, qui correspond à la phase 2.2 de notre schéma. Pour ce faire, il va aller rechercher dans la politique de sécurité l’interaction requise. 1. Si l’interaction ne satisfait pas la politique, alors le moniteur considère que l’appel système doit être refusé et qu’il faut auditer ce refus. 2. Si l’interaction est présente dans la politique, alors le moniteur effectue le traitement correspondant. Le moniteur génère une trace lors des interdictions dans le but d’assurer la traçabilité des opérations effectuées sur le système. Lorsque les opérations sont autorisées par la politique de sécurité, il n’est pas nécessaire de générer de trace. 3.1.2.3 Phase de post-décision audit Après la phase de décision, le moniteur entre dans la phase d’audit. Dans cette phase, il va pouvoir enregistrer les éléments de l’interaction : sujet, objet, opération élémentaire. De plus, nous avons récupéré lors de la phase de prétraitement une date et un identifiant unique, ainsi que des informations secondaires. Nous allons nous servir de tous ces éléments pour construire une trace suffisamment précise pour décrire l’interaction. Cette phase est obligatoire lorsque le moniteur est mis en mode permissif. détection et protection Lorsque le moniteur est en mode permissif, l’opération élémentaire se poursuit c’est-à-dire que l’appel système est toujours exécuté. Lorsque le moniteur est en mode actif, en cas de refus explicite, l’interaction ne se poursuit pas et l’appel système n’est pas exécuté. Si l’interaction est autorisée, alors le moniteur va exécuter l’appel système (flèche 3). Il s’agit du mode protection. post-traitement La phase de post-traitement permet d’effectuer des traitements après l’exécution de l’appel système ou en cas de refus. Dans le cadre du retour de l’appel système, le moniteur peut mettre à jour la trace d’audit en spécifiant par exemple le code de retour de l’appel système : s’il a réussi, échoué, quel code d’erreur, etc. La mise à jour de la trace passe aussi par l’inscription de la date de retour de l’appel système. Ainsi, en traitant les différentes traces, on peut connaître les sujets ayant eu accès en même temps à une ressource et ainsi contrer les attaques de type race condition, en analysant les dépendances causales entre interactions [Rouzaud-Cornabas, 2010]. Lorsque l’interaction a été refusée, le moniteur peut notifier les utilisateurs en fonction de la gravité de l’opération élémentaire. Par exemple, il peut envoyer un message directement depuis l’espace noyau pour déclencher une alerte. 683.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS retour du moniteur La dernière phase consiste à retourner le résultat de l’appel système au processus appelant. Lorsque l’interaction a été autorisée et que l’appel système a été exécuté, on peut renvoyer les résultats retournés par l’appel système. Lorsque l’interaction a été refusée, il faut renvoyer un code d’erreur significatif au processus. Par exemple sous Windows, le moniteur peut renvoyer le code STATUS_ACCESS_DENIED et sous Linux -EACCES. Il est à noter que le post-traitement permet de modifier si besoin les résultats de l’appel. 3.1.3 Répartition des observateurs Nous avons présenté dans l’introduction de notre étude 1.3.3 qu’un seul observateur n’était pas suffisant pour protéger efficacement le système et qu’il était nécessaire de mettre en place plusieurs observateurs. La répartition des observateurs consiste à ajouter différents observateurs dans la chaîne de contrôle des interactions, c’est-à-dire des appels système. Définir la répartition nécessite de décrire la méthode d’association de deux observateurs, leurs localisations et leurs redondances. 3.1.3.1 Association Nous définissions deux modes d’association pour qu’une interaction puisse être traitée par deux observateurs. Ces deux modes sont mutuellement exclusifs. Deux observateurs ne peuvent pas être à la fois en mode cascade et en mode continuation, puisque comme nous le verrons, dans le premier mode, le premier observateur attend la réponse du second, ce qui n’est pas le cas dans le second mode. Cascade Le premier mode est le mode cascade. Ce mode est illustré par la figure 3.14. Dans ce mode, le premier observateur reçoit la requête et la transmet au second observateur. Le second observateur renvoie la réponse au premier observateur qui renvoie ensuite une réponse à l’appelant. FIGURE 3.14 – Mode d’association : cascade Ce mode de fonctionnement a été, par exemple, mis en place dans le défi ANR [ANR, 2009] par l’utilisation combinée de SELinux et de PIGA. Il permet d’additionner les contrôles des deux observateurs. Continuation Le second mode est le mode continuation. Ce mode est illustré par la figure 3.15. Dans le mode continuation, le premier observateur n’attend pas la réponse du second. Il effectue son traitement et transmet ensuite, si nécessaire, la requête au second. Ce mode peut être illustré en donnant une priorité dans les contrôles d’accès. Le premier contrôle est prioritaire et décide seul d’interdire/autoriser l’accès ou bien de transmettre la demande au second mécanisme. 693.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS FIGURE 3.15 – Mode d’association : continuation 3.1.3.2 Localisation Nous avons défini les modes de sécurité ainsi que les modes d’association possibles pour les observateurs. Nous allons maintenant détailler les modes de localisation, c’est-à-dire la place d’un observateur au sein de différentes architectures. Colocalisée Le premier mode concerne un observateur localisé sur la même machine que le client. Ce mode est illustré par la figure 3.16. FIGURE 3.16 – Mode de localisation : colocalisé Ce mode est principalement utilisé par les mécanismes de contrôle d’accès obligatoire : SELinux, grsecurity, etc. Distante Le second mode de répartition possible est d’avoir un observateur distant. Ce mode est illustré par la figure 3.17. Dans ce mode, les requêtes ne sont pas transmises localement, mais envoyées depuis un client vers un nœud distant. Nous avons dans ce schéma une relation 1 : 1, c’est-à-dire qu’à chaque nœud, nous associons un observateur spécifique sur une machine distante. FIGURE 3.17 – Mode de localisation : distant Ce mode peut être illustré par le fonctionnement en mode client/serveur du programme de gestion des traces système (syslog-ng). Le serveur de centralisation des logs reçoit les logs depuis tous les nœuds distants. 703.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS Parallèle Ce troisième mode de répartition est différent du précédent. Le mode distant associe à chaque nœud une machine hébergeant un observateur, ce qui pose clairement un problème de dimensionnement du système réparti. Dans le mode parallèle, une même machine est capable d’héberger plusieurs observateurs qui s’exécutent en parallèle. Cependant, chaque observateur n’est associé qu’à un seul nœud distant. Ce mode est illustré par la figure 3.18. S’il est difficile de qualifier ce modèle, on peut le noter n : 1(||) au sens que n nœuds peuvent être traités en parallèle par 1 machine. FIGURE 3.18 – Mode de localisation : distant avec plusieurs nœuds et plusieurs observateurs Partagée Dans le mode partagé, au lieu d’avoir une relation 1 : 1 entre les nœuds et les observateurs, la relation se note en n : 1(p). Cela signifie qu’un observateur est partagé par plusieurs nœuds distants. Ce mode est illustré par la figure 3.19. FIGURE 3.19 – Mode de localisation : distant avec plusieurs nœuds et un seul observateur 3.1.3.3 Redondance Dans les architectures distribuées, il est nécessaire d’assurer la disponibilité des services. Dans le cas qui nous intéresse, l’observateur est un élément vital qu’il faut pouvoir redonder. Diffusion Le premier mode de redondance est le mode diffusion. Dans ce mode, le nœud envoie simultanément les requêtes à (au moins) deux observateurs. Il doit ainsi traiter les deux réponses des 713.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION LINUX ET WINDOWS observateurs. Ce mode est illustré par la figure 3.20. Ainsi, si un des deux observateurs ne répond plus, le nœud n’est pas obligatoirement bloqué puisqu’il peut obtenir une réponse du second observateur. Dans le cas de fautes byzantines, on peut imaginer au moins trois redondances (R1, R2, R3) avec un vote majoritaire. FIGURE 3.20 – Mode de redondance : diffusion des requêtes par le nœud Maître-Esclave Le second mode de redondance est le mode maître-esclave. Dans ce mode, ce sont les observateurs qui se communiquent les requêtes envoyées par le nœud au serveur maître. Nous avons pris comme exemple l’observateur maître qui fait suivre la requête. Ainsi, les deux observateurs possèdent tous les deux toutes les requêtes envoyées. Ce mode de fonctionnement est illustré par la figure 3.21. Lorsque l’observateur maître ne répond plus, le nœud se connecte à l’observateur esclave. FIGURE 3.21 – Mode de redondance : architecture de la forme maître-esclave 3.1.3.4 Discussion Nous venons de détailler les différents modes d’association, de localisation et de redondance des observateurs. Par la définition des modes d’association, nous modélisons l’utilisation combinée de deux observateurs. Dans le mode en cascade, le premier observateur a un rôle primordial dans la chaîne de traitement des requêtes puisque c’est lui qui doit envoyer les requêtes au second observateur et attendre la réponse. Il est ainsi possible de corréler, au niveau du premier observateur, les dé- cisions prises par les deux observateurs. Cependant, dans ce mode de fonctionnement, le premier observateur doit attendre une réponse du second observateur, ce qui peut réduire les performances du système. Dans le second mode, le premier observateur n’attend pas la réponse du second. Il effectue son traitement et transmet ensuite, si nécessaire, la requête au second. Ce mode de fonctionnement évite le blocage du premier observateur attendant la réponse du second. Cependant, il n’est plus possible de corréler les réponses des observateurs au niveau du premier. 723.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT Les modes de localisation adaptent les modèles des systèmes répartis aux observateurs. À partir du mode distant, nous avons spécialisé l’approche de répartition. Ainsi, par la définition des modes parallèle et partagé, nous avons centralisé les requêtes et les décisions prises par les observateurs. Avec une localisation distante et les deux cas particuliers (parallèle et partagé), il semble possible de réduire la charge de calcul des nœuds clients. De plus, avec les modes parallèles et partagés, il est possible de faire des corrélations entre les interactions des différents nœuds clients. Néanmoins, en déportant les observateurs sur une machine dédiée, nous introduisons des situations de pannes supplémentaires : les pannes sur le réseau et les pannes de la machine hébergeant l’observateur déporté. De plus, ce déport peut aussi entraîner une latence au niveau de la communication avec l’observateur puisque cette communication passe par un lien réseau. Pour réduire les pannes potentielles introduites par le déport de l’observateur, nous avons proposé un modèle de redondance. Nous considérons deux modes de fonctionnement. Le premier repose sur la diffusion des requêtes faites directement par le nœud. Le principal avantage de cette méthode est qu’elle permet de tolérer un grand nombre de situations de défaillance. Cependant, le nœud doit gérer les réponses envoyées par plusieurs observateurs, ce qui implique un calcul supplémentaire réalisé au niveau du nœud. Le second mode de fonctionnement propose un modèle maître-esclave. Dans ce mode de redondance, le nœud envoie les requêtes qu’à un seul observateur, le maître et c’est ce dernier qui transmet à l’observateur esclave. Cependant, lorsque l’observateur maître ne répond plus, c’est au nœud client de se connecter à l’observateur esclave, ce qui peut entraîner une latence importante, voir un blocage du nœud si l’observateur met trop de temps à répondre. Nous venons de donner une définition de la notion d’observateur pour les systèmes et une modélisation de la notion de la répartition des observateurs. Nous allons maintenant décrire la modélisation de la politique de sécurité sur laquelle se base l’observateur pour effectuer ces traitements. 3.2 Modélisation d’une politique de contrôle d’accès direct Une politique de sécurité définit les traitements à entreprendre par l’observateur, tels que : autoriser, refuser, auditer, détecter, etc. Dans le cadre d’une politique de sécurité ayant pour objet de faire du contrôle d’accès direct, nous avons vu dans l’état de l’art (voir en section 2.2.2), qu’il existe plusieurs modèles obligatoires. Nous avons choisi ici deux modèles de contrôle d’accès direct : le path-based access control et le domain and type enforcement. Nous proposons une grammaire commune à ces deux modèles. La création d’une politique de sécurité impose de nommer chaque ressource du système, que ce soit les processus, les fichiers ou les sockets par exemple. Nous allons expliquer pourquoi il est nécessaire de proposer un système de noms absolus indépendants de la localisation pour désigner les ressources. Grâce à ce système de nommage, nous pouvons générer des politiques de sécurité portables. Nous montrons l’usage pour les systèmes Windows. Nous définissons une grammaire commune supportant PBAC et DTE pour Windows. Nous présentons ensuite une étude des mécanismes de détournement pour Windows. 3.2.1 Grammaire de la politique Une politique de protection regroupe l’ensemble des interactions qui sont autorisées ou interdites. Ces règles peuvent être : — des règles de décision : autorise ou refuse les interactions ; — des règles d’audit : définit si l’interaction doit être auditée ; 733.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT ✞ ☎ 1 grammar gram_commune; 2 3 politique : (regle’\n’)*; 4 regle : regle_traitement|regle_transition; 5 6 regle_traitement : regle_decision|regle_audit; 7 regle_transition : role_transition|objet_transition; 8 9 regle_decision : autorise_interaction vecteur_acces; 10 regle_audit : audit vecteur_acces; 11 12 role_transition : autorise_role ’ ’ role ’ ’ role; 13 objet_transition : autorise_objet ’ ’ contexte ’ ’ contexte (’:’ classe)? ’ ’ contexte ; 14 15 vecteur_acces : contexte Delimiteurs_debut? (liste_operations_elementaires)+ Delimiteurs_fin? ; 16 liste_operations_elementaires : (’ ’|’\t’)* contexte(’:’ classe)? operations_elementaires ; ✝ ✆ Listing 3.1 – grammaire commune aux modèles de protection PBAC et DTE — des règles de transition : modifie l’état de la politique ou les contextes du système (sujet ou objet). Nous avons défini une grammaire commune pour l’écriture d’une politique de contrôle d’accès, que l’on retrouve dans le listing 3.1. Notons que cette grammaire ne propose aucun terminal. En effet, les terminaux sont propres à chaque modèle de protection. Nous spécifierons dans la suite de cette étude les terminaux pour les modèles PBAC et DTE. Nous allons maintenant détailler la grammaire. Les ressources du système (contextes) Nous avons distingué dans une interaction directe l’élé- ment sujet, qui réalise l’opération élémentaire, de l’élément objet. Dans la grammaire, il n’est pas nécessaire de distinguer ces deux éléments puisque les sujets et les objets sont des sous-ensembles de l’ensemble des contextes. C’est pourquoi nous regroupons ces deux notions au sein d’un même ensemble que nous appelons contexte. Définition 3.2.1 Un contexte identifie une ressource à l’aide d’un nom. On retrouve dans la littérature essentiellement deux méthodes pour nommer les ressources d’un système. La première méthode consiste à utiliser le chemin complet dans l’arborescence du système de fichiers, ce qui est fait dans le modèle PBAC utilisé par grsecurity 2.3.1.2 tandis que la seconde méthode est d’associer un label à la ressource pour la caractériser, ce qui est fait dans le modèle DTE, comme le fait SELinux (voir en section 2.3.1.1). On notera CS l’ensemble des contextes sujet et CO l’ensemble des contextes objet. La figure 3.22 illustre l’opération d’écriture faite par le processus Firefox.exe. Dans le modèle PBAC, ce dernier est représenté par son chemin complet C:\Program Files\Mozilla\Firefox.exe. Il réalise une écriture sur le fichier C:\Users\bob\Downloads\malware.exe. Nous pouvons faire de même pour les systèmes Linux, illustré aussi par la figure 3.22. La figure 3.23 illustre cette opération d’écriture d’un contexte sujet sur un contexte objet en utilisant le modèle DTE. Comme ce modèle associe des types ou des domaines aux ressources, nous associons au processus Firefox.exe le domaine domaine_firefox et au fichier malware.exe le type type_malware. Le principal avantage de ce modèle est la possibilité d’abstraire les ressources du système. Ainsi, il suffit d’associer le domaine domaine_firefox 743.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT FIGURE 3.22 – Nommage des ressources au format PBAC au processus /usr/bin/firefox et le type type_malware au fichier exploit.sh pour que la même figure illustre cette même opération sur un système Linux. FIGURE 3.23 – Nommage des ressources au format DTE Une politique de sécurité Une politique de sécurité est un ensemble de deux types de règles : les règles de traitement, qui définissent les actions de l’observateur vis-à-vis des interactions et les règles de transition, qui vont modifier l’état effectif de la politique. Règle de traitement Une règle de traitement est composée de deux éléments : un traitement spécifique à effectuer par l’observateur et un vecteur d’accès. Le tableau de vecteurs d’accès dé- termine les sujets, objets et les opérations élémentaires de l’interaction. Le traitement de l’observateur peut être : une autorisation explicite, un audit, une interdiction explicite, etc. Le vecteur d’accès détermine des opérations élémentaires entre un contexte sujet et un contexte objet. Règle de transition Une règle de transition va modifier l’état effectif de la politique ainsi que les contextes des sujets et des objets. Nous définissons deux règles de transition : 1. une transition entre deux rôles ; 2. une transition entre différentes ressources du système. La transition entre deux rôles permet de modifier l’ensemble des opérations élémentaires accessibles. Par exemple, un utilisateur ayant le rôle user aura besoin de changer de rôle pour effectuer des tâches d’administration. La figure 3.24 illustre les interactions autorisées pour les rôles user et admin. Les transitions entre les ressources du système interviennent lors de la création d’un processus. Dans ce cas, la transition provient du chargement du fichier en mémoire dans le but de créer un nouveau processus. Vecteur d’accès Un vecteur d’accès v représente un ensemble d’interactions directes à observer sur le système. Il est composé d’un contexte sujet, d’un contexte objet et d’une liste d’opérations élémentaires potentiellement regroupées par un ensemble associé à une classe. Soit cs ∈ CS, soit co ∈ CO, soit class ∈ Class et oe1, ..., oen ∈ OE, 753.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT role:user liste d’accès read write execute fichier 1 Accès Refusé Accès Autorisé fichier 2 read Accès Autorisé read fichier transition de rôle role:admin liste d’accès read write execute fichier 1 Accès Autorisé Accès Refusé fichier 2 read Accès Autorisé read fichier FIGURE 3.24 – Transition de rôle modifiant les accès possibles à certaines ressources du système alors v = (cs, co : class, {oe1, ..., oen}) Selon la figure 3.2 (présente au début de ce chapitre), pour une seule interaction sur un système Windows entre le contexte sujet firefox.exe et le contexte objet malware.exe on peut par exemple écrire un vecteur : v = (f irefox.exe, malware.exe : f ile, {write}) On peut factoriser un ensemble d’interactions entre deux contextes avec un seul vecteur de la façon suivante : v = (f irefox.exe, malware.exe : f ile, {create, setattr}) Cependant, nous verrons qu’il est préférable d’avoir des contextes précis (ici la règle s’applique à tous les sujets firefox.exe présents sur le système ce qui peut être acceptable pour une interdiction mais peu recommandé pour une autorisation) avec dans ce cas la nécessité que les noms soient indépendants de leurs localisations physiques afin de garantir la portabilité des politiques. 3.2.1.1 La portabilité des noms utilisés pour les contextes Dans notre grammaire, un contexte est un nom qui désigne aussi bien les sujets et les objets. Il est donc nécessaire que ces noms soient précis afin de contrôler finement chaque processus et chaque ressource du système. En même temps, ces noms doivent être les plus portables possibles. Le système de nommage sous Windows Sur les systèmes Windows, il n’existe pas de racine commune à l’espace de noms. Historiquement, les systèmes Windows sont installés sur la lettre du lecteur "C:" car les lecteurs "A :" et "B :" étaient utilisés pour les lecteurs de disquettes. Il est cependant possible d’installer le système sur un autre lecteur mais aussi d’avoir plusieurs partitions montées sur des lecteurs différents. Ainsi, le listing 3.2 montre sur sa première ligne le chemin classique pour l’exécutable de Firefox alors que la seconde ligne montre un chemin depuis un autre lecteur pour le même exécutable. ✞ ☎ 1 C:\Program Files\Mozilla\Firefox.exe 2 D:\Program Files\Mozilla\Firefox.exe ✝ ✆ Listing 3.2 – Deux chemins Windows différents désignant le même exécutable 763.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT Si l’on utilise le nom C:\Program Files\Mozilla\Firefox.exe désignant précisément l’exécutable Firefox concerné, ce nom n’est pas portable puisqu’il n’est pas correct sur un système où les programmes sont installés sur le système de fichiers D :. Pour résoudre ce problème, nous utilisons la notion de nom symbolique absolu indépendant de la localisation définie par [Hagimont et J.Mossière, 1996]. 1. Un nom symbolique, par exemple le fichier ./policy.24, correspond à un nom usuel qui est manipulé par les usagers. Ce nom usuel est associé à une localisation physique, sans que l’utilisateur n’ait besoin de la connaître. Ainsi le nom symbolique ./policy.24 est par exemple associé au numéro d’i-node 11274188 et au périphérique 19h/25d sous Unix. 2. Un nom absolu rend le nom symbolique unique c’est-à-dire qu’il désigne une seule ressource. Le nom absolu est par exemple /home/damien/policy.24 en opposition au nom relatif policy.24. 3. Un nom absolu indépendant de la localisation physique est un nom qui ne fait pas apparaître l’emplacement de stockage de la ressource. Cette solution est particulièrement efficace pour assurer la portabilité des noms. Pour atteindre ce but sur les systèmes Windows, nous allons abstraire le nom usuel pour rendre absolu et indépendant de la localisation le nom symbolique. Définitions Pour formaliser cette problématique de nommage sur Linux et sur Windows, nous allons défi- nir les deux notions importantes que sont nom et ressource. Définition 3.2.2 Ressource Une ressource est un identifiant interne au système utilisé pour manipuler des objets : par exemple, l’i-node d’un système de fichier. Définition 3.2.3 Nom Un nom est un moyen simple et usuel pour accéder à une ressource. Géné- ralement, le nom est représenté sous la forme d’une chaîne de caractères. Ainsi, une même ressource peut avoir plusieurs noms différents. Nous illustrerons cela dans la suite de cette partie. 3.2.1.2 Modélisation de la problématique des noms Nous allons maintenant montrer comment fonctionne le mécanisme de nom symbolique absolu indépendant de la localisation. Notre modélisation commence par définir deux éléments importants du système : les notions d’Emplacement physique et de Ressource. Définition 3.2.4 Emplacement physique Soit ephy un élément de l’ensemble Ephy regroupant les emplacements physiques. Concrètement, ephy correspond à un bloc de données sur le disque dur. Définition 3.2.5 Ressource Soit r une ressource du système, par exemple un fichier, appartenant à l’ensemble R, l’ensemble de toutes les ressources du système. Cette ressource r se caractérise par un ensemble d’emplacement physique. Nous noterons RSC la fonction qui associe à une ressource r un ensemble d’emplacement physiques. 773.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT ∀r ∈ R, RSC r 7→ e tel que e = {ephy1, .., epyhn} avec {ephy1, .., epyhn} ∈ Ephy Toute ressource du système possède, au moins, un élément dans l’espace d’arrivée Ephy. A contrario, tout élément de l’espace Ephy ne possède pas nécessairement un antécédent dans l’espace des ressources. Par exemple, lorsqu’un fichier est supprimé par le système par les fonctions classiques de suppression telles que rm, les données présentes sur le disque dur associées à ce fichier ne sont pas supprimées. Il faut, pour cela, utiliser des fonctions spécifiques. De plus, tout élément de Ephy qui possède un antécédent, ne possède qu’un seul et unique antécédent par la fonction RSC. Donc par définition, la fonction RSC est injective. Ceci est illustré par le schéma 3.25. Ressource Emplacement physique r ephy1 ephyn R E_phy e FIGURE 3.25 – Correspondance entre une ressource et les emplacements physiques En outre, chaque ressource du système possède un emplacement logique. Cet emplacement logique se caractérise sur le système par un chemin dans le système de fichiers. Une ressource peut posséder plusieurs emplacements logiques différents, grâce à des opérations de montage ou par la création de liens. Définition 3.2.6 Emplacement logique et chemins Nous noterons Elog la fonction qui associe à une ressource r un emplacement logique dans le système. Cette fonction renvoie un chemin complet de l’arborescence du système de fichiers. L’ensemble de tous les chemins complets possibles est noté Chemin. C’est cet emplacement logique qui est utilisé par l’utilisateur pour accéder à la ressource. ∀r ∈ R, Elog : r 7→ chemin avec chemin ∈ Chemin Pour qu’une ressource du système puisse être utilisée par un utilisateur, il est nécessaire qu’elle possède au moins un emplacement logique, c’est-à-dire un nom dans l’espace des noms logiques. Une ressource peut posséder plusieurs emplacements logiques grâce à des opérations de montage ou par la création de lien. Cette notion est illustrée par la figure 3.26. On obtient pour un fichier, une ressource correspond à l’i-node et un ensemble d’emplacement physique. Comme une ressource peut être désignée par plusieurs emplacements logiques, il est nécessaire de définir une nouvelle fonction capable d’uniformiser la description d’une ressource pour un utilisateur. 783.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT Ressource Emplacement logique r chemin_1 R E_log chemin_2 FIGURE 3.26 – Correspondance entre une ressource et les emplacements logiques Définition 3.2.7 Nom symbolique absolu indépendant de la localisation Nous définissons la fonction Nabs. Cette fonction associe à un emplacement logique d’une ressource un nom symbolique absolu indépendant de la localisation n abs r ∈ Nabs, où Nabs est l’ensemble des noms symboliques absolus indépendants de la localisation. Soit r ∈ R et soit chemin ∈ Chemin avec Elog : r 7→ chemin, alors Nabs : chemin 7→ n abs r Par définition, tout emplacement logique possède un seul et unique nom symbolique absolu indé- pendant de la localisation. A contrario, un nom symbolique absolu indépendant de la localisation possède au moins un emplacement logique. La fonction Nabs est donc surjective, illustrée par la figure 3.27. Emplacement logique chemin1 n^abs Chemin Nom symbolique absolu indépendant de la localisation chemin2 N^abs FIGURE 3.27 – Représentation de la fonction Nabs 793.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT La propriété essentielle de cette fonction est la suivante : si une même ressource possède diffé- rents emplacements logiques, alors, par la fonction Nabs, elle ne possède qu’un seul et unique nom symbolique absolu indépendant de la localisation. Cette propriété s’exprime de la façon suivante : ∀r ∈ R, si ∃Elog(r) = chemin1 et Elog(r) = chemin2 avec chemin1 6= chemin2 ⇒ Nabs(chemin1) = Nabs(chemin2) Cette propriété sera illustrée par la suite. Solution pour les systèmes Windows Sur les systèmes Windows, la problématique de nommage des ressources est essentiellement due au fait qu’il n’y a pas de racine commune entre les différents systèmes. Pour résoudre ce problème et pour appliquer notre fonction permettant d’obtenir un nom symbolique absolu indé- pendant de la localisation, nous allons utiliser un mécanisme interne au système commun à chaque système Windows. Dans un premier temps, le nom de la ressource est séparé en deux : la lettre du lecteur qui est potentiellement changeante, et son chemin dans l’arborescence qui est constant. Nous appliquons la fonction Nabs à la partie changeante. Pour ce faire, nous utilisons la notion d’espace de noms (namespace) d’une ressource. L’espace de noms d’une ressource est une fonctionnalité du système qui associe aux ressources une représentation abstraite indépendante de leur localisation. La fonction Nabs est appliquée à C:\Program Files exemple présenté dans le listing 3.2. C’est la partie que l’on considère comme changeante. On obtient ainsi Nabs(C : \P rogramF iles) = ns_programf iles. En reprenant notre exemple présenté dans le listing 3.2, nous obtenons pour les deux noms usuels différents 3.3 un même nom symbolique absolu indépendant de la localisation. ✞ ☎ 1 C:\Program Files\Mozilla\Firefox.exe : ns_programfiles:\Mozilla\Firefox.exe 2 D:\Program Files\Mozilla\Firefox.exe : ns_programfiles:\Mozilla\Firefox.exe ✝ ✆ Listing 3.3 – Application des noms symboliques absolus indépendants de la localisation pour identifier une même ressource sur un système Windows L’utilisation de cet espace de noms offre une meilleure portabilité de la politique de contrôle d’accès. Cet espace de noms étant géré directement au sein du système Windows, il n’est plus nécessaire de réécrire les politiques pour les appliquer sur un autre système Windows. Solution pour les systèmes Linux Les systèmes Linux utilisent des identifiants internes pour différencier les ressources sur un système. Même si ces identifiants sont accessibles depuis l’espace utilisateur, ils ne sont pas facilement manipulables. Et même si les systèmes Linux disposent d’une racine commune, nous pouvons aussi appliquer notre formalisation à ce système. Par exemple en adaptant le listing 3.4 et en appliquant la fonction Nabs, nous obtenons le résultat suivant 3.5. ✞ ☎ 1 /lhome/gros/policy.24 : ns_home:gros/policy.24 2 /mnt/home/gros/policy.24 : ns_home:gros/policy.24 ✝ ✆ Listing 3.5 – Application des noms symboliques absolus indépendants de la localisation pour identifier une même ressource sur un système Linux 803.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT ✞ ☎ 1 gros@ossus:~% stat /lhome/gros/policy.24 2 File: ’/lhome/gros/policy.24’ 3 Size: 1592659 Blocks: 3112 IO Block: 32768 regular file 4 Device: 19h/25d Inode: 11274188 Links: 1 5 6 sudo mount -o bind /home/ /mnt/ 7 8 gros@ossus:~% stat /mnt/home/damien/policy.24 9 File: ’/mnt/home/gros/policy.24’ 10 Size: 1592659 Blocks: 3112 IO Block: 32768 regular file 11 Device: 19h/25d Inode: 11274188 Links: 1 ✝ ✆ Listing 3.4 – Différents noms Linux pour une même ressource identifiée par son numéro i-node 3.2.2 Application de la grammaire sur deux modèles de protection pour les systèmes Windows L’étude des travaux précédents a montré qu’il existait des implantations de modèles de protection pour les systèmes Linux. C’est pourquoi nous allons nous concentrer exclusivement sur les systèmes Windows pour l’application de notre grammaire. La première partie de cette section a démontré que cette grammaire pouvait s’appliquer sur les deux systèmes d’exploitation. Nous appliquons la grammaire que nous venons de définir sur deux modèles de protection : PBAC et DTE. Dans cette section, nous montrerons que seuls les terminaux de la grammaire doivent être spécifiés, mais que ces deux modèles se basent sur la grammaire commune que nous avons définie. Nous avons choisi le modèle PBAC pour la facilité qu’il permet dans la rédaction de la politique car ce modèle se base sur les chemins des ressources. Le second modèle, DTE, offre une couche d’abstraction entre la politique et le système permettant d’avoir des politiques plus précises mais aussi supportant mieux l’hétérogénéité. 3.2.2.1 Policy-Based Access Control Représentation du système Grâce à l’introduction de notre mécanisme d’abstraction des noms, il est possible de décrire complètement le système. Nous définissons NS la fonction du système qui associe à un répertoire donné un élé- ment de l’espace de noms. Par exemple, NS(C:\ProgramFiles)=ns_programfiles où ns_programfiles est un élément de l’espace de noms. Les objets Les objets du système sont toutes les entités qui subissent les interactions : fichiers, répertoires, éléments du registre, mais aussi les processus. Grâce à sa stabilité d’architecture, il existe un certain nombre de répertoires communs entre les différentes versions des systèmes Windows. Il est donc possible de définir des éléments propres à l’espace de noms pour ces répertoires. Le listing 3.6 fait la correspondance entre les répertoires et leur nom dans l’espace de noms. ✞ ☎ 1 NS(C:\Windows) = ns_windows 2 NS(C:\Program Files) = ns_programfiles 3 NS(C:\Users) = ns_users 4 NS(C:\Recycler) = ns_recycler ✝ ✆ Listing 3.6 – Correspondance entre les répertoires système et leur nom dans l’espace de noms 813.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT ✞ ☎ 1 NS(C:\Windows\explorer.exe) = ns_windows\explorer.exe 2 NS(System) = system ✝ ✆ Listing 3.8 – Noms associés aux sujets pour le modèle PBAC Lorsqu’un répertoire est spécifique à un système, ou simplement ajouté par un administrateur, il est possible de lui ajouter un élément générique de l’espace de nom comme ns_racine\monrepertoire, où ns_racine désigne de manière générique la racine du système. L’administrateur peut aussi définir ses propres éléments, dans la cadre d’un parc informatique identique, en utilisant par ns_monrepertoire. De manière analogue, nous pouvons faire la même chose pour le registre, illustré par le listing 3.7. ✞ ☎ 1 NS(HKEY_LOCAL_MACHINE) = ns_hklm 2 NS(HKEY_USERS) = ns_hku ✝ ✆ Listing 3.7 – Correspondance entre les ruches du registre système et leur nom dans l’espace de noms Les sujets Les sujets sont les entités du système qui réalisent les interactions sur les objets. Dans la pratique, les sujets sont un sous-ensemble de l’ensemble des objets. En effet, comme les sujets sont associés aux processus et aux services, ils peuvent interagir entre eux : un processus pouvant par exemple récupérer un handle sur un autre processus dans le but d’interagir avec lui. A la différence des systèmes Linux où l’extension des fichiers n’est pas représentative de son comportement, sur les systèmes Windows, elle permet de spécifier la nature de la ressource. Ainsi, la reconnaissance des processus, et donc des sujets, se fait par l’extension .exe qui leur est associée. Néanmoins, il existe des processus spécifiques qui ne respectent pas ce schéma, comme le processus System associé au PID 4. Cependant, ce processus possède le même nom ainsi que le même PID sur chaque système Windows, il est donc facilement reconnaissable. Ainsi, nous aurons, en prenant par exemple les sujets explorer.exe et System les noms associés comme le montre le listing 3.8. Les opérations élémentaires Les opérations élémentaires sont basées sur les ACL classiques présentes sous Windows. Nous obtenons ainsi les droits : 1. r, pour le droit de lecture ; 2. w, pour le droit d’écriture ; 3. x, pour le droit d’exécution. À ces droits classiques, nous rajoutons les droits suivants : 1. h, pour cacher un élément aux autres entités du système ; 2. ap, pour ajouter des privilèges ; 3. rp, pour supprimer des privilèges. Les rôles Dans ce modèle de politique, la notion de rôle pour les utilisateurs est très importante. En effet, une politique de type PBAC donne les mêmes droits à tous les utilisateurs, sans distinction aucune. Il est donc nécessaire de définir des rôles pouvant accéder à certains domaines privilégiés pour faire de la séparation de privilèges. 823.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT ✞ ☎ 1 grammar pbac; 2 3 // include gram_commune 4 5 classe : Chaine ; 6 autorise_interaction : ; 7 audit : ’audit ’; 8 autorise_objet : ’’; 9 autorise_role : (’role’); 10 11 contexte : Chaine ; 12 13 operations_elementaires : ’ ’ operation_elementaire (’\n’)?; 14 operation_elementaire : (’r’|’w’|’x’) ; 15 role: Chaine ; 16 17 Chaine : ( ( ’a’..’z’|’A’..’Z’|’0’..’9’|’_’|’.’|’,’|’\\’) )+ ; 18 Delimiteurs_debut: ’ {’ (’’|’\n’ )? ; 19 20 Delimiteurs_fin: (’ ’)? ’}’ ; ✝ ✆ Listing 3.9 – Définition des terminaux pour le modèle de protection PBAC ✞ ☎ 1 systemroot\explorer.exe { 2 systemroot\cmd.exe w 3 systemdrive\fichier.txt r 4 } 5 audit explorer.exe { programfiles\firefox.exe r } 6 role user admin ✝ ✆ Listing 3.10 – Extrait d’une politique PBAC Sous Windows, on peut se baser sur les groupes d’appartenance des utilisateurs pour établir les rôles de chaque utilisateur. Le principal avantage de cette méthode est que ce mécanisme est intégré à Windows et facilement modifiable. Grammaire spécifique pour le modèle PBAC À partir de la grammaire générique que nous avons définie dans le listing 3.1, nous pouvons étendre cette grammaire pour le modèle PBAC. Le listing 3.9 détaille la grammaire spécifique pour PBAC. Cette extension ne fait que renseigner les terminaux de la grammaire, qui sont spécifiques à ce modèle de protection. Cette grammaire spécifique pour le modèle de protection PBAC permet de définir les éléments de la politique : les contextes, les rôles et les opérations élémentaires. Elle va aussi spécifier les délimiteurs pour l’écriture des vecteurs d’accès. Dans cette politique, les contextes, en pratique des noms symboliques absolus, sont définis comme des chaînes de caractères spécifiques (par exemple incluant les antislash). Les opérations élémentaires sont représentées par les ACL classiques présentes sur les systèmes : r pour l’opération read, w pour l’opération write, etc. Nous proposons dans le listing 3.10 un extrait de politique pour le modèle PBAC. Les lignes 1 à 4 autorisent deux interactions directes. La ligne 5 définit une interaction directe qui doit être auditée. Enfin, la ligne 6 permet à un utilisateur du rôle user de changer son rôle pour atteindre le rôle admin. 833.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT 3.2.2.2 Domain and Type Enforcement Représentation du système Dans le modèle de protection basé sur DTE, les sujets sont associés à des domaines alors que les objets sont associés à des types. Nous allons décrire ici comment construire ces deux notions. Puis, comment proposer des contextes de sécurité étendus avec des notions d’identité et de rôle. Les objets Les types, qui sont donc associés aux objets du système, sont construits à partir de deux éléments. Le premier élément est simplement le nom relatif de la ressource sans son extension, dans le cas où elle en possède une. Ce nom relatif n’est pas unique sur le système, puisqu’il ne se base que sur le nom de la ressource sans son chemin dans l’arborescence du système de fichiers. Le second élément est un suffixe qui précise la nature de l’objet : répertoire, exécutable, bibliothèque, etc. Par exemple, la ressource C:\Program Files\Mozilla\Firefox.exe. Le nom relatif de la ressource sans son extension est Firefox. On ajoute à cela sa caractéristique, ici Cat(executable). Donc le type associé au fichier C:\Program Files \Mozilla \Firefox.exe est F irefox.Cat(executable). De manière similaire, nous aurons des catégories pour les répertoires, les driver, les bibliothèques, etc. Les éléments du registre seront typés de manière similaire au système de fichiers, à la diffé- rence qu’ils disposent de catégories spécifiques telles que Cat(key) et Cat(value). Cette dernière catégorie est aussi utilisée pour la prise de décision. Les sujets Les sujets sont associés à la partie domaine du modèle DTE. À la différence des objets qui possèdent une catégorie, les sujets n’en ont pas besoin. En effet, il n’est pas nécessaire de renseigner la catégorie puisqu’il n’y a que la catégorie processus (en général). Le domaine est uniquement composé du nom relatif du fichier exécutable privé de son extension. Par exemple, le domaine associé au fichier C:\Program Files\Mozilla\Firefox.exe sera Firefox. Tout comme pour le modèle PBAC, il existe des cas particuliers tels que le processus nommé System qui aura pour domaine exactement le même nom. Les opérations élémentaires Dans ce modèle de protection, les opérations élémentaires sont dérivées des appels système. En définissant la fonction Cl, qui associe à un objet o appartenant à l’ensemble O des objets du système l’ensemble des opérations élémentaires spécifiques à cet objet, nous pouvons écrire : Cl(o) = oe1, ..., oen, avec oei ∈ OE où OE est l’ensemble de toutes les opérations élémentaires. Par exemple, le fichier cmd_exec_t se définit de la manière suivante : Cl(cmd_exec_t) = f ile et il possède les opérations élémentaires associées aux fichiers f ile{read write execute etc.}. Nous pouvons citer quelques opérations élémentaires simples comme read, write ou encore execute. Il y a aussi getattr lorsqu’un processus demande à récupérer les attributs d’un objet. La liste de ces opérations élémentaires est équivalente au nombre d’appels système disponibles pour l’objet considéré. Extension aux contextes de sécurité Nous définissons des contextes de sécurité plus complets en ajoutant les notions d’identités mais aussi de rôles aux types et aux domaines. Pour la notion de rôles, nous utiliserons la même représentation que pour le modèle PBAC, à savoir l’utilisation des groupes présents sous Windows. Les identités seront liées au SID de l’utilisateur. Les identités 843.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT ✞ ☎ 1 grammar dte 2 3 // include gram_commune 4 5 classe : Chaine ; 6 autorise_interaction : (’allow ’|’neverallow ’); 7 audit : ’auditallow ’; 8 autorise_objet : ’transition’; 9 autorise_role : ’role’; 10 11 contexte : (utilisateur ’:’)? (role ’:’)? (attribut); 12 13 utilisateur: Chaine ; 14 role: Chaine ; 15 attribut: Chaine ; 16 17 operations_elementaires : ’ { ’ (operation_elementaire ’ ’)* operation_elementaire ’ }’; 18 operation_elementaire: (’read’|’write’| Chaine ) ; 19 20 21 Chaine : ( ’a’..’z’|’A’..’Z’|’0’..’9’|’_’|’.’)+ ; 22 Delimiteurs_debut: ’ ’ ; 23 Delimiteurs_fin: ’}’ ; ✝ ✆ Listing 3.12 – Définition des terminaux pour le modèle de protection DTE et les rôles permettent des contrôles supplémentaires même si ceux-ci sortent du cadre de notre travail. Ainsi, on obtiendra un contexte de sécurité sous Windows de la forme 3.11. ✞ ☎ 1 SELinux : user:role:type/domaine 2 Windows : SID:Groupe Windows:type/domaine ✝ ✆ Listing 3.11 – Représentation d’un contexte de sécurité sous Windows Les transitions Il existe deux types de transition : la première est la plus courante, c’est le passage d’un type à un domaine. Cela se caractérise par l’exécution d’un fichier qui est dans la Cat(executable). Pour qu’un processus soit autorisé à transiter vers un domaine destination, il est nécessaire que : 1. le domaine source possède une règle d’accès autorisée à exécuter ce fichier, ainsi que toutes les opérations élémentaires annexes nécessaires à ce type d’opération comme le droit de récupérer des informations sur le fichier (getattr) ; 2. le fichier exécutable possède le domaine destination dans la politique de contrôle d’accès. La seconde transition possible est le changement de rôle. Cette transition n’est pas propre au modèle DTE. Cela permet de réduire considérablement la taille de la politique donnant les accès aux rôles plutôt qu’aux utilisateurs directement. Grammaire spécifique pour le modèle DTE Comme pour le modèle PBAC, nous étendons la grammaire commune pour qu’elle puisse fonctionner sur ce modèle de protection. Le listing 3.12 illustre les éléments propres à ce modèle. Nous définissons deux mots clés pour les règles d’autorisation : allow et neverallow. Le premier permet d’autoriser de manière explicite l’interaction qui est donnée pour le vecteur d’accès. Le second l’interdit de manière explicite. Nous montrerons dans la partie expérimentation comment nous utilisons ces règles d’interdiction. La règle d’audit est signifiée par le mot clé audit. 853.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT À la différence du modèle PBAC, où le contexte est une chaine de caractères représentant un chemin dans le système de fichiers, dans le modèle DTE, il est composé de trois identifiants : un identifiant pour spécifier l’utilisateur, un autre pour le rôle et enfin un attribut. Les deux premiers éléments ne sont pas propres au modèle DTE, mais ils facilitent l’administration du système. L’attribut est soit un domaine, pour un sujet, soit un type pour un objet. Nous proposons une politique minimale dans le listing 3.13 illustrant la grammaire. ✞ ☎ 1 allow explorer_t cmd_exec_t:file { write read getattr execute } 2 auditallow firefox_t document_t:file { read } 3 role user_r sysadm_r 4 transition explorer_t cmd_exec:file cmd_t ✝ ✆ Listing 3.13 – Extrait d’une politique DTE La première règle autorise le domaine firefox_t à accéder au fichier cmd_exec_t en lecture et écriture. La seconde règle est une règle d’audit, mais qui n’autorise pas l’interaction. Enfin, les règles 3 et 4 sont des transitions de rôles et de domaine. Pour que le domaine cmd_t soit autorisé, il faut la règle de la ligne 1 du listing ainsi que la ligne 4. 3.2.2.3 Lien entre la politique d’accès direct et le moniteur de référence La politique d’accès directe (PBAC ou DTE) est parcourue par le moniteur de référence lors de la phase de décision. Cette décision peut être divisée en deux : soit le moniteur trouve une règle d’accès dans la politique et il applique le traitement associé, soit il ne trouve rien et dans ce cas-là, il applique une règle par défaut. La figure 3.28 illustre les deux possibilités offertes par le moniteur. Comme nous pouvons le voir sur la figure, nous avons ajouté une règle à la grammaire regle_defaut définissant l’action par défaut que doit avoir le moniteur lorsqu’il ne trouve pas le vecteur d’accès au sein de la politique de sécurité. Dans le cadre d’un moniteur de référence, nous avons choisi d’avoir une règle par défaut qui refuse l’opération et qui génère une trace dans le but de connaître les opérations qui ont été interdites par le moniteur. 863.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS FIGURE 3.28 – Mécanisme de prise de décision du moniteur de référence 3.3 Les techniques de détournement sur les systèmes Windows Dans cette section, nous allons expliquer les techniques de détournement des flux d’exécution présent sous Windows. Des détails se trouvent en annexe C de notre étude. Nous discuterons des limites de chaque méthode de détournement et de leur place dans le contrôle d’accès sur les systèmes Windows. 3.3.1 Explications des techniques 3.3.1.1 Détournement de la table des appels système Sur les systèmes d’exploitation Windows, tous les appels système sont stockés dans une table nommée table des appels système. Dans cette table, Windows associe un numéro d’appel système avec une adresse mémoire. Pour réaliser des interactions, les processus utilisent les fonctions de l’API Win32, qui sont les fonctions de haut niveau fournies par Microsoft. Il faut ensuite faire correspondre ces fonctions de haut niveau avec les appels système. Pour cela, une couche d’abstraction placée en espace utilisateur récupère la fonction de l’API Win32 pour ensuite utiliser l’appel système correspondant. Pour détourner le flux d’exécution, un driver va aller modifier l’adresse d’un appel système, dans la table des appels système, pour la remplacer par l’adresse d’une de ses propres fonctions. Ainsi, lorsque Windows exécute l’appel système dont l’adresse a été modifiée, il exécute une fonction du driver. 873.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS Le schéma 3.29 montre le flux d’exécution d’une action sous Windows. Lorsqu’un processus veut effectuer une interaction sur le système, il fait appel à une fonction présente dans la table des appels système qui exécute une fonction au sein du noyau. Le second 3.30 schéma illustre lui le détournement d’un appel système. Lorsque le processus veut effectuer une interaction, avant de passer dans le noyau, son interaction est détournée par l’observateur, qui va autoriser ou refuser cette interaction. FIGURE 3.29 – Fonctionnement régulier d’un appel système présent dans la table des appels système FIGURE 3.30 – Mécanisme de détournement de la table des appels système 3.3.1.2 Inline-Hook Cette technique consiste à modifier directement la fonction en mémoire. Sous Windows, au début des fonctions, il existe une partie de code appelée junk code : c’est ce que l’on appelle un code sans effet de bord. On peut donc le modifier sans pour autant modifier le comportement de la fonction. En allant modifier le junk code présent au début de la fonction pour y placer un saut inconditionnel, il est possible de détourner le flux d’exécution pour le rediriger vers l’espace mémoire du driver. Cette technique a été implémentée pour les fonctions de l’API Win32 et est connue sous le nom de MS Detour [Hunt et Brubacher, 1999]. Ce projet est porté par Microsoft Research et cible essentiellement les systèmes Windows XP. Microsoft propose, au travers d’un framework, des API pour modifier de manière complètement transparente des fonctions spécifiques en espace utilisateur grâce à l’utilisation d’un mécanisme nommé trampoline. Cette interface est chargée de récupérer les arguments des fonctions pour qu’ils puissent être exploités par la fonction réalisant l’inline hook. Elle est cependant transposable aux appels système. 883.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS Cette méthode est illustrée par la figure 3.31. Elle détaille le placement, en début de fonction, de la modification introduite pour détourner le flux d’exécution et le placement de l’observateur. FIGURE 3.31 – Mécanisme d’inline hook 3.3.1.3 filter-driver Microsoft a mis en place une architecture spécifique basée sur des driver en couches pour contrôler les interactions réalisées sur le système de fichiers. Cette architecture se base sur la création de filter-driver s’enregistrant auprès d’un gestionnaire d’entrée/sortie et demandant à traiter certaines IRP (I/O Request Packets). Une IRP représente une opération d’entrée/sortie. À la différence des appels système qui ne font qu’une seule opération élémentaire (ouverture de fichier, lecture, écriture, etc.), les IRP englobent plusieurs appels système pour finalement représenter un type d’action, par exemple l’ouverture d’un fichier. La figure 3.32 montre l’architecture des driver en couches. Pour représenter ces différentes couches, qui définissent le comportement du driver, les filter-driver possèdent une altitude. Cette altitude définit le type du driver. Par exemple, il existe une plage d’altitude pour les driver d’antivirus ou pour les driver de chiffrement. Par construction, les filter-driver sont naturellement placé en mode continuation. Action d’un processus sur le système de fichiers Espace utilisateur Espace noyau Moniteur d’activité Altitude 360 000 FSFilter Antivirus Altitude 325 000 FSFilter Compression Altitude 165 000 FSFilter de chiffrement Altitude 145 000 Driver de stockage Filter Manager Frame 0 FS Filter Pas d’altitude Filter Manager Frame 1 I/O Manager FIGURE 3.32 – Architecture des filter-driver en prétraitement L’altitude du filter-driver définit le type du driver mais aussi son placement par rapport aux autres filter-driver. Ce placement influe sur les informations que reçoit ou non le driver. Une IRP est transmise aux filter-driver concernés par l’action courante. Les transmissions aux filter-driver sont faites de manière séquentielle et sont définies par leur altitude. Ainsi un filterdriver qui est à l’altitude 325 000 récupère l’IRP avant un filter-driver qui est à l’altitude 145 893.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS 000 pour des opérations de prétraitement. A contrario, lors des opérations de post-traitement, le filter-driver qui est à l’altitude 145 000 récupère l’IRP avant celui à l’altitude 325 000. Dans cette architecture, l’observateur se place dans la pile de driver comme illustré dans la figure 3.33 pour le prétraitement et pareillement pour le post-traitement 3.34. FIGURE 3.33 – Place de l’observateur en prétraitement FIGURE 3.34 – Architecture des filter-driver en post-traitement Grâce à cette architecture spécifique, nous pouvons définir à quelle altitude sera notre filterdriver. Comme il a pour but de superviser les interactions faites sur le système de fichiers, ce sera un driver de type moniteur d’activité et aura donc une altitude comprise entre 360000 et 389999. Cette altitude a l’avantage de nous placer très haut dans la pile des driver. 903.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS 3.3.2 Discussion Nous venons de présenter les méthodes de détournements présentes sous Windows. Nous allons dans cette section discuter du placement de l’observateur dans l’architecture du contrôle d’accès sur les systèmes Windows. Ensuite nous présenterons des méthodes de contrôle des driver. 3.3.2.1 Place de l’observateur dans le contrôle d’accès de Windows Comme nous l’avons déjà présenté dans l’état de l’art (voir la section 2.3.2.1), depuis l’arrivée de Windows Vista, un nouveau mécanisme de sécurité a été introduit dans le système Windows. Il est complémentaire au modèle de protection discrétionnaire classique. Mais à la différence des contrôles d’accès obligatoires présents sous Linux, la vérification du niveau d’intégrité est faite avant la vérification des droits discrétionnaire, ce qui permet par ailleurs, de les contourner. Avec l’insertion de notre observateur au sein du système Windows, il est nécessaire de connaître sa place dans l’architecture du contrôle d’accès sous Windows. Nous allons ici traiter les trois méthodes présentées précédemment en expliquant le placement de l’observateur pour chaque cas. Détournement de la table des appels système Lorsque l’observateur détourne le flux d’exécution en modifiant la table des appels système, l’appel système n’est exécuté qu’à partir du moment où l’observateur a autorisé l’interaction. Cela implique que dans cette configuration, le contrôle s’effectue de la manière suivante : 1. contrôle d’accès obligatoire ; 2. contrôle d’intégrité obligatoire ; 3. contrôle des droits discrétionnaires. En effet, le détournement empêche l’appel système et donc en pratique les contrôles classiques qui, de ce fait, ont lieu à la suite des contrôles de notre observateur. Inline hook Cette technique consiste à modifier des fonctions du noyau dans le but de contrôler le plus grand nombre d’opérations. Dans la pratique, si on ne s’intéresse qu’aux appels système, nous aurons donc le même comportement que le détournement de la table des appels système. Dans cette configuration, le contrôle s’effectue de la manière suivante : 1. contrôle d’accès obligatoire ; 2. contrôle d’intégrité obligatoire ; 3. contrôle des droits discrétionnaires. filter-driver Dans ce modèle de détournement, l’ordre des vérifications est différent. En effet, dans cette architecture, les requêtes passent par le noyau et sont ensuite transférées au gestionnaire d’entrée/sortie qui les transmet aux filter-driver concernés par l’opération. 1. contrôle d’intégrité obligatoire ; 2. contrôle des droits discrétionnaires; 3. contrôle d’accès obligatoire. 913.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS 3.3.2.2 Contrôle des driver Toutes ces techniques se basent sur l’utilisation d’un driver pour agir en espace noyau et ainsi avoir un impact sur tout le système. Cependant, toutes les opérations que nous avons décrites peuvent être aussi réalisés par n’importe quel driver. Il est donc nécessaire de contrôler les autres driver qui sont chargés. Sur les systèmes Windows, les driver offrent des moyens de communication entre les périphé- riques tels que les scanner, les webcam, etc. et le système d’exploitation. Ils sont donc nécessaires au bon fonctionnement du système. On ne peut tout simplement pas empêcher le chargement des driver. Il faut par conséquent proposer des solutions pour contrôler aussi les driver. Depuis les systèmes Windows Vista 64 bits et la mise en place de Kernel Patch Protection, les driver qui sont chargés doivent être signés numériquement par un certificat délivré par Microsoft. Cela constitue une première vérification quant au chargement des driver. Cependant, ce mécanisme n’est pas suffisamment fiable puisque certains logiciels malveillants arrivent à charger des drivers malgré la présence de ce mécanisme. Nous allons discuter dans cette section, pour chaque solution, du contrôle du chargement des driver. En effet, il est nécessaire les driver existant ne puissent pas contourner voire supprimer notre détournement. Détournement de la table des appels système Le chargement des driver s’effectue par l’appel système NtLoadDriver. Il est donc possible, en contrôlant cet appel de contrôler le chargement des driver. Cependant, nous allons dé- tailler deux installations de driver qui pourraient compromettre le bon fonctionnement de notre moniteur. Le premier exemple concerne un driver légitime et le second, un driver malveillant. Un driver légitime peut modifier la table des appels système. Ce sont généralement les logiciels de sécurité qui réalisent ce type d’opération comme les antivirus ou les pare-feux. Si un driver légitime modifie la table des appels système, nous pouvons être confrontés à deux possibilités : 1. l’observateur se charge en dernier parmi l’ensemble des driver qui modifient la table des appels système : cela implique que notre observateur sera correctement installé et il prendra la première décision. 2. l’observateur ne se charge pas en dernier, c’est-à-dire qu’un driver, que l’on a autorisé à se charger, modifie la table des appels système après nos modifications. Si le driver fait correctement la modification, c’est-à-dire qu’il prend l’adresse présente dans la table avant sa modification pour appeler l’appel système, alors notre observateur sera toujours impliqué dans la chaine d’exécution. Si le driver préfère résoudre manuellement l’appel système, alors l’observateur ne sera plus impliqué dans la chaine d’exécution. La figure 3.35 illustre l’empilement des driver qui détournent des flux d’exécution engendrés par la modification de la tables des appels système par plusieurs driver. Chaque observateur maintient une table modifiée des appels système. Le dernier observateur maintient lui la table régulière pour exécuter l’appel système. Dans cette configuration, les observateurs sont en mode cascade. 923.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS Observateur 1 Table courante des appels système Table des appels système modifée par un second observateur processus Table des appels système régulières Observateur 2 Décision Décision appel système FIGURE 3.35 – Empilement de driver modifiant la table des appels système Un driver malveillant peut conduire à une attaque basée sur une situation de concurrence, illustrée par la figure 3.36. Le principe de l’attaque repose sur le fait que les vérifications faites par le driver ayant détourné l’appel système ne sont pas atomiques, c’est-à-dire qu’elles prennent un certain temps. La fonction NtLoadDriver prend en paramètre un UNICODE. Cet UNICODE contient le chemin complet du driver à charger. L’attaque réussie lorsque cette fonction est appelée depuis l’espace utilisateur. Au moment du passage en espace noyau, la structure n’est pas recopiée, mais seul un pointeur est copié en espace noyau. processus malveillant chemin vers driver légitime 1 2 3 4 Observateur 5 6 7 8 9 table des appels système modifiée NtLoadDriver Décision appel système FIGURE 3.36 – Schéma détaillant la situation de concurrence sur la table des appels système Tout d’abord, un processus malveillant remplit un UNICODE avec un chemin de driver lé- gitime (flèche 1), puis exécute l’appel système NtLoadDriver (flèche 2). Comme la table des appels système a été modifiée par l’observateur, le flux d’exécution est détourné dans l’observateur (flèche 3). L’UNICODE n’est pas recopié en espace noyau, l’observateur récupère juste un pointeur vers cet UNICODE (flèche 4). L’observateur effectue ses vérifications (flèche 5). Une fois ces vérifications faites, le processus malveillant modifie les informations contenues dans l’UNICODE pour mettre un chemin vers un driver malveillant (flèche 6). L’observateur poursuit le flux d’exé- cution en appelant la véritable fonction (flèche 7). Le noyau récupère lui aussi un pointeur vers cet UNICODE (flèche 8) et exécute la fonction (flèche 9). Il est ainsi possible de charger un driver malveillant malgré les vérifications. 933.4. DISCUSSION Inline hook Cette technique ne ciblant pas que les appels système, nous pouvons contrôler plus de fonctions impliquées dans le chargement des driver. Nous pouvons commencer par contrôler l’appel système NtLoadDriver. Nous pouvons aussi cibler MmLoadSystemImage. Nous citons ici quelques fonctions mais cette liste n’est pas exhaustive. En effet, beaucoup de fonctions internes ne sont pas documentées donc non présentes sur la MSDN. Tout comme pour le détournement de la table des appels système, si un driver effectue la même opération que nous, c’est-à-dire placer un saut inconditionnel en début de fonction, notre observateur ne sera plus impliqué dans la chaîne d’exécution. Il est donc nécessaire de mettre en place un moniteur qui va vérifier que le saut est toujours présent. A la différence du détournement de la table des appels système, il n’est pas possible d’avoir un empilement, comme le montre la figure 3.35 au niveau des driver qui réalisent ce genre de détournement. Par conséquent, si un driver fait une modification après notre observateur, il faut soit générer une erreur pour bloquer le système, soit remettre en place le saut inconditionnel. Ce n’est pas la seule différence. En effet, ce genre de technique n’est pas une technique couramment utilisée par les driver légitimes. Donc, si on est capable de détecter ce genre de modification, on peut légitimement supposer que le driver ne devrait pas être autorisé à être chargé. Tout comme pour le mécanisme de détournement de la table des appels système, il est difficile de contrôler une modification qui interviendrait sur notre driver. Par conséquent, si un driver vient modifier notre observateur pour modifier la fonction responsable de la supervision des modifications, alors l’observateur ne verra pas les nouvelles modifications. filter-driver Le filter-driver étant la technique préconisée par Microsoft, elle est donc légitimement devenue la méthode utilisée par les logiciels antivirus. Les filter-driver ne contrôlent que les interactions réalisées sur le système de fichiers. Par conséquent, ils ne sont pas capables de contrôler le chargement des exécutables et par extension, des driver. C’est pourquoi il est nécessaire de mettre un système de callback. Un callback peut s’enregistrer auprès du Process Manager. Il peut ainsi contrôler le chargement de tous les exécutables, y compris les driver. Le contrôle du réseau doit se faire par la création d’un driver spé- cifique, basé sur l’architecture Windows Filtering Platform. Ces techniques ne sont pas réservées au filter-driver, mais elles sont nécessaires pour contrôler le chargement des exécutables par un filter-driver. Les filter-driver sont installés en spécifiant une altitude. Pour respecter les spécifications de Microsoft, il faut faire une demande sur leur site pour se faire attribuer une altitude. Une fois que filter-driver possède une altitude fournie par Microsoft, il enregistre cette altitude dans une clé du registre. On peut aussi retrouver toutes les altitudes définies dans un fichier fourni par Microsoft. Néanmoins, rien n’empêchera un filter-driver malveillant de se charger à une autre altitude que celle spécifiée dans le registre. Cette définition d’altitude n’implique, en aucun cas, que seul un filter-driver précis peut se charger à cette altitude donnée. 3.4 Discussion Dans ce chapitre, nous avons commencé par formaliser la notion d’observateur. Nous définissons les éléments observés tels que les sujets, objets et opérations élémentaires. Nous avons ensuite défini les modes de sécurité possible pour un observateur : requête/réponse, évidence et continuation. Puis, nous avons détaillé un observateur spécifique : le moniteur de référence. Dans cette 943.4. DISCUSSION section, nous avons décrit les trois grandes phases de traitement. Ce moniteur de référence sera par la suite, appliqué aux systèmes Windows 7. Enfin, nous formalisons les modes de répartition des observateurs, qui se traduit par des méthodes d’association, de localisation et de redondance. Nous nous sommes ensuite intéressés à la création de politique d’accès direct. Nous avons, pour cela, proposé un langage générique pour la protection du système définissant une grammaire commune aux modèles obligatoires PBAC et DTE. Pour le modèle PBAC, les politiques sont portables entre les différents systèmes Windows car notre méthode de désignation des ressources est indépendante de la localisation des ressources. Pour le modèle DTE, les ressources étant identi- fiées par des types ou des domaines, les politiques pourraient être utilisées à la fois sur Linux et sur Windows. Enfin, nous finissons ce chapitre en décrivant des méthodes de détournement de flux d’exécution sur les systèmes Windows. Au sein d’une discussion ainsi que dans l’annexe C, nous avons décrit quelle est leur place dans le contrôle d’accès sous Windows ainsi que leurs limites. Nous avons expliqué la nécessité de contrôler le chargement des driver pour protéger notre observateur. Il ressort de ce chapitre que nous avons défini de manière générique la notion d’observateur pour les systèmes d’exploitation. Nous avons montré que cette notion pouvait s’appliquer aussi bien aux systèmes Linux qu’aux systèmes Windows. Nous avons abstrait aussi bien leurs modes de sécurité que leurs modes de répartition. Dans le chapitre 4, nous allons nous intéresser à la répartition de deux observateurs dans un environnement HPC en proposant une architecture originale. Mais nous devrons aussi proposer un modèle nous permettant de mesurer l’impact de la répartition de ces observateurs sur un système. Dans le chapitre 5, nous mettrons en œuvre le moniteur de référence défini dans ce chapitre pour les systèmes Windows. Pour cela, nous montrerons comment écrire une politique de contrôle d’accès direct et les usages que nous en avons faits pour l’analyse et le contrôle des malware. 953.4. DISCUSSION 96Chapitre 4 Répartition d’observateurs en environnement HPC et analyse des performances En étudiant deux scénarios d’attaque complets sur les systèmes d’exploitation en introduction de notre étude (voir la section 1.3), nous avons expliqué qu’il faillait pouvoir mesurer et contrôler les interactions directes. Ce contrôle s’effectue par la définition d’un observateur capable de gérer les interactions directes. Cependant, il est parfois difficile de prévenir une attaque en agissant uniquement sur les interactions directes sans pour autant nuire au fonctionnement global du système. C’est pour cette raison qu’il est nécessaire d’associer plusieurs observateurs, réalisant des calculs supplémentaires pour protéger le système en profondeur sans nuire à son bon fonctionnement. Dans le chapitre 3, nous avons proposé une définition générique d’observateur pour les systèmes d’exploitation ainsi qu’un modèle de répartition. Ajouter des observateurs au sein d’un système va nécessairement consommer des ressources supplémentaires, que ce soit du temps processeur, de la mémoire vive, des ressources sur le disque, etc. Cependant, il n’existe pas de modèle de mesure des performances permettant de quantifier de manière précise le surcoût engendré par l’ajout d’observateurs au sein d’un système. Il est pourtant nécessaire de pouvoir calculer ce surcoût, surtout en vue de l’intégration dans des environnements à haute performance. Nous avons détaillé au cours de l’introduction, mais aussi tout au long de notre étude, qu’il existait des associations naturelles d’observateurs sur les systèmes : SELinux et PIGA, SELinux et iptables, un antivirus et un pare-feu sous Windows, etc. Néanmoins, il n’existe pas de modèle permettant de formaliser ces répartitions, c’est pour cela que nous en avons proposé un dans la section 3.1.3. Au cours de cette modélisation, nous avons défini des modes de répartition autorisant le déport de l’observateur. Dans une première section de ce chapitre, nous allons détailler la méthode que nous avons développée pour mesurer l’impact sur les performances du système d’exploitation de l’association de plusieurs observateurs. Nous traiterons plus spécialement les modes colocalisés et distants avec une association en cascade des observateurs. Puis, dans une autre section, nous détaillerons deux répartitions d’observateurs, SELinux avec PIGA, dans un environnement HPC. La première répartition est colocalisée et la seconde est distante. Nous expliquerons comment nous avons pu déporter PIGA en utilisant les technologies spécifiques des environnements HPC. Enfin nous appliquerons notre méthode de mesure des performances pour calculer l’impact de la répartition des observateurs sur le système. Nous comparerons la répartition colocalisée et notre architecture distante à haute performance. Nous montrerons l’amélioration de la protection grâce aux moniteurs SELinux et PIGA. 974.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI D’OBSERVATEURS 4.1 Méthode de mesure des performances d’un système réparti d’observateurs 4.1.1 Mesures globales L’objectif est l’impact des observateurs répartis sur les performances d’un nœud client. Nous avons choisi de comparer deux observateurs colocalisés et deux observateurs en mode distant. En effet, le mode colocalisé et le mode distant opèrent sur le même principe sauf que le mode distant nécessite des communications réseaux. On pourra ainsi déduire le gain réalisé grâce au mode distant et il est légitime de penser que cela améliorera les performances du nœud client. Afin d’évaluer l’impact sur les performances du système d’exploitation de ces deux associations, il convient d’avoir un temps de référence (noté tempsreference). Ce temps de référence correspond au temps pris par un appel système, donc à la différence entre son appel tr0 et son retour tr1, sans observateur. Cette méthode de mesure peut être étendue à un jeu de tests, où le premier temps correspond au début du jeu et le second temps à sa fin. Ce temps fait référence au temps sans aucun observateur comme l’illustre la figure 4.1. FIGURE 4.1 – Prise du temps de référence 984.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI D’OBSERVATEURS 4.1.1.1 Mode colocalisé Le second temps concerne la latence générée par le premier observateur, noté temps1_coloc_rr = tl1 − tl0 où tl1 et tl0 correspondent respectivement au temps de fin et de début de l’appel système (ou du jeu de test), colocalisé en mode requête/réponse, illustré par la figure 4.2. FIGURE 4.2 – Prise du temps avec ajout du premier observateur Cette mesure, que l’on nomme temps1_coloc_rr comprend : — le détournement par l’observateur du flux d’exécution ; — la prise de décision de la part du premier observateur ; — le retour de l’observateur. Ces trois éléments mesurés sont illustrés par le diagramme de séquence 4.3. FIGURE 4.3 – Diagramme de séquence illustrant les temps mesurés lors l’ajout d’un seul observateur Le troisième temps est la mesure du temps global, noté temps2_glob_coloc_rr = tgl1 − tgl0, avec deux observateurs colocalisés et associés en mode cascade. Cette prise de temps est illustrée par la figure 4.4. Dans ce cas, le second observateur est aussi en mode requête/réponse. 994.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI D’OBSERVATEURS FIGURE 4.4 – Prise du temps global avec deux observateurs en mode colocalisé Cette mesure, que l’on nomme temps2_glob_coloc_rr comprend : — le détournement par un observateur du flux d’exécution ; — la prise de décision de la part du premier observateur ; — la communication entre les observateurs ; — le temps de prise de décision du second observateur ; — la communication retour entre les deux observateurs ; — le retour du premier observateur. Ces éléments mesurés sont illustrés par le diagramme de séquence 4.5. FIGURE 4.5 – Diagramme de séquence illustrant les temps mesurés lors l’ajout de deux observateurs en mode colocalisé 4.1.1.2 Mode distant Pour la mise en place du second observateur en mode distant, nous introduisons deux nouveaux composants : un client et un serveur. 1004.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI D’OBSERVATEURS Cette quatrième mesure concerne le temps global avec : un observateur local en mode requê- te/réponse associé en mode cascade avec un observateur distant en mode requête/réponse. Ce temps, noté temps2_glob_dist_rr = td1 − td0 où td0 et td1 correspondent respectivement au début et fin de l’appel système, est illustré par la figure 4.6. FIGURE 4.6 – Prise du temps global avec un observateur en mode distant Cette mesure, que l’on nomme temps2_glob_dist_rr comprend : — le détournement par un observateur du flux d’exécution ; — la prise de décision de la part du premier observateur ; — la communication entre le client et le serveur ; — le temps de prise de décision du second observateur ; — la communication entre le serveur et le client ; — le retour du premier observateur. Ces éléments mesurés sont illustrés par le diagramme de séquence 4.7. FIGURE 4.7 – Diagramme de séquence illustrant le temps global distant lors du déport du second observateur 1014.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI D’OBSERVATEURS 4.1.2 Comparaison des performances 4.1.2.1 Combinatoire En reprenant les modes de répartition que nous avons définis dans le chapitre 3, chaque observateur peut avoir : 3 modes de sécurité, 2 modes d’association et 4 modes de localisation possibles. L’ensemble des configurations possibles est 3x2x4=24 pour un seul observateur. Il semble diffi- cile d’évaluer et comparer toutes ces configurations possibles. Nous avons donc restreint l’étude à certaines configurations pour limiter la combinatoire. Ainsi, nous considérons les modes requête/réponse (protection) et évidence (détection) pour deux observateurs en cascade de façon colocalisée et distante. Le nombre de configurations pour un seul observateur, placé sur la même machine que le client, se résume à 1 localisation, 1 association et 2 modes de sécurité, donc 1x1x2=2. Nous avons donc 2 configurations à évaluer. Pour ce premier observateur, il n’y pas de configuration distante car c’est la solution que nous rencontrons en pratique avec SELinux où le moniteur est en mode colocalisé. L’ajout d’un second observateur ajoute un certain nombre de configurations. Pour le second observateur, nous avons : 2 localisations, 2 modes de sécurité et 1 association, donc 2x2x1=4. Ce second observateur crée 4 configurations supplémentaires. Nous avons donc 2x4=8 configurations à évaluer, les 2 du premier multipliées par les 4 du second. Pour résumer, nous devons donc réaliser 8 mesures pour les 8 configurations possibles et les comparer entre elles et avec le temps de référence. A priori, l’instrumentation a peu d’impact et surtout est uniforme avec le temps de référence. En pratique, la réalisation de moyennes sur les temps mesurés lisse la variabilité et le caractère non reproductible des jeux d’essais. 4.1.2.2 Un seul observateur Le tableau 4.1 établit les mesures à effectuer suivant les modes voulus du premier observateur. Mode de sécurité de l’observateur Localisation d’un seul observateur Requête/Réponse Evidence Colocalisé temps1_coloc_rr temps1_coloc_evi TABLE 4.1 – Tableau des mesures à réaliser pour les différents modes d’un seul observateur Nous retrouvons dans ce tableau les 2 mesures pour un seul observateur placé en mode colocalisé avec le client. 4.1.2.3 Deux observateurs Le tableau 4.2 établit les mesures à effectuer suivant les modes voulus du second observateur. Chaque mesure doit donc être réalisée suivant les deux modes possibles du premier observateur soit au total deux tableaux 4.2 pour les deux modes de sécurité du premier observateur. Nous ne précisons ici que les temps pour le second observateur. Mode de sécurité du second observateur Localisation de second observateur Requête/Réponse Evidence Colocalisé temps2_glob_coloc_rr temps2_glob_coloc_evi Distant temps2_glob_dist_rr temps2_glob_dist_evi TABLE 4.2 – Tableau des mesures à réaliser pour les différents modes du second observateur 1024.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI D’OBSERVATEURS 4.1.3 Mesures détaillées En plus des mesures globales que nous venons de présenter, nous allons spécifier des mesures plus détaillées. Nous n’avons réalisé ces mesures que pour le second observateur en mode requê- te/réponse étant donné que c’est celui-ci qui introduit le plus d’attente pour l’appel système. La cinquième mesure concerne, puisque nous sommes dans le mode distant, le temps de communication ainsi que le temps de décision du second observateur en mode requête/réponse comme illustrée par la figure 4.8. De nouvelles mesures au niveau du client permettent d’évaluer le temps tempscomm_observateur2_rr = tgo1 − tgo2, où tgo0 et tgo1 correspondant aux temps d’émission et de réception au niveau du client. FIGURE 4.8 – Prise du temps avec une communication et un observateur en mode distant Cette mesure, que l’on nomme tempscomm_observateur2_rr comprend : — la communication entre les observateurs ; — le temps de prise de décision du second observateur ; — la communication de retour. Cette mesure est illustrée par le diagramme de séquence suivant 4.9. 1034.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI D’OBSERVATEURS FIGURE 4.9 – Diagramme de séquence illustrant les temps mesurés lors d’une communication complète avec le second observateur en mode distant Enfin, la sixième mesure concerne le temps de décision du second observateur en mode requête/réponse, illustrée par la figure 4.10. Cette mesure se fait au niveau du serveur, on la note tempsobservateur2_rr = tod1 − tod0, où tod1 et tod0 sont les réponses et les requêtes envoyées depuis le serveur. FIGURE 4.10 – Prise du temps pour l’observateur 2 en mode distant Cette mesure, que l’on nomme tempsobservateur2_rr comprend : — Le temps de prise de décision du second observateur. Cette mesure est illustrée par le diagramme de séquence suivant 4.11. 1044.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI D’OBSERVATEURS FIGURE 4.11 – Diagramme de séquence illustrant les temps mesurés lors de la prise de décision du second observateur en mode distant 4.1.3.1 Résultats déduits Nous venons de détailler des mesures globales et des mesures détaillées. Mais certains temps ne sont pas mesurables, comme le temps de communication entre le client et le serveur. Cependant, il est calculable. Ainsi, nous proposons un ensemble de calcul de performance issu des mesures effectuées : — Le temps de communication : nous n’avons pas défini de mesure pour déterminer le temps pris par la communication entre les deux observateurs. Il est effet difficile de mesurer de manière précise une communication réseau entre deux machines car il faut synchroniser parfaitement les horloges des deux systèmes. Cependant, ce temps est obtenu en soustrayant deux mesures. 2 ∗ tempscommunication = tempscomm_observateur2_rr − tempsobservateur2_rr (4.1) — Le temps global : même si nous réalisons une mesure du temps global, nous pouvons la vérifier en additionnant des points de mesure. temps2_glob_dist_rr =temps1_coloc_rr + tempscommunication ∗ 2 + tempsobservateur2_rr (4.2) — Nous pouvons en déduire la latence introduite par l’ajout des deux observateurs en mode colocalisé, qui s’obtient de manière naturelle en comparant le temps de référence au temps global, qu’il soit mesuré ou calculé. tempslatence_colocalise_rr = |temps2_glob_coloc_rr − tempsreference| — Nous pouvons en déduire la latence introduite par l’ajout des deux observateurs en mode distant, qui s’obtient de manière naturelle en comparant le temps de référence au temps global, qu’il soit mesuré ou calculé. tempslatence_distant_rr = |temps2_glob_dist_rr − tempsreference| — Nous pouvons ensuite comparer les deux modèles de localisation : colocalisé et distant. Nous pouvons ainsi en déduire l’impact d’une architecture vis-à-vis de l’autre. impactrr = temps2_glob_coloc_rr temps2_glob_dist_rr 1054.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI D’OBSERVATEURS — Taux d’augmentation Comme nous comparons chaque valeur mesurée par rapport à un temps de référence, nous pouvons exprimer le taux d’augmentation introduit au niveau de chaque appel système. Par exemple, le taux d’augmentation pour l’observateur 2 en mode colocalisé est : taux_augmentation = temps2_glob_coloc_rr − tempsreference tempsreference 1064.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT HPC 4.2 Solution pour répartir les observateurs dans un environnement HPC Dans cette section, nous allons nous intéresser au développement d’une solution pour répartir les observateurs dans un environnement HPC. Nous allons donc détailler la mise en place d’une architecture avec deux observateurs pour les systèmes Linux. Le premier observateur est SELinux tandis que le second est PIGA. Cette répartition se fera suivant deux modes de localisation : le mode colocalisé et le mode distant. Dans l’objectif de limiter l’impact sur les performances du nœud client, nous utilisons un réseau InfiniBand pour faire communiquer les deux observateurs entre eux dans le mode distant. Cette architecture a fait l’objet de deux publications : [Blanc et al., 2013a] et [Blanc et al., 2013b]. Nous nous sommes intéressés dans la publication [Blanc et al., 2011] à la protection des nœuds de connexion, en composant en mode colocalisé SELinux et PIGA. 4.2.1 Architecture avec deux observateurs en mode distant Notre modèle de protection se base sur l’ajout de deux observateurs. Nous avons ici choisi d’utiliser SELinux et PIGA, qui réalisent des calculs complémentaires. En effet, SELinux gère les interactions directes alors que PIGA est capable de contrôler les scénarios complets. La figure 4.12 illustre l’architecture globale que nous avons mise en place. Le canal de communication que nous avons choisi est un lien InfiniBand. Nous appelons serveur de sécurité le nœud qui héberge PIGA. FIGURE 4.12 – Architecture décentralisée Dans cette architecture, SELinux est chargé de détourner les flux d’exécution du système pour les traiter et les envoyer à PIGA. Il réalise ce détournement grâce à l’utilisation des LSM. Les deux observateurs sont mis en mode de sécurité cascade, ce qui permet d’attendre la réponse de PIGA lorsque celui-ci est en mode protection ou de simplement transférer les requêtes sans attendre de réponse lorsque PIGA est en mode évidence (détection). 1074.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT HPC 4.2.2 Choix des observateurs 4.2.2.1 SELinux Dans le but de nous rapprocher au maximum des conditions réelles, c’est-à-dire celles mises en place par le CEA, nous avons utilisé un système d’exploitation proche de celui mis en place sur les différents nœuds. Sur les calculateurs tels que Curie, c’est le système d’exploitation Bull Advanced Server qui est déployé. Cette distribution est un clone du système Red Hat Enterprise Linux. Dans ce système d’exploitation, SELinux est intégré et activé par défaut. SELinux étant nativement intégré au noyau Linux, il n’est pas nécessaire de modifier le code du noyau pour le faire fonctionner. De plus, les politiques SELinux fournies avec cette distribution sont fonctionnelles. Mais surtout, notre choix a été motivé par les premières expérimentations que nous avons faites sur l’impact de SELinux sur les performances du système d’exploitation. Comme nous le verrons dans la partie résultat de ce chapitre 4.3.2, l’impact de SELinux est minime sur les performances du système. Il peut donc être intégré, même sur les nœuds de calcul. Cela est rendu possible par les différentes optimisations présentes dans SELinux. Nous pouvons par exemple citer le Access Vector Cache qui va conserver les derniers vecteurs d’accès calculés par SELinux. Ainsi, si une décision est déjà présente dans ce cache, il n’est pas nécessaire de parcourir de nouveau la politique pour rechercher ce vecteur d’accès. Une seconde optimisation de SELinux est la non revérification des droits acquis lors des opérations de lecture ou d’écriture en l’absence de modification des contextes sujets et objets. La figure 4.13 illustre le mécanisme de prise de décision de SELinux : 1. un processus réalise une opération élémentaire (un appel système) (flèche 1) ; 2. SELinux la détourne grâce aux LSM (flèche 2) : ces deux premières étapes correspondent à une requête ; 3. il prend une décision au regard de sa politique de contrôle d’accès (flèche 3) ; 4. si l’interaction est interdite, une trace est inscrite dans le fichier d’audit (flèche 4) : cette étape est une réponse de l’observateur ; 5. un code d’erreur est retourné à l’application ayant fait la requête (flèche 5) ; 6. si l’interaction est autorisée, alors SELinux transmet la requête au noyau pour qu’elle soit exécutée (flèche 6) ; 7. le noyau envoie le retour de l’appel système à l’application (flèche 7) : cette étape est une réponse, ici de l’appel système, qui dans ce cas, n’est pas traitée par SELinux. Chaque décision de SELinux est associée à un access vector. Un vecteur d’accès se compose des contextes sujet et objet, de la classe de l’objet, des opérations élémentaires et enfin de la décision d’accès donnée par SELinux. 4.2.2.2 PIGA Le choix de PIGA a été motivé par le fait qu’il est capable de gérer les scénarios complets en reconstruisant l’activité du système, tout en se basant sur les politiques de SELinux. PIGA est le second mécanisme de protection utilisé dans notre architecture. Il est constitué de deux parties : PIGA-Kernel, qui détourne les interactions autorisées par SELinux et PIGA-UM, qui est le moteur de décision. Il faut noter que PIGA n’a pas été implanté pour avoir un mode de fonctionnement distant, il nous faut donc résoudre ce problème. 1084.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT HPC FIGURE 4.13 – Architecture de prise de décision de SELinux PIGA-Kernel Comme nous l’avons déjà dit, PIGA est basé sur la reconstruction des activités du système. Pour cette reconstruction, PIGA se base sur les vecteurs d’accès générés SELinux. Pour récupérer ces vecteurs, PIGA-Kernel insère un hook directement dans le code de SELinux pour détourner le flux d’exécution. Une fois le flux d’exécution de SELinux détourné, PIGA-Kernel construit sa propre trace avant de l’envoyer à PIGA-UM et il attend une réponse lorsqu’il est placé en mode protection, sinon il rend la main à SELinux. Une fois que la réponse a été calculée, il poursuit l’exécution. Si PIGAUM n’autorise pas l’interaction, PIGA-Kernel modifie le vecteur d’accès de SELinux afin que l’interaction soit refusée, sinon la décision d’accès prise par SELinux est appliquée. PIGA-UM PIGA-UM récupère la trace envoyée par PIGA-Kernel pour reconstruire les activités et vérifie que cette interaction ne fait pas partie d’un ensemble d’activités illégitimes. Une fois que la décision est prise, PIGA-UM la renvoie à PIGA-Kernel. L’insertion des composants PIGA-Kernel et PIGA-UM dans le système, en mode colocalisé, est détaillée dans la figure 4.14. 1. un processus réalise une opération élémentaire (un appel système) qui est détournée par SELinux(flèche 1) : cela correspond à la requête ; 2. SELinux prend une décision au regard de sa politique de contrôle d’accès (flèche 2) ; 3. si l’interaction est autorisée, PIGA-Kernel détourne le flux d’exécution (flèche 3), si l’interaction est refusée par SELinux, le refus est envoyé au processus appelant (flèche 10), cette étape constitue alors une réponse ; 4. PIGA-Kernel envoie la trace à PIGA-UM (flèche 4). En mode détection, il n’attend pas le retour de PIGA-UM et il redonne la main à SELinux (flèche 6) ; 1094.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT HPC 5. PIGA-UM vérifie que cette interaction ne termine pas un scénario complet (flèche 5) ; 6. PIGA-UM envoie une réponse à PIGA-Kernel (flèche 6) ; 7. PIGA-Kernel transmet la réponse à SELinux (flèche 7) ; 8. si l’interaction est refusée, SELinux envoie le refus au processus appelant (flèche 10) : cette étape constitue une réponse ; 9. si l’interaction est autorisée, alors l’appel système est exécuté (flèche 8) ; 10. se noyau envoie le retour de l’appel système à l’application (flèche 9) : cette étape est une réponse, ici de l’appel système, qui dans ce cas, n’est pas traitée par SELinux. FIGURE 4.14 – Insertion de PIGA dans l’architecture en mode colocalisé Il est à noter que PIGA-Kernel autorise l’interaction sans attendre de réponse de la part de PIGA-UM lorsque celui-ci est en mode évidence (ou détection). Dans ce mode, on voit que PIGA est moins pénalisant, au niveau de l’impact sur les performances, pour les processus appelant. 4.2.2.3 Infiniband Pour assurer les communications entre le nœud client et le serveur de sécurité, nous avons fait le choix d’utiliser les réseaux Infiniband. Ce sont des réseaux à très haute performance utilisés dans les environnements HPC qui offrent un important débit et ont une faible latence. La principale particularité de l’architecture Infiniband est qu’elle peut s’appuyer sur différents protocoles pour être intégrée dans des environnements hétérogènes. Il existe plusieurs types de protocoles : Remote Direct Memory Access, IP over IB, ISCSI, etc. Nous avons fait le choix du protocole RDMA car c’est le protocole qui est le plus efficace lors de l’utilisation d’InfiniBand. Le principal avantage du protocole RDMA est qu’il passe directement par le matériel. Le protocole RDMA peut être utilisé suivant deux méthodes : soit la carte du nœud écrit dans la mémoire distante, soit c’est la carte distante qui vient lire dans la mémoire de la première. Nous avons fait le choix d’écrire dans la mémoire distante. La figure 4.15 illustre le fonctionnement d’une communication Infiniband sur RDMA. Un processus veut écrire dans la mémoire d’un processus placé sur une autre machine. Le noyau alloue au driver de la carte Infiniband un espace mémoire (ou plusieurs). Cet espace mémoire sera le tampon d’échange (lecture ou écriture) pour les deux processus impliqués dans la communication. 1104.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT HPC Le processus va écrire dans la mémoire allouée (flèche 1) puis valider l’écriture auprès de la carte de la machine courante. Cette dernière va alors récupérer les informations de la mémoire (flèche 3) pour les écrire directement dans la mémoire du processus distant en utilisant le lien Infi- niBand (flèche 4). Une fois que la carte a fini son opération d’écriture (flèche 5), l’écrivain notifie le lecteur que l’information est disponible (flèche 6) au travers d’une communication InfiniBand. Le lecteur peut accéder au contenu de la mémoire pour récupérer l’information (flèche 7). FIGURE 4.15 – Schéma d’une communication RDMA sur un lien InfiniBand Au cours de cette opération, le noyau n’a jamais été impliqué dans la communication. Ainsi, nous évitons un changement de contexte pour le processus, la création d’un paquet TCP, le parcours des différentes couches du modèle de réseau OSI, etc. 4.2.3 Déport du mécanisme de prise de décision Nous venons de détailler le fonctionnement en local de SELinux, de PIGA et le fonctionnement du protocole RDMA sur des réseaux InfiniBand. Nous allons maintenant, à partir de tous les éléments proposés, définir une architecture permettant de déporter le mécanisme de protection PIGA. Nous proposons un programme que l’on nomme proxy, chargé des échanges entre PIGA-UM et PIGA-Kernel. Le proxy Le proxy est un programme que l’on va retrouver à la fois sur le nœud client, mais aussi sur le serveur de sécurité. Sur le nœud client, il est chargé de récupérer les vecteurs d’accès générés par SELinux et transmis par PIGA-Kernel pour les envoyer sur le lien InfiniBand. Il attend ensuite la réponse provenant du proxy serveur de sécurité pour la transmettre à SELinux. Le proxy serveur récupère les vecteurs d’accès envoyés par le client, les transmet à PIGA-UM, puis renvoie la décision d’accès de PIGA-UM sur le lien InfiniBand. 4.2.3.1 Le nœud client Nous allons présenter l’architecture simplifiée mise en place sur un nœud client, illustrée par la figure 4.16. 1114.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT HPC FIGURE 4.16 – Architecture de protection sur un nœud client Comme nous l’avons décrit auparavant, SELinux détourne le flux d’exécution régulier pour prendre une décision (flèche 1). Si l’interaction est autorisée par SELinux, PIGA-Kernel intercepte à son tour le flux (flèche 2) pour le transmettre au proxy client (flèche 3), qui va l’envoyer au serveur (flèche 5) par le lien InfiniBand. Le proxy client attend la réponse du proxy serveur et la récupère toujours sur le lien InfiniBand (flèche 5). Il transmet la réponse à PIGA-Kernel (flèche 6) qui la renvoie à SELinux (flèche 7). Si l’accès est autorisé, le vecteur d’accès n’est pas modifié. Dans le cas contraire, une modification du vecteur d’accès a lieu pour interdire l’interaction. Cette décision est enfin transmise au processus (flèche 8). Si la décision est interdite, elle sera enregistrée dans un fichier d’audit. La figure 4.17 représente l’architecture complète mise en place sur le nœud de calcul et le chemin du contrôle d’une interaction directe. 1. un processus réalise une interaction directe (un appel système) qui est détournée par la couche LSM ; 2. la couche LSM transmette cette requête à SELinux : c’est la requête ; 3. SELinux prend une décision au regard de sa politique de sécurité ; 4. si SELinux autorise l’opération, alors le vecteur d’accès est détourné par PIGA-Kernel ; 5. PIGA-Kernel transmet la trace au proxy ; 6. le proxy envoie cette trace sur le lien Infiniband ; 7. le proxy récupère la réponse du serveur de sécurité ; 8. il la transmet à PIGA-Kernel ; 9. PIGA-Kernel la renvoie à SELinux ; 10. si l’interaction est interdite (soit par SELinux, soit par PIGA), alors la trace est enregistrée dans le fichier d’audit ; 11. si l’interaction est refusée, un retour spécifique est envoyé au processus : c’est une réponse ; 12. sinon, la requête est transmise au noyau, qui l’exécute ; 13. le noyau envoie le retour au processus, non traité par SELinux, c’est une réponse. 1124.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT HPC FIGURE 4.17 – Architecture détaillée du contrôle d’accès sur un nœud client 4.2.3.2 Le proxy serveur Sur le serveur distant, nous n’avons que deux éléments : le proxy serveur et le moniteur de référence PIGA-UM. La figure 4.18 illustre l’architecture du contrôle mise en place sur le serveur de sécurité. FIGURE 4.18 – Architecture sur le serveur de sécurité 1. Le proxy récupère la trace sur le lien InfiniBand ; 2. Il la transmet à PIGA-UM ; 3. PIGA-UM prend une décision au regard de sa politique de sécurité ; 4. Il envoie sa décision au proxy ; 5. Le proxy la transmet au nœud de calcul en utilisant le lien InfiniBand. 1134.3. EXPÉRIMENTATIONS 4.3 Expérimentations Nous venons de détailler la mise en place d’une architecture décentralisée basée sur l’utilisation de deux observateurs : SELinux et PIGA. Pour faire communiquer ces deux observateurs, nous avons implanté un proxy qui gère les différentes communications entre les observateurs. Nous allons maintenant nous attacher à comparer l’impact sur les performances d’une architecture en mode colocalisé avec une architecture où un des observateurs est déporté. Nous allons pour cela, nous appuyer sur le modèle d’analyse que nous avons défini dans la section 4.1.1. Pour réaliser des mesures de temps précises et surtout reproductibles, nous avons utilisé deux logiciels : le premier se nomme linpack et le second est un programme permettant de stresser les observateurs en faisant beaucoup d’entrées/sorties. 4.3.1 Les moyens de mesure Pour tester l’impact sur les performances de la répartition de deux observateurs, nous avons défini deux types de tests : un test de référence appliqué dans le HPC, et un logiciel spécifique stressant les deux moniteurs de référence SELinux et PIGA. Le premier test que nous avons réalisé se base sur le logiciel de benchmark linpack 1 . Ce logiciel est utilisé pour classer les calculateurs dans le monde entier (voir le site Internet top500 2 ). Nous avons configuré ce logiciel au moyen du fichier de configuration disponible en annexe A. La particularité de ce logiciel est qu’il réalise très peu d’accès disque et d’appels système. C’est essentiellement du calcul en mémoire qui est réalisé, et il va de surcroit utiliser le nombre maximum de cœurs du processeur. Pour le stress, nous avons créé un logiciel spécifique qui réalise le scénario suivant : 1. ouverture d’un fichier présent sur le système, correspondant à l’appel système sys_open ; 2. lecture d’un nombre constant d’octets dans un tampon mémoire, correspondant à l’appel système sys_read ; 3. fermeture du fichier, correspondant à l’appel système sys_close ; 4. création d’un nouveau fichier avec un nom aléatoire sur le disque local, correspondant à l’appel système sys_open ; 5. écriture du tampon dans le fichier, correspondant à l’appel système sys_write ; 6. fermeture du fichier, correspondant à l’appel système sys_close ; Le code utilisé est mis en annexe B. Nous avons réalisé ce test pendant une durée d’une heure et les prises de temps sont réalisées en début et fin de séquence pour avoir une vision macroscopique des latences qui sont dues au modèle de protection. Ce test nous permet d’estimer l’impact du modèle de protection sur le système dans, ce que l’on peut considérer comme le pire des cas pour les mécanismes de protection. En effet, le scénario effectue beaucoup d’appels système puisqu’il ne fait que des entrées/sorties. Toutefois, réaliser des tests sur un système de fichiers peut soulever quelques problèmes. En effet, il ne faut pas que les mesures soient influencées par le cache du système de fichiers, ou par la vitesse d’écriture du disque dur. C’est pourquoi, nous avons réalisé la prise de temps en début et en fin de scénario, plutôt qu’entre chaque appel système car cela permet de linéariser les effets des différents caches présents sur le système. Ce test est réalisé de manière séquentielle, c’est-à-dire qu’un seul cœur du processeur est utilisé durant l’expérimentation. 1. http://www.netlib.org/benchmark/hpl/ 2. http://top500.org 1144.3. EXPÉRIMENTATIONS 4.3.2 Résultats sur les performances Nous présentons ici les résultats pour les 8 temps globaux que nous avons présentés dans la section 4.1.1. Comme nous l’avons dit, nous allons comparer ces mesures avec une mesure de référence prise sans aucun observateur. Nous présentons ici les résultats que nous avons obtenus pour comparer les modèles de répartition sur les performances des systèmes. Nous allons découper ces résultats en partant d’une vision globale puis isoler chaque élément de la prise de décision grâce au modèle vu en section 4.1.1. 4.3.2.1 Architecture d’expérimentation Les expérimentations que nous présentons ici ont toutes été réalisées sur des machines physiques pour être les plus précises possibles. En effet, la virtualisation ajoute une couche de complexité et entraîne des effets de bords qu’il est difficile d’annuler. Les nœuds clients Nous disposions de deux machines parfaitement identiques pour réaliser des calculs. Nous avons ainsi pu réaliser des tests en mode colocalisé et en utilisant notre architecture décentralisée. Les nœuds de calcul disposent de deux processeurs Intel(R) Xeon(R) X5450 cadencés à 3,00 GHz. Ils disposent chacun de 8 Go de mémoire vive. Les tests sont réalisés sur un système de fichiers en ext4, avec un matériel en RAID-10, sur des disques en SAS à 15 000 tours par minutes. Nous avons choisi comme distribution Scientific Linux 6, qui un clone de RHEL 6. Les paquets formant le système de base sont les mêmes entre les deux distributions. Comme nous avons eu besoin de modifier le noyau, nous avons modifié un RPM source de Red Hat nommé 2.6.32-279.5.2.el6. SELinux a été modifié pour ne charger que 37 modules. Nous avons supprimé du chargement de la politique les modules inutiles sur un nœud de calcul tels que le module mozilla, ou encore openoffice. La politique SELinux ne contient plus que 79196 règles d’autorisation alors que la politique de référence en contenait 240669. De plus, nous avons défini des politiques SELinux spécifiques pour que linpack et notre logiciel stressant le système de fichiers soient autorisés. Le serveur de sécurité Le serveur de sécurité est une machine dédiée qui dispose de deux processeurs Intel(R) Xeon(R) E5405 cadencés à 2,00 GHz. Ce nœud dispose lui aussi de 8 Go de mémoire vive. Le système installé est aussi du Scientific Linux 6. Sur cette machine, nous avons déployé PIGA-UM, qui s’exécute en espace utilisateur, avec l’ensemble de propriété de sécurité du listing 4.1. Ces propriétés de sécurité sont générales et assurent la confidentialité des utilisateurs vis-à-vis des personnes présentes dans le rôle staff_r ainsi que des personnes présentes dans le rôle sysadm_r, l’intégrité des fichiers de configuration et des domaines linpack et staff_t. En traitant à la fois de la confidentialité et de l’inté- grité, nous configurons PIGA dans le pire des cas car cela génère un grand nombre d’activités à surveiller. Le canal de communication Les deux machines sont connectées en Ethernet et en InfiniBand. Le nœud de calcul et le serveur de sécurité disposent de la même technologie de carte Mellanox Technologies MT26428 offrant un débit théorique maximum de 40 Gb par secondes. 1154.3. EXPÉRIMENTATIONS ✞ ☎ 1 confidentiality( $sc1:="user_u:user_r:user.*_t", $sc2:=system_u:object_r:etc_t ); 2 3 confidentiality( $sc1:=system_u:object_r:nfs_t, $sc2:=user_u:user_r:user_t ); 4 confidentiality( $sc2:=system_u:object_r:nfs_t, $sc1:=user_u:user_r:user_t ); 5 6 confidentiality( $sc1:=system_u:object_r:nfs_t, $sc2:=staff_u:staff_r:staff_t ) ; 7 confidentiality( $sc2:=system_u:object_r:nfs_t, $sc1:=staff_u:staff_r:staff_t ) ; 8 9 confidentiality( $sc1:="user_u:user_r:user.*_t", $sc2:="staff_u:staff_r:staff.* _t" ); 10 confidentiality( $sc2:="user_u:user_r:user.*_t", $sc1:="staff_u:staff_r:staff.* _t" ); 11 12 confidentiality( $sc1:="user_u:user_r:user.*_t", $sc2:="sysadm_u:sysadm_r: sysadm.*_t" ); 13 confidentiality( $sc2:="user_u:user_r:user.*_t", $sc1:="sysadm_u:sysadm_r: sysadm.*_t" ); 14 15 integrity( $sc1:="user_u:user_r:user.*_t", $sc2:=".*:.*:.*etc_t" ); 16 integrity( $sc1:="staff_u:staff_r:staff.*_t", $sc2:=".*:.*:.*etc_t" ); 17 18 domainintegrity( $CHROOT:="staff_u:staff_r:linpack.*" ); 19 domainintegrity( $CHROOT:="staff_u:staff_r:staff.*" ); ✝ ✆ Listing 4.1 – Propriétés de sécurité appliquées pour les tests de performances 4.3.2.2 Mesures globales L’objectif est tout d’abord de déterminer la latence globale au niveau de l’application due à notre modèle de protection. Linpack Ce test a été fait pendant une durée de 23 heures. Linpack réalise plusieurs types d’opérations, c’est-à-dire des calculs matriciels, et propose le temps mis pour réaliser le calcul comme le montre l’extrait 4.2. Il réalise 18 opérations différentes. Nous faisons une moyenne du temps mis et de la puissance calculée pour les différents tests que nous avons réalisés. ✞ ☎ 1 T/V N NB P Q Time Gflops 2 WR00L2L2 26752 128 2 4 8117.16 1.573e+00 ✝ ✆ Listing 4.2 – Extrait d’un fichier de résultat de linpack Le tableau 4.3 propose les résultats d’un ensemble de tests effectués pour connaître l’impact sur les performances du système d’exploitation des différentes répartitions d’observateurs. Comme les premiers résultats obtenus avec SELinux (en mode requête/réponse mais aussi en mode évidence) sont concluants, nous avons réalisé les expérimentations suivantes avec SELinux uniquement en mode requête/réponse. Nous comparons donc 6 temps globaux avec le temps de référence. De plus, dans le but de minimiser les traitements réalisés par PIGA, il est nécessaire de bloquer les interactions directes lorsqu’elles ne sont pas autorisées dans la politique de contrôle d’accès. C’est pour cela que nous avons réalisé les tests en ajoutant PIGA uniquement avec SELinux en mode protection. Pour cela, nous avons tout d’abord réalisé un premier test avec aucune protection obligatoire, que ce soit SELinux ou PIGA. C’est le test de référence. Puis nous avons ajouté un à un chaque 1164.3. EXPÉRIMENTATIONS moniteur dans le but d’avoir des résultats précis et exploitables. Nous avons donc ajouté SELinux à nos tests en utilisant les modes : détection et protection. Lors du test de ces deux modes, SELinux disposaient de la même politique de sécurité. On peut noter une légère amélioration des résultats lorsque SELinux est activé sur la machine. Cela peut s’expliquer par le fait que SELinux va bloquer des programmes concurrents et ainsi, linpack ne sera pas préempté. Nous avons ensuite ajouté PIGA en mode détection pour avoir une première vision de l’impact de ce mécanisme. Nous avons réalisé ces tests avec une version en mode colocalisé puis avec une version décentralisée. L’objectif étant de savoir si le déport d’un observateur apportait réellement un plus au niveau de l’impact sur les performances du système d’exploitation. Les résultats obtenus avec Linpack montrent que la version décentralisée n’impacte pas les performances du système d’exploitation. La version en mode colocalisé de PIGA génère une faible latence. Temps en secondes Puissance en GFlops tempsref erence 8 124 1.571 SELinux détection : temps1_coloc_evi 8 118 1.572 SELinux protection : temps1_coloc_rr 8 111 1.575 SELinux/PIGA colocalisé : temps2_glob_coloc_evi 8 127 1.571 SELinux/PIGA colocalisé : temps2_glob_coloc_rr 8 130 1.570 SELinux/PIGA distant : temps2_glob_dist_evi 8 121 1.572 SELinux/PIGA distant : temps2_glob_dist_rr 8 114 1.573 TABLE 4.3 – Tableau des résultats avec l’utilisation de linpack avec PIGA Le tableau 4.3 présente aussi les résultats obtenus, toujours avec linpack, mais cette fois-ci, PIGA est mis en mode protection. Dans cette configuration, SELinux est toujours placé en mode enforcing. L’utilisation de PIGA en mode distant améliore légèrement les performances vis-à-vis du mode colocalisé. Stress des moniteurs répartis Notre second test vise à réaliser un maximum d’appels système afin de solliciter de manière soutenue les observateurs répartis. Nous rappelons brièvement le protocole de test. Le programme est lancé pendant une heure et réalise en boucle le scénario des actions : ouverture, lecture, fermeture, création, écriture, fermeture. Nous récupérons le nombre de jeux/scénarios réalisés. Le temps indiqué est le temps moyen de chaque scénario correspondant à un jeu de test. Le tableau 4.4 présente les résultats que nous avons obtenus en stressant le système de fichiers. Dans ce tableau, nous détaillons les résultats obtenus avec le moniteur PIGA mis en mode détection. Dans chaque test, nous avons mis SELinux en mode protection puisque la première mesure, temps1_coloc_rr présente dans ce tableau, confirme que l’impact de SELinux en mode requête/ré- ponse est négligeable par rapport au temps de référence, mais aussi à son mode évidence. En mode détection, avec SELinux et PIGA en mode colocalisé, nous multiplions par 6 le temps moyen par scénario, ce qui conduit à réduire de moitié le nombre de scénarios. Avec PIGA en distant, nous réduisons cette latence. Ainsi nous obtenons un temps moyen multiplié par 3 et un nombre d’opérations réduit d’un tiers par rapport au mode avec le seul moniteur SELinux. Le tableau 4.4 donne aussi les résultats obtenus avec PIGA en mode protection. Avec PIGA en mode colocalisé, nous divisons par 5 le nombre de scénarios et nous multiplions le temps moyen par 13. Cependant, nous améliorons avec PIGA en mode distant puisque le nombre de scénarios réalisés est divisé par 2 et le temps moyen est multiplié par 5. 1174.3. EXPÉRIMENTATIONS Nombre de scénarios temps par scénario en µs tempsreference 5 176 731 689 SELinux : temps1_coloc_evi 5 176 731 691 SELinux : temps1_coloc_rr 5 176 731 692 SELinux + PIGA colocalisé temps1_glob_coloc_evi 2 481 727 3 787 SELinux + PIGA colocalisé temps1_glob_coloc_rr 1 133 107 7 954 SELinux + PIGA distant temps2_glob_dist_evi 3 889 542 1 717 SELinux + PIGA distant temps2_glob_dist_rr 2 746 805 3 186 TABLE 4.4 – Table détaillant l’impact avec stress des moniteurs répartis À partir de ces différentes mesures, obtenues en mode détection et en mode protection, nous pouvons estimer le temps moyen par appel système. Pour cela, nous divisons le temps moyen par scénario par le nombre d’opérations élémentaires réalisées par notre programme, c’est-à-dire 6. Ces résultats, illustrés par le tableau 4.5, nous permettent, tout d’abord, de calculer un temps moyen par appel système (ou plus exactement par interaction) au niveau de notre système. Ensuite, nous sommes capables d’estimer le surcoût induit par la répartition de deux observateurs, que ce soit en mode cololocalisé ou en mode distant : — colocalisé : en mode protection, le surcoût est de 1211 µs par appel système alors qu’en mode détection il n’est que de 517 µs ; — distant : en mode protection le surcoût est de 417 µs par appel système alors qu’en mode détection, il n’est que de 172 µs. temps moyen/scénario en µs temps moyen/appel système en µs Sans SELinux : tempsref erence 689 114,3 SELinux temps1_coloc_rr 692 115,3 SELinux + PIGA colocalisé : temps2_glob_coloc_evi 3 787 631,12 SELinux + PIGA colocalisé : temps2_glob_coloc_rr 7 954 1325,6 SELinux + PIGA distant : temp2_glob_dist_evi 1 717 286,16 SELinux + PIGA distant : temp2_glob_dist_rr 3 186 531 TABLE 4.5 – Table détaillant le temps moyen par appel système Il faut rappeler que ces surcoûts correspondent à notre avis au pire des cas et que celui-ci est peu représentatif des environnements HPC. En effet, dans la pratique, les codes de calcul ne font pas autant d’entrée/sortie, mais réalisent des calculs en mémoire. 4.3.2.3 Mesures détaillées Afin de définir où sont les surcoûts des observateurs répartis, nous appliquons notre méthode de mesure définie en section 4.1.1. Dans cette partie, nous nous sommes exclusivement intéressés au mode distant car c’est cette architecture qui vise à être implantée dans un environnement HPC. L’objectif est de donc d’utiliser notre solution pour analyser les performances sur cette architecture. Nous réalisons ces tests uniquement pour le mode requête/réponse de PIGA. Grâce à nos premiers tests, nous avons montré que ce n’était pas SELinux qui générait une latence. Toutes les mesures vont nous permettre de quantifier les surcoûts aux différents endroits. Estimation du coût d’une communication complète avec prise de décision du second observateur Nous avons réalisé des mesures de temps au niveau du proxy client déployé sur le nœud client. Cette mesure, tempscomm_observateur2_rr, consiste à connaitre le temps pris par la suite d’instructions suivantes : 1184.3. EXPÉRIMENTATIONS 1. le proxy a déjà lu la trace générée par PIGA-Kernel donc cette interaction n’est pas prise en compte dans la mesure ; 2. il prend le premier temps ; 3. il envoie la trace au serveur de sécurité et attend la réponse ; 4. il obtient une réponse ; 5. il prend le deuxième temps. Le diagramme de séquence 4.19 détaille toutes les opérations qui se déroulent pendant la mesure. FIGURE 4.19 – Diagramme de séquence illustrant la mesure faite au niveau du proxy coté nœud de calcul Cette mesure a été réalisée sur une moyenne d’un million de communications entre le nœud client et le serveur de sécurité. Nous obtenons une valeur moyenne de 260 µs pour le temps tempscomm_observateur2_rr, une valeur maximum de 400 µs et une valeur minimum 200 µs. Lecture d’une trace avec une prise de décision Cette première mesure montre que la latence est générée, soit par la communication, soit par la prise de décision de la part de PIGA. Nous allons donc mesurer le temps de prise de décision de PIGA, tempsobservateurs2_rr. 1. le proxy lit la trace en mémoire ; 2. la première mesure de temps est déclenchée ; 3. le proxy transmet la trace à PIGA. 4. PIGA prend une décision d’accès ; 5. le proxy récupère la décision ; 6. la seconde mesure de temps est réalisée. Ainsi, en prenant le temps au niveau du proxy, nous pouvons déterminer le temps pris par PIGA pour prendre une décision d’accès. Cette procédure est illustrée par le diagramme de sé- quence 4.20. On obtient un temps de prise de décision moyen pour PIGA de 220 µs, qui correspond au temps tempsobservateurs2_rr. Tout comme pour la précédente mesure, ce temps est obtenu en faisant une moyenne sur un échantillon d’un million d’appels à PIGA. Afin d’être précis, nous avons fait cette mesure au niveau du proxy qui est en C plutôt qu’au niveau de PIGA qui est en Java. 1194.3. EXPÉRIMENTATIONS FIGURE 4.20 – Diagramme de séquence illustrant la mesure faite au niveau du proxy serveur pour calculer le temps de prise de décision de PIGA Coût d’une communication À partir des deux dernières mesures, nous pouvons en déduire le coût d’une communication entre le proxy client et le proxy serveur. En nous basant sur les moyennes obtenues, on obtient un temps 260−220 2 soit 20 µs, correspondant au temps tempscommunication. Les messages échangés entre les deux proxys ont une taille maximale de 300 octets. Mesures spécifiques Nous avons dû réaliser des mesures spécifiques inhérentes à l’architecture que nous avons choisie et plus précisément, à la mise en place du proxy sur le nœud de calcul. En effet, de part sa conception, il doit récupérer les traces générées par PIGA-Kernel pour les envoyer sur le lien InfiniBand et il doit ensuite renvoyer à PIGA-Kernel les décisions d’accès prises par PIGA. Pour ce faire, nous avons choisi d’utiliser le système de fichiers procfs. Nous avons donc deux pipes nommés : pigaseq et piga_rep. Le premier permet au proxy de lire les traces provenant de l’espace noyau tandis que le second lui permet d’écrire les décisions d’accès. Nous avons donc dû mesurer le temps pris par le proxy pour lire et écrire dans ces pipes. Pour cela, nous avons daté l’envoi des traces ainsi que sa réception. Le temps de lecture par le proxy donne, en moyenne, 10 µs. Par contre, la mesure de l’écriture se révèle beaucoup plus difficile à réaliser. Dans le but d’avoir une valeur correcte, nous allons prendre la valeur moyenne que nous avons calculée dans ce tableau 4.5, à savoir 115 µs. 4.3.2.4 Synthèse des mesures Nous allons dans cette partie synthétiser les mesures que nous avons réalisées sur la répartition de deux observateurs au sein d’une architecture distribuée. En nous appuyant sur le tableau 4.5, nous pouvons calculer que la latence générée en mode protection (ou requête/réponse) par l’architecture décentralisée de 417 µs. Ce nombre est la somme de : 1. le temps de la prise de décision de la part de PIGA tempsobservateurs2_rr : 220 µs ; 2. le temps de la communication (aller-retour) 2 ∗ tempscommunication : 40 µs ; 1204.3. EXPÉRIMENTATIONS 3. le temps de lecture et d’écriture de la part du proxy dans les pipes pour communiquer avec PIGA-Kernel : 10 + 114 µs ; 4. le temps introduit par SELinux temps1_coloc_rr : 1 µs. On obtient pour résultat 385 µs, soit une différence de 32 µs avec la mesure globale. Ce résultat s’explique par le fait que nous avons à chaque fois pris des moyennes sur un échantillon donné, donc il existe toujours une marge d’erreur non négligeable. De plus, grâce à toutes ces différentes mesures, nous pouvons voir que les mécanismes de mesure de temps n’influent pas ou peu sur le temps global. Nous proposons ce diagramme de séquence 4.21 qui nous permet de résumer de manière simple les différentes mesures que nous avons effectuées pour connaitre les points qui peuvent être améliorés en termes de performance. Ce diagramme illustre la répartition de SELinux avec PIGA en mode protection (temp2_glob_dist_rr). FIGURE 4.21 – Diagramme de séquence résumant les différentes mesures effectuées au sein de l’architecture distribuée Nous proposons une synthèse des temps calculés dans le tableau suivant 4.6 établi par rapport aux résultats sur les expérimentations du stress du système de fichiers. temps par appel système en µs tempsreference 114,3 SELinux temps1_coloc_rr 115,3 SELinux + PIGA colocalisé : temps2_glob_coloc_evi 631,12 SELinux + PIGA colocalisé : temps2_glob_coloc_rr 1325,6 SELinux + PIGA distant : temp2_glob_dist_evi 286,16 SELinux + PIGA distant : temp2_glob_dist_rr 531 Communication + PIGA distant tempscomm_observateur2_rr 260 PIGA distant tempsobservateur2_rr 220 TABLE 4.6 – Tableau résumant les mesures effectuées pour la répartition de deux observateurs Nous proposons une synthèse des temps déduits dans le tableau suivant 4.7 établi par rapport aux résultats sur les expérimentations du stress du système de fichiers. Ce tableau montre que le déport du second moniteur de référence permet de réduire l’impact sur le nœud client. Ce gain se situe entre 2,2 et 2,5 par rapport au mode colocalisé. 1214.3. EXPÉRIMENTATIONS temps en µs tempscommunication 20 tempslatence_coloc_evi 517 tempslatence_coloc_rr 1211 tempslatence_dist_evi 172 tempslatence_dist_rr 417 impactevi 2,2 impactrr 2,5 TABLE 4.7 – Tableau résumant les temps calculés Cette amélioration vient, d’une part par l’utilisation des technologies spécifiques à faibles latences des environnements HPC (InfiniBand et RDMA) et, d’autre part, par le déport de PIGAUM. En déportant ce composant de notre architecture qui le plus consommateur en terme de ressources système (mémoire et processeur), nous réduisons son impact sur le nœud de calcul. De plus, comme PIGA-UM dispose d’une machine dédiée, il ne sera plus pré-empté par un autre processus et disposera de toute la puissance qui lui est nécessaire. 1224.4. AMÉLIORATION DE LA SÉCURITÉ 4.4 Amélioration de la sécurité Dans cette partie, nous nous intéressons à l’attaque que nous avons présentée en introduction de ce mémoire1.3. Nous montrons comment nous contrôlons cette attaque grâce à l’utilisation des observateurs SELinux et PIGA. Pour pouvoir contrôler ce scénario complet, il est nécessaire tout d’abord de définir une propriété de sécurité qui sera appliquée par PIGA. Puis nous montrerons comme PIGA est capable de détecter ce scénario complet. 4.4.1 Propriété de sécurité Nous montrons ici qu’il est possible d’utiliser PIGA pour améliorer la sécurité et traiter les scénarios complets d’attaque. À partir du scénario complet que nous avons étudié en introduction de ce mémoire (voir la section 1.3), nous allons exprimer une propriété de sécurité permettant de le contrôler. Le listing 4.3 montre la définition de la propriété de sécurité que nous avons donnée à PIGA. ✞ ☎ 1 define exploit_staff_kernel( $sc1 IN CS, $sc2 IN CS, $sco1 IN CSO ) [ 2 Foreach $eo1 IN is_execute_like(IS), Foreach $a1 IN ACT, Foreach $a2 IN ACT 3 TQ { ( $sc2 -> { $eo1 } $sco1 o $sc1 -> { $eo1 } $sco1 ) } , 4 { not( exist() ) } ; 5 ]; ✝ ✆ Listing 4.3 – Propriété de sécurité contrôlant l’exploitation de la faille perf_event Cette propriété se décrit de la manière suivante. Elle s’assure qu’il n’existe aucun lien not( exist() ) entre l’enchaînement des interactions suivantes : tout d’abord le contexte de sécurité $sc1 fait une opération d’exécution sur le contexte de sécurité $sco1 puis que le contexte de sécurité $sc2 réalise lui aussi une opération d’exécution sur le contexte de sécurité $sco1. La fonction not( exist() ) s’assure qu’il n’y a aucun lien entre ces deux interactions. Ce lien peut être : un contexte de sécurité partagé, un processus en commun, une filiation, etc. sc1 −−−−→ execute sco1 sc2 −−−−→ execute sco1 Nous avons appliqué cette propriété de la manière suivante 4.4. ✞ ☎ 1 exploit_staff_kernel( sc1:=staff_u:staff_r:staff_t, 2 sc2:=system_u:system_r:kernel_t, 3 sco1:=system_u:object_r:shell_exec_t ); ✝ ✆ Listing 4.4 – Application de la propriété de sécurité pour contrer l’exploitation de la faille Le contexte de sécurité sc1 correspond au contexte de sécurité de connexion de notre utilisateur de test. Ici nous avons choisi que ce dernier puisse être dans le rôle staff_r. Le contexte de sécurité sc2 correspond aux sujets qui s’exécutent en espace noyau. Or, comme la faille permet d’exploiter une faille au sein même du noyau, son contexte d’exécution sera system_u:system_r:kernel_t. Le contexte de sécurité sco1 correspond au contexte de sécurité des objets du système de type shell, comme bash, zsh, etc. Comme l’exploit lance un shell depuis l’espace noyau, nous avons décidé de bloquer explicitement cette exécution. 1234.5. DISCUSSION 4.4.2 Application de la propriété de sécurité Pour appliquer cette propriété, PIGA a besoin de la politique de contrôle d’accès de SELinux. L’objectif de PIGA est de trouver les chemins autorisés dans la politique permettant de violer la propriété de sécurité que nous venons de décrire. À partir de cette propriété de sécurité seule et en parcourant la politique de SELinux, PIGA a détecté 6 activités pouvant mener à violer la propriété de sécurité. Le listing 4.5 montre le résultat d’une détection de la part de PIGA lorsque l’utilisateur tente d’exploiter la faille. ✞ ☎ 1 ( system_u:system_r:kernel_t -( file { execute } )-> system_u:object_r: shell_exec_t rond staff_u:staff_r:staff_t -( file { execute } )-> system_u: object_r:shell_exec_t ) | 172.30.3.1 55031 system_u:system_r:kernel_t-> system_u:object_r:shell_exec_t:file execute;2180 2081 -1 -1 exploit null 138016 2 ( system_u:system_r:kernel_t -( file { execute_no_trans } )-> system_u:object_r :shell_exec_t rond staff_u:staff_r:staff_t -( file { execute_no_trans } )-> system_u:object_r:shell_exec_t ) | 172.30.3.1 55034 system_u:system_r: kernel_t->system_u:object_r:shell_exec_t:file execute_no_trans;2180 2081 -1 -1 exploit null 138016 ✝ ✆ Listing 4.5 – Détection par PIGA de la violation de la propriété de sécurité Nous retrouvons dans cette détection les deux activités visées. La première concerne l’exécution par l’utilisateur du shell 4.6, puis nous avons une seconde activité qui détecte l’exécution du shell par le noyau 4.7. ✞ ☎ 1 staff_u:staff_r:staff_t -( file { execute } )-> system_u:object_r:shell_exec_t ) ✝ ✆ Listing 4.6 – Première activité détectée par PIGA ✞ ☎ 1 system_u:system_r:kernel_t -( file { execute } )-> system_u:object_r: shell_exec_t ✝ ✆ Listing 4.7 – Deuxième activité détectée par PIGA Nous sommes donc bien capables de détecter et de prévenir les scénarios d’attaque complets correspondant à de réelles vulnérabilités grâce à l’association de deux observateurs. 4.5 Discussion Dans ce chapitre, nous avons proposé un modèle d’évaluation des performances pour la répartition des observateurs. Cette méthode permet de comparer les modes colocalisés et distants. Cette méthode conduit à comparer 8 mesures globales à un temps de référence sans observateur. Nous ajoutons à cette méthode des mesures détaillées qui permettent de connaître précisément les temps de communication entre les deux observateurs pour le mode distant ainsi que le temps de décision pour le second observateur. Nous avons ensuite proposé une architecture originale pour déporter de manière efficace le second observateur. Nous avons pour cela exploité les technologies spécifiques des environnements HPC afin de minimiser les temps de communication. Nous avons mis en place cette architecture avec les moniteurs de référence SELinux et PIGA. Pour l’échange des requêtes, un proxy client et un proxy serveur permettent les communications sur des liens InfiniBand entre les deux moniteurs. Nous avons enfin réalisé des expérimentations dans le but de comparer deux observateurs en mode colocalisé avec deux observateurs en mode distant. Nous avons pour cela appliqué notre mé- thode d’évaluation des performances sur l’architecture que nous avons mise en place. Durant ces 1244.5. DISCUSSION expérimentations, les deux moniteurs sont utilisés en mode requête/réponse et en mode évidence, ce qui conduit à devoir comparer 8 mesures avec un temps de référence. Pour établir ces mesures, nous avons utilisé dans les premières expérimentations le logiciel Linpack, un logiciel spécialement utilisé dans les environnements HPC. Les résultats que nous avons obtenus montrent que la répartition des observateurs SELinux et PIGA n’impactent pas les performances du code de calcul car Linpack réalise essentiellement des calculs mémoire et peu d’entrées/sorties. On peut donc considérer que ce logiciel se place dans le meilleur des cas quant à l’impact des observateurs sur les performances. Dans la seconde expérimentation, nous avons voulu tester le pire des cas pour les observateurs en stressant le système de fichiers. Nous résumons les taux d’augmentation pour chaque temps global dans le tableau 4.8. Nous rappelons que dans les modes d’association colocalisés et distants, le premier observateur (SELinux) est toujours placé en mode requête/réponse. Mesure temps en µs surcoût en % tempsreference 114,3 temps1_coloc_evi 115,3 0.8 temps1_coloc_rr 115,3 0.8 temps2_glob_coloc_evi 631 453 temps2_glob_coloc_rr 1325 1062 temps2_glob_dist_evi 286 150 temps2_glob_dist_rr 531 365 TABLE 4.8 – Tableau détaillant le surcoût de la répartition Ce tableau montre que le mode distant améliore d’un facteur 3 les performances de la répartition des observateurs. Il est nécessaire de rappeler que ces chiffres sont donnés pour le pire des cas et qu’il n’y a pas de code de calcul qui réalise autant d’entrées/sorties lors de son exécution. A contrario, les résultats de Linpack représentent le meilleur des cas, puisque sur une durée de 23 heures, ce logiciel fait seulement 3000 opérations d’entrée/sortie. Nous pouvons dire qu’un code de calcul "standard" se situe entre les deux. De plus, nous avons volontairement choisi une configuration, au niveau des propriétés de sécurité PIGA, non optimale puisque nous garantissons l’intégrité et la confidentialité pour tout le système. Un gain important pourrait être obtenu en affinant les propriétés de sécurité PIGA et en évitant les propriétés contrôlant les flux indirects. Dans la pratique, un code de calcul fait des entrées/sorties sur le système de fichiers essentiellement pour réaliser des checkpoints (points de sauvegarde en cas de panne). Ces entrées/sorties se traduisent pas l’écriture (ou la lecture) de fichiers ayant une taille importante mais générant peu d’appels, donc les moniteurs sont moins sollicités que dans notre scénario de stress. Par consé- quent, le comportement d’un code de calcul sera plus proche du comportement de Linpack que de notre logiciel pour stresser les moniteurs de référence. Nous notons que le logiciel Linpack réalise environ 3000 appels système en 23 heures, soit 0,036 appels système par secondes (soit 2,17 par minutes) alors que notre logiciel de stress réalise 5 000 000 d’appels système en 1 heure, soit 1 388 appels système par secondes. Dans le cas de Linpack, nous ne notons aucune augmentation de la latence tandis que l’impact du stress du système de fichiers est compris entre 150 et 365 % pour le mode distant, que ce soit en mode évidence ou requête/réponse. Cependant, aucun de ces deux logiciels ne correspond exactement au nombre d’entrées/sorties d’un code de calcul. Par une estimation linéaire, nous pouvons estimer qu’un code de calcul réalise entre 100 et 200 appels système par secondes, nous pouvons estimer l’impact suivant les modes de répartition : — en mode évidence (détection) et distant, l’impact sur les performances du code de calcul serait compris entre 10 et 20%. Puisqu’un ordre de 1500 appels système par secondes 1254.5. DISCUSSION correspond (environ) à un impact de 150%, on obtient par estimation linéaire un impact de 150/1500x100 soit 10% pour 100 appels système par secondes. — en mode requête/réponse (protection) et distant, l’impact sur les performances du code de calcul sera entre 25 et 50% par estimation linéaire. Pour l’instant, il semble difficile de mettre en place une répartition de deux observateurs tels que SELinux et PIGA sur les nœuds de calcul sans nuire aux performances. Le gain réalisé par le déport du second moniteur en mode détection introduisant un surcoût de l’ordre de 10%. Néanmoins, l’amélioration des politiques PIGA devrait permettre de passer à un surcoût plus faible, potentiellement de l’ordre de 5% selon les propriétés requises. D’autres améliorations sur le moteur de PIGA devrait permettre d’aller encore en dessous. Les autres nœuds du calculateur sont moins demandeurs en termes de performance. Nous pouvons par exemple citer les nœuds de visualisation ou de connexion. Les nœuds de visualisation sont utilisés pour présenter graphiquement les résultats obtenus lorsque les calculs sont finis. Sur ce type de nœuds, les programmes chargent des fichiers de taille importante (plusieurs téraoctets) mais réalisent peu d’appels système. Par conséquent, l’impact devrait être acceptable pour la visualisation. Pour les nœuds de connexion, ils sont utilisés pour accéder au calculateur, ce sont donc des nœuds exposés aux attaques. En effet, les utilisateurs disposent d’un accès ssh leur permettant de déposer leur code de calcul, tester leur code, etc. Sur ces types de nœuds, les besoins en performances sont moins importants que sur les nœuds de calcul mais les besoins en sécurité sont donc plus importants. Ce type de nœuds est donc tout à fait candidat pour utiliser nos deux moniteurs répartis en mode protection. Enfin, nous avons illustré l’efficacité de deux moniteurs pour prévenir les scénarios complets d’attaque. Pour la vulnérabilité réelle décrite en introduction de ce mémoire, nous avons défini une propriété de sécurité qui prévient le scénario de façon optimiste c’est-à-dire qui laisse les activités légitimes avancer. Il est à noter que la propriété est générique car elle prévient toutes les vulnérabilités de ce type. 126Chapitre 5 Contrôle d’accès obligatoire pour Windows et Expérimentations Dans l’état de l’art 2.3.5, nous avons montré la nécessité d’avoir un moniteur de référence pour les systèmes Windows. Dans le chapitre 3, nous avons défini un modèle de moniteur pour contrôler les interactions directes. Nous proposons dans ce chapitre une implantation fonctionnelle d’un tel moniteur pour les systèmes Windows. Un moniteur de référence doit mettre en place des mécanismes de détournement du flux d’exé- cution au sein du système, afin d’appliquer les décisions prises par la partie moniteur de référence de notre implantation. Notre moniteur de référence implante les deux modèles de protection obligatoires que nous avons présentés dans la section 3.2, à savoir les modèles PBAC et DTE. Pour obtenir une politique PBAC portable sur les différents systèmes Windows, nous apportons une réponse à la problématique de désignation des ressources. Pour le modèle DTE, nous proposons de calculer dynamiquement les contextes de sécurité à chaque interaction. Toutefois, l’écriture d’une politique de sécurité pour tout un système est une tâche complexe et laborieuse et nous avons donc mis en place un mécanisme facilitant leur écriture. Ce mécanisme se base sur les traces générées par l’observateur pour dériver, de manière automatique, les règles correspondantes. Ce chapitre est divisé en quatre parties. Dans une première partie, nous traiterons de la problé- matique de création des politiques. Nous proposerons une solution pour résoudre la problématique de la construction des noms symboliques absolus indépendants de la localisation. Nous présenterons enfin notre mécanisme de génération automatique de la politique. La seconde partie sera consacrée à l’implantation de deux Policy Enforcement Point, c’est-à- dire des méthodes pour détourner le flux d’exécution régulier du système, que nous avons décrites dans la partie 3.3. Nous avons ici choisi de nous focaliser sur le détournement de la table des appels système et sur la création d’un filter-driver. Nous expliquerons en détail le fonctionnement de ces deux méthodes. La troisième partie traitera des expérimentations que nous avons réalisées. Dans une première section, nous montrerons que nous sommes capables de bloquer des attaques simples visant à violer une propriété de sécurité telle que la confidentialité. Nous illustrerons les limites de ce mécanisme grâce à des scénarios d’attaques complets. Pour franchir ces limites, nous introduirons l’utilisation d’un second moniteur, PIGA. Dans une seconde section, nous proposerons des modifications de notre moniteur pour l’orienter sur l’étude des logiciels malveillants. Nous présentons les modifications apportées ainsi que la plateforme mise en place pour faciliter l’interprétation des résultats. Pour cela, nous reprendrons l’exemple que nous avons présenté dans l’introduction de ce mémoire 1.3. 1275.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT Enfin, la dernière partie discutera les choix que nous avons faits ainsi que les limites de notre implantation. L’implantation de la solution basée sur le modèle DTE et sur le détournement de la table des appels système a fait l’objet d’une publication [Gros et al., 2012]. L’application des propriétés de sécurité est détaillée dans [Blanc et al., 2012]. Une application du modèle de protection a été proposée au sein des clouds dans [Blanc et al., 2014]. 5.1 Politique de contrôle d’accès direct Cette section s’intéresse à la création et à la gestion des politiques de contrôle d’accès direct. Nous traitons dans cette partie les deux modèles de protection, PBAC dans un premier temps puis le modèle DTE dans un second temps. Chaque sous-section est organisée ainsi : dans une première partie, nous expliquerons les choix réalisés pour représenter les ressources du système. Puis, nous aborderons la création d’une politique de contrôle d’accès s’appliquant à chaque modèle de protection. Enfin, nous détaillerons le mécanisme d’automatisation pour générer des politiques de sécurité. 5.1.1 Path-Based Access Control Représentation du système Nous avons détaillé dans la partie 3.2.1.1 la problématique du système de nommage des fichiers sous Windows. Pour résoudre ce problème, nous proposons l’utilisation de noms symboliques absolus indépendants de la localisation. L’implantation choisie se base sur l’utilisation des variables d’environnement présentes sous les systèmes Windows. Les variables d’environnement dites "système", c’est-à-dire gérées directement par le noyau, sont communes à tous les systèmes Windows. On peut par exemple citer systemroot qui est la variable d’environnement pointant sur le répertoire d’installation du dossier Windows. Pour simplifier leur utilisation, nous utilisons les dénominations utilisées en batch, ce qui se traduit par l’utilisation de la syntaxe %systemroot%. En utilisant les variables d’environnement, nous sommes capables de gé- nérer des politiques de sécurité portables sur chaque système Windows. Par exemple, le fichier C:\Windows\system32\cmd.exe se transforme en %systemroot%\System32\cmd.exe. Cette méthode fonctionne aussi bien pour les sujets que pour les objets de type fichier. Les répertoires sont traités de la même façon. Tous les répertoires système possèdent une variable d’environnement associée. Lorsqu’un répertoire est au niveau du point de montage du système mais ne possède pas de variable d’environnement associée, il suffit d’utiliser la variable définie pour le point de montage du système %systemdrive%. Pour étendre ce modèle aux disques ou aux partitions qui seraient montés sur un autre lecteur et qui ne possèderaient pas de variables associées, il est nécessaire d’en créer de nouvelles. Concrètement, si une partition est montée sur la lettre D: et ne contient aucun dossier système comme les répertoires des utilisateurs ou des programmes, il est nécessaire de la nommer avec une variable comme %datadrive%. La gestion du registre est simplifiée par rapport à celle du système de fichiers. Les ruches, qui sont les éléments qui hébergent les clés du registre, sont identiques sur tous les systèmes Windows. On peut donc s’en servir comme espace de noms pour désigner les clés. Ainsi, la clé CurrentVersion qui est dans la ruche HKEY_LOCAL_MACHINE, est représentée par le chemin \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion. Les éléments du réseau se gèrent aussi de façon naturelle. Ils peuvent être identifiés à la fois par un couple d’adresse IP et de port, soit par le nom des hôtes. Pour qu’il n’y ait pas de confusion 1285.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT entre un objet local et un objet réseau, nous les préfixons par l’espace de nom RES. Ainsi l’objet 192.168.1.254 avec le port 80 est représenté par la directive RES/192.168.1.254 80. Nous avons la même directive pour les noms d’hôte, par exemple RES/www.google.fr 80. Extrait d’une politique basée sur les chemins complets Nous avons précisé dans le listing 3.9 les terminaux propres au modèle de protection PBAC. De plus, la définition de la grammaire générique 3.1 précise la forme des vecteurs d’accès que nous reprenons dans ce listing 5.1 : ✞ ☎ 1 vecteur_acces : contexte Delimiteurs_debut? (liste_operations_elementaires)+ Delimiteurs_fin? ; ✝ ✆ Listing 5.1 – Règle générique d’un vecteur d’accès extrait de la grammaire générique Donc à partir de ces différents éléments, nous allons pouvoir écrire une politique de sécurité basée sur le modèle de protection PBAC. Ainsi, le listing 5.2 illustre la manière d’autoriser le sujet %systemroot%\explorer.exe à lire (r) et exécuter (x) l’objet ayant pour chemin %systemroot%\System32\cmd.exe. Ce fichier se situe donc dans le répertoire d’installation du dossier Windows. Le sujet %systemroot%\explorer.exe est aussi autorisé à aller lire (r) et écrire (w) dans le fichier %programfiles%\fichier.txt, dont la variable d’environnement correspond au répertoire nommé Program Files. ✞ ☎ 1 %systemroot%\explorer.exe { 2 %systemroot%\System32\cmd.exe rx 3 %programfiles%\fichier.txt rw 4 } ✝ ✆ Listing 5.2 – Extrait d’une politique de type TPE Pour les accès au registre, les règles s’écrivent de la même façon. Ainsi le listing 5.3 montre comment autoriser le sujet %systemroot%\explorer.exe à lire (r) la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion. ✞ ☎ 1 %systemroot%\explorer.exe { 2 HKEY_LOCAL__MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion r 3 } ✝ ✆ Listing 5.3 – Extrait d’une politique de type PBAC pour le registre Pour les autorisations liées aux objets du réseau, nous écrivons la politique suivante 5.4. Ainsi la première ligne autorise le sujet %systemroot%\explorer.exe à se connecter (c) au domaine www.google.fr vers le port 80. ✞ ☎ 1 %systemroot%\explorer.exe { 2 RES\www.google.fr 80 c 3 } ✝ ✆ Listing 5.4 – Extrait d’une politique de type PBAC pour le réseau Création d’une politique basée sur le modèle PBAC La création d’une politique au format PBAC peut se faire de manière manuelle mais aussi automatique. Ces deux méthodes peuvent se faire en se basant sur une trace d’audit. Cette méthode simplifie l’écriture des règles d’accès. 1295.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT Pour faciliter l’administration d’une politique de contrôle d’accès basée sur le modèle PBAC, nous proposons l’utilisation d’un outil capable d’automatiser la création d’une telle politique en utilisant les fichiers d’audit générés par le moniteur de référence. Nous présentons la méthode d’automatisation plus en détail dans la section 5.1.4. Ainsi, à partir du listing 5.5, nous avons généré la règle 5.6. ✞ ☎ 1 type=PBAC audit(1174358746:36452) ips:denied { read execute } for pid=2004 comm ="%systemroot%\explorer.exe" ppid=872 path="%systemroot%\system32\audiodev. dll" tclass=file ✝ ✆ Listing 5.5 – Trace d’audit pour l’implantation utilisant le modèle PBAC ✞ ☎ 1 subjet %systemroot%\explorer { 2 %systemroot%\system32\audiodev.dll rwa 3 } ✝ ✆ Listing 5.6 – Règle de contrôle d’accès pour le modèle PBAC résultat de l’apprentissage Une fois que la règle a été ajoutée à la politique courante et que l’observateur a rechargé cette nouvelle politique, lorsque le moniteur observe que l’interaction courante est présente dans la politique, il va le spécifier dans la trace qu’il génère. Il faut noter que, mis à part le timestamp et l’identifiant de trace qui sont modifiés, la seule différence se trouve dans la décision prise par l’observateur qui passe de denied à granted comme le montre les traces 5.5 et 5.7 ✞ ☎ 1 type=PBAC audit(1174956145:264) ips:granted { read execute } for pid=1024 comm= "%systemroot%\explorer.exe" ppid=988 path="%systemroot%\system32\audiodev. dll" tclass=file ✝ ✆ Listing 5.7 – Trace d’audit pour l’implantation utilisant le modèle PBAC Trusted Path Execution Nous avons défini les répertoires de confiance à partir d’une installation classique d’un système Windows. Ainsi, les répertoires %systemroot% et %systemroot%\System32 qui sont les répertoires d’installation du système, et %programfiles%, qui est le répertoire d’installation des applications tierces, sont des répertoires de confiance. Naturellement, pour qu’un fichier puisse être exécuté, il est nécessaire qu’une règle d’accès autorise un sujet à l’exécuter. La définition des répertoires de confiance permet de mettre en place une règle d’accès simple qui stipule que tout sujet qui souhaite exécuter un fichier qui n’est pas dans un de ces dossiers, verra son accès refusé. Les répertoires d’où sont exécutés les exécutables que l’administrateur autorise, sont notés en début de politique sous la forme suivante 5.8 : ✞ ☎ 1 tpe { 2 %programfiles% 3 %systemroot% 4 } ✝ ✆ Listing 5.8 – Définition des répertoires de confiance 5.1.2 Domain and Type Enforcement Labellisation Le second modèle de protection que nous avons traité est le modèle DTE. Nous avons présenté les avantages d’utiliser ce modèle de protection dans la section 3.2.2.2. 1305.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT Sur les systèmes Linux supportant SELinux, les contextes de sécurité des objets sont stockés dans les attributs étendus du système de fichiers. Ces informations sont disponibles en utilisant les commandes comme ls -Z ou encore getfattr. Un exemple de résultat est montré dans le listing 5.9. Il est possible de stocker ces informations car le système de fichiers prévoit la possibilité d’avoir des noms arbitraires d’attributs étendus. L’avantage de cette technique est la persistance des contextes mais celle-ci pose des problèmes pratiques. ✞ ☎ 1 getfattr -m security.selinux -d pol.xml.bak 2 # file: pol.xml.bak 3 security.selinux="system_u:object_r:default_t:s0" ✝ ✆ Listing 5.9 – Récupération des attributs étendus sous Linux Cependant, dans le cas de Windows, il n’est pas prévu d’étendre le système de fichiers pour ajouter des contextes de sécurité comme sous Linux car c’est un système de fichiers propriétaire (NTFS). Par conséquent, plutôt que de les stocker, nous avons fait le choix de les calculer dynamiquement. Cette opération se déroule durant la phase de prétraitement du moniteur de référence (phase 2.1 de la figure 3.9). Le calcul à la volée des contextes de sécurité implique une considération importante : il est nécessaire de pouvoir identifier précisément chaque ressource. Sous SELinux, le fait d’avoir des contextes de sécurité non uniques est compensé par l’impossibilité pour un utilisateur de modifier les contextes. Ainsi, SELinux s’appuie à la fois sur le nom de la ressource mais aussi sur son contexte pour différencier les objets sur le système. Le calcul à la volée des contextes ne permet pas de faire cette distinction dans ce cas. Par exemple, il n’est pas possible de différencier un fichier explorer.exe qui se trouve dans C:\Windows\explorer.exe et dans C:\Users\Damien\explorer.exe, lorsque les contextes de sécurité ne sont basés que sur le nom relatif des fichiers. Pour résoudre ce problème, nous avons utilisé notre approche de désignation des ressources déjà appliquée au modèle PBAC. Ainsi, nous offrons une méthode dynamique et portable. Nous ajoutons une couche d’abstraction par l’utilisation des noms symboliques absolus indépendants de la localisation. Dans ce cas, nous avons aussi utilisé les variables d’environnement puisqu’elles sont communes à tous les systèmes Windows. À partir de ces choix, nous pouvons labelliser le système. Nous rappelons qu’un contexte de sécurité est constitué d’une identité, d’un rôle, d’un type pour les objets et d’un domaine pour les sujets. Dans l’implantation actuelle, nous n’utilisons ni l’identité, ni les rôles. Nous nous sommes concentrés sur les types et les domaines tout comme le fait SELinux. Les objets Dans la section 3.2.2.2 où nous avons présenté notre formalisation pour la description des objets dans le modèle de protection DTE, nous avons défini des catégories pour identifier la nature des ressources. Par exemple, un répertoire a un type associé finissant par dir_t. Le listing 5.10 exprime une règle de correspondance entre le chemin exprimé sous la forme de variable d’environnement et le contexte de sécurité qui lui est associé. Nous noterons que tous les objets possèdent les mêmes identité et rôle system_u:object_r. Le rôle object_r précise explicitement que ce contexte de sécurité se rattache à un objet du système. ✞ ☎ 1 %programfiles% system_u:object_r:programfiles_dir_t ✝ ✆ Listing 5.10 – Contexte de sécurité associé au répertoire Program Files Le contexte de sécurité des objets calculé à la volée fait apparaître son chemin complet dans le système de fichiers. Ainsi, si l’objet courant est dans un point de l’arborescence avec plusieurs répertoires parents, son contexte contiendra tous ces répertoires. Pour aider à la lecture des contextes de sécurité dans les fichiers d’audit, nous séparons chaque répertoire par 1315.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT le caractère |. Ce caractère étant un caractère interdit dans le nom des fichiers et des répertoires sous Windows, nous sommes sûrs qu’il n’apparaîtra pas dans le nom des objets. Par exemple, le répertoire C:\Program Files\Mozilla\Plugins a pour contexte de sécurité system_u:object_r:programfiles|mozilla|plugins_dir_t. La construction du contexte de sécurité pour les fichiers se fait de façon similaire. Cependant, un répertoire possède une catégorie spécifique aux répertoires, c’est-à-dire un suffixe dir_r ajouté au type de son contexte de sécurité, il faut aussi définir les catégories pour les fichiers. Pour faciliter la reconnaissance faite par le moniteur de référence, il va se baser sur les extensions des fichiers pour en extraire leur catégorie. Nous obtenons un grand nombre de catégories possibles pour les fichiers : exécutable, bibliothèque, driver, un document Word, etc. Dans ces catégories, nous portons une attention toute particulière à un sous-ensemble : les fichiers qui peuvent être exécutés comme les binaires exécutables mais aussi les bibliothèques, ainsi que les fichiers pouvant transporter une charge virale tels que les fichiers pdf ou MS Word. Les fichiers ont aussi un suffixe spécifique dans leur type qui représente leur catégorie. Ainsi, un fichier exécutable, classiquement représenté par son extension .exe, aura comme type exec_t. Un driver, qui a pour extension .sys aura comme type sys_t. Ainsi, le fichier C:\Windows\system32\cmd.exe a pour contexte de sécurité system_u:object_r:systemroot|system32|cmd_exec_t. De manière analogue, les fichiers de bibliothèques dynamiques (dll) ont un type se finissant par lib_t. Grâce à cette méthode de labellisation dynamique, chaque objet du système possède un contexte de sécurité précis basé sur sa place dans l’arborescence du système de fichiers. Cependant, cette méthode conduit à avoir potentiellement un nombre important de contextes de sécurité. Nous avons donc prévu un traitement spécifique pour certains répertoires dans lesquels fichiers et répertoires ont tous le même contexte de sécurité. Cette exception dans notre méthode de labellisation dynamique s’applique essentiellement pour les dossiers temporaires. En effet, il n’est pas possible de prévoir le contenu de ce type de dossiers dans le but de pouvoir faire une politique de contrôle d’accès. Prenons un répertoire temporaire tel que C:\Temp, si un utilisateur y crée un fichier, alors il aura pour contexte de sécurité system_u:object_r:tmp_t. Les sujets Les contextes de sécurité sujet sont construits à partir du nom relatif du fichier du binaire exécuté. Les identités et rôles utilisés sont génériques pour l’instant. Par exemple, le processus explorer.exe a pour contexte de sécurité le label system_u:system_r:explorer_t. Il n’est pas nécessaire de stocker tout le chemin du binaire dans le contexte de sécurité sujet. L’objectif est d’alléger les traces et les politiques, ainsi que de faciliter leur lecture. Cependant, nous pourrions tout à fait stocker tout le chemin dans le contexte de sécurité comme pour les objets. Le registre Dans l’implantation proposée, nous ne faisons qu’une labellisation générique du registre. Cela signifie que tous les objets du registre ont pour contexte de sécurité system_u:object_r:registry_t. Néanmoins, à partir de la formalisation que nous avons proposée, nous pouvons définir les contextes de sécurité pour les objets du registre. Ainsi, en utilisant les mêmes méthodes que pour le modèle PBAC, c’est-à-dire en utilisant le nom de la ruche comme namespace, on peut construire les contextes de sécurité en utilisant tout le nom de la clé. On utilisera aussi le même séparateur que celui utilisé pour les chemins dans le nom des objets, à savoir |, pour décrire l’arborescence de la clé. 1325.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT On utilisera aussi des catégories spécifiques. Ainsi, une clé aura pour suffixe key_t, alors qu’une valeur aura pour catégorie value_t. Le listing 5.11 montre sur deux exemples le résultat sur une clé et sur une valeur. ✞ ☎ 1 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run system_u: object_r:hkey_local_machine|software\microsoft|windows|currentversion| run_key_t 2 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run|Avira system_u :object_r:hkey_local_machine|software\microsoft|windows|currentversion| run_avira_value_t ✝ ✆ Listing 5.11 – Exemples d’associations d’éléments du registre et de contextes de sécurité Extrait d’une politique basée sur les types Comme pour le modèle de protection PBAC, nous avons formalisé les terminaux pour le modèle de protection DTE dans le listing 3.12. La spécification des terminaux nous permet de définir de manière explicite les traitements que l’observateur doit réaliser lorsqu’il intercepte les interactions directes. Les règles d’autorisation sont plus complexes que dans le cas de PBAC car les permissions exprimées sont basées sur les appels système, donc avec une plus grande finesse. Ainsi, pour autoriser (allow) un sujet ayant comme domaine explorer_t à exécuter un invite de commande, il faut, tout d’abord, l’autoriser à récupérer des informations et à lire le fichier binaire. Cette règle est représentée par la ligne 1 du listing 5.12. Ensuite on doit l’autoriser à exécuter le fichier binaire pour en faire un processus, ce qui est représenté pour la ligne 2 du listing. ✞ ☎ 1 allow explorer_t systemroot|system32|cmd_exec_t:file { read execute create getattr } 2 allow explorer_t systemroot|system32|cmd_exec_t:process { execute } ✝ ✆ Listing 5.12 – Extrait d’une politique SEWindows Lors de l’exécution d’un fichier binaire (généralement un .exe), il se produit une transition du type du fichier vers un domaine. Par exemple, lorsque le sujet ayant comme domaine explorer_t exécute un invite de commande, soit le binaire C:\Windows\system32\cmd.exe qui a pour contexte de sécurité objet system_u:object_r:%systemroot%|system32|cmd_exec_t, le nouveau processus transite vers le contexte de sécurité sujet system_u:system_r:cmd_t. Le contrôle des accès pour le registre se fait de manière similaire. Il est possible d’associer chaque opération du registre à une opération élémentaire (lire, écrire, exécuter, etc). Donc la création d’une règle d’accès pour le registre se fait comme une règle pour le système de fichiers. Le listing 5.13 détaille une règle pour la lecture du contenu d’une clé. ✞ ☎ 1 allow explorer_t hkey_local_machine|software|microsoft|windows|currentversion| run_key_t:key { read execute } ✝ ✆ Listing 5.13 – Extrait d’une politique SEWindows pour la gestion du registre Nous avons défini dans la grammaire trois traitements possibles pour une règle d’accès. L’instruction allow autorise de manière explicite les interactions. L’instruction allowaudit va gé- nérer un message dans le fichier d’audit spécifiant que cette règle a été utilisée. Elle peut être utilisée pour surveiller des interactions particulières. Toutefois elle n’autorise pas l’interaction, pour cela, elle doit être complétée avec une règle allow. Enfin, l’instruction neverallow empêche explicitement l’interaction décrite par la règle d’accès. Cette règle prime sur toute règle allow autorisant la même interaction. 1335.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT Création de la politique basée sur le modèle DTE Comme pour le modèle de protection PBAC, la création d’une politique pour le modèle DTE peut se faire de manière manuelle ou automatique. Nous allons ici décrire la création de règles d’accès à partir d’une trace générée par le moniteur. Nous allons détailler cette création sur un exemple concret. Nous avons lancé l’application Windows Media Player. Au niveau du mécanisme de création de processus de Windows, c’est le processus %systemroot%\explorer.exe qui lance le processus qui a pour nom wmplayer.exe. Cette opération se traduit par la génération de plusieurs traces. Nous avons extrait deux traces pour illustrer notre propos. Dans un premier temps, le processus %systemroot%\explorer.exe va demander les opérations élémentaires { read execute create getattr } sur le fichier %programfiles%\windows media player\wmplayer.exe comme le montre la première ligne du listing 5.14. Le processus de labellisation transforme les noms et chemins des fichiers en contexte de sécurité comme expliqué dans la partie 5.1.2 . Ainsi, le processus %systemroot%\explorer.exe aura pour contexte de sécurité sujet system_u:system_r:explorer_t. De la même façon, l’objet %programfiles%\windows media player\wmplayer.exe aura pour contexte de sécurité system_u:system_r:programfiles|windowsmediaplayer|wmplayer_exec_t. Avec ces éléments, nous sommes capables de créer une première règle pour notre politique de contrôle d’accès comme le montre la première règle du fichier de politique présent en listing 5.15. Ensuite, il y a une deuxième interaction faite par le sujet qui est la création du processus. Cette interaction se traduit au niveau du moniteur par une seconde trace. La différence se fait sur la classe de l’objet. En effet, sur la première trace, l’interaction se fait sur le fichier, alors que la deuxième trace concerne une création de processus, c’est-à-dire à la transition du fichier vers son domaine. Pour autoriser la création du processus, il est nécessaire d’ajouter la deuxième ligne présente dans le listing 5.15. ✞ ☎ 1 type=DTE audit(1285242977:13) avc:denied { read execute create getattr } for pid=1576 comm="%systemroot%\explorer.exe" ppid=1528 path="%programfiles%\ windows media player\wmplayer.exe" scontext=system_u:system_r:explorer_t tcontext=system_u:object_r:programfiles|windowsmediaplayer|wmplayer_exec_t tclass=file 2 type=DTE audit(1285242977:14) avc:denied { execute } for pid=1576 comm="% systemroot%\explorer.exe" ppid=1576 path="%programfiles%\windows media player\wmplayer.exe" scontext=system_u:system_r:explorer_t tcontext= system_u:object_r:programfiles|windowsmediaplayer|wmplayer_exec_t tclass= process ✝ ✆ Listing 5.14 – Extrait d’un fichier d’audit ✞ ☎ 1 allow explorer_t programfiles|windowsmediaplayer|wmplayer_exec_t:file { read execute create getattr } 2 allow explorer_t programfiles|windowsmediaplayer|wmplayer_exec_t:process { execute } ✝ ✆ Listing 5.15 – Règles de contrôle d’accès créées à partir d’une trace 5.1.3 Modes de fonctionnement Notre moniteur de référence a trois modes de fonctionnement : disabled, permissif (évidence) aussi appelé détection et enforcing ou protection (requête/réponse). Dans le mode disabled, le flux 1345.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT d’exécution n’est pas détourné par le moniteur et aucune décision n’est calculée. Nous allons donc détailler dans cette section les deux autres modes du moniteur. Mode détection (Évidence) Le mode détection, ou permissif, est un mode dans lequel le moniteur n’applique pas sa décision. Le flux d’exécution est détourné, une décision est bien calculée au regard de la politique, mais elle n’est pas appliquée. Ce mode peut aussi fonctionner sans aucune politique prédéfinie, dans ce cas, toutes les interactions seront considérées comme refusées. Cette particularité peut se révéler intéressante pour l’étude des logiciels malveillants puisqu’il sera alors possible d’enregistrer toutes les opérations qui se déroulent au sein du système. Ce mode a deux objectifs : la première, il permet de créer une politique de contrôle d’accès pour un nouveau programme et la seconde, il permet de valider la politique. Ce mode peut aussi être appelé mode d’apprentissage quand il est utilisé pour créer une politique. La création de la politique se fait à partir des traces générées par le moniteur. Une fois les traces générées, l’écriture de la politique peut se faire de manière manuelle ou automatique comme nous le détaillons dans la section 5.1.4. Chaque interaction est vérifiée dans la politique et une trace est générée spécifiant si cette interaction est autorisée, c’est-à-dire qu’il existe une règle d’accès dans la politique qui l’autorise, sinon l’interaction est refusée. Le mode apprentissage peut être réalisé avec ou sans politique de sécurité. Si une politique existe, les traces contiennent le terme granted stipulant que l’interaction est autorisée dans la politique courante comme le montre le listing 5.16. La règle pour autoriser cette interaction a été définie dans le listing 5.12. ✞ ☎ 1 type=DTE audit(1285243100:4600) avc:granted { execute } for pid=1576 comm="% systemroot%\explorer.exe" ppid=1576 path="%systemroot%\system32\cmd.exe" scontext=system_u:system_r:explorer_t tcontext=system_u:object_r:systemroot |system32|cmd_exec_t tclass=process ✝ ✆ Listing 5.16 – Extrait d’un fichier d’audit autorisant une interaction Une fois que l’administrateur considère avoir réalisé toutes les interactions nécessaires pour que son programme puisse fonctionner et avant de passer le moniteur en mode protection, ce qui pourrait bloquer la machine, il peut valider sa politique dans le mode détection en vérifiant les traces générées. Ce mode peut aussi se révéler utile dans des environnements où seule la détection des interactions est voulue. Mode protection (Requête/Réponse) Le mode protection, ou enforcing, est le mode dans lequel le moniteur applique les décisions. Si une interaction n’est pas dans la politique de contrôle d’accès, alors elle sera bloquée par le moniteur et une trace sera générée pour notifier l’administrateur de ce refus. 5.1.4 Définition des politiques Les politiques de contrôle d’accès peuvent être écrites soit de façon manuelle, soit de manière automatique grâce à l’outil que nous proposons. Nous allons dans cette section détailler les deux fonctionnements. 1355.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT Automatisation Nous proposons un outil pour la création automatique d’une politique de contrôle d’accès, quel que soit le modèle de protection. Grâce à cette automatisation, la politique s’écrit par répétition. Pour réaliser cet apprentissage, il est nécessaire de mettre le moniteur en mode détection, ainsi le programme ou processus pour lequel on veut créer la nouvelle politique ne sera pas bloqué. Prenons un exemple illustré par la figure 5.1. Nous désirons ici ajouter un programme sur notre système d’exploitation, il faut donc ajouter les règles d’accès correspondantes pour qu’il puisse fonctionner correctement. Ce mode peut fonctionner avec ou sans politique de base. Si le moniteur n’a pas de politique de base, il va enregistrer toutes les interactions faites sur le système, même celles qui ne sont pas réalisées par le programme que l’on veut ajouter. La méthodologie d’apprentissage est la suivante. On change le mode du moniteur en détection. On lance une première fois le nouveau programme (flèche 0 du schéma). Le moniteur trace les interactions du processus (flèche 1) et les enregistre dans le fichier d’audit (flèche 2). Notre outil parcourt le fichier d’audit (flèche 3) et transforme automatiquement les traces en règles d’accès au bon format, c’est-à-dire PBAC ou DTE. Ces nouvelles règles sont ajoutées à la politique courante (flèche 4) puis cette nouvelle politique est rechargée par le moniteur (flèche 5). Le processus ou programme que l’on veut ajouter est ensuite relancé. La fin du processus d’apprentissage est laissée à la discrétion de l’administrateur. En effet, il n’est pas possible de déterminer de manière certaine quand un programme a réalisé toutes les interactions de manière automatique. Par exemple, pour une application graphique, il faut que l’administrateur réalise lui-même les tâches qu’il souhaite autoriser. Il est donc conseillé d’avoir une check-list précisant les tâches nécessaires au moment de lancer l’apprentissage. L’apprentissage peut être considéré comme terminé lorsqu’on a réalisé toutes les tâches listées dans la check-list et qu’il n’apparaît plus aucune trace d’accès bloqué. FIGURE 5.1 – Schéma décrivant l’apprentissage d’une politique 1365.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT Avantages Le principal avantage de cette méthode d’écriture de la politique de contrôle d’accès est sa grande facilité de mise en place. En effet, il suffit de lancer le programme d’apprentissage et de réaliser les tâches nécessaires au sein du programme que l’on veut ajouter pour que les règles soient automatiquement générées. En plus de facilité l’écriture, cela l’accélère aussi. De plus, si l’administrateur a minutieusement réalisé toutes les tâches désirées au sein du nouveau programme, il ne devrait pas avoir à modifier plus tard sa politique. Cependant, lors d’une mise à jour du programme, il peut être nécessaire de recommencer l’opération pour ajouter automatiquement les nouvelles règles dans la politique mais les tâches sont prédéfinies. Inconvénient Le principal inconvénient de cette méthode est la nécessité pour l’administrateur de vérifier, à la main, les règles qui ont été ajoutées par l’outil dans la politique. En effet, il est possible que le programme que l’on veuille ajouter, réalise des interactions malveillantes ou illégitimes pour l’administrateur, cachées par des tâches "normales". Par exemple, on pourrait imaginer un programme qui tente de copier la partie du registre contenant les mots de passe des utilisateurs. Lors de la phase d’apprentissage, cette interaction ne sera pas bloquée par le moniteur et par apprentissage, elle sera ajoutée à la politique courante. Si l’administrateur ne vérifie pas les règles, cette interaction malveillante sera aussi autorisée même en mode protection. Il est donc nécessaire pour l’administrateur de vérifier les règles qui ont été ajoutées pour un programme. C’est pour cela que nous conseillons d’avoir au préalable une politique déjà écrite prenant en compte le reste du système, pour ne pas être parasité par les autres applications. Manuelle La seconde méthode pour créer une politique est de le faire de façon manuelle. Nous pouvons définir deux cas : soit l’administrateur connait précisément ce que fait le programme qu’il veut ajouter, dans ce cas, il écrit toutes les règles, soit il utilise la même méthode que pour l’automatisation, en transformant manuellement les traces en règles d’accès. Dans les deux cas, le moniteur peut être utilisé soit en mode détection pour plus de facilité, soit en mode protection. Avantages Le principal avantage de cette méthode est que l’administrateur maîtrise entièrement le processus de création des règles d’accès. Il peut ainsi vérifier qu’il n’autorise pas une interaction malveillante ou illégitime pour le nouveau programme. Inconvénient Le principal inconvénient est que cette méthode est beaucoup plus coûteuse en temps. En effet, la retranscription à la main de chaque règle peut se révéler être un travail très fastidieux, surtout dans le cas des mises à jour des programmes qui les modifient intégralement, voire pour les mises à jour du système. 5.1.5 Discussion Nous venons de détailler l’implantation choisie pour les modèles de protection PBAC et DTE appliqués aux systèmes Windows. Dans cette section, nous avons dû résoudre la problématique des ressources. Pour le modèle de protection PBAC, nous avons choisi d’implanter le mécanisme de namespace en utilisant les variables d’environnement. Ces variables sont divisées en deux types : le premier est géré directement par le système. On le retrouve ainsi sur tous les systèmes Windows. Cela assure une portabilité complète de nos politiques de contrôle d’accès. Le second type est géré par l’administrateur. Il peut ainsi ajouter des variables d’environnement pour rédiger des règles 1375.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE d’accès propres à son système ou à son parc de machines. Nous avons aussi ajouté à ce modèle de protection, un second modèle de protection nommé TPE. Il permet de définir des répertoires de confiance d’où seront lancés les fichiers exécutables. En ce qui concerne le modèle de protection DTE, la principale difficulté était de trouver un moyen de stocker les contextes de sécurité des objets. Nous avons vu que SELinux utilisait les attributs étendus du système de fichiers pour les stocker. Cette solution n’est pas portable sur les systèmes Windows qui n’utilisent pas le même système de fichiers. Nous avons ainsi proposé une méthode évitant d’avoir à stocker les contextes de sécurité. Afin de ne pas créer de faiblesse dans notre modèle de protection, nous avons dû définir des contextes de sécurité plus précis que ceux proposés par SELinux. Pour cela, nous avons choisi de mettre dans le type du contexte de sécurité objet le chemin complet de l’objet. Cette méthode conduit à avoir les mêmes problèmes que pour le modèle PBAC, à savoir un problème dans le mécanisme de noms des ressources. Pour résoudre ce problème, nous avons utilisé la même solution que pour le modèle PBAC. Nous avons donc utilisé les variables d’environnement pour la définition des chemins complets des objets. Grâce à l’implantation basée sur les variables d’environnement nous proposons donc des noms symboliques absolus indépendants de la localisation tels que définit dans le chapitre 3. Nous offrons donc un mécanisme permettant de désigner de manière précise chaque ressource du système. Nous avons montré que nous pouvions appliquer cette méthode non seulement sur les ressources du système de fichiers mais aussi sur les éléments du registre, mécanisme important dans les systèmes Windows. Nous avons aussi détaillé les deux modes de fonctionnement de notre moniteur de référence. Le mode détection, qui va permettre d’écrire une politique de contrôle d’accès et un mode protection, qui l’applique strictement. Grâce au mode détection, nous avons mis en place un outil qui automatise la création de nouvelles règles pour l’ajout d’un nouveau programme. Cette automatisation n’est pas sans risque puisque l’outil n’effectue aucun contrôle sur la légitimité des règles ajoutées. Il est donc nécessaire que l’administrateur vérifie les règles générées. Enfin, nous avons présenté notre mécanisme d’audit, qui génère des traces permettant de connaître les interactions qui se sont déroulées sur le système, mais qui sont aussi utilisées pour créer des règles de contrôle d’accès, que ce soit de façon automatique ou manuelle. 5.2 Implantation des mécanismes de contrôle d’accès obligatoire Dans cette section, nous allons présenter les implantations de deux mécanismes de contrôle d’accès obligatoire pour les systèmes d’exploitation Windows, que nous avons appelé SEWINDOWS. Cette section, qui est divisée en deux parties, propose l’implantation sous deux formes différentes du Policy Enforcement Point. Ces deux méthodes ont été décrites dans la section 3.3. La première implantation que nous proposons, utilise le détournement de la table des appels système de Windows. Cette première version nous a permis de valider les politiques que nous avons générées. La seconde implantation utilise les filter-driver pour détourner les flux d’exécution. Cette seconde version respecte les préconisations faites par Microsoft pour surveiller l’activité du système. 5.2.1 Implantation du mécanisme de contrôle d’accès basé sur la modification de la table des appels système L’implantation de cette solution s’appuyant sur le modèle de protection DTE a fait l’objet d’une publication [Gros et al., 2012]. L’application qui en a été faite, dont la définition des propriétés de sécurité fut détaillée dans [Blanc et al., 2012]. 1385.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE 5.2.1.1 Architecture fonctionnelle du mécanisme de contrôle d’accès La figure 5.2 décrit l’architecture logicielle de notre solution de contrôle d’accès pour les systèmes Windows. Nous présentons ici les composants de cette architecture. Le premier composant est le driver. C’est le point central du mécanisme. Il est responsable de la prise de décision (Policy Decision Point). Cette implantation reprend toutes les phases que nous avons détaillées dans la partie 3.1.2. Dans la phase de pré-décision, le moniteur est chargé de récupérer toutes les informations nécessaires à la prise de décision. Il est aussi en charge d’horodater et de numéroter la trace correspondante à l’interaction directe observée. C’est aussi dans cette phase que le moniteur doit mettre en place la méthode de représentation du système. Dans le cadre du modèle PBAC, il transforme les chemins des ressources en nom absolu indépendant de la localisation. Dans le cadre du modèle DTE, il doit labelliser les ressources. Ensuite, le moniteur doit prendre une décision pour autoriser ou non l’interaction au regard de la politique de contrôle d’accès. La décision est ensuite ajoutée à la trace pour qu’elle puisse être générée. Enfin, dans la phase de post-décision, soit le moniteur autorise la poursuite de l’interaction soit il la refuse. Dans tous les cas, il renvoie à la fin une réponse au processus ayant réalisé l’interaction. Dans cette implantation, les points d’application de la politique (Policy Enforcement Point) sont réalisés par un module du driver : dans ce cas la, il s’agit de la modification de la table des appels système. La figure 5.2 illustre l’architecture divisée en trois blocs de cette implantation. Comme le schéma le montre, le moniteur est placé au centre du flux d’exécution pour pouvoir contrôler en prétraitement et en post-traitement les interactions réalisées sur le système. Le premier bloc, nommé Appel de fonction, correspond à l’utilisation régulière d’un appel de fonction depuis l’espace utilisateur. Une application, qui réside en espace utilisateur, réalise une interaction sur le système. Cette interaction se traduit par l’exécution d’un appel système. Pour exécuter cet appel système, le système va chercher son adresse dans la table des appels système. C’est cette table qui a été modifiée par le driver SEWINDOWS pour détourner le flux d’exécution régulier. Le deuxième bloc correspond à la partie SEWINDOWS. Une fois l’interaction détournée, le moniteur va prendre une décision dans le but d’autoriser ou non l’interaction courante. Cette décision se fait par le serveur de sécurité qui, dans le cas du modèle DTE, labellise les ressources. Dans le cas du modèle PBAC, les chemins sont transformés en nom symbolique absolu indépendant de la localisation. Cette partie est réalisée par un module spécifique du driver. Une fois la décision prise, la trace est transmise au thread d’audit qui enregistre la trace dans le fichier d’audit. Le troisième bloc correspond à l’exécution normale, c’est-à-dire sans détournement opéré par le driver SEWINDOWS. Les fonctions de la table des appels système permettent d’interagir avec les éléments du système tels que le registre, le réseau ou encore le système de fichiers. 5.2.1.2 Détournement de la table des appels système Nous allons dans cette partie décrire, d’un point de vue technique, la méthode de détournement du flux d’exécution en modifiant la table des appels système. Pour cela, nous allons dans un premier temps détailler le fonctionnement d’un flux d’exécution classique, puis dans un second temps, les modifications faites par le driver. Exécution régulière La figure 5.3 illustre un flux d’exécution régulier. Un processus fait une interaction sur le système de fichiers comme la création d’un fichier. Pour cela, le processus utilise la fonction CreateFile de l’API Win32. Avant d’entrer en espace noyau, le flux d’exécution passe par la bibliothèque ntdll qui est chargée de faire correspondre la fonction CreateFile de l’API 1395.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE FIGURE 5.2 – Architecture globale Win32 avec l’appel système correspondant qui est NtCreateFile. La bibliothèque ntdll ne passe au noyau que le numéro de l’appel système et non son nom. L’instruction processeur SYSENTER est enfin déclenchée pour effectuer le changement de contexte. Une fois en espace noyau, le dispatcheur du noyau récupère le numéro de l’appel système et il lit dans la table des appels système SSDT l’adresse de la fonction à exécuter. Cette fonction se situe dans l’espace mémoire du noyau. Une fois l’appel système terminé, le retour de la fonction est renvoyé au processus ayant réalisé l’interaction. La vérification des droits d’accès est faite directement dans l’appel système. Exécution modifiée Notre première implantation modifie le flux d’exécution régulier en altérant cette table des appels système. La figure 5.4 montre comment le détournement opère. Lorsque le driver SEWINDOWS se charge, il modifie la SSDT. Il remplace les adresses des appels système par des adresses de fonctions qu’il maîtrise. À la différence des appels système dont les adresses sont situées dans l’espace mémoire du noyau, ces nouvelles adresses sont situées dans l’espace mémoire du driver SEWINDOWS. Le dispatcheur du noyau, qui lit l’adresse de l’appel système dans la SSDT obtient ainsi l’adresse 1405.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE Espace utilisateur Espace noyau processus ntdll Dispatcheur noyau Noyau N° Adresse 66 SSDT 0x825824AE FIGURE 5.3 – Flux d’exécution classique d’une fonction du driver SEWINDOWS. Le flux d’exécution est donc détourné dans le driver SEWINDOWS. Le serveur de sécurité peut alors autoriser ou non l’exécution de l’appel système en fonction de la politique de contrôle d’accès qu’il a chargée. Toute interaction refusée par le serveur de sécurité est enregistrée dans le fichier d’audit. L’altération de la table des appels système nous donne le contrôle des interactions ciblant le système de fichiers, des interactions sur le registre ainsi que des communications réseau. Les communications sont initialisées par l’utilisation de l’appel système NtDeviceIoControl. Limites Cependant, la SSDT ne gère pas les appels système contrôlant la partie graphique de Windows. En effet, sur les systèmes d’exploitation Windows, la partie graphique est gérée indé- pendamment du système par le driver win32.sys. Elle possède, par conséquent, sa propre table d’appels système spécifique à la gestion graphique qui se nomme Shadow SSDT. Nous avons fait le choix de ne par modifier cette table système car son altération peut provoquer une instabilité du système. En ne modifiant pas la Shadow SSDT, nous ne traitons pas les appels système qui gèrent la partie graphique de Windows. Un attaquant pourrait, s’il arrive à charger son exploit, réaliser des interactions que l’on peut considérer comme critiques. Par exemple, il serait capable de modifier ou voler les communications entre les applications. Il peut aussi forcer des applications à se fermer sans intervention de l’utilisateur. Les tables des appels système ne sont accessibles et donc modifiables qu’en espace noyau, ce qui les protègent des attaques que pourraient réaliser des processus. Néanmoins, un attaquant qui arrive à charger un driver pourrait supprimer les modifications faites sur les SSDT sans que l’utilisateur ou l’administrateur ne s’en aperçoive. Il faut, pour détecter ces modifications, surveiller les modifications de ces tables. Ces limitations ont été traitées plus en détails dans la section 3.3.2.2. 1415.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE processus ntdll Dispatcheur noyau N° Adresse 66 Noyau Driver SEWindows SSDT modifiée Espace utilisateur Espace noyau 0xA34E70E0 N° Adresse 66 SSDT régulière 0x825824AE FIGURE 5.4 – Flux d’exécution détourné par la modification de la SSDT 5.2.2 Architecture basée sur les filter-driver et les Kernel Callback Dans la première partie de cette section, nous avons mis en place une première architecture basée sur la modification de la table des appels système (SSDT). Cette solution, bien que fonctionnelle, n’est pas une solution pérenne. En effet, cette première solution souffre de quelques limites qui peuvent se révéler très contraignantes. Tout d’abord, notre implantation n’est pas portable sur les Windows 64 bits puisqu’elle modifie une table du système qui est protégée par Kernel Patch Protection. Sur ces systèmes, Kernel Patch Protection vérifie l’intégrité des tables système et déclenche des exceptions lorsqu’elles sont modifiées. Ces exceptions conduisent à la création d’un Blue Screen Of Death. Il n’est donc pas possible de les modifier. Ensuite, la modification des tables système peuve rendre le système d’exploitation instable et peut générer des Blue Screen Of Death. Enfin, il est nécessaire d’avoir une certificat signé par Microsoft pour pouvoir charger un driver sur un système 64 bits. Pour résoudre ce problème, il est nécessaire d’utiliser une méthode légitime pour détourner le flux d’exécution. Cette nouvelle solution modifie toujours le flux d’exécution du système sans pour autant altérer les tables système. Ce modèle est celui préconisé par Microsoft pour détourner le flux d’exécution. Il se base sur la mise en place de différents driver : les filter-driver et les Kernel Callback. Cette méthode a été décrite dans la partie C.3 (en Annexe). 5.2.2.1 Architecture globale La figure 5.5 décrit la nouvelle architecture logicielle que nous avons mise en place. Cette nouvelle solution se base sur la création de trois nouveaux composants tout en conservant les éléments clés de l’architecture que nous avons décrite dans la partie 5.2.1. L’architecture de contrôle d’accès 1425.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE globale n’est en rien modifiée. Le serveur de sécurité est toujours en charge d’appliquer strictement la politique de contrôle d’accès définie. Un processus de labellisation transforme les sujets et les objets pour leur associer des contextes de sécurité basés sur leur chemin complet. La partie traçabilité est conservée pour assurer des fichiers d’audit consistants détaillant avec précision les interactions passées sur le système. Les modifications interviennent au niveau du détournement du flux d’exécution du système. Comme nous l’avons expliqué en introduction de cette partie, notre première implantation n’est pas pérenne par rapport à la politique de Microsoft mais surtout elle n’est pas portable sur les systèmes 64 bits. Les modifications introduites dans cette nouvelle architecture ont pour but de respecter les critères de développement et de surveillance édictés par Microsoft. Nous avons donc une architecture de détournement des flux d’exécution du système divisée en trois composants principaux. Nous détaillerons plus la partie système que la partie réseau dans cette section. La raison est que la partie réseau est similaire dans la conception à la méthode utilisée par les filter-driver pour les entrées/sorties sur le système de fichiers. Le premier composant de notre solution est un filter-driver qui gère les requêtes d’entrée/sortie sur le système de fichiers. De part son design spécifique, il n’est pas capable de gérer d’autres aspects du système, néanmoins, il offre la possibilité de pouvoir réaliser des traitements en pré- traitement et post-traitement. Ce filter-driver est géré par un composant du système nommé le gestionnaire d’entrée/sortie auprès duquel il est nécessaire de s’enregistrer. Le second composant est un driver filtrant les interactions sur le registre. Il est lui aussi capable de faire des contrôles en prétraitement et en post-traitement. Il s’enregistre auprès du gestionnaire d’entrée/sortie spécifique au registre. Le troisième composant est un driver capable de contrôler le chargement et le déchargement de fichiers. Il peut ainsi contrôler le chargement des exécutables, mais aussi des bibliothèques ainsi que des driver. Il est aussi notifié de la mort d’un processus. Filter Manager Frame 1 Filter Manager Frame 0 FS Filter No altitude Action d’un processus sur le système de fichiers Espace noyau Espace utilisateur Action d’un processus sur le registre Action d’un processus pour créer un nouveau processus Registry Manager I/O Manager Process Manager Driver de stockage Registre Filter Process Driver Filter Driver Registry Filter Driver Driver SEWindows FIGURE 5.5 – Architecture de détournement basée sur l’utilisation de filter-driver et de kernel callback 5.2.2.2 Détournement des flux d’exécution Détournement des interactions d’entrée/sortie Une limite du détournement des appels système par la modification de la SSDT est l’impossibilité de contrôler les interactions réalisées par les driver. En effet, la SSDT est essentiellement utilisée par les processus, qui résident en espace 1435.3. EXPÉRIMENTATIONS utilisateur. Or, les driver n’utilisent pas les fonctions de la table des appels système pour réaliser des interactions sur le système. Grâce à l’utilisation des filter-driver qui catégorisent les interactions sur le système de fichiers au lieu de détourner juste un appel système, il est aussi possible de contrôler les interactions faites par les driver. En effet, lorsqu’un driver utilise des fonctions comme ZwCreateFile ou IoCreateFile, le système convertit ces fonctions en IRP pour être traitées par les filter-driver. La description de cette méthode a été faite dans la partie C.3. Nous allons juste reprendre quelques points importants. Les filter-driver sont rangés grâce à un système d’altitude. Cette altitude détermine l’ordre de traitement des requêtes. Plus un filter-driver aura une altitude haute, c’est-à-dire proche du noyau, plus il recevra la requête tôt dans la phase de prétraitement. À l’inverse, dans la phase de post-traitement, il sera parmi les derniers à recevoir la requête. Donc la place choisie pour le filter-driver est très importante. Nous avons choisi comme altitude 360 000, qui est une altitude préconisée par Microsoft pour la catégorie de filter-driver que nous faisons. Détournement des interactions sur le registre Les accès au registre passent par un gestionnaire d’entrée/sortie spécifique au registre. Pour contrôler les accès qui y sont fait, il est possible d’enregistrer un driver auprès de ce gestionnaire en utilisant le mécanisme de Registry Callback. Grâce à cet enregistrement, le driver est capable de contrôler toutes les interactions sur le registre sans avoir à préciser les interactions qu’il désire traiter. Comme pour les filter-driver, le contrôle se fait en pré et post traitement. Détournement des interactions de chargement et de déchargement des fichiers Les chargements des fichiers exécutables sont traités spécifiquement par le noyau Windows. Mais il est aussi possible pour un driver de contrôler le chargement de ces fichiers qui sont les plus dangereux pour le système puisqu’ils sont exécutés en espace noyau. Le noyau Windows propose ainsi des routines de notification pour contrôler les créations de processus, le chargement de bibliothèques mais aussi de driver, appelées Process Notify Routine. Ces routines renseignent sur le nom du nouveau processus ainsi que sur son PID mais aussi sur le PPID. Il est ainsi possible de contrôler le chargement des fichiers exécutables. Ces routines du noyau Windows renseignent aussi sur la mort d’un processus. Il n’est par contre pas possible de contrôler la mort d’un processus mais la notification offre la possibilité de l’inscrire dans un fichier d’audit. Détournement des interactions sur le réseau Le détournement des interactions effectuées sur le réseau s’effectue par l’utilisation de la Windows Filtering Platform. Cette plateforme mise en place par Microsoft est similaire à celle des filter-driver. Grâce à l’utilisation des API que la plateforme fournie, il est possible de contrôler les interactions au niveau du réseau. 5.3 Expérimentations Dans cette section, nous allons détailler les expérimentations réalisées grâce à notre moniteur pour Windows. Nous avons séparé cette section en deux parties distinctes. La première partie traite des expérimentations réalisées grâce à notre première implantation de SEWINDOWS basée sur le modèle DTE. Ces expérimentations nous ont permis de 1) générer des politiques ainsi que des file_context pour les systèmes d’exploitation Windows, 2) valider notre modèle de politique et 3) valider l’implantation que nous avons faite. Nous avons pour cela mis en place des scénarios d’attaque, basés dans un premier temps sur des interactions directes, c’est-à-dire des interactions 1445.3. EXPÉRIMENTATIONS directes d’un sujet sur un objet, puis sur des scénarios complets avec des flux indirects en ajoutant PIGA à l’architecture de protection. Dans une seconde partie, nous détaillons les expérimentations faites à partir de la seconde implantation de notre mécanisme de contrôle d’accès basée sur les filter-driver. Dans le but de générer des propriétés de sécurité et des configurations de mécanisme de contrôle d’accès pouvant contrer des menaces réelles, nous avons mis en place une architecture spécifique pour incorporer notre filter-driver au sein d’un mécanisme d’étude de logiciels malveillants (sandbox). En exécutant plusieurs logiciels malveillants et en étudiant les traces générées, nous allons écrire des règles de contrôle d’accès ainsi que des propriétés de sécurité pour PIGA afin de contrer explicitement ces comportements. 5.3.1 Violation d’une propriété de confidentialité Dans cette partie, nous présentons les expérimentations réalisées grâce à notre mécanisme de contrôle d’accès. Nos expérimentations ne portent que sur l’implantation du modèle de protection DTE car nous voulons être en mesure d’exprimer des propriétés de sécurité grâce à PIGA. Pour pouvoir exprimer ces propriétés de sécurité, PIGA utilise de façon préférentielle un fichier contenant les contextes de sécurité objets et d’une politique basée sur les types. 5.3.1.1 Environnement des expérimentations Introduction Pour pouvoir réaliser nos expérimentations, nous avons dû définir une politique de contrôle d’accès autorisant le fonctionnement des programmes que nous voulions tester. Pour ce faire, nous avons utilisé le mode apprentissage de notre moniteur pour générer les politiques, c’est- à-dire que nous avions placé notre driver en mode évidence. Nous avons aussi utilisé la méthode automatique, c’est-à-dire que nous avons utilisé notre outil transformant les traces générés en règles de contrôle d’accès, tout en vérifiant qu’il n’y avait pas de règles illégitimes qui pourraient fausser nos expérimentations. Plateforme Nous avons réalisé nos expérimentations dans une machine virtuelle avec un Windows 7 32 bits. Le driver SEWINDOWS était en mode apprentissage et nous avons fait des opérations légitimes sur la machine : exécution de Windows Media Player, Firefox, Opera, etc. Il est nécessaire de définir précisément les opérations que l’on souhaite autoriser par la suite. Cette planification se fait généralement à la main par l’utilisation d’une check-list. Il faut bien évidemment refaire plusieurs fois les exécutions pour être sûr de n’avoir pas oublié de règles nécessaires au bon fonctionnement des applications. Une fois cette phase d’apprentissage terminée, nous disposions d’une politique suffisante pour que les applications puissent fonctionner correctement, même avec notre moniteur en mode protection. La politique générée est suffisante pour un fonctionnement normal du système d’exploitation, c’est-à-dire que nous sommes capables de réaliser certaines tâches définies sans que le driver SEWINDOWS ne les bloque. Nous obtenons donc une politique SEWINDOWS avec environ 5000 règles d’accès et 40 000 contextes de sécurité. La table 5.6 récapitule les informations sur la politique. Nombre de contextes de sécurité objets 40 000 Nombre de contextes de sécurité sujets 1 800 Nombre d’interactions 5 000 FIGURE 5.6 – Statistiques sur la politique de contrôle d’accès pour le premier scénario 1455.3. EXPÉRIMENTATIONS 5.3.1.2 Scénario des attaques Nous détaillons deux scénarios d’attaque pour montrer l’efficacité de notre solution. Le premier propose une attaque "simple" qui repose sur un scénario joué volontairement par l’utilisateur. Il essaye de contourner la politique de contrôle d’accès par une interaction directe. Le second scénario est plus réaliste puisqu’il utilise des flux indirects autorisés par SEWINDOWS. Nous montrons dans le premier cas, qui correspond à un flux d’information direct, que notre moniteur est capable de l’interdire. A contrario, nous montrerons, dans le second cas qui résultat d’un flux d’information indirect, que notre moniteur, même s’il est capable de voir l’ensemble des interactions directes, n’est pas capable de bloquer la violation de propriété. Il est donc nécessaire d’utiliser un second moniteur pour détecter ce genre de violation. 5.3.1.3 Violation directe Dans notre premier exemple, nous avons un utilisateur qui tente de lire le contenu d’un dossier auquel il n’a pas accès en passant par un navigateur Internet. Ce refus se traduit par la trace suivante listée en listing 5.17. Elle montre que le sujet ayant pour contexte de sécurité system_u:system_r:firefox_t veut lire (read) et traverser (execute) le dossier ayant pour contexte de sécurité system_u:object_r:systemdrive|users|ensib|appdata|roaming|opera|opera_dir_t ✞ ☎ 1 type=DTE audit(129320375967434054:683) 2 avc:denied { execute read } for pid=1756 comm="%programfiles%\mozilla 3 firefox\firefox.exe" ppid=1456 4 path="%systemdrive%\users\ensib\appdata\roaming\opera\opera" 5 scontext=system_u:system_r:firefox_t 6 tcontext=system_u:object_r:systemdrive|users|ensib|appdata|roaming|opera| opera_dir_t 7 tclass=dir ✝ ✆ Listing 5.17 – Trace d’interdiction pour Firefox de lire le contenu du dossier d’Opera 5.3.1.4 Violation indirecte Ce second scénario propose de reprendre l’attaque qui vise à enfreindre la confidentialité que l’on veut imposer entre nos deux navigateurs Firefox et Opera. Dans cette attaque, nous allons essayer de contourner la politique de contrôle d’accès en utilisant une suite d’interactions légitimes au système vis-à-vis de SEWINDOWS. Via des propriétés de sécurité comme la confidentialité, PIGA est capable de détecter des violations indirectes de la confidentialité. Le listing 5.18 montre la définition d’une propriété de confidentialité entre deux contextes de sécurité. Cette propriété spécifie qu’il ne doit y avoir aucun flux d’information entre le contexte de sécurité objet et le contexte de sécurité sujet. C’est pourquoi, dans notre propriété de confidentialité, nous interdisons les flux d’information indirects représentés par le symbole >>, allant de sc2 vers sc1. ✞ ☎ 1 define confidentiality( $sc1 IN SCS , $sc2 IN SCO ) 2 ST { $sc2 >> $sc1 } , { not(exist ( ) ) } ; ✝ ✆ Listing 5.18 – Définition de la propriété de confidentialité Nous l’appliquons entre les navigateurs Firefox et Opera. Pour contrôler les flux entre les deux navigateurs, il est nécessaire d’écrire les deux propriétés de confidentialité comme le montre le listing 5.19. 1465.3. EXPÉRIMENTATIONS ✞ ☎ 1 confidentiality( $sc1: =".*:.*:opera_t" ,$sc2: =".*:.*:firefox_t" ) ; 2 confidentiality( $sc1: =".*:.*:firefox_t" ,$sc2: =".*:.*:opera_t" ) ; ✝ ✆ Listing 5.19 – Application de la propriété de confidentialité En rejouant des traces générées par notre driver SEWINDOWS dans PIGA et en appliquant la propriété de sécurité définie au listing 5.19, nous détectons un flux d’information entre Firefox et Opera. Ce transfert d’informations réussit grâce à l’utilisation d’un logiciel tiers, ici Adobe. Le listing 5.20 montre une détection faite par PIGA. Nous avons Firefox qui écrit un fichier à la racine du système. Puis Adobe qui lit le contenu du fichier pour aller ensuite écrire un nouveau fichier dans le répertoire d’Opera qui va finir par le lire. ✞ ☎ 1 system_u : system_r : firefox_t −( file { create write } )−>system_u : object_r : systemroot_file_t ; 2 system_u : system_r : adobe_t −( file { execute read } )−> system_u : object_r : systemroot_file_t ; 3 system_u : system_r : adobe_t −( dir { create setattr unlink } )−> user_u : object_r : systemdrive | user | bob | AppData | Local | opera_dir_t ; 4 system_u : system_r : opera_t −( file { execute getattr read } )−> system_u : object_r : systemdrive | user | bob | AppData | Local | opera_file_t ; ✝ ✆ Listing 5.20 – Trace d’un flux indirect de Firefox vers Opera La détection faite par PIGA pouvant être difficile à lire, nous proposons une illustration 5.7 qui montre le cheminement de l’attaque. Firefox écrit dans un fichier (flèche 1). Ce fichier est lu par Adobe (flèche 2). Adode écrit dans un second fichier, qui est dans le répertoire visé par l’attaque (i.e : le répertoire d’Opera). Enfin Opera lit le contenu de ce fichier. Firefox Fichier 1 Adobem Fichier 2 Opera 3 : Ecrit 2 : Lit 1 : Ecrit 4 : Lit FIGURE 5.7 – Schéma du flux indirect conduisant à la violation de la propriété de confidentialité Nous obtenons donc un flux d’information indirect entre les deux navigateurs, obtenu grâce à un programme intermédiaire, ici Adobe Reader. 5.3.2 Étude de logiciels malveillants 5.3.2.1 Introduction Dans cette partie, nous développons les tests que nous avons réalisés sur une architecture spécifique que nous avons mise en place. Ces tests se sont orientés sur l’analyse de logiciels malveillants. Dans cette configuration, nous avons dû mettre en place une solution pour assurer l’intégrité des fichiers d’audit que nous récupérons lors de l’exécution du logiciel malveillant. Cette solution consiste à envoyer les traces générées par le moniteur à un serveur de sécurité. Les expérimentations que nous avons faites ont été réalisées en machine virtuelle et nous décrivons dans cette partie les protocoles qui ont été appliqués sur deux types de logiciels malveillants. Nous avons mis en place des outils facilitant la lecture des traces générées dans le but de comprendre l’impact du logiciel malveillant sur le système et pour connaître les fichiers contaminés. 1475.3. EXPÉRIMENTATIONS Ces outils offrent une représentation textuelle et graphique des résultats ce qui facilite la compré- hension des mécanismes d’installation du logiciel malveillant. En plus de ces outils de visualisation, nous proposons des méthodes pour dériver une politique de contrôle d’accès pour SEWINDOWS à partir des traces générées. Ces politiques empêchent l’installation de ce type de logiciel malveillant en traitant les interactions directes entre les sujets et les objets du système. Cependant, comme ces politiques empêchent les interactions illégitimes, nous proposons aussi des outils pour en dériver des propriétés de sécurité qui pourront être appliquées par PIGA. Exécution d’un logiciel malveillant Ce premier scénario propose l’exécution d’un logiciel malveillant plutôt basique. En utilisant le mode détection de notre mécanisme, nous montrerons les comportements clés du logiciel malveillant. Nous avons commencé par étudier un FakeAV dont l’analyse par VirusTotal se trouve ici 1 . Comme le binaire n’est pas présent dans la politique nous avons mis notre driver SEWINDOWS en mode détection pour dérouler l’installation du logiciel malveillant et nous montrerons des points clés dans son installation que notre mécanisme de contrôle d’accès est capable de bloquer. Le premier point important est le moment où le logiciel malveillant est exécuté. Cela se traduit par le chargement (load) du binaire par explorer.exe. Cette trace est retranscrite par notre driver SEWINDOWS dans le listing 5.21. Nous avons volontairement renommé le logiciel malveillant en malware pour pouvoir plus facilement suivre son évolution dans les traces. Le logiciel malveillant est exécuté par nos soins. ✞ ☎ 1 type=DTE audit(129676508858814710,43) avc:denied { execute } for pid=308 2 com="%systemroot%\explorer.exe" ppid=360 3 path="%systemdrive%\users\bob\desktop\malware.exe" 4 scontext=system_u:system_r:explorer_t 5 tcontext=system_u:object_r:systemdrive|users|bob|desktop|malware_exec_t 6 tclass=load ✝ ✆ Listing 5.21 – Chargement du logiciel malveillant par explorer.exe Ensuite, le logiciel malveillant va exécuter un invite de commande comme le montre le listing 5.22. ✞ ☎ 1 type=DTE audit(129676508874908460,159) avc:denied { execute } for pid=3376 2 com="%systemdrive%\users\bob\desktop\malware.exe" ppid=308 3 path="%systemroot%\system32\cmd.exe" scontext=system_u:system_r:malware_t 4 tcontext=system_u:object_r:systemroot|system32|cmd_exec_t tclass=load ✝ ✆ Listing 5.22 – Exécution du premier invite de commande par le logiciel malveillant Ce premier invite de commande exécute un second invite de commande et écrit un nouveau fichier qui se nomme script.bat. 5.23. ✞ ☎ 1 type=DTE audit(129676508874908460,171) avc:denied { execute } for 2 pid=2628 com="%systemroot%\system32\cmd.exe" ppid=3376 3 path="%systemroot%\system32\cmd.exe" scontext=system_u:system_r:cmd_t 4 tcontext=system_u:object_r:systemroot|system32|cmd_exec_t tclass=load 5 6 type=DTE audit(129676508875064710,177) avc:denied { write } for pid=3376 7 com="%systemdrive%\users\bob\desktop\malware.exe" ppid=308 8 path="%systemdrive%\users\bob\desktop\script.bat" 1. https://www.virustotal.com/en/file/d0d0d53f66b400cb43b3019be9e5e49a9097458119eba8f18d27d9e7b4ac8d9b/ analysis/ 1485.3. EXPÉRIMENTATIONS 9 scontext=system_u:system_r:malware_t 10 tcontext=system_u:object_r:systemdrive|users|bob|desktop|script_bat_t 11 tclass=file ✝ ✆ Listing 5.23 – Exécution d’un second invite de commande et écriture du script Enfin, le second invite de commande va lire le contenu du script pour exécuter les commandes qui sont à l’intérieur. 5.24. ✞ ☎ 1 type=DTE audit(129676508875689710,221) avc:denied { read } for pid=2832 2 com="%systemroot%\system32\cmd.exe" ppid=2628 3 path="%systemdrive%\users\bob\desktop\script.bat" 4 scontext=system_u:system_r:cmd_t 5 tcontext=system_u:object_r:systemdrive|users|bob|desktop|script_bat_t 6 tclass=file ✝ ✆ Listing 5.24 – Lecture du script par le second invite de commande Grâce à la précision des fichiers d’audit, nous pouvons facilement suivre l’évolution de ce logiciel malveillant sur le système. Il nous est facile de suivre les relations de filiation grâce notamment aux PID et aux PPID. À travers l’étude des traces générées par notre moniteur, nous avons pu suivre l’évolution de l’installation du logiciel malveillant. Nous ne montrons pas tous les éléments de cette infection, mais nous pouvons bloquer une par une les interactions réalisées par le logiciel. Ce scénario, entièrement joué puisque le moniteur est en mode détection, est un cas concret d’exécution du logiciel malveillant par un navigateur soumis à une attaque. 5.3.2.2 Architecture décentralisée À partir de l’implantation du mécanisme de contrôle d’accès basée sur les filter-driver et les kernel callback, nous avons mis en place une architecture spécifique permettant d’analyser les logiciels malveillants. L’objectif de ces expérimentations est d’exécuter les logiciels malveillants sans bloquer leurs interactions dans le but de connaître leur impact sur le système entier et d’en étudier leur comportement. Comme notre driver est en mode détection pour ces études, il enregistre chaque interaction effectuée sur le système. De plus, pour être sûr de ne pas rater d’interaction, il n’y a pas de politique de contrôle d’accès. Cependant, le logiciel malveillant pourrait modifier le contenu du fichier d’audit, voire le supprimer puisqu’il est stocké sur le système et que les interactions ne sont pas bloquées par le moniteur. Pour éviter d’avoir des fichiers d’audit potentiellement modifiés par le logiciel malveillant, nous avons décidé d’envoyer directement les traces sur un serveur de sécurité distant. Instrumentation du système La figure 5.8 représente notre nouvelle architecture du côté du Windows instrumenté. Cette architecture est divisée en quatre parties distinctes. Le premier bloc traite les accès au système de fichiers. Lorsqu’une interaction est réalisée sur le système de fichiers, l’interaction est interceptée lors de son prétraitement par notre filterdriver (flèche 1, 2, 3). Le filter-driver est chargé de construire une trace suffisamment précise pour pouvoir avoir toutes les informations nécessaires à l’étude du logiciel. De plus, pour avoir une chronologie des différentes interactions réalisées, nous ajoutons un identifiant unique pour chaque interaction ainsi qu’un timestamp. Nous obtenons ainsi une trace contenant : 1. un numéro de trace unique, ainsi que le numéro du cœur processeur qui exécute l’action ; 2. un timestamp ; 1495.3. EXPÉRIMENTATIONS FIGURE 5.8 – Instrumentation du système pour l’analyse de logiciel malveillant 3. le type d’accès ; 4. nom court du processus qui a fait l’action et PID ; 5. nom de l’objet. Dans le but de ne pas faire de calcul intempestif sur la machine d’étude, nous ne calculons pas de contexte de sécurité. Cette tâche sera faite par le serveur de sécurité dans un mode offline. Un exemple de trace générée est illustré par le listing 5.25. Cette trace est ensuite envoyée (flèche 4) au thread qui s’occupe de la communication avec le serveur de sécurité. ✞ ☎ 1 trace=1118 , cpu=0 2 timestamp=130208621983766250 3 Access : create 4 pid : consent.exe 568 5 Object Name : \Device\HarddiskVolume2\Users\toto\AppData\LocalLow ✝ ✆ Listing 5.25 – Trace générée par le filter-driver pour une interaction sur le système de fichiers Le second bloc traite de la gestion de processus. À chaque création ou mort d’un processus, un thread du filter-driver enregistre certaines informations. Il doit récupérer les noms complets des processus impliqués, c’est-à-dire du père et du fils, ainsi que leur PID (flèche 5.1 et flèche 5.2). Une fois que ces informations sont enregistrées, la trace générée pour la création d’un processus 5.26 est envoyée au thread qui s’occupe de la communication avec le serveur de sécurité. La même chose est faite pour la mort d’un processus 5.27. Nous ne datons pas ces traces car ce n’est pas nécessaire. Nous nous servons de ces traces pour connaître les chemins complets ainsi que les PID des processus créés et détruits. ✞ ☎ 1 Parent Process name : \Device\HarddiskVolume2\Windows\System32\svchost.exe pid =908 2 Process name : \Device\HarddiskVolume2\Windows\System32\consent.exe pid=568 ppid=908 sid=1 ✝ ✆ Listing 5.26 – Trace générée par le filter-driver pour la création d’un processus 1505.3. EXPÉRIMENTATIONS ✞ ☎ 1 Parent Process name : \Device\HarddiskVolume2\Windows\System32\svchost.exe pid =908 2 Process name : \Device\HarddiskVolume2\Windows\System32\consent.exe pid=568 ppid=908 sid=1 ✝ ✆ Listing 5.27 – Trace générée par le filter-driver pour la mort d’un processus Le troisième bloc de l’architecture concerne la gestion du registre. Tout comme pour le système de fichiers, nous n’interceptons que les requêtes en prétraitement. Lorsqu’un processus fait une interaction sur le registre, elle est interceptée (flèche 6) par le gestionnaire de registre puis transmise (flèche 7) à notre driver. Le Registry Filter Driver récupère toutes les informations nécessaires à la compréhension de l’interaction. Il ajoute aussi un identifiant unique ainsi qu’un timestamp. La trace construite est très proche de la trace générée pour le système de fichiers. Mais, en plus des informations de type nom du processus ainsi que son PID et nom de l’objet, qui dans ce cas la correspond à une clé registre, nous ajoutons le couple valeur et donnée dans la trace, pour connaître précisément les interactions du logiciel étudié. Nous obtenons ainsi une trace complète, comme le montre le listing 5.28, qui est envoyée au thread qui s’occupe de la communication avec le serveur de sécurité. ✞ ☎ 1 trace=2258 , cpu=0 2 timestamp=130257368578773750 3 Access : set_value_key 4 pid : explorer.exe 1644 5 \REGISTRY\USER\S-1-5-21-2571257828-2288546103-543878076-1001\Software\Microsoft \Windows\CurrentVersion\Explorer\UserAssist\{CEBFF5CD-ACE2-4F4F-9178-9926 F41749EA}\Count 6 {Q65231O0-O2S1-4857-N4PR-N8R7P6RN7Q27}\pzq.rkr REG_BINARY : 00000000250000008001000095CA5300000080BF000080BF000080BF000080BF 7 000080 BF000080BF000080BF000080BF000080BF000080BFFFFFFFFFC0B06AEB62C4CE0100000000 ✝ ✆ Listing 5.28 – Trace générée par le driver pour une interaction sur le registre Enfin, le quatrième bloc est celui qui gère les communications avec le serveur de sécurité. L’implantation choisie sur le système instrumenté doit assurer deux règles importantes : la première règle est que les communications avec le serveur de sécurité distant doivent être assurées par un module dédié de l’architecture pour ne pas interférer avec le reste du mécanisme. Pour cela, nous utilisons un thread dédié qui ne s’occupera que des communications réseau. La seconde règle impose que cette communication ne doit ni ralentir, ni bloquer le fonctionnement de la machine. Pour cela, nous avons choisi une implantation basée sur le principe de producteur/consommateur. Les producteurs sont les trois parties précédemment présentées. Elles approvisionnent une file de messages sans attendre que le message soit envoyé. Ainsi, elles n’ont pas besoin d’attendre un retour de la part du thread qui envoie les traces et elles ne bloquent donc pas les interactions. Le consommateur est par conséquent le thread qui récupère les traces et les envoie au serveur de sécurité. Les communications sont réalisées sur une connexion TCP. Nous noterons une chose importante. Nous avons ajouté dans les traces traitant les interactions du système de fichiers et du registre, un identifiant unique ainsi qu’un timestamp. Il est indispensable pour la compréhension de l’installation de l’infection que cet identifiant soit unique pour tout le système. Il est donc partagé entre les différentes parties de notre architecture. 1515.3. EXPÉRIMENTATIONS De plus, comme nous le montrons dans les traces, nous n’enregistrons que le nom court des processus. Ce nom est récupéré grâce à la fonction ZwQueryInformationProcess. Elle va lire un champ de la structure EPROCESS 2 . Une étape importante est donc réalisée au moment du démarrage du driver. Lors de cette étape, il va établir la liste des processus qui sont en cours de fonctionnement en recherchant, quand c’est possible, le père de chaque processus. En effet, sous Windows, il est possible qu’un processus n’ait pas de père (à la différence des systèmes Linux où les processus sont toujours au moins rattachés à init). Nous obtenons ainsi un graphe de l’activité courante du système. Cela nous permet aussi de connaître les chemins complets ainsi que les PID des processus qui sont lancés au moment où nous exécutons le logiciel étudié. Serveur de sécurité distant Le serveur de sécurité est divisé en deux parties : la première partie est un serveur TCP, fait en python, qui récupère les traces envoyées par le driver pour les mettre dans une base de données. Comme le nombre de traces est relativement grand, la mise en base est faite de manière offline pour ne pas surcharger la machine. La seconde partie permet la visualisation des résultats. Elle propose la génération de rapport présentant les activités qui se sont déroulées sur le système étudié. 5.3.2.3 Protocoles des expérimentations Plateforme Nous avons fait le choix d’instrumenter un Windows 7 32 bits. Même si cette nouvelle implantation nous permet de tester sur les architectures 64 bits, il est nécessaire de signer le driver avec un certificat émis par une autorité reconnue par Microsoft pour que le Kernel Patch Protection l’autorise à se charger. Il existe cependant un mode appelé testsigning qui permet d’auto-signer son driver avec un certificat que nous aurions créé. Néanmoins, dans ce mode, Kernel Patch Protection ne vérifie plus que la validité de la signature, ce qui modifie le comportement du système. Si un logiciel malveillant charge un driver auto-signé, il ne sera pas bloqué par les protections natives du système. Ces tests ont été réalisés dans une machine virtuelle pour bénéficier de la possibilité de faire des instantanés des machines et ainsi éviter de les réinstaller entre chaque étude. De plus, cela nous permet de connaître parfaitement l’état de départ de la machine qui sert pour les tests. Le serveur de sécurité est une machine capable de faire fonctionner un serveur web ainsi que des scripts pythons, dans notre cas, un système Linux. Exécution des logiciels malveillants Les logiciels malveillants étudiés sont téléchargés directement sur la machine. Les logiciels malveillants ont besoin d’être exécutés à la main car il faut pouvoir autoriser son exécution si une demande d’élévation des privilèges est demandée. Cette manipulation nous permet à la fois de connaître le nom du binaire qui est exécuté mais aussi de savoir comment il doit être lancé. Nous savons par cette manipulation que le processus, qui lance le logiciel malveillant, est explorer.exe. Cette information facilite le traitement des résultats. Une fois que le logiciel malveillant est installé, nous laissons l’infection se développer sur le système. Il est parfois nécessaire que valider des opérations intermédiaires à cause de l’User Access Control. Nous acceptons à chaque fois les demandes faites par l’User Access Control. Nous avons fait le choix de ne pas désactiver l’User Access Control car cette désactivation fausserait aussi l’étude. En effet, lorsque cette protection n’est plus activée, des mécanismes de 2. EPROCESS est une structure du noyau de Windows contenant les informations sur les processus (nom, PID, thread, etc). Cette structure est opaque, c’est-à-dire qu’il est nécessaire d’utiliser une fonction pour récupérer des informations dans les champs de structure 1525.3. EXPÉRIMENTATIONS sécurité ne sont plus appliqués. Par exemple, il n’y a plus de vérification des niveaux d’intégrité lorsqu’un sujet effectue une interaction sur un objet. Serveur de sécurité Une fois que l’utilisateur considère que l’exécution est terminée, le serveur de sécurité met dans une base de données les informations recueillies par le driver pour les conserver et les comparer aux autres études. Il génère ensuite les résultats pour qu’ils puissent être analysés. 5.3.2.4 Visualisation des résultats et définition des propriétés de sécurité Une fois le logiciel malveillant exécuté, il faut pouvoir fournir des résultats pertinents, c’est- à-dire des résultats qui permettent de comprendre le cheminement de l’infection : nous ciblerons donc les interactions spécifiques au logiciel malveillant qui permettent la propagation de l’infection au sein du système. Pour ce faire, nous proposons un outil graphique générant les résultats sous la forme d’un graphe. Ce graphe est une représentation du système ayant pour nœud les processus et comme feuilles les interactions réalisées ainsi que les objets. Nous proposons aussi un outil qui extrait les interactions directes sous la forme d’automates. Ces automates sont des sous graphes, qui repré- sentent une partie du comportement du logiciel malveillant étudié. À partir de ce sous graphe, il nous est possible d’écrire des règles de contrôles d’accès empêchant le déploiement de l’infection, mais aussi des propriétés de sécurité qui peuvent être vérifiées et appliquées par PIGA. Visualisation Pour comprendre le cheminement utilisé par l’infection, nous présentons les résultats sous une forme brute. Dans une première partie, nous listons les processus ainsi que leurs parents. Associées à ces processus, il est possible de connaître toutes les interactions directes générées sur le système par ce processus sans aucun filtre. Cette première visualisation permet de connaître l’activité complète du processus (fichier créé, supprimé, processus lancé, clé registre modifiée, etc.). Cette forme est une forme brute des traces générées, triées par ordre temporaire. Dans le but de mieux comprendre les interactions passées sur la machine d’analyse, il est nécessaire de travailler les résultats. La première chose est de visualiser quelques interactions précises. Nous avons choisi d’isoler pour la partie système de fichiers : — les chargements, — écriture et suppression. Ce choix est motivé par le fait que nous voulons suivre la propagation de l’infection au sein du système et ainsi connaître les éléments qui ont été infectés. Donc nous isolons les interactions qui permettent d’échanger de l’information depuis un processus infecté vers un objet du système. Ce modèle n’est pas figé. En rajoutant par exemple, les opérations élémentaires de lecture, nous pouvons détecter les fuites d’information ou les violations de confidentialité. Nous allons détailler nos résultats sur l’analyse d’un logiciel malveillant appelé ZeroAccess. Ce malware est celui que nous avons utilisé dans notre introduction 1.3. Nous allons chercher à comprendre son comportement lors de son installation pour en extraire les règles de contrôle d’accès nécessaires pour empêcher sa propagation au sein du système. Génération du graphe des processus La représentation sous la forme d’un graphe nous permet de connaître quelques interactions spécifiques. La figure 5.9 montre le premier résultat obtenu. À partir du fichier de l’infection nommé xxx-porn-movie.avi.exe, nous remarquons qu’il va 1535.3. EXPÉRIMENTATIONS écrire des fichiers dans la corbeille de Windows qui se nomme Recycler.Bin. On peut tout d’abord noter que le logiciel malveillant veut se cacher en utilisant une double extension, pour tromper l’utilisateur en lui faisant croire que c’est une vidéo dans le but qu’il exécute le fichier binaire. FIGURE 5.9 – Logiciel malveillant écrivant des fichiers dans la corbeille de Windows Le graphe nous montre un lien entre notre fichier principal de l’infection et un processus qui semble légitime nommé InstallFlashPlayer.exe. Nous pouvons voir que ce fichier a été écrit par l’infection. En effet, en extrayant les parties write et load du graphe pour le processus xxx-porn-movie.avi.exe, nous pouvons voir que c’est l’infection qui écrit et charge ce fichier. La figure 5.10 nous montre une partie des interactions faites par le processus InstallFlashPlayer.exe qui vient d’être exécuté par le logiciel malveillant. Nous pouvons voir que celui-ci va aussi écrire dans la corbeille de Windows. Enfin, la figure 5.11 nous montre que c’est le processus services.exe qui va charger les fichiers qui ont été écrits par les deux processus malveillants. C’est à ce moment là que la charge active du logiciel malveillant est exécutée. L’exécution, par un service système, de cette charge, assure à l’infection la possibilité de pouvoir réaliser toutes les interactions qu’elle désire. Dans cette étude, nous pouvons noter plusieurs points : tout d’abord, la dissimulation de la véritable extension par le logiciel malveillant dans le but de tromper l’utilisateur. Cette technique est assez courante pour installer des logiciels malveillants. Ensuite, l’utilisation d’un logiciel lé- gitime pour installer la charge active de l’infection qui est aussi une méthode pour se cacher aux yeux de l’utilisateur. Ici, le logiciel malveillant peut justifier l’installation par nécessité pour lire la vidéo. Nous notons aussi l’utilisation d’un répertoire temporaire, ici la Corbeille, pour l’écriture des fichiers utilisés pour exécuter la charge active. Enfin, nous voyons l’utilisation de processus lé- gitime, présent sur tous les systèmes Windows et tournant avec des privilèges élevés pour installer la charge active. 1545.3. EXPÉRIMENTATIONS FIGURE 5.10 – Flash player écrit dans la Corbeille de Windows FIGURE 5.11 – services.exe chargeant les fichiers écrits par les logiciels malveillants. Nous nous sommes intéressés uniquement à l’étude de l’installation de l’infection, pour connaître son cheminement et les fichiers qui ont été contaminés par l’infection. 1555.3. EXPÉRIMENTATIONS Cette représentation permet de voir les liens entre les différentes entités du système ainsi que de connaître les interactions réalisées par chaque processus au moment de l’étude. Néanmoins, elle ne permet pas de tout représenter. En effet, dans un souci de clarté pour la représentation, nous avons fait le choix de ne pas y inclure toutes les interactions des processus ni les éléments du registre. De plus, cette représentation nous fait perdre la notion de temporalité des interactions. Il faut noter que cette première représentation est suffisante pour comprendre le comportement global de l’infection et établir des règles de contrôle d’accès permettant de contrer explicitement son installation. Mais pour comprendre tout le cheminement de l’installation, il est nécessaire d’ajouter la notion de temps pour situer les interactions les unes par rapport aux autres. Automates La représentation des traces sous la forme d’automates nous permet d’exprimer la notion de temporalité des interactions que nous n’avons pas avec la représentation sous la forme de graphe. Nous allons ainsi générer un automate global, c’est-à-dire que nous allons représenter les opé- rations importantes réalisées par le logiciel malveillant pour en dégager un comportement. Nous affinerons ce comportement en prenant en compte des "sous automates". Grâce à ces différents éléments, nous pourrons écrire des règles de contrôle d’accès ciblant des comportements que nous considérons comme malveillants. La figure 5.12 montre un résultat simplifié de la génération de l’automate. Ce résultat est simplifié puisque nous n’identifions qu’un nombre restreint d’actions qui conduisent à l’installation de l’infection. Nous voyons dans cet automate que le canal de communication utilisé entre les différentes entités mises en jeu dans l’installation de l’infection est une valeur dans le registre. Nous avons nommé sample le fichier binaire qui est à la base de l’installation. Cette représentation simplifiée permet d’inclure les éléments qui étaient difficiles à inclure dans les graphes pour ne pas nuire à la lecture. La simplification repose sur deux éléments : tout d’abord, nous ne nommons pas explicitement les objets du système, ensuite, nous n’utilisons pas directement le temps des interactions, nous numérotons les interactions pour plus de clarté. sample Corbeille Valeur registre Flash Player Installer services.exe 7: Suppression 1: Ecriture 2: Ecriture 3: Ecriture 4: Exécution 5: Lecture 6: Ecriture 8: Ecriture 10: Exécution 9: Lecture FIGURE 5.12 – Automate complet des interactions réalisées par le logiciel malveillant L’automate met en relief la séquentialité des opérations qui se sont déroulées durant l’infection. Cette forme sert d’intermédiaire entre les graphes des processus et les diagrammes de séquence. Même si les interactions sont numérotées, cet automate fait perdre la notion de temporalité des interactions. Nous proposons donc une représentation sous la forme d’un diagramme de séquence pour raffiner encore l’analyse comme l’illustre la figure 5.13. C’est à partir de ce diagramme que nous allons pouvoir identifier des comportements malveillants ou des séquences d’interactions propres à la détection de logiciel malveillant. À partir de l’automate que nous avons présenté 5.12 ainsi que du diagramme de séquence 5.13, nous allons résumer le déroulement de l’installation de l’infection : 1565.3. EXPÉRIMENTATIONS sample Corbeille Registre Flash services Ecriture Ecriture Ecriture Exécution Lecture Ecriture Suppression Ecriture Lecture Exécution t0 t1 temps t2 t3 t4 t5 t6 t7 t8 t9 FIGURE 5.13 – Diagramme d’activité sur l’installation de l’infection — écriture du sample sur le disque et exécution du fichier : ces deux phases ne sont pas repré- sentées ici car elles peuvent varier suivant les contextes. On peut imaginer un utilisateur qui télécharge et qui l’exécute, ou encore une exploitation de vulnérabilité dans un module tiers d’un navigateur. — écriture des éléments pour initialiser l’installation de l’infection dans un répertoire spéci- fique. Ce répertoire est ensuite renseigné dans le registre ; — exécution de la charge active ; — suppression du sample ; — lecture des informations importantes pour l’installation et l’écriture des éléments permettant à l’infection de survivre ; — exploitation d’une vulnérabilité dans un processus possédant des droits élevés. Nous avons donc proposé trois outils permettant d’analyser les logiciels malveillants. Ces trois outils sont complémentaires en proposant chacun un degré de précision différent. La première représentation, celle sous la forme de graphe, permet de connaître, de façon macroscopique, les interactions qui ont été faites par tous les éléments du système. On peut ainsi connaître les éléments qui ont été écrits, lus, chargés et supprimés. Nous n’avons présenté dans cette étude que les interactions faites sur le système de fichiers. Nous pouvons naturellement faire la même chose pour les interactions faites au niveau du registre. La seconde représentation propose un raffinement de l’analyse en numérotant le début des interactions grâce à l’utilisation des timestamps. Cette représentation permet de connaître l’enchainement des interactions faites sur le système. La troisième représentation ajoute un nouveau niveau de raffinement en détaillant les temps du début des interactions. Ce diagramme pourra être étendu en rajoutant les dates de fin des interactions. Politiques de protection Maintenant que nous connaissons le comportement du logiciel malveillant par la définition de l’automate et par la création d’un diagramme de séquence, nous pouvons écrire des politiques de protection dans le but de bloquer ces comportements malveillants. 1575.3. EXPÉRIMENTATIONS ✞ ☎ 1 neverallow domain recycle_bin_t:file { execute } 2 neverallow domain recycle_bin_t:process { execute } ✝ ✆ Listing 5.29 – Règle bloquant l’exécution d’un élément de la corbeille Le premier comportement que l’on peut bloquer est l’exécution d’un élément dans la corbeille de Windows. Pour ce faire, il suffit de mettre une labellisation générique sur cet élément du type recycle_bin_t et d’empêcher toute exécution d’un objet de ce type. Par exemple, les règles 5.29 permettent de contrer l’exécution d’un fichier de type recycle_bin_t. Pour cela, nous allons utiliser une interaction spécifique de la politique par l’utilisation de l’instruction neverallow dans la politique de contrôle d’accès. De plus, pour que cette règle s’applique à tous les sujets du système, nous utiliserons l’instruction domain, qui repré- sente tous les domaines du système. Cette règle bloque donc explicitement l’interaction numéro 10 de notre automate 5.12. Cependant, ces règles de contrôle d’accès peuvent se révéler difficiles à mettre en place. En effet, elles pourraient nuire à l’utilisation normale du système. Imaginons par exemple qu’un administrateur définisse la règle suivante 5.30, qui empêche toute écriture de fichier dans la corbeille, cela implique que les utilisateurs ne peuvent plus déplacer de fichiers ou de dossiers dans la corbeille. Ce qui nuit au fonctionnement d’un programme ou du système. ✞ ☎ 1 neverallow domain recycle_bin_t:file { write } ✝ ✆ Listing 5.30 – Règle bloquant l’écriture d’un élément dans la corbeille C’est pour cela que nous allons plutôt utiliser des propriétés de sécurité en utilisant le langage de PIGA. Nous noterons les contextes de sécurité sujets scs et les contextes de sécurité objets sco. Voici, sous une forme simple, les interactions qui se déroulent sur le système en termes de contexte de sécurité et d’opérations élémentaires. 1. scs1 →w sco : création d’un nouvel objet, i.e : le sample écrit dans la corbeille. 2. scs1 →w sco1 : création d’un second objet, i.e : le sample écrit dans les fichiers temporaires l’installateur modifié de FlashPlayer. 3. scs1 →x sco1 ⇒t scs2 : exécution du second objet qui transite vers un nouveau contexte sc2. 4. scs2 →w scs3 : le nouveau domaine interagit avec un troisième domaine déjà présent sur le système. 5. scs3 →x sco : ce troisième domaine va exécuter l’objet écrit par le premier domaine. Cette énumération nous permet d’écrire directement la propriété de sécurité correspondante 5.31. ✞ ☎ 1 define zeroaccess_behavior ( $sc1 IN SCS ) [ 2 Foreach $eo1 IN is_write_like(IS), Foreach $eo2 IN is_write_like(IS), Foreach $eo3 IN is_execute_like(IS), 3 Foreach $oe4 IN is_write_write(IS), Foreach $oe5 IN is_execute_like( IS), 4 Foreach $sc2 IN $SCS, Foreach $sc3 IN $SCS, 5 Foreach $sco1 IN $SCO, Foreach $sco IN $SCO, 6 Foreach $a1 IN ACT, Foreach $a2 IN ACT 7 TQ { ( [ $a2 := $sc3 -> { $eo5 } $sco ] o $sc2 -> { $eo4 } $sc3 ) 8 o ( $sc1 -> { $eo3 } $sco1 o $sc1 -> { $eo2 } $so1 o [ $a1 := $sc1 -> { $eo1 } $sco ] ) } , 9 { INHERIT($a2 , $a1) }; 1585.4. DISCUSSION 10 11 ]; ✝ ✆ Listing 5.31 – Propriété de sécurité pour PIGA contrant l’installation d’une variante de ZeroAccess Grâce à cette propriété, nous sommes capables de contrôler de manière un scénario complet. Nous avons donc proposé deux méthodes pour contrer l’installation de ce logiciel malveillant. La première méthode consiste à bloquer une interaction directe qui ne semble pas légitime faite par le logiciel malveillant. Même si cette solution est efficace, sa portée sur le fonctionnement du système pourrait se révéler très préjudiciable. En effet, les règles d’accès créées pourraient bloquer le système. C’est pour cela que nous avons proposé une solution basée sur l’utilisation d’un second moniteur de référence, qui offre la possibilité de bloquer un scénario complet plutôt qu’une interaction précise. 5.4 Discussion Dans ce chapitre, nous avons détaillé les choix que nous avions fait pour répondre aux problèmes soulevés dans la partie formalisation. En ce qui concerne la problématique de désignation des contextes sous Windows, nous avons fait le choix, pour la construction des noms symboliques absolus indépendants de la localisation d’utiliser les variables d’environnement. Elles ont l’avantage d’être à la fois communes à tous les systèmes Windows et d’être gérées par le système. De plus, elles peuvent être étendues par l’administrateur pour répondre à des problèmes spécifiques. Cette solution nous a permis de répondre à un second problème plus lié à l’implantation. En effet, nous avons dû résoudre la problématique de stockage des contextes de sécurité pour les objets dans le modèle de protection basé sur DTE. Comme nous ne pouvions utiliser les attributs étendus du système de fichiers comme le fait SELinux, nous avons mis en place un système de labellisation dynamique. Cette méthode présente l’avantage d’être plus simple à administrer et plus portable car ne nécessitant pas de labelliser les systèmes des fichiers. Nous avons ensuite proposé deux implantations des méthodes de détournement que nous avons décrites dans la partie formalisation. Ces deux méthodes nous ont permis de tester et de valider nos politiques de protection pour les deux modèles PBAC et DTE. Nous avons ensuite fait le choix de poursuivre nos expérimentations en utilisant le modèle de protection DTE. Nos expérimentations ont porté sur deux aspects. Le premier point montre que nous sommes capables d’associer notre moniteur Windows au moniteur PIGA pour contrôler efficacement les scénarios complets. Le second concerne la protection contre les logiciels malveillants. Une architecture dédiée permet l’envoi des traces de notre moniteur à un serveur limitant ainsi la compromission de l’analyse. L’analyse permet de comprendre le scénario complet et de déduire une politique pour notre moniteur ou pour PIGA qui empêche le scénario d’attaque. La solution PIGA propose une méthode optimiste qui limite moins les activités légitimes. 5.4.1 Pertinence/complétude de la solution Notre solution, basée sur une architecture modulaire est capable d’implanter deux modèles de protection. Le premier est basé sur le modèle PBAC et le second sur le modèle DTE. Ces deux modèles permettent de définir des politiques de contrôle d’accès fines et précises. Chaque ressource du système est parfaitement identifiée. Notre solution facilite la maintenabilité du mécanisme de contrôle d’accès. Le mécanisme de création de politique basé à la fois sur un mode d’apprentissage auquel s’ajoute un outil de création de politique de contrôle d’accès, facilite le travail de l’administrateur. Quel que soit le modèle de 1595.4. DISCUSSION protection utilisé, il est possible d’avoir une couche d’abstraction efficace des ressources et ainsi de pouvoir porter facilement des politiques d’un système à un autre. Que ce soit en modifiant la table contenant tous les appels système ou par l’ajout d’un filterdriver, nous sommes capables de gérer finement les accès, que ce soit sur le registre, au niveau réseau et ou sur le système de fichiers. Non seulement nous pouvons vérifier les accès en prétraitement, mais aussi en post-traitement puisque nous détournons entièrement le flux d’exécution, chose que ne font pas encore les MAC tels que SELinux. Grâce à cette implantation, nous contrôlons toutes les entrées/sorties des processus. Nous contrôlons aussi les méthodes de synchronisations entre threads. Ces évènements passent par des appels système que nous contrôlons. 5.4.2 Performances Même si l’objectif de nos expérimentations n’était pas les performances, nous avons évalué la latence que génère notre implantation. Nous avons fait ce test de performance sur la version qui modifie la table des appels système. Nous avons ainsi pu noter qu’il y avait une latence générée au démarrage des applications par notre mécanisme de contrôle d’accès. Cela s’explique par les nombreuses interactions faites sur le système de fichiers réalisées par l’application pour charger ses bibliothèques, créer ses fichiers spécifiques, accéder au registre pour récupérer ses informations de configuration, etc. Cette latence, que nous avons notée et estimée à un ajout de 2 secondes en moyenne par rapport au temps de lancement normal de l’application, peut facilement être réduite en introduisant les mêmes optimisations que pour SELinux. Par exemple, l’ajout d’un système de cache dans notre driver SEWINDOWS pourrait accélérer la prise de décision. Ainsi, il ne serait pas nécessaire d’aller consulter la politique SEWINDOWS à chaque interaction faite par le même contexte sujet. Une seconde optimisation serait de ne pas vérifier à chaque fois les accès pour certains types d’interactions, comme les opérations de lecture ou d’écriture. Par exemple, lorsqu’un sujet demande l’accès en lecture sur un objet, l’accès est vérifié une première fois dans la politique. Puis, tant que les contextes de sécurité mis en jeu ne sont pas modifiés, nous pouvons considérer qu’il est inutile de vérifier de nouveau l’accès. Il faudrait vérifier que cette optimisation ne nuit pas à la sécurité du système et qu’il n’existe pas de solution pour la contourner. Il faut noter que cette optimisation a été mise en place dans SELinux. Enfin, une troisième optimisation concerne le parcours de la politique par le serveur de sécurité. Nous avons développé une première version où le moniteur mémorise la politique sous la forme de chaîne de caractères. Nous avons ensuite mis en place un système basé sur des tables de hashages. Une méthode pour optimiser la recherche dans la politique serait d’avoir une table par sujet, ainsi, il ne serait plus nécessaire de parcourir la politique entièrement à chaque fois. 160Chapitre 6 Conclusion Les enjeux de cette thèse étaient doubles. D’une part, il s’agissait d’améliorer la sécurité des systèmes de calcul intensif basés sur Linux. D’autre part, des solutions devaient être apportées pour que les postes de travail Windows puissent garantir des objectifs de sécurité. Le fait de rassembler ces deux points présentait déjà une difficulté technique puisqu’il fallait connaitre deux systèmes d’exploitation et maîtriser le développement dans leurs noyaux respectifs. Cet aspect technique constituait en soi un pari. Un des objectifs était donc d’offrir un cadre commun pour protéger des contextes d’usages aussi différents que le calcul intensif et les postes de travail Windows. Définir une approche extensible était une première difficulté. De plus, il était nécessaire de s’intéresser en parallèle à la sécurité et aux performances, ce qui est en soi assez antinomique. Enfin, il fallait s’intéresser aux vulnérabilités des postes de travail et offrir des méthodes avancées d’analyse et de protection. Il aurait été possible de faire une thèse sur chacun de ces points pris séparément. Il n’en reste pas moins que s’intéresser de façon globale à ces domaines en dégageant correctement les problèmes et en proposant des solutions extensibles constitue déjà un objectif ambitieux et intéressant. Au final, nous répondons globalement à ces différents points d’étude en définissant un cadre commun à la protection du calcul intensif et des postes de travail. En introduction, nous avons ainsi décrit le problème de sécurité, à savoir contrôler les interactions directes et être capable de contrôler les scénarios d’attaque complets. Nous avons aussi synthétisé les manques dans ces domaines, à savoir l’absence de modèle général, non seulement pour observer les appels système, mais aussi pour répartir efficacement différents observateurs afin de détecter et prévenir des scénarios d’attaque complets. Nous nous sommes intéressés aux observateurs appelés moniteurs de référence et capables de garantir l’intégrité et la confidentialité. Nous avons considéré aussi le besoin d’une méthode pour répartir ces moniteurs, ainsi que mesurer et comparer les performances de différentes solutions. Enfin, nous avons considéré, d’une part, la nécessité d’un observateur constituant un moniteur de référence portable pour contrôler les interactions directes, et d’autre part, d’une implantation de ce moniteur pour Windows afin d’analyser et prévenir les scénarios d’activité des logiciels malveillants. Dans le chapitre 2, nous avons établi l’état de l’art. Il montre à la fois le manque de modèle gé- nérique d’observateurs, les faiblesses des moniteurs de référence existants et le manque de modèle et de solutions pour répartir différents observateurs et évaluer leurs performances de façon précise et extensible. Cet état de l’art étaye les points adressés par notre étude et justifie la réalité des difficultés que nous avons listées en introduction. Il montre qu’il y a un réel manque de moniteurs répartis pour le calcul intensif et de solutions pour les postes de travail Windows. Le chapitre 3 a proposé une définition générique de la notion d’observateur capable de capturer les appels système des différents processus pour contrôler les accès aux ressources du système d’exploitation. Nous avons distingué trois modes de sécurité : requête/réponse, évidence et noti- fication. Ils couvrent la majorité des approches permettant de détecter ou protéger les activités. 161Cette notion d’observateur est très générale et correspond à un large ensemble de mécanismes de sécurité (pare-feu, contrôle d’accès des processus, antivirus, antimalware, détection d’intrusion. . . ). Nous avons définis un type particulier d’observateur, le moniteur de référence, qui nous intéresse en priorité. Ensuite, nous avons proposé un modèle conceptuel qui caractérise la répartition des observateurs en terme d’association, de localisation et de redondance. Les deux types d’association, cascade et notification, permettent de décrire le couplage de différents observateurs. En pratique, le type cascade est le plus représentatif car il couvre bien la façon habituelle de coopérer des observateurs. Les quatre localisations distinguent les observateurs colocalisés, distants, parallèles et partagés. Ces différentes localisations visent à classifier les méthodes de répartition des observateurs et de leurs clients. La redondance concerne les méthodes de tolérance aux pannes d’un observateur. Pour la partie poste de travail, nous avons proposé une politique pour contrôler les accès directs de façon obligatoire (MAC). Cette politique est générique, mais correspond bien aux modèles DTE et PBAC adoptés sous Unix. Nous avons défini une façon de mettre en œuvre cette politique pour Windows en offrant un mécanisme de désignation des processus et des ressources qui simplifie l’administration des politiques. Nous avons proposé différentes méthodes pour détourner les appels système des processus sous Windows afin de pouvoir contrôler leurs activités. Ainsi, par la conjonction du modèle de politique et d’un détournement, nous sommes capables d’offrir un modèle conceptuel de moniteur de référence qui est bien adapté à Windows. Le chapitre 4 a étudié la répartition des observateurs en environnement de calcul intensif. Nous avons proposé d’abord un objectif de mesure précise des performances. Pour cela, nous nous sommes concentrés sur la répartition de deux observateurs en mode cascade en considérant qu’ils peuvent être colocalisés ou distants. Nous avons proposé un calcul de la combinatoire des évaluations et établissons la liste de mesures à effectuer. Nous avons proposé ainsi différentes mesures globales et mesures détaillées. Nous pouvons déduire le temps de communication entre les deux observateurs et comparer les performances pour les combinaisons des différentes approches. Une mise en œuvre du mode distant à haute performance est proposée en utilisant des technologies InfiniBand. L’efficacité repose sur deux coupleurs InfiniBand pour les communications entre les deux observateurs. Nous avons proposé un protocole de mesure des performances reposant sur deux logiciels de test. Le premier logiciel est le benchmark Linpack pour le HPC. Ce benchmark n’est pas complètement représentatif des codes de calcul du CEA mais constitue le meilleur des cas puisqu’il fait peu d’opérations d’entrée/sortie. Le second est un logiciel développé spécifiquement pour stresser le système en réalisant un grand nombre d’entrées/sorties avec des politiques SELinux et PIGA exigeantes en temps de calcul. On peut considérer qu’il s’agit donc du pire cas. La réalité se situant entre ces deux cas, nous avons montré qu’il est possible de limiter le surcoût à 10% pour les nœuds de calcul pour le mode détection et 25% pour le mode protection. Des optimisations supplémentaires permettront de pouvoir passer en dessous de 5% et 10% respectivement pour le mode détection et protection. Si ces résultats restent discutables, ils montrent la possibilité d’un faible surcoût au regard du contrôle de scénarios d’attaque complets. L’approche est efficace en termes de sécurité puisqu’elle réalise un contrôle optimiste qui ne limite pas les activités légitimes. Dans le chapitre 5, nous avons décrit la mise en œuvre d’un moniteur de référence pour Windows autorisant l’analyse et le contrôle des logiciels malveillants. Nous avons proposé une implantation de la désignation des ressources basée sur les variables d’environnement. Cette méthode calcule dynamiquement les contextes de sécurité et évite donc d’avoir à les stocker au niveau des systèmes de fichiers, simplifiant ainsi l’administration. Nous utilisons le moniteur en mode dé- tection pour transférer de façon sûre les accès observés à un serveur. Cette approche a pour but d’analyser le scénario d’attaque complet via différentes représentations graphiques. Ainsi, nous sommes capables de décrire le déroulement temporel et logique du scénario. Nous montrons que nous pouvons définir une politique pour notre moniteur, ou pour le moniteur PIGA, qui empêche 1626.1. PERSPECTIVES l’attaque observée. Le contrôle des interactions directes par notre moniteur est plus immédiat, mais présente le risque de limiter les activités légitimes des processus. A contrario, l’approche PIGA est plus optimiste puisqu’elle peut bloquer le scénario à un point précis de son avancement. Nous avons développé deux méthodes de détournement des appels système, la seconde étant davantage portable. Globalement, nous livrons ainsi un moniteur portable aussi bien en termes de détournement que de politique pour des environnements Windows 7 hétérogènes. 6.1 Perspectives Amélioration des performances de PIGA Nous avons montré au cours du chapitre 4 que l’inté- gration de SELinux dans les environnements HPC était aujourd’hui possible, notamment grâce aux différentes optimisations réalisées. Cette intégration est possible car le surcoût dû à SELinux est de l’ordre d’une µs par appel système. Même si le déport par Infiniband du moniteur PIGA amé- liore les performances, des optimisations supplémentaires sont nécessaires pour passer en dessous d’un surcoût de 5% pour les nœuds de calcul. C’est pour cela qu’il est nécessaire de travailler à l’optimisation de PIGA. Cela peut passer par la réécriture complète de la partie PIGA-UM pour qu’elle soit résidente en espace noyau. Actuellement, la partie PIGA-UM est écrite en Java, qui est une technologie consommatrice de ressources. En modifiant le code avec un langage moins consommateur, il serait alors possible de co-localisé PIGA-UM sur un nœud client. De plus, comme nous l’avons présenté au cours de notre étude, nous avons utilisé PIGA avec des politiques de sécurité extrêmement génériques capable de couvrir un large ensemble de scénarios complets. Cette large couverture n’est pas spécifique aux environnements HPC, il est donc nécessaire de travailler ces propriétés pour qu’elles soient spécifiques à ces environnements. Grâce aux nouvelles propriétés, PIGA aurait un plus petit nombre d’activités à surveiller et ces performances en seront améliorées. Enfin, les compressions des signatures proposées dans [Clairet et al., 2012] devraient diminuer de façon importante le temps de traitement et l’occupation mémoire. Observateurs dans les systèmes répartis Nous avons commencé à mettre en place le mode de redondance maître-esclave sur l’architecture que nous avons proposée dans le chapitre 4. Il est nécessaire de poursuivre les travaux que nous avons commencés dans le but d’avoir un système tolérant aux différentes pannes. Nous avons concentré notre étude sur le mode distant pour le second observateur. Nous pouvons maintenant orienter nos travaux sur les modes parallèles et partagés des observateurs, dans un premier temps pour résoudre le problème de dimensionnement du mécanisme de protection, et dans un second temps pour pouvoir corréler les requêtes reçues par le second observateur. En effet, actuellement, le mode distant impose d’avoir une machine dédiée par observateur distant (dans notre étude PIGA), ce qui pose un problème de dimensionnement de l’architecture de protection puisque si nous voulons protéger 1 000 nœuds, il est nécessaire d’avoir 1 000 serveurs de sécurité pour une localisation en mode distant. En travaillant sur les modes parallèles et partagés, nous pourrions ainsi réduire le nombre de serveurs de sécurité utilisés dans notre architecture de protection. De plus, il serait alors possible d’écrire des propriétés de sécurité adaptées aux systèmes répartis. Expérimentations à plus grande échelle de notre moniteur SEWINDOWS La première extension pour les systèmes Windows serait la mise en place d’expérimentations à grande échelle pour notre mécanisme de protection. Les objectifs seraient de corriger les limites de nos implantations, de définir des politiques de plus en plus complètes ainsi que de connaître précisément l’impact sur les performances du système. 1636.1. PERSPECTIVES De plus, il serait intéressant de travailler sur les contextes de sécurité. Dans la version actuelle, seuls les types et les domaines sont traités par notre moniteur, nous pourrions développer le contrôle d’accès en nous basant sur les SID et sur les rôles. Association des observateurs sur les systèmes Windows A partir des modèles que nous avons définis dans le chapitre 3 de ce mémoire, il faudrait, par la suite, associer notre observateur avec un autre observateur réalisant des calculs plus complexes. Au cours de notre étude, nous avons réalisé cette composition de façon offline en rejouant les traces générées dans PIGA. Maintenant, il faudrait les faire fonctionner tous les deux sur un même système. De plus, les travaux que nous avons présentés sous Linux, visant à utiliser des technologies du HPC pour déporter de manière efficace le second observateur, pourraient aussi être utilisés sur les systèmes Windows. En effet, le proxy que nous avons développé est en mesure de réaliser les mêmes actions que sur les systèmes Linux. Par extension, l’intégration de ce modèle de protection pourrait être fait dans les architectures de cloud basées sur les technologies de Microsoft. Extension de la répartition à d’autres systèmes d’exploitation Nous avons présenté la notion d’observateur pour les systèmes Linux et Windows puis nous avons défini la notion de répartition. Nous avons montré au cours de notre étude que nous pouvions appliquer ces deux notions sur ces deux systèmes et dans des environnements hétérogènes. Nous pourrions maintenant étendre ces notions à d’autres systèmes d’exploitation tels que les les systèmes Android et les OSX. De plus, comme les systèmes Android ont pour base les systèmes Linux, nous pourrions dé- ployer les deux observateurs que nous avons testés, à savoir SELinux et PIGA. 164Chapitre 7 Bibliographie [ Alexander Kjeldaas, 1998] ALEXANDER KJELDAAS (1998). Linux Capability FAQ v0.1. http://www.uwsg.indiana.edu/hypermail/linux/kernel/9808.1/ 0178.html. [Anderson, 1980] ANDERSON, J. (1980). Computer security threat monitoring and surveillance. Rapport technique, James P. Anderson Company, Fort Washington, Pennsylvania. [Anderson, 1972] ANDERSON, J. P. (1972). Computer Security technology planning study. Rapport technique, Deputy for Command and Management System, USA. [ANR, 2009] ANR (2009). Anr sec&si. http://www.agence-nationalerecherche.fr/programmes-de-recherche/appel-detail/programmesystemes-embarques-et-grandes-infrastructures-defi-securitesysteme-d-exploitation-cloisonne-et-securise-pour-linternaute-2008/. [Bell et La Padula, 1973] BELL, D. E. et LA PADULA, L. J. (1973). Secure computer systems : Mathematical foundations and model. Technical Report M74-244, The MITRE Corporation, Bedford, MA. [Biba, 1975] BIBA, K. J. (1975). Integrity considerations for secure computer systems. Technical Report MTR-3153, The MITRE Corporation. [Bishop, 2003] BISHOP, M. (2003). Computer Security Art and Science. Numéro ISBN 0201440997. Addison-Wesley Professional. [Blanc, 2006] BLANC, M. (2006). Sécurité des systèmes d’exploitation répartis : architecture décentralisée de méta-politique pour l’administration du contrôle d’accès obligatoire. These, Université d’Orléans. [Blanc et al., 2014] BLANC, M., BOUSQUET, A., BRIFFAUT, J., CLEVY, L., GROS, D., LEFRAY, A., ROUZAUD-CORNABAS, J., TOINARD, C. et VENELLE, B. (2014). Mandatory access protection within cloud systems. In NEPAL, S. et PATHAN, M., éditeurs : Security, Privacy and Trust in Cloud Systems, pages 145–173. Springer Berlin Heidelberg. [Blanc et al., 2011] BLANC, M., BRIFFAUT, J., TOINARD, C. et GROS, D. (2011). PIGA-HIPS : Protection of a shared HPC cluster. International journal on advances in security, 4(1):44–53. [Blanc et al., 2012] BLANC, M., GROS, D., BRIFFAUT, J. et TOINARD, C. (2012). PIGAWindows : contrôle des flux d’information avancés sur les systèmes d’exploitation Windows 7. In MajecSTIC 2012, Villeneuve d’Ascq, France. [Blanc et al., 2013a] BLANC, M., GROS, D., BRIFFAUT, J. et TOINARD, C. (2013a). Mandatory access control with a multi-level reference monitor : PIGA-cluster. In ACM CLHS ’13 Procee- 165dings of the first workshop on Changing landscapes in HPC security, pages 1–8, New-York, United States. ACM. [Blanc et al., 2013b] BLANC, M., GROS, D., BRIFFAUT, J. et TOINARD, C. (2013b). PIGACluster : a distributed architecture integrating a shared and resilient reference monitor to enforce mandatory access control in the HPC environment. In SHPCS - 8th International Workshop on Security and High Performance Computing Systems - 2013, Helsinki, Finland. [Blanc et Lalande, 2012] BLANC, M. et LALANDE, J.-F. (2012). Improving Mandatory Access Control for HPC clusters. Future Generation Computer Systems, pages –. [Boebert et Kain, 1985] BOEBERT, W. E. et KAIN, R. Y. (1985). A practical alternative to hierarchical integrity policies. In The 8th National Computer Security Conference, pages 18–27, Gaithersburg, MD, USA. [Briffaut, 2007] BRIFFAUT, J. (2007). Formalization and guaranty of system security properties : application to the detection of intrusions. Thèse de doctorat, Université d’Orléans. SDS. [Briffaut et al., 2009] BRIFFAUT, J., LALANDE, J.-F. et TOINARD, C. (2009). Formalization of security properties : enforcement for MAC operating systems and verification of dynamic MAC policies. International journal on advances in security, 2(4):325–343. ISSN : 1942-2636. [Casey Schaufler , 2008] CASEY SCHAUFLER (2008). The Simplified Mandatory Access Control Kernel . White Paper, pages 1–11. [Clairet et al., 2012] CLAIRET, P., BERTHOMÉ, P. et BRIFFAUT, J. (2012). Compression de signatures pour PIGA IDS. In ETIEN, A., éditeur : 9ème édition de la conférence MAnifestation des JEunes Chercheurs en Sciences et Technologies de l’Information et de la Communication - MajecSTIC 2012 (2012), Villeneuve d’Ascq, France. Nicolas Gouvy. [Clark et Wilson, 1987] CLARK, D. D. et WILSON, D. R. (1987). A Comparison of Commercial and Military Computer Security Policies. Proc. IEEE Symp. Computer Security and Privacy, IEEE CS Press, pages 184–194. [Corporation, 2003] CORPORATION, N. D. (2003). Tomoyo. http://tomoyo. sourceforge.jp/index.html.en. [Darivemula et al., 2006] DARIVEMULA, A., BOX, C., TIKOTEKAR, A. et POURZANDI, M. (2006). Work in progress : Rass framework for a cluster-aware selinux. Cluster Computing and the Grid, IEEE International Symposium on, 2:29. [Ferraiolo et Kuhn, 1992] FERRAIOLO, D. F. et KUHN, D. R. (1992). Role-based access controls. In 15th National Computer Security Conference, pages 554–563, Baltimore, MD, USA. [Focardi et Gorrieri, 2001] FOCARDI, R. et GORRIERI, R. (2001). Classification of security properties (part i : Information flow). [Gros et al., 2012] GROS, D., TOINARD, C. et BRIFFAUT, J. (2012). Contrôle d’accès mandataire pour Windows 7. In SSTIC 2012, pages 266–291, Rennes, France. [Hagimont et J.Mossière, 1996] HAGIMONT, D. et J.MOSSIÈRE (1996). Problèmes de désignation, de localisation et d’accès dans les systèmes répartis à objets . Rapport technique. [Harrison et al., 1976] HARRISON, M. A., RUZZO, W. L. et ULLMAN, J. D. (1976). Protection in operating systems. Communications of the ACM, 19(8):461–471. [Hoglund et Butler, 2005] HOGLUND, G. et BUTLER, J. (2005). Rootkits : Subverting the Windows Kernel. Addison-Wesley Professional. [Hunt et Brubacher, 1999] HUNT, G. et BRUBACHER, D. (1999). Detours : Binary interception of win32 functions. In Proceedings of the 3rd Conference on USENIX Windows NT Symposium - Volume 3, WINSYM’99, pages 14–14, Berkeley, CA, USA. USENIX Association. 166[ITSEC, 1991] ITSEC (1991). Information Technology Security Evaluation Criteria (ITSEC) v1.2. Technical report. [Labs, 2005] LABS, C. (2005). Core force user’s guide. pages 1–2. [Lampson, 1969] LAMPSON, B. W. (1969). Dynamic protection structures. In AFIPS Fall Joint Computer Conference (FJCC 1969), volume 35, pages 27–38, Las Vegas, Nevada, USA. AFIPS Press. [Lampson, 1971] LAMPSON, B. W. (1971). Protection. In The 5th Symposium on Information Sciences and Systems, pages 437–443, Princeton University. [Lampson, 1973] LAMPSON, B. W. (1973). A note on the confinement problem. Commun. ACM, 16(10):613–615. [Leangsuksun et Haddad, 2004] LEANGSUKSUN, C. et HADDAD, I. (2004). Building highly available hpc clusters with ha-oscar. In Cluster Computing, 2004 IEEE International Conference on, page 2. [Leangsuksun et al., 2005] LEANGSUKSUN, C., TIKOTEKAR, A., POURZANDI, M. et HADDAD, I. (2005). Feasibility study and early experimental results towards cluster survivability. In Proceedings of the Fifth IEEE International Symposium on Cluster Computing and the Grid - Volume 01, CCGRID ’05, pages 77–81, Washington, DC, USA. IEEE Computer Society. [M. Fox et Thomas, 2003] M. FOX, J. Giordano, L. S. et THOMAS, A. (2003). Selinux and grsecurity : a side-by-side comparison of mandatory access control and access control list implementations. Rapport technique. [McAfee, 2013] MCAFEE (2013). ZeroAccess Rootkity. Rapport technique, McAfee. [Microsoft, 2009] MICROSOFT (2009). Applocker. http://technet.microsoft.com/ en-us/library/dd759117.aspx. [Microsoft, 2013] MICROSOFT (2013). Windows integrity mechanism design. In The Microsoft Developper Network. [Naldurg et al., 2006] NALDURG, P., SCHWOON, S., RAJAMANI, S. et LAMBERT, J. (2006). Netra : : seeing through access control. In FMSE ’06 : Proceedings of the fourth ACM workshop on Formal methods in security, pages 55–66, New York, NY, USA. ACM. [OASIS, 2013] OASIS (2013). Xacml. https://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=xacml. [Pourzandi et al., 2002] POURZANDI, M., HADDAD, I., LEVERT, C., ZAKRZEWSKI, M. et DAGENAIS, M. (2002). A distributed security infrastructure for carrier class linux clusters. [Richard Ward, 2006] RICHARD WARD, Jeffrey Hamblin, P. B. (2006). Mandatory integrity control. [Rouzaud-Cornabas, 2010] ROUZAUD-CORNABAS, J. (2010). Formalisation de propriétés de sécurité pour la protection des systèmes d’exploitation. Thèse de doctorat. [Saltzer et Schroeder, 1975] SALTZER, J. et SCHROEDER, M. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9):1278 – 1308. [Sandhu, 1988] SANDHU, R. S. (1988). The schematic protection model : Its definition and analysis for acyclic attenuating schemes. Journal of the ACM, 35(2):404–432. [Sandhu, 1992] SANDHU, R. S. (1992). The Typed Access Matrix Model. In Proceedings of the IEEE Symposium on Research in Security and Privacy, pages 122–136, Oakland, CA, USA. IEEE. [Sandhu et al., 1996] SANDHU, R. S., COYNE, E. J., FEINSTEIN, H. L. et YOUMAN, C. E. (1996). Role-based access control models. Computer, 29:38–47. 167[Soshi et al., 2004] SOSHI, M., MAEKAWA, M. et OKAMOTO, E. (2004). The dynamic-typed access matrix model and decidability of the safety problem. IEICE Transactions, 87-A(1):190– 203. [Spencer et al., 1998] SPENCER, R., SMALLEY, S., LOSCOCCO, P., (national SECURITY AGENCY), P. L., HIBLER, M., LEPREAU, J. et ANDERSEN, D. (1998). The flask security architecture : System support for diverse security policies. In in Proceedings of The Eighth USENIX Security Symposium, pages 123–139. [Spender, 2003] SPENDER (2003). Grsecurity feature. https://grsecurity.net/ features.php. [Spengler, 2002] SPENGLER, B. (2002). Detection, prevention, and containment : A study of grsecurity. In In Libre Software Meeting 2002 (LSM2002), Bordeaux, France. [Takeda, 2009] TAKEDA, K. (2009). Tomoyo linux overview. security mini-conf. [TCSEC, 1985] TCSEC (1985). Trusted Computer System Evaluation Criteria. Technical Report DoD 5200.28-STD, Department of Defense. [Team, 2012] TEAM, P. (2012). 20 Years of PaX. pages 1–20, Rennes, France. SSTIC 2012. [Wang et al., 2008] WANG, X., LI, Z., LI, N. et CHOI, J. Y. (2008). Precip : Towards practical and retrofittable confidential information protection. In In 16th Annual Network and Distributed System Security Symposium. [Wright et al., 2002] WRIGHT, C., COWAN, C., SMALLEY, S., MORRIS, J. et KROAHHARTMAN, G. (2002). Linux security modules : General security support for the linux kernel. In Proceedings of the 11th USENIX Security Symposium, pages 17–31, Berkeley, CA, USA. USENIX Association. 168Première partie Annexes 169Annexe A Configuration pour le logiciel linpack et utilisation ✞ ☎ 1 HPLinpack benchmark input file 2 Innovative Computing Laboratory, University of Tennessee 3 HPL.out output file name (if any) 4 6 device out (6=stdout,7=stderr,file) 5 1 # of problems sizes (N) 6 26752 Ns 7 1 # of NBs 8 128 NBs 9 0 PMAP process mapping (0=Row-,1=Column-major) 10 1 # of process grids (P x Q) 11 2 Ps 12 4 Qs 13 16.0 threshold 14 3 # of panel fact 15 0 1 2 PFACTs (0=left, 1=Crout, 2=Right) 16 2 # of recursive stopping criterium 17 2 4 NBMINs (>= 1) 18 1 # of panels in recursion 19 2 NDIVs 20 3 # of recursive panel fact. 21 0 1 2 RFACTs (0=left, 1=Crout, 2=Right) 22 1 # of broadcast 23 0 BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM) 24 1 # of lookahead depth 25 0 DEPTHs (>=0) 26 2 SWAP (0=bin-exch,1=long,2=mix) 27 64 swapping threshold 28 0 L1 in (0=transposed,1=no-transposed) form 29 0 U in (0=transposed,1=no-transposed) form 30 1 Equilibration (0=no,1=yes) 31 8 memory alignment in double (> 0) ✝ ✆ Listing A.1 – Fichier de configuration pour le logiciel linpack 171172Annexe B Code utilisé pour la réalisation des tests de performances ✞ ☎ 1 #include 2 #include 3 #include 4 #include 5 #include 6 7 int main(){ 8 struct timespec t1,t2; 9 FILE * file =NULL; 10 char buffer[42]; 11 char fichier[102]; 12 13 while(1) 14 { 15 bzero(buffer, sizeof(buffer)); 16 bzero(fichier, sizeof(fichier)); 17 srand(time(NULL)); 18 19 clock_gettime(CLOCK_MONOTONIC, &t1); 20 21 file = fopen("/dev/urandom", "rb+"); 22 if(file ==NULL) exit(-1); 23 24 fread(buffer, sizeof(buffer),1,file); 25 fclose(file); 26 27 strcat(fichier,"/local/test/"); 28 sprintf(fichier,"%s%i", fichier,rand()); 29 sprintf(fichier,"%s%li", fichier,t1.tv_nsec); 30 sprintf(fichier,"%s%i", fichier,rand()); 31 32 file =NULL; 33 file =fopen(fichier, "wb+"); 34 if(file == NULL) exit(-6); 35 36 fwrite(buffer, sizeof(buffer), 1, file); 37 fclose(file); 38 39 clock_gettime(CLOCK_MONOTONIC, &t2); 40 printf("time : %li.%li\n", t1.tv_sec, t1.tv_nsec); 41 printf("time : %li.%li\n", t2.tv_sec, t2.tv_nsec); 42 } 43 return 1; 44 } ✝ ✆ Listing B.1 – Code utilisé pour les tests de performances 173174Annexe C Les techniques de détournements Il existe plusieurs techniques pour détourner les appels système sur les systèmes Windows. Ces techniques sont dangereuses car elle peuvent endommager le système en générant des BSOD (Blue Screen of Death), c’est-à-dire que le noyau crashe, et ainsi rendre le système complètement instable ce qui rend ces techniques illégitimes. Il existe cependant des techniques de détournement légitimes, c’est-à-dire qu’elles sont nativement intégrées au système. Nous détaillerons dans cette partie trois techniques spécifiques. Nous avons choisi ces techniques car ce sont les plus connues et les plus utilisées à ce jour. Ces trois techniques sont des techniques destinées à être utilisées en espace noyau. Il existe d’autres techniques en espace utilisateur, mais leur efficacité ainsi que leur portée sur le système n’est pas la même. C.1 Détournement de la table des appels système La première technique est le détournement de la table des appels système. Cette méthode est apparue sur les systèmes Windows avec les premiers rootkits nommés rustock 1 . Avantages et portée Cette première technique est plutôt simple à mettre en place avec une grande portée puisque toutes les applications utilisent la table des appels système pour réaliser une action sur le système. Elle gère les accès au système de fichiers, les accès au registre, les actions entre les processus comme la création de pipe nommé mais aussi les accès réseau. L’un des principaux avantages de cette technique est qu’elle est maintenant assez documentée. On peut par exemple retrouver les explications techniques pour la mettre en œuvre dans le livre [Hoglund et Butler, 2005]. De plus, lorsqu’elle est correctement mise en place, elle peut permettre l’empilement des logiciels de sécurité, c’est-à-dire que plusieurs driver peuvent détourner les mêmes appels système sans pour autant nuire à la sécurité du système ou à sa stabilité. Le second avantage de cette méthode est la possibilité de réaliser des contrôles en post-traitement mais aussi en prétraitement. En effet, lorsqu’une fonction est détournée de la table des appels système, elle est exécutée directement par le driver si l’exécution est autorisée. Mais dans ce cas, c’est aussi le driver qui récupère le retour de la fonction. Il peut ainsi réaliser un nouveau contrôle. Cette méthode de détournement des appels système permet de contrôler toutes les actions sur le système réalisées par des applications mais pas les driver qui résident en espace noyau et qui n’utilisent pas cette table pour réaliser des actions sur le système. 1. rustock : https://www.securelist.com/en/analysis/204792011/Rustock_and_All_ That 175C.2. INLINE HOOK Limites et légitimité Cette technique modifie la mémoire du noyau, c’est-à-dire que les modifications ne sont pas pérennes et ne résistent pas à un redémarrage. Il est donc nécessaire de recommencer l’opération de détournement à chaque démarrage du système. Cette technique a été énormément utilisée par les logiciels de sécurité comme les antivirus ou les pare-feux sur les systèmes Windows XP. Même si cette technique a été utilisée par les éditeurs de logiciels de sécurité, elle n’est pas recommandée par Microsoft. En effet, une mauvaise gestion des détournements entraîne la génération de BSOD. De plus, pour contrôler toutes les actions sur le système, il est nécessaire de détourner un par un tous les appels système, opération qui peut se révéler très longue. Par exemple, sur un Windows 7, on trouve plus de 400 appels système alors qu’il n’y en a que 200 sur Windows XP. Cela nous amène à une première limite de cette technique : la portabilité entre les différentes versions de Windows. A chaque nouvelle version de Windows, la table des appels système est modifiée, il faut donc refaire le détournement pour chaque nouveau Windows. De plus, le traitement de chaque fonction peut être différent entre les versions de Windows puisque les paramètres des fonctions ne sont pas toujours les mêmes. Certains logiciels de sécurité détournent certains appels système dans le but de protéger leur application. Ce détournement a pour but de contrôler la terminaison des processus et ainsi protéger leurs processus et autres services d’un kill provenant d’un processus non autorisé à le faire. Il existe néanmoins des techniques contournant les protections 2 mises en place au niveau de la table des appels système. Il devient ainsi possible de tuer les processus protégés par ces détournements. Enfin, depuis Windows Vista en version 64 bits et sur les versions supérieures de Windows, la table des appels système est protégée par le mécanisme appelé Kernel Patch Protection 3 . Cette protection empêche tout driver de modifier cette table. Donc la technique de détournement de la table des appels système n’est pas portable sur les systèmes Windows 64 bits supérieurs à Windows Vista. Il faut noter que certaines personnes ont pu réaliser ces modifications mais en désactivant le Kernel Patch Protection, ce qui revient à désactiver un mécanisme de sécurité essentiel aux nouvelles versions de Windows. Pour que le contrôle réalisé par l’observateur soit efficace, il est nécessaire de contrôler le chargement de tous les driver, puisqu’un driver pourrait supprimer ces détournements, et de vérifier constamment que : — la table des appels système possède toujours les modifications faites par le driver; — qu’aucun driver malveillant ne soit chargé. C.2 Inline Hook Le seconde technique pour détourner les appels système est appelée inline hook. A la diffé- rence de la modification de la table des appels système qui n’est réalisable qu’en espace noyau, l’inline hook est une technique qui s’applique à n’importe quelle fonction et peut être réalisée en espace utilisateur tout comme en espace noyau. Avantages et portée Grâce à l’utilisation des frameworks, Microsoft Research ou easyhook, le travail de détournement est grandement facilité et la portabilité entre les différentes versions de Windows est assurée. Depuis les systèmes Windows XP, le junk code des fonctions de l’API Win32 a été normalisé par Microsoft. Ainsi, il n’est plus nécessaire de "rechercher" l’emplacement libre en début de fonction pour placer le saut inconditionnel. 2. http://www.kernelmode.info/forum/viewtopic.php?f=11&t=1878 3. http://blogs.msdn.com/b/windowsvistasecurity/archive/2006/08/11/695993. aspx 176C.3. FILTER-DRIVER En modifiant toutes les fonctions du noyau, il est possible de contrôler toute l’activité du système, même des driver qui résident en espace noyau, à condition qu’ils utilisent les fonctions du noyau. Limites et légitimité Le fait d’introduire un junk code en début de fonction est une réalisation de Microsoft pour justement permettre le hot-patching. On peut donc considérer que ces techniques sont autorisées par Microsoft, qui fournit à la fois l’espace nécessaire pour placer un saut inconditionnel mais aussi un framework facilitant le déploiement de cette technique. Pour pouvoir modifier les fonctions du noyau, il est nécessaire de désactiver Kernel Patch Protection car il vérifie aussi l’intégrité des fonctions. En désactivant ce mécanisme de sécurité, la signature des driver qui sont chargés ne sera plus vérifiée, ce qui peut conduire au chargement de driver malveillant. De plus, on se retrouve avec les mêmes inconvénients qu’avec la technique modifiant la table des appels système. Il faut en effet modifier chaque fonction pour contrôler de manière globale le système. Cette méthode ne se limitant pas qu’aux appels système cette technique devient extrêmement contraignante à mettre en place. Enfin, la modification des fonctions implique de connaître parfaitement leur fonctionnement. Or, certaines fonctions ne sont pas documentées et peuvent être modifiées par Microsoft, que ce soit dans leur prototypage ou dans leur fonctionnement. C.3 Filter-driver La troisième technique que nous décrivons se base sur les filter-driver. Elle se base sur une architecture spécifique mise en place par Microsoft pour réaliser des contrôles sur les entrées/sorties au niveau du système de fichiers. Avantages et portée Les filter-driver reposent sur un système entièrement normalisé et documenté par Microsoft. En plus de fonctionner sur toutes les architectures classiques, Microsoft s’engage à assurer la portabilité des fonctions de l’API qu’il propose. Ainsi, un filter-driver fonctionnant sur Windows XP fonctionne aussi sur Windows 7 ainsi que sur les différentes architectures 32 et 64 bits. Un filter-driver ne gère que les accès au système de fichiers, mais grâce à l’utilisation des IRP, qui regroupent des classes d’action, il est possible de contrôler non seulement les applications mais aussi les autres driver qui réalisent des opérations sur le système de fichiers. Il est ainsi possible de contrôler l’ensemble du système sans pour autant devoir modifier toutes les fonctions. Limites et légitimité Comme c’est un mécanisme entièrement documenté et décrit par Microsoft, c’est le système qu’il faut utiliser pour détourner le flux d’exécution du système. Comme les appels système sont contenus dans les IRP, on ne détourne plus directement les appels système, mais une classe d’appel système. Comme nous l’avons expliqué, le modèle des filter-driver repose sur des couches de driver. Ils sont représentés comme un empilement de driver. Cela signifie que potentiellement, le driver précédent dans l’opération, que ce soit en prétraitement ou en post-traitement, peut modifier les informations de l’IRP sans que le filter-driver ne puisse le savoir. Il faut donc contrôler les driver autorisés à se charger dans la couche de driver. 177Damien GROS Protection obligatoire répartie La thèse porte sur deux enjeux importants de sécurité. Le premier concerne l’amélioration de la sécurité des systèmes Linux présents dans le calcul intensif et le second la protection des postes de travail Windows. Elle propose une méthode commune pour l’observation des appels système et la répartition d’observateurs afin de renforcer la sécurité et mesurer les performances obtenues. Elle vise des observateurs du type moniteur de référence afin de garantir de la confidentialité et de l’intégrité. Une solution utilisant une méthode de calcul intensif est mise en œuvre pour réduire les surcoûts de communication entre les deux moniteurs de référence SELinux et PIGA. L’évaluation des performances montre les surcoûts engendrés par les moniteurs répartis et analyse la faisabilité pour les différents noeuds d’environnements de calcul intensif. Concernant la sécurité des postes de travail, un moniteur de référence est proposé pour Windows. Il repose sur les meilleures protections obligatoires issues des systèmes Linux et simplifie l’administration. Nous présentons une utilisation de ce nouveau moniteur pour analyser le fonctionnement de logiciels malveillants. L’analyse permet une protection avancée qui contrôle l’ensemble du scénario d’attaque de façon optimiste. Ainsi, la sécurité est renforcée sans nuire aux activités légitimes. Mots clés : sécurité, contrôle d’accès obligatoire, systèmes d’exploitation, logiciels malveillants, poste de travail, calcul intensif Distributed mandatory protection This thesis deals with two major issues in the computer security field. The first is enhancing the security of Linux systems for scientific computation, the second is the protection of Windows workstations. In order to strengthen the security and measure the performances, we offer a common method for the distributed observation of system calls. It relies on reference monitors to ensure confidentiality and integrity. Our solution uses specific high performance computing technologies to lower the communication latencies between the SELinux and PIGA monitors. Benchmarks study the integration of these distributed monitors in the scientific computation. Regarding workstation security, we propose a new reference monitor implementing state of the art protection models from Linux and simplifying administration. We present how to use our monitor to analyze the behavior of malware. This analysis enables an advanced protection to prevent attack scenarii in an optimistic manner. Thus, security is enforced while allowing legitimate activities. Keywords : security, mandatory access control, operating systems, malware, workstation, high performance computing Laboratoire d’Informatique Fondamentale d’Orléans Bâtiment IIIA Rue Léonard de Vinci B.P. 6759 F-45067 ORLEANS Cedex 2 CEA/DAM/DIF Bruyères-le-Châtel 91297 Arpajon Cedex M´ethodes et structures non locales pour la restauration d’images et de surfaces 3D Guillemot Thierry To cite this version: Guillemot Thierry. M´ethodes et structures non locales pour la restauration d’images et de surfaces 3D. Signal and Image Processing. Telecom ParisTech, 2014. French. HAL Id: tel-01022843 https://tel.archives-ouvertes.fr/tel-01022843 Submitted on 16 Jul 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.T H È S E EDITE - ED130 2014-ENST-0006 Doctorat ParisTech T H È S E pour obtenir le grade de docteur délivré par Télécom ParisTech Spécialité : Signal et Images Présentée et soutenue publiquement par Thierry GUILLEMOT le 3 Février 2014 Méthodes et structures non locales pour la restauration d’images et de surfaces 3D Jury : Mme. Julie DELON, Professeur, Université Paris Descartes Présidente M. Pierre ALLIEZ, Directeur de recherche, Inria Sophia-Antipolis Rapporteur M. Jean-Michel MOREL, Professeur, CMLA, Ecole Normale Supérieure de Cachan Rapporteur M. Cyril CRASSIN, Chercheur, Nvidia Examinateur Mme Pooran MEMARI, Chargé de Recherche, CNRS-LTCI, Télécom ParisTech Examinatrice M. Andrés ALMANSA, Chargé de Recherche, CNRS-LTCI, Télécom ParisTech Directeur M. Tamy BOUBEKEUR, Professeur, CNRS-LTCI, Télécom ParisTech Directeur TELECOM ParisTech École de l’Institut Mines-Télécom - Membre de ParisTech 46 rue Barrault 75013 Paris - (+33) 1 45 81 77 77 - www.telecom-paristech.frRemerciements Tout d’abord, je tiens à remercier mes directeurs de thèse Andrès Almansa et Tamy Boubekeur pour leurs qualités pédagogique, scientifique mais surtout humaine. Grâce à eux, j’ai pu découvrir le monde de la recherche, apprendre beaucoup sur le traitement des images et des données 3D. Leur soutien, gentillesse et optimisme m’ont permis de travailler dans un cadre idéal pour réaliser ce doctorat. Je remercie les membres du Jury, Pierre Alliez, Jean-Michel Morel, Cyril Crassin, Julie Delon et Pooran Memari d’avoir accepté d’évaluer mon travail ainsi que pour leurs remarques et conseils. Mais que serait une thèse sans les soutiens de ces collègues devenus des amis au fils des années ? Je pense ici aux amis du bureau C07 (ou "Bureau Link") : Baptiste et Cécilia soutiens infaillibles depuis les premiers jours de stage, Alasdair pour sa touche anglaise et son optimisme, Yann pour la sagesse de l’ancien et son goût de la bonne bière et Guillaume pour sa gloutonnerie et ces blagues qui ne font rire que lui (et Alasdair). Je pense également aux autres collègues de TSI, les sages Noura et Jean-Marc pour leurs innombrables conseils et soirées improvisées, Charline, Emilie et Loredana pour leur inflexible bonne humeur, Guillaume pour ses remotivations ludiques, Edoardo pour son amour de la cuisine, David pour son amour de la bière, Joseph pour sa passion des débats, Julien pour son accent américain, Pooran pour sa gentillesse, ainsi que tous les autres Malik, Hélène, Stéphane, Flora, Sonia, Flora, Beibei, Leila, Mathias et Bert pour leurs discussions et conseils. Je souhaite également remercier les anciens collègues pour m’avoir acceuilli dans les premiers jours de thèse : Charles, Vincent et plus particulièrement Benoit pour son humour, sa passion du monde ludique, son immense culture... et ses talents d’improvisation. Je voudrais aussi remercier Andrés, Tamy, Isabelle, Yann, Julie, Florence et Michel pour m’avoir donné l’envie de faire une thèse quand j’étais étudiant et pour leur accueil au laboratoire TSI. Avant de terminer, je voudrais exprimer ma gratitude à tous mes amis. Les plus Vieux : Ludovic, Tom, Fabien, Sandrine et Mylène, les plus Récents : Cédric, Marine, Sophie et Valérie, les plus Toulousains : Delphine et Manu, les plus Anglais : Terry, Cécile et Laurie, les plus Théatreux : Marie, Cyril, Anne, Benoit, Florian, Bianka, Emmanuelle, Alban et Sophie et les plus Télécommiens : Alexis, Romane, Rémi, Chloé, Laure et Morgane qui ont toujours été là pour moi, même dans les moments les plus difficiles. Je voudrais terminer ces remerciements en exprimant ma gratitude à mes proches : mon père, ma mère et mes deux soeurs Karine et Coralie qui m’ont toujours encouragé, aidé et soutenu pendant toutes ces années. A vous tous, sans qui rien de tout cela n’aurait été possible, merci ! Je dédie cette thèse à mes neuveux et nièces à qui je souhaite d’avoir autant de soutien, d’aide et d’encouragement que ce que j’ai pu avoir jusqu’à présent pour réussir ce qu’ils entreprendront. iTable des matières Table des matières iii 1 Introduction 1 1.1 Contextes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Du Local au Non Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 Méthodes de restauration locales . . . . . . . . . . . . . . . . . . . . 3 1.2.2 Méthodes de restauration non locales . . . . . . . . . . . . . . . . . . 4 1.3 Problématiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Organisation de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.6 Prix et Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 Tour d’horizon des méthodes de restauration non locales 7 2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Filtres à moyennes non locales . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 Formulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2 Limitations et améliorations des NL-Means . . . . . . . . . . . . . . 12 2.3 Filtres 3D non locaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.1 Filtres surfaciques non locaux . . . . . . . . . . . . . . . . . . . . . . 15 2.3.2 Filtres non locaux de nuage de points . . . . . . . . . . . . . . . . . 15 2.3.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Filtres collaboratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.2 Méthodes de restauration collaboratives . . . . . . . . . . . . . . . . 18 2.4.3 Généralisation des filtres collaboratifs . . . . . . . . . . . . . . . . . 19 3 Surface de points non locale 21 3.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.1 Acquisition 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.2 Travaux existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.3 Généralisation des PSS . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2 Surfaces de points non locales . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.1 Principe général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.2 Carte de déplacement . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.3 Fonction de pondération . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.4 Opérateur de projection non local . . . . . . . . . . . . . . . . . . . 29 3.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.1 Détails d’implémentation et performance . . . . . . . . . . . . . . . 30 3.3.2 Analyse des paramètres . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.3 Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 iiiiv 3.3.4 Analyse de la qualité de la surface . . . . . . . . . . . . . . . . . . . 42 3.3.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.4 Limitation et possibles améliorations . . . . . . . . . . . . . . . . . . . . . . 47 4 Arbre de covariances 51 4.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.1.1 Filtrage à hautes dimensions . . . . . . . . . . . . . . . . . . . . . . 51 4.1.2 Travaux existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2 Arbre de Covariance Simplifié . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2.2 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.2.3 Apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.2.4 Requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.3 Généralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.2 CovTree généralisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.3.3 Algorithme généralisé . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.4 Analyse et temps de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.4.1 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.5 Limitations et possibles améliorations . . . . . . . . . . . . . . . . . . . . . 72 5 Filtrage collaboratif généralisé 75 5.1 Débruitage d’images par filtre collaboratif . . . . . . . . . . . . . . . . . . . 75 5.1.1 Non Local Bayes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.1.2 Débruitage d’images par CovTree . . . . . . . . . . . . . . . . . . . . 78 5.1.3 Analyse des paramètres . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.1.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2 Restauration par dictionnaires . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.2.1 Principe général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.2.2 Débruitage d’images . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.2.3 Reconstruction d’image échantillonnée aléatoirement . . . . . . . . . 92 5.2.4 Limitations et possibles améliorations . . . . . . . . . . . . . . . . . 93 5.3 Restauration de surface 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.3.1 Positionnement du problème . . . . . . . . . . . . . . . . . . . . . . 94 5.3.2 Surface de points par NLB . . . . . . . . . . . . . . . . . . . . . . . 95 5.3.3 Restauration de surface par dictionnaire . . . . . . . . . . . . . . . . 96 6 Conclusion 99 7 Perspectives 101 Bibliographie 103C h a p i t r e 1 Introduction 1.1 Contextes Les technologies à base de semi-conducteurs ont évolué de façon significative au début des années 90 et ont permis l’arrivée de nouveaux systèmes d’acquisition numérique. Cependant, leur qualité de capture était à l’origine trop limitée par rapport aux systèmes analogiques. L’augmentation de la résolution des capteurs est donc rapidement devenue un enjeu crucial de cette décennie. C’est à cette époque qu’apparaissent les premiers appareils photographiques entièrement numériques : les pellicules et leur développement sont respectivement remplacées par des cartes de stockages réutilisables et des impressions instantanées. Les appareils numériques réussissent ainsi à s’imposer progressivement face aux analogiques. Les précédentes avancées ont permis le développement d’autres techniques dans des domaines différents de la photographie. De nouveaux systèmes de capture ont ainsi émergés tels que les scanners 3D. Les systèmes de capture 3D classiques, estimant la profondeur par contact, sont ainsi améliorés par l’utilisation de capteurs CCD et de Laser. Ce nouveau type de scanner est particulièrement employé dans des domaines tels que la conservation du patrimoine (par ex. project Michelangelo - Figure 1.1) où il est nécessaire de numériser des objets sans qu’ils ne subissent de détériorations. Cependant la nature des données 3D diffère de celle des images 2D. Des outils spécifiques à leur traitement ont donc été introduits et définissent ainsi les toutes premières chaines d’acquisition 3D. À la fin des années 90, les capteurs numériques réussissent à atteindre des résolutions équivalentes ou supérieures à celles obtenues par des systèmes classiques. Malheureusement, l’utilisation des appareils numériques reste réservée à une élite. Ce phénomène peut être expliqué par plusieurs facteurs : un prix d’achat trop élevé, et des systèmes de capture qui ne sont généralement pas adaptés aux besoins du grand public (difficulté d’utilisation, encombrement, poids élevé, etc.). Ainsi, l’adaptation des systèmes d’acquisition numérique à ces besoins est devenu l’enjeu principal des années 2000. Cette démocratisation est particulièrement visible avec l’apparition des appareils photos compacts. L’utilisation de nouveaux algorithmes de gestion automatique des paramètres intrinsèques (focus, ouverture, balance des blancs, etc.) les rendent facile d’utilisation pour les non-connaisseurs. La photographie numérique devient donc accessible à tous à partir 12 Figure 1.1: Résultat du projet Michelangelo : Gauche : numérisation 3D sans détérioration utilisant des capteurs CCD et Laser. Droite : comparaison entre la statue réelle et le résultat 3D obtenu. Les images proviennent de [LPC+00] du début des années 2000. À partir de là, de nombreux constructeurs se sont mis à dé- velopper des appareils de plus en plus performants à des prix toujours plus bas afin de mieux satisfaire les demandes de ces nouveaux utilisateurs. Au milieu des années 2000, de nouvelles avancées technologiques permettent de produire des capteurs miniaturisés à l’extrême pour des coûts dérisoires. Désormais plus petits qu’une pièce de monnaie, ils se retrouvent rapidement intégrés aux téléphones portables et bouleversent par la même occasion les habitudes d’utilisation du grand public. La résolution et les performances de capture (zoom, iso etc.) deviennent progressivement des arguments de vente incontournables. Pendant ces années 2000, les systèmes de captures 3D ne cessent d’évoluer. De nouveaux types de capteurs font leur apparition en proposant l’exploitation de plusieurs images par stéréovision, la projection de motifs connus par lumière structurée, l’analyse du focus d’un appareil photo ou, plus récemment, les capteurs plénoptiques. Pendant cette période, l’utilisation des capteurs 3D se généralise à de nombreux domaines tels que le cinéma, les jeux vidéo, la robotique, l’automobile, etc. . Durant plusieurs années, l’utilisation de ces scanners 3D reste néanmoins réservée à un public restreint. Ce n’est qu’à partir du début des années 2010 que les capteurs 3D grand public sont démocratisés par l’industrie des jeux vidéos (par ex. Microsoft Kinect). Grâce à leur faible prix, il devient facile d’acquérir des données 3D. Cela permet d’attirer de nouveaux utilisateurs et d’élargir les types d’usage de ces données. À l’heure actuelle, la démocratisation des capteurs numériques est telle, qu’en France, des millions d’appareils photos numériques sont vendus chaque année, environ la moitié de la population possède un capteur photo sur son téléphone (smartphone) et environ un million de personnes possèdent une Kinect. Ainsi, chaque jour, une quantité astronomique de données 2D et 3D est ainsi générée à travers le monde. Avec l’essor des réseaux de communications et avec l’apparition des smartphones, une grande partie de cette information se retrouve partagée avec le reste du monde. En guise d’exemple, des dizaines de milliards de photos sont échangées chaque année sur l’un des principaux réseaux sociaux actuels (Facebook). Désormais, la majorité des systèmes d’acquisition numérique modernes sont connectés aux réseaux de communications (3G, 4G en préparation, etc.). Ils peuvent donc trans-1.2. DU LOCAL AU NON LOCAL 3 Restauration locale Restauration non locale Restauration par base de données Figure 1.2: Illustration des différentes méthodes de restauration. Nous représentons en rouge le voisinage retenu. mettre très facilement l’information acquise. Aujourd’hui, ces données partagées restent néanmoins difficilement exploitables par les machines de calculs modernes (ordinateur personnel, smartphone, etc.) dans la mesure où elles ne disposent pas d’une capacité de mémoire suffisante pour pouvoir les gérer. Ainsi, les différentes évolutions récentes laissent à penser que cette exploitation sera le nouveau challenge de ces années 2010. Cette thèse s’inscrit au cœur de cette évolution en proposant quelques éléments de réponse à l’un des enjeux technologiques des années 2010, à savoir : la capture, transmission et traitements de masses de données 2D et 3D. Après cette brève introduction sur l’historique de la capture numérique, nous introduisons les enjeux de la restauration moderne. 1.2 Du Local au Non Local Durant ces dernières années, les technologies d’acquisition numériques n’ont cessées de se perfectionner. Ces différentes évolutions ont donc permis l’apparition de capteurs miniaturisés, économes en énergie et surtout capables d’acquérir des données avec une qualité toujours plus fine. Malgré ces différentes améliorations, les capteurs restent sujet à des perturbations (tel que bruit électronique, résonance magnétique, etc.). Ces problèmes électroniques ajoutés aux contraintes d’acquisition (distorsions, effets de masquage, etc.) viennent perturber la capture entrainant l’apparition de défauts tels que du bruit, des points parasites, des trous dans les données acquises, etc. Ces imperfections sont inhérentes à toute technologie de capture et ne peuvent pas être corrigées matériellement. Elles nécessitent donc un traitement logiciel particulier. Ainsi, en même temps que l’apparition des tout premiers capteurs numériques dès le début des années 90 apparaissent les premières méthodes de restauration telles que le débruitage, la reconstruction, le suréchantillonnage, etc. 1.2.1 Méthodes de restauration locales Jusqu’au milieu des années 2000, ces approches s’appuient uniquement sur un traitement local des données (Figure 1.2). Dans le cadre du traitement des images, cette localité s’exprime de deux manières différentes :4 Durant les années 90, la puissance de calcul et la capacité de stockage en mémoire restant limitées, seul des filtres simples pouvaient être évalués. Ainsi, le support du filtre a été restreint à un support local : un pixel est filtré par rapport aux pixels appartenant à un voisinage local. C’est à cette époque que sont introduits les filtres par minimisation de la variation totale, bilatéraux, etc.. Avant le milieu des années 2000, les réseaux de communications ne permettent pas d’échanger une quantité de donnée importante. Ainsi, les approches de restauration sont réduites à l’utilisation d’une seule image : un pixel est filtré à partir de l’information contenue dans l’image à filtrer. 1.2.2 Méthodes de restauration non locales À partir du milieu des années 2000, les performances de calcul et la quantité de mémoire présentes sur les ordinateurs ont suffisamment évolué pour que les limitations locales pré- cédentes soient supprimées. Dans un premier temps, les méthodes non locales proposent d’étendre le support local du filtre de restauration à l’ensemble de l’image en faisant l’hypothèse que les données acquises sont autosimilaires (Figure 1.2). Ainsi, l’information détériorée est restaurée en utilisant des données similaires présentes en d’autres endroits de l’image. Face à leur succès en traitement des images, ces méthodes sont progressivement étendues au cas 3D où l’hypothèse d’autosimilarité peut être supposée de manière équivalente. Dans un deuxième temps, de nouvelles méthodes plus générales ont permis de combiner les idées introduites par les méthodes non locales avec la multiplication de la quantité de données (Figure 1.2). La non localité est désormais définie par rapport à une information extraite à partir de plusieurs images. 1.3 Problématiques S’il est vrai qu’il y a eu un développement récent des méthodes non locales, ces dernières ont principalement été utilisées afin de restaurer des données régulières et structurées telles que des images. À l’heure actuelle, ces méthodes restent encore peu étendues dans le cadre de données irrégulières. Dans le cas extrême des nuages de points 3D qui sont à la fois irréguliers et non structurés, il n’existait au début de cette thèse aucune méthode de restauration capable d’exploiter la redondance de l’information judicieusement afin de définir une surface 3D. Avec la démocratisation des capteurs numériques, la quantité de données transmise sur les réseaux de communication ne cesse d’augmenter. Le challenge est donc de réussir à exploiter judicieusement ces grands ensembles d’information. Néanmoins, à l’heure actuelle seules quelques grosses entreprises possèdent les infrastructures de calcul et de stockage nécessaires pour y arriver. Bien évidémment, le grand public ne peut avoir à sa disposition de telles structures. Il faut donc réussir à trouver un moyen pour que cette exploitation puisse être réalisée sur des systèmes possédant des capacités limitées (par ex. smartphones).1.4. CONTRIBUTIONS 5 Malheureusement, les données accessibles sont généralement brutes, semi-structurées ou non structurées. Il devient donc nécessaire de trouver un moyen pour les regrouper. Les évolutions récentes des filtres non locaux tendent à incorporer une problématique orientée big data en proposant des nouvelles démarches qui analysent l’information de sorte à extraire un modèle pour améliorer la restauration des données. Malheureusement, ce type de méthodes reste peu utilisable en pratique à cause du temps qu’il nécessite pour effectuer l’analyse. Il devient donc nécessaire d’introduire des nouvelles méthodes non locales qui soient à la fois flexibles pour pouvoir être utilisées sur n’importe quel type de données et génériques pour être utilisables par une large variété d’applications. 1.4 Contributions Le point de départ de cette thèse est le débruitage non local de nuages de points. Ce problème a mis en évidence le besoin de structures dédiées aux traitements non-locaux des données de dimension deux et supérieure, ainsi que la possibilité de généraliser les méthodes existantes de restauration non-locale 2D et 3D. Les principales contributions de cette thèse sont : – une définition de surface de points capable d’exploiter le caractère autosimilaire d’un nuage de points. Cette définition permet d’étendre n’importe quelle définition de surface de points locales précédente. – une structure de données flexible et générique capable d’apprendre les distributions d’un grand ensemble d’échantillons avec une capacité de mémoire limitée. Cette structure permet de définir pour tout voisinage, la gaussienne anisotrope associée aux échantillons qui sont compris dans ce voisinage. – une généralisation des méthodes de restauration par filtres collaboratifs appliquées aux données 2D et 3D qui utilisent la structure de données introduite précédemment pour apprendre un modèle statistique a priori à partir d’un grand ensemble de données. 1.5 Organisation de la thèse Dans le Chapitre 2, nous introduisons de manière générale les méthodes de restauration non locales. Au travers ce chapitre, nous présenterons les méthodes de débruitage par moyenne non locale, leurs applications aux cas 3D ainsi qu’une analyse générale des méthodes collaboratives. Le Chapitre 3 sera consacré à l’adaptation de la méthode de filtrage par moyennes non locales au cas des nuages de points. Dans le Chapitre 4, nous introduisons une nouvelle structure capable d’apprendre rapidement une grande base de données en utilisant uniquement une quantité de mémoire limitée. Cette structure sera utilisée au Chapitre 5 pour résoudre différents problèmes de restauration collaboratifs.6 Finalement, le Chapitre 6 offrira une conclusion générale des contributions de cette thèse et le Chapitre 7 une ouverture générale des travaux de recherche à venir. 1.6 Prix et Publications Covariance Tree for 2D and 3D Processing, Thierry Guillemot, Andrés Almansa et Tamy Boubekeur, Computer Vision and Pattern Recognition (CVPR), Columbus, 2014 Non Local Point Set Surface, Thierry Guillemot, Andrés Almansa et Tamy Boubekeur, 3D Imaging Modeling Processing Visualization Transmission (3DIMPVT), Zurich, 2012 Non Local Point Set Surface, Thierry Guillemot, Andrés Almansa et Tamy Boubekeur, Symposium on Geometry Processing (SGP), Tallinn, 2012 - Best Poster AwardC h a p i t r e 2 Tour d’horizon des méthodes de restauration non locales Dans ce chapitre, nous allons introduire un état de l’art des méthodes non locales. Nous commençons par présenter un contexte général de la restauration des images ainsi qu’un historique des méthodes de débruitage par moyenne de valeurs. Cet historique est suivi d’une analyse des méthodes non locales qui se concentrera sur l’influence des paramètres, les limitations et les évolutions des méthodes non locales. Nous présentons ensuite, une généralisation de ces méthodes au cas 3D en nous focalisant sur le débruitage surfacique et de nuage de points. Finalement, nous introduisons les filtres collaboratifs ainsi que leurs différentes applications en traitement des images. Durant ce chapitre, nous introduisons les notions indispensables qui seront utilisées durant l’ensemble de cette thèse. Nous précisons au lecteur que des analyses de l’état de l’art plus spécifiques aux travaux développés durant cette thèse seront présentées en début des Chapitres 3, 4 et 5. 2.1 Contexte Quel que soit le système d’acquisition et la précision de ce dernier, les signaux modernes restent altérés lors de leur capture. Ces dégradations, généralement dues aux contraintes matérielles (optique, capteur CCD, etc.), algorithmiques (compression JPEG, etc.) ou transmissives (satellitaires, internet, etc.), doivent être traitées afin de récupérer au mieux l’information originalle contenue dans ces signaux. Dans cette partie, nous considérerons des images discrètes dont chaque élément (pixel) est associé à une couleur (Rouge, Vert, Bleu - RGB). Plusieurs hypothèses sont généralement faites afin de modéliser les dégradations subies par l’image. En particulier, nous supposerons que nous avons accès à une observation dégradée de l’image qui associe à chaque pixel xi une couleur f(xi) obtenue à partir de la couleur réelle u(xi) en ajoutant un bruit n(xi) gaussien i.i.d. (indépendant et identiquement distribué) de variance σ connue : fi = f(xi) = u(xi) + n(xi) (2.1) Ce modèle est utilisé de manière standard dans la communauté du traitement des images, car il est à la fois simple et efficace pour modéliser le bruit dû à l’acquisition de l’image. 78Zone homogène Contour Zone texturée Images bruitées Poids gaussien Poids bilatéral Poids non local Figure 2.1: Nous illustrons la définition des poids gaussien, bilatéral et non local pour trois différentes zones de l’image : une zone homogène, un contour, une zone texturée. Pour tout ces exemples, les poids sont calculés en fonction du pixel central de chaque image. Les poids élevés sont représentés en blanc tandis que les poids faibles sont représentés en noir. D’autres modèles, par exemple les modèles poissoniens, ne seront pas abordés dans cette thèse (voir [Bov05] pour plus de détails). Le principe des méthodes de débruitages consiste à éliminer le bruit ajouté lors de l’acquisition afin d’estimer une couleur ˆu(xi) proche de la couleur originale u(xi). Pour résoudre ce problème, des nombreux travaux ont été introduits proposant une minimisation de la variation totale [ROF92], l’application de filtres de Wiener empiriques [YY85], une décomposition de l’image en ondelettes [Don95], l’utilisation de voisinages de taille variable [PS00,KEA02,KFEA04,FKEA04], ou plus récemment une analyse de l’a priori des textures de l’image par dictionnaire [DFKE09,ZDZS10,YSM10], etc.. Parmi toutes ces méthodes, un grand nombre de filtres peuvent s’exprimer comme une moyenne sur les pixels de l’image. En considérant un sous-ensemble de pixels N(xi) proches du pixel d’intérêt xi , la forme générale de ces filtres peut être exprimée comme une combinaison des couleurs fj pondérées par les poids wij : uˆ(xi) = X xj∈N(xi) wij fj (2.2)2.1. CONTEXTE 9 Images bruitées Filtrage gaussien Filtrage bilatéral Filtrage non local Figure 2.2: Résultat des différents filtrages gaussien, bilatéral et non local appliqués sur l’image barbara bruitée avec un bruit gaussien de variance 0.08. Les poids wij sont normalisés : P xj∈N(xi) wij = 1, et leur définition permet de définir les caractéristiques du filtre souhaité. Ce dernier peut dépendre de la position spatiale xi , de la couleur des pixels fi , ou de toute autre caractéristique de l’image. En particulier, l’Équation 2.2 peut être utilisée pour exprimer la convolution par un noyau gaussien φ d’écart type hp. Dans ce cas, les poids wij sont fonction de l’éloignement spatial entre les pixels de l’image xj et le pixel d’intérêt xi : wij ∝ φ(kxi − xjk 2 /h2 p ) (2.3) Une analyse du filtre gaussien [BCM05] démontre que l’écart entre l’image originale et l’image filtrée est directement proportionnel au laplacien de l’image. Il en résulte que le filtre gaussien permet de récupérer correctement les valeurs des zones homogènes de l’image, mais floute les bords et les zones texturées (Figure 2.1 et 2.2). Par conséquent, à cause de ces faibles performances, ce filtre est assez peu utilisé par les systèmes de débruitage modernes.10 La simplicité de la formulation du filtre gaussien restant très attrayante, de nombreux travaux ont proposé d’améliorer ses performances afin d’obtenir un débruitage des images plus efficace. En proposant une approche similaire aux travaux de Lee [Lee83] et de Yaroslavsky [YY85], Tomasi introduit le filtre bilatéral [TM98] en définissant un poids dépendant à la fois de la distance spatiale entre les pixels et de la distance entre leurs couleurs associées (distance colorimétrique). D’une manière totalement équivalente, le filtre bilatéral peut être vu comme un filtre gaussien défini dans un espace augmenté qui mélange les positions des pixels xi et leurs valeurs associées fi . Les poids du filtre sont calculés en combinant deux noyaux φ, ψ définis respectivement dans les domaines spatial (différence des positions des pixels) et colorimétrique (différences des couleurs des pixels) : wij ∝ φ(kxi − xjk 2 /h2 p )ψ(kfi − fjk 2 /h2 f ) (2.4) Ces noyaux, généralement gaussiens, sont dépendants de deux paramètres hp et hc utilisés pour limiter la taille du voisinage spatial et colorimétrique. Désormais seuls les pixels qui possèdent à la fois des positions et des couleurs proches du point d’intérêt ont un poids élevé. Par exemple, les pixels proches d’un contour appartenant à une zone différente de celle du pixel d’intérêt possèdent dans ce cas un poids négligeable. Le filtre bilatéral permet de débruiter correctement les zones homogènes tout en préservant les bords de l’image. Néanmoins, l’utilisation d’une unique valeur pour estimer un voisinage colorimétrique reste trop sensible au bruit de l’image (Figure 2.1 et 2.2). Les zones texturées de l’image restent donc difficilement récupérables par une telle approche. Face au succès des méthodes de synthèse de texture [EL99] et d’inpainting [CPT03,CPT04] utilisant la notion de patch (correspondant à une imagette de l’image considérée), Buades et coll. [BCM05] (et en même temps [AW05,KB06,AW06]) introduisent le filtre à moyennes non local (Non Local Means - NL-Means). Ce dernier étend l’idée du filtre bilatéral d’utiliser la couleur des pixels pour raffiner l’estimation du voisinage en la remplaçant par un patch (ou imagette) décrivant l’information contenue autour du pixel. Ce patch PW f,xi ∈ R dP de dimension dP = (2W + 1)2 est défini comme l’ensemble des valeurs de f comprises dans une fenêtre carrée de taille W centrée sur le pixel considéré xi . Les poids non locaux wij sont donc définis par l’intermédiaire d’un noyau de pondération φ dépendant de la distance entre patchs : wij ∝ φ(kP W f,xi − P W f,xj k 2 /h2 ) ∝ φ( X dP k=1 kfi+k − fj+kk 2 /h2 ) (2.5) Le paramètre h permet de définir le nombre de voisins utilisés pour le débruitage. Désormais le poids dépend uniquement de la similarité entre les patchs et non de l’éloignement spatial entre les pixels (d’où son caractère non local). Il est intéressant de noter qu’une version dégénérée des NL-Means, où la taille du patch est réduite à un unique pixel, nous permet d’obtenir une forme équivalente au filtre bilatéral. Tout comme ce dernier, le filtre NL-Means peut être exprimé de manière équivalente comme un filtre gaussien appliqué dans l’espace des patchs. Par l’utilisation d’un ensemble de couleurs {fi+k}k∈[[1,dP]], les poids définis par les NL-Means sont moins dépendants du bruit et permettent d’obtenir un débruitage de l’image satisfaisant dans les zones homogènes, les contours et les zones texturées de l’image (Figure 2.1 et 2.2). Cette propriété est due au fait que les images naturelles présentent une auto similarité affine locale [Ale05]. De par leur formulation simple et leur capacité de débruitage, les NL-Means sont devenus durant ces dernières années l’un des filtres les plus utilisés pour le débruitage d’images.2.2. FILTRES À MOYENNES NON LOCALES 11 2.2 Filtres à moyennes non locales Dans cette partie, nous effectuons une étude plus approfondie des NL-Means. Nous nous intéresserons en particulier à l’analyse de ses différents paramètres, évolutions et limitations. Lebrun et. coll. [LCBM12] fait une analyse en profondeur des propriétés mathématiques de ces filtres et ses généralisations en traitement d’images. 2.2.1 Formulations Nous rappelons ici la définition des NL-Means telle qu’elle a été introduite par Buades et coll. [BCM05] : uˆi = X xj∈N(xi) φ(kP W f,xi − P W f,xj k 2 /h2 )fj (2.6) où N(xi) est un ensemble de pixels voisins de xi , φ un noyau de pondération, W la taille des patchs PW f,xi centrés sur xi et h le facteur d’autosimilarité. Tous ces paramètres sont directement liés à la qualité de la restauration. De nombreux travaux ont proposé une analyse détaillée de leur influence respective. Noyau de pondération Le noyau de pondération φ permet de définir le poids de chaque échantillon en fonction de la similarité de leurs voisinages. La pondération est normalisée de sorte que : X xj∈N(xi) φ(kP W f,xi − P W f,xj k 2 /h2 ) = 1 (2.7) Les travaux originels des NL-Means [BCM05, AW05, KB06, AW06] utilisent un noyau de pondération gaussien. Chaque pixel de la somme possède un poids non nul qui influence l’estimateur final. L’accumulation des poids des pixels les plus éloignés peut par conséquent biaiser le débruitage. Par conséquent, n’importe quel point, même le plus éloigné, influence l’estimateur non local. Pour résoudre ce problème, de nombreux travaux [GLPP08,DAG10, Sal10a] arrivent à la conclusion qu’il est préférable d’utiliser un noyau à support compact qui permet d’annuler l’influence des échantillons trop différents. Dans l’Équation 2.6, le patch PW f,xi possède le double rôle de patch de référence (utilisé pour définir la similarité entre deux patchs) et de patch estimateur (combiné pour définir la moyenne). Ce pixel particulier possédera donc un poids plus important que les autres pixels de l’image biaisant par la même occasion l’estimateur non local. Pour résoudre ce problème, Buades et coll. [BCM05] suggèrent de le remplacer par le poids maximal des autres pixels utilisés dans la somme. Cette solution n’est pas vérifiée théoriquement, mais permet d’obtenir de bons résultats pratiques. Zimmer et coll. [ZDW08] proposent d’annuler l’influence de ce patch particulier. Néanmoins, une telle solution ne permet pas de concilier le double rôle du patch central. Salmon [Sal10b] résout ce problème en supprimant la variance du bruit dans la distance euclidienne utilisée pour comparer les patchs. Ainsi, tout patch qui possède une distance inférieure à la variance du bruit possède un poids égal à 1.12 Facteur d’autosimilarité Le facteur d’autosimilarité h définit le degré de similarité des échantillons. Il est choisi de manière globale et peut être assimilé à la quantité de flou des méthodes locales. Le choix d’une valeur globale pour ce facteur reste dfficile à choisir, en effet certaines textures de l’image sont plus redondantes que d’autres. Ce paramètre est donc généralement estimé par une analyse heuristique sur un ensemble représentatif d’images. Des estimations de h basées sur l’estimateur SURE (Stein’s Unbiased Risk Estimate) sont néanmoins calculées globalement par Van et coll. [VDVK09] et localement par Duval et coll. [DAG10]. Taille des patchs La taille des patchs W correspond au niveau de détail à utiliser pour définir la similarité entre deux patchs. Augmenter l’échelle W permet de définir une mesure de similarité plus robuste et moins dépendante du bruit. Malheureusement, cela limite le nombre de patchs similaires utilisés pour le débruitage et augmente le temps de calcul des NL-Means. Par conséquent, la taille W doit être idéalement choisie en fonction de la quantité de bruit et de l’image à traiter. Généralement, elle est déterminée par une analyse statistique effectuée sur une base d’images représentatives. Zones de recherche Initialement, le voisinage N(xi) a été introduit comme un moyen d’accélérer l’estimation des NL-Means [BCM05]. En effet, le temps de calcul est directement proportionnel au nombre d’échantillons utilisé par l’Équation 2.6. Nous pourrions penser qu’augmenter la taille du voisinage améliorerait la qualité de restauration. En effet, nous obtiendrions dans ce cas un nombre de patchs similaires plus élevé. Malheureusement, nous augmenterions par la même occasion le nombre de mauvais candidats susceptibles de parasiter le résultat final. Pour résoudre ce problème, Kervrann et coll. [KB06] proposent de définir un voisinage adaptatif permettant de récupérer un plus grand nombre de patchs similaires sans introduire un trop grand nombre de mauvais représentants. 2.2.2 Limitations et améliorations des NL-Means Les NL-Means sous leur forme originale présentent des limitations. De nombreux travaux ont été proposés pour enrichir le modèle de départ afin de corriger ces problèmes tout en améliorant les performances qualitatives et temporelles de la restauration. L’un des problèmes principaux des NL-Means vient de la redondance des patchs. En effet, nous avons supposé que le patch était suffisamment bien représenté pour pouvoir être débruité correctement. Malheureusement, il arrive que certains pixels de l’image soient moins bien représentés que d’autres. Une première catégorie de méthodes propose entre autres d’augmenter le nombre de patchs similaires en utilisant le caractère autosimilaire local des images naturelles [Ale05]. Plusieurs approches [ZDW08, JCSX09] utilisent une analyse des moments robuste aux bruits afin de rendre les patchs invariants par rotation.2.2. FILTRES À MOYENNES NON LOCALES 13 D’autres travaux [BCM05] suggèrent l’utilisation d’espace échelle afin de simuler l’invariance par changement d’échelles. Dans ce cas, les patchs calculés sur les différentes images sous-échantillonnées sont ajoutés à l’ensemble des patchs utilisé classiquement. La mesure de similarité est faite sur un ensemble de patchs bruités. Idéalement, cette dernière devrait être effectuée sur des patchs non bruités. Ces données étant inaccessibles, Buades et coll. [BCM05] ont proposé l’utilisation de la distance euclidienne, car elle permet d’être peu dépendant du bruit de l’image. D’autres méthodes [BC07,BKC08] proposent de calculer la similarité sur les patchs débruités de manière itérative. Ces NL-Means itératifs débruitent l’image en utilisant une mesure de similarité calculée sur des patchs extraits de l’image qui a été débruitée à l’itération précédente. En d’autres termes, ce type d’approches permet un regroupement des patchs en fonction de la ressemblance du voisinage débruité à l’itération précédente. À l’origine, les patchs utilisés sont centrés sur le pixel d’intérêt xi . Dans le cas d’un patch contenant un contour de l’image, la mesure de similarité risque d’être biaisée et donc de favoriser un côté du contour par rapport à l’autre. Ce phénomène d’adhérence introduit des poids parasites dans la combinaison finale des pixels. Il en résulte une apparition de halos autour des bords de l’image. D’autres méthodes [DFKE07, DFKE08, DFKE09, LBM13] proposent d’utiliser des patchs carrés décentrés pour corriger ces halos en reformulant l’Équation 2.6 d’une manière équivalente par : Pˆ W f,xi = X xj∈N(pi) φ(kP W f,xi − P W f,xj k 2 /h2 )P W f,xj (2.8) L’estimation finale est définie en effectuant des moyennes sur les estimateurs [SS12]. Ce type de solutions permet d’étendre l’agrégation d’estimateurs [Nem00] au cas des patchs. Parmi ces méthodes, Deledalle, Salmon et Duval [DDS12] proposent en particulier l’utilisation d’un estimateur SURE (Estimateur de risque sans biais de Stein - Stein’s Unbiased Risk Estimate) couplée à l’utilisation de patchs de différentes formes (non carrés). Cette idée (utilisée de manière similaire par Baraniuk et coll. [MNB12]) permet de tirer parti de la géométrie locale de l’image tout en étant peu victime du phénomène d’adhérence. Salmon [Sal10a] propose une étude plus détaillée concernant l’agrégation d’estimateurs dans le cas des NL-Means. En plus de ces facteurs limitant la qualité de restauration de l’image, l’un des problèmes majeurs des NL-Means reste son temps de calcul. De nombreuses approches ont été proposées afin d’accélérer l’estimation. Certaines proposent une estimation approchée des plus proches patchs [BSFG09,OA12,KA11,Tas09,HS12], une approximation de l’image filtrée par regroupement de patchs similaires [AGDL09,ABD10,HST10,GO12], etc. Une analyse plus détaillée de ce point de l’état de l’art sera proposée en Section 4.1.1. La simplicité et les performances des NL-Means ont favorisé la généralisation des filtres non locaux à de nombreux domaines connexes tels que l’imagerie satellitaire [DDT09], la vidéo [BCM08,AGDL09], l’imagerie médicale [MCCL+08], etc. Nous focaliserons la suite de notre analyse sur le traitement 3D.14 Figure 2.3: Nous présentons plusieurs exemples de surface numérisée à partir d’objet réels d’origine humaine. Tous ces objets peuvent être considérés comme autosimilaires du fait qu’ils présentent un ensemble de structures redondantes. Une telle hypothèse peut être faite pour la plupart des objets d’orgines humaine ou naturelle. 2.3 Filtres 3D non locaux Une chaîne d’acquisition 3D permet d’obtenir une surface maillée à partir d’un objet réel. Cette dernière peut être résumée par deux principales étapes : l’étape d’acquisition et l’étape de reconstruction. Tout d’abord, l’étape d’acquisition définit à partir de l’objet réel un nuage de points 3D. Pour ce faire, cette étape utilise généralement des capteurs automatiques (par ex. systèmes d’acquisitions Kinect), des appareils photo et/ou camé- ras vidéo couplés à des méthodes de stéréovision [BBH08,BBB+10,BHB+11], etc. Lors de cette étape, le nuage de points obtenu peut être dégradé par du bruit, des trous, des points aberrants et/ou des taux d’échantillonnages variables. Ensuite, l’étape de reconstruction permet de définir une surface maillée à partir du nuage de points acquis. Plusieurs mé- thodes peuvent être utilisées telles que les Marching Cubes [LC87], la reconstruction de Poisson [KBH06], etc. Si elles ne sont pas traitées correctement, les dégradations introduites lors de l’étape d’acquisition parasitent la reconstruction de la surface maillée. Durant ces dernières années, les méthodes de débruitage ont donc été particulièrement utilisées afin de corriger les erreurs apportées par la chaîne d’acquisition. Nous pouvons diviser ces méthodes en deux principales catégories. La première catégorie, que nous appellerons filtres de nuages de points est appliquée sur le nuage de points 3D obtenu en amont de l’étape de reconstruction. Ces filtres permettent d’obtenir une surface maillée résultante de meilleure qualité. La deuxième, appelée filtre surfacique, est appliquée sur la surface maillée obtenue en aval de l’étape de reconstruction. Ces filtres sont utilisés dans le cas où l’utilisateur ne peut pas avoir accès à la chaîne d’acquisition. La plupart de ces méthodes ont été inspirées des avancées en traitement des images [FDCO03, JDD03,VB11]. Des hypothèses similaires à celles utilisées pour les images peuvent en effet être faites concernant les données 3D. En particulier, ces dernières sont considérées de nature autosimilaire, car elles sont généralement issues d’objets réels d’origines naturelles ou humaines et possèdent de nombreuses primitives et structures redondantes (Figure 2.3). Les méthodes non locales ont donc logiquement été adaptées afin d’améliorer la qualité de la restauration 3D. Pour ce faire, ces dernières nécessitent la définition d’un signal à débruiter et d’une mesure de similarité adaptée aux données 3D considérées. Contrai-2.3. FILTRES 3D NON LOCAUX 15 rement aux images qui possèdent un échantillonnage régulier et une définition de signal bruité évidente, les données 3D ne possèdent pas de support pouvant être utilisé pour les deux définitions précédentes. Plusieurs solutions ont donc été introduites dans le cas des surfaces et des nuages de points pour définir des notions équivalentes. 2.3.1 Filtres surfaciques non locaux Yoshizawa et coll. [YBS06] étendent les NL-Means aux filtrages surfaciques comme un moyen de supprimer les dégradations tout en préservant les structures principales de la surface maillée. Ils proposent une approche itérative basée sur [FDCO03] qui déplace les points du maillage xi dans la direction de la normale n(xi). Ce déplacement est calculé comme une combinaison des valeurs < xi − xj , n(xi) > des points xj ∈ N (xi) compris dans un voisinage de xi pondérées par rapport à la similarité des surfaces locales autour de xi et de xj . Dans ce cas, l’utilisation de Radial Basis Functions (RBF) permet de définir une interpolation de la surface ainsi qu’un repère de comparaison normalisé. Wang et coll. [WCZ+08] proposent une démarche similaire à [YBS06] en remplaçant la mesure de similarité sur les RBF par une mesure plus proche des NL-Means classiques qui utilisent des patchs. Ainsi, ils introduisent un repère normalisé local défini par le plan tangent à la surface au point du maillage xi orienté par rapport à l’analyse en composantes principales des points compris dans le voisinage de xi . Dans ce repère, ils définissent des patchs de la variation géométrique locale de la surface. Ils utilisent une grille régulière centrée sur xi dont les valeurs sont calculées en interpolant la hauteur des points du maillage du voisinage. Pour accélérer le temps de calcul et obtenir de meilleurs résultats, ils proposent d’effectuer un regroupement des points du maillage par Meanshift [CM02]. Adams et coll. [AGDL09] introduisent leur propre filtre surfacique non local comme une application de sa structure d’accélération de filtres à hautes dimensions. Ils proposent d’utiliser une surface de référence. Cette dernière, calculée par application itérative du filtre laplacien sur le maillage, permet d’associer à chaque point du maillage une valeur bruitée (correspondant à l’écart entre la surface bruitée et la surface de référence). Dans leur approche la similarité est calculée en utilisant des histogrammes 2D représentant la répartition locale des points bruités du maillage appartenant aux différentes zones d’un descripteur cylindrique. Morigi et coll. [MRS12] proposent un filtre surfacique différent capable de préserver les structures principales du maillage par un débruitage non local de la courbure moyenne. Dans ce cas la mesure de similarité de la géométrie locale est définie par rapport à un descripteur basé sur la courbure moyenne locale. 2.3.2 Filtres non locaux de nuage de points Malgré les bonnes performances des filtres surfaciques non locaux, il reste difficile de corriger les dégradations de l’acquisition après reconstruction de la surface maillée. En effet, une partie de l’information contenue dans le nuage de point 3D est perdue à ce moment de la chaîne d’acquisition. Par conséquent, il semble plus judicieux de filtrer le nuage de points 3D avant de reconstruire une surface. Contrairement aux surfaces maillées,16 les nuages de points 3D ne possèdent aucune information de structure. Cette dernière est malheureusement indispensable pour définir un signal à débruiter et une mesure de similarité appropriée indispensables à toute restauration non locale. Pour résoudre ce problème, Deschaud et coll. [DG10] suggèrent l’utilisation de méthodes de projection par moindres carrés glissants (Moving Least Square - MLS) [Lev98,ABCO+01] qui définissent localement une surface à partir d’un nuage de points. Leur approche peut être résumée par trois principales étapes. Tout d’abord, ils définissent pour chaque point du nuage un système de coordonnées local défini à partir des vecteurs associés aux deux plus grands vecteurs propres de la covariance des points. Ensuite, les variations de la surface autour du point d’intérêt sont approchées localement par un polynôme bivarié exprimé dans ce repère. Finalement, la position débruitée est estimée comme une combinaison des points proches pondérée par la similarité de leur polynôme bivarié. Cette démarche appliquée à chaque point du nuage permet d’obtenir le nuage débruité. Malheureusement, comme le démontre [Dig12], la paramétrisation du repère local n’est pas suffisamment stable. Digne [Dig12] propose de décomposer le nuage de points en une surface grossière et un champ scalaire bruité en utilisant un filtre isotropique [DMSL11]. Elle propose ensuite de filtrer le champ scalaire par NL-Means. Pour ce faire, elle utilise un patch qui décrit les variations locales de la surface définie dans un repère local. La paramétrisation du repère local est calculée à partir d’une analyse en composantes principales des normales du nuage plus robuste aux variations de la surface [DM11]. Les valeurs du patch sont calculées par une interpolation sur une grille des hauteurs des points voisins par RBF. Plus récemment, une méthode de débruitage de nuage de point par analyse spectrale collaborative de patchs a été introduite [RDK13]. Ces patchs utilisent un opérateur de Laplace-Beltrami afin débruiter le nuage d’une manière robuste. 2.3.3 Limitations Les méthodes non locales ont été introduites pour améliorer la correction des dégradations introduites lors de l’étape d’acquisition. Ces approches ont été définies pour être utilisées sur deux types de données : la surface maillée, corrigeant ainsi les erreurs introduites par l’utilisation d’un nuage de points dégradé lors de l’étape de reconstruction ; le nuage de points, avant que la surface ne soit définie. En utilisant la méthode de débruitage surfacique, il devient difficile de récupérer l’information dégradée, car une partie a été perdue lors de la phase de reconstruction. Par conséquent, il est préférable d’utiliser les méthodes de débruitage de nuages de points. Néanmoins, dans ce cas, la reconstruction ne permet pas d’exploiter correctement l’ensemble de l’information présente dans le nuage de points. En particulier, la propriété autosimilaire du nuage n’est pas exploitée par la reconstruction de la surface. Nous introduisons au Chapitre 3 un nouvel opérateur capable de définir une surface implicite qui exploite correctement le caractère autosimilaire du nuage de points. Nous utilisons ce dernier pour définir des surfaces maillées, le débruitage de nuage de points et l’intensi- fication des structures de l’objet.2.4. FILTRES COLLABORATIFS 17 Approche des NL-Means Approches collaboratives Figure 2.4: Principe des filtres collaboratifs : Nous considérons ici un ensemble d’individus possédant chacun une caractéristique bruitée (cercle interne à chaque individu). Pour les NL-Means, un individu ( cercle rouge) utilise les caractéristiques que lui transmettent les individus voisins (cercle discontinu) pour restaurer la valeur de sa propre caractéristique. Une telle approche peut utiliser des individus qui ne font pas nécessairement partie de la même famille que l’individu considéré. Dans le cas des filtres collaboratifs, les individus sont regroupés en familles (cercles en pointillé). L’information sur les caractéristiques des individus d’une même famille est mise en commun (cercle bleu au centre de chaque famille), analysée puis retransmise à l’ensemble des individus de la famille. Dans ce cas, toutes les valeurs des individus d’une même famille sont restaurées en même temps en utilisant une information partagée par la famille uniquement. 2.4 Filtres collaboratifs Les récents travaux sur les filtres non locaux ont permis une généralisation des NL-Means à des domaines d’applications différents de ceux de la restauration d’images et une évolution de ces principes originaux pour une meilleure exploitation de la redondance de l’information. De plus en plus, ces évolutions ont rapproché la restauration non locale d’un autre genre de filtrage : le filtrage collaboratif. 2.4.1 Principe Le filtrage collaboratif est un procédé de filtrage de l’information utilisant des techniques qui impliquent une collaboration entre de multiples agents, points de vue, sources de données, etc. À l’origine, ces derniers ont été particulièrement utilisés dans le domaine de l’e-commerce comme un système de recommandation automatique à partir d’une connaissance de l’intérêt d’un grand nombre d’utilisateurs. De manière générale, ces méthodes consistent à prédire une information inconnue d’un individu (débruitage, complétion, etc.) par une analyse détaillée d’un groupe de personnes qui possède des caractéristiques communes à l’individu considéré. Ce genre d’idées diffèrent d’approches plus simples qui four-18 nissent un score moyen non spécifique exprimant l’intérêt d’un ensemble d’utilisateurs (basé par exemple sur le nombre de votes). Ce principe de filtrage a été généralisé au traitement des images par [DFKE07]. L’idée principale dans ce cas consiste à rassembler les patchs similaires par famille puis de les débruiter en utilisant l’information commune de la famille à laquelle ils appartiennent. Pour bien comprendre la différence entre NL-Means et les méthodes collaboratives, considérons un ensemble d’individus chacun associé à une caractéristique bruitée. Pour les deux types de méthodes, le but est de débruiter chaque caractéristique à l’aide d’autres individus (Figure 2.4). Dans le cas des NL-Means, elle est débruitée en combinant les caractéristiques des individus proches. L’individu en question ne retransmet aucune information qu’il a pu récupérer de ses voisins. Pour les filtres collaboratifs, les individus sont d’abord regroupés par familles d’individus proches. Ensuite, les individus d’une même famille se mettent d’accord mutuellement sur les valeurs débruitées de leurs caractéristiques respectives. En opposition aux filtres collaboratifs classiques, la collaboration en traitement d’image vient d’une analyse commune du groupe de patch qui est ensuite utilisée pour améliorer la qualité de la restauration. Ce type de filtre permet de révéler les détails partagés par l’ensemble du groupe tout en conservant les caractéristiques uniques de chaque patch. Le patch obtenu est donc plus proche de la position originale qu’en le débruitant par NL-Means. 2.4.2 Méthodes de restauration collaboratives Dabov et coll. [DFKE07,DFKE08,DFKE09] sont les premiers à introduire le filtrage collaboratif pour la restauration des images. Leur méthode, appelée BM3D (Block Matching and 3D Filtering), se base sur trois principales étapes. Tout d’abord ils empilent les patchs en les regroupant en fonction de leurs similarités de sorte à former des piles de patchs. Ensuite, cette pile 3D est débruitée en gardant les fréquences principales d’une transformée (ondelettes, transformées en cosinus discret) appliquées sur la pile. Un filtrage appliqué sur cette troisième dimension permet de garder les caractéristiques communes de la famille tandis que le filtrage des deux autres dimensions permet de garder les caractéristiques spécifiques à chaque patch. Ainsi, la collaboration vient du fait que les patchs d’une même famille sont débruités conjointement en considérant l’analyse globale de la pile. Finalement, les patchs débruités sont agrégés de sorte à définir les valeurs débruitées de l’image. Ces trois étapes sont itérées deux fois afin d’améliorer la qualité finale du débruitage. BM3D constitue l’une des méthodes applicatives les plus performantes actuellement pour le débruitage d’images. Néanmoins, l’influence de ces nombreux paramètres reste difficile à analyser. Yu et coll. [YSM12] proposent d’étendre le principe des filtrages collaboratifs à d’autres problèmes inverses tels que le débruitage, l’amélioration de la résolution ou d’inpainting en introduisant l’estimateur linéaire par morceaux (Piecewise Linear Estimator - PLE). Leur idée basée sur les travaux sur les structures parcimonieuses [MBP+09] approxime l’ensemble des patchs par un modèle de mélange de gaussiennes (Gaussian Mixture Model - GMM). Les gaussiennes sont ajustées à l’ensemble des patchs inconnus à restaurer via une Maximisation A Posteriori (MAP) qui utilise un algorithme d’espérance-maximisation (Expectation Maximisation - EM) itératif. Pour cette méthode il est difficile de trouver le bon nombre de classes des GMM ainsi qu’une bonne initialisation afin que la procédure2.4. FILTRES COLLABORATIFS 19 EM converge vers un bon minimum de la fonction objectif non convexe. En pratique, le nombre de gaussiennes est fixé à l’avance à environ une dizaine afin de garder la complexité du calcul sous contrôle. Quand l’ensemble des patchs est corrompu par un bruit gaussien de variance σ 2 , l’Équation 2.6 des NL-Means peut être reformulée comme une Espérance A Posteriori (EAP) bayésienne. Lebrun et coll. [LBM13] reformule les NL-Means pour définir les Non Local Bayes (NLB) en remplaçant la formulation EAP des NL-Means par une Maximisation A Posteriori (MAP). Désormais en plus de la moyenne non locale, chaque patch est associé à une matrice de covariance Σ décrivant la variabilité au sein du groupe de patchs. La covariance étant bruitée, le côté collaboratif de ce filtre vient du fait que tous les patchs sont débruités conjointement par l’opération de filtrage de la covariance Σ˜ = Σ−σ 2 Id. En utilisant une approche similaire aux BM3D, le patch est débruité en deux étapes : la première étape débruite à partir de variations estimées sur les patchs bruités et la deuxième à partir des patchs débruités à la première étape. Tout comme BM3D, une phase d’agré- gation permet de définir un meilleur débruitage des pixels de l’image. Nous proposons en Section 5.1.1 plus de détails concernant les NLB. Les NLB permettent actuellement d’obtenir les meilleures performances de débruitage. Néanmoins, leur approche nécessite une grande quantité de calcul dans la mesure où un modèle gaussien local a besoin d’être appris deux fois autour de chaque patch. Pour être calculable, l’estimation du voisinage est approchée par une recherche des k plus proches voisins dans l’espace des patchs. 2.4.3 Généralisation des filtres collaboratifs Durant ces dernières années, la formulation collaborative des méthodes de débruitage a permis d’améliorer significativement la qualité de la restauration d’images bruitées. Le principe introduit par BM3D [DFKE07, DFKE08, DFKE09] a ensuite été amélioré par NLB [LBM13] en remplaçant la formulation EAP des NL-Means par une formulation MAP qui permet de mieux récupérer les structures communes d’un groupe de patchs similaires tout en préservant ses caractéristiques spécifiques. Néanmoins, de telles approches nécessitent une grande quantité de calculs et sont généralement simplifiées pour pouvoir être calculables. De plus, PLE [YSM12] a proposé une généralisation des filtres collaboratifs à d’autres applications du traitement des images. Cette solution offre d’excellentes performances, mais utilise une GMM simplifiée pour pouvoir obtenir de bons résultats dans un temps raisonnable. Par conséquent, une telle approche semble difficilement applicable sur de grands ensembles de données. Nous introduisons au Chapitre 4 une nouvelle structure de données capable d’apprendre les variations d’un grand ensemble de points avec une quantité de mémoire limitée. Elle représente les variations des données apprises en n’importe quelles positions et échelles de l’espace des patchs par une gaussienne anisotropique. Une telle structure est définie comme une approche hybride entre PLE et NLB. Nous utilisesons cette structure au Chapitre 5 pour reformuler des problèmes de restauration 2D et 3D d’un point de vue d’une MAP collaborative. En outre, nous apprendrons20 les variations de grandes bases de données avec une quantité de mémoire limitée afin de mieux restaurer des données dégradées.C h a p i t r e 3 Surface de points non locale Dans ce chapitre, nous proposons de définir la première surface qui exploite l’autosimilarité présente dans un nuage de points (Non Local Point Set Surfaces — NLPSS). Nous commencerons par décrire dans la Section 3.1 une généralisation des méthodes de surface de points. En Section 3.2, nous introduisons notre opérateur de projection non local ainsi que l’ensemble des outils nécessaires à sa définition. Nous montrerons en Section 3.3 que notre approche permet de retrouver les caractéristiques importantes de l’objet tout en comblant l’information manquante par une augmentation locale du ratio signal sur bruit. Finalement en Section 3.4, nous proposons différentes améliorations possibles pour notre opérateur non local. 3.1 Contexte 3.1.1 Acquisition 3D Avec la démocratisation des appareils d’acquisition 3D, il est devenu aujourd’hui facile de numériser des objets réels avec une haute précision. Généralement sous la forme de nuages de points bruts corrompus par du bruit, des points aberrants, des trous et/ou des taux d’échantillonnages variables, ces acquisitions doivent être traitées pour définir des surfaces maillées exploitables. Les méthodes basées points ont donc été introduites comme un moyen d’améliorer la qualité des données acquises sans pour autant faire de choix concernant la nature de la surface sous-jacente. Les surfaces de nuages de points (Point Set Surfaces — PSS) ont été définies en ce sens, et permettent de faire le lien entre les nuages de points et les surfaces maillées. Elles introduisent une représentation surfacique lisse non maillée essentiellement définie par l’ensemble des points fixes d’un opérateur de projection. 3.1.2 Travaux existants Alexa [ABCO+01] introduit initialement les PSS en se basant sur les travaux de Levin [Lev98,Lev03] qui étend une classe de méthodes d’approximation fonctionnelles de don- 2122 nées parcimonieuses — les moindres carrés glissants (Moving Least Squares - MLS) [She68] — au cas d’approximation de formes. Cette première version des PSS est définie par l’intermédiaire d’un opérateur de projection itératif. À chaque étape, un point d’évaluation est projeté sur une surface localement définie par un polynôme bivarié paramétré sur un plan qui approxime les données. Ces deux derniers sont estimés localement par une minimisation non linéaire du carré de la distance des données aux points d’évaluation. Amanta et coll. [AK04] démontre qu’il est possible de définir une surface d’aussi bonne qualité en effectuant une moyenne pondérée des positions, sans utiliser de polynôme bivarié ou de minimisation non linéaire. Ils introduisent une fonction de distance signée permettant une représentation implicite de la surface. Cette représentation peut être utilisée par différents algorithmes de remaillage comme les Marching Cubes [LC87] ou une triangulation de Delaunay restreinte [BO05] pour définir une surface polygonale. Adamson et coll. [AA04a] exploitent cette idée pour introduire un modèle simple de surface de nuages de points (Simple Point Set Surfaces — SPSS). Dans le cas de nuages de points munis de normales, le plan local de projection peut être estimé par une combinaison linéaire pondérée des positions et des normales. Si le nuage de point ne comporte pas de normales, une analyse en composantes principales [HDD+94] permet d’équiper chaque point du nuage avec une normale estimée. Avec les SPSS, Adamson [AA04b] introduit trois procédures différentes pour estimer itérativement la projection d’un point sur la surface : l’orthogonale qui projette le point d’évaluation précisément au terme de calculs sophistiqués, la basique d’une faible complexité, mais peu précise, et l’orthogonale approximative qui constitue un bon compromis entre simplicité et précision. Fleishman et coll. [FCOS05] améliorent cette définition en introduisant une formule implicite des moindres carrés glissants (Implicit Moving Least Squares - IMLS) qui préserve les bords anguleux de la surface. Alexa et Adamson [AA09] proposent une surface de point hermitienne (Hermite Point Set Surfaces — HPSS) qui limite les effets de réduction des méthodes précédentes. Au lieu de projeter le point sur un seul plan, il est projeté sur l’ensemble des plans définis par chaque échantillon voisin. Ensuite la position est calculée par une combinaison pondérée de ces différentes projections permettant de définir une combinaison hermitienne. La procédure d’estimation du plan peut devenir rapidement instable quand le nuage de points n’est pas assez dense par rapport à la taille du support de l’opérateur ou quand les taux d’échantillonnage du nuage de points sont trop variables. Guennebaud et coll. [GG07] proposent de remplacer le plan par une sphère algébrique définissant une nouvelle surface de points algébrique (Algébraic Point Set Surfaces — APSS). Ce modèle est ensuite amélioré en contraignant les gradients de la sphère algébrique à correspondre aux normales des échantillons [GGG08]. Les méthodes précédentes ne sont pas adaptées pour définir une surface à partir d’un nuage de points corrompu par des points aberrants. En utilisant une méthode de régression par noyau qui ajuste itérativement les poids de chaque échantillon, Öztireli et coll. [ÖGG09] introduisent une nouvelle formule implicite et robuste des moindres carrés glissants (Robust Implicit Moving Least Square - RIMLS). En plus d’une résistance aux points aberrants, cette définition permet une meilleure préservation des caractéristiques de la surface. Nous vous renvoyons vers [CWL+08] pour un état de l’art plus complet sur les surfaces MLS.3.1. CONTEXTE 23 Figure 3.1: Gauche : Le SPSS [AA04a] définit une surface à partir d’un nuage de points X muni de normales par l’intermédiaire d’un opérateur Π qui projette pour tout x ∈ R 3 sur un plan estimé localement de normale n(x). Droite : L’opérateur de projection Π introduit une fonction implicite f(x) dont l’ensemble des valeurs nulles définissent la surface de l’opérateur (en orange). 3.1.3 Généralisation des PSS Jusqu’à la fin de ce chapitre, nous considérerons comme entrée des PSS un nuage de points X = {xi , ni} où xi ∈ R 3 correspond à la position spatiale d’un point et ni ∈ R 3 est la normale qui lui est associée. D’après la procédure de projection orthogonale approximative introduite par Adamson et Alexa [AA04b], l’ensemble des définitions PSS précédentes peuvent s’exprimer à l’aide d’un opérateur de projection Π : MLSX : R 3 → R 3 , x → Π(x) (3.1) Chaque point d’évaluation x est projeté sur une primitive Q localement estimée par moindres carrés (e. g. plan pour le SPSS, sphère algébrique pour l’APSS) : Π(x) = x − f(x)n(x) (3.2) Cette formulation permet de mettre en évidence la distance implicite f(x) entre x et sa projection sur Q et n(x) la normale PSS définie en cet emplacement. Q est paramétrée sur X par rapport à x à une échelle t liée à la taille du support choisie pour le noyau de pondération spatial sous-jacent. Par exemple dans le cas des SPSS (Figure 3.1), cette définition générale peut être exprimée par : n(x) = P xi∈X wt(x, xi)ni k P xi∈X wt(x, xi)nik c(x) = P xi∈X wt(x, xi)xi P xi∈X wt(x, xi) f(x) =< x − c(x), n(x) >24 Figure 3.2: Gauche : les opérateurs PSS conventionnels définissent la surface en considé- rant un voisinage local. Face aux conditions réelles de capture, ce point de vue purement local devient insuffisant pour définir une surface correcte. Droite : le principe de notre algorithme est d’exploiter le caractère autosimilaire des nuages de points pour augmenter localement le ratio signal sur bruit et ainsi proposer une définition de surface plus adaptée aux conditions de capture. Le noyau de pondération spatial wt(x, xi) est généralement défini à partir d’une fonction à support compact polynomiale par morceaux g : wt(x, xi) = 1 Zt(x) g( 1 t kx − xik) Zt(x) est choisie de manière à assurer la somme unitaire des poids P xi∈X wt(x, xi) = 1. Le paramètre t associé à wt correspond au paramètre de filtrage de la surface : plus t est grand, plus la surface résultante est lisse. Faire varier t permet de décomposer le PSS à différentes échelles. Au cours de ce chapitre, nous appellerons respectivement Πt (x), f t (x) et n t (x) l’opérateur de projection, la distance implicite et la normale définie par l’opérateur PSS à cette échelle t. 3.1.4 Problématique Dans tous les modèles PSS, le choix de la taille du support du noyau spatial induit la qualité de la surface résultante : une taille élevée lissera la surface en éliminant les défauts introduits lors de l’acquisition, et à l’opposé une taille fine fera ressortir les détails importants de l’objet sans débruiter la surface. Malheureusement, il est difficile de trouver une taille de support idéale pour satisfaire le compromis lissage/préservation des caractéristiques de l’objet car le problème est restreint à un point de vue strictement local. Pour résoudre ce problème de manière adéquate, nous proposons de ne plus nous limiter à un point de vue strictement local, mais d’utiliser l’information apportée par l’ensemble du nuage lors de la projection d’un point d’évaluation. Comme le montre la Figure 3.2, une telle approche permet d’augmenter le ratio information/bruit et ainsi de résoudre les ambiguïtés dues aux défauts du nuage de points. Ainsi, nous proposons de définir une surface de points non locale (Non Local Points Set Surfaces — NLPSS) qui possède les avantages suivants :3.2. SURFACES DE POINTS NON LOCALES 25 1. Définition d’une surface non locale : Notre définition n’est pas restreinte au débruitage de nuages de points dans le sens où nous proposons un nouvel opérateur PSS exploitant l’autosimilarité du nuage et qui peut être utilisé pour de la reconstruction, du débruitage et d’autres traitements plus génériques sur un ensemble non organisé du nuage de points. 2. Généralisation : Nous proposons une extension de toutes les méthodes PSS précé- dentes en leur incorporant une propriété non locale. 3. Dégénérescence : Notre définition dégénère en la définition traditionnelle du PSS sur lequel il se base dans le cas de faible autosimilarité. 3.2 Surfaces de points non locales Dans cette partie nous allons définir notre opérateur non local de surface de points. Pour pouvoir introduire cette définition, nous introduirons trois notions : 1. Signal : De par la nature non structurée des nuages de points, il n’est pas possible de définir un signal en considérant directement leur positions spatiales des points du nuage. Nous introduirons un signal adapté qui contient les défauts du nuage sur lequel nous appliquerons les méthodes non locales. 2. Descripteur local : La comparaison de deux sous-ensembles d’un nuage de points doit être peu sensible à la nature des nuages de points et aux défauts introduits lors de l’acquisition. Nous définirons un descripteur local adapté au nuage de points défini dans un repère local normalisé. 3. Fonction de pondération : Nous proposerons une fonction de pondération tenant compte de la quantité d’information non locale qui est présente. 3.2.1 Principe général En considérant une échelle t0 suffisamment large, le PSS peut être décomposé en une surface grossière St0 et un champ scalaire de déplacement résiduel m(xi)n t0 (xi) qui contient les caractéristiques du nuage de points contaminées par le bruit. L’idée principale de notre approche est d’utiliser les méthodes non locales pour supprimer le bruit du champ scalaire résiduel, et, simultanément, calculer la projection (interpolation) à une échelle fine pour tous les points d’évaluation x ∈ R 3 . Nous appliquons tout d’abord un opérateur de projection PSS local Πt0 à une échelle large t0 pour définir une surface grossière St0 . Nous ajoutons ensuite à St0 un champ scalaire de déplacement fin mNL(x)n t0 (x) défini par une approximation non locale de la distance résiduelle m(x) entre la surface grossière et la reconstruction de X . Les différentes étapes de notre approche sont présentées figure 3.3. Nous introduisons donc la première définition de surface de points non locale (Non Local Point Set Surfaces — NLPSS) par l’opérateur de projection : ΠNL(x) = Πt0 (x) − mNL(x)n t0 (x) (3.3) Nous présentons Figure 3.4 notre schéma de projection non local.26 + Estimation non locale PSS à échelle grossière Figure 3.3: Nous utilisons un opérateur PSS grossier sur notre nuage de points d’entrée X pour décomposer le signal en une surface grossière St0 (en vert) et un champ scalaire de déplacement résiduel m. Ce dernier étant éventuellement bruité et défini seulement aux points du nuage de points original, nous approximons ces valeurs en tout point de la surface grossière mNL par une méthode non locale qui améliore la qualité de l’approximation en exploitant le caractère autosimilaire du nuage. Notre surface non locale SNL est par conséquent définie en ajoutant à la surface grossière le champ scalaire de déplacement approximé. 3.2.2 Carte de déplacement Le champ scalaire de déplacement m(x) est défini par la distance résiduelle entre la surface grossière St0 et X . Pour tout x = xi ∈ X : m(xi) = D xi − Π t0 (xi), n t0 (xi) E = f t0 (xi) (3.4) Malheureusement, la nature parcimonieuse du nuage de points et les défauts introduits par l’acquisition 3D font que le champ de déplacement est défini seulement pour les points du nuage xi ∈ X et peut être bruité. Dans le but de débruiter ces valeurs et d’étendre sa définition pour tous les points x ∈ R 3 , nous considérons une moyenne pondérée non locale des m(xi) : mNL(x) = X xi∈X wNL(x, xi)m(xi) (3.5) Ainsi nous allons devoir introduire une mesure de similarité wNL entre les voisinages locaux des deux points x et xi . Pour cela, nous introduirons un descripteur 3D défini par l’intermédiaire de repères locaux pour faciliter leur comparaison. 3.2.3 Fonction de pondération Dans cette partie nous allons introduire une mesure de similarité entre deux sous-ensembles du nuage de points. Par conséquent nous allons introduire un patch qui décrit localement3.2. SURFACES DE POINTS NON LOCALES 27 Figure 3.4: Notre définition permet de projeter tout point x ∈ R 3 par l’intermédiaire de l’opérateur ΠNL. x est projeté dans un premier temps sur la surface grossière (représentée en vert) en Πt0 (x). La projection ΠNL(x) sur la surface NLPSS (représentée en rouge) est définie en ajoutant la valeur du champ scalaire de déplacement débruité mNL dans la direction de la normale grossière n t0 (x). le champ scalaire de déplacement dans un repère normalisé tangent à la surface grossière St0 . Descripteur 3D Figure 3.5: Gauche : Nous définissons la mesure de similarité entre deux sous-ensembles du nuage de points par l’intermédiaire d’un patch de taille l = 5δ (où δ correspond à l’écart moyen entre les points) avec n = 2 centré en Πt0 (x). L’ensemble des points qui composent le patch sont disposés sur le plan tangent à la surface St0 définie par la normale nt0 (x). Droite : Les valeurs du patch sont calculées en utilisant la surface St1 (en bleu). Les valeurs colorées du patch représentent les différences locales entre St0 (en vert) et St1 .28 La définition de notre patch est présentée figure 3.5. Pout tout point x ∈ R 3 , notre patch local de déplacement est défini par un ensemble de dimension (2n + 1) × (2n + 1) points D = [[−n, n]]2 ⊂ Z 2 . Ces points sont localisés dans un carré de taille l × l défini par l’intermédiaire d’un systeme de coordonnées local centré en xt0 = Πt0 (x) dont deux axes définissent le plan tangent à la surface grossière en xt0 . Pour (i, j) ∈ D, chaque point xi,j du patch a une valeur Pxt0 (i, j) correspondant à la valeur de déplacement m(xi,j ). Comme nous l’avons expliqué section 3.2.2, les valeurs de la carte de déplacement ne sont connues que pour les points du nuage x = xi ∈ X . Par conséquent, nous approximons les valeurs de m(xi,j ) en utilisant un PSS local pour définir une surface St1 à une échelle fine t1 ≪ t0. Ici, St1 représente une surface peu débruitée et interpolée de X . Les valeurs Pxt0 correspondent donc à la projection des points du patch sur la surface fine St1 : Pxt0 (i, j) = f t1 (xi,j ) ∀(i, j) ∈ D. (3.6) Pour que la distance entre les points xi,j et St0 soit négligeable par rapport à Pxt0 , nous choisissons la taille du patch l ≈ t0 3 . Orientation du repère Pour comparer les descripteurs locaux d’une manière similaire, nous introduisons un repère orthonormé local (u, v, n t0 ). Pour bien définir le patch de distance, les deux axes u, v appartiennent au plan tangent à la surface grossière St0 au point xt0 . Par conséquent notre patch est défini à une orientation près. Pour que cette dernière reste robuste au bruit et au taux d’échantillonnage, nous la choisissons en fonction des directions principales de courbures de la surface. Digne [Dig12,DM11] a montré qu’il était possible de les calculer par une simple analyse en composantes principales des normales. Le vecteur propre associé à la plus grande valeur propre est tangent à la direction principale. Nous estimons la moyenne nm et la matrice de covariance Σn des normales en considérant un sous-ensemble de points X˜ autour de xt0 : nm = 1 |X | ˜ X ni∈X˜ ni (3.7) Σn = 1 |X | ˜ X ni∈X˜ (ni − nm). t (ni − nm) (3.8) Le vecteur propre u˜ associé à la plus grande valeur propre de la matrice de covariance Σn n’appartient pas nécessairement au plan tangent à la surface St0 . Par conséquent, nous redéfinissons les directions u et v par v = n t0∧u˜ knt0∧u˜k et u = v∧n t0 kv∧nt0 k . Désormais, le repère (u, v, n t0 ) est défini à une direction près. Si nous définissons, les moments mk d’ordre k du patch par : mk = X i,j < (xi,j − xt0 ), u > k . < (xi,j − xt0 ), nt0 > mk = X i,j < (xi,j − xt0 ), u > k .Pxt0 (i, j) (3.9)3.2. SURFACES DE POINTS NON LOCALES 29 Nous utilisons le moment m1 d’ordre 1 pour lever l’ambiguïté sur la direction de u lors du calcul du patch. La direction pour le vecteur u est obtenue de telle sorte que m1 > 0. Mesure de similarité 1 0similarity Figure 3.6: Résultats de notre mesure de similarité par rapport à un point appartenant à un bord de l’objet (gauche) et à un point appartenant à un plan (droite) représenté dans chaque cas en blanc. Les couleurs représentent la similarité entre le point de référence et les autres points de l’objet, allant du rouge (très similaire) au bleu (peu similaire). Pour deux points y, z ∈ R 3 , nous définissons la distance entre leurs patchs associés par : d(y, z) = 1 2n + 1 kPyt0 − Pzt0 k2 (3.10) La mesure de similarité correspondante est définie par l’intermédiaire d’un paramètre h : wNL(y, z) = 1 ZNL(y) exp − d(y, z) 2 h 2 ! (3.11) La constante de normalisation ZNL(y) assure que P xi∈X wNL(y, xi) = 1. Le paramètre h permet d’ajuster la mesure en fonction de l’autosimilarité du nuage de points. Nous présentons figure 3.6 les résultats de notre mesure de similarité entre un point de référence et l’ensemble des points de l’objet. 3.2.4 Opérateur de projection non local Notre opérateur de projection ΠNL(x) est défini en utilisant la distance implicite fNL(x) d’un point x ∈ R 3 à la surface de points non locale : ΠNL(x) = x − fNL(x)n t0 (x) (3.12) La distance implicite non locale est définie par : fNL(x) = f t0 (x) − X xi∈X wNL(x, xi)m(xi) (3.13)30 Dégénérescence du noyau de pondération non local Pour des points x dont le facteur d’autosimilarité est faible, notre définition aura tendance à ne pas débruiter suffisamment le point résultant introduisant ainsi des artefacts dans la définition de notre surface non locale. Dans ces cas-là, l’utilisation de PSS locaux semble plus adaptée. Notre définition précédente peut être facilement modifiée pour tenir compte de cette particularité. Pour cela, nous ajoutons au noyau non local wNL un noyau spatial wt (correspondant à la définition locale des PSS). Notre nouveau noyau de pondération w˜NL permet de combiner l’information locale et non locale par l’intermédiaire d’un facteur de contrôle α : w˜NL(x, xi) = 1 Z(x) (αZt(x)wt(x, xi) + ZNL(x)wNL(x, xi)) (3.14) La constante de normalisation Z(x) est choisie pour assurer une somme unitaire. Dans cette formule, quand x fait partie d’un ensemble très représenté, le terme non local domine, permettant d’augmenter la qualité du débruitage et d’améliorer la résolution. Au contraire, si x appartient à une zone peu représentée, le terme spatial domine, assurant ainsi une meilleure completion des trous du nuage. Le paramètre α permet de choisir l’impact du noyau non local par rapport au noyau local dans la définition de la surface finale. Noyau à support compact Lors du calcul de la projection non locale, dû à l’utilisation d’un noyau gaussien, chaque point xi ∈ X possède un poids wNL non nul. Par conséquent, la somme des points de poids faibles ne peut plus être considérée comme négligeable. Ce phénomène est d’autant plus important que le paramètre h est élevé (ce qui aura pour conséquence de rendre similaires l’ensemble des patchs de l’image). En traitement des images, cette somme est généralement réduite à un sous ensemble de pixels locaux autour du point d’évaluation. Dans ce cas, l’impact des points similaires dans la somme finale est plus significatif. Malheureusement, une telle démarche peut dif- ficilement être appliquée au cas des nuages de points. En effet, il est plus intéressant de considérer le nuage de points dans sa totalité permettant, par conséquent, de débruiter les caractéristiques du nuage les plus rares. Ainsi, pour limiter l’impact des points parasites, nous remplaçons le voisinage local par l’ensemble des k patchs qui sont les plus similaires. Le poids des autres points du nuage est imposé à zéro. Cette démarche permet à la fois d’obtenir des résultats d’une meilleure qualité et une accélération du temps de calcul. 3.3 Résultats 3.3.1 Détails d’implémentation et performance Nous avons implémenté notre algorithme en C++. La recherche des k plus proches patchs telle que nous l’avons décrite section 3.2.4 est accélérée par l’utilisation d’un algorithme3.3. RÉSULTATS 31 Figure 3.7: Nuage de points original Fandisk (gauche) qui a été bruité par un bruit uniforme (droite) permettant de simuler un système d’acquisition 3D de basse qualité. de recherche approximatif des plus proches voisins : FLANN [ML12,ML09]. Pour mieux représenter les différences des résultats, nous présenterons les surfaces NLPSS maillées finement. L’entrée de notre algorithme restera malgré tout un nuage de points muni de normales et non une surface maillée. 3.3.2 Analyse des paramètres Dans cette partie nous allons présenter en détail l’influence des paramètres de notre opérateur non local. Pour permettre une meilleure analyse des résultats, nous utiliserons, jusqu’à la fin de cette section, le même objet Fandisk comme entrée des différents algorithmes. Le nuage de points original a été bruité artificiellement avec un bruit uniforme de variance égale à l’espacement moyen entre les points du nuage (Figure 3.7). Toutes les mesures d’écart des surfaces résultantes seront effectuées par rapport au maillage original. Échelle grossière L’échelle grossière t0 est utilisée pour définir la surface grossière St0 ainsi que le champ scalaire de déplacement résiduel bruité m(x). Pour que l’utilisation des méthodes non locales ait du sens, cette dernière doit définir un signal autosimilaire bruité dont les variations principales sont liées aux traits principaux de l’objet considéré. Nous présentons Figure 3.8 différents choix pour l’échelle t0 ainsi que le champ scalaire résiduel et les surfaces NLPSS associées. Le choix idéal pour l’échelle t0 (représenté en vert sur la Figure 3.8) est dépendant de la quantité de bruit appliqué à l’objet. Si nous choisisson une valeur de t0 trop faible (cas t0 = 5), la surface grossière résultante exhibera uniquement les structures de bruit locales introduisant un champ scalaire dont les variations ne sont pas liées à l’aspect de l’objet considéré. De la même manière, si t0 est trop large (cas t0 = 30) les lignes caractéristiques de l’objet seront filtrées excessivement entraînant l’apparition de variations parasites dans le champ de déplacement résiduel.32 Surface grossière Distance résiduelle bruitée Distance résiduelle débruitée NLPSS 2.5 10 -2 Déplacement: -2.5 10 0 -2 Figure 3.8: Évolution de la surface NLPSS en fonction de l’échelle grossière t0. Cette dernière permet de définir une surface dont le bruit et les caractéristiques principales ont été lissés et a fortiori une carte de déplacement résiduel contenant les variations principales de l’objet. Un choix idéal pour le paramètre t0 a été représenté en vert.3.3. RÉSULTATS 33 Surface fine Écart entre la surface grossière et fine NLPSS 1.5 10 -2 Déplacement: -1.5 10 0 -2 Figure 3.9: Évolution de la surface NLPSS en fonction de l’échelle fine t1. Cette dernière permet de définir la carte d’écart entre la surface grossière St0 et St1 utilisée par nos patchs pour définir la mesure de similarité de deux sous-ensembles du nuage de points. Un choix idéal pour le paramètre t1 a été représenté en vert. Par conséquent, la valeur t0 idéale doit être choisie de manière à définir un champ scalaire dont les variations correspondent à l’aspect de l’objet. En pratique, si la valeur de t0 est choisie entre 10 et 20 fois l’écart moyen des points du nuage. Échelle fine L’échelle fine t1 définit une surface fine St1 utilisée par notre mesure de similarité pour estimer les variations des patchs. Pour définir une surface d’une meilleure qualité, t1 doit être choisi de manière à ce que la mesure de similarité soit peu dépendante des structures34 locales de bruits. En Figure 3.9, nous présentons différents choix pour t1, la carte d’écart entre St0 et St1 ainsi que les surfaces NLPSS associées. Une fois encore, le choix idéal de l’échelle t1 (représenté en vert sur la Figure 3.9) dépend du niveau de bruit appliqué à l’objet. Elle doit être choisie suffisamment petite par rapport à t0 de manière à approcher les caractéristiques de l’objet tout en lissant les structures locales de bruit. Pour des valeurs de t1 faibles (cas t1 = 3), la mesure de similarité rassemblera des structures locales de bruits similaires exagérant ainsi les variations parasites de l’objet. Au contraire pour des valeurs de t1 élevées (cas t1 = 10), la mesure de similarité associera ensemble des traits non similaires de l’objet tendant à introduire des artefacts et à uniformiser les traits principaux de la surface NLPSS résultante. Choisir une valeur de t1 supérieure à t0, n’aurait pas de sens et résulterait d’un mauvais choix de t0. De plus, prendre t1 = t0 définirait un ensemble de patchs égaux rendant impossible toute mesure de similarité de deux sous-ensembles du nuage de points. En pratique, nous choisissons t1 ≈ 0.5t0 . Opérateur PSS local sous-jacent Notre opérateur NLPSS est défini pour étendre n’importe quel opérateur PSS local afin d’exploiter le caractère autosimilaire des nuages de points. Nous présentons en Figure 3.10 une comparaison des surfaces non locales générées en considérant différents opérateurs PSS locaux. La qualité de notre NLPSS est très dépendante du choix du PSS local sous-jacent. Ce dernier permet de définir la surface grossière et la surface fine à partir du nuage de points (Figure 3.11). Il est important de noter que les propriétés intéressantes des PSS locaux sont transmises au NLPSS. Ainsi, un opérateur qui préserve les bords d’un objet produira un NLPSS qui les préserve également (cf. NLPSS basé sur le RIMLS). Notre définition permet également de corriger les imperfections introduites par les PSS locaux. Dans le cas du SPSS et HPSS qui exagèrent les caractéristiques principales d’un objet sans filtrer les structures de bruits locales, notre NLPSS réussit à définir une surface les supprimant tout en préservant les arêtes et les coins de l’objet. Malheureusement, notre définition est très dépendante de la qualité de la surface grossière : toutes les discontinuités introduites par l’opérateur PSS local à échelle grossière seront difficilement corrigées par notre approche. De manière équivalente, un PSS local capable de définir une surface fine qui préserve les caractéristiques principales d’un objet définira une mesure de similarité plus précise. Mesure qui est utile pour définir une surface non locale de meilleure qualité. L’APSS et le RIMLS qui génèrent des surfaces grossières exemptes de défauts remarquables et des surfaces fines préservant les caractéristiques de l’objet définissent des NLPSS idéaux. En pratique, nous utilisons l’APSS comme opérateur de notre NLPSS car il donne de manière générale les meilleurs résultats.3.3. RÉSULTATS 35 Resultat Local NLPSS Erreur Local Erreur NLPSS SPSS HPSS APSS RIMLS 7.0 10 -3 0 Erreur Figure 3.10: Comparaison des surfaces NLPSS utilisant différents opérateurs PSS sousjacents et des surfaces PSS originales. Les erreurs ont été calculées par rapport au Fandisk original.36 Échelle fine Échelle grossière SPSS HPSS APSS RIMLS Figure 3.11: Surfaces fines St1 et grossières St0 utilisées par notre NLPSS pour étendre les PSS conventionnels. NLPSS Figure 3.12: Évolution de la surface NLPSS en fonction de la taille du patch l. Cette taille est utilisée pour définir la taille des détails qui doivent être pris en compte lors du débruitage par les méthodes non locales. Si cette dernière est choisie trop fine, notre approche non locale dégénère en une approche bilatérale. La définition du patch sur un plan tangent à la surface grossière St0 , implique que le paramètre l ne doit pas être choisi supérieur à l’échelle fine t1. Le choix idéal pour l a été représenté en vert. Taille du descripteur La largeur l des patchs permet de sélectionner la taille des traits de l’objet présents dans le nuage de points que notre NLPSS doit récupérer. En Figure 3.12, nous présentons différents choix pour la taille l du descripteur ainsi que les surfaces NLPSS résultantes.3.3. RÉSULTATS 37 NLPSS Temps (s) 5 10 15 Figure 3.13: Évolution de la surface NLPSS en fonction du nombre de points n par patch. Les surfaces résultantes sont peu influencées par le nombre de points compris dans chaque patch. Néanmoins, le temps de calcul pour estimer ces dernières augmente linéairement avec le nombre de points. En définitive, des patchs de taille 5 × 5 semblent être un bon compromis qualité/temps de calcul. Il est intéressant de noter que pour des valeurs faibles de l (cas l = 1), notre approche non locale dégénère en un simple opérateur de projection bilatéral [TM98, JDZ04]. La surface NLPSS résultante aura donc tendance à s’accrocher aux valeurs du champ scalaire résiduel les plus proches. Pour des valeurs de l plus élevées (cas l = 4), la mesure de similarité est peu influencée par le bruit présent dans le nuage de points résultant en une suppression des variations locales dans les zones plates. Néanmoins, à cause de l’approximation de la surface grossière par un plan tangent à la surface (cf. Section 3.2.3), l doit être choisie inférieure à t1. Pour des valeurs de l supérieures à t1 (cas l = 10) les variations décrites par les patchs ne correspondent pas aux variations réelles entre la surface grossière et la surface fine. Ainsi, la mesure de similarité est faussée ce qui entraîne l’apparition d’artefacts dans la surface NLPSS. En pratique, nous choisissons l variant entre 3 et 5 fois l’écart moyen des points du nuage. Nombre de points par patch Le nombre de points du patch n est utilisé pour décrire plus précisément les variations locales de la surface. Figure 3.13, nous présentons une analyse du temps de calcul des38 Distance résiduelle débruitée NLPSS 1.0 10 -2 Déplacement: -1.0 10 0 -2 Figure 3.14: Évolution de la surface NLPSS en fonction du degré d’autosimilarité h du nuage de points. Ce dernier permet de sélectionner le degré de débruitage des caracté- ristiques principales de l’objet. Si ce dernier est choisi trop faible, les caractéristiques de l’objet resteront bruitées. À l’opposé, pour des valeurs trop élevées ces dernières seront complètement lissées. Le choix idéal (représenté en vert) correspond au degré de filtrage de notre méthode. L’utilisateur peut interagir avec ce paramètre sans contrainte de temps de calcul. patchs en fonction de la qualité de la surface NLPSS associée à des nombres de points différents par patchs. De toute évidence, augmenter le nombre de points par patch permet de définir une mesure de similarité plus fiable en contrepartie d’un temps de calcul élevé. En pratique, l’influence du nombre de points par patchs reste négligeable. Ainsi, le choix d’un nombre points par patch faible s’impose. Dans de rares cas, le choix de patch 3 × 3 peut être insuffisant pour décrire correctement la différence entre les surfaces grossière et fine. Par conséquent, nous avons opté pour des patchs 5 × 5 ce qui constitue un bon compromis qualité/temps de calcul. Facteur d’autosimilarité du nuage Le paramètre h définit le degré de similarité présent dans le nuage de points et correspond au facteur de filtrage du nuage de points. Nous présentons Figure 3.14 différents choix pour h ainsi que le champ scalaire résiduel débruité et les surfaces NLPSS associées.3.3. RÉSULTATS 39 Pour des valeurs h ≈ 0 (cas h = 0.1), la mesure de similarité aura tendance à différencier l’ensemble des patchs ce qui s’exprimera en pratique par des poids qui tendent vers 0. Comme la somme des poids de l’équation 3.11 est assurée d’être unitaire, les points prendront la valeur m(xi) du point pi le plus similaire. Par conséquent, le champ scalaire résiduel ne sera pas débruité et la surface non locale résultante approximera le bruit contenu dans le nuage. De même, pour des valeurs trop faibles de h (cas h = 10), les lignes singulières de l’objet seront peu débruitées. À l’opposé des zones plates, ces zones sont plus rares dans l’objet entraînant un débruitage plus faible. À l’opposé, si h est choisi trop grand (cas h = 100), les poids de l’équation 3.11 seront tous égaux entraînant une uniformisation du champ scalaire de déplacement résiduel. La valeur idéale de h (représentée en vert sur la Figure 3.14) doit être choisie par l’utilisateur et correspond au facteur de filtrage de notre méthode. Une fois l’ensemble des patchs calculés et les k plus proches patchs déterminés, l’estimation d’une surface pour différentes valeurs de h n’est pas coûteuse. Ainsi, l’utilisateur peut intéragir avec le paramètre h sans contrainte sur le temps de calcul. Facteur de dégénérescence local L’utilisation du facteur α de l’équation 3.14 nous permet de choisir des valeurs h moins élevées. Ainsi, les traits peu présents dans l’objet sont mieux préservés et les artefacts introduits par les éléments les plus rares de l’objet sont lissés par l’opérateur local. En Figure 3.15, nous présentons l’évolution de la surface NLPSS pour différentes valeurs de α. Lorsque α = ∞, l’équation 3.15 dégénère simplement en une définition locale des PSS. Au contraire quand α = 0, le résultat obtenu correspond à la surface NLPSS. Les valeurs intermédiaires de α permettent d’obtenir une combinaison de ces deux surfaces. Pour des valeurs croissantes de α, les traits les moins présents dans le nuage sont les premiers à être remplacés par les valeurs des PSS locaux permettant d’améliorer la qualité de la surface NLPSS résultante. Ainsi, comme le montre la figure 3.15 pour des valeurs croissantes de α, les coins, les arêtes puis finalement les zones plates vont être remplacés par les PSS locaux. La valeur idéale dépendra de la présence de points peu autosimilaires dans le nuage. Il est intéressant de noter que changer la valeur du facteur α ne nécessite que peu de calcul supplémentaire. En effet l’équation 3.2.4 peut s’exprimer comme une combinaison linéaire des points des nuages résultants de l’opérateur PSS local et non local. Choix pratique Parmi les sept différents paramètres que possède notre NLPSS, seulement deux d’entre eux ont besoin d’être réellement choisis par l’utilisateur : le facteur d’autosimilarité h et le facteur de dégénérescence α. En pratique, pour des nuages de points issus de scanners 3D dont l’écart moyen entre les points est défini par ¯δ, les meilleurs résultats sont obtenus pour des NLPSS basés sur l’APSS dont l’échelle grossière t0 = 12¯δ, l’échelle fine t1 = 7¯δ et les patchs de taille l = 4¯δ40 NLPSS PSS local NLPSS dégénéré Figure 3.15: Évolution de la surface NLPSS en fonction du facteur α. Ce paramètre est complémentaire au paramètre h et permet de remplacer les structures peu débruitées (peu autosimilaires) par leurs versions débruitées en utilisant l’opérateur PSS sous-jacent. Pour des valeurs croissantes de α notre définition remplace en premier les structures peu autosimilaires pour finir par les caractéristiques les plus présentes dans le nuage de points. Nous pouvons par conséquent faire un compromis entre localité (pour les structures peu autosimilaires) et similarité (pour les structures très autosimilaires). Calculer les surfaces résultantes pour différentes valeurs de α est possible sans avoir besoin d’estimer de nouveau l’ensemble des patchs et les k plus proches voisins. α peut donc être choisi interactivement par l’utilisateur.3.3. RÉSULTATS 41 i) Calcul de la surface grossière ii) Calcul des patches iii) Calcul des plus proches patches iv) Calcul des valeurs débruitées Temps de calcul avec accélération 5 10 15 10000 50000 100000 Temps (s) Temps de calcul sans accélération Temps (s) 150 300 10000 50000 100000 Figure 3.16: Gauche : Temps de calcul des différentes étapes de notre approche estimés en utilisant un seul cœur. Notre approche est plus longue que les opérateurs PSS précédents, car elle nécessite un plus grand nombre de projections (dû aux projections successives sur la surface grossière et sur la surface fine). Droite : Temps de calcul des différentes étapes de notre approche en utilisant différents outils d’accélération (parallélisation, GPU). En pratique, nous avons grandement accéléré le temps de calcul (20x) permettant de définir une utilisation plus interactive de notre NLPSS. sont définis avec une précision de 5 × 5 points. De plus, dans la mesure où ces paramètres sont fixés, le calcul des patchs du nuage peut être effectué une fois pour toutes. Ainsi, les surfaces résultantes peuvent être générées rapidement pour différentes valeurs de h et α. 3.3.3 Performances Notre approche non locale reste plus lente que des méthodes PSS conventionnelles. Ces performances inférieures peuvent s’expliquer par : (i) un nombre de projections sur les surfaces plus conséquent que les approches locales, (ii) la nécessité de comparer l’ensemble des patchs entre eux. Nous présentons en Figure 3.16, l’évolution des temps de calcul pris par chacune des étapes de notre algorithme en fonction du nombre de points à projeter. Certains paramètres du NLPSS influencent directement le temps de calcul, comme les échelles t0 et t1 du PSS sous-jacent. Ces dernières sont directement liées à la taille du voisinage nécessaire pour estimer les projections sur les surfaces grossières et fines. Ainsi, plus ce voisinage est grand, plus le temps de calcul est élevé. De la même manière, le nombre de points influence le nombre de projections nécessaires (Figure 3.13). Néanmoins comme nous l’avons expliqué en Section 3.3.2, le nombre de points par patch est fixé car il influence peu la qualité de la surface résultante. Pour estimer rapidement le voisinage d’un point donné, chaque PSS est basé sur un ball-tree tels qu’il est introduit par Guennebaud et coll. [GGG08]. De même, pour accélérer la comparaison des patchs, la moyenne non locale définie par l’Équation 3.13 est limitée à une recherche approximée des 500 plus proches voisins du patch considéré par FLANN [ML12,ML09]. Pour une meilleure interactivité avec l’utilisateur, ces temps de calcul sont grandement diminués (Figure 3.16) grâce à des outils de parallélisation CPU et GPU. De plus, notre approche peut être divisée en quatre étapes successives : (i) calcul de la surface grossière, (ii) estimation des patchs, (iii) calcul approché des plus proches voisins et (iv) calcul des valeurs débruitées (réglage de h et α). Comme les paramètres utilisés par notre approche42 Original SPSS HPSS APSS RIMLS NLPSS Figure 3.17: Comparaison entre les reconstructions PSS locales et notre NLPSS obtenues à partir d’un nuage de point 2D. peuvent être généralisés, seule l’étape ( iv) nécessite une interaction réelle avec l’utilisateur. De plus, une fois les étapes précédentes estimées, cette dernière peut être calculée rapidement (comme le montre le graphique de droite de la Figure 3.16) sans avoir besoin de réappliquer la chaîne complète. Les valeurs idéales de h et α peuvent donc être choisies interactivement par l’utilisateur. 3.3.4 Analyse de la qualité de la surface Les opérateurs PSS conventionnels essayent d’extraire une surface à partir d’un voisinage purement local. Comme le montre la Figure 3.17 qui présente différentes reconstructions de surfaces PSS à partir d’un nuage de points 2D synthétique, ce point de vue ne permet pas de conserver les caractéristiques présentent dans le nuage de points d’entrée supprimant par la même occasion les symétries originales du nuage d’entrée. En utilisant un point de vue plus global, notre NLPSS permet de générer une surface capable de conserver les symétries présentes dans l’objet original. Dans le cas d’un nuage de points réel issu d’un scanner 3D (Figure 3.18), les opérateurs PSS conventionnels doivent, en plus, faire un compromis entre la préservation des caracté- ristiques principales de l’objet et la suppression du bruit. Ce problème est particulièrement visible pour les SPSS qui tendent à trop filtrer les arêtes et pour le HPSS qui exagère les structures locales de bruits. D’autres opérateurs, comme l’APSS, possèdent un fort pouvoir débruitant, mais doivent être utilisés à des échelles de filtrage fines pour éviter une sup-3.3. RÉSULTATS 43 Original SPSS HPSS APSS RIMLS NLPSS Figure 3.18: Comparaison entre différentes surfaces obtenues par des PSS locaux et notre NLPSS obtenues à partir du modèle 3D scanné Ramesses pression complète des arêtes de l’objet. Malheureusement, à de telles échelles, ce dernier est incapable de supprimer complètement le bruit. Contrairement aux autres opérateurs, le RIMLS a été défini pour extraire les arêtes tout en supprimant le bruit de l’objet. Cette définition fournit de bons résultats dans le cas d’objets purement géométriques possédant des arêtes vives (par ex. objets manufacturés). Malheureusement, dans le cas d’objets réels, le RIMLS tend à exagérer les caractéristiques de l’objet. En comparaison, notre NLPSS réussit à éliminer le bruit introduit par la numérisation sans altérer les structures présentes dans l’objet. Cet avantage est dû à l’utilisation de l’information non locale qui peut augmenter localement le rapport signal sur bruit. Contrairement au RIMLS qui exagère les structures, notre opérateur NLPSS réussit à générer une surface qui est proche du nuage d’entrée. Il est important de comprendre que notre définition de surface non locale est plus gé- nérale qu’une simple combinaison d’un algorithme de filtrage de nuage de points (par exemple [DM11,Dig12]) et d’un modèle de reconstruction de surface existant. Pour mieux appréhender les différences fondamentales entre ces deux types d’approches, nous présentons en Figure 3.19 deux reconstructions de surfaces différentes. Dans le premier cas, la surface est définie en utilisant L’APSS à partir d’un nuage de points préalablement dé- bruité par un algorithme de débruitage non local. Dans le deuxième cas, la surface est directement définie en utilisant notre NLPSS. La première approche réussit à débruiter les points en exploitant l’autosimilarité du nuage, mais reste incapable de reconstruire une surface en exploitant l’autosimilarité du nuage. Ainsi, la surface résultante ne permet de compléter les trous en respectant le caractère périodique du nuage original. Au contraire, notre modèle NLPSS est capable de reconstruire la surface pour chaque point en exploitant l’autosimilarité et la redondance des structures du nuage de points. De manière similaire, une troisième approche, qui consisterait à reconstruire une surface directement à partir des points du nuage puis à utiliser une méthode non locale de débruitage de maillage surfacique [FDCO03,YBS06,WCZ+08,MRS12], n’exploiterait pas totalement l’autosimilarité du nuage tout en introduisant des problèmes de définition. Comme le montre la Figure 3.20, dans le cas de nuages très épars et bruités, les modèles PSS existants peuvent difficilement générer une surface correcte à des tailles de filtrage44 Largeur du patch : NL APSS NLPSS Figure 3.19: Comparaison des surfaces obtenues en utilisant l’APSS [GGG08] à partir d’un nuage de points débruité par un algorithme de filtrage non local et la surface obtenue directement avec notre définition de surface NLPSS. Nuage de points original APSS RIMLS NLPSS Figure 3.20: Comparaison entre différentes surfaces obtenues en utilisant des opérateurs PSS locaux et notre NLPSS sur un modèle d’étoile 3D synthétique. petites. Pour résoudre ce problème, les modèles de PSS conventionnels doivent augmenter leur niveau de filtrage, supprimant par conséquent toute l’information de basse échelle présente dans le nuage. Contrairement à ces définitions, notre NLPSS est capable de générer une surface plus stable. Cette propriété est due à (i) l’utilisation d’une surface grossière comme base à notre surface qui définit une structure topologique à notre PSS et (ii) la moyenne non locale qui est capable de débruiter des structures fines et de les rajouter sur la surface grossière sans introduire de fausses structures comme le font les modèles de PSS conventionnels. En Figure 3.21 et 3.22, nous présentons les surfaces obtenues par notre NLPSS à partir de nuages de points bruités issus de scanners 3D. Il est intéressant de noter que notre NLPSS est capable d’utiliser l’ensemble de l’information pour compléter les trous du nuage de3.3. RÉSULTATS 45 Original NLPSS Figure 3.21: Illustration du pouvoir débruitant de notre NLPSS sur le nuage de points 3D Dragon (413k points) acquis par numérisation 3D. Original NLPSS Figure 3.22: Application du NLPSS sur le nuage de points Ramesses (350K points) issu d’une numérisation 3D. Notre approche est capable de combler les trous de l’objet en utilisant l’autosimilarité présente dans le nuage de points. points. Cette propriété est illustrée en Figure 3.22) où l’information inconnue du visage d’un relief est complétée par l’information connue d’un relief similaire présent sur la statue. Néanmoins, cette propriété reste très dépendante de la qualité de la surface grossière sousjacente.46 Figure 3.23: Application de notre opérateur NLPSS au cas du débruitage de nuages de points. Nous avons utilisé le jeu de données Pyramid (120k points) issue de [DAL+11] Figure 3.24: Application de notre NLPSS pour définir une surface maillée en utilisant un algorithme de type Marching Cubes [LC87]. 3.3.5 Applications Filtrage de nuages de points Une des applications les plus évidentes des PSS est le filtrage de nuages de points. En considérant un nuage de points bruités, l’opération de débruitage du nuage consiste à remplacer chaque point xi ∈ X du nuage par leur projection x˜i = ΠNL(xi) sur la surface définie par l’opérateur de projection ΠNL définie par l’Équation 3.12. Ainsi, le nuage débruité est défini par P˜ = {x˜i}. Nous présentons en Figure 3.23, le résultat du débruitage obtenu par NLPSS. Reconstruction de surface L’une des utilisations majeures des opérateurs PSS est de définir une surface maillée à partir de la définition implicite de la surface. Nous définissons la surface comme la 0-3.4. LIMITATION ET POSSIBLES AMÉLIORATIONS 47 Figure 3.25: Application de notre NLPSS à l’édition de surfaces. Le paramètre β permet de moduler à quel point le champ scalaire de déplacement doit être ajouté à la surface grossière. Gauche : pour des valeurs β > 1, ces détails sont exagérés. Droite : pour des valeurs β < 0, ces derniers sont inversés. surface de la distance implicite fNL définie par l’Équation 3.13. La surface maillée est obtenue en utilisant un algorithme de Marching Cubes. Nous présentons en Figure 3.24 la surface NLPSS maillée obtenue à partir d’un nuage de points bruités. Améliorations des détails Pour illustrer le potentiel de notre NLPSS, nous proposons une utilisation de notre dé- finition pour l’édition de surfaces. Comme nous l’avons expliqué en Section 3.2.1, notre opérateur NLPSS est défini par une surface grossière sur laquelle nous ajoutons un champ scalaire de déplacement. Nous pouvons modifier la fonction implicite fNL définie en Équation 3.13 en multipliant le champ scalaire de déplacement par un champ scalaire continu β(x) : fNL(x) = f t0 (x) − β(x) X xi∈X wNL(x, xi)f t0 (xi) (3.15) Par conséquent, β(x) permet de décrire pour chaque x à quel point les détails fins fNL(x) sont ajoutés à la surface grossière St0 . Les détails sont ajoutés à la surface grossière pour des valeurs de β(x) > 0, et exagérés si β(x) > 1. Des valeurs de β(x) négatives permettent de supprimer les détails de la surface grossière, inversant de la même manière les caractéristiques de l’objet. Ainsi, l’utilisateur peint directement sur la surface grossière St0 les valeurs de β(x) choisissant, de la même manière, les éléments de l’objet qu’il souhaite exagérer. Nous présentons en Figure 3.25 une illustration de cette démarche. 3.4 Limitation et possibles améliorations Dans cette partie nous avons défini un opérateur PSS capable d’exploiter le caractère autosimilaire des nuages de points pour définir une surface. Notre définition est capable48 Figure 3.26: Gauche : Notre approche non locale peut résulter en l’apparition de halos sur la surface. Centre : Une solution simple pour résoudre ce problème consiste à définir différentes surfaces NLPSS en utilisant des patchs décentrés. Droite : Une simple moyenne de ces différentes valeurs débruitées permet de limiter les effets des halos introduits. d’améliorer la qualité des surfaces définies par des opérateurs PSS locaux en augmentant le rapport signal/bruit. Néanmoins, les résultats de notre opérateur sont très dépendants de l’aspect autosimilaire du nuage à traiter. Plus le nuage de points présentera de parties similaires, plus la qualité de la surface générée par notre approche sera élevée. Dans le cas, peu probable, d’absence d’autosimilarité dans le nuage de points, notre NLPSS obtiendra des résultats identiques à l’opérateur PSS local sous-jacent (Section 3.2.4). Il est courant que l’utilisation de patchs par les méthodes non locales introduise des oscillations ou halos autour des arêtes des images. Le même phénomène peut être observé sur les surfaces définies par notre approche autour des arêtes vives de l’objet (Figure 3.26). Ce problème peut s’expliquer par le phénomène d’adhérence des patchs. [LBM13] proposent une solution simple pour résoudre ce problème. Elle consiste à faire une moyenne des différentes cartes débruitées en considérant des patchs décentrés. Nous présentons en Figure 3.26 une extension de cette solution à notre NLPSS. Cette solution permet d’éliminer les halos et d’améliorer la qualité de la surface résultante au prix de temps de calcul plus coûteux. Pour définir notre mesure de similarité (Section 3.2.3), nous avons utilisé une distance euclidienne entre les patchs. Cette distance nous permet de définir des surfaces NLPSS correctes, mais reste néanmoins trop sensible au bruit et aux points aberrants. Remplacer la norme L2 par une norme L1 permettrait de définir une surface moins sensible aux points aberrants. Il serait intéressant de redéfinir les patchs en ajoutant pour chaque point projeté la normale associée à cette projection. Ainsi, la distance entre les patchs correspondrait à une distance L2,1 qui tient compte à la fois des variations des positions et des normales. Une telle approche revient à étendre les patchs de manières "géodésique" plus qu’euclidienne permettant ainsi de différencier les caractéristiques intrinsèques de l’objet tout en étant moins sensibles au bruit. En comparaison avec les définitions de PSS conventionnelles, le NLPSS requiert un temps de calcul supérieur. Ce phénomène s’explique par la nécessité de projeter plus de points que les méthodes PSS précédentes et de rechercher les patchs les plus similaires. Durant3.4. LIMITATION ET POSSIBLES AMÉLIORATIONS 49 ces dernières années, beaucoup de travaux se sont fixés comme objectif d’accélérer le calcul des filtres à moyennes non locales (Section 4.1.1). Un point important de notre travail futur consistera à essayer d’adapter ces méthodes au cas des nuages de points et à utiliser les technologies de parallélisation offerte par les cartes graphiques modernes pour que notre approche soit utilisable en temps réel. Pour conclure, notre NLPSS permet le remplissage de trous d’une taille similaire à celle utilisée pour définir les patchs de surface. Pour des trous d’une échelle supérieure, une telle approche n’est pas suffisante. Il est donc nécessaire d’utiliser une méthode itérative d’inpainting de surfaces. Malheureusement, de telles méthodes restent difficile à calculer et nécessitent la connaissance d’un a priori sur les surfaces 3D.C h a p i t r e 4 Arbre de covariances Dans ce chapitre, nous présentons une structure de données capable d’apprendre les variations de grands ensembles d’échantillons en utilisant une quantité de mémoire limitée. En Section 4.1, nous présentons un historique des méthodes d’accélérations des filtres à hautes dimensions. Dans la Section 4.2, nous introduisons une version simplifiée de notre arbre définie dans un domaine spatial. Cette version est ensuite étendue en Section 4.3 en distinguant deux domaines : spatial et des attributs. Les performances de notre structure sont ensuite analysées en Section 4.4. Finalement, nous proposons en Section 4.5 diverses améliorations de notre structure de données. 4.1 Contexte 4.1.1 Filtrage à hautes dimensions Avec l’apparition des nouvelles technologies et de nouvelles capacités de calculs, le filtrage à hautes dimensions est devenu durant ces dernières années une brique fondamentale pour une variété d’applications telles que le débruitage [BCM05], la récoloration [CPD07], le suréchantillonage [KCLU07], la manipulation de détails [BPD06,FAR07], le filtrage spatiotemporel [BM05]. Implémentés naïvement, de tels filtres restent difficiles et lents à calculer et nécessitent d’être accélérés. Ainsi, le rapport entre le temps de calcul et la qualité des résultats obtenue est devenu un enjeu important pour les communautés de la vision par ordinateur, du traitement des images et de la photographie calculatoire. De nombreuses approches ont été introduites afin d’accélérer leur estimation. Parmi elles, une première catégorie de méthodes propose une accélération par estimation d’un champ approché des k-plus proches voisins comme par exemple PatchMatch [BSFG09] (récemment étendu à d’autres domaines [NFP+13, CFGS12, BRR11] et accéléré par kdtree [HS12], l’utilisation d’images intégrales [OA12], l’utilisation d’une transformée de Fourier [WGY+06, DDS12], la réduction de la dimensionnalité des patches par les filtres de Haar [KA11] ou une analyse en composantes principales [APG07,Tas08,Tas09], la limitation de la recherche à un voisinage 2D local (utilisé en pratique par [BCM05,LBM13]). Ces méthodes restent néanmoins trop spécifiques aux problèmes de traitement des images et peuvent difficilement être étendues au cas 3D. De plus, les approches de débruitage par 5152 filtres collaboratifs, définissant une meilleure restauration de l’image que les approches par moyenne non locale, ne peuvent être accélérées par une estimation approchée des k-plus proches voisins. Par conséquent, nous focaliserons notre étude sur l’utilisation de structures d’accélération qui permettent une réduction de la complexité computationnelle des filtres au prix d’approximations visuelles résultantes. 4.1.2 Travaux existants Parmi tous les filtres non linéaires, le filtre bilatéral [TM98] a été l’un des premiers à avoir été accéléré car il constitue une approximation intéressante des filtres anisotropes [Bar02]. Durand et Dorsey [DD02] sont parmi les premiers à proposer une accélération de ce filtre appliquée à l’affichage d’images à grande dynamique (High Dynamic Range - HDR). Leur idée principale est de réduire la complexité du filtre en utilisant une approximation linéaire par morceaux du filtre bilatéral, ce qui revient à appliquer un filtre gaussien, plus rapide à calculer, sur un sous-échantillonnage du domaine spatial. Ces valeurs sous-échantillonnées sont ensuite interpolées pour obtenir le signal filtré. En remarquant que le filtre bilatéral peut être exprimé par un filtre gaussien appliqué dans un espace de dimensions supérieures, Paris et Durand [PD06] introduisent la grille bilaté- rale. Cette dernière sous-échantillonne le signal à filtrer par des voxels de taille uniforme en exprimant le signal à filtrer comme une variété linéaire par morceaux définie dans un espace qui associe le domaine spatial et colorimétrique (appelé par la suite espace augmenté). Pour rendre l’accélération plus performante, l’espace colorimétrique est réduit à une unique dimension. Néanmoins, les distances en chrominance ne sont pas respectées ce qui introduit des effets de flou parasites. Ce problème est résolu dans une version ultérieure de leurs travaux [PD09] par l’utilisation de toutes les dimensions colorimétriques. La grille bilatérale, définissant désormais un volume 5D, nécessite une quantité de mémoire et en temps supérieur. En particulier pour des échelles de filtrage faibles, cette méthode devient impraticable. Adams et coll. [AGDL09] proposent de remplacer le pavage régulier par un pavage adaptatif de l’espace augmenté. Ils introduisent une structure d’accélération indépendante de l’échelle de filtrage, le kd-tree gaussien (Gaussian KD-Tree - GKD-Tree), en se basant sur les travaux de Aray et coll. [AMN+98]. Ils proposent de paver l’espace augmenté avec des voxels de tailles non uniformes en utilisant un kd-tree [Ben75] qui regroupe les échantillons proches. Les valeurs des voxels sont estimées par diffusion des valeurs des échantillons qui lui sont proches (splatting), filtrées entre elles (blurring) et finalement interpolées pour définir les valeurs filtrées de chaque échantillon (slicing). Cette approche peut être gé- néralisée à l’accélération de l’ensemble des filtres non linéaires à poids gaussiens (filtre gaussien, bilatéral, à moyenne non locale, etc.). Ultérieurement, Adams et coll. [ABD10] étendent leurs travaux en pavant l’espace avec des simplexes et en stockant les valeurs de ces derniers dans une table de hachage. Ainsi, la structure d’accélération permet d’appliquer des filtres non linéaires de hautes dimensions avec une complexité linéaire par rapport au nombre de points et polynomiale par rapport à la dimensionnalité du filtre. Dans le cas des filtres à très hautes dimensions, la complexité polynomiale par rapport aux nombres de dimensions des précédentes approches ne permet pas qu’elles soient appliquées en temps réel. He et coll. [HST10] proposent de réduire la dimensionnalité du problème4.1. CONTEXTE 53 en comparant indirectement chaque pixel de l’image par rapport à leur relation à un guide. Même si cette approche permet une accélération significative, elle introduit des artefacts dus à l’utilisation d’une distance non euclidienne. De la même manière, Gastal et Oliveira [GO11] proposent, dans le cas des filtres bilatéraux, l’utilisation d’une transformée de l’image qui déforme la géométrie du domaine spatial 2D du signal à filtrer de sorte que la distance spatiale entre deux points de l’espace déformé corresponde à la distance géodésique dans l’espace augmenté 5D. Ainsi, le filtre bilatéral est approximé par un filtre gaussien appliqué dans le domaine spatial. Ces travaux sont ensuite généralisés au cas de filtres de plus hautes dimensions [GO12]. Gastal et Oliveira démontrent que le signal à filtrer peut rarement être défini par une variété linéaire. Par conséquent, l’utilisation de voxels n’est pas adaptée pour obtenir un sous-échantillonnage correct de l’espace. À la place, ils proposent l’utilisation de variétés non linéaires adaptatives qui sont définies en appliquant récursivement un filtre passebas sur les échantillons du signal. Le signal filtré est estimé en utilisant une approche similaire au GKD-Tree [AGDL09] : les valeurs des variétés sont estimées par diffusion des valeurs des échantillons (splatting), puis filtrées entre elles indépendamment des valeurs des autres variétés (blurring) et finalement interpolées pour définir les valeurs filtrées de chaque échantillon (slicing). Cette approche permet d’obtenir une complexité qui est à la fois linéaire par rapport à la dimensionnalité du filtre et du nombre d’échantillons. 4.1.3 Problématique Si l’on devait résumer les progrès de ces dernières années, le calcul de filtres non linéaires a été accéléré de deux manières : (i) en redéfinissant les filtres non linéaires par des filtres linéaires exprimés dans des espaces augmentés qui associent les domaines spatial et colorimétrique (ii) en interpolant une version sous-échantillonnée du signal filtré adapté à l’échelle de filtrage. Même si les structures d’accélérations associées sont aujourd’hui capables d’appliquer en temps réels des filtres non linéaires à hautes dimensions, elles ne peuvent pas être utilisées pour accélérer le calcul de filtres probabilistes collaboratifs tels que les Non-Local Bayes. De plus, elles doivent être entièrement reconstruites pour chaque modification des paramètres de filtrage. D’un autre point de vue, avec l’augmentation de la quantité d’information, peu de mé- thodes à l’heure actuelle exploitent réellement l’information contenue dans les grandes bases de données ou au prix d’une quantité de mémoire et de calculs beaucoup trop importante. Les structures d’accélération de filtrage non linéaire actuelles ne sont pas conçues pour être directement exploitées sur ces bases. Nous proposons d’associer les avancés récentes sur les structures d’accélération des filtres non linéaire avec les dernières avancées du domaine non local. Nous proposons une nouvelle structure de données, plus générale qu’une simple structure d’accélération, capable d’apprendre les distributions locales d’un grand ensemble d’échantillons en les représentant par des gaussiennes anisotropes. Contrairement aux méthodes qui représentent les distributions d’échantillons par un modèle de mixture de gaussiennes de nombre fini [YSM12], ces gaussiennes sont estimées en fonction de la région de l’espace considéré.54 Ainsi, nous introduisons l’arbre de covariance (Covariance Tree - CovTree) qui possède les caractéristiques suivantes : 1. Apprentissage de grande base de données : En utilisant une approche similaire aux structures d’accélérations des filtres non linéaires, l’ensemble des échantillons est réparti en sous-ensembles adaptés représentés par des gaussiennes indépendantes du nombre d’échantillons. 2. Optimisation de la mise à jour des données : L’ajout d’un échantillon dans notre structure n’entraîne pas la reconstruction complète de la structure. Seules les gaussiennes qui décrivent les distributions de chaque sous-ensemble sont modifiées. L’ajout d’un point dans notre structure permet d’améliorer l’estimation des statistiques des distributions sans changer la quantité de mémoire utilisée. 3. Estimation des distributions locales à différentes échelles : Contrairement aux structures d’accélération des filtres non linéaires, notre CovTree a été conçu pour être indépendant des paramètres d’échelles. Ainsi, l’estimation des distributions locales peut être effectuée en un temps raisonnable sans avoir besoin de reconstruire entièrement la structure. 4. Généralisation de la structure d’apprentissage : Notre approche est générique et peut être appliquée dans un espace de dimensions arbitraires. Pour être utilisable par un plus grand nombre d’applications, elle est définie en utilisant deux domaines distincts : un domaine spatial (utilisé pour calculer une distance entre les échantillons) et un domaine des valeurs (utilisé pour exprimer les statistiques sur les distributions). Notre structure d’apprentissage est beaucoup plus générique qu’une simple structure d’accélération de filtres collaboratifs. Comme nous le montrerons dans le chapitre 5, cette dernière peut être utilisée pour des applications 2D et 3D variées. 4.2 Arbre de Covariance Simplifié Pour mieux appréhender les idées fondamentales de notre approche, nous introduisons dans cette section une version simplifiée de notre CovTree qui sera utilisé pour apprendre les distributions d’échantillons dans un espace fini. Elle nous permettra d’introduire les principes sous-jacents à notre structure de données. Néanmoins, cette définition reste trop spécifique pour être utilisée en pratique. Par consé- quent, nous introduisons en Section 4.3 une définition plus générique de notre CovTree utilisable pour résoudre des problèmes de restauration variés. 4.2.1 Principe Idée générale Considérons un ensemble d’échantillons P = {pi} où pi ∈ S ⊂ R dS . Notre CovTree est défini comme une structure de données qui apprend localement la distribution des points de P à partir d’un sous-échantillonnage adaptatif (cellules) de S. Pour n’importe quelle4.2. ARBRE DE COVARIANCE SIMPLIFIÉ 55 Figure 4.1: Gauche : Nous illustrons le principe de notre CovTree sur un nuage de points pi extrait d’une courbe 2D pour un voisinage centré en q et de rayon σq. Droite : Le but de notre CovTree est d’apprendre la distribution des points P et de modéliser la répartition des points qui sont compris dans ce voisinage par une gaussienne anisotrope représentée par une moyenne µˆ et une matrice de covariance Σˆ . requête de position q ∈ S et échelle σq ∈ R, la structure retourne la gaussienne anisotrope correspondante à la distribution locale des échantillons de P appris. En Figure 4.1, nous illustrons les entrées et sorties de notre Cov-Tree dans le cas où P correspond à un nuage de points 2D issu d’une courbe. Dans ce cas, les pi définis dans un espace S = R 2 représentent les positions des points du nuage. Notre CovTree permet donc d’apprendre la répartition des points du nuage et fournit pour n’importe quel voisinage euclidien, la gaussienne anisotrope correspondante à la distribution des points du nuage compris dans ce voisinage. Dans le cas où P correspond à l’ensemble des patchs d’une image bruitée, cette structure de donnée simplifiée peut être utiliser pour estimer le résultat de filtres collaboratifs tels que les Non Local Bayes [LBM13]. Représentation des distributions locales Pour apprendre les distributions des échantillons de P, nous effectuons une analyse statistique de sous-ensembles C ⊂ P d’échantillons locaux. L’idée fondamentale de notre CovTree est de remplacer ces sous-ensembles par leurs statistiques respectives. Dans cette partie, nous fournissons une analyse de pouvoir synthétique de ces dernières et de leur impact sur les performances de notre CovTree. En considérant que l’ensemble des points de C sont compris dans une boule de rayon négligeable, la distribution peut être représentée correctement par une simple moyenne des points de C. Cette solution est utilisée pour accélérer le calcul des filtres à hautes dimensions [AGDL09] car pour des échelles inférieures à l’échelle de filtrage, il est inutile de conserver de plus fines variations des échantillons. Comme nous le présentons en Figure 4.2, cette solution est équivalente à conserver l’ensemble des échantillons de P en mémoire pour des échelles de filtrage fines. De plus, comme la moyenne ne fournit aucune information56 (a) Nuage de points 2D (c) Représentation par des gaussiennes isotropes (b) Représentation par des moyennes (d) Représentation par des gaussiennes anisotropes Figure 4.2: Différentes représentations statistiques du nuage de points 2D. (a) Nuage de points 2D original. (b) Utiliser une moyenne par cellules pour représenter un nuage de points revient à garder l’ensemble des points du nuage pour des tailles de cellules faibles et ne permet de représenter efficacement les variations du nuage à de grandes échelles. (c) En utilisant des gaussiennes isotropes, la modélisation devient plus fiable à des échelles fines, mais reste malgré tout trop grossière pour représenter la distribution à des échelles élevées. (d) Nous proposons l’utilisation de gaussiennes anisotropes qui permettent de représenter correctement les distributions à de grandes échelles avec un nombre de gaussiennes limitées. sur les variations des échantillons qu’elle représente, elle ne peut être utilisée correctement à de larges échelles pour représenter la distribution de grands ensembles de données. Pour de grandes échelles comme la moyenne ne fournit aucune information variationnelle, il devient difficile de représenter correctement la distribution des échantillons d’un grand ensemble de données. Pour des ensembles d’échantillons de C distribués de manière isotrope dans une boule, l’approche précédente peut être améliorée en associant à la moyenne des points de C une variance. La distribution peut par conséquent être modélisée par une gaussienne isotrope. Désormais, la représentation dépend directement de la répartition des données et non de l’échelle de filtre à appliquer. Comme nous l’illustrons en Figure 4.2, cette contrainte d’isotropie reste difficile à satisfaire pour des échelles élevées. De plus, elle revient à garder en mémoire l’ensemble des échantillons pour des échelles fines. Les deux approches précédentes ne sont pas suffisantes pour apprendre les distributions d’échantillons. Par conséquent, nous préférons les représenter par l’intermédiaire de gaussiennes anisotropes. Nous associons donc chaque sous-ensemble C à sa moyenne µ et sa matrice de covariance Σ. Comme nous le démontrons en Figure 4.2, ce choix permet de4.2. ARBRE DE COVARIANCE SIMPLIFIÉ 57 Figure 4.3: Notre CovTree est basé sur trois étapes principales. Construction : à partir d’un ensemble d’échantillons, nous construisons un arbre binaire qui partitionne l’espace en fonction des positions des échantillons {pi} pour créer des cellules de taille σb. Apprentissage : chaque nœud apprend les distributions statistiques locales modélisées par des noyaux anisotropes en propageant l’ensemble des échantillons à travers l’arbre en fonction de leur position pi et ajoutant une contribution pondérée des pi au noyau de chaque nœud de l’arbre traversé. Requête : pour toute requête constituée d’une position q ∈ S et échelle σq ∈ R, notre CovTree modélise la distribution locale des données apprises en q et à l’échelle σq par une gaussienne multivariée définie par sa moyenne µˆ et sa matrice de covariance Σˆ . représenter correctement les distributions des échantillons à des échelles fines et élevées. De plus, l’utilisation d’une gaussienne anisotrope nous permet de diminuer la quantité de mémoire nécessaire, d’augmenter le pouvoir descriptif de notre CovTree et d’être plus indé- pendant des contraintes d’échantillonnages (complétion des trous/données manquantes). Chaîne de traitement Notre approche, résumée en Figure 4.3, peut être divisée essentiellement en trois étapes. Ces dernières peuvent être comparées avec les trois étapes de splatting, blurring, slicing utilisé par les travaux sur l’accélération de filtres à hautes dimensions [PD09, ABD10, GO12]. 1. Construction : Nous effectuons un sous-échantillonnage hiérarchique pyramidal de S basé sur les échantillons de P jusqu’à l’obtention de cellules de taille σb. Il en résulte un arbre binaire dont chaque nœud (correspondant à un sous-espace de S) est associé à un noyau anisotrope modélisant la distribution statistique des points de P appartenant à la cellule spatiale correspondante (Section 4.2.2). 2. Apprentissage : Nous apprenons les distributions de points par propagation (entraînement) des données à travers l’arbre binaire. Chaque point est classifié en considérant sa position et ajoute une contribution pondérée au noyau anisotrope de chaque nœud de l’arbre qu’il traverse (Section 4.2.3). 3. Requête : Pour toute requête définie par une boule de centre q ∈ S et échelle σq ∈ R, notre CovTree fournit la distribution des données apprises correspondant à ce voisinage. Elle est modélisée par une gaussienne multivariée représentée par58 (a) Partionnement par grille (b) Partionnement par kd-tree (c) Partionnement par bsp-tree Figure 4.4: Nous proposons ici différents partitionnements de l’espace. (a) : Une grille régulière permet de définir des cellules régulières. Ces dernières sont définies indépendamment des données qu’elles contiennent résultant des cellules vides ou mal définies. (b) : Le kd-tree définit un partitionnement hiérarchique de l’espace dont les partitions sont faites dans des directions indépendantes des données à apprendre. Il ne crée pas de cellules vides, mais ne tient pas compte de l’anisotropie des données. (c) : Notre bsp-tree définit un partitionnement hiérarchique de l’espace qui permet de tenir compte de l’anisotropie des données à apprendre. une une moyenne µˆ et d’une matrice de covariance Σˆ interpolée en q à l’échelle σq (Section 4.2.4). Il est important de comprendre que σb et σq sont liés à la quantité d’informations que nous voulons récupérer. L’application successive des trois étapes de construction, d’apprentissage et de requête est approximativement équivalente à estimer une matrice de covariance avec un noyau gaussien de taille √ 2σq. Pour prévenir tout problème de calcul σq doit être choisi plus grand que σb, suffisamment large pour outrepasser le bruit, mais suffisamment petit pour capturer les structures locales. Généralement, σb ≈ σn et σq ≥ σn. 4.2.2 Construction Pavage adapté de l’espace Durant l’étape de construction, nous définissons un partitionnement de l’espace S en cellules spatiales. Ces cellules doivent être adaptées à la distribution des échantillons de P afin de respecter les variations topologiques de P (et d’obtenir un meilleur apprentissage des données). Nous fournissons dans cette partie une analyse de plusieurs solutions pour partitionner l’espace et de leur impact sur les performances du CovTree. Une des solutions les plus faciles est de diviser l’espace en un ensemble de cellules régulières par l’intermédiaire d’une grille [PD06, PD09]. Malgré sa simplicité de mise en œuvre, utiliser ce schéma de subdivision pour notre CovTree présente trois problèmes (Figure 4.4). Tout d’abord, la quantité de mémoire utilisée est d’autant plus grande que l’espace S est de dimension élevée et que la taille des cellules est faible. Ensuite, les cellules sont définies indépendamment du signal à considérer, ainsi, les gaussiennes anisotropes ne sont pas nécessairement représentatives des variations des échantillons. Le problème majeur vient4.2. ARBRE DE COVARIANCE SIMPLIFIÉ 59 du fait que ces cellules ne contiennent pas obligatoirement des échantillons et accaparent inutilement de l’espace mémoire. Pour résoudre ce problème, il est plus judicieux d’utiliser des structures de subdivision hiérarchique telle que le kd-tree [AGDL09]. Ce dernier est défini comme un arbre binaire dans lequel chaque nœud est associé à un sous-espace de S. Chaque nœud interne de l’arbre divise l’espace en deux demi-espaces distincts selon un hyperplan normal à la direction de plus grande variation des points. Cette direction est choisie parmi les directions d’un repère orthonormé fixe de l’espace S définie indépendamment de P. Une fois encore, les cellules spatiales échouent à capturer l’anisotropie des données correctement (Figure 4.4). Les échantillons, regroupés de manière inadéquate, définissent des distributions locales de P parasites. De plus, le partitionnement ainsi défini est différent pour tout changement d’orientation. Par conséquent, nous définissons notre CovTree par l’intermédiaire d’une structure de partitionnement binaire de l’espace, le bsp-tree [FKN80], qui divise l’espace en deux sousespaces distincts par l’intermédiaire d’un hyperplan orienté selon la direction de plus grande variation des données d’entrées. Les cellules ainsi obtenues ne sont pas nécessairement parallélépipédiques et permettent de tenir compte de l’anisotropie des données à apprendre (Figure 4.4). Les gaussiennes anisotropes résultantes permettent de mieux représenter le signal. Algorithme Nous divisons l’espace par l’intermédiaire d’un bsp-tree dont chaque nœud est associé à un sous-espace C ⊂ S, un sous-ensemble d’échantillons pj ∈ P ∩ C et à un rayon de cellule ηr (utilisé pour apprendre les distributions à différentes échelles). Chaque nœud interne de l’arbre divise l’espace en deux demi-espaces distincts par l’intermédiaire d’un plan de coupe {ηc, ηd} dont la normale ηd est définie comme le vecteur propre normalisé associé à la plus grande valeur propre de la covariance des {pj} et ηc par la moyenne des {pj}. En pratique, ηd est estimé avec une complexité linéaire par rapport à la dimension de S et au nombre d’échantillons en utilisant la méthode de la puissance itérée. Le rayon de cellule est défini par : ηr = max pj kpj − ηck (4.1) L’ensemble des points {pj} est partagé en deux sous-ensembles par rapport à leur distance signée au plan (pj − ηc) tηd. Les deux sous-branches du nœud η sont ensuite construites en se basant sur ces deux sous-ensembles. En initialisant le nœud racine avec l’ensemble des données d’entrée {pi}, nous appliquons récursivement ce schéma de subdivision tant que le rayon de cellule ηr > σb. Par consé- quent, l’utilisateur peut choisir la précision d’apprentissage de notre CovTree (ainsi que la quantité de mémoire qu’il va utiliser) en modifiant la valeur du paramètre σb. L’Algorithme 1 présente le pseudo-code de cette étape de construction.60 Algorithm 1: Construction de l’arbre Fonction ConstruireNœud(C ⊂ P, σb ∈ R) Entrées: C un sous-ensemble de P, σb l’échelle d’arrêt Sorties: η le nœud créé Allouer un nouveau nœud η // Estimation des paramètres de la cellule ηd ← le vecteur associé à la plus grande valeur propre de cov(C) ηc ← mean pi∈Ck (pi) ηr ← max pi∈Ck kpi − ηck si ηr ≤ σb alors Marquer η comme feuille de l’arbre sinon // Répartition des points dans les deux sous-espaces Cgauche ← {pi ∈ Ck,(pi − ηc) tηd ≤ 0} Cdroit ← {pi ∈ Ck,(pi − ηc) tηd ≥ 0} // Création des deux sous-arbres ηgauche ← ConstruireNœud(Cgauche, σb) ηdroit ← ConstruireNœud(Cdroit , σb) fin retourner η fin 4.2.3 Apprentissage Algorithme Une fois la structure de l’arbre initialisée, nous pouvons calculer les statistiques de chaque cellule en propageant l’ensemble des données d’apprentissage {pi} à travers l’arbre. En partant de la racine, les points traversent l’arbre jusqu’à atteindre une feuille. Le parcours est effectué en considérant les positions des points pi . Les gaussiennes anisotropes associées à chacun des nœuds η traversés sont enrichies des valeurs pi pondérées par un poids wi = φ  kpi−ηck ηr  . Ce poids est défini grâce à une approximation compacte, linéaire par morceaux du noyau gaussien φ centré en ηc et de variance ηr : φ(x) =    4 − 0.75x 2 (2 − x) si 0 < |x| ≤ 1 0.25(2 − x) 3 si 1 < |x| ≤ 2 0 sinon (4.2) Pour simplifier les deux étapes d’apprentissage et de requête, la moyenne et la covariance des échantillons ne sont pas directement conservées en chaque nœud. A la place, nous4.2. ARBRE DE COVARIANCE SIMPLIFIÉ 61 Algorithm 2: Apprentissage des variations locales Fonction ApprendreVariations(p, η) Entrées: p un point à ajouter dans la structure, η un nœud de l’arbre // Calcul des poids w par approximation d’une gaussienne de variance ηr w ← φ  kpi−ηck ηr  // Mise à jour des statistiques de chaque nœud wη := wη + w w2η := w2η + w.w µη := µη + w.p Ση := Ση + w.p tp // Apprentissage des statistiques à une échelle inférieure si η n’est pas une feuille de l’arbre alors si (p − ηc) tηd ≤ 0 alors ApprendreVariations(p, ηgauche) sinon ApprendreVariations(p, ηdroit) fin fin fin stockons une somme partielle µη , une somme croisée partielle des positions Ση et deux constantes de normalisation wη et w2η : wη := wη + wi w2η := w2η + wi .wi µη := µη + wi .pi Ση := Ση + wip t ipi (4.3) La moyenne et la covariance représentatives des variations du nœud peuvent être retrouvées à partir de ces quatres variable. L’Algorithme 2 présente le pseudo-code de l’étape d’apprentissage. Complétion des données d’apprentissage De manière générale, le même ensemble de points P est utilisé lors de l’étape de construction et d’apprentissage. Néanmoins, il est possible d’utiliser un sous-ensemble représentatif P ′ ⊂ P différent pour définir un partitionnement de l’espace S lors de l’étape de construction. Cette approche possède deux avantages : (i) le partitionnement de l’espace peut être défini plus rapidement (en particulier dans le cas d’une large base de données), (ii) il n’est pas nécessaire de connaître l’ensemble des données pour commencer l’apprentissage des données (par ex. traitement vidéo). De plus, comme nous utilisons une analyse statistique partielle (nous stockons en mémoire uniquement des sommes partielles et non directement les statistiques), il devient possible62 d’ajouter au fur et à mesure des échantillons par l’intermédiaire de l’Équation 4.3. Chaque point ajouté durant l’étape d’apprentissage augmente la précision des distributions apprises par chaque cellule. L’avantage d’une telle approche est que l’espace mémoire utilisé reste constant quel que soit le nombre d’échantillons rajoutés. En effet, nous ne gardons pas en mémoire l’ensemble des échantillons, mais uniquement les quatre variables wη, w2η, µη et Ση. Cette propriété peut être utilisée pour apprendre la distribution d’échantillons issus d’une grande base de données. Notre structure représente localement la répartition des échantillons par l’intermédiaire de gaussiennes multivariées utilisant peu d’espace mémoire. Cette propriété sera utilisée en Section 5.2 pour approcher l’a priori sous-jacent aux patchs des images naturelles. 4.2.4 Requête Accélération de la requête Pour tout voisinage de centre q ∈ S et de rayon σq ∈ R, la gaussienne anisotrope est estimée par une combinaison des données apprises sur chaque nœud de l’arbre avec des poids décroissants par rapport à l’éloignement au centre de la requête q. Pour accélérer le calcul de cette estimation, il suffit de sélectionner uniquement les nœuds qui possèdent les poids les plus élevés. Certaines méthodes [AGDL09] proposent par exemple un schéma de requête à importance des échantillons. L’idée principale est de distribuer un nombre d’échantillons à travers l’arbre jusqu’à atteindre les feuilles en favorisant les nœuds de poids les plus élevés. Cette démarche peut être perçue comme une méthode de Monte-Carlo qui propage les points dans l’arbre de manière probabiliste de sorte à atteindre les nœuds les plus proches. Même si une telle démarche fonctionne relativement bien pour des espaces de basses dimensions (car peu d’échantillons sont nécessaires pour estimer correctement les distributions), pour des espaces de dimensions élevées il devient nécessaire de faire un choix entre précision de l’estimation et temps de calculs. En effet le nombre d’échantillons nécessaires pour avoir une précision de l’estimation suffisante est plus élevé. Par conséquent, ce genre d’approche ne peut être utilisé dans notre CovTree. Pour ré- soudre ce problème, nous proposons d’utiliser l’apprentissage des distributions à différents niveaux de l’arbre et le rayon ηr associé à chaque nœud. Cette démarche nous permet de limiter le parcours en profondeur de l’arbre, le nombre de nœuds à explorer et d’être plus indépendant de l’échelle de la requête σq. Algorithme Une fois notre CovTree complètement construit et appris, nous utilisons un schéma de requête pour estimer la gaussienne anisotrope décrivant la distribution des données apprises pour n’importe quel voisinage centré en q ∈ S d’échelle σq ∈ R. Tout d’abord, nous collectons l’ensemble des nœuds η qui intersecte la boule [q, σq]. Pour ce faire, chaque requête traverse l’arbre jusqu’à atteindre une feuille ou un nœud vérifiant4.2. ARBRE DE COVARIANCE SIMPLIFIÉ 63 Algorithm 3: Interroger l’arbre Fonction InterrogerArbre(q, σq) Entrées: q ∈ S un point requête et σq une échelle de requête Sorties: la gaussienne anisotrope N (µˆ, Σˆ ) // Requête de l’arbre en commençant par la racine η0 {w, ˆ wˆ2, µ, Σ} ←CalculerVariations(q, σq, η0) // Estimation des paramètres de la gaussienne multivariée µˆ ← 1 wˆµ Σˆ ← wˆ 2−wˆ2 wˆ (Σ − wˆµˆ tµˆ) retourner N (µˆ, Σˆ ) fin Fonction CalculerVariations(q, σq, η) Entrées: q ∈ S un point requête, σq une échelle de requête et η un nœud de l’arbre Sorties: µ, Σ, ˆw et ˆw2 si ηr ≤ σq où η est une feuille de l’arbre alors // Calcul des poids w par approximation d’une gaussienne de variance σq w ← φ  kq−ηck σq  // Ajout des variations du nœud η wˆ := ˆw + w wˆ2 := ˆw2 + w 2 µ := µ + wµη Σ := Σ + wΣη sinon // Ajout des variations du nœud η en résultat si (q − ηc) tηd ≤ σq alors {w, ˆ wˆ2, µ, Σ} := {w, ˆ wˆ2, µ, Σ}+CalculerVariations(q, σq, ηgauche) sinon {w, ˆ wˆ2, µ, Σ} := {w, ˆ wˆ2, µ, Σ}+CalculerVariations(q, σq, ηdroit) fin fin retourner {w, ˆ wˆ2, µ, Σ} fin ηr > σq. Lors de la propagation de la requête, nous considérons que chaque cellule est élargie de σq. Ainsi pour des distances au plan de coupe |(q − ηc) tηd| < σq, les deux sous-arbres gauche et droit sont explorés.64 Au final, la distribution en q est estimée par une combinaison des distributions des nœuds collectés {µi , Σi} pondérées par des poids wi définis à partir de l’approximation du noyau gaussien φσq centré en q et de variance σq : wˆ = X i wiwηi wˆ2 = ˆw 2− X i wiw2ηi µˆ = 1 wˆ X i wiµηi Σˆ = wˆ wˆ2 X i wiΣηi − wˆµˆ tµˆ (4.4) Si σq est choisi suffisamment large, la gaussienne anisotrope obtenue décrit la distribution de l’ensemble des données apprises. L’Algorithme 3 présente le pseudo-code de l’étape de requête. 4.3 Généralisation Dans la partie précédente, nous avons présenté une version simplifiée de notre CovTree qui permet d’apprendre la distribution d’un ensemble de points d’un espace de dimension arbitraire. Pour une majorité d’applications de notre CovTree, cette définition reste trop limitée. Nous proposons dans cette section de la généraliser en utilisant deux domaines distincts : le domaine spatial S qui définit les distances entre les différents échantillons de l’espace et le domaine des attributs R qui associe chaque échantillon à une valeur. 4.3.1 Notations Soit un domaine spatial S ∈ R dS et un nuage de points P = {pi}i∈[[1,N]] de N échantillons. Nous allons considérer une correspondance f : S → R associant à chaque échantillon de position spatiale pi ∈ S, une valeur fi du domaine des attributs R ∈ R dR. Pour une meilleure compréhension, il peut être utile de considérer f comme une fonction. Néanmoins, notre structure ne requiert pas que la correspondance f soit connue explicitement, bien définie ou unique pour n’importe quel p ∈ S. L’association entre les p et les f est apprise à l’aide de notre approche à partir d’une base de données de paires d’échantillons (pi ,fi). Une telle représentation peut par exemple être utilisée pour représenter des images RGB associant à chaque pixel de l’image pi = (xi , yi) T une valeur couleur fi = (ri , gi , bi) T , des nuages de points 3D définis par leurs positions spatiales et normales pi = fi = (xi , yi , zi , nx i , n y i , nz i ) T , etc.4.3. GÉNÉRALISATION 65 (a) Population (pi , fi ) (b) Principe de notre CovTree généralisé f0 f5 f2 f1 f7 f6 f4 f3 f0 f5 f2 f1 f7 f6 f4 f3 {f1 f3 f6 f4 f7 { Figure 4.5: Gauche : Considérons une foule dont chaque individu possède une position spatiale pi définie dans le domaine spatial S et un attribut fi défini dans le domaine des attributs R. À l’aide de notre CovTree généralisé, nous apprenons la répartition des {fi} par rapport à leur position spatiale {pi} et à différentes échelles spatiales. Droite : Ainsi en considérant un sous-ensemble spatial de centre q ∈ S de taille σq ∈ R (représenté en Vert), notre structure de données permet d’estimer la distribution des attributs des individus qui sont compris dans ce voisinage en la modélisant par une gaussienne multivariée définie dans l’espace des attributs R. Cette dernière est définie par une moyenne µˆ ∈ R et une matrice de covariance Σˆ ∈ R × R. 4.3.2 CovTree généralisé Principe général Tout comme sa version simplifiée, la version généralisée de notre CovTree permet d’apprendre des distributions pour différentes échelles et de fournir pour tout voisinage requête une gaussienne anisotrope modélisant la distribution des données locales apprises comprise dans ce voisinage. Cette structure est définie par l’intermédiaire d’un domaine spatial S (utilisé pour définir le voisinage des échantillons) et d’un domaine des attributs R (utilisé pour définir les distributions). Ainsi, tout regroupement des échantillons et requête de voisinage sont effectués dans S alors que les distributions apprises et résultantes sont définies dans R. Cette différence étant difficile à appréhender, nous proposons une illustration du principe du CovTree généralisé ainsi que la distinction entre les deux domaines S et R en Figure 4.5 considérons une population d’individus possédant une position spatiale pi ∈ S (correspondant à leur position dans l’espace) et un attribut fi ∈ R associé (correspondant aux valeurs inscrites dans chaque individu). Ici, nous ne posons aucune condition sur le lien qui existe entre pi et fi . Par l’intermédiaire de notre CovTree généralisé, nous souhaitons analyser les variations des attributs associés à un sous-ensemble d’individus de cette foule. Cette distribution d’attributs sera modélisée par l’intermédiaire d’une gaussienne anisotrope.66 Applications S R Méthode de reconstruction Gaussien 1D Position des pixels Niveau de gris Moyenne (xi, yi) (gi) Gaussian 3D Position des pixels Valeur couleur Moyenne (xi, yi) (ri, gi, bi) Bilateral Position des pixels + Valeur couleur Valeur couleur Moyenne (xi, yi, ri, gi, bi) (ri, gi, bi) NLM patches autour du pixel Valeur couleur EAP Pxi,yi (ri, gi, bi) NLB Patches Patches MAP Pxi,yi Pxi,yi Completion de trous pyramidal Patches basse résolutions Patches hautes résolutions MAP PSS Point 3D Point 3D Moyenne  xi, yi, zi n x i , n y i , n z i   xi, yi, zi n x i , n y i , n z i  NLPSS Patches 3D Champs scalaire EAP Pxi,yi,zi vi NLB-PSS Patches 3D Patches 3D + champs scalaire MAP Pxi,yi,zi (Pxi,yi,zi , vi) Table 4.1: Notre CovTree est très flexible : Cette table montre comment définir les domaines spatiaux S et des attributs R ainsi que la méthode de reconstruction à utiliser.4.3. GÉNÉRALISATION 67 Les regroupements des individus (sous-ensembles) sont définis dans le domaine spatial S, c’est-à-dire en considérant uniquement les positions spatiales pi de chacun de ces individus. Ensuite, les distributions de ces différents regroupements sont estimées en considérant uniquement les attributs fi associés à chaque individu de ce sous-ensemble. Par conséquent, la gaussienne anisotrope résultante correspond uniquement aux variations dans l’espace des attributs R de ce sous-ensemble d’individus (et non de leur position spatiale pi). Notre CovTree généralisé permet donc d’apprendre de grandes bases de données de couples d’échantillons exemples (pi ,fi) et fournit pour tout voisinage spatial q ∈ S de rayon σq ∈ R la distribution des attributs associée à ces échantillons représentés par une gaussienne anisotrope définie dans R. Il est possible de retrouver la version simplifiée de notre CovTree en confondant les deux domaines spatiaux et des attributs : S = R. Problèmes de restauration simple Avant de présenter les modifications apportées par la version généralisée de notre CovTree, nous illustrons ici quelques problèmes de restauration simple qui peuvent être traités par notre structure : 1. Convolution gaussienne : Considérons une image à niveaux de gris bruitée u˜(x, y) = u(x, y)+n(x, y). Dans ce cas dS = 2 (correspondant aux deux coordonnées spatiales) et dR = 1 (correspondant au niveau de gris). En supposant l’image homogène, un a priori de la valeur ˜u(x, y) peut être estimé à partir des valeurs ˜u(x ′ , y′ ) d’un ensemble de voisins p = (x ′ , y′ ) proche du point requête q = (x, y). Dans ce cas, la convolution gaussienne peut être définie comme Estimation A Posteriori (EAP) de cet a priori. 2. Filtre Bilateral : Considérons désormais une image bruitée couleur ˜u(x, y) = u(x, y) + n(x, y). En définissant dS = 5 (correspondant aux deux coordonnées spatiales (x, y) plus trois canaux couleurs (r, g, b)) et dR = 3 (les trois canaux couleurs (r, g, b)). Cette fois l’estimation de la valeur débruitée obtenue est plus fine, en effet, les points (x, y) proches d’un contour pourront être rejetés grâce à l’information de couleur qui a été ajoutée au domaine spatial S. 3. Filtre Non-Local : Pour des images hautement texturées, la supposition d’image lisse des deux précédentes illustrations n’est plus valable. Dans ce cas, les filtres non locaux supposent que l’ensemble des patchs d’une image texturée appartiennent à une variété lisse de basse dimension. En prenant pi = fi comme l’ensemble de tout les patchs de l’image, un patch requête q peut être débruité par les NLB [LBM13] en calculant une gaussienne multivariée à partir d’un ensemble de patchs voisins {pj , pj ∈ N(q)} proches de la requête q. Cette distribution gaussienne est utilisée pour estimer le patch débruité via une Maximisation A Posteriori (MAP) Bayesienne. En complément des exemples précédents, nous présentons en Table 4.1 d’autres problèmes de restauration qui peuvent être modélisés par cette structure. 4.3.3 Algorithme généralisé Les principes sous-jacents et les différents explications proposées pour définir la version simplifiée de notre CovTree 4.2 restent toujours valables dans sa version généralisée. Ainsi,68 Algorithm 4: Construction de l’arbre généralisé Fonction ConstruireNœud(C ⊂ pi , σb ∈ R) Entrées: C un sous-ensemble de pi , σb l’échelle d’arrêt Sorties: η le nœud créé allouer un nouveau nœud η // Estimation des paramètres de la cellule ηd ← le vecteur associé à la plus grande valeur propre de cov(C) ηc ← mean pi∈Ck (pi) ηr ← max pi∈Ck kpi − ηck si ηr ≤ σb alors Marquer η comme feuille de l’arbre sinon // Répartition des points dans les deux sous-espaces Cgauche ← {pi ∈ Ck,(pi − ηc) tηd ≤ 0} Cdroit ← {pi ∈ Ck,(pi − ηc) tηd ≥ 0} // Création des deux sous-arbres ηgauche ← ConstruireNœud(Cgauche, σb) ηdroit ← ConstruireNœud(Cdroit , σb) fin retourner η fin nous présenterons uniquement dans cette section les différences entre les opérateurs simplifiés et les opérateurs généralisés. Pour que le lecteur appréhende bien ces différences, nous fournissons le pseudo-code généralisé de chaque étape dans leur intégralité. Construction Durant l’étape de construction, nous définissons un partitionnement de l’espace spatial S. Seules les positions spatiales pi des couples d’échantillons interviennent ici pour définir des cellules représentatives. En effet, comme nous l’avons illustré en Figure 4.5, notre structure de données fournit une analyse statistique des variations des attributs en fonction de regroupements spatiaux (et non en fonction des attributs). Par conséquent, le critère d’arrêt σb ∈ R correspond désormais à une échelle spatiale. L’Algorithme 4 fournit le pseudo-code de l’étape de construction généralisée. Apprentissage Désormais, l’apprentissage des distributions des échantillons est effectué sur le domaine des attributs. Comme l’arbre est défini en considérant le domaine spatial S, chaque couple d’échantillons (pi ,fi) explore l’arbre en fonction de sa position spatiale pi . Chaque échan-4.4. ANALYSE ET TEMPS DE CALCUL 69 Algorithm 5: Apprentissage des variations locales généralisé Fonction ApprendreVariations(p,f, η) Entrées: p un point à ajouter dans la structure, η un nœud de l’arbre // Calcul des poids w par approximation d’une gaussienne de variance ηr w ← φ  kpi−ηck ηr  // Mise à jour des statistiques de chaque nœud wη := wη + w w2η := w2η + w.w µη := µη + w.f Ση := Ση + w.f t f // Apprentissage des statistiques à une échelle inférieure si η n’est pas une feuille de l’arbre alors si (p − ηc) tηd ≤ 0 alors ApprendreVariations(p,f, ηgauche) sinon ApprendreVariations(p,f, ηdroit) fin fin fin tillon ajoute une contribution partielle pondérée de ces attributs fi . Le poids est défini par l’approximation de la gaussienne φ et dépend de la distance spatiale entre pi et le centre spatial de la cellule ηc. Lors de cette étape, chaque nœud de l’arbre est associé à une gaussienne anisotrope définie dans le domaine des attributs R, exprimant la distribution des attributs fi des échantillons qu’il contient. L’Algorithme 5 présente le pseudo-code de l’opérateur d’apprentissage. Requête Pour toute requête définie par une position spatiale q ∈ S et échelle spatiale σq ∈ R, notre CovTree fournit la distribution des attributs de l’ensemble des échantillons appris appartenant à ce voisinage spatial par l’intermédiaire d’une gaussienne multivariée définie dans R. Par conséquent la moyenne µˆ et la matrice de covariance Σˆ estimée par notre CovTree seront respectivement de dimensions dR et dR × dR. L’Algorithme 6 présente le pseudo-code de l’étape de requête généralisée. 4.4 Analyse et temps de calcul Dans cette section, nous analysons la complexité et les temps de calcul de chaque étape de notre CovTree. Cette analyse est effectuée indépendamment des applications possibles70 Algorithm 6: Interroger l’arbre Fonction InterrogerArbre(q, σq) Entrées: q ∈ R un point requête et σq une échelle de requête Sorties: la gaussienne anisotrope N (µˆ, Σˆ ) // Requête de l’arbre en commençant par la racine η0 {w, ˆ wˆ2, µ, Σ} ←CalculerVariations(q, σq, η0) // Estimation des paramètres de la gaussienne multivariée µˆ ← 1 wˆµ Σˆ ← wˆ 2−wˆ2 wˆ (Σ − wˆµˆ tµˆ) retourner N (µˆ, Σˆ ) fin Fonction CalculerVariations(q, σq, η) Entrées: q ∈ S un point requête, σq une échelle de requête et η un nœud de l’arbre Sorties: µ, Σ, ˆw et ˆw2 si ηr ≤ σq où η est une feuille de l’arbre alors // Calcul des poids w par approximation d’une gaussienne de variance σq w ← φ  kq−ηck σq  // Ajout des variations du nœud η wˆ := ˆw + w wˆ2 := ˆw2 + w 2 µ := µ + wµη Σ := Σ + wΣη sinon // Ajout des variations du nœud η en résultat si (q − ηc) tηd ≤ σq alors {w, ˆ wˆ2, µ, Σ} := {w, ˆ wˆ2, µ, Σ}+CalculerVariations(q, σq, ηgauche) sinon {w, ˆ wˆ2, µ, Σ} := {w, ˆ wˆ2, µ, Σ}+CalculerVariations(q, σq, ηdroit) fin fin retourner {w, ˆ wˆ2, µ, Σ} fin de notre structure de données. Par conséquent, seules les performances temps et mémoire pour estimer des gaussiennes anisotropes seront prises en compte ici. Pour une analyse plus détaillée concernant les performances qualitatives de notre CovTree, nous renvoyons le lecteur en Section 5.1.1 où une implémentation des filtrages collaboratifs réalisés par l’intermédiaire de notre structure est comparée aux méthodes de l’état de l’art.4.4. ANALYSE ET TEMPS DE CALCUL 71 4.4.1 Complexité Notre CovTree est basé sur les trois principaux opérateurs de construction, apprentissage et requête. Nous rappelons que S est un domaine spatial de dimension dS et R un domaine des valeurs de dimension dR. Nous proposons d’analyser la complexité temporelle de ces trois principales étapes : 1. Construction : Supposons que nous utilisons Nb points pour définir le partitionnement de l’espace. Durant cette étape de construction, chacun des Nb points apparaît une seule fois dans chaque nœud de l’arbre. À chaque division est effectuée une analyse en composantes principales pour déterminer la direction de plus grande variation. Cette dernière est accélérée par la méthode des puissances qui estime le vecteur propre principal avec une complexité O(2mdSNb) ou la constante m = 3. Ainsi, en considérant que notre arbre possède Kb nœuds l’étape de construction complète prend O(dSNblog(Kb)). 2. Apprentissage : Supposons que nous utilisons Nl échantillons pour apprendre les distributions des données (e. g. Nl >> Nb). Comme les Nl points parcourent l’arbre en partant de la racine jusqu’à atteindre une feuille en n’explorant qu’une seule des deux sous-branches de chaque nœud, la classification des points prend donc O(NldSlog(Kb)). Pour chaque nœud rencontré, les matrices de covariance et moyenne sont mises à jour ce qui requiert un temps de O(Nld 2 Rlog(Kb)). L’étape d’apprentissage totale requiert donc O(Nl(dS + d 2 R)log(Kb)). 3. Requête : Supposons que nous utilisons Nq points en requête de notre arbre. Tout d’abord nous effectuons la recherche des Kq plus proches nœuds demandant une complexité de O(NqdSKq). Ensuite, l’estimation des gaussiennes anisotropes né- cessite O(Nqd 2 RKq). Au total, notre étape de requête possède une complexité de O(Nq(dS + d 2 R)Kq). Le coût mémoire de notre structure dépend uniquement du nombre de nœuds créés lors de l’étape de construction. En effet chaque point appris lors de l’étape d’apprentissage ne fait que mettre à jour les données apprises par chaque nœud de l’arbre sans prendre plus de mémoire. Par conséquent, le coût total en mémoire de notre structure de données est O(Kbd 2 R). 4.4.2 Discussion Il est intéressant de noter que l’arbre peut être construit sur un ensemble d’échantillons différents de ceux de la base d’apprentissage. De toute évidence pour que cette propriété soit intéressante, il est nécessaire que l’ensemble utilisé pour la construction soit significatif par rapport à l’ensemble des échantillons de l’étape d’apprentissage. Outre l’accélération évidente qu’apporte la diminution du nombre d’échantillons, notre structure permet un apprentissage progressif des données. Il devient possible de raffiner la précision des distributions pour un budget mémoire constant en apprenant des données supplémentaires. Cette propriété est l’un des aspects principaux de notre CovTree. Nous pouvons donc apprendre la distribution d’échantillons issue de grandes bases de données tout en contrôlant la quantité mémoire nécessaire à son apprentissage. Cette propriété permet également de72 1 5.5 10 128 256 512 1024 Temps (s) Facteur de filtrage Figure 4.6: Temps de calcul (en seconde) pour estimer 5.105 requêtes (excluant les étapes de construction et d’apprentissage qui sont exécutées une seule fois) par notre CovTree pour différentes échelles σq. Le temps est mesuré en se contraignant à l’utilisation d’un seul cœur de calcul sur un PC avec un processeur 2.4 GHz Intel Xeon avec 12 GB de mémoire. pouvoir réapprendre et/ou mettre jour les distributions sans pour autant avoir besoin de reconstruire complètement l’arbre. Une fois les données apprises, l’arbre peut être réutilisé pour différentes applications sans avoir besoin de recommencer son apprentissage complet. Cette propriété, particulièrement utile dans les technologies mobiles qui possèdent des capacités limitées, est possible grâce à notre algorithme de requête. L’estimation d’une gaussienne anisotrope pour tout voisinage de centre q ∈ S et toute échelle σq ∈ R ne requiert pas de recalculer l’arbre. Nous présentons en Figure 4.6 la courbe des temps de calcul pour interroger notre CovTree pour différentes échelles σq. Il est intéressant de noter que le temps requis pour résoudre une requête reste peu affecté par la taille σq de la requête. Cet avantage est dû à l’apprentissage des distributions à différentes échelles qui permet de limiter le nombre de nœuds (et du coup la complexité de calcul) nécessaires pour évaluer une requête. Comme nous le montrons en Figure 4.7, pour des échelles σq faibles, le parcours de l’arbre est uniquement effectué en profondeur. Pour des échelles σq élevées, au lieu de parcourir un grand nombre de nœuds (et ainsi de renvoyer les variations d’un grand nombre de feuilles), notre démarche permet d’effectuer un parcours en largeur de l’arbre tout en limitant son exploration en profondeur. Le pire des cas correspond aux échelles σq de taille moyenne. En effet, la requête doit effectuer un parcours en largeur et en profondeur. Il en résulte un grand nombre de nœuds à explorer pour pouvoir estimer cette requête. 4.5 Limitations et possibles améliorations Dans ce chapitre, nous avons introduit une nouvelle structure de données capable de traiter une famille continue de gaussiennes multivariés locales. Notre structure est efficace pour apprendre de grandes quantités d’échantillons avec peu d’espace mémoire et permet une estimation rapide des requêtes. Le modèle extrait varie continûment sur un domaine de valeurs R quand le point requête varie sur un domaine spatial S (potentiellement différent). En plus de la position, différentes échelles peuvent être spécifiées à la requête permet-4.5. LIMITATIONS ET POSSIBLES AMÉLIORATIONS 73 Figure 4.7: Notre requête accélérée permet de limiter le nombre de nœuds du CovTree à explorer (en vert) pour estimer une distribution anisotrope locale. (a) Quand la requête possède une échelle σq large, seuls les nœuds supérieurs de l’arbre sont explorés. (b) Pour des valeurs plus petites de σq, l’arbre est parcouru plus en profondeur tout en limitant son parcours en largeur. tant de définir différents degrés de localité spatiale pour le modèle statistique extrait. Cette structure de données sera utilisée dans le chapitre suivant pour résoudre différents problèmes de restauration. Néanmoins, notre structure de données peut être améliorée. En effet, lors de la construction de l’arbre, nous définissons un partitionnement de l’espace par l’intermédiaire d’un bsp-tree. Par rapport à d’autres structures de partitionnement, cet type d’arbre permet de mieux gérer l’anisotropie des données. Néanmoins, il n’offre aucune garantie sur la conservation de la topologie des échantillons que nous souhaitons apprendre. Par conséquent, les sousespaces définis de cette manière ne sont pas obligatoirement les plus significatifs pour représenter la variété sous-jacente aux données. Il en résulte une augmentation significative du nombre de nœuds pour représenter les échantillons ainsi qu’une mauvaise estimation des matrices de covariances correspondantes. Ce genre de problème peut être résolu par l’utilisation de structures de partitionnement qui respectent la topologie des données. Dans tout ce chapitre, nous avons fait la supposition que l’ensemble des échantillons étaient connus à l’avance ou qu’une partie suffisamment significative était connue. Pour de nombreuses applications où les échantillons arrivent au fur et à mesure (par ex. traitement vidéo, internet), il est impossible de définir un sous-ensemble significatif sans connaître l’intégralité des données. Ce type de problèmes peut être géré par notre structure de données en modifiant l’étape de construction. Une solution possible serait de partitionner l’arbre progressivement en fonction des données qui sont fournies en entrée de l’arbre. Il faut donc distinguer trois cas : (a) quand le nombre d’échantillons d’un nœud est trop faible, il est nécessaire de garder en mémoire l’ensemble des échantillons (b) quand le nombre d’échantillons d’un nœud est trop élevé le sous-espace correspondant doit être divisé en deux (c) sinon il faut garder en mémoire la distribution des échantillons. Malheureusement, une telle solution ne permet pas de résoudre les problèmes concernant la propagation des données apprises d’un nœud à ses enfants.74 Une autre amélioration possible de notre structure de données serait de faire évoluer les données apprises avec le temps. Considérons le cas où un ensemble d’échantillons a besoin d’être appris à des temps {t0, t1, . . . , tn} (par ex. flux vidéo). Nous supposons que pour deux temps consécutifs tk, tk+1, les variations entre échantillons à apprendre sont faibles. Au temps tk+1, il est intéressant de conserver partiellement les données apprises au temps tk. Nous proposons d’introduire un facteur d’oubli 0 ≤ α ≤ 1. Ce dernier serait multiplié aux données apprises à chaque changement de temps pour permettre de simuler une persistance mémorielle. Pour α = 0, l’ensemble d’échantillons appris est oublié d’un temps à l’autre. Pour α = 1, l’ensemble des échantillons est gardé en mémoire indéfiniment. Pour toutes valeurs de α, les données sont oubliées au fur et à mesure et remplacées par les nouveaux échantillons. Une telle solution suppose que le partitionnement de l’espace spatial S n’a pas besoin d’être mis à jour, ce qui est rarement vérifiable en pratique.C h a p i t r e 5 Filtrage collaboratif généralisé Dans cette partie, nous présentons plusieurs applications de restauration d’images et de surfaces 3D basées sur notre structure de données, le CovTree, introduite au Chapitre 4. En Section 5.1, nous proposons d’appliquer notre CovTree au débruitage d’images pour calculer l’algorithme des Non Local Bayes. Cette section nous permet de valider les performances qualitatives de notre structure de données, en comparant les performances des Non Local Bayes obtenues par notre CovTree et leur implémentation originale [LBM13]. En Section 5.2, nous utilisons notre CovTree pour apprendre un grand ensemble de patchs non bruités de sorte à définir un a priori des images naturelles. Nous l’utilisons pour amé- liorer le débruitages des images et pour définir la reconstruction d’images échantillonnées aléatoirement. En Section 5.3, nous introduisons les problèmes et les idées principaux pour pouvoir étendre les filtres collaboratifs au cas des nuages de points 3D. Dans cette section, nous utilisons les outils développés au Chapitre 3, pour étendre les NLPSS au cas des Non Local Bayes. Nous présentons également comment définir une base de données 3D appliquée à l’augmentation de la résolution du nuage de points. 5.1 Débruitage d’images par filtre collaboratif Durant ces dernières années, les différentes évolutions des filtres non locaux ont permis de développer un nouveau type de filtre : les filtres collaboratifs. Contrairement aux approches par NL-Means qui débruitent les patchs de l’image sans se soucier d’une information globale, ce type de filtre effectue une analyse commune de l’information basée sur des regroupements de patchs similaires. Ces méthodes permettent d’extraire les détails communs d’un groupe tout en préservant les caractéristiques spécifiques du patch considéré. Nous allons particulièrement nous intéresser aux NLB (Non Local Bayes) [LBM13] car ils exploitent l’information commune par l’intermédiaire d’une analyse de la moyenne et de la covariance du groupe de patchs. Malheureusement, comme il est coûteux et difficile d’effectuer des regroupements directement dans l’espace des patchs, ces statistiques sont généralement approchées de sorte que le filtre reste calculable. La formulation des NLB étant particulièrement adaptée, nous proposons, dans cette section, de les accélérer par l’intermédiaire de notre CovTree généralisé (Section 4.3.3). Cette application nous permet d’étendre au cas des NLB certaines accélérations classiques des 7576 NL-Means (telle que la réduction de la dimensionnalité globale des patchs par une analyse en composantes principales [APG07, Tas08, Tas09]) et de fournir une analyse qualitative des performances de notre CovTree. 5.1.1 Non Local Bayes Principe Considérons un ensemble P = {fi} de patchs de dimension dP obtenu à partir d’un ensemble de patchs non bruités P˜ = {ri} corrompu par un bruit additif ni gaussien d’écart type σn : fi = ri + ni La probabilité du bruit qui est rajoutée à chaque patch correspond donc à une gaussienne isotrope d’écart type σn. Introduit par Lebrun et coll. [LBM13], les NLB débruitent un patch d’intérêt q ∈ R dP en utilisant une Maximisation A Posteriori (MAP) bayésienne. Cette maximisation, équivalente à projeter le patch q localement sur la variété de patchs non bruités, suppose que les variations probabilistes des patchs s’expriment par une gaussienne anisotrope N (µq , Σq) de moyenne µq et de matrice de covariance Σq. Ne pouvant être directement calculée sur un ensemble de patchs non bruités, cette gaussienne est estimée à partir des patchs bruités {fi}. Les NLB sont basés sur trois principaux opérateurs inspirés des travaux concernant les BM3D (Block Matching 3D) [DFKE07,DFKE08,DFKE09] : 1. Regroupement : un groupe de patchs N(q) similaires à q est formé en considérant une distance quadratique normalisée. Le voisinage est défini à la fois dans l’espace des patchs et dans l’espace spatial (distance pixelique entre les centres des patchs). Cette restriction permet de rendre la recherche des patchs similaires calculables pour de grandes images, car elle devient indépendante de la taille de l’image. De plus, pour ne pas être trop sensible aux patchs parasites, le groupe est généralement limité aux k plus proches patchs. 2. Débruitage collaboratif : les variations des patchs associés au groupe sont modélisées de manière probabiliste par une gaussienne anisotrope N (µq , Σq) qui est ensuite utilisée pour définir un estimateur par MAP du patch débruité. Lors de cette étape, chaque patch est débruité indépendamment les uns des autres. 3. Agrégation : chaque pixel de l’image, commun à plusieurs patchs, est associé à plusieurs valeurs débruitées. Une valeur débruitée finale est donc obtenue par une moyenne sur l’ensemble des valeurs débruitées. Débruitage itératif Afin d’améliorer les performances du débruitage et d’estimer une gaussienne anisotropique N (µq , Σq) non biaisée, ces trois étapes sont itérées deux fois. Lors de la première itération, le patch d’intérêt q est débruité en considérant l’ensemble des patchs bruités {fi}. La gaussienne anisotrope correspond donc aux variances de l’ensemble5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 77 des patchs bruités. Afin de débruiter conjointement les patchs du groupe tout en obtenant une modélisation des patchs non bruités, la matrice de covariance Σq est filtrée par un facteur σ 2 d correspondant à la variance du bruit estimée que contient l’image (σd ≈ σn) : Σ′ q = Σq − σ 2 d Id. L’estimateur de débruitage NLB(1) est défini pour tout patch bruité q associé à une moyenne µq et une matrice de covariance Σq calculée sur l’ensemble {fi} par : NLB(1)(q, µq , Σq) = µq + [Σq − σ 2 d Id]Σ−1 q (q − µq ) (5.1) Les patchs bruités {fi} sont donc débruités une première fois par : ˆr (1) i = NLB(1)(fi , µfi , Σfi ) (5.2) Durant la deuxième itération, le patch d’intérêt q est débruité en considérant l’ensemble des patchs {ˆr (1) i }. La gaussienne anisotrope décrit donc, désormais, les variations de l’ensemble des patchs débruités autour du patch d’intérêt débruité une première fois q (1) = NLB(1)(q, µq , Σq). L’estimateur de débruitage NLB(2) est défini pour tout patch bruité q associé à une moyenne µq(1) et une matrice de covariance Σq(1) calculée sur l’ensemble {ˆr (1) i } par : NLB(2)(q, µq(1) , Σq(1) ) = µq(1) + Σq(1) [Σq(1) + σ 2 d Id] −1 (q − µq(1) ) (5.3) Les patchs bruités {fi} sont donc débruités une deuxième fois par : ˆr (2) i = NLB(2)(fi , µˆr (1) i , Σˆr (1) i ) (5.4) Critère d’homogénéité Lors du calcul de l’Équation 5.1, certaines instabilités peuvent apparaître lorsque σd ≤ σn. Ces instabilités sont dues à l’estimation de la matrice de covariance débruitée Σ′ q . Il faut donc s’assurer par une Analyse en Composantes Principales (ACP) que l’ensemble des valeurs propres de Σ′ q restent positives ou nulles. Malheureusement, effectuer une ACP est d’autant plus coûteux que la dimension de l’espace des patchs dP est élevée. Les NLB proposent une résolution partielle de ce problème en introduisant un critère d’homogénéité. Dans le cas où l’ensemble des valeurs propres de Σ′ q sont négatives, les variations du groupe dans n’importe quelle direction correspondent uniquement à celles du bruit (cas d’un groupe de patchs homogène). Par conséquent, le meilleur estimateur pour le patch débruité est un patch moyen ¯r dont les valeurs sont toutes définies par : ∀k ∈ [[1, dP]], ¯r(k) = X fi∈N(q) X dP l=1 fi(l) (5.5) Le critère d’homogénéité permet de vérifier que le patch d’intérêt q n’est pas un patch homogène avant d’appliquer l’une des deux Équations 5.1 ou 5.3 accélérant ainsi le temps de calcul. En considérant un ensemble de m valeurs (correspondant à l’ensemble des valeurs contenues dans chaque patch du groupe), le critère d’homogénéité définit l’écart type des valeurs du groupe σh : σ 2 h = 1 m − 1   X fi∈N(q) X dP k=1 fi(k) 2 −   X fi∈N(q) X dP k=1 fi(k)   2   (5.6)78 Lorsque σh ≤ σn, le patch débruité est défini par l’Équation 5.5 sinon il reste débruité par les Équations 5.1 ou 5.3. Il est important de noter que ce critère permet de résoudre les problèmes d’instabilités quand l’ensemble des valeurs propres de Σ′ q sont négatives, mais ne permet pas résoudre les instabilités de calculs lorsqu’une partie des valeurs propres sont négatives. En pratique, ce problème reste peu visible, car il est atténué par l’étape d’Agrégation et l’utilisation de la double itération de l’algorithme. 5.1.2 Débruitage d’images par CovTree Adaptation des NLB Nous rappelons que le CovTree, tel qu’il a été introduit en Section 4.3.3, est une structure de données capable d’apprendre les variations d’un ensemble d’échantillons (pi ,fi) où pi est une position dans le domaine spatial S et fi est un attribut du domaine des attributs R. Le domaine spatial S est utilisé pour effectuer des regroupements entre les échantillons et le domaine des attributs R est utilisé pour analyser les variations des échantillons. Pour toute requête (q ∈ S, σq ∈ R), la structure retourne la gaussienne anisotrope N (µq,σq , Σq,σq ) de moyenne µq,σq ∈ R et de covariance Σq,σq ∈ R × R modélisant les variations des échantillons compris dans un voisinage spatial N(q, σq). La formulation des NLB étant particulièrement adaptée pour être calculée par notre CovTree, nous pouvons faire un parallèle entre les opérateurs du CovTree et les étapes des NLB. Par exemple, les opérateurs d’Apprentissage et de Requête peuvent être utilisés pour estimer une gaussienne anisotropique équivalente à celle estimée lors de l’étape de Débruitage collaboratif. Dans ce cas-là, le domaine des attributs R est défini par l’espace des patchs. Les attributs appris correspondent donc aux patchs de l’image. Pour pouvoir appliquer les deux itérations des NLB de manière équivalente, nous devons utiliser deux CovTree différents. La première est construite et apprise en utilisant l’ensemble des patchs de l’image bruités {fi} puis utilisée afin de débruiter l’ensemble des patchs par l’Équation 5.1 pour obtenir un premier débruitage des patchs {ˆr (1) i }. La deuxième est définie par rapport à l’ensemble des patchs débruités {ˆr (1) i } de sorte à pouvoir être utilisée par l’Équation 5.3 pour définir le patch débruité final. La gaussienne anisotropique N (µq,σq , Σq,σq ) estimée par notre CovTree dépend explicitement de la taille du voisinage σq considéré. Contrairement aux NLB originaux qui fixent définitivement cette taille pour accélérer le calcul du filtre, nous pouvons estimer diffé- rentes images débruitées en changeant la taille σq avec une influence négligeable sur le temps de calcul total. Critère de regroupement La distinction entre le domaine spatial S et celui des attributs R nous permet de définir différents critères de regroupement. En effet l’étape de Construction de notre CovTree permet d’effectuer des divisions dans S qui servent à rassembler les échantillons proches.5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 79 La Construction du CovTree est donc équivalente à l’étape de Regroupement. La définition des données spatiales utilisées par notre CovTree permet d’introduire différents types de regroupement N(q). Nous introduisons donc trois différents types de voisinage pour les NLB : 1. Voisinage global : nous définissons un domaine spatial S qui est confondu avec le domaine des attributs R par p = fi . Dans ce cas, le voisinage N(q) dépend uniquement de la similarité entre les patchs bruités fi et le patch requête q. Le domaine spatial S est donc de dimension dS = dP. 2. Voisinage local : afin de définir un voisinage équivalent à celui utilisé dans la version originale des NLB, nous proposons d’augmenter S avec les coordonnées pixéliques du centre du patch x = (xi , yi). Par conséquent, les pi doivent désormais être proches spatialement de q. Ce voisinage est défini dans un domaine spatial S de dimension dS = dP + 2. 3. Voisinage local compressé : l’idée ici est d’adapter la réduction de dimensionnalité des patchs proposée dans le cas des NL-Means [APG07,Tas08,Tas09] au NLB. Nous proposons donc de réduire les dP dimensions de l’espace des patchs aux l < dP dimensions principales par une ACP globale de l’ensemble des patchs bruités de l’image. Dans ce cas, S est de dimension dS = l + 2. Il est important de noter que seul le domaine spatial S est changé (et a fortiori les regroupements des différents patchs). En particulier, le domaine des attributs R ne change pas, ce qui permet de calculer les NLB avec différent types de voisinages sans avoir à modifier les équations originales. Critère d’homogénéité Tout comme dans la version originale des NLB, nous pouvons définir un critère homogène calculable à partir de la moyenne µq , la matrice de covariance Σq et des deux constantes de normalisation wq et w2q estimées par notre CovTree. Dans notre cas, l’écart type des valeurs du groupe σh est défini par : σ 2 q = 1 w2 qdP − w2q  (w 2 q − w2q)  Tr(Σq) + wq µq 2 2  − w 2 q dP X l=1 µq (l) !2   (5.7) De plus, l’ensemble des valeurs de patch moyen ¯r sont définies par ∀k ∈ [[1, dP]], ¯r(k) = 1 dP X dP l=1 µq (l) (5.8) Le critère d’homogénéité tel qu’il a été introduit dans les cas de NLB originaux reste inchangé dans le cas de l’utilisation de notre CovTree. 5.1.3 Analyse des paramètres Dans cette partie, nous proposons une analyse des différents paramètres de l’application du CovTree au débruitage d’images. Nous n’analysons pas ici l’influence de l’échelle d’arrêt de notre CovTree car il est lié uniquement à la taille mémoire finale utilisée par notre80 structure. Nous n’analysons pas non plus l’influence de la taille des patchs sur la reconstruction, nous renvoyons donc le lecteur vers une analyse plus approfondie de ce paramètre effectué par Lebrun et coll. [LBM13]. Facteur de filtrage Le facteur de filtrage σd correspond à la quantité de bruit que contiennent les patchs bruités. Nous présentons en Figure 5.1 les restaurations d’une image corrompue par un bruit gaussien d’écart type σn = 0.08 obtenu pour différentes valeurs de σd. Pour mieux analyser l’influence de ce paramètre sur la qualité de la restauration finale, une seule itération des NLB sans utiliser le critère d’homogénéité a été appliquée (Équation 5.1). Une analyse de la qualité de la restauration de l’image en fonction de l’évolution de ce paramètre n’est généralement pas effectuée car il est évident que la meilleure restauration sera obtenue pour des valeurs , σd ≈ σn. Dans notre cas, l’évolution de ce facteur nous permet d’analyser les performances qualitatives de notre CovTree. Pour des valeurs de σd trop faibles (cas σd = 0.04), la matrice de covariance Σ′ q = Σq − σ 2 d Id n’est pas assez débruitée. Ainsi, le patch débruité obtenu est proche du patch bruité passé en requête. Pour des valeurs de σd trop élevées (cas σd = 1.00), l’ensemble des valeurs propres associées à la matrice de covariance Σ′ q sont nulles. Le patch débruité obtenu est donc confondu avec la moyenne µq estimée par notre CovTree. Pour des valeurs de σd moyennes (cas σd = 0.08), la matrice de covariance Σ′ q est exploitée efficacement de sorte à extraire l’information commune à l’ensemble des patchs bruités du groupe. L’image résultante réussit à supprimer le bruit tout en préservant les détails fins. Il est important de noter que l’image moyenne (cas σd = 1.00) conserve les caractéristiques principales de l’image d’entrée. Ainsi, les différentes divisions effectuées par notre structure de données dans le domaine spatial S respectent la topologie des patchs. L’image moyenne réussit en effet à flouter les zones homogènes tout en préservant les contours principaux de l’image. Une grande majorité des détails de l’image ont néanmoins été supprimés, car le nombre de nœuds de notre structure reste limité. Contrairement à d’autres structures d’accélération telle que les Gaussian KD-Tree [AGDL09], notre structure utilise des matrices de covariance pour représenter les variations du groupe. Le pouvoir de représentation des covariances étant plus important que celui de simples moyennes, le nombre de noeuds né- cessaire pour apprendre l’information contenue dans l’image est inférieur. Cette propriété est illustrée dans le cas σd = 0.08 où des détails fins de l’image sont restaurés, confirmant que les gaussiennes anisotropes estimées lors des étapes d’Apprentissage et de Requête sont représentatives des variations de chaque groupe de patchs. Taille du voisinage spatial Par l’intermédiaire de notre CovTree, on peut estimer une gaussienne anisotrope pour différentes tailles de voisinage σq. Contrairement au NLB classique, il est possible d’estimer les gaussiennes anisotropes pour différentes échelles pour un coût équivalent (Section 4.4.2). Nous présentons en Figure 5.2, les restaurations de trois différentes images bruitées avec un bruit additif gaussien d’écart type σn = 0.5 obtenues pour différentes tailles σq.5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 81 Image originale Bruit d'écart type 0.08 Figure 5.1: Restauration d’une image corrompue par un bruit gaussien d’écart type 0.08 obtenu pour différents σd. Le choix idéal de σd est représenté en gras.82 Figure 5.2: Restaurations d’une image corrompue par un bruit additif gaussien d’écart type 0.2 obtenues pour différentes échelles d’estimation de la gaussienne anisotrope σq. Plus la taille σq est élevée plus la gaussienne anisotrope résultante est grossière. La taille idéale pour estimer la matrice de covariance est représentée en gras. Contrairement au NLB, la taille du voisinage peut être changée sans nécessiter de calculs supplémentaires. Pour des valeurs de σq trop larges (cas σq = 1.5), la gaussienne anisotrope estimée est trop grossière pour correctement modéliser la variété sous-jacente des patchs débruités.5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 83 Bruit écart type 0.08 Crit. global (147-D) Crit. local (147+2-D) Crit. compressé (6+2-D) PSNR 22.7 dB PSNR 27.6 dB PSNR 28.0 dB PSNR 28.4 dB Figure 5.3: Comparaison des restaurations obtenues pour différents critères de voisinage. La première ligne correspond aux débruitages obtenus et la deuxième à l’écart entre le débruitage et l’image originale. Par conséquent, l’image restaurée perd toute l’information haute fréquence qu’elle contient entraînant la création de zones floues. Pour des tailles σq faibles (cas σq = 0.5), il n’est pas possible d’extraire les caractéristiques communes à chaque groupe. Ainsi, la gaussienne anisotrope résultante permet de représenter uniquement les structures de bruit locales ce qui se traduit par l’apparition d’un bruit de haute fréquence sur les images restaurées. La taille de voisinage idéale (cas σq = 0.6) doit être choisie par rapport à la quantité de bruit contenue dans les patchs bruités. Une telle taille permet de limiter l’apparition des hautes fréquences tout en préservant les caractéristiques de l’image. Choix du voisinage Nous présentons en Figure 5.3 différentes restaurations d’une image corrompue par un bruit additif gaussien d’écart type 0.08 pour différents types de voisinages. En utilisant un critère global, les regroupements de patchs se font uniquement en considérant une distance calculée dans l’espace des patchs. L’ensemble des patchs appris étant bruité, cette distance est très dépendante de la quantité de bruit dans les patchs. Ainsi, les groupes de patchs contiennent plus facilement des patchs parasites influençant négativement la qualité de la restauration finale. Un critère global peut donc être difficilement utilisé dans le cas de patchs bruités. Pour résoudre ce problème, il suffit d’augmenter de deux dimensions le domaine spatial correspondant à la position pixelique du centre du patch. Ce critère local permet de limiter84 30.7 31 31.3 1 2 4 8 16 32 64 PSNR(dB) Dimensionnalité spatiale ( ) Figure 5.4: Évolution du PSNR du débruitage de 20 images par notre CovTree-NLB en fonction de la réduction par ACP de la dimensionnalité du domaine spatial. La courbe moyenne est représentée en rouge et l’écart type des données centrées en gris. Les courbes de PSNR de chaque images présentent des formes similaires et montrent un pic autour des valeurs dS = 4. le nombre de points parasites présents dans un groupe. L’image restaurée est donc d’une meilleure qualité. Dans la version originale des NLB, ce critère est également utilisé afin d’accélérer le calcul du filtre en rendant indépendante de la taille de l’image l’étape de Regroupement. Comme nous le présentons en Figure 5.4, le critère compressé qui effectue une réduction de dimensionnalité par ACP appliqué sur le domaine S permet non seulement d’accélérer la recherche, mais de produire également de meilleurs résultats. Ce phénomène peut être expliqué par le fait que les valeurs propres les plus petites contiennent principalement du bruit. En gardant uniquement les valeurs propres les plus élevées, la distance entre les patchs devient donc moins sensible au bruit permettant de définir des regroupements de patchs plus pertinents. Schéma itératif Nous présentons en Figure 5.5, trois images restaurées obtenues après la première itération (Équation 5.1 puis la deuxième itération (Équation 5.3) des NLB. Les images sont corrompues avec un bruit additif gaussien d’écart type σn = 0.2. La première itération des NLB permet de récupérer les caractéristiques principales de l’image. Étant calculée uniquement sur l’ensemble des patchs bruités, l’estimation des gaussiennes anisotropes reste néanmoins biaisée entraînant l’apparition d’artefacts de hautes fréquences et de changements de teinte de certaines zones de l’image. Appliquer une deuxième itération calculée sur l’ensemble des patchs débruités permet de corriger ces problèmes. Désormais les variations et les regroupements sont calculés en considérant une distance entre les patchs qui n’est plus biaisée par le bruit. Les regroupements formés sont donc plus pertinents et permettent de mieux faire ressortir les détails communs à chaque groupe de patchs. Les images résultantes obtenues préservent mieux les caractéristiques.5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 85 Première itération des NLB Deuxième itération des NLB PSNR 24.1 dB PSNR 24.6 dB PSNR 29.2 dB PSNR 29.6 dB PSNR 29.0 dB PSNR 29.6 dB Figure 5.5: Images débruitées obtenues après la première et la deuxième itération de notre CovTree-NLB à partir de trois images corrompues par un bruit additif gaussien d’écart type 0.2. Afin de mieux comparer les performances, nous fournissons des agrandissements des trois images sur les deux lignes centrales. Néanmoins, lorsque l’information d’un groupe est trop filtrée lors de la première itération, il devient difficile de récupérer cette information lors de la deuxième itération. Inversement, si le bruit présent dans le groupe n’est pas totalement éliminé alors il pourra être considéré comme une caractéristique principale du groupe diminuant ainsi la qualité de la restauration.86Original NL-Means NLB Original NLB par CovTree Bruit PSNR 14.7 dB PSNR 14.6 dB PSNR 14.8 dB PSNR 27.9 dB PSNR 23.8 dB PSNR 28.8 dB PSNR 29.0 dB PSNR 24.7 dB PSNR 29.5 dB PSNR 29.2 dB PSNR 24.6 dB PSNR 29.6 dB Figure 5.6: Résultats de restaurations obtenus pour différents algorithmes de débruitages non locaux : les NL-Means [GO12], les NLB originaux [LBM13] et notre CovTree-NLB. Un agrandissement de ces images est proposé en Figure 5.7 5.1.4 Résultats Nous présentons en Figure 5.6 les résultats obtenus pour trois méthodes : les NL-Means calculées par l’approche de Gastal et coll. [GO12], les NLB originaux [LBM13] et notre CovTree-NLB. Ces méthodes sont appliquées à trois différentes images corrompues par un bruit additif gaussien d’écart type 0.2. Pour mieux percevoir les différences entre les différentes méthodes, nous présentons en Figure 5.7 des vues détaillées de ces différents résultats. Les résultats du CovTree sont obtenus sans utiliser le critère d’homogénéité et en réduisant la dimensionnalité des patchs aux 6 principales dimensions.5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 87 Original NL-Means NLB Original NLB par CovTree PSNR 14.7 dB PSNR 14.6 dB PSNR 14.8 dB PSNR 27.9 dB PSNR 23.8 dB PSNR 28.8 dB PSNR 29.0 dB PSNR 24.7 dB PSNR 29.5 dB PSNR 29.2 dB PSNR 24.6 dB PSNR 29.6 dB Bruit Figure 5.7: Comparaison de différents algorithmes non locaux : les NL-Means [GO12], les NLB originaux [LBM13] et notre CovTree-NLB.88 Dans le cas des NL-Means, les pixels de l’image sont débruités à partir d’une combinaison de valeurs bruitées. Le poids de chaque élément est calculé en fonction d’une mesure de similarité évaluée à partir d’un voisinage autour du pixel. Malheureusement, ce voisinage est défini à partir de l’image bruitée. Par conséquent, la mesure de similarité aura tendance à rechercher des pixels dans l’image qui possèdent des voisinages qui sont bruités de la même manière que le patch d’intérêt. Ce phénomène reste peu visible pour des écarts types σn faibles, mais se traduit par l’apparition d’un bruit résiduel haute fréquence pour des valeurs de σn élevées. Ce problème est particulièrement visible en Figure 5.7, où il entraine l’apparition d’imprécisions et la modification des contours de l’image. Ce problème est corrigé dans les NLB originaux en analysant l’information commune à un groupe de patchs similaires. À la différence des NL-Means, le filtrage est effectué collaborativement. Les caractéristiques principales communes à l’ensemble des patchs du groupe sont donc extraites indépendamment du bruit puis utilisées pour filtrer le patch. Les NLB permettent donc de mieux préserver les détails principaux contenus dans l’image sans introduire de bruit haute fréquence. Notre CovTree-NLB permet d’obtenir des résultats légèrement supérieurs aux NLB originaux. Nous pouvons expliquer cette différence par l’utilisation du critère de voisinage local compressé. Il permet de former des groupes de patchs similaires moins dépendants du bruit. De plus, dans la formulation originale des NLB, la moyenne et la covariance sont estimées avec un poids constant à partir d’une combinaison des k plus proches voisins. Dans notre cas, la combinaison est pondérée en utilisant un noyau gaussien qui limite l’influence des patchs parasites. En effectuant une comparaison plus détaillée, nous pouvons remarquer que les NLB originaux ont tendance à créer des zones régulières. Ce problème est dû à l’utilisation du critère homogénéité qui a tendance à uniformiser l’ensemble des valeurs du patch. Comme notre CovTree-NLB n’utilise pas le critère d’homogénéité, le patch est remplacé dans notre cas par la moyenne estimée durant la phase de requête de notre CovTree. Comme nous l’avons vu précédemment, la moyenne estimée par notre structure permet de bien préserver les caractéristiques principales. Elle remplace donc les zones régulières qui provoquent un phénomène de quantification par des variations lisses entre les différentes zones. Pour conclure, les deux implémentations des NLB produisent des résultats globalement équivalents. Ce constat nous permet donc d’affirmer que notre CovTree est correctement défini pour estimer la moyenne et la covariance d’un ensemble d’échantillons pour diffé- rentes requêtes qui peuvent être utilisées dans des approches telles que les NLB. 5.2 Restauration par dictionnaires Une propriété intéressante de notre CovTree est qu’il peut être utilisé pour apprendre les variations à différentes échelles de grandes bases d’échantillons en utilisant une quantité de mémoire limitée. Nous proposons d’exploiter ce caractère compressif afin de résoudre deux applications : le débruitage par dictionnaire et la reconstruction d’images échantillonnées aléatoirement.5.2. RESTAURATION PAR DICTIONNAIRES 89 Figure 5.8: Échantillons de la base de données de façades parisiennes comprenant plus de 120 images (soit plus de 108 patchs). 5.2.1 Principe général Avec la démocratisation des capteurs numériques et la facilité d’accès aux réseaux de communication, il est devenu facile aujourd’hui de récupérer et/ou partager de l’information. Malgré la multiplication de ces données, il existe encore peu de moyens réussissant à exploiter cette grande quantité d’informations et d’en extraire des caractéristiques utiles. Pourtant, l’utilisation d’une telle connaissance pourrait être particulièrement utile dans des domaines tels que la restauration. Durant ces dernières années, les méthodes de restauration des images ont proposé des approches de plus en plus performantes pour réussir à récupérer l’information contenue dans des images corrompues. Néanmoins, les performances de ces méthodes resteront toujours limitées du fait que les données sont trop détériorées ou trop rares pour être récupérées. L’utilisation d’une analyse de l’information commune à de grands ensembles d’images pourrait donc permettre de résoudre ce problème tout en améliorant la qualité de la restauration. Cette idée est confirmée dans [LN11] où l’utilisation de grandes bases d’images est proposée comme un moyen d’apprendre l’a priori sous-jacent aux patchs d’images naturelles. Ce genre d’approche (appelée shotgun NLM [LCBM12]) a été utilisé pour estimer les limites fondamentales des méthodes de débruitage non locales. Néanmoins, aucune proposition n’a été faite afin de rendre ce genre de méthodes calculables dans le cas d’applications réelles. Une idée similaire a ensuite été proposée par [ZW11]. Elle définit un apprentissage sur une large base de données par l’intermédiaire d’une approche similaire à celle des PLE [YSM12]. Malheureusement, une telle approche nécessite plusieurs jours pour apprendre l’a priori sous-jacent. Nous proposons donc d’utiliser notre CovTree généralisé afin d’apprendre l’a priori sousjacent aux patchs des images naturelles rapidement et en utilisant une quantité de mémoire limitée. Une fois encore, cet avantage est possible, car la quantité de mémoire utilisée par90 notre structure de données dépend uniquement de la précision de l’information que l’on souhaite apprendre et non du nombre d’échantillons à apprendre. Dans toute cette section, nous considérons un ensemble de 108 patchs non bruités de dimension 7×7 extraits d’une base de plus de 120 images de façades parisiennes. Ces patchs seront utilisés lors de l’étape d’Apprentissage de sorte à pouvoir définir une approximation de l’a priori sous-jacent de l’ensemble des patchs appartenant aux images naturelles. Nous présentons en Figure 5.8 un sous-ensemble d’images appartenant à cette base de données. En terme de performance, un tel apprentissage nécessite environ 5 heures de calcul sur un PC possédant un processeur 2.4 GHz Intel Xeon et utilise 8GB de RAM pour retenir l’ensemble de la structure de données. En comparaison, ce temps de calcul est bien plus rapide que les temps de calcul reportés dans [LN11, ZW11] alors que la quantité d’échantillons apprise par notre structure est largement supérieure. 5.2.2 Débruitage d’images Principe Les démarches par NLB restaurent l’image en utilisant uniquement un ensemble de patchs bruités. Par conséquent, la gaussienne anisotrope utilisée pour modéliser l’a priori sousjacent représente les variations des patchs bruités. Les NLB résolvent ce problème en débruitant la matrice de covariance d’un facteur σd et en itérant deux fois leurs différentes étapes. Néanmoins, l’estimation de la gaussienne reste limitée. Dans cette section nous proposons de définir une approche similaire à [LCBM12]. Nous définissons un algorithme de débruitage, le Shotgun NLB, qui utilise un a priori appris sur une grande base de données à partir notre CovTree. Cette idée a deux principaux avantages : nous pouvons augmenter le nombre de patchs appris (par rapport aux NLB classiques) et les données utilisées ne sont pas dégradées par du bruit, permettant ainsi d’augmenter la précision de la gaussienne anisotropique estimée. En pratique, nous construisons notre arbre en considérant un critère de voisinage global (sans coordonnées pixeliques) afin de définir les cellules dans le domaine spatial S. Ensuite, nous apprenons le modèle gaussien de chaque cellule à partir de l’ensemble des patchs non bruités provenant de la base de données. Finalement, la matrice de covariance Σq et le vecteur moyen µq sont estimés à partir d’un patch bruité q avec un rayon σq proche de l’écart type du bruit du patch. Contrairement aux NLB classiques, les gaussiens anisotropes N (µq , Σq) estimées par la structure sont non bruitées. Par conséquent, nous appliquons directement l’Équation 5.3 sans avoir besoin de débruiter la matrice de covariance. Résultats En Figure 5.9, nous présentons une comparaison d’images filtrées par les NLB originaux, les CovTree-NLB et notre Shotgun NLB. Les résultats sont obtenus à partir d’images corrompues par un bruit gaussien additif d’écart type 0.08. Dans cette partie, les CovTree-NLB sont calculés à partir du critère de voisinage local compressé aux 6 principales dimen-5.2. RESTAURATION PAR DICTIONNAIRES 91 Bruit écart type 0.08 NLB Original (147+2-D) NLB CovTree (147+2-D) Shotgun NLB (147-D) PSNR 22.4 dB PSNR 30.2 dB PSNR 30.0 dB PSNR 31.1 dB Figure 5.9: Comparaison des images débruitées obtenues pour différentes versions des NLB : le NLB original, notre CovTree NLB et notre Shotgun NLB. La deuxième ligne présente des agrandissements des résultats obtenus sur la première ligne. sions sans utiliser de critère d’homogénéité. Notre Shotgun-NLB est évalué avec une seule itération. Pour mieux illustrer nos propos, nous allons baser nos explications sur les agrandissements proposés en Figure 5.9 représentant un mur de briques. Ce cas de restauration est particulièrement difficile, car les détails fins et le bruit de l’image sont confondus. La gaussienne anisotrope résultante de ce groupe de patchs sera donc principalement composée du bruit du groupe. En effet, la distance utilisée pour former les groupes de patch aura tendance à rassembler les patchs par rapport à la similarité de leur bruit respectif plutôt que de l’information réelle qu’ils contiennent. Les groupes ainsi formés contiendront donc un grand nombre de patchs parasites qui perturberont l’extraction des caractéristiques communes. La légère perte de performance de notre CovTree-NLB par rapport aux NLB originaux est due à ce problème. Les NLB originaux utilisent le critère d’homogénéité pour éviter d’exacerber les structures de bruits locales. Il permet d’harmoniser l’ensemble des valeurs quand il est difficile de faire la distinction entre l’information contenue dans le groupe et le bruit. Le Shotgun-NLB est particulièrement efficace pour résoudre ce genre de cas. En effet, il permet d’estimer, en toutes circonstances, des gaussiennes anisotropes représentatives des variations des patchs non bruités. Pour ce faire, il utilise l’information commune de la base de patchs non bruités pour définir un a priori qui approche celui des patchs des images naturelles. Cet a priori peut donc contenir une information sur les caractéristiques fines des patchs qui se retrouvaient précédemment confondues dans le bruit de l’image. Le ShotgunNLB permet de restaurer des détails fins de l’image que les filtres classiques ne sont pas capables de retrouver. De plus amples expérimentations restent néanmoins nécessaires92 pour déterminer si la restauration obtenue est proche de la limite fondamentale présentée par [LN11]. 5.2.3 Reconstruction d’image échantillonnée aléatoirement Principe Dans cette section, nous proposons de reconstruire une image à partir d’un sous-ensemble aléatoire de ces pixels. Comme le proposent entre autres les PLE [YSM12], nous proposons d’utiliser l’a priori sous-jacent aux patchs des images naturelles qui a été appris par l’intermédiaire de notre CovTree sur une large base de données pour compléter l’information manquante. Considérons un patch q˜ échantillonné aléatoirement à partir d’un patch original q par un opérateur q˜ = Sq. Ici, l’opérateur S dépend de la position spatiale de q. De manière équivalente aux filtres NLB, nous allons considérer ici que les patchs de l’image peuvent être modélisés localement par une gaussienne anisotrope dont la moyenne µq et la covariance Σq ont été estimées à partir d’un dictionnaire local. Par conséquent, nous pouvons définir le patch reconstruit qˆ comme une MAP bayésienne : qˆ = (ΣqS HS + σ 2 2 Id) −1 (ΣqS Hq˜ + σ 2 2 µq ) (5.9) Dans la minimisation précédente, la gaussienne anisotrope N (µq , Σq) est estimée autour du patch complet original q. Ce patch étant bien évidemment inconnu, nous utilisons une approche itérative basée sur trois étapes pour approcher cette gaussienne : 1. Estimation : le patch qˆt−1 reconstruit à l’itération précédente t − 1 est utilisé en requête de notre CovTree afin de définir une approximation de l’a priori statistique local autour de q représentée par une gaussienne anisotrope N (µqˆt−1 , Σqˆt−1 ). 2. Reconstruction : le patch qˆt est reconstruit à l’itération t à partir d’une MAP bayésienne et de la gaussienne anisotrope N (µqˆt−1 , Σqˆt−1 ) par : qˆt = (Σqˆt−1S HS + σ 2 2 Id) −1 (Σqˆt−1S Hq˜ + σ 2 2 µqˆt−1 ) (5.10) 3. Agrégation : tout comme pour les NLB, un pixel de l’image appartient à plusieurs patchs de l’image. Par conséquent, le patch qˆt et l’image sont estimés à l’itération t par une moyenne des valeurs des pixels reconstruits. En pratique, nous initialisons la reconstruction à partir d’une estimation initiale qˆ0 du patch complet effectué en utilisant une interpolation cubique basée sur une triangulation de Delaunay des pixels connus. De plus, pour obtenir une meilleure reconstruction de l’image, lors de l’étape d’Estimation nous utilisons des échelles de filtrage σqˆ,t = α tσqˆ,0 de plus en plus fines à partir d’une échelle grossière σqˆ,0 et d’un facteur d’échelle α ∈ [0, 1]. Résultats Nous présentons en Figure 5.9 la restauration obtenue à partir d’une image où seulement 20% des pixels échantillonnés aléatoirement ont été conservés. Notre approche est initia-5.2. RESTAURATION PAR DICTIONNAIRES 93 Original 20% pixels originaux Reconstruction cubique Notre reconstruction PSNR 24.9 dB PSNR 27.2 dB Figure 5.10: Résultat de la reconstruction d’une image dont 20% des pixels échantillonnés aléatoirement ont été retenus. Notre approche est initialisée à partir d’une reconstruction cubique définie sur la triangulation de Delaunay des pixels connus. lisée par une première interpolation cubique définie sur la triangulation de Delaunay des pixels connus pour des valeurs α = 0.8 et σqˆ,0 = 0.65. Comme nous l’avons expliqué précédemment, nous avons théoriquement besoin de connaître le patch restauré pour pouvoir définir un modèle local des patchs. Pour ré- soudre ce problème, nous avons introduit une approche itérative qui évalue à chaque étape une reconstruction de plus en plus fine. Ce schéma itératif est initialisé à partir d’une restauration grossière de l’image. Il est important de comprendre que tout le cœur de notre problème de restauration réside dans l’estimation d’une gaussienne anisotrope correcte. C’est grâce à elle que l’information manquante est comblée. Par conséquent, plus la requête sera proche du patch original meilleure sera la restauration. Pour éviter de bloquer les itérations dans des minimums locaux, nous utilisons des échelles de requêtes σqˆ,t décroissantes. Cette idée nous permet de récupérer des détails de l’image qui n’était pas nécessairement présents dans l’approximation originale. Ce phénomène est parfaitement illustré en Figure 5.10 par la restauration des briques ou des carreaux de la porte de la maison. Malheureusement, une telle solution ne permet pas de résoudre toutes les ambiguïtés. Les patchs restaurés peuvent parfois être assez éloignés de leur version originale. Néanmoins, ce problème n’est pas forcément choquant visuellement. 5.2.4 Limitations et possibles améliorations Dans cette section, nous avons utilisé notre CovTree pour apprendre rapidement la distribution d’une grande base de données de patchs issues d’images naturelles et avec une94 quantité de mémoire limitée. Nous avons démontré que ce modèle peut être utilisé effi- cacement pour résoudre des problèmes de restauration par MAP bayésienne tels que le débruitage ou la reconstruction d’images. Nous avons fait la supposition que l’a priori sous-jacent est appris sur une base de patchs non bruités représentatifs des patchs à restaurer. Cette hypothèse n’est pas toujours vérifiée en pratique. En effet, l’apprentissage est effectué ici sur un ensemble de patchs extraits d’images différentes. Ces images ne sont pas nécessairement acquises avec des appareils ou dans des conditions équivalentes. Par conséquent, des changements de teintes ou de contraste peuvent limiter la qualité de l’apprentissage. Ce problème peut bien évidemment être résolu en augmentant la quantité d’images apprises. Mis à part l’augmentation de la quantité de temps nécessaire à l’apprentissage, les statistiques apprises pourraient être corrompues par l’introduction de patchs aberrants. Pour résoudre ce problème, une première solution consisterait à apprendre les statistiques indépendamment des changements de contraste et/ou de teintes. Cette solution reviendrait en quelque sorte à normaliser les patchs avant de les apprendre. Notre CovTree devrait donc être modifié pour gérer indépendamment la moyenne et les covariances. Plus simplement, nous pourrions utiliser l’information contenue dans les patchs corrompus quand celles de l’a priori ne sont pas suffisante. Cette idée est équivalente à celle de la dégéné- rescence du noyau non local introduit en Section 3.2.4 pour les NLPSS. 5.3 Restauration de surface 3D Notre CovTree peut être utilisé pour résoudre des problèmes de restauration d’images tels que le débruitage ou la reconstruction. Nous proposons d’étendre ces différentes applications au cas des nuages de points 3D. Pour cela, nous utilisons les principes et outils introduits pour les NLPSS ainsi que le CovTree dans sa version étendue. Nous présentons uniquement les idées et les problèmes sous-jacents à la mise en œuvre de ces applications. 5.3.1 Positionnement du problème Nous rappelons ici les notations introduites au Chapitre 3. Soit X = (xi , ni) un nuage de point 3D extrait à partir d’une surface S inconnue, où xi ∈ R 3 est la position d’un point et ni ∈ R 3 est la normale qui lui est associée. Pour tout point x ∈ R 3 , l’opérateur PSS Πt projette x sur la surface S t définie à l’échelle t. Nous appelons respectivement Πt (x), f(x) et n(x), la projection de x sur S t , la distance implicite et la normale associée. En appliquant Πt0 à une échelle t0 large, nous obtenons une surface grossière S t0 et un champ scalaire résiduel bruité m(xi) défini uniquement pour les points du nuage xi ∈ X (Section 3.2.2). De manière générale, adapter les méthodes restaurations MAP non locales pose principalement deux contraintes : 1. Tout d’abord, elles nécessitent la définition d’un signal corrompu et d’un descripteur pour définir la mesure de similarité entre deux échantillons. En traitement des images (et en particulier dans le cas des filtres collaboratifs), c’est le patch qui5.3. RESTAURATION DE SURFACE 3D 95 Figure 5.11: Reconstruction de surface obtenue à partir de notre opérateur NLB-PSS. possède le double rôle de descripteur et de signal à débruiter. Dans le cas des NLPSS, le signal est défini par le champ scalaire résiduel bruité m(xi) (uniquement pour tout xi ∈ X ) et le descripteur par un patch de surface 3D (Section 3.2.3). 1 2. Ensuite, les formulations MAP (par ex. l’Équation 5.1) nécessitent de connaître le signal corrompu en tout point du domaine. En effet, elles peuvent être vues généralement comme une projection d’un échantillon corrompu sur une variété locale (Section 5.1.1). Leur formulation fait donc explicitement intervenir le signal corrompu. Un tel problème ne se pose pas nécessairement dans le cas de formulations EAP (par ex. l’Équation des NLPSS). En conclusion, tout l’enjeu de l’adaptation des restaurations MAP au cas de surface 3D sera dans la définition d’une valeur du signal corrompue pour tout point de l’espace x ∈ R 3 . 5.3.2 Surface de points par NLB Nous proposons maintenant de définir un opérateur NLB-PSS qui étend les NLPSS au cas des NLB. Dans le cas des nuages de points 3D, il est difficile de définir un signal bruité pour tout x ∈ R 3 . Dans les NLPSS, ce problème a été résolu en utilisant le champ scalaire résiduel bruité m(pi) qui est uniquement défini pour les points du nuage xi ∈ X . Pour pouvoir définir un patch de surface 3D, ce signal a été approché par un opérateur PSS Πt1 à une échelle t1. Πt1 permet de définir une surface S t1 qui approxime finement X . Le patch de surface 3D peut donc être considéré comme une approximation peu filtrée du signal bruité. Il peut donc être débruité par l’Équation 5.1. Nous définissons l’opérateur NLB-PSS ΠNLB pour tout x ∈ R 3 par : ΠNLB(x) = x − fNLB(x)n t0 (x) (5.11) 1. Ces deux notions sont intimement liées aux deux domaines des attributs R et spatial S introduit dans la version généralisée de notre CovTree. R correspond au signal à débruiter et S aux descripteurs.96 où fNLB(x) correspond à la valeur centrale du patch de surface débruitée définie à partir du patch de surface bruité Px par l’Équation 5.3. Pour les NLB-PSS, nous n’effectuons aucune étape d’agrégation En effet, contrairement aux patchs définis en traitement des images, les patchs de surface ne possèdent aucunes valeurs en commun. En pratique, le NLB-PSS est accéléré par notre CovTree. Nous le construisons et l’apprenons en considérant l’ensemble des patchs 2 Pxi associé à chaque point xi ∈ X . Une requête de notre arbre est donc définie par un patch de surface Px et un rayon de requête σx ∈ R. Nous présentons en Figure 5.11 les premiers résultats des NLB-PSS. 5.3.3 Restauration de surface par dictionnaire Comme nous l’avons proposé dans le cas des images, nous pouvons apprendre les variations d’un ensemble de patchs de surface non bruités afin de définir un a priori des surfaces 3D. Il peut être utilisé pour des applications telles que le débruitage et la reconstruction de surface. Problèmes Dans les NLPSS, les patchs de surface (Section 3.2.3) sont définis par rapport à une surface grossière S t0 (utilisée pour définir les valeurs du patch) et à une largeur de patchs (employée pour estimer l’orientation du patch). Malheureusement ces deux paramètres sont dépendants de la résolution du nuage de points considérée. Par conséquent, un nuage acquis à différentes résolutions ne produira pas des ensembles de patchs qui contiennent des informations équivalentes. Dans le cas de grands ensembles de nuages de points, ce problème est d’autant plus présent que les nuages ne sont pas acquis par le même capteur. Pour résoudre ce problème, nous proposons d’extraire les patchs du nuage à différentes échelles. La base de données ainsi constituée sera donc moins dépendante des problèmes d’acquisition. Plus d’expérimentations sont néanmoins nécessaires pour valider cette hypothèse. Densification de nuages de points 3D L’apprentissage de grand ensemble de patchs est particulièrement utile pour augmenter la résolution d’un nuage de points. Pour pouvoir être défini de manière équivalente aux problèmes de reconstruction d’image échantillonnée aléatoirement, nous proposons d’introduire un patch de surface incomplet P˜ x, pour tout x ∈ R 3 , en projetant les points xj ∈ N(x) ⊂ X sur le plan du patch (Figure 5.12). Une discrétisation du plan permet de définir les valeurs du patch ainsi qu’un opérateur d’échantillonnage S. Les valeurs sont obtenues par une combinaison pondérée des m(xj ) et l’opérateur d’échantillonnage comme la somme des poids reçus dans les cases correspondantes. 2. Pour tout point xi ∈ X , la valeur centrale du patch correspond à la valeur du signal bruité m(xi). Par conséquent, chaque xi ∈ X est associé à un patch amélioré P ′ xi . En pratique, notre arbre est donc construit par rapport à l’ensemble des patchs approchés {Pxi } et appris sur l’ensemble des patchs améliorés {P ′ xi }.5.3. RESTAURATION DE SURFACE 3D 97 0.8 0.6 0.8 0.2 0.7 0.2 0.8 0.4 0.8 S = xj Figure 5.12: Définition d’un patch de surface incomplet. Les points xj sont projetés sur le plan du patch. À partir d’une discrétisation du plan, nous obtenons les valeurs du patch et l’opérateur d’échantillonnage S. Par conséquent, les patchs incomplets peuvent être reconstruits en considérant une approche similaire à celle proposée en Section 5.2.3. Une fois l’ensemble des {P˜ xi } reconstruits par l’Équation 5.10 un nuage est densifié en ajoutant des points en fonction des valeurs du patch reconstruit (Figure 5.12).C h a p i t r e 6 Conclusion À partir du débruitage non local de nuages de points, nous avons mis en évidence le besoin de structures dédiées aux traitements non-locaux des données de dimension deux et supérieure, ainsi que la possibilité de généraliser les méthodes existantes de restauration non-locale 2D et 3D. Pour pouvoir y répondre nous avons introduit les contributions suivantes : Surface de point non locale Les opérateurs de surface de points (PSS) conventionnels permettent de définir une surface à partir d’un voisinage local. Malheureusement face aux conditions réelles de capture, ce point de vue devient rapidement insuffisant pour définir une surface correcte. Pour résoudre ce problème, nous avons proposé une nouvelle définition qui étend toutes les définitions PSS locales précédentes en exploitant le caractère autosimilaire du nuage de points. Pour ce faire, nous utilisons un opérateur PSS défini à une échelle grossière pour définir une surface grossière (servant de support à notre méthode) et un champ scalaire résiduel contenant les caractéristiques bruitées de la surface. Notre surface non locale est définie en ajoutant à cette surface grossière le champ scalaire de déplacement résiduel débruité par la méthode des moyennes non locales. La mesure de similarité entre deux parties du nuage de points est définie par l’intermédiaire de patchs de surfaces dont les valeurs représentent les variations entre la surface grossière et une surface calculée par un PSS à échelle fine. Nous avons démontré que notre définition est capable d’améliorer la qualité des surfaces PSS locales en augmentant le rapport signal/bruit. Néanmoins ces résultats sont très dépendants du caractère autosimilaire du nuage à traiter. Dans le cas peu probable, d’absence d’autosimilarité, notre opérateur non local obtiendra des résultats identiques à ceux de l’opérateur PSS sous-jacent. En pratique, l’estimation de notre opérateur non local est accélérée par GPU permettant une utilisation plus interactive. Arbre de covariances Avec l’augmentation de la quantité d’information, peu de mé- thodes à l’heure actuelle exploitent réellement l’information contenue dans les grandes bases de données ou au prix d’une quantité de mémoire et de calculs beaucoup trop importante. Comme solution, nous introduisons le CovTree, une nouvelle structure de données capable d’apprendre les distributions locales d’un grand ensemble d’échantillons en les représentant par des gaussiennes anisotropes. Cette structure est définie par l’in- 99100 termédiaire de trois principales étapes. Tout d’abord, nous construisons un arbre binaire à partir d’un ensemble d’échantillons qui partitionne l’espace en fonction de la position des différents échantillons. Ensuite, nous apprenons les distributions statistiques locales de chaque nœud en propageant l’ensemble des échantillons à travers l’arbre en fonction de leur position et ajoutant une contribution pondérée des points au noyau de chaque nœud de l’arbre traversé. Finalement, pour toute requête, notre arbre modélise la distribution locales des données apprises. Pour permettre une utilisation générique, nous définissons une version généralisée de notre structure par l’intermédiaire de deux domaines : spatial correspondant au descripteur du point et des attributs correspondant à signal associé. Par l’intermédiaire d’un schéma de requête adaptatif, il devient possible d’interroger à n’importe quelle échelle pour des temps sensiblement équivalents. Restauration collaboratives Les filtres collaboratifs utilisent l’information commune à des ensembles de patchs similaires afin d’améliorer la qualité de la restauration. Malheureusement, il est coûteux et difficile d’analyser l’information contenue dans une grande base de données. Ces approches sont donc généralement simplifiées et limitées à un ensemble de points réduit. Pour résoudre ce problème, différents ensemble de données sont appris par l’intermédiaire du CovTree. Nous introduisons différentes applications de débruitages et de reconstructions de données 2D et 3D. Par rapport aux approches précédentes, il devient possible d’apprendre un a priori à partir d’une grande base d’échantillons de données non détériorées. Nous utilisons cet a priori pour améliorer les performances des méthodes de restauration. Dans cette partie, nous effectuons une analyse qualitative des performances de notre CovTree qui permet de valider son utilisation. En conclusion, nos différentes contributions permettent de s’attaquer aux problématiques soulevées par les évolutions récentes des méthodes de restaurations non locales et de l’augmentation de la quantité de données. Cette thèse s’inscrit donc au cœur de cette évolution en proposant quelques éléments de réponse à l’un des enjeux technologiques des années 2010, à savoir : la capture, transmission et traitements de masses de séquences temporelles de données 2D et 3D.C h a p i t r e 7 Perspectives Dans cette thèse, nous avons travaillé sur différents thèmes découlant de la restauration par méthodes non locales d’un ensemble de données 2D et 3D. Au-delà des contributions techniques proposées, un certain nombre de nouvelles pistes plus générales que celle abordées en Section 3.4 et 4.5 peut découler de ce travail de recherche. La définition des NLPSS suppose que le nuage de points 3D est corrompu par un bruit additif gaussien 3D. Cette supposition est indispensable pour pouvoir utiliser les moyennes non locales. Néanmoins, à l’heure actuelle, il n’existe (à notre connaissance) aucune analyse du modèle statistique du bruit introduit par les scanners 3D car il est trop dépendant du type de capteurs utilisé. Il serait donc intéressant de définir les NLPSS pour des bruits différents comme c’est proposé en traitement des images dans [DDT09]. Une telle idée nécessiterait de définir des mesures de similarité spécifiques. Les travaux de Deledalle et coll. [DDT12] et Desolneux et coll. [DD13] donnent quelques pistes le deuxième étant particulièrement pertinent car il pourrait permettre de rendre le NLPSS plus robuste aux points aberrants. Néanmoins, le changement du type de bruit entrainerait nécessairement un problème dans l’estimation du repère de normalisation des patchs. L’amélioration des systèmes de captures par agrégation des données 3D du type Kinect Fusion [IKH+11] pourrait être une autre piste de recherche intéressante. Une telle application nécessiterait de coupler notre CovTree afin de cumuler les données dans le temps, avec un système d’acquisition de données 3D en temps réel (tels que Microsoft Kinect par exemple). Une telle idée nécessite néanmoins de faire évoluer notre CovTree temporellement (Section 4.5). 101Bibliographie [AA04a] A. Adamson and M. Alexa. Approximating bounded, nonorientable surfaces from points. In Proceedings of Shape Modeling Applications, pages 243–252. IEEE, 2004. [AA04b] M. Alexa and A. Adamson. On normals and projection operators for surfaces defined by point sets. In Symposium on Point-Based Graphics, pages 149– 155. Citeseer, 2004. [AA09] M. Alexa and A. Adamson. Interpolatory point set surfaces - convexity and hermite data. ACM Transactions on Graphics (TOG), 28(2) :20, 2009. [ABCO+01] M. Alexa, J. Behr, D. Cohen-Or, S. Fleishman, D. Levin, and C. T. Silva. Point set surfaces. In Proceedings of the Conference on Visualization, pages 21–28. IEEE, October 2001. [ABD10] A. Adams, J. Baek, and M. A. Davis. Fast high-dimensional filtering using the permutohedral lattice. Computer Graphics Forum (CGF), 29(2) :753– 762, 2010. [AGDL09] A. Adams, N. Gelfand, J. Dolson, and M. Levoy. Gaussian kd-trees for fast high-dimensional filtering. ACM Transactions on Graphics (TOG), 28(3) :21, July 2009. [AK04] N. Amenta and Y. J. Kil. Defining point-set surfaces. ACM Transactions on Graphics (TOG), 23(3) :264–270, August 2004. [Ale05] S. K. Alexander. Multiscale methods in image modelling and image processing. Ph.d. thesis, University of Waterloo, Ontario, Canada, 2005. [AMN+98] S. Arya, D. M. Mount, N. S. Netanyahu, R. Silverman, and A. Y. Wu. An optimal algorithm for approximate nearest neighbor searching fixed dimensions. Journal of the ACM (JACM),, 45(6) :891–923, 1998. [APG07] N. Azzabou, N. Paragios, and F. Guichard. Image denoising based on adapted dictionary computation. In International Conference on Image Processing (ICIP), volume 3, pages 109–112. IEEE, 2007. [AW05] S. P. Awate and R. T. Whitaker. Higher-order image statistics for unsupervised, information-theoretic, adaptive, image filtering. In Computer Vision and Pattern Recognition (CVPR), volume 2, pages 44–51. IEEE, 2005. [AW06] S. P. Awate and R. T. Whitaker. Unsupervised, information-theoretic, adaptive image filtering for image restoration. IEEE Trans. Pattern Analysis and Machine Intelligence (PAMI), 28(3) :364–376, 2006. [Bar02] D. Barash. Fundamental relationship between bilateral filtering, adaptive smoothing, and the nonlinear diffusion equation. IEEE Trans. Pattern Analysis and Machine Intelligence (PAMI), 24(6) :844–847, 2002. 103104 [BBB+10] T. Beeler, B. Bickel, P. Beardsley, B. Sumner, and M. Gross. High-quality single-shot capture of facial geometry. ACM Transactions on Graphics (TOG), 29(3) :40, 2010. [BBH08] D. Bradley, T. Boubekeur, and W. Heidrich. Accurate multi-view reconstruction using robust binocular stereo and surface meshing. In Computer Vision and Pattern Recognition (CVPR), pages 1–8. IEEE, 2008. [BC07] T. Brox and D. Cremers. Iterated nonlocal means for texture restoration. In Scale Space and Variational Methods in Computer Vision, pages 13–24. Springer, 2007. [BCM05] A. Buades, B. Coll, and J.-M. Morel. A non-local algorithm for image denoising. In Computer Vision and Pattern Recognition (CVPR), volume 2, pages 60–65. IEEE, 2005. [BCM08] A. Buades, B. Coll, and J.-M. Morel. Nonlocal image and movie denoising. Springer International Journal of Computer Vision (IJCV), 76(2) :123–139, 2008. [Ben75] J. L. Bentley. Multidimensional binary search trees used for associative searching. Communications of the ACM, 18(9) :509–517, 1975. [BHB+11] T. Beeler, F. Hahn, D. Bradley, B. Bickel, P. Beardsley, C. Gotsman, R. W. Sumner, and M. Gross. High-quality passive facial performance capture using anchor frames. ACM Transactions on Graphics (TOG), 30 :75, August 2011. [BKC08] T. Brox, O. Kleinschmidt, and D. Cremers. Efficient nonlocal means for denoising of textural patterns. IEEE Transactions on Image Processing, 17(7) :1083–1092, 2008. [BM05] E. P. Bennett and L. McMillan. Video enhancement using per-pixel virtual exposures. ACM Transactions on Graphics (TOG), 24(3) :845–852, 2005. [BO05] J.-D. Boissonnat and S. Oudot. Provably good sampling and meshing of surfaces. Graphical Models, 67(5) :405–451, 2005. [Bov05] A. C. Bovik. Handbook of image and video processing. Academic Press, 2005. [BPD06] S. Bae, S. Paris, and F. Durand. Two-scale tone management for photographic look. ACM Transactions on Graphics (TOG), 25(3) :637–645, 2006. [BRR11] M. Bleyer, C. Rhemann, and C. Rother. Patchmatch stereo - stereo matching with slanted support windows. In British Machine Vision Conference (BMVC), volume 11, pages 1–11, 2011. [BSFG09] C. Barnes, E. Shechtman, A. Finkelstein, and D. Goldman. Patchmatch : a randomized correspondence algorithm for structural image editing. ACM Transactions on Graphics (TOG), 28(3) :24, 2009. [CFGS12] X. Chen, T. Funkhouser, D. B. Goldman, and E. Shechtman. Non-parametric texture transfer using meshmatch. Adobe Technical Report, November 2012. [CM02] D. Comaniciu and P. Meer. Mean shift : A robust approach toward feature space analysis. IEEE Trans. Pattern Analysis and Machine Intelligence (PAMI), 24(5) :603–619, 2002.BIBLIOGRAPHIE 105 [CPD07] J. Chen, S. Paris, and F. Durand. Real-time edge-aware image processing with the bilateral grid. ACM Transactions on Graphics (TOG), 26(3) :103, 2007. [CPT03] A. Criminisi, P. Pérez, and K. Toyama. Object removal by exemplar-based inpainting. In Computer Vision and Pattern Recognition (CVPR), volume 2, pages II–721. IEEE, 2003. [CPT04] A. Criminisi, P. Pérez, and K. Toyama. Region filling and object removal by exemplar-based image inpainting. IEEE Transactions on Image Processing, 13(9) :1200–1212, 2004. [CWL+08] Z-Q. Cheng, Y-Z. Wang, B. Li, K. Xu, G. Dang, and S-Y. Jin. A survey of methods for moving least squares surfaces. In Proceedings of conference on Point-Based Graphics, pages 9–23. IEEE, 2008. [DAG10] V. Duval, J.-F. Aujol, and Y. Gousseau. On the parameter choice for the non-local means. Technical Report hal-00468856, 2010. [DAL+11] J. Digne, N. Audfray, C. Lartigue, C. Mehdi-Souzani, and J-M. Morel. Farman Institute 3D Point Sets - High Precision 3D Data Sets. Image Processing On Line (IPOL), 2011. [DD02] F. Durand and J. Dorsey. Fast bilateral filtering for the display of highdynamic-range images. ACM Transactions on Graphics (TOG), 21(3) :257– 266, 2002. [DD13] J. Delon and A. Desolneux. A patch-based approach for removing impulse or mixed gaussian-impulse noise. Journal on Imaging Sciences (SIAM), 6(2) :1140–1174, 2013. [DDS12] C.-A. Deledalle, V. Duval, and J. Salmon. Non-local methods with shapeadaptive patches (NLM-SAP). Journal of Mathematical Imaging and Vision, 43(2) :103–120, 2012. [DDT09] C.-A. Deledalle, L. Denis, and F. Tupin. Iterative weighted maximum likelihood denoising with probabilistic patch-based weights. IEEE Transactions on Image Processing, 18(12) :2661–2672, 2009. [DDT12] C.-A. Deledalle, L. Denis, and F. Tupin. How to compare noisy patches ? patch similarity beyond gaussian noise. Springer International Journal of Computer Vision (IJCV), 99(1) :86–102, 2012. [DFKE07] K. Dabov, A. Foi, V. Katkovnik, and K. Egiazarian. Image denoising by sparse 3D transform-domain collaborative filtering. IEEE Transactions on Image Processing, 16(8) :2080–2095, 2007. [DFKE08] K. Dabov, A. Foi, V. Katkovnik, and K. Egiazarian. Image restoration by sparse 3D transform-domain collaborative filtering. In Proceedings of Electronic Imaging 2008, page 681207, 2008. [DFKE09] K. Dabov, A. Foi, V. Katkovnik, and K. Egiazarian. BM3D Image Denoising with Shape-Adaptive Principal Component Analysis. In Signal Processing with Adaptive Sparse Structured Representations (SPARS), 2009.106 [DG10] J.-E. Deschaud and F. Goulette. Point cloud non local denoising using local surface descriptor similarity. IAPRS, 2010. [Dig12] J. Digne. Similarity based filtering of point clouds. Computer Vision and Pattern Recognition (CVPR), 2012. [DM11] J. Digne and J.-M. Morel. Numerical analysis of differential operators on raw point clouds. Numerische Mathematik, pages 1–35, 2011. [DMSL11] J. Digne, J.-M. Morel, C.-M. Souzani, and C. Lartigue. Scale space meshing of raw data point sets. Computer Graphics Forum (CGF), 30(6) :1630–1642, 2011. [Don95] D. L. Donoho. De-noising by soft-thresholding. IEEE Transactions on Information Theory, 41(3) :613–627, 1995. [EL99] A. A. Efros and T. K. Leung. Texture synthesis by non-parametric sampling. In Proceedings of International Conference on Computer Vision (ICCV), volume 2, pages 1033–1038. IEEE, 1999. [FAR07] R. Fattal, M. Agrawala, and S. Rusinkiewicz. Multiscale shape and detail enhancement from multi-light image collections. ACM Transactions on Graphics (TOG), 26(3) :51, 2007. [FCOS05] S. Fleishman, D. Cohen-Or, and C. T. Silva. Robust moving least-squares fitting with sharp features. ACM Transactions on Graphics (TOG), 24(3) :544– 552, 2005. [FDCO03] S. Fleishman, I. Drori, and D. Cohen-Or. Bilateral mesh denoising. ACM Transactions on Graphics (TOG), 22(3) :950–953, 2003. [FKEA04] A. Foi, V. Katkovnik, K. Egiazarian, and J. Astola. A novel anisotropic local polynomial estimator based on directional multiscale optimizations “. In International conference of IMA, pages 79–82, 2004. [FKN80] H. Fuchs, Z. M. Kedem, and B. F. Naylor. On visible surface generation by a priori tree structures. ACM SIGGRAPH Computer Graphics, 14(3) :124–133, 1980. [GG07] G. Guennebaud and M. H. Gross. Algebraic point set surfaces. ACM Transactions on Graphics (TOG), 26(3) :23, 2007. [GGG08] G. Guennebaud, Marcel Germann, and M. H. Gross. Dynamic sampling and rendering of algebraic point set surfaces. Computer Graphics Forum (CGF), 27(2) :653–662, 2008. [GLPP08] B. Goossens, Q. Luong, A. Pizurica, and W Philips. An improved nonlocal denoising algorithm. In International workshop on Local and Non-Local Approximation in Image Processing (LNLA), pages 143–156, 2008. [GO11] E. S. L. Gastal and M. M. Oliveira. Domain transform for edge-aware image and video processing. ACM Transactions on Graphics (TOG), 30(4) :69, 2011.BIBLIOGRAPHIE 107 [GO12] E. S. L. Gastal and M. M. Oliveira. Adaptive manifolds for real-time highdimensional filtering. ACM Transactions on Graphics (TOG), 31(4) :33, 2012. [HDD+94] H. Hoppe, T. DeRose, T. Duchamp, J. McDonald, and W. Stuetzle. Surface reconstruction from unorganized points. PhD thesis, University of Washington, 1994. [HS12] K. He and J. Sun. Computing nearest-neighbor fields via propagation-assisted kd-trees. In Computer Vision and Pattern Recognition (CVPR), pages 111– 118. IEEE, 2012. [HST10] K. He, J. Sun, and X. Tang. Guided image filtering. In European Conference on Computer Vision (ECCV), pages 1–14. Springer, 2010. [IKH+11] S. Izadi, D. Kim, O. Hilliges, D. Molyneaux, R. Newcombe, P. Kohli, J. Shotton, S. Hodges, D. Freeman, and A. Davison. KinectFusion : real-time 3D reconstruction and interaction using a moving depth camera. In Proceedings of symposium on User interface software and technology, pages 559–568. ACM, 2011. [JCSX09] Z. Ji, Q. Chen, Q.-S. Sun, and D.-S. Xia. A moment-based nonlocal-means algorithm for image denoising. Information Processing Letters, 109(23) :1238– 1244, 2009. [JDD03] T. R. Jones, F. Durand, and M. Desbrun. Non-iterative, feature-preserving mesh smoothing. ACM Transactions on Graphics (TOG), 22 :943–949, July 2003. [JDZ04] T. R. Jones, F. Durand, and M. Zwicker. Normal improvement for point rendering. IEEE Computer Graphics and Applications, 24(4) :53–56, 2004. [KA11] S. Korman and S. Avidan. Coherency sensitive hashing. In International Conference on Computer Vision (ICCV), pages 1607–1614. IEEE, 2011. [KB06] C. Kervrann and J. Boulanger. Optimal spatial adaptation for patch-based image denoising. IEEE Transactions on Image Processing, 15(10) :2866–2878, 2006. [KBH06] M. Kazhdan, M. Bolitho, and H. Hoppe. Poisson surface reconstruction. In Proceedings of Symposium on Geometry processing (SGP), 2006. [KCLU07] J. Kopf, M. F. Cohen, D. Lischinski, and M. Uyttendaele. Joint bilateral upsampling. ACM Transactions on Graphics (TOG), 26(3) :96, 2007. [KEA02] V. Katkovnik, K. Egiazarian, and J. Astola. Adaptive window size image de-noising based on intersection of confidence intervals (ICI) rule. Journal of Mathematical Imaging and Vision, 16(3) :223–235, 2002. [KFEA04] V. Katkovnik, A. Foi, K. Egiazarian, and J. Astola. Directional varying scale approximations for anisotropic signal processing. In Proceedings in European Signal Processing Conference (EUSIPCO), pages 101–104. Citeseer, 2004. [LBM13] M. Lebrun, A. Buades, and J-M. Morel. Implementation of the "Non-Local Bayes" (NL-Bayes) Image Denoising Algorithm. Image Processing On Line (IPOL), 2013 :1–42, 2013.108 [LC87] W. E. Lorensen and H. E. Cline. Marching cubes : A high resolution 3d surface construction algorithm. In Proceedings of SIGGRAPH, pages 163– 169, 1987. [LCBM12] M. Lebrun, M. Colom, A. Buades, and J-M. Morel. Secrets of image denoising cuisine. Acta Numerica, 21(1) :475–576, 2012. [Lee83] J.-S. Lee. Digital image smoothing and the sigma filter. Computer Vision, Graphics, and Image Processing, 24(2) :255–269, 1983. [Lev98] D. Levin. The approximation power of moving least-squares. Mathematics of Computation, 67 :1517–1531, 1998. [Lev03] D. Levin. Mesh-independent surface interpolation. Geometric Modeling for Scientifc Visualization(2003), pages 1517–1523, 2003. [LN11] A. Levin and B. Nadler. Natural image denoising : Optimality and inherent bounds. In Computer Vision and Pattern Recognition (CVPR), pages 2833– 2840. IEEE, 2011. [LPC+00] M. Levoy, K. Pulli, B. Curless, S. Rusinkiewicz, D. Koller, L. Pereira, M. Ginzton, S. Anderson, J. Davis, and J. Ginsberg. The digital michelangelo project : 3d scanning of large statues. In Proceedings of Computer Graphics and Interactive Techniques, pages 131–144. ACM, 2000. [MBP+09] J. Mairal, F. Bach, J. Ponce, G. Sapiro, and A. Zisserman. Non-local sparse models for image restoration. In International Conference on Computer Vision, pages 2272–2279. IEEE, 2009. [MCCL+08] J. V. Manjón, J. Carbonell-Caballero, J. J. Lull, G. García-Martí, L. Martí- Bonmatí, and M. Robles. MRI denoising using non-local means. Medical image analysis, 12(4) :514–523, 2008. [ML09] M. Muja and D. G. Lowe. Fast approximate nearest neighbors with automatic algorithm configuration. In International Conference on Computer Vision Theory and Application (VISSAPP), pages 331–340. INSTICC Press, 2009. [ML12] M. Muja and D. G. Lowe. Fast matching of binary features. In Computer and Robot Vision (CRV), pages 404–410. IEEE, 2012. [MNB12] A. Maleki, M. Narayan, and R. G. Baraniuk. Anisotropic nonlocal means denoising. Applied and Computational Harmonic Analysis, 2012. [MRS12] S. Morigi, M. Rucci, and F. Sgallari. Nonlocal surface fairing. Scale Space and Variational Methods in Computer Vision, pages 38–49, 2012. [Nem00] A. Nemirovski. Topics in non-parametric. Ecole d’Ete de Probabilites de Saint-Flour, 28 :85, 2000. [NFP+13] A. Newson, M. Fradet, P. Pérez, A. Almansa, and Y. Gousseau. Towards fast, generic video inpainting. HAL Technical Report 00838927, June 2013. [OA12] I. Olonetsky and S. Avidan. Treecann-kd tree coherence approximate nearest neighbor algorithm. In European Conference on Computer Vision (ECCV), pages 602–615. Springer, 2012.BIBLIOGRAPHIE 109 [ÖGG09] A. C. Öztireli, G. Guennebaud, and M. H. Gross. Feature preserving point set surfaces based on non-linear kernel regression. Computer Graphics Forum (CGF), 28(2) :493–501, 2009. [PD06] S. Paris and F. Durand. A fast approximation of the bilateral filter using a signal processing approach. In European Conference on Computer Vision (ECCV), pages 568–580. Springer, 2006. [PD09] S. Paris and F. Durand. A fast approximation of the bilateral filter using a signal processing approach. International Journal of Computer Vision (IJCV), 81(1) :24–52, 2009. [PS00] J. Polzehl and V. G. Spokoiny. Adaptive weights smoothing with applications to image restoration. Journal of the Royal Statistical Society (Statistical Methodology), 62(2) :335–354, 2000. [RDK13] G. Rosman, A. Dubrovina, and R. Kimmel. Patch-collaborative spectral point-cloud denoising. In Computer Graphics Forum (CGF). Wiley Online Library, 2013. [ROF92] L. I. Rudin, S. Osher, and E. Fatemi. Nonlinear total variation based noise removal algorithms. Physica D : Nonlinear Phenomena, 60(1) :259–268, 1992. [Sal10a] J. Salmon. Agrégation d’estimateurs et méthodes à patch pour le débruitage d’images numériques. PhD thesis, Université Paris-Diderot-Paris VII, 2010. [Sal10b] J. Salmon. On two parameters for denoising with non-local means. IEEE Signal Processing Letters, 17(3) :269–272, 2010. [She68] D. Shepard. A two-dimensional interpolation function for irregularly-spaced data. In Proceedings of the ACM national conference, pages 517–524. ACM, 1968. [SS12] J. Salmon and Y. Strozecki. Patch reprojections for non-local methods. Signal Processing, 92(2) :477–489, 2012. [Tas08] T. Tasdizen. Principal components for non-local means image denoising. In IEEE International Conference on Image Processing (ICIP), pages 1728– 1731, 2008. [Tas09] T. Tasdizen. Principal neighborhood dictionaries for nonlocal means image denoising. IEEE Transactions on Image Processing, 18(12) :2649–2660, 2009. [TM98] C. Tomasi and R. Manduchi. Bilateral filtering for gray and color images. In Proceedings of International Conference on Computer Vision (ICCV), page 839. IEEE Computer Society, 1998. [VB11] G. Vialaneix and T. Boubekeur. Sbl mesh filter : fast separable approximation of bilateral mesh filtering. In SIGGRAPH Talks, page 24. ACM, 2011. [VDVK09] D. Van De Ville and M. Kocher. SURE-based non-local means. IEEE Signal Processing Letters, 16(11) :973–976, 2009. [WCZ+08] R. F. Wang, W. Z. Chen, S. Y. Zhang, Y. Zhang, and X. Z. Ye. Similaritybased denoising of point-sampled surfaces. Journal of Zhejiang UniversityScience, 9(6) :807–815, 2008.110 [WGY+06] J. Wang, Y. Guo, Y. Ying, Y. Liu, and Q. Peng. Fast non-local algorithm for image denoising. In IEEE International Conference on Image Processing (ICIP), pages 1429–1432, 2006. [YBS06] S. Yoshizawa, A. Belyaev, and H.-P. Seidel. Smoothing by example : Mesh denoising by averaging with similarity based weights. In In Proceedings of IEEE International Conference on Shape Modeling and Applications, pages 38–44, 2006. [YSM10] G. Yu, G. Sapiro, and S. Mallat. Image modeling and enhancement via structured sparse model selection. In IEEE International Conference on Image Processing (ICIP), pages 1641–1644, 2010. [YSM12] G. Yu, G. Sapiro, and S. Mallat. Solving inverse problems with piecewise linear estimators : from gaussian mixture models to structured sparsity. IEEE Transactions on Image Processing, 21(5) :2481–2499, 2012. [YY85] L. P. Yaroslavsky and L. P. Yaroslavskij. Digital picture processing. an introduction. Springer Seriesin Information Sciences, 1, 1985. [ZDW08] S. Zimmer, S. Didas, and J. Weickert. A rotationally invariant block matching strategy improving image denoising with non-local means. In Proceedings of International Workshop on Local and Non-Local Approximation in Image Processing, pages 135–142, 2008. [ZDZS10] L. Zhang, W. Dong, D. Zhang, and G. Shi. Two-stage image denoising by principal component analysis with local pixel grouping. Pattern Recognition, 43(4) :1531–1549, 2010. [ZW11] D. Zoran and Y. Weiss. From learning models of natural image patches to whole image restoration. In Proceedings of International Conference on Computer Vision (ICCV), pages 479–486. IEEE, 2011.Méthodes et structures non locales pour la restauration d’images et de surfaces 3D Thierry GUILLEMOT Résumé : Durant ces dernières années, les technologies d’acquisition numériques n’ont cessé de se perfectionner, permettant d’obtenir des données d’une qualité toujours plus fine. Néanmoins, le signal acquis reste corrompu par des défauts qui ne peuvent être corrigés matériellement et nécessitent l’utilisation de méthodes de restauration adaptées. Jusqu’au milieu des années 2000, ces approches s’appuyaient uniquement sur un traitement ocal du signal détérioré. Avec l’amélioration des performances de calcul, le support du filtre a pu être étendu à l’ensemble des données acquises en exploitant leur caractère autosimilaire. Ces approches non locales ont principalement été utilisées pour restaurer des données régulières et structurées telles que des images. Mais dans le cas extrême de données irrégulières et non structurées comme les nuages de points 3D, leur adaptation est peu étudiée à l’heure actuelle. Avec l’augmentation de la quantité de données échangées sur les réseaux de communication, de nouvelles méthodes non locales ont récemment été proposées. Elles utilisent un modèle a priori extrait à partir de grands ensembles d’échantillons pour améliorer la qualité de la restauration. Néanmoins, ce type de méthode reste actuellement trop coûteux en temps et en mémoire. Dans cette thèse, nous proposons, tout d’abord, d’étendre les méthodes non locales aux nuages de points 3D, en définissant une surface de points capable d’exploiter leur caractère autosimilaire. Nous introduisons ensuite une nouvelle structure de données, le CovTree, flexible et générique, capable d’apprendre les distributions d’un grand ensemble d’échantillons avec une capacité de mémoire limitée. Finalement, nous généralisons les méthodes de restauration collaboratives appliquées aux données 2D et 3D, en utilisant notre CovTree pour apprendre un modèle statistique a priori à partir d’un grand ensemble de données. Mots-clefs : non local, restauration, structure de données, débruitages, surface, nuage de points, filtre collaboratif Abstract : In recent years, digital technologies allowing to acquire real world objects or scenes have been significantly improved in order to obtain high quality datasets. However, the acquired signal is corrupted by defects which can not be rectified materially and require the use of adapted restoration methods. Until the middle 2000s, these approaches were only based on a local process applyed on the damaged signal. With the improvement of computing performance, the neighborhood used by the filter has been extended to the entire acquired dataset by exploiting their self-similar nature. These non-local approaches have mainly been used to restore regular and structured data such as images. But in the extreme case of irregular and unstructured data as 3D point sets, their adaptation is few investigated at this time. With the increase amount of exchanged data over the communication networks, new non-local methods have recently been proposed. These can improve the quality of the restoration by using an a priori model extracted from large data sets. However, this kind of method is time and memory consuming. In this thesis, we first propose to extend the non-local methods for 3D point sets by defining a surface of points which exploits their self-similar of the point cloud. We then introduce a new flexible and generic data structure, called the CovTree, allowing to learn the distribution of a large set of samples with a limited memory capacity. Finally, we generalize collaborative restoration methods applied to 2D and 3D data by using our CovTree to learn a statistical a priori model from a large dataset. Keywords : non local, restauration, data structure, denoising, surface, points set, collaborative filter Couplage de mod`eles, algorithmes multi-´echelles et calcul hybride Jean-Matthieu Etancelin To cite this version: Jean-Matthieu Etancelin. Couplage de mod`eles, algorithmes multi-´echelles et calcul hybride. Analysis of PDEs. Universit´e de Grenoble, 2014. French. HAL Id: tel-01094645 https://tel.archives-ouvertes.fr/tel-01094645v2 Submitted on 15 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THÈSE Pour obtenir le grade de DOCTEUR DE L’UNIVERSITÉ DE GRENOBLE Spécialité : Mathématiques Appliquées Arrêté ministériel : 7 août 2006 Présentée par Jean-Matthieu Etancelin Thèse dirigée par Georges-Henri Cottet et codirigée par Christophe Picard préparée au sein du Laboratoire Jean Kuntzmann et de l’école doctorale MSTII: Mathématiques, Sciences et Technologies de l’Information, Informatique Couplage de modèles, algorithmes multi-échelles et calcul hybride Thèse soutenue publiquement le 4 décembre 2014, devant le jury composé de : M. Stéphane Labbé Professeur, Université Joseph Fourier, Président M. Florian De Vuyst Professeur, École Normale Supérieure de Cachan, Rapporteur M. Philippe Helluy Professeur, Université de Strasbourg, Rapporteur M. Guillaume Balarac Maître de conférences, Grenoble INP, Examinateur M. Georges-Henri Cottet Professeur, Université Joseph Fourier, Directeur de thèse M. Alexis Herault Maître de conférences, Conservatoire National des Arts et Métiers, Examinateur M. Christophe Picard Maître de conférences, Grenoble INP, Co-Directeur de thèse M. Christophe Prud’homme Professeur, Université de Strasbourg, Examinateur M. Jean-Baptiste Lagaert Maître de conférences, Université Paris-Sud, InvitéCouplage de modèles, algorithmes multi-échelles et calcul hybride Thèse présentée et soutenue publiquement par : Jean-Matthieu Etancelin le 4 décembre 2014 Composition du jury : Président : Stéphane Labbé, Professeur, Université Joseph Fourier Rapporteurs : Florian De Vuyst, Professeur, École Normale Supérieure de Cachan Philippe Helluy, Professeur, Université de Strasbourg Examinateurs : Guillaume Balarac, Maître de conférences, Grenoble INP Georges-Henri Cottet, Professeur, Université Joseph Fourier (Directeur de thèse) Alexis Herault, Maître de conférences, Conservatoire National des Arts et Métiers Christophe Picard, Maître de conférences, Grenoble INP (Co-Directeur de thèse) Christophe Prud’homme, Professeur, Université de Strasbourg Invité : Jean-Baptiste Lagaert, Maître de conférences, Université Paris-Sud Thèse préparée au sein du Laboratoire Jean Kuntzmann et de l’école doctorale MSTII : Mathémaiques, Sciences et Technologies de l’Information, Informatique. Cette thèse a été effectuée dans le cadre du projet ANR HAMM (ANR-10-COSI-0009).iiRemerciements Je voudrais exprimer ma gratitude auprès de toutes les personnes, du Laboratoire Jean Kuntzmann ou d’ailleurs, qui ont contribué à la réussite de cette thèse aussi bien sur le plan scientifique qu’humain. Je remercie très chaleureusement mon directeur de thèse, Georges-Henri Cottet, et mon co-encadrant, Christophe Picard, pour leur disponibilité et leur soutient tout au long de ces trois années. Votre encadrement a été réel et complémentaire sur le fond et la forme de ces travaux. Je remercie l’ensemble des membres de mon jury d’avoir pris le temps d’examiner mon travail, en particulier Florian De Vuyst et Philippe Helluy, rapporteurs de cette thèse. Je remercie également Franck, Chloé, Jean-Baptiste et Éric pour les nombreux questionnements et discussions lors des réunions du groupe de travail. Ces échanges ont été en grande partie à l’origine des avancées majeures des travaux et ont permis de conserver une motivation à chaque instant. Je voudrais adresser ma reconnaissance aux membres de l’équipe des Moyens Informatiques et Calcul Scientifique du LJK et du mésocentre CIMENT qui ont contribué à la résolution des nombreux problèmes techniques qui se sont posés tout au long de la thèse. Je remercie en particulier Franck (encore) pour sa grande disponibilité, surtout le vendredi après-midi, pour répondre à mes très nombreuses questions techniques. Pour les aspects informatiques, je remercie aussi Frédéric pour ses nombreuses remises en route de la machine de calcul du laboratoire. Je voudrais remercier l’ensemble des gestionnaires administratives du laboratoire qui assurent une présence rassurante pour mener à bien toutes les démarches. Je remercie l’ensemble des doctorants et post-doctorants sur lesquels on peut compter pour un repas au RU, un café, des mots fléchés, de bons conseils, une soirée jeux, une sortie cinéma, une bière, une randonnée, des crêpes, une sortie ski, un footing, un trail,. . . Pour tout cela, merci à Chloé, Roland, Vincent, Bertrand, Thomas, Madison, Lukáš, PierreOlivier, Matthias, Nelson, Romain, Morgane, Pierre-Jean, Meriem, Kevin, Gilles, Euriell, Amin, Kolé, Louis, Federico Z., Mahamar, Abdoulaye, Federico P., Margaux, Olivier, . . . Merci à Martial pour les très nombreuses « buissonnades » en tout genre dans lesquelles on se laisse facilement embarquer. Je remercie également les copains de l’INSA pour leur promptitude à traverser la France et à proposer des hébergements pour passer du bon temps. Merci à ma famille pour son soutient tout au long de mes études. Enfin, et non des moindres, merci à Myriam pour tout ces instants que l’on partage au quotidien. iiiRésumé Dans cette thèse nous explorons les possibilités offertes par l’implémentation de mé- thodes hybrides sur des machines de calcul hétérogènes dans le but de réaliser des simulations numériques de problèmes multiéchelles. La méthode hybride consiste à coupler des méthodes de diverses natures pour résoudre les différents aspects physiques et numériques des problèmes considérés. Elle repose sur une méthode particulaire avec remaillage qui combine les avantages des méthodes Lagrangiennes et Eulériennes. Les particules sont dé- placées selon le champ de vitesse puis remaillées à chaque itération sur une grille en utilisant des formules de remaillage d’ordre élevés. Cette méthode semi-Lagrangienne bénéficie des avantages du maillage régulier mais n’est pas contrainte par une condition de CFL. Nous construisons une classe de méthodes d’ordre élevé pour lesquelles les preuves de convergence sont obtenues sous la seule contrainte de stabilité telle que les trajectoires des particules ne se croisent pas. Dans un contexte de calcul à haute performance, le développement du code de calcul a été axé sur la portabilité afin de supporter l’évolution rapide des architectures et leur nature hétérogène. Une étude des performances numériques de l’implémentation GPU de la méthode pour la résolution d’équations de transport est réalisée puis étendue au cas multiGPU. La méthode hybride est appliquée à la simulation du transport d’un scalaire passif dans un écoulement turbulent 3D. Les deux sous-problèmes que sont l’écoulement turbulent et le transport du scalaire sont résolus simultanément sur des architectures multi-CPU et multi-GPU. Mots clés: Méthodes pariculaires ; couplage de modèles ; calcul hybride ; écoulements turbulents. ivAbstract In this work, we investigate the implementation of hybrid methods on heterogeneous computers in order to achieve numerical simulations of multi-scale problems. The hybrid numerical method consists of coupling methods of different natures to solve the physical and numerical characteristics of the problem. It is based on a remeshed particle method that combines the advantages of Lagrangian and Eulerian methods. Particles are pushed by local velocities and remeshed at every time-step on a grid using high order interpolation formulas. This forward semi-lagrangian method takes advantage of the regular mesh on which particles are reinitialized but is not limited by CFL conditions. We derive a class of high order methods for which we are able to prove convergence results under the sole stability constraint that particle trajectories do not intersect. In the context of high performance computing, a strong portability constraint is applied to the code development in order to handle the rapid evolution of architectures and their heterogeneous nature. An analysis of the numerical efficiency of the GPU implementation of the method is performed and extended to multi-GPU platforms. The hybrid method is applied to the simulation of the transport of a passive scalar in a 3D turbulent flow. The two sub-problems of the flow and the scalar calculations are solved simultaneously on multi-CPU and multi-GPU architectures. Keywords: Particle methods; model coupling; hybrid computing; turbulent flows. vTable des matières Remerciements iii Résumé iv Introduction générale 1 1. Calcul intensif pour la mécanique des fluides 5 1.1. Mécanique des fluides numérique . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.1. Modèle mathématique . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Équations de Navier-Stokes . . . . . . . . . . . . . . . . . . . . . . 6 Fluides incompressibles . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1.2. Principales méthodes de résolution . . . . . . . . . . . . . . . . . . . 9 Méthodes Eulériennes . . . . . . . . . . . . . . . . . . . . . . . . . 9 Méthodes de Lattice Boltzmann . . . . . . . . . . . . . . . . . . . 12 Méthodes Lagrangiennes . . . . . . . . . . . . . . . . . . . . . . . 13 Qualité des résultats numériques . . . . . . . . . . . . . . . . . . . 16 1.1.3. Exemples d’application . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2. Calcul intensif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2.1. Augmentation des besoin et des ressources de calcul . . . . . . . . . 18 Ressources de calcul pour les simulations numériques . . . . . . . . 18 Augmentation de la puissance de calcul des machines . . . . . . . 18 Difficulté d’adaptation des codes de calcul . . . . . . . . . . . . . . 20 1.2.2. Mesure de performances . . . . . . . . . . . . . . . . . . . . . . . . . 20 Scalabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Modèle roofline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Efficacité énergétique . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.2.3. Défi de l’exascale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Pourquoi l’exascale ? . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Principales difficultés . . . . . . . . . . . . . . . . . . . . . . . . . 25 Quelques stratégies . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.3. Transport de scalaire passif dans un écoulement turbulent . . . . . . . . . . 26 1.3.1. Domaines d’application . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.3.2. Physique du problème . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.3.3. Formulation mathématique . . . . . . . . . . . . . . . . . . . . . . . 28 viiTable des matières 2. Méthode particulaire pour l’équation de transport 31 2.1. Méthode particulaire avec remaillage . . . . . . . . . . . . . . . . . . . . . . 32 2.1.1. Deux classes de méthodes semi-Lagrangiennes . . . . . . . . . . . . . 32 2.1.2. Principe général de la méthode particulaire avec remaillage . . . . . 33 2.1.3. Cas monodimensionnel . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.1.4. Lien avec la méthode des différences finies . . . . . . . . . . . . . . . 37 2.1.5. Construction des formules de remaillage . . . . . . . . . . . . . . . . 39 Construction à partir des moments discrets . . . . . . . . . . . . . 39 Construction à partir de B-splines . . . . . . . . . . . . . . . . . . 39 Extrapolation à partir de noyaux réguliers . . . . . . . . . . . . . . 40 2.1.6. Exemple d’implémentation . . . . . . . . . . . . . . . . . . . . . . . . 42 2.2. Advection semi-Lagrangienne d’ordre élevé . . . . . . . . . . . . . . . . . . . 42 2.2.1. Construction de formules de remaillage d’ordre élevé . . . . . . . . . 42 Utilisation des poids de remaillage . . . . . . . . . . . . . . . . . . 45 Précision numérique du schéma d’Horner . . . . . . . . . . . . . . 46 2.2.2. Consistance de la méthode semi-Lagrangienne . . . . . . . . . . . . . 47 Advection par un schéma d’Euler . . . . . . . . . . . . . . . . . . . 50 Advection par un schéma de Runge-Kutta du second ordre . . . . 50 Cas d’une seule particule par cellule . . . . . . . . . . . . . . . . . 51 2.2.3. Stabilité de la méthode semi-Lagrangienne . . . . . . . . . . . . . . . 51 Advection à vitesse constante . . . . . . . . . . . . . . . . . . . . . 52 Advection à vitesse non constante . . . . . . . . . . . . . . . . . . 56 3. Méthode hybride pour le transport turbulent 59 3.1. Idée générale d’une méthode hybride . . . . . . . . . . . . . . . . . . . . . . 59 3.1.1. Méthode hybride en méthode numérique . . . . . . . . . . . . . . . . 60 3.1.2. Méthode hybride en résolution . . . . . . . . . . . . . . . . . . . . . 60 3.1.3. Méthode hybride en matériel . . . . . . . . . . . . . . . . . . . . . . 61 3.2. Application au transport turbulent . . . . . . . . . . . . . . . . . . . . . . . 61 3.2.1. Méthodes spectrale et différences finies . . . . . . . . . . . . . . . . . 61 3.2.2. Méthodes spectrale et semi-Lagrangienne . . . . . . . . . . . . . . . 62 3.2.3. Méthodes semi-Lagrangiennes et architecture hybride . . . . . . . . . 62 4. Développement d’un code multiarchitectures 65 4.1. Développement d’une librairie de calcul scientifique . . . . . . . . . . . . . . 66 4.1.1. Conception préliminaire . . . . . . . . . . . . . . . . . . . . . . . . . 66 Découpage sémantique des concepts mathématiques . . . . . . . . 66 Différents niveaux d’abstraction . . . . . . . . . . . . . . . . . . . 67 Couplage faible et cohésion forte . . . . . . . . . . . . . . . . . . . 67 Schéma d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.1.2. Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.1.3. Fonctionnement de la librairie . . . . . . . . . . . . . . . . . . . . . . 70 Langages de programmation . . . . . . . . . . . . . . . . . . . . . 70 Dépendances externes . . . . . . . . . . . . . . . . . . . . . . . . . 71 Fonctionnement global . . . . . . . . . . . . . . . . . . . . . . . . . 72 viiiTable des matières 4.2. Calcul générique sur carte graphique . . . . . . . . . . . . . . . . . . . . . . 72 4.2.1. Description du matériel . . . . . . . . . . . . . . . . . . . . . . . . . 72 Fonctionnement des cartes graphiques . . . . . . . . . . . . . . . . 72 Architecture des cartes graphiques . . . . . . . . . . . . . . . . . . 74 4.2.2. Différentes méthodes de programmation . . . . . . . . . . . . . . . . 75 Programmation par directives . . . . . . . . . . . . . . . . . . . . . 75 Programmation directe . . . . . . . . . . . . . . . . . . . . . . . . 76 4.2.3. Les modèles de programmation OpenCL . . . . . . . . . . . . . . . . 76 4.2.4. Analyse de performances par le modèle roofline . . . . . . . . . . . . 80 4.3. Utilisation de cartes graphiques dans la librairie . . . . . . . . . . . . . . . . 82 5. Mise en œuvre sur cartes graphiques 85 5.1. Implémentations GPU de méthodes semi-Lagrangiennes . . . . . . . . . . . 86 5.1.1. Méthodes semi-Lagrangiennes . . . . . . . . . . . . . . . . . . . . . . 86 5.1.2. Deux types d’interpolations . . . . . . . . . . . . . . . . . . . . . . . 86 5.2. Implémentation et performances . . . . . . . . . . . . . . . . . . . . . . . . 89 5.2.1. Adéquation de la méthode au matériel . . . . . . . . . . . . . . . . . 89 5.2.2. Préambule à l’étude des performances . . . . . . . . . . . . . . . . . 91 5.2.3. Initialisation des particules . . . . . . . . . . . . . . . . . . . . . . . 94 Copie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Transposition XY . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Transposition XZ . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.2.4. Advection et remaillage . . . . . . . . . . . . . . . . . . . . . . . . . 98 Advection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Remaillage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Noyau complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.3. Application simple GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.3.1. Transport de scalaire 2D . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.3.2. Transport de scalaire 3D . . . . . . . . . . . . . . . . . . . . . . . . . 111 6. Implémentation sur architectures hétérogènes 115 6.1. Lien entre la méthode et l’architecture hybride . . . . . . . . . . . . . . . . 116 6.1.1. Description d’une machine hybride . . . . . . . . . . . . . . . . . . . 116 6.1.2. Différents niveaux de parallélisme . . . . . . . . . . . . . . . . . . . . 117 6.1.3. Stratégie d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.2. Application multi-GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.2.1. Mécanisme de communication . . . . . . . . . . . . . . . . . . . . . . 119 6.2.2. Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.3. Transport turbulent d’un scalaire passif . . . . . . . . . . . . . . . . . . . . 126 6.3.1. Application hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 6.3.2. Exploitation d’une machine hétérogène . . . . . . . . . . . . . . . . . 128 6.3.3. Résultats et performances . . . . . . . . . . . . . . . . . . . . . . . . 129 Conclusion générale 135 Bibliographie 139 ixTable des matières A. Formules de remaillage de type Λp,r 145 A.1. Formules de type Λ2,r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 A.2. Formules de type Λ4,r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 A.3. Formules de type Λ6,r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 A.4. Formules de type Λ8,r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 B. Publications 157 B.1.. High order semi-Lagrangian particle methods for transport equations : numerical analysis and implementation issues . . . . . . . . . . . . . . . . . . . 159 B.2.. Multi-scale problems, high performance computing and hybrid numerical methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 xIntroduction générale La réalisation de simulations numériques est une activité majeure dans les secteurs de la recherche et de l’industrie. Une simulation numérique permet d’obtenir une solution à un problème mathématique qu’il n’est généralement pas possible de résoudre analytiquement. Ces problèmes sont constitués d’équations modélisant un phénomène à étudier. Les premières simulations numériques datent du milieu du XXe siècle lorsque l’informatique commence à être utilisée dans ce but. En 1955, Fermi et al. réalisent une des premières simulations numériques d’un système dynamique monodimensionnel constitué de 64 masses reliées par des ressorts. Depuis, l’usage des calculateurs n’a cessé de se développer avec l’essor de l’informatique et des machines de calcul. D’une part, les objectifs des simulations numériques sont de permettre une validation des modèles physiques et mathématiques utilisés pour l’étude d’un phénomène, par rapport à la théorie et à d’éventuelles données expérimentales. D’autre part, elles servent d’outils de conception et d’optimisation à des fins industrielles et permettent d’éviter le recours à de nombreux et coûteux modèles réduits et prototypes. L’explosion de la puissance de calcul développée par les machines parallèles au cours des dernières décennies permet la réalisation de simulations numériques de plus en plus précises et complexes tout en conservant des temps de calculs comparables. Ainsi, dans le domaine de la mécanique des fluides, l’évolution des simulations numériques contribue fortement à l’amélioration de la compréhension de phénomènes complexes comme la turbulence. En effet, les machines sont capables de traiter des résolutions toujours plus grandes, ce qui permet d’accroître la finesse des résultats, en particulier pour des Simulations Numériques Directes (DNS en anglais). De même, des études de fluides complexes (non Newtoniens, biologiques, alimentaires, . . .) ou de problèmes multiphysiques (interaction fluide-structure, combustion, plasma, . . .) font appel à des schémas numériques plus complexes et dont la mise en œuvre nécessite d’importantes ressources de calcul. Enfin, dans le cadre d’applications graphiques pour le cinéma ou les jeux vidéos, les capacités des machines actuelles permettent une utilisation de véritables modèles de fluide plutôt que des approximations afin d’augmenter le réalisme des écoulements dans des temps de calcul compatibles avec les contraintes de l’application. Les simulations numériques reposent à la fois sur une ou plusieurs méthodes numériques et sur un code de calcul qui transcrit ces méthodes sur les machines de calcul. Le choix de la méthode de résolution dépend essentiellement de l’adéquation entre la nature du problème à résoudre, les caractéristiques attendues pour les solutions et les spécificités de la méthode. Le code de calcul met en œuvre les algorithmes issus de la méthode. 1Introduction générale Le rôle de l’informatique est primordial pour l’obtention d’un code de calcul efficace. La qualité d’une méthode se mesure à la fois à travers les résultats qu’elle produit, mais aussi à son implémentation. L’efficacité numérique d’un code se mesure, entre autres, par le temps de calcul nécessaire à l’obtention de la solution en fonction de la qualité désirée. Ainsi, l’implémentation d’une méthode nécessite une attention particulière dans le but d’exploiter au mieux les ressources informatiques disponibles. Le développement d’un code efficace dans un contexte de calcul à hautes performances est un véritable défi sur des machines hétérogènes et massivement parallèles. Par conséquent, les méthodes numériques doivent non seulement être adaptées aux caractéristiques des problèmes à résoudre, mais également aux architectures des machines sur lesquelles elles seront implémentées. En particulier, l’aspect hétérogène des composants (CPU, GPU, coprocesseurs, . . .) doit être pris en compte dès la conception de l’algorithme de résolution et de l’élaboration de la méthode numérique. Dans cette thèse, nous considérons un problème de transport de scalaire passif dans un écoulement turbulent comme cadre applicatif. De nombreuses applications sont concernées par ce type de problème notamment dans les domaines de l’environnement, de l’industrie ou de la biologie (Shraiman et al., 2000). Le scalaire transporté peut représenter une quantité réelle comme une concentration en espèce chimique ou en bactéries, ou bien abstraite comme une interface entre deux fluides. Dans ce travail nous nous limitons à l’étude du transport de scalaires passifs qui n’influent pas sur l’écoulement en retour. En général, la physique de ce type de problème se caractérise par la présence de plusieurs phénomènes à différentes échelles (Batchelor, 1958). L’approche envisagée ici est celle d’une résolution par une méthode hybride. Cette notion nécessite une précision quant au sens du mot hybride tel que nous l’entendons. Une méthode hybride consiste à résoudre les différents aspects physiques à l’aide d’une ou plusieurs méthodes numériques adaptées en fonction de leurs caractéristiques respectives. La méthodologie employée dans cette thèse est de chercher à exploiter les spécificités des aspects physiques des problèmes par la mise en place d’une méthode hybride (Gotoh et al., 2012 ; Lagaert et al., 2014). Une des problématiques traitées dans ce manuscrit concerne l’exploitation de l’analogie entre l’aspect hybride de la méthode numérique et la nature hétérogène des machines de calcul. Nous nous intéressons à exécuter les différents éléments de résolution sur différents composants des machines. Nous en exposerons les raisons dans le chapitre 6. La mise en œuvre d’une stratégie hybride sera explorée en combinant des méthodes numériques de diverses natures, des résolutions différentes et une implémentation sur architecture hétérogène. L’approche suivie repose sur une implémentation sur cartes graphiques d’une méthode particulaire avec remaillage. Cette dernière permet, entre autres, de résoudre naturellement des équations de conservations sans imposer de condition de type Courant-Friedrichs-Lewy mais une condition de stabilité moins restrictive permettant l’usage de plus grands pas de temps. L’utilisation de cette méthode conduit, à travers la présence d’une grille sousjacente, à des algorithmes et des structures de données régulières, ce qui est parfaitement adapté à l’emploi de cartes graphiques. Enfin, nous utiliserons la puissance de calcul offerte par les GPU pour proposer une extension à un ordre élevé de la méthode particulaire avec remaillage. L’analyse des schémas numériques se base sur une approche similaire à celle employée pour l’étude de schémas aux différences finies (Cottet et al., 2006). Un des aspects informatiques considéré est lié à la nécessité du développement d’un code de calcul portable et non spécifique à une architecture afin de supporter l’évolution rapide des matériels et des librairies. 2L’enchaînement des six chapitres de ce manuscrit reprend une démarche classique du calcul scientifique. En partant de la description des modèles puis des méthodes numériques et de leurs spécificités, on aboutit à l’implémentation générique multicœur GPU et hybride sur des machines hétérogènes combinant des processeurs multicœurs et des cartes graphiques. La progression et la répartition des différents chapitres sont schématisés par la figure 1. Chapitre 1 Chapitres 2 et 3 Chapitre 4 Chapitres 5 et 6 Modèle physique Modèle mathématique Modèle numérique Modèle algorithmique Implémentation Validation Observations Expériences Figure 1. – Cycle de résolution d’un problème en mathématiques appliquées Dans un premier chapitre, les modèles mathématiques pour la modélisation de fluides Newtoniens seront exposés. Nous présenterons également quelques méthodes numériques usuelles. Elles font appel à des ressources informatiques dont l’évolution, en termes de capacité et d’architecture, joue un rôle important dans le développement des codes de calcul. Une description des applications envisagées et notamment le transport de scalaire passif dans un écoulement turbulent terminera ce chapitre. Le second chapitre sera consacré à la description de la méthode particulaire avec remaillage. À travers une revue bibliographique de son évolution et de ses utilisations, nous exposerons l’analogie entre cette méthode et celle des différences finies. Cette revue sera complétée par une extension à un ordre élevé faisant intervenir la construction de formules de remaillage appropriées. Une analyse des schémas numériques en termes de consistance et de stabilité sera également développée. Dans un troisième chapitre, nous introduirons, à partir de travaux existants, la stratégie hybride envisagée pour la résolution de problèmes de transport de scalaire. Son application à un contexte de machine de calcul hétérogène sera abordé. Le quatrième chapitre sera consacré aux détails du développement d’une librairie de calcul scientifique portable et multiarchitecture. En particulier, nous verrons comment une conception souple simplifie l’utilisation de composants comme les cartes graphiques. Le chapitre cinq est dédié aux détails techniques de l’implémentation sur cartes graphiques de la méthode particulaire avec remaillage. Les choix d’implémentation seront éclairés par l’analyse de travaux similaires existants. Ce chapitre sera illustré par des exemples de transport de scalaire dans des cas où la vitesse est analytique afin de valider la méthode et d’en exposer les performances. Le 3Introduction générale sixième chapitre sera consacré à l’extension multi-GPU de la méthode. Une analyse de la stratégie de couplage entre la méthode hybride et l’architecture hétérogène des machines de calcul sera donnée à travers un exemple de transport turbulent de scalaire passif. Enfin, nous terminerons ce manuscrit par un chapitre de conclusion donnant lieu à une critique des travaux effectués ainsi qu’à un énoncé des perspectives dégagées par cette étude. 41. Calcul intensif pour la mécanique des fluides Le contexte des travaux de cette thèse est celui des mathématiques appliquées, au point de rencontre d’une application, d’une méthode numérique et d’un code de calcul. À partir d’observations de phénomènes naturels ou artificiels, des modèles physiques sont élaborés puis mis en équations sous la forme de modèles mathématiques. La spécialisation de ces modèles par rapport à une situation concrète se fait par la spécification de divers paramètres, de conditions initiales et de conditions aux limites des modèles. Ils expriment ainsi les conditions d’observations des phénomènes et le contexte expérimental des reproductions en laboratoire. Dans le cadre de simulations numériques, les modèles mathématiques sont discrétisés selon une ou plusieurs méthodes numériques conduisant à l’expression d’algorithmes qui sont implémentés dans des codes de calcul. L’exécution de ces codes sur des machines de calcul permet d’une part de valider les méthodes et les modèles par rapport aux phénomènes physiques mais aussi d’explorer les configurations qui ne sont pas aisément observables ou mesurables. Ce premier chapitre est dédié à la présentation du contexte mathématique de la mécanique des fluides à travers la construction du modèle des équations de Navier-Stokes. Nous donnerons ensuite quelques méthodes de résolution classiques. Dans un second temps, nous verrons que la mise en pratique des méthodes numériques est étroitement liée à l’exploitation des ressources de calcul. Une forte contrainte de portabilité et d’adaptivité pèse sur les algorithmes et leurs implémentations du fait de la rapidité à laquelle les technologies des machines évoluent. Afin de garantir une certaine pérennité pour les codes de calcul, il est nécessaire de prendre en compte, dès la conception, non seulement les types ressources et les technologies actuelles mais aussi à venir, en particulier dans la perspective de l’exascale. Dans ce cadre, une grande importance est attachée à l’évaluation des performances des implémentations et à des comparaisons d’algorithmes dont nous donnerons quelques mé- triques couramment utilisées. Enfin, nous détaillerons les modèles physiques des applications envisagées pour ce travail. 51. Calcul intensif pour la mécanique des fluides 1.1. Mécanique des fluides numérique L’objectif de la mécanique des fluides est d’analyser et de comprendre les comportements de fluides, qu’ils soient liquides ou gazeux, lorsqu’ils sont en mouvement et éventuellement en présence d’obstacles ou de structures avec lesquels ils interagissent. La majeure partie des problèmes de mécanique des fluides sont issus de l’ingénierie avec notamment l’industrie aéronautique et plus généralement les domaines des transports, de l’énergie, du génie civil et des sciences de l’environnement. Des applications portant sur l’étude de fluides moins conventionnels sont également considérées en biologie et par l’industrie agro-alimentaire. La modélisation mathématique de ces problèmes conduit à des systèmes d’équations trop complexes pour être résolus formellement. Dans de nombreux cas, la démonstration formelle de l’existence de solutions à ces système reste encore un problème ouvert. Une modélisation numérique de ces problèmes permet d’approcher une solution par l’utilisation de méthodes numériques. Les équations de Navier-Stokes permettent de décrire de manière générale le comportement d’un fluide en se basant sur des principes physiques de conservation de masse, de quantité de mouvement et d’énergie. 1.1.1. Modèle mathématique Équations de Navier-Stokes Conservation de la masse : Ce principe fondamental de la physique stipule que la masse totale contenue dans un système fermé reste constante au cours du temps. La matière, ou l’énergie, du système considéré peut éventuellement changer de forme ou se réarranger dans l’espace. La variation temporelle de la masse totale contenue dans un volume Ω est égale au bilan de masse traversant la frontière du domaine, ∂Ω : d dt Z Ω ρdx  = − I ∂Ω ρu · nds, où ρ est la masse volumique, u la vitesse et n la normale extérieure unitaire à la surface du volume de fluide Ω. L’équation se réécrit de manière équivalente sous sa forme locale : ∂ρ ∂t + div(ρu) = 0. (1.1) Conservation de la quantité de mouvement : De même, la variation temporelle de la quantité de mouvement d’un système, notée ρu, est égale à son bilan sur la frontière auquel s’ajoutent d’éventuelles forces F. On note u : u le produit tensoriel de u avec lui-même. Cela se traduit par la relation : d dt Z Ω ρudx  = − I ∂Ω ρu : u · nds + Z Ω Fdx, ou encore sous forme locale : ∂ρu ∂t + div(ρu : u) = F. 61.1. Mécanique des fluides numérique Le développement de cette équation se simplifie avec l’équation de conservation de la masse (1.1) pour donner : ρ  ∂u ∂t + (u · ∇)u  = F. Les forces F s’exerçant sur un volume de fluide se décomposent en deux termes selon leur nature : F = div σ¯¯ + fe . Les forces extérieures qui agissent sur l’ensemble du système sont notées fe , et les forces générées par les contraintes internes du fluide dépendent du tenseur des contraintes totales σ¯¯ qui se décompose également en deux termes : σ¯¯ = −PI ¯¯ + τ¯¯ , (1.2) où P est la pression, I ¯¯ le tenseur identité et τ¯¯ le tenseur des contraintes. Ainsi on obtient la formulation suivante : ρ  ∂u ∂t + (u · ∇)u  = −∇P + div τ¯¯ + fe . (1.3) Loi de comportement : Le tenseur des contraintes τ¯¯ issu de la décomposition du tenseur des contraintes totales (1.2) permet de modéliser le comportement d’un fluide en particulier. Dans le cadre de fluides Newtoniens, le tenseur des contraintes est proportionnel au taux de déformations : τ¯¯ i,j = ν  ∂ui ∂xj + ∂uj ∂xi  , avec ν la viscosité dynamique du fluide. Lorsque la viscosité ne dépend pas de l’espace, on a : div τ¯¯ = ν (∆u − ∇ div u). (1.4) Équations de Navier-Stokes : Dans le cadre général, les équations de Navier-Stokes constituent un système d’équations aux dérivées partielles obtenues à partir des équations de conservation de masse, (1.1), de quantité de mouvement (1.3) et de la loi de comportement du fluide (1.4).    ∂ρ ∂t + div(ρu) = 0, ρ  ∂u ∂t + (u · ∇)u  = −∇P + ν (∆u − ∇ div u) + ρfe . (1.5) Les inconnues du problème sont la vitesse u, la masse volumique ρ, et la pression P. Une troisième équation est alors nécessaire pour obtenir un modèle complet. Une équation de conservation de l’énergie est généralement utilisée. Les forces extérieures sont à préciser selon le cas d’étude. 71. Calcul intensif pour la mécanique des fluides Formulation vitesse-vorticité : Dans bon nombre d’écoulements, les zones d’intérêts, où se forment et évoluent des tourbillons, sont généralement de petite taille relativement au domaine d’étude et se localisent, entre autres, dans les couches limites et les sillages. Il est naturel d’employer une formulation adaptée. La vorticité de l’écoulement ω est un champ vectoriel défini comme le rotationnel du champ de vitesse. ω = rotu (1.6) On obtient la formulation vitesse-vorticité en appliquant l’opérateur rotationnel à la seconde équation du système (1.5) : ρ  ∂ω ∂t + (u · ∇) ω  = ρ(ω · ∇)u + ν∆ω + ρ rot fe . (1.7) Fluides incompressibles Hypothèse d’incompressibilité : Dans de nombreux cas, les fluides considérés ont une très faible compressibilité. Un fluide est dit incompressible lorsque que la variation de volume sous l’effet d’une pression extérieure est négligée. Cette hypothèse n’est valide que lorsque la vitesse du fluide est inférieure à la vitesse du son dans ce fluide. Dans ce cas, la densité ρ est approchée par une constante, l’équation (1.1) se réduit à : div u = 0, (1.8) et la loi de comportement (1.4) se simplifie en : div τ¯¯ = ν∆u. (1.9) L’obtention d’un champ de vitesse à divergence nulle, vérifiant (1.8), est généralement effectuée par l’utilisation d’une méthode de projection. Cette méthode a été introduite par Chorin (1968) et Temam (1968) et se base sur une décomposition du champ de vitesse selon une composante à divergence nulle et une composante à rotationnel nul : u = u∇ + ∇φ, avec div u∇ = 0 et rot ∇φ = 0. En pratique, un champ de vitesse intermédiaire u ∗ à divergence non nulle est obtenu par la méthode de résolution puis la fonction scalaire φ est obtenue par résolution d’une équation de Poisson : div u ∗ = ∆φ, et enfin le champ de vitesse incompressible est calculé simplement par : u = u ∗ −∇φ. Dans le cas de la formulation vitesse-pression, la pression peut jouer le rôle de la fonction scalaire φ. Équations de Navier-Stokes pour les fluides Newtoniens incompressibles : À l’aide de l’hypothèse d’incompressibilité (1.8) et pour une loi de comportement correspondant à un fluide Newtonien (1.9), le système générique (1.5) se réécrit :    div u = 0, ρ  ∂u ∂t + (u · ∇)u  = −∇P + ν∆u + ρfe . (1.10) 81.1. Mécanique des fluides numérique La formulation vitesse-vorticité conduit au système suivant :    div u = 0, ω = rotu, ρ  ∂ω ∂t + (u · ∇) ω  = ρ(ω · ∇)u + ν∆ω + ρ rot fe . (1.11) La vorticité et la vitesse sont couplées par la relation ω = rotu, ou bien, de façon équivalente, par une équation de Poisson, en utilisant ∇ · u = 0 : ( ∆ψ = −ω, u = rot ψ. (1.12) 1.1.2. Principales méthodes de résolution Dans cette section nous donnons quelques unes des méthodes de résolution classiques des équations précédentes. La plupart de ces méthodes ne se restreignent pas à la mécanique des fluides et sont utilisées pour résoudre des problèmes aux dérivées partielles plus généraux. Méthodes Eulériennes Dans le cas des méthodes Eulériennes, la discrétisation des équations se fait par un découpage du domaine de calcul en un maillage, structuré ou non. Un maillage structuré se caractérise par une connectivité régulière des éléments, ce qui permet un accès efficace aux données des éléments voisins. Dans le cas non structuré, une table de connectivité définissant les relations de voisinage est nécessaire et permet alors une meilleure discrétisation de géométries complexes. Différences finies La plus ancienne et la plus simple de ces méthodes est celle des différences finies. Elle a été formalisée par Euler en 1768. La méthode est construite sur la définition de la dérivée : U 0 (x) = lim h→0 U(x + h) − U(x) h , qui se généralise sous la forme d’un développement limité : U(x + h) = U(x) + hU0 (x) + h 2 2 U 00(x) + · · · (1.13) Lorsque la quantité h représente une distance entre deux points d’une grille et que la quantité U est approchée en chaque point xi par U(xi) = Ui , le développement précédent, tronqué au premier ordre, donne le schéma aux différences finies du premier ordre décentré en amont suivant : U 0 i = Ui+1 − Ui h + O(h). (1.14) Il est possible de combiner différents développements d’ordres plus élevés pour construire des schémas d’ordre plus élevés ou approcher des dérivées d’ordres supérieurs. Ces schémas 91. Calcul intensif pour la mécanique des fluides peuvent être étendus pour l’approximation de variables multidimensionnelles, puis à la discrétisation de dérivées partielles. Le cas des grilles non uniformes se traite en prenant un paramètre h dépendant de la grille. Au point d’indice i, on a hi = xi+1 − xi . Ainsi la méthode conduit à un calcul relativement simple à mettre en œuvre, dans les cas explicites, avec un schéma identique sur chaque point du domaine. Dans les cas implicites, il est nécessaire de résoudre un système linéaire. L’inconvénient majeur de cette méthode est la difficulté de prise en compte de géométries complexes. Volumes finis La méthode des volumes finis, est aujourd’hui très largement utilisée, notamment par les industriels dans les domaines de l’aéronautique et de l’hydrodynamique. Cette popularité vient, entre autres, du fait que le caractère conservatif des équations est traduit directement dans la discrétisation. De plus cette méthode s’adapte parfaitement à de nombreux problèmes qu’ils soient en domaines fermés ou ouvert et sur des discrétisation spatiales structurées ou non. Cette méthode permet de résoudre une équation de conservation, sous forme intégrale : ∂ ∂t Z Ω UdΩ + I S F · dS = Z Ω QdΩ, (1.15) où U représente le vecteur des variables conservatives, F est un flux et Q un terme source. La discrétisation de ces équations repose sur le découpage du domaine de calcul en petits volumes de contrôle ΩJ autour d’un point de maillage J. L’équation (1.15) se discrétise donc sur chaque volume élémentaire par la relation suivante : ∂ ∂t (UJΩJ ) + X Ωk∈ voisins de Ωj Fk,j · Γk,j = QJΩJ , (1.16) puis est intégrée entre deux instants consécutifs tn et tn+1. Les quantités UJ et QJ sont les valeurs moyennées sur ΩJ à l’instant tn. Ainsi, il est possible d’utiliser un schéma d’inté- gration en temps implicite ou explicite. L’application de ce schéma nécessite une méthode de calcul des flux Fk,j traversant la face Γk,j commune aux éléments de maillage Ωj et Ωk. En plus du calcul des flux en chaque face du maillage, la méthode nécessite un calcul direct, dans le cas explicite en temps, ou la résolution d’un système, pour le cas implicite. Le principal inconvénient de cette méthode est la difficulté de la montée en ordre. Éléments finis La méthode des éléments finis est issue du domaine de la mécanique des structures. Elle repose sur des principes bien plus abstraits que ceux des deux méthodes précédentes. L’espace est discrétisé en un ensemble de cellules appelés éléments et se base sur une formulation intégrale du problème. Le point clé de la méthode consiste à exprimer le problème sous forme variationnelle, à partir de sa formulation intégrale. Cette formulation variationnelle du problème fait intervenir des espaces fonctionnels qu’il est nécessaire de décrire avec précision ainsi que les normes qui leur sont associées afin de pouvoir déterminer certaines propriétés de convergence. Les espaces fonctionnels utilisés définissent des classes d’éléments finis sur les élé- ments de maillage. À partir de ce maillage, le plus souvent non structuré, il est nécessaire de 101.1. Mécanique des fluides numérique définir des fonctions d’interpolation des variables du problème sur les éléments du maillage. La discrétisation de la formulation variationnelle sur ces éléments conduit à l’obtention d’un système linéaire creux dont la taille dépend de la finesse du maillage. L’approximation d’une quantité u sur un élément se fait par combinaison linéaire des fonctions de base vI pour chaque nœud I de l’élément. u˜(x) = X I uIvI (x). (1.17) Selon l’ordre d’approximation, les nœuds sont définis aux sommets, sur les arrêtes ou encore à l’intérieur des éléments du maillage. Une fois la discrétisation effectuée, la solution est calculée par l’inversion d’un système linéaire dont la taille dépend du nombre d’éléments et du nombre de degrés de libertés associé. Le cadre mathématique de cette méthode permet de réaliser des études des propriétés numériques des schémas, une montée en ordre assez aisée ainsi que la prise en compte de géométries complexes. Toutefois, le système linéaire obtenu, peut parfois être difficile à résoudre. Pour cela des méthodes itératives avec préconditionnement sont généralement employées. D’autre part, l’inversion d’un système de grande taille creux n’est pas parallélisable aisément sans utiliser de méthodes additionnelles, de décomposition de domaine par exemple. Dans le cas des équations de Navier-Stokes, les variables ne sont pas exprimées dans les mêmes espaces fonctionnels. L’introduction de contraintes supplémentaires entre les classes d’éléments finis utilisés pour discrétiser la vitesse et la pression permettent d’assurer la convergence. Cette méthode n’est pas la plus adaptée pour la résolution de problèmes dont la physique est dominée par l’advection. Dans un contexte de mécanique des fluides, elle est utilisée essentiellement pour des simulations de fluides complexes. Méthodes spectrales Le principe général des méthodes spectrales est de transformer l’ensemble du problème dans un espace spectral. Pour ce faire, on exprime les variables du problème dans cet espace, par exemple en séries de Fourier tronquées : u(x, t) = X N/2 k=−N/2 uˆk(t)e ik·x , avec uˆk(t) les coefficients de Fourier tels que : uˆk(t) =  1 2π 3 Z 2π 0 u(x, t)e −ik·xdx. Avec ces représentations, le système d’équations à résoudre se réécrit pour les uˆk. On aboutit généralement à un système d’équations différentielles ordinaires complexes ne dépendant que du temps. Les équations dans l’espace spectral sont généralement plus simples à résoudre que dans l’espace réel et permettent une précision numérique très importante même avec un petit nombre de coefficients. Néanmoins, il est assez difficile de traiter, avec cette méthodes, des domaines non périodiques ainsi que des géométries complexes. De plus, les transformations dans l’espace spectral impliquent un calcul global sur l’ensemble du domaine. 111. Calcul intensif pour la mécanique des fluides L’utilisation de méthodes spectrales nécessite quelques précisions quant à leur mise en œuvre sur des équations non linéaires. En effet, un produit de fonctions ou des termes non linéaires dans l’espace réel conduisent à des opérations de type convolution en espace complexe. Dans le cas discret, une erreur d’aliasing apparaît lors du calcul de ces termes de manière directe. Il existe différentes techniques de suppression de cette erreur. La règle des 3/2 est couramment utilisée et son principe est de réaliser les transformées de Fourier discrètes sur M points au lieu de N, avec M > 3N/2. Les coefficients de Fourier des termes du produit de convolution pour des nombres d’ondes supérieurs à N/2 sont simplement pris égaux à zéro. De même, le résultat est tronqué aux N premiers coefficients permettant, par transformée inverse, d’obtenir les valeurs réelles. En 3D, des erreurs d’aliasing doubles et triples sont corrigées par des des troncatures adaptées (Canuto et al., 1987). Méthodes de Lattice Boltzmann Cette classe de méthode n’est pas basée sur la résolution des équations de Navier-Stokes mais sur une équation de Boltzmann qui modélise l’évolution cinétique de particules de fluide (Chen et al., 1998). La méthode de Lattice Boltzmann dérive d’un modèle discret de dynamique particulaire sur une grille qui peut être vu comme un automate cellulaire (Lattice gaz method). Le principe de base de cette méthode est de modéliser l’évolution d’une fonction de distribution de la vitesse des particules f en fonction d’un opérateur de collision Ω pour les interactions entre particules : fi(x + ei , t + ∆t) = fi(x, t) + Ωi(f(x, t)). (1.18) Cette équation est donnée pour chaque direction i de la grille utilisée. La figure 1.1 représente les vecteurs ei utilisés dans des grilles courantes. La notation DxQy est employée pour référencer ces grilles où x est la dimension de l’espace et y le nombre de vecteurs ei considérés. (a) Grille D2Q9 (b) Grille D3Q15 Figure 1.1. – Exemple de grilles pour la méthode Lattice Boltzman Les grandeurs macroscopiques de l’écoulement sont retrouvées à partir des moments de f : ρ = X i fi et ρu = X i fiei . Dans le cas le plus simple, un modèle de collision de Bhatnagar-Gross-Krook (BGK) permet d’exprimer Ωi comme une relaxation vers une distribution à l’équilibre f eq i en un temps caractéristique τ : Ωi = f eq i − fi τ , 121.1. Mécanique des fluides numérique avec : f eq i = ρwi  1 + 3ei · u + 9 2 (ei · u) 2 − 3 2 u 2  , (1.19) où les wi sont des poids associés à chaque direction ei . Le schéma numérique obtenu est local et la mise en œuvre est généralement réalisée en deux étapes. Dans un premier temps, le membre de droite de l’équation (1.18) est évalué avec le modèle de collision (1.19). Dans un second temps, l’équation (1.18) est résolue dans une étape de propagation des fonctions de distribution. Méthodes Lagrangiennes De manière générale, les méthodes Lagrangiennes sont adaptées à la résolution d’équations de conservation de la forme : d dt Z Ω U(x, t)dx = Z Ω F(x, t, U, ∇U, . . .)dx. (1.20) Elles se distinguent des méthodes Eulériennes par le fait que la discrétisation spatiale du domaine de calcul par un ensemble de particules suit la dynamique du système contrairement au cadre Eulérien où le maillage reste fixe. On définit la dérivée Lagrangienne d’une fonction f à partir de la trajectoire d’un point de l’écoulement. Df Dt (x(t), t) = ∂f ∂t (x, t) + dx dt · ∇f(x, t) = ∂f ∂t (x, t) + (u · ∇)f(x, t) (1.21) Dans un cadre Lagrangien, les variables sont discrétisées sur un ensemble de particules qui correspondent à un volume élémentaire du domaine. Le principe général est que les particules portent des quantités correspondant aux variables du problème. Une quantité U est ainsi approchée par l’ensemble des particules selon la formule : U(x) = Z Ω U(y)δ(x − y)dy, (1.22) ou sa forme discrète régularisée : U(x) ' X p UpWε(x − xp). (1.23) La quantité portée par la particule p, est donnée par sa valeur moyenne : vpUp = Z Vp U(x)dx, sur le volume Vp. La fonction Wε, qui apparaît dans l’équation (1.23) est une fonction de régularisation dont le choix et les propriétés sont propres à chaque méthode. Dans tous les cas, elle est construite de telle sorte que sa limite quand ε tend vers 0 soit la mesure de Dirac δ. 131. Calcul intensif pour la mécanique des fluides Au cours de la résolution, les particules sont déplacées relativement au champ de vitesse puis interagissent pour donner une nouvelle répartition des quantités transportées qui conduisent à un nouveau champ de vitesse. La position de chaque particule, xp, est solution d’une équation de mouvement : dxp dt = u(xp, t). (1.24) D’autre part, la discrétisation de l’équation (1.20) donne le système d’équations différentielles : dUp dt = vpFp, (1.25) où Fp représente le terme source local à la particule p. La difficulté de ces méthodes réside dans le calcul du second membre de cette équation, en particulier le terme Fp, à partir des particules. Différentes approches sont possible et conduisent à des méthodes comme SPH et Vortex, détaillées plus loin. Enfin, le volume des particules varie selon l’équation : dvp dt = vp div u(xp). (1.26) Une propriété remarquable des méthodes particulaires est que la stabilité du schéma numérique ne dépend pas explicitement du maillage ou de la distance entre deux particules contrairement aux méthodes Eulériennes dont le pas de temps est contraint par une condition de Courant Friedrichs Lewy, notée CF L, dont la constante C est souvent inférieure à 1. CF L = ∆t||u||∞ ∆x 6 C (1.27) Dans le cas des méthodes particulaires, la contrainte sur le pas de temps dépend du gradient du champ de vitesse et consiste en l’inégalité suivante : LCF L = ∆t||∇u||∞ 6 C (1.28) En pratique, la constante C, appelée quelquefois nombre LCFL (pour Lagrangian CFL), conduit à une condition moins restrictive que la condition de CFL (1.27). Cela permet géné- ralement d’utiliser de plus grands pas de temps que dans le cas d’une méthode Eulérienne, le nombre de CFL obtenu peut alors atteindre des valeurs de plusieurs dizaines. Méthode SPH Dans la méthode Smoothed Particle Hydrodynamics (SPH), les dérivées spatiales des variables sont calculées sur les particules à partir d’une régularisation de la mesure de Dirac, à l’aide d’un noyau Wε. Pour tendre vers la mesure de Dirac lorsque ε tend vers 0, la fonction Wε est construite à partir d’une fonction d’intégrale égale à 1, à symétrie radiale et à support compact de rayon supérieur à ε (Liu et al., 2010). Enfin le noyau Wε doit être suffisamment régulier pour approcher les dérivées spatiales des variables intervenant dans le calcul des forces. Le principe suppose qu’en plus de l’équation d’approximation (1.23), on dispose d’approximations des dérivées obtenues à partir des dérivées de Wε : ∇U(xi) ' X p U(xp)∇Wε(xi − yp )vp. (1.29) 141.1. Mécanique des fluides numérique Ainsi, avec un schéma d’intégration en temps explicite et une discrétisation du membre de droite de l’équation (1.20), on obtient le schéma de résolution globale. Les sommes dans les équations (1.23) et (1.29) impliquent des interactions entre toutes les paires de particules. Cependant, la compacité du support de la fonction Wε permet de ne considérer que les particules les plus proches du point de calcul courant à l’aide d’un tri des particules. Les particules dont le support du noyau d’interpolation intersecte le bord du domaine nécessitent un traitement particulier en fonction des conditions limites. L’inconvénient majeur de cette méthode est la difficile montée en ordre du schéma de résolution. Méthode vortex La méthode vortex est une méthode Lagrangienne adaptée à la résolution des équations de Navier-Stokes en formulation vitesse et vorticité (1.11). Les particules portent alors la vorticité de l’écoulement, selon l’approximation (1.23) : ω(x) = X p ωpWε(x − xp). (1.30) La méthode développée par Chorin (1973) et Leonard (1980) conduit à résoudre le système d’équations différentielles suivant :    dxp dt = u(xp), (1.31a) dωp dt = ωp∇u(xp) + ν∆ω(xp). (1.31b) Le champ de vitesse est alors obtenu en résolvant l’équation de Poisson (1.12) en fonction de la vorticité portée par les particules : u(x) = u∞ + Z Ω Kε(x − y)ω(y)dy. (1.32) Le noyau Kε est une régularisation d’un noyau obtenu par le rotationnel de la solution fondamentale de l’équation de poisson. Ce noyau s’exprime comme la convolution de la fonction de Green pour l’opérateur laplacien et du champ de vorticité. D’autre part, le gradient du champ de vitesse est obtenu par : ∇u(x) = Z Ω ∇Kε(x − y)ω(y)dy. Différentes techniques peuvent être employées pour discrétiser le terme de diffusion des équations (1.31). Nous pouvons citer par exemple la méthode de marche aléatoire, Randomwalk, introduite par Chorin (1973) ou encore la méthode PSE, Particle Strength Exchange par Degond et al. (1989) et Cottet et al. (1990). La discrétisation du terme d’étirement au second membre de l’équation (1.31b) et de l’équation de Poisson par une équation de Biot-Savart (1.32) nécessitent l’évaluation d’interactions entre toutes les paires de particules, ce qui engendre une complexité en O(N2 ) pour N particules. Une complexité en O(N) est possible en utilisation une méthode FMM (Fast Multipole Method). Cette dernière consiste en un algorithme hiérarchique, basé sur un arbre, permettant de traiter des problèmes à N corps par une approximation des interactions combinant des développement locaux et multipôles du noyau Kε (Cheng et al., 1999). 151. Calcul intensif pour la mécanique des fluides Méthode particulaire avec remaillage Cette méthode faisant l’objet du chapitre 2, nous donnons ici uniquement l’idée générale de la méthode. Le remaillage est employé dans les méthodes particulaire, en particulier les méthodes Vortex, et consiste en une redistribution des particules sur une grille (Koumoutsakos et al., 1995). Il permet d’assurer le recouvrement nécessaire au maintient des propriétés de convergence de la méthode. La méthode obtenue lorsque le remaillage est effectué systématiquement à chaque itération s’apparente à une méthode semi-Lagrangienne explicite. Ainsi, après une advection des particules de manière Lagrangienne, une étape de remaillage permet de redistribuer les quantités portées par les particules sur une grille sous-jacente. Enfin les termes d’étirement et de diffusion ainsi que l’équation de Poisson peuvent être résolus sur cette grille. Qualité des résultats numériques Toutes ces méthodes de résolution reposent sur une approximation numérique des variables et des équations. Le principe commun est de discrétiser le domaine de calcul en divers éléments : grille, maillage ou particules. Dans tous les cas, la solution est donnée sur ces éléments discrets. Ainsi, l’augmentation du nombre d’éléments conduit à un meilleur niveau de détail de la solution. Une discrétisation temporelle plus fine permet également une meilleure description de la solution. Cependant, les pas de temps sont généralement choisis les plus grands possibles tout en veillant à préserver la stabilité du schéma. D’autre part, la plupart des méthodes permettent une estimation de l’erreur d’approximation des équations par le schéma numérique. Cette erreur s’exprime généralement en fonction des résolutions spatiales et temporelles de la discrétisation. En contrepartie de l’amélioration de la précision et du niveau de détail des solutions, le coût de calcul augmente avec la résolution. Ce coût provient du nombre d’opérations arithmétiques à réaliser mais aussi du stockage et de l’accès aux données. En pratique, l’obtention de résultats pour une résolution plus fine permet généralement une plus grande précision dans la prise en compte des phénomènes physiques, ce qui contribue à une meilleure compréhension des mécanismes mis en jeu. La conséquence de ce phénomène est que les ressources informatiques nécessaires à un raffinement des solutions numériques deviennent importantes et que les stratégies mises en œuvre pour l’implémentation des méthodes ont un impact direct sur cette augmentation de qualité numérique. 1.1.3. Exemples d’application Dans ce paragraphe nous donnons quelques exemples d’implémentation des méthodes décrites précédemment dans un contexte de calcul à haute performance. L’objectif est simplement d’illustrer comment sont employées les différentes méthodes numériques à travers les quantités de ressources de calcul nécessaires. Récemment, une méthode de volumes finis a été implémentée par Rossinelli et al. (2013) pour la simulation de la coalescence de 15 000 bulles de vapeur. Les auteurs ont réalisé des simulations allant jusqu’à 13.1012 points de calcul en utilisant 1,6 millions de cœurs CPU. Les performances obtenues sont, en partie, dues à l’utilisation de schémas numériques 161.2. Calcul intensif d’ordre élevés en espace ce qui conduit à un nombre d’opérations par itérations élevé. Les auteurs emploient également des techniques permettant d’augmenter la localité des données ainsi que des opérations vectorisées spécifiques à la machine utilisée. L’écoulement autour d’un modèle complet de voiture a été étudié par Jansson et al. (2011) en utilisant une méthode de résolution par éléments finis. Le domaine de calcul est discrétisé par 4,5 millions de points et 24 millions d’éléments et les solutions sont obtenues en utilisant 3 000 cœurs CPU. Cette étude montre que les résultats obtenus par une méthode par éléments finis associée à simulation aux larges échelles adaptative et à un raf- finement automatique de maillage sont comparables, voire meilleurs, que certains modèles de turbulence. Enfin, une comparaison de méthodes spectrales et vortex est réalisée par Yokota et al. (2013) sur 4 000 cartes graphique pour des résolutions de 69 milliards de particules ou points de calcul dans le cadre de simulations de turbulence homogène. Dans cet article, les auteurs montrent les limites des méthodes spectrales lors de l’utilisation d’un très grand nombre de cartes graphiques. En particulier, les opérations non locales des transformées de Fourier engendrent un coût de communication très important, ce qui n’est pas le cas en utilisant une méthode multipôle rapide (Fast Multipole Method). Ainsi, l’étude montre que la méthode FMM permet d’atteindre une efficacité parallèle bien meilleure que les méthodes spectrales sur plusieurs milliers de cartes graphiques. Ces études montrent l’importance d’une bonne exploitation des ressources informatiques. En général, les méthodes numériques ne sont pas directement adaptées à de grandes machines de calcul car les coûts de communication deviennent prohibitifs. Ainsi, il est nécessaire de prendre en compte ces architectures au niveau de la méthode numérique développée. L’implémentation de méthodes numériques, nécessaire à la résolution de nombreux problèmes physiques, est indissociable des ressources informatiques disponibles. En particulier lorsque les applications considérées nécessitent un haut niveau de détail des solutions, ce qui implique un coût de calcul élevé. 1.2. Calcul intensif Le calcul intensif est un domaine de l’informatique qui consiste à utiliser des supercalculateurs pour des applications relevant généralement du calcul scientifique. L’objectif est d’exploiter au maximum de leurs performances l’ensemble des ressources disponibles pour obtenir la solution d’un problème numérique. On distingue deux contextes d’utilisation intensive des ressources de calcul. Le premier, que nous considérerons par la suite, consiste à résoudre un seul problème sur un ensemble de ressources d’une machine de calcul. Dans ce cas, la méthode numérique employée est distribuée sur les éléments de calculs de manière collaborative, ce qui implique des communications entre les éléments. Une machine de calcul est constituée de différents niveaux hiérarchiques de ressources. Elle est composée de nœuds de calcul interconnectés sur lesquels est installé un système d’exploitation. Un nœud comprend généralement de la mémoire vive, un disque local, des processeurs et éventuellement des accélérateurs, coprocesseurs ou cartes graphiques. Ces ressources sont partagées par les différents processeurs multicœurs. Les uti- 171. Calcul intensif pour la mécanique des fluides lisateurs se partagent la machine et peuvent réserver des ressources selon leurs besoins par l’intermédiaire d’un gestionnaire de ressources. D’un autre côté, pour des calculs d’optimisation, des études de sensibilité par rapport à des paramètres ou des calculs de quantification d’incertitudes, le problème initial est de taille relativement modeste mais il doit être résolu un très grand nombre de fois à partir de données initiales différentes . Pour cela, des grilles de calcul sont utilisées, comme par exemple dans le projet Folding@home de l’Université de Standford. Dans ce cadre, un réseau composé d’un très grand nombre de machines grand public est constitué à travers Internet par les utilisateurs volontaires et est en perpétuelle évolution au gré des connexions et déconnexions des utilisateurs. Les différentes exécutions sont indépendantes et ne nécessitent pas de communications entre elles. Une des difficultés techniques rencontrées dans ce contexte est que les machines présentent de très nombreuses caractéristiques différentes notamment en termes de matériels et de systèmes d’exploitation. 1.2.1. Augmentation des besoin et des ressources de calcul Ressources de calcul pour les simulations numériques Comme nous l’avons vu en section 1.1.2, l’obtention de nouveaux résultats physiques permettant une meilleure compréhension des phénomènes se fait par une amélioration de la précision et du niveau de détail des résultats numériques. Pour la plupart des méthodes cela implique une complexité plus grande aussi bien en terme de calcul qu’en terme de quantité de données. Le temps de calcul est directement lié à cette complexité et augmente rapidement avec la résolution. C’est pourquoi il est nécessaire, pour rendre réalisable cette augmentation, que le temps de calcul soit le plus faible possible. Par exemple, lorsque l’on souhaite simplement doubler la résolution dans toutes les directions spatiales d’un problème tridimensionnel, on obtient un facteur 8 sur le nombre total d’éléments. Ce qui implique un facteur au moins égal à 8 sur l’empreinte mémoire du code. De même, la complexité algorithmique du code est multipliée par un facteur 8, 16 ou 64 selon que la complexité s’exprime en O(N), O(N ln(N)) ou O(N2 ). Cela implique que le coût total de calcul devient rapidement assez élevé et justifie le recours à des techniques de parallélisation mises en places dans le cadre du calcul intensif. Deux points de vue sont envisageables. D’une part, pour un problème donné, l’augmentation des ressources allouées à sa résolution permettent de réduire le temps nécessaire à l’obtention de la solution. D’autre part, à temps de calcul constant, une solution plus précise est obtenue en augmentant conjointement les ressources et la taille du problème. Augmentation de la puissance de calcul des machines Loi de Moore Une caractéristique marquante de l’évolution de l’informatique est la loi de Moore, énoncée en 1965 par un des cofondateur d’Intel, G. Moore. En considérant la complexité de fabrication des circuits intégrés ainsi que leur coût en fonction du nombre de transistors, Moore postule que le nombre de transistors par puce double chaque année. Il observe par la suite, en 2005, que cette croissance est légèrement plus faible mais tout de 181.2. Calcul intensif même exponentielle. Nous illustrons cette loi en figure 1.2 où le nombre de transistors par processeur en fonction des dates de mise sur le marché suit une tendance exponentielle. Il 103 104 105 106 107 108 109 1010 1970 1975 1980 1985 1990 1995 2000 2005 2010 2015 Nombre de transistors par puce Année de mise sur le marché CPU GPU Tendance : 1.4 x Tendance : 1.6 x Figure 1.2. – Évolution du nombre de transistors par processeurs. est à noter que les processeurs graphiques suivent également une tendance similaire. Top500 Depuis 1993, le projet Top500 établit un classement mondial des 500 machines les plus performantes. La figure 1.3 montre l’évolution de la puissance de calcul théorique développée par ces machines. Sur cette figure sont représentés les machines de rang 1 et 500 ainsi que quelques composants introduits sur le marché en 2012 et 2013. Ces courbes conduisent à deux remarques : en 8 ans, une machine donnée passe de la première à la dernière place du classement ; sur la même durée, la puissance totale de la dernière machine du classement est disponible en un seul composant sur le marché grand public. Ainsi, une machine de bureau standard récente dispose de la puissance de calcul de la première machine du classement il y a 20 ans. La tendance de ces courbes laisse suggérer que le régime de l’exascale sera vraisemblablement atteint d’ici 2020 (Shalf et al., 2010 ; Dongarra et al., 2011 et 2014). Il correspond à la construction et à l’exploitation de systèmes capables d’exécuter 109 GFLOPS. C’est un défi majeur dans la communauté du calcul haute performance. Dans les années 90, l’augmentation de la puissance des machines était principalement due à l’augmentation de la fréquence des processeurs et à la diminution de leurs taille. Ce mécanisme a atteint ses limites principalement à cause d’une trop forte densité d’énergie dans les composants. Par la suite, seule l’augmentation du nombre de processeurs par machine a permis de poursuivre cette évolution. Désormais, la tendance serait plutôt à l’augmentation du nombre de cœurs par processeurs comme c’est le cas, entre autres, avec les cartes graphiques et la dernière génération de processeurs Intel Xeon Phi. 191. Calcul intensif pour la mécanique des fluides 10−1 100 101 102 103 104 105 106 107 108 109 1993 1995 1997 1999 2001 2003 2005 2007 2009 2011 2013 2015 Petascale Exascale 8 ans 8 ans 8 ans 12 ans 8 ans Puissance théorique (GFLOPS) Année de publication Top500 #1 Top500 #500 GPU Coprocesseur CPU Machine standard Figure 1.3. – Évolution du classement du TOP500 Difficulté d’adaptation des codes de calcul Le détail des caractéristiques des machines du Top500 montre une hétérogénéité de composants depuis ces dernières années. En effet, bon nombre de machines de ce classement ne contiennent pas seulement des processeurs mais aussi des accélérateurs, que ce soit des cartes graphiques ou des coprocesseur. La difficulté majeure de l’exploitation de ces élé- ments est que le développement et l’optimisation des codes de calculs ne fait pas appel aux mêmes techniques que sur une machine homogène. De plus, les techniques de programmation sont parfois différentes entre les processeurs et les accélérateurs. Ce qui implique une réécriture du code. D’autre part, la réutilisation d’un code sur une architecture plus récente conduit parfois à des temps de calculs plus grands dans les cas où aucune adaptation n’est réalisée. Ce travail est assez lourd et ne peut pas être réalisé pour chaque nouvelle architecture. Toutefois, cette difficulté est atténuée par l’utilisation de langages portables pour le développement de codes multiarchitectures. 1.2.2. Mesure de performances Dans le cadre du calcul intensif, il est important de pouvoir comparer les différentes implémentations et codes de calculs et d’en mesurer les performances. Pour cela des métriques spécifiques sont utilisées. La première métrique utilisée est la puissance brute développée par un algorithme. Cette grandeur est exprimée par le nombre d’opérations sur des nombres réels à virgules flottante réalisées par secondes d’exécution. On utilisera la notation FLOPS pour désigner cette unité, également notée FLOP s−1 dans la littérature. Cette mesure est notamment utilisée pour établir le classement du Top500, En pratique, le nombre d’opérations effectuées lors d’une 201.2. Calcul intensif exécution peut être obtenu par un outil de profilage et dépend fortement du compilateur, des options de compilations employées ainsi que de l’architecture utilisée. Scalabilité Scalabilité forte Lors de la parallélisation d’un code, la performance maximale atteignable est bornée par la loi d’Amdahl donnée par Rodgers (1985). L’accélération maximale dépend de la proportion de code parallélisable, notée p ∈ [0; 1]. Le temps de calcul total, pour un problème de taille fixe, sur n processeurs Tn est donné en fonction du temps de calcul séquentiel T1 par : Tn = T1(1−p+p/n). Le facteur d’accélération, Sn, égal au rapport entre le temps de calcul sur n processeurs et le temps de calcul sur un seul processeur est alors donné par l’expression : Sn = T1 Tn = 1 1 − p + p/n < n. (1.33) On remarque que lorsque le nombre de processeurs devient grand, le rapport tend vers (1 − p) −1 . Cela signifie que l’accélération maximale, lorsque la partie parallélisable devient négligeable, est bornée par la partie non parallélisable du code. De manière optimale, pour p = 1, on attend que le facteur d’accélération du code soit égal au nombre de processeurs. La performance d’un code peut être mesurée en réalisant une étude de scalabilité forte. Il s’agit d’étudier l’évolution du facteur d’accélération du code pour un problème de taille fixe en faisant augmenter les ressources employées à la résolution. Généralement, ces résultats sont présentés sur un graphe donnant le rapport T1/Tn en fonction de n. Une scalabilité idéale conduit à l’obtention d’une droite de pente égale à 1. Scalabilité faible On peut également considérer l’évolution du facteur d’accélération lorsque l’augmentation des ressources est réalisée simultanément avec une augmentation de la taille des données du problème. Dans ce cas, la loi de Gustafson-Barsis (Gustafson, 1988) conduit à une décomposition du temps de calcul sur n processeurs en une partie séquentielle ts et une partie parallèle tp, Tn = ts + tp. Ainsi, le temps de calcul de ce problème sur un seul processeur est égal à T (n) 1 = ts + ntp et le facteur d’accélération est donné par : Sn = T (n) 1 Tn = n − ts ts + tp (n − 1) (1.34) De même que précédemment, on représente Sn en fonction de n dans un graphe. Dans le cadre d’une étude de scalabilité faible, à chaque Sn correspond une taille de problème contrairement à la scalabilité forte où l’étude complète est réalisée pour une même taille de problème. Dans le cas idéal, le temps de calcul est entièrement dédié à la partie parallèle, ts = 0, on obtient une droite de pente 1. Le temps de calcul séquentiel du problème associé à n processeur, T (n) 1 , peut parfois devenir prohibitif et même impossible à obtenir lorsque n est grand. Pour cela, on pose l’hypothèse que ce temps est proportionnel au temps de calcul séquentiel du problème unitaire T (n) 1 = nT(1) 1 . On représente alors le facteur d’accélération par : S˜ n = T (1) 1 Tn = T (n) 1 nTn = 1 − ts(n − 1) n(ts + tp) . (1.35) 211. Calcul intensif pour la mécanique des fluides Modèle roofline Les architectures multicœurs se caractérisent par le partage d’une mémoire entre les différents cœurs dans lesquelles la bande passante est parfois un facteur limitant les performances. Le modèle roofline, introduit par Williams et al. en 2009, est un modèle de visualisation de performances basé sur l’intensité opérationnelle d’une implémentation. Cette grandeur est définie comme le nombre d’opérations en virgule flottante par Byte de donnée transférée entre les unités de calcul et la mémoire globale. La quantité de données échangées entre les unités de calculs et la mémoire du système est constituée des accès en lecture et écriture. Ce modèle permet de représenter graphiquement les performances de calcul en fonction de l’intensité opérationnelle. Le graphe, en échelle logarithmique, présente la performance atteignable en fonction de l’intensité opérationnelle selon la formule : P A = min(P, B × I), (1.36) avec P A la puissance atteignable en GFLOPS, P la puissance crête théorique de la machine, également en GFLOPS, B la bande passante théorique en GByte/s et I l’intensité opérationnelle du code en FLOP/Byte. L’intensité opérationnelle dépend de la machine et du code et peut être calculée à partir des compteurs présents dans le matériel et éventuellement accessibles via un outil de profilage. Dans certains cas, il est possible d’approcher cette intensité par un comptage des opérations du code. Le modèle conduit à la représentation donnée en exemple en figure 1.4. On détermine si une implémentation est bornée par la bande passante, comme pour l’intensité IA, ou par la puissance de calcul théorique, comme pour IB. Cela donne une borne de performance maximale atteignable pour une implémentation donnée. Une première stratégie d’optimisation pour un algorithme donné consiste à se déplacer vers une intensité opérationnelle plus grande, flèches horizontales sur la figure 1.4. Elle consiste en une optimisation de l’implémentation pour limiter les accès à la mémoire globale afin de maximiser la puissance atteignable. La seconde stratégie consiste à optimiser le code pour diminuer le temps de calcul. En effet, la performance atteinte lors d’une exécution correspond à un point sur le graphe. Visuellement, les optimisations visent à déplacer ce point vers la borne théorique le long d’une demi-droite correspondant à l’intensité opérationnelle de l’implémentation évaluée. Cette seconde stratégie est représentée par les flèches verticales sur la figure 1.4. Efficacité énergétique Dans le cadre de l’étude de l’impact environnemental des machines, la puissance de calcul est mise en regard de la consommation électrique. En particulier, depuis fin 2007, le classement du Green500 ordonne les éléments du Top500 en fonction de leur performance énergétique qui est exprimée en MFLOPS par watt consommé au cours d’un calcul. La figure 1.5 donne l’évolution des machines de rang 1 et 500 du classement Green500 ainsi que, à titre de comparaison, du Top500. La figure 1.6 représente les 150 premières machines des classements du Top500 et Green500 par groupes de couleurs selon le type d’accélérateurs ou selon l’architecture. Comme le montre Subramaniam et al. (2013), dans leur analyse de la consommation énergétique des super-calculateurs l’utilisation d’accélérateurs graphiques, GPU, ou de coprocesseurs semble contribuer fortement à l’amélioration de l’efficacité énergétique. À titre de 221.2. Calcul intensif 0.1 1 10 100 1000 0.1 IA 1 IA0 10 IB 100 Borne calcul Borne bande passante Puissance atteignable (GFLOPS) Intensité opérationnelle (FLOP/Byte) Roofline Figure 1.4. – Exemple de modèle roofline. 100 101 102 103 104 2007 2008 2009 2010 2011 2012 2013 2014 2015 Efficacité énergétique (MFLOPS/W) Date de publication des classements Green500 - #1 Green500 - #500 Top500 - #1 Top500 - #500 Figure 1.5. – Évolution de l’efficacité énergétique des machines. 231. Calcul intensif pour la mécanique des fluides comparaison, les ordres de grandeurs de puissance consommée sont illustrés par des maté- riels usuels. Le code de couleurs utilisé sur la figure 1.6 permet de distinguer quatre types d’architecture. L’architecture classique correspond à une machine constituée de processeurs multicœurs traditionnels et ne contenant aucun accélérateur. L’architecture BlueGene se distingue de la précédente par un nombre bien plus grand de processeurs, par une faible fréquence des processeurs et une faible quantité de mémoire des nœuds. Ces deux dernières caractéristiques permettent à ce type de machine d’être extrêmement efficace en termes de performance énergétique. Les machines dotées de coprocesseurs représentées sur la figure 1.6 sont constituées de processeurs multicœurs Xéon Phi comportant jusqu’à 61 cœurs de calcul et qui ont été introduits récemment par Intel. La machine à coprocesseurs la plus efficace est constituée de processeur PEZY-SC contenant 1 024 cœurs qui sont développés par la société japonaise PEZY Computing. Enfin, le second type d’accélérateur est représenté par les GPU dont les caractéristiques seront détaillées dans le chapitre 4. 105 106 107 108 10−1 100 101 20 MW 1 MW 0.1 MW éolienne motrice de TGV voiture Puissance de calcul (GFLOPS) Efficacité énergétique (GFLOPS/W) Top500 Green500 GPU Coprocesseur BlueGene Classique Figure 1.6. – Comparaison des performances énergétiques des 150 premières machines du Top500 et Green500 selon le matériel (classements de novembre 2014). 1.2.3. Défi de l’exascale Pourquoi l’exascale ? Comme nous l’avons vu précédemment, l’amélioration de la qualité des simulations numériques nécessite des résolutions plus importantes, afin d’obtenir de nouveaux résultats pour améliorer la compréhension et la prise en compte de phénomènes physiques. Cela permet ensuite d’envisager une complexification des modèles physiques puis des modèles 241.2. Calcul intensif mathématiques et numériques dans le processus itératif schématisé en figure 1. De ce point de vue, ces simulations ont besoin de ressources de calcul toujours plus importantes. D’autre part, les classements du Top500 et Green500 nous montrent que la puissance des supercalculateurs est en augmentation, apportant ainsi une réponse à ces besoins en ressources de calcul. Cette réponse permet d’envisager la simulation de problèmes physiques encore plus complexes. Toutefois, les applications sont encore loin d’exploiter toute la puissance offerte par ces calculateurs. La littérature ne fait état que de très peu d’applications capables d’atteindre le PFLOP. Des simulations d’interactions gravitationnelles en astrophysique entre 1012 corps atteignant 4.45 PFLOPS ont été obtenues par Ishiyama et al. (2012), soit 42% de la puissance maximale de la machine pour leurs configuration. Plus récemment, une performance de 11 PFLOPS a été atteinte par Rossinelli et al. (2013) pour la simulation de la coalescence de 15 000 bulles de vapeur sur 13.1012 points de calcul en utilisant 1.6 millions de cœurs CPU. Cette performance correspond à 55% de la puissance de la machine. Enfin, 4096 cartes graphiques ont permis à Yokota et al. (2013) d’atteindre 1.08 PFLOPS en simple précision, soit 25% de la puissance maximale théorique. Principales difficultés Le développement d’applications capables d’exploiter une telle puissance se confronte à de nouvelles problématiques dont nous reprenons quelques éléments, d’après Dongarra et al. (2011). Concurrence L’architecture des machines de l’exascale, basée sur des composants multicœurs ayant un très grand nombre de cœurs, soulève de nombreuses difficultés quant à l’utilisation des mécanismes et des algorithmes actuels notamment en terme de synchronisation des différents processus ou encore d’accès aux données. En effet, les architectures multicœurs ont la particularité de partager une même mémoire entre l’ensemble des cœurs ce qui rend complexe l’accès aux données, à travers une hiérarchie de caches, qui ont éventuellement été modifiées dans le même temps. Leur originalité est qu’elles disposent d’une quantité de mémoire disponible par cœur de calcul plus faible que dans les architectures classiques. L’augmentation du nombre de cœurs par processeurs conduit à une diminution de la mémoire disponible par cœurs. Les accès à des données distantes, non présentes sur la mémoire associée à un processus, deviennent rapidement très coûteux pour un très grand nombre de cœurs. Ce qui pose la question de l’élaboration d’algorithmes de communications et de synchronisations distants adaptés à ces architectures. Énergie La consommation énergétique de ces supercalculateurs devient un problème non seulement au niveau de l’alimentation électrique globale des machines mais aussi du refroidissement des composants. Une limite de faisabilité d’une consommation de 20 MW a été proposée dès 2008 par Bergman et al. et détaillée plus récemment par Subramaniam et al. (2013). Les performances énergétiques des algorithmes commencent à être considérées, en complément des mesures traditionnelles, notamment à travers le classement Green500 et contribuent à une amélioration des performances énergétiques des machines. 251. Calcul intensif pour la mécanique des fluides Robustesse Les applications déployées sur des machines exascale devront être robustes aux pannes. En effet, statistiquement, la probabilité qu’un cœur tombe en panne au cours de l’exécution d’un programme est non négligeable. Des solutions doivent être développées afin de s’affranchir de la technique traditionnelle de la sauvegarde de l’état complet d’un programme à un instant donné en vue d’un redémarrage qui devient impossible à mettre en place dans un tel environnement. De nombreuses techniques sont développées (Dongarra et al., 2014) afin de pouvoir, d’une part, détecter les pannes et les erreurs introduites dans les résultats et, d’autre part, effectuer un redémarrage local des processus en échec en utilisant les données locales pour reconstruire une solution au moment de la panne. Dans ce contexte l’exécution devient non reproductible. Quelques stratégies Les contraintes de ce passage à l’échelle permettent, par nécessité, de dégager quelques stratégies au niveaux des algorithmes et des méthodes numériques employées. Ces straté- gies sont détaillées de manière exhaustive par Dongarra et al. (2014). Les auteurs soulignent notamment que l’utilisation de modèles couplés, de méthodes d’ordre élevé ou de parallé- lisation en temps permettent d’aboutir à des implémentations susceptibles de s’adapter à l’architecture des machines. L’intérêt est de pouvoir introduire des considérations maté- rielles dès la spécification des méthodes numériques et même au niveau de la modélisation mathématique du problème. D’autre part, au niveau des algorithmes, l’accent est mis sur la scalabilité des solveurs, l’utilisation d’algorithmes multiniveaux et de librairies de calcul existantes pour lesquelles les optimisations par rapport aux architectures auront été réalisées de manière très pointue. Le cadre applicatif de la mécanique des fluides s’adapte assez bien aux caractéristiques du calcul intensif. En effet, à travers une application, nous allons pouvoir employer une méthode de résolution ayant de bonnes propriétés de parallélisation dans l’optique de l’exploitation de serveurs de calculs hétérogènes. Le développement et l’implémentation de cette méthode numérique est réalisé dans le cadre défini par l’application que nous détaillons ci-après. 1.3. Transport de scalaire passif dans un écoulement turbulent 1.3.1. Domaines d’application De très nombreux phénomènes physiques sont basés, au moins en partie, sur le transport d’un ou plusieurs scalaires par un écoulement turbulent. Les scalaires correspondent à des quantités de diverses natures (Shraiman et al., 2000). Dans le domaine de l’environnement, le scalaire peut représenter un polluant transporté par l’air ou l’eau (Michioka et al., 2008). En biologie il peut s’agir de l’évolution des concentrations de certaines molécules chimiques, comme les phéromones, que de nombreuses espèces utilisent pour communiquer ou se repérer (Murtis et al., 1992) ou encore la concentration de bactéries et de leur nourriture (Taylor et al., 2012). Le domaine de l’ingénierie est concerné par de nombreux problèmes 261.3. Transport de scalaire passif dans un écoulement turbulent de ce type, notamment en combustion. Dans ces problèmes, plusieurs scalaires peuvent être transportés simultanément comme les différentes concentrations en réactifs chimiques ou encore la fraction de mélange entre le combustible et l’oxydant (Pitsch et al., 2008). La température est un autre exemple de quantité scalaire, importante dans l’étude de systèmes de refroidissements (Kuczaj et al., 2010). Un transport de scalaire peut également être utilisé comme outil de modélisation. Par exemple, le transport d’une fonction levelset permet de modéliser les interfaces dans un fluide multiphasique (Tryggvason et al., 2011) ou un objet en mouvement (Sethian et al., 2003). 1.3.2. Physique du problème Généralement, le scalaire a une influence sur l’écoulement dans lequel il est transporté. Par exemple dans les cas où on considère la densité d’un fluide multiphasique, ou encore lors du transport de concentrations en réactifs chimiques dans une réaction de combustion. Dans certaines applications, les effets du scalaire sur l’écoulement deviennent négligeables, ce qui est le cas dans le transport de petits éléments comme des polluants, molécules ou colorants. Le scalaire est alors passif dans l’écoulement et n’a pas d’effet rétroactif sur le fluide. Dans un écoulement turbulent et indépendemment du transport de scalaire, des structures de différentes tailles se forment. Des structures de grandes tailles sont créées et entretenues par l’écoulement. Les fluctuations de ces structures génèrent des structures plus petites qui elles-mêmes génèrent, en cascade, d’autre structures encore plus fines. Un tel écoulement se caractérise par une large palette de taille de structures s’étalant sur plusieurs ordres de grandeur. Cependant, à partir d’une certaine échelle, dite de Kolmogorov, les effets visqueux du fluide deviennent prédominants et engendrent une dissipation de l’énergie cinétique de l’écoulement (Lesieur, 2008). La longueur de cette échelle ne dépend que des caractéristiques du fluide dont notamment la viscosité ν. Ainsi, un écoulement turbulent ne présente pas de structures de tailles inférieures à la longueur de l’échelle de Kolmogorov, notée ην. Lors d’une simulation directe, DNS en anglais pour Direct Numerical Simulation, l’écoulement est résolu à toutes les échelles jusqu’à l’échelle de Kolmogorov. Le maillage doit avoir une longueur de maille suffisamment petite pour capter les plus petites structures de l’écoulement. Dans les cas où le maillage ne résout pas toutes les échelles, il est nécessaire de faire appel à un modèle de turbulence permettant de simuler cette dissipation d’énergie par les petites échelles non résolues (Lesieur et al., 2005 ; Sagaut, 2006). La dynamique du scalaire se caractérise par deux phénomènes : une dispersion par convection du scalaire puis sa diffusion. Le premier effet, induit par le fluide turbulent, a pour conséquence d’étirer les structures du scalaire, de générer des fluctuations à des échelles de plus en plus petites et d’amplifier ses concentrations locales. De manière similaire au fluide, l’échelle de Batchelor, notée ηκ, décrit l’échelle de concentration d’un scalaire à partir de laquelle la diffusion moléculaire devient prédominante (Batchelor, 1958). Là encore, cette échelle ne dépend que des caractéristiques du fluide, dont la viscosité et du coefficient de diffusion, noté κ. Cette diffusion permet une dissipation des variations, localement fortes, du scalaire. 271. Calcul intensif pour la mécanique des fluides Le nombre de Schmidt, sans dimension, est défini par le rapport entre la viscosité du fluide et le coefficient de diffusion du scalaire, Sc = ν/κ. Dans la plupart des fluides, le nombre de Schmidt est grand, au moins égal à 1. Ce nombre permet de relier les échelles de dissipation du fluide et du scalaire à travers la relation : ηκ √ Sc = ην. En pratique, l’échelle de Batchelor est donc (beaucoup) plus petite que l’échelle de Kolmogorov. Cela implique que le transport du scalaire développe des structures plus petites que les plus petites structures développées par le fluide. Pour de grands nombre de Schmidt, la dynamique du scalaire est essentiellement donnée par l’advection du scalaire sous l’effet du fluide. Un cadre théorique décrit l’influence du nombre de Schmidt sur des quantités statistiques du scalaire. En particulier, la décroissance du spectre de variance du scalaire, en fonction du nombre d’onde k, est modélisé par une loi de puissance en k −5/3 qui est associée au transfert d’énergie en cascade vers les petites échelles. Cette décroissance est suivie d’une loi en k −1 puis de la dissipation par les plus petites échelles. Cette lente décroissance renforce la nécessité d’une résolution des petites échelles de l’écoulement. 1.3.3. Formulation mathématique Un problème de transport d’un scalaire dans un fluide incompressible turbulent est modélisé par les équations de Navier-Stokes (1.10) pour la partie fluide et une équation de convection et diffusion pour le transport du scalaire. Ces deux parties sont liées par le champ de vitesse. Le problème consiste en le système d’équations suivant, en considérant une densité ρ = 1 et en l’absence de forces extérieures fe = 0 :    div u = 0, Du Dt =  ∂u ∂t + (u · ∇)u  = −∇P + ν∆u, Dθ Dt = ∂θ ∂t + (u · ∇)θ = κ∆θ (1.37) Les trois inconnues du problème sont le champ de vitesse u, la pression P et le scalaire passif θ. Dans le cadre d’un scalaire actif, l’effet sur l’écoulement est généralement pris en compte à travers une force fθ présente au second membre de la seconde équation du système. Ici, à travers le couplage faible entre les deux parties, nous obtenons une décomposition du problème global en deux sous-problèmes quasi indépendants. En effet, le champ de vitesse peut être vu simplement comme une donnée d’entrée du problème de transport de scalaire. Conclusion À partir d’un même problème mathématique, différentes méthodes numériques peuvent être envisagées. Le choix de l’une ou l’autre dépend des objectifs visés, des applications considérées et des architectures de calcul disponibles. Dans ce chapitre, nous avons exposé 281.3. Transport de scalaire passif dans un écoulement turbulent les grandes lignes des méthodes classiques relativement à la résolution d’un problème de mécanique des fluides. L’utilisation d’une méthode numérique permet de discrétiser un problème continu pour en approcher une solution. Leur point commun est que la précision de la solution dépend de la finesse de la discrétisation et de l’ordre d’approximation du schéma numérique. Ces deux paramètres ont une forte incidence sur le temps de calcul. Ce dernier peut rapidement devenir prohibitif en l’absence d’utilisation de techniques de parallélisation et d’optimisation du code. L’exploitation des machines de calcul, dont l’architecture peut être fortement hétérogène, dans le cadre du calcul intensif, implique une prise en compte du matériel et des technologies employées dès la conception des algorithmes. L’importance de cette prise en compte est encore plus grande lors de l’utilisation d’une grande quantité de ressources, notamment dans la perspective de l’évolution des machines vers l’exascale. Le transport d’un scalaire passif par un écoulement turbulent nous conduit à résoudre un problème, composé de deux parties assez indépendantes, présentant plusieurs échelles. Dans la suite, nous mettons en place une résolution basée sur différentes méthodes ainsi que des algorithmes multiéchelles. 292. Méthode particulaire pour l’équation de transport Comme nous l’avons exposé dans le chapitre 1, la modélisation du transport d’un scalaire passif dans un écoulement turbulent s’effectue à l’aide un système d’équations continues constitué des équations de Navier-Stokes et d’une équation d’advection-diffusion du scalaire. Ces deux équations présentent une équation de transport, une pour la vorticité et l’autre pour le scalaire. Parmi les différentes techniques de résolution possibles, ce travail se base sur le développement d’une méthode semi-Lagrangienne. En effet, elle permet de combiner les avantages des méthodes Lagrangiennes tout en se basant sur une structure de donnée régulière. Ainsi, cette méthode nous permet de choisir de grands pas de temps pour la réalisation de simulations numériques tout en bénéficiant de la régularité des données liée à la présence de la grille sous-jacente. Dans une première partie de ce chapitre, nous présenterons un état de l’art des méthodes particulaires semi-Lagrangiennes. Elles consistent en une méthode Lagrangienne avec une étape de remaillage systématique à chaque itération permettant de remédier aux éventuels problèmes de distorsions du champ de particules. Elles se distinguent des méthodes semiLagrangiennes classiques (backward) par une descente des caractéristiques. Cette méthode particulaire semi-Lagrangienne (forward) explicite peut être formalisée comme un schéma aux différences finies à travers le remaillage. Une analyse des schémas ainsi obtenus est possible en utilisant une approche propre à la méthode des différences finies. Nous présenterons également les différentes techniques de construction des formules de remaillage ainsi qu’un exemple d’implémentation. Dans une seconde partie, nous proposerons une méthode systématique pour obtenir des méthodes particulaires semi-Lagrangiennes d’ordres élevés. L’augmentation de l’ordre est obtenu par l’utilisation de formules de remaillage ayant une forte régularité et conservant un grand nombre de moments. Une nouvelle méthode de construction de ces formules permet de produire des formules d’ordre arbitraire. Des analyses de stabilité et consistance seront réalisées pour la méthode semi-Lagrangienne utilisant cette classe de formules de remaillage. 312. Méthode particulaire pour l’équation de transport 2.1. Méthode particulaire avec remaillage 2.1.1. Deux classes de méthodes semi-Lagrangiennes À l’origine, les méthodes semi-Lagrangiennes ont été développées pour la résolution d’écoulements dominés par l’advection, essentiellement dans le domaine de la météorologie (Staniforth et al., 1991). Leur principe général est basé sur l’exploitation des caractéristiques en chaque point d’une grille et de combiner les avantages des méthodes Eulériennes et Lagrangiennes. En effet, elles reposent sur le fait que la quantité transportée est invariante le long des caractéristiques. Dans une méthode semi-Lagrangienne rétrograde classique (backward semi-Lagrangian method en anglais) la résolution consiste à remonter la trajectoire depuis un point de grille et interpoler la quantité transportée au point de départ. Le résultat de l’interpolation donne directement la valeur de la quantité au point de grille considéré. Une seconde classe dont principe est similaire repose sur une descente des caracté- ristiques est appelée forward semi-Lagrangian method. Après intégration de l’équation de mouvement, l’étape de distribution de la quantité transportée sur les points de grille est réalisée de manière implicite et nécessite la résolution d’un système dont la complexité dé- pend de la nature de l’interpolation employée. La seule différence se situe dans le traitement des contributions sur les points de grille. Une comparaison avec la méthode classique a été proposée par Crouseilles et al. (2009) sur différents modèles d’équations de Vlasov pour la simulation de plasmas. Nous illustrons les deux classes de méthodes par les figures 2.1. (a) Backward (b) Forward Figure 2.1. – Méthodes semi-Lagrangiennes La méthode particulaire avec remaillage que nous détaillons dans la suite de ce chapitre est très similaire à la méthode forward mais en utilisant un schéma explicite. Notre méthode permet facilement de monter en ordre et est conservative. 322.1. Méthode particulaire avec remaillage 2.1.2. Principe général de la méthode particulaire avec remaillage Une méthode particulaire permet de résoudre une équation de transport : ∂u ∂t + div(au) = 0, (2.1) où la quantité u est transportée à vitesse a. Comme nous l’avons évoqué en section 1.1.2, la quantité u est discrétisée sur un ensemble de particules et est approchée en tout point de l’espace par l’expression : u(x) = X p upWε(x − xp), avec up la quantité portée par la particule p, Wε une fonction de régularisation et xp la position d’une particule. L’évolution des particules est soumise au champ de vitesse de l’écoulement et leurs trajectoires sont données par les équations : dxp dt = a(xp, t). La présence d’un éventuel second membre dans l’équation de transport (2.1) se traduit par une équation d’évolution de la quantité transportée par les particules. Par exemple, pour une équation de transport de vorticité ω à vitesse u, issue des équations de Navier-Stokes : ∂ω ∂t + u · ∇ω = ω · ∇u + ν∆ω, le second membre conduit aux équations suivantes : dωp dt = ωp∇u(xp) + ν∆ω(xp). Un inconvénient bien connu des méthodes particulaires est qu’au cours de l’évolution de la simulation, les particules ont des trajectoires qui suivent le champ de vitesse. Par conséquent, il peut arriver que ces particules se retrouvent trop éloignées les unes des autres ou inversement regroupées dans une petite région du domaine. Ainsi, selon les zones de l’écoulement, on assiste à une dégradation de la représentation des champs par manque ou excès de particules. Un contrôle du recouvrement des particules est alors nécessaire pour assurer de la convergence de la méthode. Dans de nombreuses implémentations de cette méthode, une redistribution des particules sur une grille est appliquée régulièrement au cours de la simulation afin de garantir un recouvrement suffisant et les propriétés de consistance de la méthode (Koumoutsakos et al., 1995). Une méthode semi-Lagrangienne est obtenue lorsque le remaillage est effectué systématiquement après chaque étape d’advection. Cela permet également une représentation des variables sur la grille et d’exploiter des méthodes de décomposition de domaine (Cottet, 1991 ; Ould Salihi et al., 2000 ; Cottet et al., 2000 ; Cocle et al., 2008), d’adaptation automatique de maillage (Bergdorf et al., 2005) ou de multirésolution basée sur des ondelettes (Bergdorf et al., 2006). Ainsi, les termes au second membre des équations de transport peuvent être résolus sur la grille et non sur les particules. 332. Méthode particulaire pour l’équation de transport Par conséquent, la quantité transportée par les particules est conservée lors de l’advection car la trajectoire des particules suit les caractéristiques et on a : dup dt = 0. Ainsi, dans ce type de méthode, les particules sont créées au début de chaque étape d’advection et sont détruites par le remaillage. En pratique, on ne crée des particules qu’aux points de grille où la quantité transportée par les particules est supérieure à une certaine valeur seuil fixée à l’avance. Cela permet d’éviter le traitement, par advection puis remaillage, de particules dont la quantité transportée est nulle ou négligeable. Le remaillage consiste en une interpolation des particules sur la grille à l’aide d’un noyau de remaillage, également appelé formule de remaillage. Le cas multidimensionnel est généralement traité par produit tensoriel de noyaux monodimensionnels. Cependant, comme nous le verrons par la suite, ces formules ont généralement un coût arithmétique élevé en 3D si des noyaux avec un large support sont utilisés. La figure 2.2 illustre une étape de résolution pour un cas 2D où la taille des disques représente les valeurs portées par les particules. Après un déplacement des particules selon le champ de vitesse représenté par les flèches en trait épais sur la figure 2.2b, les particules sont remaillées sur les S points de grille voisins. Les contributions d’une particule sur les points de grille sont représentées par des flèches en trait fin. La particule colorée sur la figure 2.2a est répartie dans les valeurs des points de grille colorés selon la contribution sur la figure 2.2c. (a) Instant t n (b) Advection et remaillage (c) Instant t n+1 Figure 2.2. – Remaillage par produit tensoriel Magni et al. (2012) proposent une alternative à la résolution multidimensionnelle basée sur un splitting dimensionnel. Cette méthode permet de découpler les directions spatiales à travers la résolution de problèmes monodirectionnels en alternant les directions. Le splitting de Strang, d’ordre deux en temps, conduit à résoudre, pour un problème 2D, une première direction sur l’intervalle [t n ;t n+1/2 [, la seconde direction sur un pas de temps complet et revenir à la première direction pour terminer l’itération sur [t n+1/2 ;t n+1[. En trois dimensions, l’algorithme est identique, toutes les étapes sont réalisées sur des demi pas de temps excepté la troisième direction. Nous illustrons ce splitting dimensionnel en figure 2.3 en utilisant les 342.1. Méthode particulaire avec remaillage mêmes conventions que pour l’illustration précédente. Dans un souci de clarté, l’exemple ne concerne qu’un splitting du premier ordre qui, selon le même principe, consiste en une alternance des directions pour des pas de temps complets. À chaque étape, une particule est remaillée seulement sur les S points voisins dans la direction concernée, soit respectivement 3S et 5S contributions par particule pour une itération complète de la formule de Strang en 2D et en 3D, au lieu de S 2 et S 3 pour un remaillage tensoriel. (a) Instant t n (b) Advection et remaillage, direction X (c) État intermédiaire (d) Advection et remaillage, direction Y (e) Instant t n+1 Figure 2.3. – Remaillage par splitting dimensionnel du premier ordre À travers l’utilisation d’un splitting dimensionnel de Strang, la résolution d’une équation de transport multidimensionnelle se réduit à une succession de problèmes 1D. Cela permet d’obtenir un coût de calcul proportionnel au nombre de particules dont la constante multiplicative dépend uniquement de la formule de remaillage. Dans un remaillage tensoriel, chaque particule contribue une fois par itération à S 3 (S 2 ) points de grilles voisins en 3D (2D). En revanche, dans notre cas, une itération est constituée de plusieurs étapes dans lesquelles une particule contribue simplement aux S points de grille. D’autres avantages en termes de complexité algorithmique seront donnés ultérieurement. 352. Méthode particulaire pour l’équation de transport 2.1.3. Cas monodimensionnel La méthode semi-Lagrangienne d’advection avec remaillage est donnée ici pour une équation de transport monodimensionnelle : ∂u ∂t + ∂ ∂x(au) = 0. (2.2) On note la vitesse, a et la quantité transportée par les particules, u. À chaque instant, ces deux variables sont connues en chaque point de la grille. À chaque itération temporelle de la méthode, les particules sont initialisées à un instant t n , en chaque point de grille x˜ n i = xi avec u˜ n i = u n i pour la quantité transportée. Puis l’équation de mouvement est résolue pour chaque particule à l’aide d’un schéma d’intégration en temps. La nouvelle position de la particule i, x˜ n+1 i est la solution du problème suivant :    d˜xi dt = a(˜xi) t ∈ [t n , tn+1[, x˜ n i = xi . (2.3) En pratique, pour chaque particule, le problème (2.3) est résolu par un schéma d’inté- gration explicite. La vitesse de la particule i, a(˜xi), est supposée constante tout au long de l’intervalle de temps [t n ;t n+1[ et son approximation est notée a˜ n (˜xi). Dans un cadre multié- chelle, la vitesse est connue sur une grille plus grossière que celle du scalaire, on utilise alors une interpolation linéaire du champ de vitesse pour obtenir l’approximation a˜ n en un point de la grille fine. Dans le cas d’une même résolution pour les deux grilles, l’approximation du champ de vitesse sur un point de grille est directement donnée par la valeur de la vitesse en ce point, sans interpolation, a˜ n (xi) = a n i . Pour une intégration du premier ordre, avec un schéma d’Euler, la position de la particule après advection s’exprime par : x˜ n+1 i = xi + a n i ∆t. (2.4) Comme nous l’avons exposé précédemment, un splitting de Strang du second ordre est utilisé pour les cas multidimensionnels. Cela implique l’utilisation d’un schéma d’intégration d’ordre plus élevé afin de conserver le second ordre en temps. En utilisant un schéma de Runge-Kutta, du second ordre, la position de la particule est donnée par l’expression : x˜ n+1 i = xi + ˜a n  xi + a n i ∆t 2  ∆t. (2.5) Ici encore, la valeur du champ de vitesse a n i n’est utilisée directement que dans les cas d’une même résolution pour la vitesse et le scalaire, sinon une interpolation linéaire supplémentaire est nécessaire. Après déplacement des particules, l’étape de remaillage permet de redistribuer les quantités portées par les particules sur la grille. Cette étape est réalisée à l’aide du noyau de remaillage W : u n+1 i = X p u n pW x˜ n+1 p − xi ∆x ! (2.6) 362.1. Méthode particulaire avec remaillage 2.1.4. Lien avec la méthode des différences finies Comme nous l’avons vu précédemment, une particule initialement au point de grille xp se retrouve après advection, par la résolution de (2.3), en position x˜p, transportant la quantité up. Ensuite la particule est remaillée sur les 2S points de grille voisins de x˜p par un noyau de remaillage Λp,r. Si on note xi le point de la grille le plus proche à gauche de x˜p, la quantité up est distribuée sur les points de grille d’indices [i − S + 1;i + S], comme l’illustre la figure 2.4. Particules Grille i − 2 i − 1 i i + 1 i + 2 i + 3 x˜p Figure 2.4. – Remaillage d’une particule pour un noyau de support [−2; 2] De même, un point de la grille se voit collecter toutes les contributions de particules situées à sa proximité indépendemment du nombre de particules. En effet, le nombre de particules par cellules peut changer (c.-à-d. être différent de un) selon les variations locales du champ de vitesse. Toutefois, les particules ne peuvent se croiser au cours de l’advection lorsque le pas de temps est contraint par une condition CFL Lagrangienne : ∆t||a 0 ||∞ 6 C (2.7) Particules Grille i Figure 2.5. – Remaillage sur un point de grille pour un noyau de support [−2; 2] La méthode d’advection suivie d’un remaillage montre une similarité avec la méthode des différences finies. Nous l’illustrons sur un exemple linéaire simple, lorsque le nombre CFL des particules, λi = ai∆t/∆x, est inférieur à 1 et que la vitesse est positive. En utilisant la formule de remaillage à deux points (2.10), les poids sont donnés par : αi = 1 − λi , βi = λi . Cette configuration est schématisée sur la figure 2.6. αi−1 βi−1 αi βi λi−1 λi λi+1 i − 1 i i + 1 i − 1 i i + 1 Instant t n Instant t n+1 Advection Remaillage Figure 2.6. – Analogie entre le remaillage et les différences finies 372. Méthode particulaire pour l’équation de transport À l’issue du remaillage, le point de grille d’indice i collecte des contributions des particules i − 1 et i : u n+1 i = βi−1u n i−1 + αiu n i = λi−1u n i−1 + (1 − λi)u n i = a n i−1u n i−1∆t ∆x + u n i − a n i u n i ∆t ∆x On reconnaît ici aisément un schéma aux différences finies du premier ordre consistant avec l’équation de transport : u n+1 i − u n i ∆t = (au) n i−1 − (au) n i ∆x Cette approche permet à Cottet et al. (2006) de démontrer le parallèle entre cette méthode semi-Lagrangienne et le schéma de Lax-Wendroff pour l’équation de Burgers. Les auteurs distinguent les cas linéaires et non linéaires. Pour une équation à vitesse constante, l’utilisation d’une formule de remaillage de support [−1.5; 1.5] conservant les trois premiers moments conduit, lorsque la CFL est inférieure à 1/2, à un schéma aux différences fines de Lax-Wendroff. Pour une CFL dans [1/2; 1], le schéma obtenu est décentré. Une formule de remaillage de support [−2; 2] conservant quatre moments est également analysée et conduit à un schéma d’ordre 3. Le cas non linéaire est bien plus complexe et n’est étudié que pour la formule Λ2 et une CFL inférieure à 1/2. Le schéma aux différences finies obtenu est d’ordre deux si les particules sont advectées avec un schéma également d’ordre deux. Un point intéressant de cette étude est que l’ordre des schémas obtenus ne dépend pas explicitement de la formule de remaillage mais simplement du nombre de moments qu’elle conserve. L’exploitation des outils de la méthodologie des différences finies permet à Cottet et al. (2009b) de développer des limiteurs pour les formules de remaillage Λ2. Les auteurs se restreignent à des CFL inférieures à 1 dans les cas linéaires et non linéaires pour l’équation de Burgers. En pratique des CFL plus grandes sont traitées en deux étapes. Les particules sont d’abord advectées sans remaillage sur la partie entière de la CFL puis advectées et remaillées avec une CFL inférieure à 1. Plus récemment, Magni et al. (2012) étendent la construction de formules de remaillage avec limiteurs d’ordre 2 et 4 corrigées pour pouvoir traiter le cas de grands pas de temps. En effet, lors d’une advection avec une CFL supérieure à 1, les nombres CFL peuvent varier d’une particule à l’autre ce qui entraîne une perte de consistance avec l’équation de transport. L’idée développée consiste en un regroupement des particules en blocs selon leur nombre CFL local. Les particules d’un même blocs sont remaillées soit avec une formule de remaillage centrée soit décentrée à gauche. Ainsi, au sein des blocs, la consistance est assurée directement. Par contre, entre deux blocs de types différents, la consistance de la méthode nécessite une correction des formules de remaillage selon les nombres CFL locaux des particules à l’interface entre les blocs. Les corrections consistent en une modification du nombre de points de grille sur lesquels ces particules sont remaillées. La consistance pour les grands pas de temps conduit à des formules de remaillage de plus grande complexité algorithmique du fait de l’étape de construction des blocs et de choix de la correction à appliquer. Enfin, Weynans et al. (2013) proposent une extension des formules de remaillage avec limiteurs dans le cas non linéaire pour une vitesse de signe quelconque. Les auteurs proposent également une preuve de convergence de la méthode en utilisant leurs schémas. Cette 382.1. Méthode particulaire avec remaillage démonstration est réalisée dans le cadre de la résolution d’une équation de Burgers. Il s’agit, à notre connaissance, de la seule preuve de convergence des méthodes particulaires pour l’équation de Burgers. 2.1.5. Construction des formules de remaillage Du fait de leur nature, les méthodes particulaires sont adaptées à la résolution d’équations de conservation. Il est donc impératif que le remaillage, par l’équation (2.6), possède également ces propriétés de conservation des moments des quantités transportées. Mathé- matiquement le moment discret d’ordre p d’une quantité u est défini par : X i x p i ui . (2.8) Par conséquent, un noyau de remaillage doit satisfaire les égalités de conservation des moments discrets d’ordre α suivantes : X i x α i u n+1 i = X i x α i u n i , 0 6 α 6 p, ou encore, en utilisant la relation (2.6) : X k∈Z k αW(x − k) = x α , 0 6 α 6 p, x ∈ R. (2.9) Construction à partir des moments discrets La première catégorie de noyaux est obtenue directement à partir des relations (2.9) et les noyaux sont notés Λp, pour un noyau conservant les moments d’ordre 0 à p. Le support est fixé à une largeur égale à p + 1 et le noyau est défini par une fonction polynomiale par morceaux de p + 1 polynômes de degrés p. Les p 2 + p coefficients sont alors obtenus de manière à vérifier les relations (2.9). Cette méthode permet notamment d’obtenir le noyau d’interpolation linéaire : Λ1(x) = ( 1 − |x| si |x| 6 1 0 sinon (2.10) Les quatre premiers noyaux de cette classe sont représentés en figure 2.7. Comme le montre la figure 2.7, certains de ces noyaux ne sont pas continus. Les pertes de précisions numérique dues au manque de régularité de ces noyaux ont été étudiées par Cottet et al. (2009b). L’ordre du remaillage peut être conservé à l’aide de corrections locales. Construction à partir de B-splines Une seconde classe de noyaux est obtenue à partir de B-splines régulières (Schoenberg, 1946) : Mp(x) = 1 2π Z ∞ −∞  sin ξ/2 ξ/2 p e iξxdξ. (2.11) 392. Méthode particulaire pour l’équation de transport −0.2 0 0.2 0.4 0.6 0.8 1 0 0.5 1 1.5 2 2.5 3 3.5 4 Λ1(x) Λ2(x) Λ3(x) Λ4(x) Figure 2.7. – Noyaux de remaillage de type Λp Ainsi un noyau Mp sera de classe C p−2 avec un support de largeur 2p − 3. La figure 2.8 représente quelques noyaux de type Mp. On remarque que M1 est la fonction chapeau de support [−1/2; 1/2] et que M2 = Λ1. Cependant, ces noyaux ne permettent qu’une conservation des deux premiers moments uniquement. −0.2 0 0.2 0.4 0.6 0.8 1 0 0.5 1 1.5 2 2.5 3 3.5 4 M1(x) M2(x) M4(x) M8(x) Figure 2.8. – Noyaux de remaillage de type Mp Extrapolation à partir de noyaux réguliers En utilisant l’extrapolation de Richarson, Monaghan (1985) produit des noyaux basés sur les fonctions Mp et leurs dérivées afin d’obtenir des ordres plus élevés en conservant leur régularité. On construit alors un noyau de la forme W(x) = Pp/2 c=0 ckx kM (k) p (x). Les coeffi- 402.1. Méthode particulaire avec remaillage cients ck sont obtenus de telle sorte que le nouveau noyau vérifie les conditions suivantes : Z W(x)dx = 1, Z x αW(x)dx = 0, 1 6 α 6 p, ce qui conduit à la résolution d’un système linéaire. Seules les contraintes pour α pair sont à considérer, car les moments impairs sont nuls par symétrie des noyaux. Par exemple, pour le noyau M4, on est ramené à la résolution du système :  R M4(x)dx R xM0 4 (x)dx R x 2M4(x)dx R x 3M0 4 (x)dx  c0 c1  =  1 −1 1/3 −1  c0 c1  =  1 0  , dont la solution est c0 = 3/2 et c1 = 1/2. On obtient donc le noyau noté M0 4 . Par construction, ce noyau est de classe C 1 , comme M4 est C 2 , mais il conserve les moments jusqu’à l’ordre 3. Il est utilisé dans la plupart des implémentations depuis la fin des années 90 (Koumoutsakos, 1997 ; Ould Salihi, 1998). M0 4 (x) = 1 2  3M4(x) + x dM4 dx (x)  M0 4 (x) =    1 − 5 2 |x| 2 + 3 2 |x| 3 si |x| 6 1 1 2 (1 − |x|)(2 − |x|) 2 si 1 < |x| 6 2 0 sinon (2.12) −0.2 0 0.2 0.4 0.6 0.8 1 0 0.5 1 1.5 2 2.5 3 3.5 4 M0 4(x) M0 5(x) M0 8(x) Figure 2.9. – Noyaux de remaillage type M0 p Un comparatif de ces différents noyaux est donné dans le tableau 2.1 en termes de moments conservés, de régularité, de largeur de support et de degré polynomial. 412. Méthode particulaire pour l’équation de transport Nom Moment maximal conservé Régularité Support Degré Λ1 1 C 0 [−1; 1] 1 Λ2 2 - [−1, 5; 1, 5] 2 Λ3 3 C 0 [−2; 2] 3 Λ4 4 - [−2, 5; 2, 5] 4 M1 1 - [−0, 5; 0, 5] 0 M2 1 C 0 [−1; 1] 1 M4 1 C 2 [−2; 2] 3 M8 1 C 6 [−4; 4] 7 M0 4 2 C 1 [−2; 2] 3 M0 5 3 C 2 [−2, 5; 2, 5] 4 M0 8 4 C 4 [−4; 4] 7 Tableau 2.1. – Comparatif des différents noyaux de remaillage de la littérature. 2.1.6. Exemple d’implémentation La principale implémentation de méthodes semi-Lagrangiennes (également appelées mé- thodes particules-grille) a été proposée par Sbalzarini et al. (2006). La librairie PPM (Parallel Particle-Mesh) repose sur une unification de méthodes de grilles et de méthodes particulaires à travers des interpolations entre les particules et la grille. Cette librairie propose une interface pour l’exploitation de machines à mémoire distribuée de manière transparente pour l’utilisateur. Le parallélisme est géré par des méthodes de décomposition de domaine et d’adaptation de charge. Des algorithmes efficaces pour l’évaluation des interactions entre particules, des méthodes de grilles globales utilisant des FFT et des solveurs multigrille ainsi que des interpolations entre les particules et la grille conduisent à de bonnes performances numériques. Dans la suite de ce chapitre nous exposons une méthode de construction de formules de remaillage dont les propriétés de régularité et du nombre de moments conservés sont choisis arbitrairement. Nous considérons ensuite ces formules dans des études de consistance et de stabilité des schémas ainsi obtenus. Nous observons que l’ordre de la méthode semi-Lagrangienne dépend directement du nombre de moments conservés par la formule de remaillage ainsi que de sa régularité. Les détails techniques des étapes d’advection et remaillage propres à l’implémentation seront donnés dans les chapitres 5 et 6. 2.2. Advection semi-Lagrangienne d’ordre élevé 2.2.1. Construction de formules de remaillage d’ordre élevé Une caractéristique intéressante des noyaux de type Λp est la propriété d’interpolation suivante : Λp(x) = ( 1, si x = 0 0, si x ∈ Z ∗ . (2.13) 422.2. Advection semi-Lagrangienne d’ordre élevé Cette propriété permet une conservation exacte de la quantité remaillée pour les particules dont la position coïncide avec un point de grille, en particulier si la vitesse est nulle. En pratique, l’utilisation de noyaux possédant cette propriété donne des résultats plus précis. Cependant, les noyaux réguliers de type Mp et M0 p perdent cette propriété. Dans cette section, nous donnons une méthode de construction de noyaux de remaillage d’ordre élevé, réguliers et vérifiant la propriété (2.13). Le principe est similaire à celui employé pour la construction des noyaux de type Λp, donnée en Section 2.1.5. Il s’agit de trouver une fonction vérifiant les propriétés suivantes : P1 : parité ; P2 : support compact [−S, S] ; P3 : polynomiale par morceaux de degré q sur les intervalles entiers ; P4 : régularité C r ; P5 : conservation les moments jusqu’à l’ordre p, selon l’égalité (2.9) ; P6 : vérification de la propriété d’interpolation (2.13). Ces propriétés conduisent à l’expression d’une régularité des noyaux Λp,r en terme d’espaces fonctionnels :    Λp,r ∈ C ∞ (]l, l + 1[), l ∈ Z, Λp,r ∈ Wr+1,∞(R) = n f ∈ L ∞(R), ∀l ∈ N ∗ , l 6 r + 1, D l f ∈ L ∞ o , (2.14) où Dlf est la dérivée d’ordre l de f au sens des distributions. Les propriété P1, P2 et P3 permettent de restreindre la recherche à seulement S polynômes de degré q, soit S(q + 1) coefficients inconnus. Le noyau s’écrit donc de manière générale : Λp,r(x) = ( Qi(x), si i 6 |x| < i + 1, i = 0 . . . S − 1 0 sinon, avec Qi(x) = X q k=0 c i k |x| k . Avec ces notations, la propriété P4 implique que q > r ainsi que les (r + 1)(S + 1) contraintes de raccords entre les polynômes aux points de coordonnées entières du support : Q (j) i (i + 1) = Q (j) i+1(i + 1), 0 6 j 6 r, 1 6 i 6 S − 1, Q (j) 0 (0) = ( 1 si j = 0 0 sinon , 0 6 j 6 r, Q (j) S−1 (S) = 0, 0 6 j 6 r. Les p+ 1 égalités polynomiales imposées par la propriété P5 se traduisent par (1+p)(q + 1) contraintes sur les coefficients polynomiaux. Cependant, par parité des noyaux, les moments 432. Méthode particulaire pour l’équation de transport Nom Moment maximal conservé Régularité Support Degré Λ2,1 2 C 1 [−2; 2] 3 Λ2,2 2 C 2 [−2; 2] 5 Λ4,2 4 C 2 [−3; 3] 5 Λ4,4 4 C 4 [−3; 3] 9 Λ6,4 6 C 4 [−4; 4] 9 Λ6,6 6 C 6 [−4; 4] 13 Λ8,4 8 C 4 [−5; 5] 9 Tableau 2.2. – Comparatif de quelques noyaux de remaillage de type Λp,r. d’ordre impair ne conduisent pas à des contraintes supplémentaires car elles sont vraies quelque soient les coefficients c i k . On ne retient donc que (1 + [p/2])(q + 1) contraintes. Enfin, la propriété d’interpolation conduit à S − 1 contraintes supplémentaires, les valeurs aux points de coordonnées 0 et S étant redondantes avec les contraintes issues de P4. Nous avons donc au total S(r + 2) + (1 + [p/2])(q + 1) + r contraintes. Des solutions uniques sont envisageables si : S(q + 1) 6 S(r + 2) + (1 + [p/2])(q + 1) + r. (2.15) Pour un couple de (S, q) donné et en considérant l’ordre p et la régularité r comme fixés, l’ensemble de ces contraintes conduit à un système linéaire dont les inconnues sont les coefficients polynomiaux c k i . Comme les contraintes de conservation des moments d’ordre impair sont vérifiées par parité, un choix naturel est de prendre p pair. Dans ce cas, en prenant S = 1 + p/2, l’inégalité 2.15 est vérifiée car S(r + 2) + r > 0. Expérimentalement, nous obtenons des solutions uniques en prenant, en plus des deux hypothèses précédentes, q = 2r + 1. Les noyaux obtenus par cette méthode sont notés Λp,r. Nous retrouvons le noyau M0 4 = Λ2,1 ainsi que le noyau Λ4,2 qui a été introduit par Bergdorf et al. (2006) sous la notation M000 6 . Les caractéristiques des noyaux utilisés dans la suite sont résumées dans le tableau 2.2 et leurs expressions sont données en annexe A. Une représentation de ces noyaux est donnée en figure 2.10. Cette méthode de construction de formules de remaillage permet de contrôler explicitement le nombre de moments conservés p ainsi que la régularité du noyau r. Ces deux paramètres, nous le verrons au cours de l’analyse de consistance qui suit, sont en lien direct avec la précision du schéma et l’ordre numérique de la méthode. Ainsi, une méthode d’ordre élevé sera obtenue en utilisant des formules avec p et r grands. Cependant, l’augmentation du nombre de moments conservés par les formules de remaillage conduit à un élargissement du support des noyaux. Cela a pour conséquence qu’un plus grand nombre de points de grille seront contenus dans le support de la formule impliquant une plus grande complexité en terme d’accès aux données lors de l’implémentation. D’autre part, l’augmentation de la régularité de la formule implique une augmentation du degré des polynômes constituant les noyaux. L’incidence de cette augmentation se traduit par une plus grande complexité numérique lors de l’évaluation de ces fonctions pour le calcul des poids de remaillage. 442.2. Advection semi-Lagrangienne d’ordre élevé −0.2 0 0.2 0.4 0.6 0.8 1 0 0.5 1 1.5 2 2.5 3 3.5 4 Λ2,1 Λ2,2 Λ4,2 Λ4,4 Λ6,4 Λ6,6 Λ8,4 Figure 2.10. – Noyaux de remaillage de type Λp,r Utilisation des poids de remaillage En pratique, on exprime les poids de remaillage en fonction de la distance entre la particule et le point de grille le plus proche. Le support est découpé en intervalles de longueur égale à la distance entre deux points de grille sur lesquels la formule s’identifie à un polynôme. Ainsi, on a exactement un point de grille dans chaque morceau d’intervalle, ce qui conduit à l’expression de 2S poids de remaillage. La figure 2.11 illustre l’obtention des poids de remaillage pour une formule Λ2,1, de support de longueur 4. Λ2,1(x) =    1 − 5 2 |x| 2 + 3 2 |x| 3 = p0(|x|) 0 6 |x| < 1 2 − 4|x| + 5 2 |x| 2 − 1 2 |x| 3 = p1(|x|) 1 6 |x| < 2 0 |x| > 2 Particules Grille xi y x˜p Λ2,1(x) x x x x p1(−x) p0(−x) p0(x) p1(x) -2 -1 0 1 2 x y α(y) β(y) γ(y) δ(y) Figure 2.11. – Obtention des poids de remaillage pour une formule de support [−2; 2] 452. Méthode particulaire pour l’équation de transport Lorsque xi est le point de grille le plus proche de coordonnée inférieure à x˜p, y est défini comme la distance normalisée entre ces deux points : y = (˜xp − xi)/∆x, y ∈ [0; 1]. De ce fait, on obtient les poids en fonction de y :    α(y) = Λ2,1(−1 − y) = p1(y) = y + y 2 − 1 2 y 3 , β(y) = Λ2,1(−y) = p0(y) = 1 − 5 2 y 2 + 3 2 y 3 , γ(y) = Λ2,1(1 − y) = p0(1 − y) = 1 2 y + 2y 2 − 3 2 y 3 , δ(y) = Λ2,1(2 − y) = p1(1 − y) = − 1 2 y 2 + 1 2 y 3 . Les poids sont donnés pour les formules de type Λp,r en annexe A. Pour les formules d’ordre élevé, les poids de remaillage sont de degré assez grand. Une implémentation efficace de l’évaluation de ces polynômes est réalisée par la méthode de Horner :    α(y) = y(y(−y + 2) − 1)/2, β(y) = (y 2 (3y − 5) + 2)/2, γ(y) = y(y(−3y + 4) + 1)/2, δ(y) = y 2 (y − 1)/2. Ainsi ce schéma permet de minimiser le nombre d’opérations arithmétiques pour l’évaluation de ces polynômes en évitant notamment le calcul des termes en y n . L’évaluation d’un polynôme de degré q ne nécessite que 2q additions et multiplications au lieu des q(q + 1)/2 pour un algorithme naïf. Précision numérique du schéma d’Horner Lors de l’évaluation d’un polynôme par le schéma d’Horner, la précision numérique atteinte, en tenant compte des erreurs d’arrondi, dépend du degré et du conditionnement du polynôme. L’erreur relative pour l’évaluation d’un polynôme p(x) = Pq i=0 aix i par un schéma de Horner est bornée par (Higham, 2002) : |p(x) − Horner(p, x)| |p(x)| 6 Kq cond(p, x) = Kq Pq i=0 |ai ||x i | | Pq i=0 aix i | . La constante Kq dépend du degré q du polynôme et de l’erreur relative lors de l’arrondi des nombres en virgule flottante, u = 2−53 en double précision selon la norme IEEE-754. De manière générale, on a : Kq = γ2q = 2qu 1 − 2qu , et lorsque des opérations FMA (Fused Multiply and Add) sont disponibles, comme c’est le cas sur la plupart des GPU, l’erreur est plus faible. En effet dans une FMA, la multiplication et l’addition sont effectuées en une seule opération arithmétique conduisant à une seule erreur d’arrondi au lieu de deux, la constante s’écrit alors : Kq = γq = qu 1 − qu . 462.2. Advection semi-Lagrangienne d’ordre élevé Les polynômes permettant de calculer les poids de remaillage pour les formules Λp,r ont un conditionnement qui augmente fortement au voisinage de 1. Cela conduit à des erreurs pouvant être assez grandes lorsque les particules s’approchent d’un point de grille par position inférieure (y → 1). Ce phénomène est d’autant plus marqué que l’ordre des formules est élevé. Nous représentons sur la figure 2.12 la borne d’erreur relative pour les poids de remaillage pour trois des formules couramment utilisées. 0 0.2 0.4 0.6 0.8 1 y Λ6,4 p3(y) p2(y) p1(y) p0(y) p0(1 − y) p1(1 − y) p2(1 − y) p3(1 − y) 0 0.2 0.4 0.6 0.8 1 y Λ4,2 p2(y) p1(y) p0(y) p0(1 − y) p1(1 − y) p2(1 − y) 10−16 10−14 10−12 10−10 10−8 10−6 10−4 10−2 100 0 0.2 0.4 0.6 0.8 1 Précision relative y Λ2,1 p1(y) p0(y) p0(1 − y) p1(1 − y) Figure 2.12. – Erreur numérique maximale du schéma de Horner pour l’évaluation des poids de remaillages pour les formules Λ2,1, Λ4,2 et Λ6,4 en double précision (sans FMA) Dans le cadre de ce travail, nous avons conservé le schéma de Horner pour l’implémentation de ces formules. 2.2.2. Consistance de la méthode semi-Lagrangienne Dans ce paragraphe nous démontrons la consistance du schéma d’advection et remaillage (2.4) ou (2.5) et (2.6) lorsque la formule de remaillage est de type Λp,r, définie en section 2.2.1. Cette démonstration est présentée dans un article paru en 2014 dans ESAIM : Mathematical Modelling and Numerical Analysis pour un schéma d’Euler, inclus en annexe B. Nous détaillons ici le cas d’une approximation d’ordre deux de la vitesse lors de l’advection. La démonstration suit une démarche similaire à celle de l’article, la seule différence est que les développements sont conservés à un ordre quelconque. 472. Méthode particulaire pour l’équation de transport Proposition 2.1 Soit un noyau de remaillage Λp,r de support [−S; S], vérifiant les contraintes de régularité (2.14), la propriété d’interpolation (2.13) ainsi que l’égalité de conservation des moments (2.9) jusqu’à un ordre p. Soient un champ de vitesse a et un scalaire u suffisamment réguliers tels que u soit solution de l’équation de transport (2.2). Lorsque la condition (2.7) est vérifiée, α est l’ordre d’approximation du champ de vitesse et β = inf(p, r), nous avons : u(xi , tn+1) = u n+1 i + O(∆t α+1) + O(∆t∆x β + ∆x β+1). (2.16) De plus, dans le cas où chaque cellule contient une seule particule, β = p. Démonstration de la proposition 2.1 : L’indice p d’une particule peut être réfé- rencé à partir de l’indice i et d’un décalage k de telle sorte que xp = xi + k∆x et ainsi : u(xp, tn ) = X β j=0 k j∆x j j! ∂ ju ∂xj (xi , tn ) + O(∆x β+1). (2.17) Ici, nous nous plaçons dans le cadre d’une grille cartésienne uniforme où xi+k = xi + k∆x. De même, la position des particules devient : x˜ n+1 p = xi + k∆x + ˜a n i+k∆t, qui se réécrit en posant λi = ˜a n i ∆t/∆x, le nombre CFL local : x˜ n+1 p − xi ∆x = k + λi+k. La règle de dérivation des fonctions composées, se généralise par : (f ◦ g) (m) (x) = X |q|=m m!cq  f (q1+···+qm) ◦ g  (x) Ym s=1  g (s) (x) qs , cq = 1 q1!1!q1 q2!2!q2 · · · qm!m! qm , où q est le multi-indice q = (q1, q2, . . . , qm) tel que |q| = q1 + 2q2 + · · · + mqm. En utilisant cette formule, en posant ν = ∆t/∆x et en prenant g(xi) = k + λi = k + νa˜ n (xi), on obtient que : Λp,r(k + λi) (m) = X |q|=m m!cqΛ (q1+···+qm) p,r (k + λi)ν q1+···+qm Ym s=1  a˜ n (s) qs . (2.18) Le développement de Λp,r(k + λi+k) au voisinage de k + λi à l’ordre r est obtenu en utilisant la relation (2.18). Cependant, comme Λp,r ∈ Wr+1,∞(R), cela implique que ||Λ (β+1) p,r ||∞ < ∞ pour 0 6 β 6 r. Par conséquent, le développement est donc 482.2. Advection semi-Lagrangienne d’ordre élevé effectué à l’ordre β = inf(p, r) : Λp,r(k + λi+k) = X β m=0 k m∆x m m! X |q|=m m!cqΛ (q1+···+qm) p,r (k + λi)ν q1+···+qm Ym s=1  a˜ n (s) qs + O  ∆x β+1||Λ (β+1) p,r ||∞||a˜ (β+1)||∞ X |q|=β+1 ν q1+q2+···+qβ+1  . (2.19) D’autre part, comme q1+q2+· · ·+qβ+1 6 |q|, alors ν q1+q2+···+qβ+1 6 ν β+1 6 ν β+1+ν, le résidu précédent se réécrit en : O  ∆t β+1 + ∆x∆t β  . Finalement, l’approximation du schéma (2.6) est obtenue à partir du produit des relations (2.17) et (2.19), noté Ek : u n+1 i = X k u(xk, tn )Λp,r(k + λi+k) = X k     X β m=0 k m∆x m X |q|=m cqΛ (q1+···+qm) p,r (k + λi)ν q1+q2+···+qm Ym s=1  a˜ n (s) qs     X β j=0 k j∆x j j! ∂ ju ∂xj (xi , tn )     + O  ∆t β+1 + ∆x∆t β + ∆x β+1 = X k Ek + O  ∆t β+1 + ∆x∆t β + ∆x β+1 . Le produit des deux sommes d’indices m et j des termes Ek se regroupent : X k Ek = X β m=0 j=0 ∆x m+j j! ∂ ju ∂xj (xi , tn ) X |q|=m cq X k k m+jΛ (q1+···+qm) p,r (k + λi)ν q1+q2+···+qm Ym s=1  a˜ n (s) qs . Par dérivation de la relation (2.9), on a : X k k αΛ (δ) p,r(k + x) = α! (α − δ)!(−1)δ (−x) α−δ si 0 6 δ 6 α 6 β. Par conséquent, on a également : X k k m+jΛ (q1+···+qm) p,r (k + λi)ν q1+q2+···+qm = di,m+j,qν m+j , avec : di,s,q = s!(−1)q1+···+qm (s − (q1 + · · · + qm))!(−a˜ n i ) s−(q1+···+qm) , si 0 6 q1 + · · · + qm 6 s 6 β. 492. Méthode particulaire pour l’équation de transport Ce qui permet d’aboutir à : X k Ek = X β m=0 j=0 ∆x m+j j! ∂ ju ∂xj (xi , tn ) X |q|=m cqdi,m+j,qν m+j Ym s=1  a˜ n (s) qs = X β m=0 j=0 ∆t m+j j! ∂ ju ∂xj (xi , tn ) X |q|=m cqdi,m+j,q Ym s=1  a˜ n (s) qs . Finalement, la troncature du schéma à l’ordre α en temps donne : u n+1 i = Xα m=0 j=0 ∆t m+j j! ∂ ju ∂xj (xi , tn ) X |q|=m cqdi,m+j,q Ym s=1  a˜ n (s) qs + O  ∆t α+1 + ∆x∆t β + ∆x β+1 . (2.20) Advection par un schéma d’Euler Les couples (m, j) possibles pour la première somme tels que m + j 6 α + 1 sont (0, 0), (0, 1) et (1, 0). Pour m = 0, le multi-indice q se réduit à un simple indice égal à 0. L’expression (2.20) devient : u n+1 i = u(xi , tn )− ∆ta˜ n i ∂u ∂x(xi , tn )− ∆t(˜a n i ) 0u(xi , tn ) +O  ∆t 2 + ∆x∆t β + ∆x β+1 . D’autre part, si le champ de vitesse est approché à l’ordre 1, on a a˜ n i = a(xi , tn ), ce qui donne : u n+1 i = u(xi , tn ) − ∆t ∂an i u ∂x (xi , tn ) + O  ∆t 2 + ∆x∆t β + ∆x β+1 . (2.21) Puis, en utilisant l’équation de transport (2.2) on aboutit au résultat : u n+1 i = u(xi , tn+1) + O  ∆t 2 + ∆x∆t β + ∆x β+1 . (2.22) Advection par un schéma de Runge-Kutta du second ordre Dans ce cas, en plus des termes présents pour le cas du schéma d’Euler, on ajoute les termes correspondants aux couples (m, j) = (0, 2), (1, 1) et (2, 0). u n+1 i = u(xi , tn ) − ∆ta˜ n i ∂u ∂x(xi , tn ) − ∆t(˜a n i ) 0u(xi , tn ) + ∆t 2 2  (˜a n i ) 2 ∂ 2u ∂x2 (xi , tn ) + 4˜a n i (˜a n i ) 0 ∂u ∂x(xi , tn ) + 2((˜a n i ) 02 + ˜a n i (˜a n i ) 00)u(xi , tn )  + O  ∆t 3 + ∆x∆t β + ∆x β+1 . 502.2. Advection semi-Lagrangienne d’ordre élevé Pour une approximation du second ordre, on a a˜ n i = a(xi + a(xi)∆t/2). Les développements de a˜ n i sont réalisés à l’ordre maximal puis injectés dans l’expression précédente : ∆ta˜ n i = ∆tan i + ∆t 2 2 a(xi)a 0 (xi) + O(∆t 3 ), ∆t(˜a n i ) 0 = ∆ta0 (xi) + ∆t 2 2 a(xi)a 00(xi) + ∆t 2 2 a 02 (xi) + O(∆t 3 ), ∆t 2 (˜a n i ) 00 = ∆t 2 a 00(xi) + O(∆t 3 ), u n+1 i = u(xi , tn ) − ∆t  a n i ∂u ∂x(xi , tn ) + (a n i ) 0u(xi , tn )  + ∆t 2 2  (a n i ) 2 ∂ 2u ∂x2 (xi , tn ) + 3˜a n i (˜a n i ) 0 ∂u ∂x(xi , tn ) + ((˜a n i ) 02 + ˜a n i (˜a n i ) 00)u(xi , tn )  + O  ∆t 3 + ∆x∆t β + ∆x β+1 . Par simplifications on obtient : u n+1 i = u(xi , tn ) − ∆t ∂an i u ∂x (xi , tn ) + ∆t 2 2 ∂ ∂x  ∂an i u ∂x  (xi , tn ) + O  ∆t 3 + ∆x∆t β + ∆x β+1 . (2.23) Puis en utilisant l’équation de transport (2.2) on obtient finalement : u n+1 i = u(xi , tn+1) + O  ∆t 3 + ∆x∆t β + ∆x β+1 . (2.24) Cas d’une seule particule par cellule Dans ce cas, le développement (2.19) peut être effectué à n’importe quel ordre, en particulier à l’ordre β = r. La suite des calculs reste identique. 2.2.3. Stabilité de la méthode semi-Lagrangienne Les démonstrations de la stabilité de la méthode sont données dans l’article Cottet et al. (2014) inclus en annexe B. Les preuves sont basées sur les propriétés de décroissance des noyaux qui sont vérifiées pour les méthodes d’ordre 2 et 4. Nous proposons ici une approche permettant de démontrer la propriété de stabilité linéaire de la méthode pour les noyaux de type Λp,r jusqu’à p = 8. 512. Méthode particulaire pour l’équation de transport Advection à vitesse constante Dans un premier temps, la stabilité du schéma est analysée pour un champ de vitesse constant en espace. La démonstration se base sur le nombre CFL local : λ = a∆t/∆x, constant. Nous définissons les suites de fonctions suivantes, pour k ∈ Z : αk(λ) = Λp,r(k + λ), (2.25) Ak(λ) = X i αi(λ)αi+k(λ). (2.26) Les noyaux de remaillage étant à support compact, seuls quelques éléments de ces suites sont non nuls. Proposition 2.2 Les suites αk(λ) et Ak(λ) vérifient : X k,l (k − l) qαk(λ)αl(λ) = 0, et X k k qAk(λ) = 0, q 6 p. (2.27) Démonstration de la proposition 2.2 : Le membre de gauche de la première équation se développe en : X k,l (k − l) qαk(λ)αl(λ) = X k,l X q m=0 C m q k ml q−mαk(λ)αl(λ). La propriété (2.9) étant vérifiée pour les formules de type Λp,r, on a : X k,l k ml q−mαk(λ)αl(λ) = (−λ) m(λ) q−m, et donc X k,l (k − l) qαk(λ)αl(λ) = X q m=0 C m q (−λ) m(λ) q−m = (λ − λ) q = 0. La seconde équation vient du fait que Ak(λ) = A−k(λ). Proposition 2.3 Pour un champ de vitesse a constant en espace et pour un noyau de remaillage Λp,r de support [−S; S] vérifiant les contraintes de régularité (2.14), la propriété d’interpolation (2.13) ainsi que l’égalité de conservation des moments (2.9) jusqu’à un ordre p, le schéma de remaillage est inconditionnellement stable. Démonstration de la proposition 2.3 : Soient I un entier tel que λ ∈ [I; I + 1[ et µ = λ − I ∈ [0; 1[. En posant vi = u n i−I , le schéma (2.6) se réécrit : u n+1 i = X k vi+kαk(µ). 522.2. Advection semi-Lagrangienne d’ordre élevé Montrons que X i  u n+1 i   2 6 X i |u n i | 2 . En utilisant (2.27), il vient : X i  u n+1 i   2 = X i X k,l vi+kvi+lαk(µ)αl(µ). (2.28) La formule de remaillage possède un support [−S; S], par conséquent, seuls quelques αk(µ) sont non nuls, pour k ∈ [−S; S−1]. Pour alléger les notations, comme µ ∈ [0, 1[ ne joue aucun rôle, il sera omis dans la suite. X i |u n+1 i | 2 = X i X k,l vi+kvi+lαkαl = X i X k v 2 i+kα 2 k + 2X k 0 = X i X k 2 X S−1 j=1 αkαk+j |vi+k − vi+k+j | 2 = X k 2 X S−1 j=1 αkαk+j X i |vi − vi+j | 2 = 2 X S−1 j=1 Aj X i |vi − vi+j | 2 . 532. Méthode particulaire pour l’équation de transport La suite consiste à démontrer que R > 0. On définit alors les suites {δJ,i}J=1,...,2S−1 de différences successives telles que :    δ1,i = vi − vi+1, δ2,i = δ1,i − δ1,i+1, δJ,i = δJ−1,i − δJ−1,i+1, (2.29) ainsi que des sommes de termes de ces suites : sJ,j = X i      X j−1 k=0 δJ,i+k      2 . Pour J = 1, on a simplement s1,j = P i |vi − vi+j | 2 , donc R se réécrit : R = 2 X S−1 j=1 Ajs1,j . (2.30) Par définition de sJ,j , on a : sJ,j = X i      X j−1 k=0 δJ,i+k      2 = X i X j−1 k=0 δ 2 J,i+k + X j−2 k=0 j−X 1−k l=1 2δJ,i+kδJ,i+k+l ! = j X i δ 2 J,i + X j−1 l=1 (j − l) X i 2δJ,iδJ,i+l . En utilisant la relation 2δJ,iδJ,i+l = δ 2 J,i + δ 2 J,i+l − |δJ,i − δJ,i+l | 2 , on obtient que : sJ,j = j X i δ 2 J,i + X j−1 l=1 (j − l) 2 X i δ 2 J,i − X i |δJ,i − δJ,i+l | 2 ! = j + 2X j−1 l=1 (j − l) !X i δ 2 J,i − X j−1 l=1 (j − l) X i |δJ,i − δJ,i+l | 2 = j 2X i δ 2 J,i − X j−1 l=1 (j − l) X i |δJ,i − δJ,i+l | 2 = j 2X i δ 2 J,i − X j−1 l=1 (j − l)sJ+1,l. Ainsi, le second terme de l’expression précédente contient j − 1 termes en sJ+1,l dont les seconds membres contiennent au maximum j − 2 termes, pour sJ+1,j−1. Le développement complet de sJ,j fait intervenir j − 1 niveaux de récurrence jusqu’au 542.2. Advection semi-Lagrangienne d’ordre élevé niveau J + j − 1. On obtient, en posant DJ = P i δ 2 J,i pour alléger les notations, le développement suivant : sJ,j = j 2DJ − X j−1 l=1 (j − l)sJ+1,l = j 2DJ − X j−1 l=1 (j − l)l 2DJ+1 + X j−1 l=1 (j − l) X l−1 m=1 (l − m)sJ+2,m = X j k=1 (−1)k+1Ck,jDJ+k−1. Avec les coefficients Ck,j définis par : C1,j = j 2 ; C2,j =    X j−1 l=1 (j − l)l 2 , si j > 2, 0, sinon ; C3,j =    X j−1 l=1 (j − l) X l−1 m=1 (l − m)m2 , si j > 3, 0, sinon ; C4,j =    X j−1 l=1 (j − l) X l−1 m=1 (l − m) mX−1 n=1 (m − n)n 2 , si j > 4, 0, sinon ; . . . L’expression (2.30) se réécrit donc : R = 2 X S−1 j=1 Aj X j k=1 (−1)k+1Ck,jDk ! , puis en permutant les sommes, on obtient : R = 2 X S−1 k=1 Dk   2 X S−1 j=k (−1)k+1Ck,jAj   . (2.31) Deux remarques permettent de simplifier la recherche du signe de R. Premièrement, les Dk étant positifs comme sommes de carrés, le dernier terme de la somme, pour k = 2S−1, est toujours positif. En effet, ce terme se simplifie en D2S−1A2S−1 = D2S−1α−SαS−1 et les α−S et αS−1 sont de même signe car on observe que les formules de type Λp,r présentent une alternance de signe sur chaque intervalle entier. Les noyaux sont positifs sur l’intervalle [−1; 1], négatifs sur [−2; −1] ∪ [1; 2] et ainsi sur l’ensemble des intervalles entiers du support. En particulier, il est positif sur l’intervalle [−S; −S + 1] ∪ [S − 1; S] si S est impair et négatif sinon. Deuxièmement, en 552. Méthode particulaire pour l’équation de transport remarquant que les coefficients Ck,j se réécrivent comme des combinaisons linéaires de puissances paires de j : C2,j = −j 2 12 + j 4 12 , C3,j = j 2 90 − j 4 72 + j 6 360 , C4,j = −j 2 560 + 7j 4 2880 − j 6 1440 + j 8 20160 , les termes de la forme PCk,jAj s’annulent lorsque k 6 [p/2] en utilisant la propriété de conservation des moments pairs (2.9). Ainsi, si la formule de remaillage conserve p moments alors les [p/2] premiers termes de la somme d’indice k sont nuls. Ainsi on obtient la majoration suivante : R > 2 X S−2 k=[p/2]+1 Dk   2 X S−1 j=k (−1)k+1Ck,jAj   . Pour toutes les formules de remaillage de type Λp,r, il a été vérifié numériquement que : 2 X S−1 j=k (−1)k+1Ck,jAj > 0 pour k = [p/2] + 1, . . . , 2S − 2 Ainsi nous obtenons que toutes les formules de type Λp,r données en annexe A conduisent à une méthode stable car R > 0. Advection à vitesse non constante Nous donnons ici les grandes lignes de la démonstration de stabilité dans le cas général qui est détaillée dans l’article Cottet et al. (2014) inclus en annexe B. Proposition 2.4 Pour un champ de vitesse a suffisamment régulier et pour un noyau de remaillage Λp,r de support [−S; S] vérifiant les contraintes de régularité (2.14), la propriété d’interpolation (2.13) ainsi que l’égalité de conservation des moments (2.9) jusqu’à un ordre p et lorsque le pas de temps est suffisamment petit vérifiant la condition (2.7), il existe une constance C indépendante de ∆t et ∆x telle que : X i  u n+1 i   2 6 (1 + C∆t) X i |u n i | 2 . (2.32) Démonstration de la proposition 2.4 : Nous ne donnons ici que l’idée générale de la démonstration qui est détaillée dans l’article en annexe. Lorsque la vitesse est non constante et le pas de temps suffisamment petit (2.7), le nombre CFL local est différent pour chaque particule : λp = ap∆t ∆x . Les particules peuvent alors être partitionnées selon l’intervalle entier auquel appartient λp : JI =  p ∈ Z, λp ∈ [I; I + 1[ . (2.33) 562.2. Advection semi-Lagrangienne d’ordre élevé Le schéma de remaillage (2.6) se réécrit : u n+1 i = X I X k∈JI u n kΛp,r(λk + k − i). En posant RI (i) = X k∈JI u n kΛp,r(λk + k − i), le membre de gauche de l’équation (2.32) devient : X i  u n+1 i   2 = X i      X I RI (i)      2 = X i X I R 2 I (i) +X i X I6=I 0 RI (i)RI 0(i). L’étude du premier terme est similaire à l’analyse dans le cas à vitesse constante et se base sur le fait que dans chaque élément de la double somme, les particules ont un nombre CFL local dans le même intervalle entier. Dans ce cas, on aboutit au résultat : X i R 2 I (i) 6 X i∈JI |u n i | 2 + C∆t (2.34) Dans le second terme, il apparaît des produits de la forme : Λp,r(λk + k − i)Λp,r(λk 0 + k 0 − i), k ∈ JI , k0 ∈ JI 0, I 6= I 0 . Ces produits sont non nuls seulement dans le cas où les particules son suffisamment proches après advection. De plus, chaque particule ne contribue que dans, au plus, 2S sommes RI (i). Ainsi on aboutit au résultat : X i X I6=I 0 RI (i)RI 0(i) 6 C∆t X i |u n i | 2 (2.35) Finalement, en combinant les résultats (2.34) et (2.35), on aboutit au résultat (2.32). Conclusion Dans ce chapitre, nous avons détaillé la méthode de résolution que nous employons pour résoudre une équation de transport. Nous avons vu comment l’étude des propriétés numé- riques de la méthode semi-Lagrangienne est réalisée en exploitant la similarité de la méthode avec celle des différences finies. En particulier, cela nous permet de produire des schémas numériques à un ordre arbitraire en utilisant des formules de remaillage appropriées. Ces formules possèdent, par construction, des propriétés de régularité et de conservation de moments des quantités transportées qui sont directement liées à l’ordre de la méthode. Cette méthode semi-Lagrangienne permet de résoudre les équations de transport pré- sentées au chapitre 1. Les autres éléments constituant le problème de transport de scalaire dans un fluide turbulent tels que les termes d’étirement et de diffusion ainsi que l’équation de Poisson sont traités par d’autres méthodes. Cela conduit à l’obtention d’une méthode hybride comme nous le verrons dans le chapitre 3. 573. Méthode hybride pour le transport turbulent Dans ce chapitre nous proposons de construire une méthode hybride, utilisant la méthode semi-Lagrangienne détaillée dans le chapitre 2, pour résoudre un problème de transport d’un scalaire dans un fluide turbulent, exposé dans le chapitre 1. Comme nous l’avons mentionné précédemment, ce système présente à la fois un caractère multiéchelle et un faible couplage entre les sous-problèmes que sont la résolution du fluide et le transport du scalaire. Ces caractéristiques nous conduisent à l’élaboration d’une méthode hybride qui est d’une part adaptée à la résolution de ce type de problème et d’autre part capable de traiter des résolutions importantes sur des machines massivement parallèles. Dans un premier temps, nous décrirons l’idée générale d’une méthode hybride puis nous donnerons quelques approches hybrides présentées dans la littérature avant de proposer la stratégie que nous emploierons par la suite. 3.1. Idée générale d’une méthode hybride Le principe d’une méthode hybride est d’utiliser différentes méthodes conjointement afin de résoudre un problème complexe en exploitant les forces de chacune des méthodes. Ainsi, le problème initial est décomposé selon ses aspects physiques en différentes parties qui sont résolues avec des méthodes différentes. Même si chacune des méthodes est bien connue individuellement, comme pour les méthodes exposées en section 1.1.2, le couplage doit être étudié en détail. La décomposition du problème global selon ses aspects physiques permet, par exemple dans le cadre de l’étude d’interactions entre un fluide et une structure, de séparer la ré- solution du fluide et du solide. De même pour le cas d’un transport de scalaire passif, il est possible de séparer la résolution du fluide de celle du transport du scalaire. Enfin, nous avons vu dans les chapitres précédents, que l’emploi d’une méthode semi-Lagrangienne pour la résolution d’un écoulement fait intervenir une équation de transport de la vorticité ainsi qu’une équation de Poisson permettant de calculer le champ de vitesse associé. Là encore une décomposition peut avoir lieu pour séparer la résolution de l’équation de Poisson de celle de l’équation de transport. 593. Méthode hybride pour le transport turbulent Ainsi dans une méthode hybride, les différentes parties du problème, issues de la décomposition selon les aspects physiques et numériques, sont résolues par différentes méthodes. Trois niveaux d’hybridation peuvent être distingués et sont détaillés dans la suite. 3.1.1. Méthode hybride en méthode numérique Le premier niveau consiste en l’utilisation de différentes méthodes numériques. Par exemple, pour la résolution d’un écoulement turbulent, une méthode hybride est utilisée par Cottet et al. (2002), Cottet et al. (2009b) et Rees et al. (2011). Cette méthode consiste en une résolution semi-Lagrangienne du transport de la vorticité combinée à une méthode spectrale pour le calcul du champ de vitesse en fonction du champ de vorticité à partir de l’équation de Poisson. La résolution de l’équation de Poisson par une méthode spectrale est une alternative à celle basée sur la loi de Biot-Savart employée dans les méthodes Vortex. Cette dernière conduit à une résolution directe sur le champ de particules, ce qui constitue un problème à N corps à travers le calcul des interactions entre les paires de particules. Les implémentations efficaces nécessitent la gestion d’une structure de données complexe basée sur des arbres afin de regrouper les particules en fonction de leurs distances pour exploiter les approximations multipoles rapides (méthodes FMM). Ainsi, la méthode spectrale est bien plus simple à mettre en œuvre. Ce type de couplage entre méthodes semi-Lagrangienne et spectrale est utilisé également pour des simulations d’écoulements en présence de solides rigides, pris en compte par pénalisation (Coquerelle et al., 2008 ; Rossinelli et al., 2010). D’autre part, dans le cas du transport turbulent d’un scalaire passif, des méthodes hybrides consistent en une résolution par méthode spectrale de l’écoulement puis un transport du scalaire par différences finies (Gotoh et al., 2012) ou par une méthode semi-Lagrangienne (Lagaert et al., 2012 ; Lagaert et al., 2014). 3.1.2. Méthode hybride en résolution Un second aspect des méthodes hybrides est d’employer des grilles de résolutions diffé- rentes pour discrétiser les équations présentes dans le modèle. Par exemple, Cottet et al. (2009a) proposent l’utilisation d’une méthode particulaire hybride en résolution pour le transport de scalaire. Les auteurs utilisent la même méthode semi-Lagrangienne pour ré- soudre l’écoulement et le scalaire. Le couplage est réalisé par interpolation du champ de vitesse pour le transport du scalaire. Dans cette méthode, le scalaire est discrétisé à une résolution plus fine que les champs de vitesse et de vorticité. Généralement, des modèles sous-maille sont utilisés dans le cadre de simulations des grandes échelles (LES) pour prendre en compte la dissipation d’énergie par son transfert vers les petites échelles. Cependant, ce modèle n’est pas suffisant pour prendre en compte les effets des plus petites échelles de fluctuations du scalaire qui ne sont pas résolues car de taille inférieure au maillage. Cottet et al. (2009a) montrent que l’emploi d’une méthode multiéchelle remédie naturellement à ce problème par une simulation directe des petites échelles du scalaire tout en conduisant à un coût de calcul similaire. Les études menées par Gotoh et al. (2012), Lagaert et al. (2012) et Lagaert et al. (2014) dans le cadre de l’analyse du comportement d’un scalaire transporté par un écoulement de 603.2. Application au transport turbulent turbulence homogène montrent que cette approche hybride en résolution permet d’obtenir des résultats cohérents avec le cas d’une méthode spectrale classique, en simple résolution. En effet, comme nous l’avons souligné dans la partie 1.3, ce problème se caractérise par la présence de différentes échelles et la résolution du fluide à l’échelle du scalaire n’apporte pas d’amélioration de la prise en compte de la physique de l’écoulement. Les méthodes utilisées dans ces travaux seront détaillées plus loin, en section 3.2. 3.1.3. Méthode hybride en matériel Comme nous l’avons vu dans la partie 1.2, les machines de calcul présentent de nombreuses architectures différentes. Un dernier niveau de construction d’une méthode hybride consiste en l’exploitation des différentes architectures d’une même machine. L’idée est de distribuer les différentes parties du problème sur différents matériels. Par exemple, dans le cas du transport de scalaire, la résolution du fluide est effectuée sur les processeurs CPU et le transport du scalaire est résolu sur les cartes graphiques d’une machine hétérogène. Cette approche sera complétée plus loin dans ce chapitre et sa mise en œuvre détaillée dans le chapitre 6. Une combinaison de ces différents niveaux est évidemment possible. En effet, une mé- thode hybride peut être définie par des résolutions et des méthodes différentes pour les parties du problème. Les approches semblables de Gotoh et al. (2012) et Lagaert et al. (2014) illustrent parfaitement ce cas de figure. Dans leurs études, le fluide est résolu par une méthode spectrale à une résolution grossière et le scalaire par différences finies ou méthode semi-Lagrangienne à une résolution plus fine. Les nombreuses possibilités de construction de méthodes hybrides nécessitent quelques précisions quant à l’application au transport de scalaire passif dans un écoulement turbulent. En effet, les caractéristiques du problème permettent d’aiguiller les choix pour la mise en place d’une méthode hybride. 3.2. Application au transport turbulent 3.2.1. Méthodes spectrale et différences finies Dans le cas du transport de scalaire passif, Gotoh et al. (2012) proposent une comparaison de leur méthode hybride avec une méthode entièrement spectrale. La méthode hybride consiste en la résolution de l’écoulement à l’aide d’une méthode spectrale alors que le transport du scalaire est résolu par différences finies d’ordre élevé. L’intérêt majeur de cette approche est que les opérations non locales sur le scalaire, issues des transformées de Fourier de la méthode spectrale, sont remplacées par des schémas locaux. Cela permet de limiter les communications lors de l’exploitation d’un grand nombre de cœurs de calcul. Les différentes échelles physiques présentes dans les cas à nombre de Schmidt élevé permettent à Gotoh et al. de réaliser des simulations en multirésolution. Le fluide est calculé sur 2563 points de grille alors que 1 0243 points sont utilisés pour discrétiser le scalaire. 613. Méthode hybride pour le transport turbulent Une réduction du temps de calcul est obtenue à travers ces différentes simulations. En particulier, les auteurs obtiennent un facteur d’accélération de 1,4 grâce à l’utilisation de leur méthode hybride au lieu d’une méthode entièrement spectrale. D’autre part, le fait de réduire le nombre de points de 1 0243 à 2563 pour la résolution du fluide, pour Sc = 50, leur permet d’obtenir un facteur d’accélération supplémentaire de 3. L’ensemble des calculs ont été réalisés en utilisant 4 096 cœurs de calcul. Une limite de cette approche est que le pas de temps reste limité par la résolution du maillage du scalaire à travers l’expression d’une condition de CFL. Ainsi, lorsque le problème est résolu en utilisant des grilles résolutions différentes, les auteurs sont limités à l’utilisation d’un pas de temps dépendant de celle du scalaire. 3.2.2. Méthodes spectrale et semi-Lagrangienne Une approche similaire a été proposée par Lagaert et al. (2012) et Lagaert et al. (2014). Les auteurs utilisent une méthode hybride où le fluide est résolu de façon spectrale couplée à une méthode semi-Lagrangienne pour le transport du scalaire. L’intérêt majeur est de pouvoir bénéficier de l’avantage des méthodes particulaires dont le pas de temps n’est pas contraint par une condition aussi restrictive que la condition CFL des méthodes Eulériennes, dans certains cas. Cela permet à Lagaert et al. de choisir un pas de temps pour le transport du scalaire dix fois plus grand que celui du fluide. Ainsi, dans le cas d’un grand nombre de Schmidt, non seulement les résolutions spatiales sont différentes mais les pas de temps aussi. Cela permet d’atteindre un facteur d’accélération approchant 40 par rapport à une méthode entièrement spectrale avec une seule résolution, dans le cas Sc = 50 avec 2563 points pour le fluide et 1 0243 points pour le scalaire. Toutefois, la méthode semi-Lagrangienne utilisée par Lagaert et al. reste d’un ordre spatial plus faible (ordre 4) que le schéma aux différences finies d’ordre 8 employé par Gotoh et al. 3.2.3. Méthodes semi-Lagrangiennes et architecture hybride Dans ce travail, nous reprenons l’idée de Cottet et al. (2009a) pour l’utilisation d’une méthode hybride. La méthode que nous utilisons exploite les trois niveaux d’hybridation exposés plus haut : maillages de résolutions différentes pour le scalaire et l’écoulement, couplage de méthodes de natures différentes et utilisation d’architectures matérielles différentes pour la résolution de l’écoulement et du transport du scalaire. Nous exploitons le caractère multiéchelle du problème avec une méthode hybride en résolution dans laquelle le scalaire transporté est résolu de manière plus fine que la vorticité. L’écoulement est résolu par une méthode semi-Lagrangienne pour le transport de la vorticité, avec des différences finies pour le terme d’étirement et une diffusion spectrale. Nous calculons le champ de vitesse à partir de la vorticité à l’aide d’un solveur spectral pour l’équation de Poisson. Le scalaire est également transporté par une méthode semi-Lagrangienne avec une diffusion en différences finies. Enfin au niveau matériel, le fluide sera résolu sur une architecture multicœurs CPU classique et nous tirons parti de la puissance de calcul disponible dans les cartes graphiques pour résoudre le transport du scalaire. 623.2. Application au transport turbulent Comme toutes les résolutions en temps sont effectuées par méthode semi-Lagrangienne, cela nous permet de choisir de grands pas de temps contraints uniquement par la condition de CFL Lagrangienne qui fait intervenir le gradient du champ de vitesse et non la taille de la grille. D’autre part, comme nous l’avons vu en section 2.2, la méthode d’ordre élevé conduit à l’utilisation de formules de remaillage d’une forte complexité arithmétique. En effet, le remaillage d’une particule nécessite l’évaluation de polynômes de degré relativement élevés en chacun des nombreux point du support. Cette complexité est maîtrisée par l’utilisation de cartes graphiques. L’intérêt de cette approche est de pouvoir accélérer, à l’aide des GPU, la partie la plus intensive du code dont la résolution pourra être réalisée en même temps que l’écoulement par l’utilisation de matériels différents pour chaque partie. D’un point de vue pratique, lors de l’exploitation de machines de calcul, il est d’usage de réserver les cartes graphiques par nœuds complets ce qui, sur la plupart des machines, donne accès à un nombre de cœurs CPU bien plus grand que le nombre de GPU. L’objectif d’une exploitation efficace des ressources est envisageable à travers une utilisation simultanée des GPU et des cœurs CPU pour résoudre respectivement le transport du scalaire et le fluide. Conclusion Dans ce chapitre, nous avons vu comment une méthode hybride permet d’exploiter les forces des différentes méthodes en fonction des caractéristiques du problème à résoudre. Ainsi, la méthode que nous utiliserons par la suite combine la méthode semi-Lagrangienne exposée dans le chapitre 2 avec des méthodes de grille classiques, différences fines et spectrales. L’idée principale de cette méthode est de profiter à la fois de la puissance de calcul développée par les cartes graphiques et de l’algorithme de splitting dimensionnel pour réaliser des simulations d’ordre élevé pour le transport du scalaire. Les résultats de cette méthode seront présentés dans le chapitre 6. 634. Développement d’un code multiarchitectures L’un des objectifs de cette thèse consiste en l’implémentation sur cartes graphiques de la méthode particulaire avec remaillage introduite dans le chapitre 2. Cette étape s’inscrit dans un cadre plus global de construction d’une méthode hybride, dont les principes ont été donnés dans le chapitre 3, afin d’explorer les possibilités d’une exploitation les ressources de machines de calcul hétérogènes telles que décrites dans le chapitre 1. Comme nous l’avons souligné dans le chapitre 2, la méthode semi-Lagrangienne semble être bien adaptée à une implémentation sur cartes graphiques du fait de la régularité des structures de données et des algorithmes qui en découlent. De plus, l’utilisation de formules de remaillage d’ordre élevé conduit à l’exécution de nombreuses opérations arithmétiques simples notamment pour le calcul des poids de remaillage. Actuellement, de nombreuses machines de calcul sont équipées de cartes graphiques. Cependant, comme nous l’avons vu dans le chapitre 1, cette tendance n’est pas immuable et peut éventuellement changer dans les prochaines années du fait des évolutions technologiques des composants. Par conséquent, dans un souci de pérennité du code, la librairie que nous développons doit pouvoir être facilement adaptée à une nouvelle architecture tout en conservant la possibilité d’une exploitation de machines classiques. D’autre part, la volonté d’une forte portabilité permettant de réaliser des simulations à la fois sur une machine de bureau, un portable ou une machine de calcul offre également une grande souplesse pour les différentes étapes de développement, de parallélisation et de production. Dans ce chapitre, nous présentons la librairie de calcul que nous utiliserons dans la suite pour les simulations numériques. Dans un premier temps, nous exposerons la conception de cette librairie qui est basée sur une stratégie de découpage sémantique en concepts mathématiques puis en différents niveaux d’abstraction, comme suggéré par Labbé et al. (2004). Dans un second temps, l’architecture et les moyens de programmation des cartes graphiques sont détaillés puis nous introduirons les principes du standard de programmation OpenCL. Enfin, l’intégration des modèles de programmation des GPU à la librairie de calcul sera rapidement décrite. Cette étape du développement est largement facilitée par la conception globale de la librairie. 654. Développement d’un code multiarchitectures 4.1. Développement d’une librairie de calcul scientifique 4.1.1. Conception préliminaire Bien que de nombreux codes numériques soient encore implémentés dans un paradigme de programmation impérative, une tendance récente consiste à employer un paradigme de programmation orientée objet pour le développement de codes de calcul scientifique. L’intérêt majeur de cette technique est de pouvoir atteindre une forte flexibilité à la fois pour le développement mais aussi pour l’utilisation. La programmation orientée objet repose sur une représentation des concepts et des entités du domaine d’application sous la forme d’objets dont les interactions constituent l’exécution du programme. Le code regroupe un ensemble de classes permettant de décrire les attributs et les méthodes des objets. L’ensemble des valeurs des attributs constituent l’état d’un objet et les méthodes expriment les interactions possibles avec cet objet. La programmation orientée objet se base sur les quatre concepts fondamentaux que sont l’encapsulation, l’héritage, l’abstraction et le polymorphisme. Leur mise en œuvre permet, lors de la conception, de décrire les relations entre les différentes classes. Selon le principe de l’encapsulation, les interactions avec les objets se font uniquement en utilisant ses méthodes et non directement ses données. Cela permet de garantir l’intégrité des propriétés de l’objet en cachant ses données. Par le principe d’héritage, il est possible de créer une classe à partir de classes existantes pour éventuellement leur ajouter de nouvelles propriétés ou fonctionnalités. De manière similaire, l’abstraction permet d’exposer uniquement les informations utiles et de laisser les détails pour des niveaux d’abstractions inférieurs. Cela permet d’accroître l’efficacité des objets ainsi que de réduire leur complexité. Enfin le polymorphisme consiste en la redéfinition de méthodes à travers les classes. L’exécution d’une méthode est réalisée par son plus proche parent dans la hiérarchie de classes si elle n’est pas définie par la classe de l’objet. L’intérêt de l’utilisation de ce type de paradigme de programmation est que cela permet aux utilisateurs et développeurs de manipuler des objets aussi proches que possibles des concepts physiques ou mathématique qu’ils représentent. La conception d’un programme orienté objet consiste en la description de l’ensemble des classes avec leurs attributs et leurs méthodes ainsi que leurs relations. En plus de l’héritage, des relations de composition et d’agrégation figurent parmi les plus couramment utilisées. Elles permettent de décrire la combinaison de plusieurs éléments pour en former un plus complexe. La composition se distingue de l’agrégation par une notion de propriété forte. Les objets qui composent un autre plus complexe n’ont pas d’existence en dehors de ce dernier. Découpage sémantique des concepts mathématiques Pour le développement de codes de calculs scientifiques, il est nécessaire d’employer une méthodologie de conception plus spécifique, comme celle décrite par Labbé et al. (2004). Dans leur approche, les auteurs se focalisent sur la résolution de systèmes d’équations différentielles par des méthodes d’algèbre linéaire. Ils aboutissent à une décomposition d’un problème de résolution d’équations aux dérivées partielles générique en différents concepts : 664.1. Développement d’une librairie de calcul scientifique Problème : Il correspond au problème mathématique global que l’on cherche à résoudre ; Opérateur : Généralisation de la notion mathématique d’opérateur, il définit un opérateur mathématique élémentaire comme le gradient ou le laplacien et, plus généralement, un terme d’une équation du problème. Il peut être vu comme un sous-problème élémentaire. Variable : Ce sont les entités mathématiques mises en relation par les opérateurs au sein du problème, qu’elles soient données ou inconnues. Domaine : Il décrit le contexte formel sur lequel sont définies les variables. Il comprend la spécification d’une géométrie et des conditions aux limites. Différents niveaux d’abstraction Toujours en suivant la méthodologie de Labbé et al. (2004), nous introduisons différents niveaux d’abstractions pour les concepts définis ci-dessus. Le point clé de cette conception est un découplage des concepts abstraits, des méthodes de résolution et des algorithmes. Ainsi, l’utilisateur manipule les éléments du niveau d’abstraction le plus élevé, qui correspondent aux concepts mathématiques des problèmes, opérateurs, variables et domaines. Un second niveau est constitué des algorithmes de résolution et de la discrétisation des variables. Enfin, un dernier niveau regroupe les implémentations des méthodes spécifiques au stockage des données des variables ainsi qu’à l’architecture permettant de réaliser les calculs. L’intérêt majeur est que les opérations réalisées à un niveau ne dépendent pas de la manière dont fonctionnent les autres niveaux. En particulier, il est aisé de changer de méthode de résolution ou d’architecture sans que l’utilisateur n’ait à modifier son code. Couplage faible et cohésion forte La structure basée sur un découpage sémantique et en niveaux d’abstraction permet d’obtenir une forte cohésion des différents composants. Les fonctionnalités de haut niveau (employées par l’utilisateur) font appel à des fonctions de niveau inférieur jusqu’à arriver au niveau le plus bas où les calculs sont effectués dans des fonctions élémentaires réalisant une tâche précise. Parallèlement, cela permet un couplage faible des différentes parties. A un niveau donné, les fonctionnalités ne sont pas interdépendantes. Ainsi, les effets de bords sont limités lors du développement et de la maintenance du code. Du point de vue de l’utilisation, les éléments sont autosuffisants à travers leurs niveaux d’abstraction. En suivant ces principes, il est possible de changer d’algorithme pour une méthode donnée sans avoir à modifier le reste des éléments. De même, plusieurs versions d’un même algorithme peuvent cohabiter, du moment qu’ils implémentent la même interface. Comme remarqué dans le chapitre 1, les architectures évoluent rapidement et une implémentation peut devenir inutilisable en changeant d’architecture. D’où l’importance d’une grande flexibilité car il sera aisé d’introduire une nouvelle version pour une architecture donnée ou, au contraire, d’écarter une version incompatible avec l’architecture courante au moment du déploiement. D’autre part, les choix de conception et de langages doivent garantir une por- 674. Développement d’un code multiarchitectures tabilité du code suffisante. Ainsi, face à une nouvelle architecture, le code existant devrait pouvoir être simplement reconfiguré et non réécrit. Schéma d’utilisation Du point de vue de l’utilisation, le code se décompose selon les étapes suivantes : 1. Description d’un problème à partir d’un domaine sur lequel sont définies des variables utilisées par des opérateurs. 2. Initialisation du problème à travers la discrétisation et l’initialisation des variables. Cette étape consiste essentiellement en l’allocation des zones mémoires ainsi qu’au branchement des différentes méthodes numériques parmi l’ensemble des versions disponibles. 3. Résolution du problème en appliquant ses opérateurs sur leurs variables. Ces étapes s’organisent dans le diagramme d’utilisation de la figure 4.1. Résout Problème Applique Opérateur Initialise Problème Discrétise Opérateur Discrétise Variable Définit Problème Définit Opérateur Définit Variable Définit Domaine Utilisateur 1. Description 2. Initialisation 3. Résolution Figure 4.1. – Diagramme de cas d’utilisation. 4.1.2. Conception détaillée Les entités issues du découpage en concepts et en différents niveaux d’abstraction sont décrites dans le diagramme de classe présenté en figure 4.2. 684.1. Développement d’une librairie de calcul scientifique Problems Domains Operators Variables Parallelism Tools Simulation current time current iteration time step end time advance time Problem domain list of variables list of operators simulation manager setUp solve <> Domain dimension list of Topologies Mesh position grid ghosts Variable nb components domain dict of (Topology, DVariable) init function discretize DVariable topology data <> Operator input variables output variables discretize setUp finalize <> DOperator input discrete variables output discrete variables apply finalize Topology domain mesh MPI process layout << neighbors interface>> NumMethod compute scales fftw h5py numpy mpi4py External Libraries n n n 1 1 n n 1 1 1 1 n 1 n 1 1 uses uses uses uses uses Abstract level Algorithm level Method level Figure 4.2. – Diagramme de classe. 694. Développement d’un code multiarchitectures Domaine Le domaine correspond à la définition mathématique sur lequel sont définies les variables et équations du problème. Cette entité nous permet de gérer la distribution des données et des calcul dans les simulations parallèles. En effet, dans ce cadre, le domaine est distribué à travers l’ensemble des processeurs et chaque sous-domaine est affecté à un processus. Variables Une variable est définie sur un domaine spatial. Les vecteurs et les scalaires ne sont pas distingués et diffèrent uniquement par leur nombre de composantes. Il est possible d’avoir différentes discrétisations d’une même variable selon leurs résolutions et leurs découpages à travers les différents processus. Les données discrètes des variables sont référencées indé- pendemment de leur stockage par un pointeur. Opérateurs Un opérateur est défini à partir de ses variables d’entrée et de sortie. Un opérateur discret est créé en fonction d’une paramétrisation de la méthode numérique, et fait appel à un ou plusieurs algorithmes de calcul et méthodes numériques en utilisant les données des variables discrètes. Méthodes numériques Ces entités de bas niveau permettent de réaliser des calculs sur les données numériques indépendemment de leur emploi et de leur provenance. Les schémas numériques issus des méthodes de résolution, comme les intégrateurs en temps, les schémas de différences finies ou les formules de remaillage sont implémentés de manière à traiter des données numériques à partir d’un espace mémoire générique. En pratique, diverses versions d’une même méthode selon le stockage des données employé peuvent cohabiter, la version appropriée étant choisie à l’initialisation des opérateurs. Problèmes Comme son équivalent mathématique, un problème est construit à partir d’une liste d’opérateurs, de variables et de domaines. Il constitue une partie de l’interface utilisateur de notre librairie et permet de discrétiser l’ensemble des entités ainsi que de piloter la simulation numérique tout au long de la boucle en temps par l’application successive des différents opérateurs. 4.1.3. Fonctionnement de la librairie Langages de programmation La conception de la librairie de calcul, donnée en sections 4.1.1 et 4.1.2, est indépendante de tout langage de programmation. Étant données les caractéristiques requises par 704.1. Développement d’une librairie de calcul scientifique notre code, le choix s’est rapidement tourné vers le langage Python. C’est un langage qui permet l’utilisation des paradigmes de programmation impératifs, objets et fonctionnels, ce qui contribue à la flexibilité du code. Python est un langage interprété, ce qui facilite le développement par l’absence d’étape de compilation. Python est présent par défaut sur de nombreux systèmes et grâce à un mécanisme de gestionnaire de modules, il est aisé d’installer les dépendances du code sur n’importe quelle machine et sans les droits d’administrateur du système. Ce langage est caractérisé par une large base de bibliothèques relatives à de nombreux domaines, en particulier pour le calcul scientifique. Il tend à être de plus en plus utilisé pour le développement de codes de calcul parallèles. Toutefois, il présente l’inconvé- nient, dû à l’aspect interprété, de conduire à des performances numériques de base assez médiocres dans le cadre d’une utilisation naïve. Il existe de nombreux moyens d’améliorer ces performances comme les modules NumPy et Cython. Le premier fournit un grand nombre d’outils et d’algorithmes pour le calcul scientifique. Le second propose des optimisations plus poussées permettent de retrouver des performances équivalentes à celles obtenues avec des langages compilés. D’autre part, Python est généralement utilisé comme interface pour l’utilisation de différentes librairies compilées et optimisées. Le surcoût de la couche Python est négligeable et on obtient directement les performances de ces librairies. De nombreux exemples de code de calcul scientifique sont écrits en Python (Pérez et al., 2011 ; Rashed et al., 2012 ; Logg et al., 2012). Dépendances externes Fort de toutes ces caractéristiques, ce langage est en plein essor dans la communauté scientifique. Cela se traduit par une très forte activité des développeurs qui fournissent de très nombreux modules sans cesse améliorés. La plupart des librairies traditionnelles possèdent une interface Python qui sont bien souvent augmentées de fonctionnalités ou de simplifications inhérentes au langage. En particulier, nous utilisons le module MPI4Py qui permet d’utiliser la librairie d’envoi de message MPI pour le parallélisme à mémoire distribuée. De même, la librairie H5py permet l’écriture et la lecture de données numériques au format HDF5. Dans le but de l’exploitation de machines de calcul parallèles, nous intégrons différents niveaux de parallélisme. Nous verrons par la suite que l’utilisation d’une carte graphique revient à l’expression d’un parallélisme à mémoire partagée. Nous détaillerons également les mécanismes mis en place pour l’utilisation de machines à mémoire distribuée, à travers la librairie MPI. D’autre part, Python permet de réaliser simplement des interfaces avec des langages compilés comme le C ou Fortran. Cela nous permet d’utiliser les librairies fftw pour les transformées de Fourier des méthodes spectrales ainsi que l’implémentation en Fortran de la méthode semi-Lagrangienne développée par Lagaert et al. (2014). 714. Développement d’un code multiarchitectures Fonctionnement global Nous achevons cette partie par une illustration de son utilisation à travers un exemple simple permettant la résolution d’un problème de transport. Un exemple de script minimal dont la majorité du code concerne l’étape de description du problème est donné en figure 4.3. Les deux fonctions permettent d’initialiser les variables. Le problème est créé avec un seul opérateur dont les calculs s’effectuent à une résolution de 1283 lors de chacune des 10 itérations. Dans cet exemple simple, l’opérateur d’advection se construit sur ses paramètres de résolution par défaut. En pratique, il convient de donner les détails de la méthode numérique comme l’ordre d’intégration en temps ou la formule de remaillage et éventuellement des spécifications en rapport avec l’architecture employée. Comme le montre l’exemple, l’interface utilisateur ainsi développée permet d’exprimer, à travers les classes Python, une sémantique proche du langage mathématique. Cela rend l’utilisation proche de celle proposée par un langage dédié. Un tel langage constitue l’expression idéale d’une interface utilisateur car il consiste en la définition d’un nouveau langage de programmation dont la sémantique est issue du domaine d’application du programme. Ainsi, l’utilisateur exprime ses besoins dans un langage ayant un sens pour l’application, ce qui conduit à une grande simplicité d’utilisation. Cependant, le développement de ce langage est assez difficile. Une approche plus simple consiste à embarquer seulement de nouveaux éléments de syntaxe dans le langage du programme (Mernik et al., 2005). La librairie décrite précédemment nous permet, de par sa conception, d’intégrer un module pour l’exploitation de cartes graphiques sans perte de portabilité sur les machines dépourvues de ce matériel. Les GPU diffèrent sensiblement des processeurs classiques tant par leurs architectures que par leurs modèles de programmation. Dans cette seconde partie, nous détaillons le fonctionnement de ces cartes. 4.2. Calcul générique sur carte graphique 4.2.1. Description du matériel Fonctionnement des cartes graphiques Les cartes graphiques que nous utilisons aujourd’hui ont été introduites à la fin des années 90. La fonction principale de ces cartes est de générer des images bidimensionnelles destinées être affichées sur un écran. Dès le milieu des années 90, les cartes sont capables de gérer un contenu tridimensionnel et sont principalement pour l’usage des jeux vidéo et à l’infographie. Dans les années 2000, l’augmentation des performances des cartes grand public rend ce matériel très compétitif en termes de capacité de calcul, relativement à leur coût d’achat. Cela conduit à l’émergence du GPGPU, acronyme anglais signifiant calcul générique sur processeur graphique. Dans le cadre du rendu 3D, une carte graphique effectue un traitement en chaîne, représenté en figure 4.4. Premièrement, le Vertex processor, calcule un ensemble de points 724.2. Calcul générique sur carte graphique Script Python : im p o r t parmepy a s pp d e f s 0 ( r e s , x , y , z , t = 0. ): r e s = . . . r e t u r n r e s d e f u0 ( r e s , x , y , z , t = 0. ): r e s = . . . r e t u r n r e s # Domaine O = pp . Box ( o r i g i n =[0 , 0 , 0 ] , l e n g t h =[1 , 1 , 1 ] ) T = pp . Simu ( t i n i t =0. , t e n d =1. , n b I t e r =10)) # V a r i a b l e s u = pp . F i e l d ( domain=O, v e c t o r=True , f o rm u l a=v _ i n i t ) s = pp . F i e l d ( domain=O, v e c t o r=F a l s e , f o rm u l a=s _ i n i t ) # O p e r a t e u r s a dvec = pp . A d v e c t i o n ( s , v e l o c i t y=u , r e s o l u t i o n =[128 , ] ∗ 3 ) # P r o b l ème pb = pp . P roblem ( o p e r a t o r s =[ advec , ] , simu=T) # I n i t i a l i s a t i o n pb . s e t u p ( ) # Ré s o l u t i o n pb . s o l v e ( ) Formalisme mathématique équivalent : s0(x) = . . . u0(x) = . . . Ω = [0; 1]3 T = [0; 1] u : Ω × T 7→ R 3 u(x, t = 0) = u0(x) s : Ω × T 7→ R s(x, t = 0) = s0(x) ∂s ∂t + (u · ∇)s = 0 Figure 4.3. – Exemple de script utilisateur 734. Développement d’un code multiarchitectures à partir de la géométrie à afficher. Ensuite, les objets tridimensionnels sont projetés sur un ensemble de pixels afin d’éliminer les parties cachées par la perspective. Les pixels sont ensuite transformés par le Fragment processor, notamment par l’application de textures. Enfin, les pixels sont assemblés dans la grille de pixels qui constituent l’image à afficher sur l’écran. Aux débuts du calcul générique sur GPU, la programmation des cartes s’effectuait en détournant cet enchaînement d’étapes par le développement de fonctions spécifiques destinées à être exécutées par le Vertex processor et le Fragment processor. Vertex Processor Rasterizer Fragment Processor Output Assembler Écran Données brutes Objets 3D Pixels Pixels Image calculés Figure 4.4. – Transformations en chaîne pour le rendu graphique Architecture des cartes graphiques Ce matériel spécifique est composé de nombreux éléments dont l’architecture diffère des processeurs classiques. Les composants principaux d’une carte graphique sont le processeur graphique et la mémoire vidéo. Les processeurs graphiques se caractérisent par un très grand nombre d’unités de calcul permettant de réaliser les opérations sur les sommets de la géométrie ainsi que des transformations des pixels. Ces unités sont spécialisées dans le traitement de données vectorielles jusqu’à quatre composantes (coordonnées spatiales ou canaux de couleurs d’un pixel). D’autre part, les unités de calculs réalisent de manière efficace des opérations simples sur ces données comme les additions, multiplications et produits scalaires. La mémoire vidéo est généralement divisée en deux zones distinctes. Une première partie permet des accès classiques en lecture et écriture et une seconde est spécialisée en lecture ou en écriture pour le stockage de données de textures 2D ou 3D. Comparativement à un processeur classique, un GPU permet un très haut débit de tâches élémentaires et indépendantes effectuées en parallèle par les unités de calcul (UC dans la figure 4.5). Ces dernières se partagent différents niveaux de cache. La figure 4.5 compare les représentations d’un processeur multicœur, 4.5a et d’un GPU, 4.5b. Dans les deux cas, seul le niveau de cache le plus haut est représenté. Alors que sur CPU, le nombre de cœurs dépasse rarement la dizaine, il atteint plusieurs milliers sur un GPU. D’autre part, les CPU peuvent accéder à la mémoire globale du système alors que la mémoire disponible sur un GPU est généralement inférieure à 8 GByte. 744.2. Calcul générique sur carte graphique Mémoire Cache Contrôleur UC UC UC UC (a) CPU Mémoire UC Contrôleur Cache (b) GPU Figure 4.5. – Comparaison haut niveau de l’architecture d’un CPU et d’un GPU L’intégration de la carte graphique au système principal se fait par une connexion à la carte mère par PCI Express dont le débit varie de 1 à 16 GByte/s selon la version. Cela constitue bien souvent un goulet d’étranglement pour les applications car le temps de transfert des données est bien plus long que le temps de leur traitement sur la carte. 4.2.2. Différentes méthodes de programmation Le calcul générique sur GPU a été grandement simplifié par les interfaces de programmations. Elles permettent de s’affranchir de la chaîne de traitement graphique, représentée en figure 4.4, au profit d’une exploitation directe des ressources des cartes. Le principe gé- néral d’un calcul sur GPU est de traiter des données régulières (proches d’une image) dont les algorithmes se décomposent selon un modèle hiérarchique en sous-blocs qui sont euxmêmes constitués d’un ensemble de tâches élémentaires par unité de donnée. Il existe deux grandes familles de modèles de programmation des GPU dont les principaux représentants sont évoqués ci-après. Programmation par directives La programmation par directive sur GPU est très similaire à l’utilisation de l’interface de programmation parallèle OpenMP pour les architectures à mémoire partagée. Les standards de programmation les plus répandus sont HMPP, introduit par Dolbeau et al. (2007), et OpenACC, qui est désormais inclus dans OpenMP depuis sa version 4.0 (2013). Ils permettent d’exécuter des parties du code, le plus souvent des boucles, sur des accéléra- 754. Développement d’un code multiarchitectures teurs par l’insertion de directives de compilation spécifiques. L’intérêt majeur de ce modèle est de pouvoir utiliser ces accélérateurs sans avoir à réécrire le code concerné. Cependant cela empêche une gestion fine de la transcription vers les instructions GPU, cette partie du travail étant effectuée par le compilateur. Le support est généralement assuré par des compilateurs commerciaux fournis notamment par CAPS Entreprise pour HMPP ou PGI pour OpenACC. Toutefois, ce dernier est en cours l’intégration au compilateur libre GCC. Programmation directe À l’opposé de la famille précédente, se trouve la programmation utilisant un langage spécifique. Il en existe plusieurs pour les GPU dont les plus utilisés sont CUDA (Nvidia, 2014) et OpenCL (Khronos, 2014). Le premier est développé par la société Nvidia pour l’utilisation exclusive de ses cartes. Le second est un standard de programmation ouvert permettant l’exploitation de processeurs multicœurs, que ce soit des processeurs traditionnels, des cartes graphiques ou des coprocesseur. Les deux langages sont assez proches et se basent sur un modèle de programmation qui reflète l’architecture du matériel. Cependant, OpenCL bénéficie d’une portabilité bien plus grande car il permet d’exploiter non seulement les cartes graphiques mais aussi les processeurs multicœurs. CUDA comme OpenCL bénéficient d’interfaces performantes en Python (Klöckner et al., 2012). 4.2.3. Les modèles de programmation OpenCL Le standard de programmation OpenCL permet de développer des modèles de parallé- lisme par tâches et de données sur processeurs multicœurs. La librairie fournit une interface de programmation de haut niveau permettant la gestion des calculs et des ressources ainsi que le profilage des applications. Les calculs de bas niveau sont implémentés en un langage basé sur le C99. Une application OpenCL se doit de définir les quatre modèles hiérarchiques suivants. Les termes techniques sont systématiquement traduits dans cette partie mais pourront être utilisés en anglais dans la suite. Le modèle de plateforme Du point de vue OpenCL, une plateforme est constituée d’un hôte (host) et de un ou plusieurs appareils (devices). Ces derniers regroupent, de manière générique, bon nombre de matériel multicœur comme les cartes graphiques mais aussi les processeurs classiques ou les processeurs spécifiques. L’implémentation consiste en une partie de code exécutée par la machine hôte (host) et capable d’envoyer et d’exécuter des noyaux de calcul (kernels) aux appareils (devices). Le code des noyaux est compilé de manière spécifique aux appareils sur lequel il sera exécuté. Les noyaux sont exécutés par les cœurs (processing elements) de chaque unité de calcul (compute unit), ce qui reflète l’organisation matérielle des unités de calculs d’un GPU, comme illustré par la figure 4.6. 764.2. Calcul générique sur carte graphique Host Device Processing element Compute unit Figure 4.6. – Modèle de plateforme OpenCL Le modèle d’exécution On distingue deux catégories d’unités d’exécution : le programme exécuté par la machine hôte et les noyaux. À chaque appareil (device) est associé une ou plusieurs files d’attente de commandes dans lesquelles sont insérées les transferts de données et les appels aux noyaux. Ces derniers sont définis par un état d’exécution (soumis, en attente, démarré, terminé, . . .) dont les durées entre transitions sont mesurables par l’outil de profilage intégré. Des dépendances entre les éléments peuvent être données explicitement, ce qui conduit à l’expression d’un parallélisme par tâche à travers une exécution asynchrone. La caractéristique principale est que chaque noyau est exécuté, par un cœur de calcul, comme une fonction en un point d’un espace d’indice représenté sur la figure 4.7. Cet espace est décomposé en un ensemble de groupes de travail (work-groups) contenant plusieurs éléments de travail (work-items). À chaque élément de travail (work-item) est associé un cœur de calcul. Espace global Work-group GX GY 0 1 2 3· · · 0 1 · · · NX 0 1 2 3 . . . 0 1 . . . NY · · · · · · · · · . . . . . . . . . 0 1 2 · · · 0 1 2 . . . WX WY Figure 4.7. – Espace d’indices OpenCL. Espace 2D de taille GX ×GY impliquant NX ×NY work-groups composés de WX × WY work-items, avec G• = N•W• 774. Développement d’un code multiarchitectures L’espace d’indices est un espace cartésien mono-, bi- ou tridimensionnel. Chaque élément de travail (work-item) est identifié de manière unique par ses coordonnées dans l’espace global ou par le couple des coordonnées du groupe (work-group) et d’une coordonnée locale au groupe (work-groups), comme illustré par la figure 4.7. Les tailles de l’espace global et des groupes de travail sont données en paramètres à chaque exécution d’un noyau. Le parallélisme de données est obtenu en reliant l’espace d’indices et l’indexation des données. Différents niveaux de synchronisation sont possibles. L’exécution des éléments de travail (work-items) est concurrente au sein d’un groupe (work-group). Il est possible de synchroniser les éléments au sein d’un même groupe à l’aide de barrières. Par contre il est impossible de synchroniser les groupes entre eux, de même qu’il n’est pas possible de spécifier l’ordre dans lequel ils seront exécutes ni de savoir lesquels seront exécutés simultanément. Du côté de l’hôte, la synchronisation globale se fait par l’intermédiaire de la file d’attente et de l’état de chaque noyau de calcul. Le modèle de mémoire Dans ce modèle, la mémoire de l’hôte est dissociée de celle des appareils. Cette dernière est décomposée en quatre région distinctes : Globale : niveau le plus haut, il est partagé en lecture et écriture par tous les éléments de travail de tous les groupes (∼ 1 GByte). Constante : mémoire accessible en lecture seule par les éléments de travail au cours de l’exécution. De taille assez faible, elle permet de stocker des constantes numériques (∼ 10 kByte). Locale : niveau intermédiaire partagé au sein d’un groupe de travail. Ce niveau peut être utilisé explicitement comme un cache (∼ 10 kByte). Privée : niveau le plus bas, il est dédié à un élément de travail et inaccessible aux autres (< 1 kByte). La mémoire globale ne peut contenir que des Buffers ou des Images. Les premiers sont des zones mémoires contiguës destinées à un usage générique comme un tableau d’éléments. Les seconds sont stockés dans la mémoire dédiée aux textures sous la forme d’une structure de données complexe et dont les accès, en lecture seule ou écriture seule, sont gérés par des fonctions OpenCL prédéfinies. Ce modèle hiérarchique est schématisé en figure 4.8. Comme nous le verrons par la suite, une gestion précise des transferts de données entre ces différents niveaux de mémoire est fondamentale pour l’amélioration les performances. Le modèle de programmation Afin d’exploiter tous les modèles définis précédemment, une application OpenCL se décompose selon trois couches dont il est nécessaire de décrire tous les niveaux. Au niveau de la plateforme, le programme hôte explore l’architecture disponible et un contexte OpenCL doit être créé afin de lier le ou les appareils utilisés avec l’hôte et pour créer les files de tâches associées à chaque appareil. Le compilateur OpenCL permet de compiler les sources des noyaux de calcul spécifiquement pour un appareil ciblé. Au niveau des modèles de mémoire et d’exécution, le programme est constitué de la gestion des files d’évènements ainsi que de 784.2. Calcul générique sur carte graphique Mémoire globale du système host Mémoire globale Constante device work-group Mémoire locale P. w.i. P. w.i. P. w.i. P. w.i. Figure 4.8. – Modèle hiérarchique OpenCL pour la mémoire transferts de données entre les mémoires de l’hôte et des appareils. Un schéma d’exécution est représenté en figure 4.9. Dans l’idéal, la conception des algorithmes doit permettre une gestion asynchrone des évènements afin de maximiser l’utilisation des composants. Cette dernière est maximale lorsque des calculs sont effectués simultanément sur les appareils et sur l’hôte ainsi que pendant des transferts de données. . . . Initialisation OpenCL Compilation Transferts Exécution des kernels Calculs Host Device Création de la file d’exécution Figure 4.9. – Schéma d’exécution OpenCL La figure 4.9 représente les durées d’exécution à titre d’illustration car les proportions entre les différentes étapes ne reflètent pas nécessairement les temps observés dans une application. 794. Développement d’un code multiarchitectures 4.2.4. Analyse de performances par le modèle roofline En préambule à l’étude des performances de l’implémentation, il est nécessaire d’explorer les performances atteignables par le matériel. Le code est développé et exploité sur différents types de machines depuis un portable jusqu’à un serveur de calcul. Une partie des caractéristiques techniques des cartes graphiques sur lesquelles le code a été exploité sont présentées dans le tableau 4.1. Les deux premières cartes sont comparables et ont permis essentiellement les développements du début de ce travail. La carte K20m est bien plus récente que les deux autres et bénéficie de technologies bien plus avancées. Carte AMD Radeon AMD Radeon Nvidia HD 6770M HD 6900 Series K20m Type de machine portable bureau serveur Date de mise sur le marché 01/2011 12/2010 01/2013 Taille mémoire (GByte) 1 1 5 Bande passante max. (GByte/s) 57.6 160 208 Puissance (SP) (GFLOPS) 696 2 253 3 519 Puissance (DP) (GFLOPS) Non supporté 563 1 173 Tableau 4.1. – Comparaison de différentes cartes graphiques Les études de performances des noyaux de calcul présentées dans la suite sont réalisées à travers le modèle roofline introduit en section 1.2.2. Nous donnons ici le modèle pour les cartes Radeon 6770M et K20m sur les figures 4.10 en utilisant les données théoriques mais aussi des mesures de performances par des programmes de test. Les deux données nécessaires à l’élaboration du roofline sont la bande passante maximale et la puissance de calcul maximale. La première est obtenue à l’aide d’un kernel réalisant une copie d’un buffer à un autre. La puissance maximale, quand à elle, est obtenue à partir d’un kernel ayant une grande intensité opérationnelle. Le kernel que nous utilisons réalise 50 instructions d’additions et multiplications sur 4 variables de type vecteur à 4 composantes en simple ou en double précision, le tout dans une boucle de 20 itérations, soit 32 000 opérations par work-item. Les performances mesurées sont résumées dans le tableau 4.2. La capacité de certaines cartes graphiques à effectuer des calculs en double précision est assez récente. La raison principale est que la précision numérique n’est pas une priorité dans le cadre de l’affichage d’un contenu graphique. La principale contrainte est d’afficher des images sur l’écran en un temps le plus court possible. Cela est poussé à l’extrême dans certains modèles qui ne sont pas conformes à la norme IEEE 754 pour le calcul en virgule flottante. Sur la majorité des cartes, des options de compilations spécifiques permettent d’autoriser le compilateur à ne pas respecter cette norme. Toutefois, les cartes qui la supportent possèdent généralement moins de cœurs capables de traiter la double précision que de cœurs pour la simple précision ce qui conduit à des performances en double précision bien inférieures à la simple précision. Le mécanisme ECC, de l’anglais Error Correction Code, activé par défaut sur les cartes Nvidia permet de vérifier et corriger, à l’exécution, les accès aux données en mémoire et ainsi remédier à d’éventuelles erreurs dues à des facteurs extérieurs. Ce mécanisme consomme 804.2. Calcul générique sur carte graphique Théorique Mesuré Mesuré (sans ECC) Simple précision Double précision 101 102 103 104 1 10 100 Puissance maximale (GFLOPS) Intensité opérationnelle (FLOP/Byte) (a) ATI Radeon 6770M 101 102 103 104 1 10 100 Puissance maximale (GFLOPS) Intensité opérationnelle (FLOP/Byte) (b) Nvidia K20m Figure 4.10. – Modèle roofline Bande passante (GByte/s) ATI Radeon 6770M Nvidia K20m Théorique 57.6 208 Mesurée 36.9 (64%) 152 (73%) ECC désactivé – 172 (83%) Puissance, simple précision (GFLOPS) Théorique 696 3 519 Mesurée 632 (91%) 3 350 (95%) Puissance, double précision (GFLOPS) Théorique – 1 173 Mesurée – 1 173 (100%) Tableau 4.2. – Performances mesurées. 814. Développement d’un code multiarchitectures 12.5% de la mémoire de la carte et réduit d’environ 12% la bande passante, comme le montre les résultats du tableau 4.2. Dans cette dernière partie, nous détaillons la mise en pratique de l’utilisation des cartes graphiques dans la librairie de calcul ainsi que la principale mesure de performances. 4.3. Utilisation de cartes graphiques dans la librairie L’implémentation de ces modèles de programmation est réalisée à travers le module Python PyOpenCL et s’insère dans le diagramme de classe présenté en figure 4.2, page 69. La figure 4.11 donne les nouvelles classes ainsi que leurs relations avec le modèle existant. Le modèle de mémoire est implémenté dans la classe GPUDVariable et encapsule un pointeur vers un objet mémoire GPU ainsi qu’une interface pour les transferts de données avec l’hôte. Le modèle de plateforme est intégré dans la classe outil ClEnvironment et permet de créer et de gérer les objets du le contexte et de la file d’attente des appareils ainsi que la compilation du code OpenCL. Enfin, le modèle d’exécution est décrit par les interactions entre les GPUDOperators. Les évènements créés par les appels aux kernels sont associés aux variables et permettent d’exprimer un parallélisme par tâches. L’intérêt majeur de séparer l’implémentation GPU dans un module distinct est de pouvoir s’affranchir de cette partie du code sur les machines dépourvues d’accélérateurs et d’implémentation OpenCL et ainsi, garantir une portabilité suffisante à la librairie. D’autre part, grâce à cette séparation, un module GPU basé sur le langage CUDA, par exemple, pourrait être intégré à la librairie sans aucun impact sur le reste du code. Nous démontrons ici la simplicité d’ajout de la prise en compte d’une nouvelle architecture particulière à la librairie de calcul. En effet, seuls les éléments dépendants de cette architecture sont à implémenter. Conclusion Dans ce chapitre nous avons obtenu une librairie de calcul présentant une grande souplesse d’utilisation ainsi qu’une forte capacité d’adaptation à des architectures hétérogènes, comme les GPU. L’obtention de ces caractéristiques est possible à travers l’utilisation d’un paradigme de programmation orientée objet ainsi qu’une conception basée sur une stratégie de découpage sémantique des concepts mathématiques exprimés à travers différents niveaux d’abstraction. La librairie ainsi conçue permet une grande flexibilité pour le développement grâce à un faible couplage des différentes parties et à une forte cohésion à travers les niveaux d’abstraction. Le choix du langage de programmation a été fait en fonction des caractéristiques de la librairie, qui s’expriment à travers la conception, et les objectifs d’utilisation du code. Ainsi, le choix s’est porté sur le langage Python dont un des avantages est de proposer de nombreux modules pour le calcul scientifique comme le module NumPy ainsi que des interfaces vers des librairies externes comme les modules PyOpenCL pour OpenCL et MPI4Py pour MPI 824.3. Utilisation de cartes graphiques dans la librairie Operators Variables Tools <> DOperator <> NumMethod DVariable <> GPUDOperator opencl environment GPUDVariable gpu data to host to device ClEnvironment opencl platform opencl device opencl context opencl queue build sources GPUKernel sources opencl program compute CL sources n 1 n build GPU Figure 4.11. – Diagramme de classe pour le module GPU L’exploitation des cartes graphiques semble pertinent au regard des reports de puissance de calcul développée dans la littérature que ce soit de manière théorique par le matériel en lui-même ou à travers des applications concrètes. Comme nous le verrons dans le chapitre 5, la structure de donnée nécessaire à la mise en œuvre de la méthode particulaire avec remaillage s’adapte bien à un traitement par cartes graphiques. D’autre part, les sché- mas numériques associés à la méthode sont compacts et locaux du fait de l’utilisation du splitting dimensionnel. Le traitement d’un point ne requiert seulement que quelques points voisins dans une seule direction de l’espace. Enfin, la majeure partie des opérations du remaillage consistent en des additions et multiplications en nombre réels qui sont effectuées de manière très efficace par les cartes graphiques. 835. Mise en œuvre sur cartes graphiques La méthode numérique, exposée au chapitre 2, semble bien adaptée à l’utilisation de cartes graphiques dont les principales caractéristiques ainsi que les techniques d’exploitation ont été détaillés au cours du chapitre 4. L’objectif de ce chapitre est, dans un premier temps, de présenter les différentes implémentations existantes de méthodes particulaires avec remaillage sur cartes graphiques afin d’identifier leurs avantages et inconvénients. À travers l’exploration des travaux existants, l’accent est mis sur les interpolations entre les particules et le maillage. Une progression se dégage de l’évolution de l’exploitation des matériels depuis 2008. En effet, les travaux les plus anciens se basent essentiellement sur les primitives propres au traitement d’images à travers la chaîne de rendu graphique alors que la tendance actuelle est plutôt à utiliser des structures de données génériques, moins dépendantes du matériel. Dans un second temps, nous détaillerons les choix effectués dans le cadre spécifique de la méthode semi-Lagrangienne d’ordre élevé avec splitting dimensionnel. Ces différents choix ne dépendent pas du matériel utilisé mais s’appliquent à n’importe quelle carte graphique. Ainsi, nous conservons le caractère portable de notre code. Une grande partie de ce chapitre est dédiée à l’étude des performances des principales fonctions des algorithmes issus de la méthode et de l’impact des optimisations réalisées. Ces dernières sont présentées dans le cadre concret de la carte graphique K20m mais, dans un souci de portabilité, elles ne sont généralement appliquées que lors de l’exécution, pendant la phase d’initialisation. En effet, nous exploitons un des aspects de la programmation sur GPU qui consiste à compiler le code à l’exécution. Ainsi, le code est développé de manière générique puis, après une prise de connaissance de la carte employée et de ses caractéristiques, certaines optimisations sont activées pour la compilation. Sans implémenter une auto-optimisation du code, cette étape nous permet d’adapter, entre autres, les tailles de l’espace d’indices OpenCL, la charge par work-item ou encore le schéma d’accès aux données aux spécifications de la carte utilisée. Enfin, nous illustrerons l’utilisation de la méthode de résolution sur quelques exemples simples de transport de scalaire en 2D et 3D. Ces exemples permettent une validation de la méthode de manière qualitative ainsi qu’une description de la répartition des temps de calcul en vue d’éventuelles optimisations plus poussées. 855. Mise en œuvre sur cartes graphiques 5.1. Implémentations GPU de méthodes semi-Lagrangiennes 5.1.1. Méthodes semi-Lagrangiennes Une première implémentation sur GPU d’une méthode semi-Lagrangienne a été proposée par Rossinelli et al. (2008) pour la simulation de fluides incompressibles en 2D. La diffusion et l’équation de Poisson sont résolues par différences finies sur la grille et les particules sont transportées de manière Lagrangienne puis remaillées à l’aide d’une formule du second ordre M0 4 . Cette implémentation se base sur l’utilisation de la mémoire de textures. Cette mémoire spécifique aux GPU permet un stockage de pixels de telle sorte que les données voisines correspondent aux pixels voisins en 2D. Les particules sont représentées par des pixels où les composantes RGB sont associées respectivement aux positions et la vorticité des particules. Les auteurs montrent une performance globale de 10 itérations par seconde pour un problème de taille 1 0242 en simple précision en utilisant une méthode de RungeKutta du second ordre. Plus récemment, Rossinelli et al. (2010) présentent des résultats pour des simulations 2D d’écoulements en présence d’obstacles solides. La méthode employée est similaire à celle utilisée précédemment avec l’ajout de la prise en compte des obstacles par une méthode de pénalisation. Là encore, le remaillage est effectué par la formule M0 4 en utilisant les fonctions intrinsèques OpenGL pour le rendu graphique et des textures sont utilisées pour le stockage des données. L’équation de Poisson est résolue par un solveur spectral utilisant l’implémentation de la FFT fournie par Nvidia en CUDA dont la résolution occupe 96% du temps de calcul total. Les simulations considérées pour ces études de performances impliquent jusqu’à 2 0482 particules en simple précision. L’inconvénient majeur de l’utilisation des textures est que les données sont arrangées en tableaux de structures. Ce stockage n’est pas le plus approprié pour des opérations n’impliquant pas toutes les composantes des éléments. D’autre part, les équivalents 3D de cette mémoire sont uniquement proposés par les dernières générations de cartes graphiques. Ainsi, le passage à une méthode de résolution de problèmes 3D nécessite une attention particulière pour l’exploitation de structures de données essentiellement 2D. 5.1.2. Deux types d’interpolations Les méthodes semi-Lagrangiennes utilisent deux algorithmes majeurs pour les interactions entre les particules et le maillage basés sur des interpolations. Une interpolation maillage-particule permet d’évaluer sur les particules une quantité connue sur le maillage et inversement pour une interpolation particule-maillage. Le premier type d’interpolation est utilisé lors de l’advection des particules pour connaître leur vitesse alors que le remaillage exploite le second type. Stantchev et al. (2008) introduisent les stratégies particle-push et particle-pull pour réaliser l’étape d’interpolation particule-maillage. Ces deux stratégies diffèrent au niveau de l’organisation de la charge de travail. La première consiste en un traitement centré sur les particules dont le principe est de les remailler sur les points de grille de leur voisinage. Elle permet un calcul simple des points de grille contenus dans le support 865.1. Implémentations GPU de méthodes semi-Lagrangiennes de la particule à partir de ses coordonnées et permet également, dans un cas tensoriel, une réutilisation des poids de remaillage. Cependant, des accès conflictuels en mémoire peuvent survenir lors du traitement en parallèle de plusieurs particules situées dans la même cellule. La seconde est centrée sur le maillage de telle sorte qu’en chaque point de grille on agrège les contributions des particules voisines. Le seul avantage de la seconde stratégie est de ne pas conduire à des accès concurrents en mémoire. Dans cette stratégie, une recherche des particules les plus proches est nécessaire. Les méthodes de type particle-in-cell sont basées sur ces interpolations. Pour les interpolations particule-maillage, la majeure partie des implémentations exploitent des stratégies particle-pull et relaxent les éventuels problèmes d’accès concurrents par un regroupement des particules voisines en blocs qui sont traités de manière séquentielle par un même processus. Ainsi, un tri des particules à deux niveaux est nécessaire, d’abord par blocs puis au sein d’un bloc. Différentes techniques sont employées comme par exemple le maintien d’une structure de données triée (Rossi et al., 2012) ou un tri à chaque itération (Kong et al., 2011). Quelque soit la méthode employée pour le tri, cela implique des réarrangements de données au gré des déplacements des particules afin d’assurer un haut niveau de localité des données. Les interpolations de type maillage-particule sont plus simples à mettre en œuvre puisque l’interpolation se fait sur la grille dont la structure est régulière. Pour ce qui est des méthodes particulaires avec remaillage, les premières implémentations GPU exploitaient les primitives OpenGL du rendu graphique. En particulier, Rossinelli et al. (2008) montrent que le remaillage des particules est bien plus efficace, avec une facteur d’accélération de 1.5, lorsque qu’il est effectué par le moteur de rendu OpenGL plutôt que par une implémentation CUDA. Cette implémentation se base sur des objets point-sprites permettant la génération d’une texture contenant, après exécution du rendu en chaîne, les sommes des contributions de l’ensemble des point-sprites. Ainsi, l’étape exécutée par le fragment processor consiste à calculer les pixels de la texture par la formule de remaillage en fonction de la distance aux point-sprites et de leur valeur. Les auteurs soulignent ici un inconvénient de l’utilisation du langage CUDA qui est de ne pas permettre une exploitation des fonctionnalités natives du matériel, en particulier les opérations du rendu graphique. L’étape du vertex processeur permet, en amont du remaillage, de traiter les conditions aux bords périodiques par une réplication des particules situées à proximité des bords ainsi que d’écarter les particules transportant une quantité nulle ou inférieure à un certain seuil. Cette approche est ensuite complétée (Rossinelli et al., 2010) pour le cas de domaines ouverts. Les auteurs traitent les particules quittant le domaine local en les écartant au moment de l’étape du vertex processor qui précède le remaillage. D’autre part, dans leur implémentation, un remaillage systématique est effectué à chaque itération ce qui fait que les particules sont toujours situées sur un point de grille au début de l’étape d’advection et permet ainsi d’éviter une interpolation maillage-particule du champ de vitesse. Une interpolation reste nécessaire pour la seconde étape du schéma d’intégration Runge-Kutta du second ordre. Une étude spécifique de l’interpolation maillage-particule est menée par Rossinelli et al. (2011) sur des architectures multicœurs CPU et GPU. Comme précédemment, l’implémentation GPU se base sur un stockage des particules en mémoire de textures. Les données d’une même particule ne sont plus stockées dans un pixel mais par composantes dans plusieurs textures. Chaque pixel contient les données de quatre points de grille dans la direction 875. Mise en œuvre sur cartes graphiques des pixels. Dans leur étude, les auteurs utilisent la formule M0 4 pour une interpolation tensorielle en 2D. Ainsi dans un traitement ligne par ligne, deux pixels consécutifs contiennent nécessairement toute l’information pour traiter une particule. Parmi les 8 données lues, seules 4 sont nécessaires, les auteurs utilisent des poids booléens afin de s’affranchir de branchements conditionnels. L’inconvénient de cette approche est qu’il est nécessaire de charger en mémoire 8 éléments (2 pixels) dans la direction des pixels pour n’utiliser que les quatre éléments du support de la particule. Les auteurs atteignent 72% de la performance maximale atteignable en simple précision et les performances chutent fortement en double précision. Plus récemment, Büyükkeçeci et al. (2012) réalisent une étude des deux types d’interpolations maillage-particule et particule-maillage basées sur des stratégies respectivement mesh-pull et particle-push ce qui conduit à des algorithmes centrés sur les particules dans les deux cas. Les auteurs proposent une implémentation générique dans laquelle les particules sont réarrangées dans une structure de donnée hiérarchique permettant un stockage contigu des particules de la même région de l’espace. Cette structure se base sur un traitement séquentiel des particules dans une même cellule en utilisant autant de copies du domaine que du nombre maximal de particules par cellule. Cela conduit à n’avoir qu’une seule particule par cellule et par copie ainsi que des cellules vides. Les cellules vides sont peuplées de particules factices, écartées à la fin de l’interpolation, ce qui permet d’éviter des branchements conditionnels. Des études systématiques de performances sont réalisées sur plusieurs cartes graphiques pour chaque interpolation avec des formules linéaire ou M0 4 et pour des problèmes 2D et 3D. Les auteurs soulignent que les meilleures performances sont obtenues pour les cas 3D utilisant la formule M0 4 . Ils montrent des accélérations significatives du temps de calcul entre leur implémentation GPU et une référence multicœur CPU. Même si cette implémentation est efficace, les performances globales restent limitées par l’intégration à la librairie PPM. En effet, l’utilisation de ce remaillage nécessite un transfert des données en entrée ainsi que de retourner les résultats sur la mémoire de la machine hôte avant de réaliser les autres parties de la résolution. Le facteur d’accélération obtenu est généralement inférieur à 10, et même inférieur à 1 dans certains cas, en prenant en compte ce temps de transfert. À partir des différentes implémentations existantes de méthodes semi-Lagrangiennes et en particulier des interpolations entre le maillage et les particules, nous proposons une implémentation qui exploite les différents aspects inhérents à la méthode considérée. En effet, l’utilisation d’un splitting dimensionnel est à l’origine de bon nombre de choix présentés dans ce qui suit. Les données sont stockées dans des tableaux classiques, sans aucune utilisation de structures de données spécifiques aux cartes graphiques comme les textures ou les pixels. Après une description de ces choix, nous présentons les performances de chaque fonction de la méthode pour la carte Nvidia K20m. La restriction à une seule carte permet de simplifier la présentation des résultats et l’extension à d’autres cartes se fait par adaptation des configurations aux caractéristiques techniques de ce nouveau matériel. Les performances sont données dans les métriques adaptées à chaque cas. 885.2. Implémentation et performances 5.2. Implémentation et performances 5.2.1. Adéquation de la méthode au matériel Les implémentations réalisées dans le cadre de ce travail sont basées, à l’instar de Büyükkeçeci et al. (2012), sur des stratégies mesh-pull pour les interpolations de type maillage-particule ainsi que particle-push pour le type particule-maillage. Toutefois, l’utilisation d’un splitting dimensionnel nous permet d’envisager l’emploi de formules de remaillage d’ordre élevé ayant un large support. Du point de vue de l’implémentation, cela conduit à un algorithme avec une localité des données plus forte que dans le cadre de méthodes classiques. En effet, le traitement d’une donnée (particule ou point de grille) ne nécessite que quelques données voisines uniquement dans la direction courante. La méthode revient à la résolution de nombreux sous-problèmes monodimensionnels ce qui pousse naturellement à l’emploi d’une structure de donnée également 1D. Ainsi, nous utilisons des objets mémoire linéaires comme les buffers qui correspondent à des tableaux classiques. Le découpage par splitting dimensionnel permet également de considérer séparément les composantes des vecteurs, en particulier de la vitesse, lors de l’étape d’advection. Nous employons donc une structure de donnée en tableaux par composantes et non pas en tableau de structures. En pratique les composantes d’un vecteur sont stockées sous la forme de plusieurs tableaux de scalaires. Dans la suite de cette thèse, nous prenons comme convention, sans que cela n’implique aucune restriction, que les données sont stockées dans un ordre en colonne, à l’instar du langage Fortran. Le stockage monodimensionnel des données d’un tableau de taille (NX, NY , NZ) dans un espace de taille NX × NY × NZ est illustré en figure 5.1. . . . . . . . . . . . . . . . . . . NX NZ NY Tableau 3D : (NX, NY , NZ ) ←→ Tableau 1D : NX × NY × NZ Figure 5.1. – Convention de stockage des données multidimensionnelles Ainsi, lors des différentes étapes de splitting, le traitement de la première direction de stockage des données conduit à des accès contigus en mémoire. Ce qui n’est plus le cas lors du traitement des autres directions. Afin d’éviter une dégradation des performances due à ces accès, nous mettons en place des transpositions des données pour le traitement des différentes directions de l’espace. En effet, les performances des accès en mémoire globale sont généralement plus faibles lors d’accès avec un saut, même constant, comme représenté par les flèches vertes et bleues sur la figure 5.1. Ainsi, l’accès aux données est toujours contigu en mémoire pour toutes les directions. Ce choix conduit à trois remarques à propos de la mise en œuvre de ces transpositions. Premièrement, le champ de vitesse u n’est 895. Mise en œuvre sur cartes graphiques utilisé que composantes par composantes dans les étapes de splitting. Lors de l’advection dans la direction X, seule la composante uX est utilisée. Par conséquent, les composantes des vecteurs, en particulier de la vitesse, sont toujours stockées de manière a avoir un accès contigu dans la direction concernée. Deuxièmement, les positions des particules à l’issue de l’étape d’advection ne changent que dans leur composante correspondant à la direction courante, les autres composantes restent inchangées car le déplacement est 1D. Cela nous permet de réduire le vecteur position des particules à un scalaire correspondant à la composante de la direction courante et ainsi de réduire l’emprunte mémoire de la méthode. Enfin, en dehors des transpositions, toutes les directions sont traitées de manière identique. En pratique, le même code s’applique dans toutes les directions moyennant une paramétrisation des dimensions des tableaux dans les cas de grilles non cubiques. Comme nous l’avons détaillé au chapitre 2, les trois étapes de résolution consistent en une initialisation en chaque point de grille, un déplacement puis un remaillage des particules. Lors de l’étape d’initialisation, la position des particules est directement donnée par la coordonnée du point de grille associé et la quantité transportée par la particule est simplement une copie de la valeur au point de grille. Ainsi dans notre implémentation, cette initialisation est remplacée par une transposition lorsque la direction courante change. En effet, une simple copie suffit dans le cas contraire car les données sont déjà dans le bon ordre de stockage. Les algorithmes 1 à 4 détaillent les étapes d’une itération complète de la méthode. Les données manipulées sont limitées aux composantes du champ de vitesse, aux valeurs sur la grille des quantités transportées, à un scalaire pour la position des particules et aux valeurs transportées par les particules. La figure 5.2 illustre l’algorithme 2 dans le cas d’un splitting du second ordre en 2D et pour un domaine rectangulaire. Les données manipulées par les opérations d’advection et de remaillage pour un sous-problème 1D sont représentées par une bande rouge verticale dans les tableaux. Algorithme 1 : 2D, splitting d’ordre 1 Direction X : 1. u˜ ← Copie (u) 2. x˜ ← Advection (dt, aX) 3. u ← Remaillage (x˜, u˜) Direction Y : 4. u˜ ← TranspositionXY (u) 5. x˜ ← Advection (dt, aY ) 6. u ← Remaillage (x˜, u˜) Réarrangement des données : 7. u˜ ← TranspositionXY (u) 8. u ← Copie (u˜) Algorithme 2 : 2D, splitting d’ordre 2 Direction X : 1. u˜ ← Copie (u) 2. x˜ ← Advection (dt/2, aX) 3. u ← Remaillage (x˜, u˜) Direction Y : 4. u˜ ← TranspositionXY (u) 5. x˜ ← Advection (dt, aY ) 6. u ← Remaillage (x˜, u˜) Direction X : 7. u˜ ← TranspositionXY (u) 8. x˜ ← Advection (dt/2, aX) 9. u ← Remaillage (x˜, u˜) Dans tous les algorithmes (1 à 4), les deux premières étapes de chaque direction sont indépendantes. Ainsi, lors de l’exécution, un parallélisme par tâches pourra être exprimé et conduira à une exécution simultanée des étapes d’advection et des étapes de copie et de transposition. Une étape de réarrangement des données apparaît en fin d’algorithme 905.2. Implémentation et performances Algorithme 3 : 3D, splitting d’ordre 1 Direction X : 1. u˜ ← Copie (u) 2. x˜ ← Advection (dt, aX) 3. u ← Remaillage (x˜, u˜) Direction Y : 4. u˜ ← TranspositionXY (u) 5. x˜ ← Advection (dt, aY ) 6. u ← Remaillage (x˜, u˜) Direction Z : 7. u˜ ← TranspositionXZ (u) 8. x˜ ← Advection (dt, aZ) 9. u ← Remaillage (x˜, u˜) Réarrangement des données : 10. u˜ ← TranspositionXZ (u) 11. u ← TranspositionXY (u˜) Algorithme 4 : 3D, splitting d’ordre 2 Direction X : 1. u˜ ← Copie (u) 2. x˜ ← Advection (dt/2, aX) 3. u ← Remaillage (x˜, u˜) Direction Y : 4. u˜ ← TranspositionXY (u) 5. x˜ ← Advection (dt/2, aY ) 6. u ← Remaillage (x˜, u˜) Direction Z : 7. u˜ ← TranspositionXZ (u) 8. x˜ ← Advection (dt, aZ) 9. u ← Remaillage (x˜, u˜) Direction Y : 10. u˜ ← TranspositionXZ (u) 11. x˜ ← Advection (dt/2, aY ) 12. u ← Remaillage (x˜, u˜) Direction X : 13. u˜ ← TranspositionXY (u) 14. x˜ ← Advection (dt/2, aX) 15. u ← Remaillage (x˜, u˜) dans les cas d’un splitting du premier ordre. Cette étape est nécessaire pour retrouver le scalaire dans l’ordre de stockage initial de l’algorithme, afin de rendre ces transformations transparentes. En effet, dans tous les cas, les données du scalaire sur la grille sont stockée en fin d’algorithme dans le même ordre qu’au début. Les kernels sont donc développés indépendemment de la direction de résolution. Nous séparons les développements de kernels de l’étape d’initialisation de ceux du calcul. Les premiers regroupent les opérations de copie et les transpositions qui ne nécessitent aucun calcul. Leurs performances sont analysées en terme de bande passante. Les performances des seconds sont données dans le modèle roofline. 5.2.2. Préambule à l’étude des performances Sauf mention contraire, dans la suite de ce chapitre, nous présenterons des résultats en double précision pour la carte Nvidia K20m. En l’absence d’outils d’optimisation automatique, nous exploitons les caractéristiques du matériel pour paramétrer les exécutions des kernels. En particulier, le lien entre la taille des données et l’espace d’indice OpenCL ne suffit pas à déterminer complètement le nombre et la taille des work-groups. Dans l’état actuel de la librairie, cette paramétrisation des noyaux est réalisée de manière explicite pour les différents cas d’utilisation tels que le nombre de dimensions du problème, la précision utilisée et le matériel employé. Les paramètres donnant les meilleures performances ont été obtenus par petites variations autour de valeurs en 915. Mise en œuvre sur cartes graphiques 1. copie 2. advection 3. remaillage 4. Transposition XY 5. advection 6. remaillage 7. Transposition XY 8. advection 9. remaillage Direction X, dt/2 Direction Y , dt Direction X, dt/2 X Y Y X X Y Grille : Particules : Vitesse Scalaire Scalaire Positions Figure 5.2. – Algorithme pour une itération en 2D, splitting de Strang 925.2. Implémentation et performances adéquation avec le matériel. Le tableau 5.1 rappelle et détaille les principales caractéristiques pour la carte K20m. Le vocabulaire employé dans ce tableau est celui du langage CUDA pour les cartes Nvidia. Pour les cartes ATI, l’architecture est similaire et les warps sont appelés wavefronts. D’autre part les termes thread et thread block sont les équivalents CUDA de ce que sont les work-items et work-groups pour OpenCL. Puissance double (simple) précision 1 173 (3 519) GFLOPS Cœurs double (simple) précision 832 (2496) Bande passante 208 GByte/s Multiprocesseurs (MP) 13 Cœurs double (simple) précision par MP 64 (192) Mémoire partagée par MP 48 kByte Registres 32-bit par MP 65536 Nb. Threads par warp 32 Nb. max. de warps par MP 64 Nb. max. de threads par MP 2048 Nb. max. de thread blocks par MP 16 Nb. max. de registres par thread 255 Nb. max. de threads par thread blocks 1024 Tableau 5.1. – Caractéristiques techniques de la carte Nvidia K20m (Nvidia, 2012b ; Nvidia, 2012a) De manière générale l’obtention de bonnes performances sur GPU se fait en considérant finement les caractéristiques du matériel. Comme nous l’avons souligné précédemment, la mesure des performances se fait par diverses métriques souvent complémentaires comme la puissance de calcul ou la bande passante. L’occupation est une métrique spécifique aux cartes graphiques qui permet de mesurer l’utilisation des multiprocesseurs. Lors de l’exécution d’un kernel, les work-item sont associés aux cœurs physiques de la carte par groupes constituant un warp. Les multiprocesseurs possèdent un planificateur permettant une exé- cution simultanée de plusieurs warps. L’occupation est donc simplement le rapport entre le nombre de warps exécutés simultanément par multiprocesseur et le nombre maximal supporté. Ainsi, lors d’une exécution d’un kernel, la spécification de l’espace d’index ainsi que la quantité de mémoire partagée et le nombre de registres utilisés peuvent limiter l’occupation. Des outils de calcul d’occupation sont proposés à la fois par Nvidia 1 et AMD 2 . Le calcul de l’occupation nécessite la connaissance du nombre de registres utilisés par work-item. Cette information peut être obtenue par l’analyse des binaires produits par les compilateurs pour une carte spécifique. L’option de compilation -cl-nv-verbose permet d’obtenir ce nombre lors de la compilation avec OpenCL sur une carte Nvidia. Toutefois, comme le montre Volkov (2010) sur des exemples simples, la maximisation de l’occupation ne permet pas toujours de maximiser les performances. En effet, le temps que les unités de calculs mettent à effectuer les opérations arithmétiques ou à réaliser un accès en mémoire peut être exploité afin d’augmenter les performances. La latence arithmétique peut 1. http://developer.download.nvidia.com/compute/cuda/CUDA_Occupancy_calculator.xls 2. http://developer.amd.com/tools-and-sdks/archive/amd-app-profiler/user-guide/ app-profiler-kernel-occupancy/ 935. Mise en œuvre sur cartes graphiques être cachée en augmentant la charge de travail par work-item afin de bénéficier d’opérations non interdépendantes pouvant être exécutées simultanément. De même, il est possible de cacher la latence mémoire en utilisant d’avantage de registres et en réduisant le nombre de work-item. Ces optimisations au niveau des instructions (Instruction Level Parallelism) impliquent généralement une augmentation du nombre de registres et une diminution du nombre de work-item ce qui peut conduire à une diminution de l’occupation. De manière générale, il n’est pas possible de connaître a priori quelles optimisations sont préférables entre les instructions et l’occupation. C’est pourquoi dans les résultats qui vont suivre, les noyaux n’ont pas été optimisés systématiquement à différents niveaux. De plus, dans un souci de portabilité et de non spécialisation à une carte en particulier, les optimisations restent générales et basées uniquement sur les connaissances des caractéristiques techniques. 5.2.3. Initialisation des particules Les étapes d’initialisation des particules se caractérisent par une absence totale de calculs. Les opérations consistent uniquement en des transferts de données. Ainsi, les performances sont mesurées en terme de bande passante. Copie Cette opération consiste en une simple copie des données entre deux zones mémoire. Une fonction de copie directe est proposée par l’interface OpenCL. Dans cette comparaison, nous utilisons la fonction clEnqueueCopyBuffer pour la copie d’un buffer complet vers un autre. La figure 5.3 illustre le fonctionnement simple de ce kernel. La copie est réalisée directement par blocs successifs, en pointillés sur la figure. Chaque bloc est traité par un work-group dont les work-items, en pointillés, traitent un seul élément du tableau. La taille du workgroup est fixée à 256 work-item ce qui permet d’atteindre une occupation maximale avec 8 warps par multiprocesseur. Entrée Sortie Figure 5.3. – Fonctionnement du kernel de copie La figure 5.4 présente les performances atteintes par le kernel et la fonction OpenCL pour différentes tailles de tableaux en 2D (5.4a) et 3D (5.4b). Les résultats obtenus sont comparables et atteignent la bande passante maximale mesurée dès lors que la taille des tableaux est suffisamment grande. En effet, l’exécution sur des données trop petites ne permettent pas une occupation maximale de la carte et donc conduit à de mauvaises performances. Ainsi, nous donnons les performances pour les petites tailles, inférieures à 10242 ou à 1283 , seulement à titre indicatif. 945.2. Implémentation et performances OpenCL clEnqueueCopyBuffer kernel 0 10 20 30 40 50 60 70 80 322 1282 5122 20482 81922 Max. 0 20 40 60 80 100 120 140 160 10−2 10−1 1 101 102 103 % bande passante théorique Bande passante (GByte/s) Taille des tableaux (MByte) (a) 2D 0 10 20 30 40 50 60 70 80 323 643 1283 2563 5123 Max. 0 20 40 60 80 100 120 140 160 1 101 102 103 % bande passante théorique Bande passante (GByte/s) Taille des tableaux (MByte) (b) 3D Figure 5.4. – Performances des copies Transposition XY Nous appelons transposition XY une transposition 2D dans le plan XY . Dans le cas de données 2D, cela revient à une transposition classique. Cette opération est bien connue et l’implémentation proposée ici se base sur l’exemple donné par Ruetsch et al. (2009) pour la transposition d’une matrice de taille 2 0482 en simple précision. Les auteurs présentent différentes optimisations permettant d’obtenir une bande passante pour la transposition égale à 70% de celle obtenue pour une copie. Nous étendons cette approche à différentes tailles de tableaux 2D et 3D en double précision. Pour les données 3D, une telle transposition est effectuée pour chaque plan dans la direction Z. La transposition optimale est schématisée en figure 5.5 et fait apparaître les trois niveaux d’optimisation que nous détaillons ci-après. Les données représentées en rouge et en vert sont traitées par les work-items d’un même work-group et une boucle permet de compléter les sous-tableaux en pointillés. Une transposition naïve, similaire au kernel de copie, réalisant une écriture directe dans le tableau de sortie conduit à de très mauvaises performances. En effet, une telle implémentation implique des accès en mémoire globale non contigus. Une solution consiste à utiliser un tableau intermédiaire en mémoire partagée permettant de réaliser des accès contigus à la fois en lecture et en écriture pour les tableaux en mémoire globale. Dans ce cas, l’écriture des données en colonnes dans le tableau de sortie revient à lire des lignes en mémoire locale. Cependant, cette approche provoque des conflits de banc lors de la lecture des données en ligne dans la mémoire partagée. Ce phénomène vient du fait que la mémoire partagée est organisée en différents bancs, dont le nombre est en général égal à 32. Ces bancs ne permettent qu’un accès séquentiel aux données et on assiste à un conflit lorsque plusieurs 955. Mise en œuvre sur cartes graphiques processus accèdent simultanément à des données situées dans le même banc, les accès sont alors effectués de manière séquentielle. Du fait du choix de la taille de cette zone mémoire, 162 ou 322 , les données d’une même ligne sont situées dans le même banc. En suivant l’exemple de Ruetsch et al. (2009), on alloue une zone de taille 17×16 ou 33×32 pour décaler les données dans les bancs et ainsi avoir des accès sans conflits. Une autre approche consiste à accéder aux données du tableau en mémoire partagée dans un système de coordonnées diagonale (Baqais et al., 2013). Si x et y sont respectivement les indices de ligne et de colonne du sous-tableau traité par un work-group, les données correspondantes sont stockées aux indices x 0 et y 0 avec : x 0 = (x + y)%T avec T la taille du sous-tableau, y 0 = x. Ainsi, les accès ne provoquent pas de conflits et la mémoire allouée est entièrement utilisée. Cependant, cette approche n’a pas été envisagée pour l’instant car la version avec extension du tableau conduit à des performances satisfaisantes. D’autre part, la réduction d’utilisation de mémoire partagée n’est pas suffisamment importante pour influencer l’occupation de manière significative. Enfin, comme la mémoire partagée, la mémoire globale est organisée en partitions si bien que le traitement simultanée d’une colonne de sous-tableaux conduit à la lecture de données dans différentes partitions et à une écriture dans les même partitions. Une structuration des sous-tableaux en coordonnées diagonales permet des accès non restreints à un petit nombre de partitions (flèches pointillées sur la figure). Cependant, nos expérimentations sur des cartes plus récentes que celles utilisées par Ruetsch et al. (2009) montrent que ce réarrangement en diagonale ne conduit pas à une augmentation significative des performances. Mémoire partagée Entrée Sortie Figure 5.5. – Fonctionnement du kernel de transposition XY La figure 5.6 présente les performances obtenues pour les trois niveaux d’optimisation de la transposition XY en 2D et 3D pour différentes tailles de tableaux ainsi qu’une implémentation naïve. La mise en place de ces niveaux d’optimisation conduit à une bande passante pour la transposition supérieure à 80% de la bande passante maximale mesurée pour la copie. 965.2. Implémentation et performances Naif Mémoire partagée Mémoire partagée élargie Mémoire partagée élargie, coord. diagonales 0 10 20 30 40 50 60 70 80 322 1282 5122 20482 81922 Max. 0 20 40 60 80 100 120 140 160 10−2 10−1 1 101 102 103 % bande passante théorique Bande passante (GBytes/s) Taille des tableaux (MByte) (a) 2D 0 10 20 30 40 50 60 70 80 323 643 1283 2563 5123 Max. 0 20 40 60 80 100 120 140 160 1 101 102 103 % bande passante théorique Bande passante (GBytes/s) Taille des tableaux (MByte) (b) 3D Figure 5.6. – Performances des transpositions XY Lorsque la taille du sous-tableau alloué en mémoire partagée est fixé à 33 × 32, soit 8448Byte, et que les work-groups contiennent 512 work-items, 12 registres sont utilisés ce qui conduit à une occupation maximale avec l’exécution simultanée de 4 work-groups par multiprocesseurs. Transposition XZ Cette transposition est réalisée de manière similaire à la transposition XY comme illustré en figure 5.7a. L’opération se réalise par le traitement de sous-tableaux 2D formés dans les plans XZ successifs. Chacun de ces plans est traité séparément par plusieurs soustableaux avec l’utilisation d’une mémoire partagée élargie et avec des coordonnées diagonales pour les différents blocs. Cependant, bien que les accès soient contigus dans une même colonne des sous-tableaux, le passage d’une colonne à une autre dans les tableaux 3D se fait avec un saut bien plus important que pour la transposition XY . Ce phénomène pénalise grandement les performances sur des cartes plus anciennes et une seconde transposition a été implémentée par sous-tableau 3D, illustré par la figure 5.7b. Le principe reste le même mais les données sont lues également dans la direction Y , avec un saut bien plus faible. Comparativement à la version 2D, cela revient à réaliser les transpositions simultanées de plusieurs plans XZ. Cependant, les dimensions de la zone en mémoire partagée imposent une taille plus faible pour les work-groups. Les performances de cette transposition sont représentées sur la figure 5.8. Il apparaît clairement que l’utilisation d’une transposition par bloc 3D n’est pas optimale du fait d’une trop faible occupation (16%) induite par une très grande taille de mémoire partagée par 975. Mise en œuvre sur cartes graphiques Mémoire partagée Entrée Sortie (a) Par tranches 2D Mémoire partagée Entrée Sortie (b) Par blocs 3D Figure 5.7. – Fonctionnement du kernel de transposition XZ work-groups, (163 éléments). La meilleure configuration pour cette transposition est obtenue pour une occupation de 63%. 5.2.4. Advection et remaillage Advection Cette fonction permet de résoudre l’équation de mouvement des particules à partir du champ de vitesse connu sur la grille. Les particules sont initialisées en chaque point de grille, leur vitesse en ce point est donc directement lue sur la grille. Les schémas de Runge-Kutta d’ordre deux et quatre, notés respectivement RK2 et RK4, nécessitent des évaluations du champ de vitesse à plusieurs positions intermédiaires qui sont réalisées par des interpolations linéaires de type maillage-particule. Une stratégie centrée sur les particules permet de réaliser ces interpolations à la volée au cours de l’advection. Ainsi, une particule est traitée en une seule fois mais nécessite plusieurs accès aux données du champ de vitesse. De plus le schéma d’accès est inconnu car il dépend du champ de vitesse. Toutefois, du fait de la condition de non croisement des particules, ces accès restent ordonnés de la même manière que les particules. La stratégie de distribution des calculs sur l’espace d’indices des GPU est choisie de telle sorte qu’un sous-problème 1D est traité par les work-items d’un seul work-group. Ces sous-problèmes étant indépendants, plusieurs pourront être traités simultanément en 985.2. Implémentation et performances 0 10 20 30 40 50 60 70 80 323 643 1283 2563 5123 Max. 0 20 40 60 80 100 120 140 160 10−2 10−1 1 101 102 103 % bande passante théorique Bande passante (GBytes/s) Taille des tableaux (MByte) 2D Naïf 2D Mémoire partagée 2D Optimisé 3D Naïf 3D Optimisé Figure 5.8. – Performances des transpositions XZ fonction de l’occupation des multiprocesseurs de la carte. Les multiples accès aux données du champ de vitesse peuvent être évités en utilisant une zone en mémoire partagée, comme illustré sur la figure 5.9. Cela permet, après un remplissage par accès contigus en mémoire globale, à des accès plus rapides et dont le schéma inconnu est moins pénalisant. Les workitems réalisent, dans une premier temps, un chargement en mémoire partagée des données du champ de vitesse nécessaires au traitement d’un problème 1D. Cette opération, qui s’apparente à une mise en cache, est réalisée de manière collaborative par les work-items et est nécessairement suivie d’une barrière de synchronisation des processus du work-group. Dans un second temps, l’intégration du champ de vitesse est réalisée à l’aide d’interpolations. Intégration Interpolations Vitesse (grille) Mémoire partagée Position (particules) Figure 5.9. – Algorithme pour le noyau d’advection Dans le cas où la grille est identique pour le champ de vitesse et pour les particules, les 3 ou 7 accès aux données de vitesse respectivement pour les schémas RK2 et RK4 nécessaires au calcul des positions des particules sont effectués en mémoire partagée et bénéficient ainsi de son temps de latence plus faible. La quantité de données lues et écrites en mémoire globale pour une étape d’advection est donc indépendante du schéma et est donnée par : MA,s = 2N uP, (5.1) 995. Mise en œuvre sur cartes graphiques où Nu est le nombre de points de grille du scalaire et P la taille d’un nombre en virgule flottante (P = 8 en double précision). On note Na le nombre de points de grille du champ de vitesse. Pour ce qui est du cas multiéchelle, deux interpolations supplémentaires sont nécessaires. Le cache pour le champ de vitesse, de Na X éléments, est complété par une première interpolation linéaire tensorielle des points de grille dans les directions Y et Z en la coordonnée du sous-problème 1D. Ainsi, les données du champ de vitesse sont lues plusieurs fois, et conduisent à une quantité totale exprimée par : MA,m = ( (2N a + N u )P pour un problème 2D, (4N a + N u )P pour un problème 3D. (5.2) La seconde interpolation se fait dans la mémoire partagée pour l’évaluation de la vitesse initiale des particules dont la position est un point de la grille fine. Le calcul d’un problème 1D étant effectué par un work-group, plusieurs particules peuvent être traitées par le même work-item. Ainsi les opérations effectuées en dehors de la boucle interne sont mutualisées pour ces particules. On note nwi le nombre de work-item par work-group. Les nombres d’opérations nécessaires à la réalisation d’une étape d’advection simple échelle sont données par : FA,s =    4N u pour un schéma d’Euler 12N u pour un schéma de Runge-Kutta d’ordre 2 32N u pour un schéma de Runge-Kutta d’ordre 4 (5.3) Pour les cas multiéchelle, le nombre d’opérations est : FA,m = FA,s + ( (4nwi + 3N a X)N u /Nu X en 2D (8nwi + 11N a X)N u /Nu X en 3D (5.4) Le choix de l’espace d’index se fait en fixant le nombre de particules traitées par un workitem. Les figures 5.10 représentent les performances pour 1, 2 ou 4 particules respectivement notées v1, v2 et v4 dans la légende. Dans un souci de clarté, nous ne présentons pas ici les autres choix qui ont été envisagés d’autant qu’ils ont conduit à des performances plus faibles. L’augmentation de la complexité arithmétique due à l’augmentation de l’ordre des schémas se traduit directement par une hausse de la puissance obtenue. Cela sera analysé par la suite à l’aide du modèle roofline. Une différence structurelle entre les problèmes 2D et 3D est que la résolution est constituée de sous-problèmes 1D bien plus petits en 3D. Ainsi, l’usage de la mémoire partagée est plus faible en 3D qu’en 2D et implique donc une plus grande occupation de la carte pour les grands problèmes. Un traitement de plusieurs particules par work-item permet de diminuer la taille des work-groups ce qui, là encore permet une augmentation de l’occupation. Cependant la limite des 1 024 work-items est rapidement atteinte en 2D. Ce qui explique la chute de performances à partir de 1 0242 . L’effet inverse se produit en 3D où trop peu de work-items sont assignés ce qui conduit à une faible occupation en raison de la limite du nombre de work-group exécutables simultanément par multiprocesseur. Pour ce qui est de l’advection multiéchelle, nous donnons les performances atteintes pour différentes tailles de problèmes sur les figures 5.11. Seules les performances de la version 1005.2. Implémentation et performances Euler v4 Euler v2 Euler v1 RK2 v4 RK2 v2 RK2 v1 RK4 v4 RK4 v2 RK4 v1 0 50 100 150 200 250 300 322 1282 5122 20482 Puissance (GFLOPS) Taille de problème (a) 2D 0 50 100 150 200 250 300 323 643 1283 2563 5123 Puissance (GFLOPS) Taille de problème (b) 3D Figure 5.10. – Performances des noyaux d’advection 1015. Mise en œuvre sur cartes graphiques pour laquelle chaque work-item traite 4 particules sont présentées. Les rapports d’échelle entre les grilles des particules et celle du champ de vitesse sont fixés à 2, 4 et 8 et conduisent aux courbes dans l’ordre indiqué par les flèches. Ces résultats montrent que les performances suivent l’évolution du rapport d’échelle, à taille de grille fine fixée. Cette évolution est, en partie, due au fait que l’augmentation du rapport d’échelle implique une diminution à la fois du nombre de données nécessaires pour le calcul, d’après l’équation (5.2), et du nombre d’opérations arithmétique à réaliser, équation (5.4). 0 50 100 150 200 250 300 1282 5122 20482 Puissance (GFLOPS) Taille de problème (grille fine) RK2 RK4 Euler (a) 2D 0 50 100 150 200 250 300 643 1283 2563 5123 Puissance (GFLOPS) Taille de problème (grille fine) RK2 RK4 Euler (b) 3D Figure 5.11. – Performances des noyaux d’advection multiéchelle Le modèle roofline nous permet de réaliser une analyse de performances relativement à la puissance maximale atteignable. Nous représentons sur les figures 5.12 les résultats pour quelques tailles de problèmes. En simple échelle, l’intensité opérationnelle FA,s/MA,s est constante lorsque la taille du problème change. Ces intensités sont représentées par un trait vertical sur les figures 5.12. Dans le cas multiéchelle, les intensités ne sont plus constantes et donc les points qui leur correspondent ne sont pas sur les segments verticaux. Afin de remédier aux effets visuels des échelles logarithmiques du modèle roofline, nous représentons également les niveaux 0,5 et 0,1 de la puissance maximale atteignable. Remaillage Cette étape permet de réaliser l’interpolation particule-maillage en employant une stratégie centrée sur les particules. À partir de la coordonnée d’une particule, les points de la grille sur lesquels se remaille la particule sont calculés en fonction de la largeur du support de la formule utilisée. Les positions sont dépendantes du champ de vitesse donc le schéma de remaillage en termes d’accès aux données de la grille ne peut pas être connu à priori. 1025.2. Implémentation et performances Euler RK2 RK4 10 100 1000 0.1 1 10 100 Euler RK2 RK4 50% 10% Puissance (GFLOPS) Intensité opérationnelle (FLOP/Byte) 10242 20482 40962 (a) 2D 10 100 1000 0.1 1 10 100 Euler RK2 RK4 50% 10% Puissance (GFLOPS) Intensité opérationnelle (FLOP/Byte) 1283 2563 5123 (b) 3D Figure 5.12. – Modèle roofline pour les noyaux d’advection Par conséquent, deux particules consécutives peuvent avoir exactement les mêmes points de remaillage. Cependant, du fait de la régularité des champs de vitesse traités, nous pouvons poser l’hypothèse que le nombre maximal de particules par cellule reste petit. On supposera que ce nombre ne dépasse pas deux. La distribution de l’espace d’index est similaire à celle de l’advection et chaque sousproblème 1D est traité par un work-group. La charge par work-item est modifiée pour remédier aux éventuels accès concurrents lorsque plusieurs particules sont situées dans la même cellule. Ainsi, chaque work-item traite au moins deux particules consécutives. En conservant les mêmes notations que dans le chapitre 2, le support des formules de remaillage est de largeur 2S. Par conséquent, le remaillage d’une particule nécessite 2S accès en lecture et autant en écriture pour les points de grille contenus dans son support. Ces nombreux accès sont effectués dans un tableau temporaire correspondant au sous-problème 1D en mémoire partagée, comme illustré sur la figure 5.13. Une fois toutes les particules traitées et après une barrière de synchronisation, les données sont copiées en mémoire globale. Scalaire (particules) Position (particules) Scalaire (grille) Mémoire partagée Λp,r Figure 5.13. – Algorithme pour le noyau de remaillage 1035. Mise en œuvre sur cartes graphiques Le nombre d’accès en mémoire globale est donné par l’expression suivante, en fonction du nombre de composantes remaillées c : MR = (2c + 1)N uP. (5.5) Pour ce qui est du nombre d’opérations en virgule flottante, il dépend de la largeur du support 2S, de la formule de remaillage et du degré q des polynômes dont l’évaluation est effectuée par la méthode de Horner en utilisant les opérations FMA de la carte. FR = (2S(2c + 2q + 1) + 5) N u (5.6) Nous donnons les performances des noyaux pour quelques formules de remaillage. Les meilleurs résultats ont été obtenus lorsque chaque work-item traite exactement deux particules. Une augmentation du nombre de particules par work-item implique une occupation plus faible car la quantité de mémoire employée ne change pas et la taille des work-groups diminue. Un nombre plus grand implique une utilisation d’un grand nombre de registres et donc une diminution de l’occupation des multiprocesseurs. Comme pour les noyaux d’advection on assiste à une chute des performances en 2D à partir d’une taille de 4 0962 à cause d’une trop grande consommation de mémoire partagée. 0 50 100 150 200 250 300 350 322 1282 5122 20482 Puissance (GFLOPS) Taille de problème Λ2,1 Λ2,2 Λ4,2 Λ4,4 Λ6,4 Λ6,6 Λ8,4 (a) 2D 0 50 100 150 200 250 300 350 323 643 1283 2563 5123 Puissance (GFLOPS) Taille de problème Λ2,1 Λ2,2 Λ4,2 Λ4,4 Λ6,4 Λ6,6 Λ8,4 (b) 3D Figure 5.14. – Performances des noyaux de remaillage Les performances relatives à la puissance maximale atteignable sont représentées dans un modèle roofline sur les figures 5.15. À l’instar de Büyükkeçeci et al. (2012), nous observons de plus hautes performances en 3D qu’en 2D essentiellement à cause d’une utilisation du tableau en mémoire partagée plus efficace du fait de la différence des tailles des sousproblèmes 1D. 1045.2. Implémentation et performances Λ2,1 Λ2,2 Λ4,2 Λ4,4 Λ6,4 Λ6,6 Λ8,4 10 100 1000 0.1 1 10 100 50% 10% Puissance (GFLOPS) Intensité opérationnelle (FLOP/Byte) 10242 20482 40962 (a) 2D 10 100 1000 0.1 1 10 100 50% 10% Puissance (GFLOPS) Intensité opérationnelle (FLOP/Byte) 1283 2563 5123 (b) 3D Figure 5.15. – Modèle roofline pour les noyaux de remaillage Noyau complet Une approche regroupant les opérations d’advection et de remaillage en un seul noyau est également envisagée. Le principal intérêt est de supprimer le tableau en mémoire globale pour la position des particules. En effet, cette variable intermédiaire est simplement locale au processus. Cependant, cette approche nécessite deux tableaux temporaires en mémoire partagée, comme illustré sur la figure 5.16. En pratique, cette implémentation n’est pas Intégration Interpolation Vitesse (grille) Scalaire (particules) Scalaire (grille) Mémoire partagée Mémoire partagée Λp,r Figure 5.16. – Algorithme pour le noyau d’advection et remaillage pertinente pour les grandes tailles de problèmes 2D. Cependant, comme la mémoire partagée n’est pas un facteur limitant en 3D, son utilisation semble intéressante. Dans ce noyau, nous réutilisons les fonctions employées précédemment, ce qui conduit à une quantité d’accès 1055. Mise en œuvre sur cartes graphiques mémoire en simple et multiéchelle : MAR,s = MR,s = (1 + 2c)N uP, (5.7) MAR,m = ( (2N a + 2cNu )P en 2D (4N a + 2cNu )P en 3D. (5.8) Pour ce qui est du nombre d’opérations, il est simplement donné par la somme des opérations des noyaux d’advection et de remaillage. Les performances obtenues sont représentées en figures 5.17 et dans un modèle roofline en figures 5.18. Nous considérons le cas d’une advection par un schéma Runge-Kutta d’ordre 2 ainsi que l’utilisation des formules de remaillage Λ2,1, Λ4,2 et Λ8,4. L’évolution des performances selon la formule de remaillage utilisée est identique à celle observée pour le noyau de remaillage seul. De même, les performances pour une advection avec un schéma d’Euler et Runge-Kutta d’ordre 4 sont respectivement inférieures et supérieures à celles représentées lorsque la formule de remaillage est fixée. Les courbes notées MS dans la légende correspondent à une advection multiéchelle pour un facteur d’échelle égal à 4. Comparativement au cas simple échelle, cela induit une petite augmentation de performances ainsi qu’une augmentation de l’intensité opérationnelle du noyau qui est renforcée par l’effet de la complexité de la formule de remaillage. Cependant, une comparaison des performances relatives des modèles roofline avec les noyaux simples montrent que cette approche n’apporte pas une meilleure efficacité. Toutefois, comme nous le verrons par la suite, l’utilisation de ce noyau conduit à un temps de calcul légèrement inférieur à la somme des deux noyaux simples ce qui permet de bénéficier de la réduction de l’empreinte en mémoire globale. 0 50 100 150 200 250 300 350 322 1282 5122 20482 Puissance (GFLOPS) Taille de problème Λ2,1 Λ4,2 Λ8,4 MS Λ2,1 MS Λ4,2 MS Λ8,4 (a) 2D 0 50 100 150 200 250 300 350 323 643 1283 2563 5123 Puissance (GFLOPS) Taille de problème Λ2,1 Λ4,2 Λ8,4 MS Λ2,1 MS Λ4,2 MS Λ8,4 (b) 3D Figure 5.17. – Performances des noyaux d’advection et remaillage pour un schéma RK2 1065.3. Application simple GPU Λ2,1 Λ4,2 Λ8,4 MS Λ2,1 MS Λ4,2 MS Λ8,4 10 100 1000 0.1 1 10 100 50% 10% Puissance (GFLOPS) Intensité opérationnelle (FLOP/Byte) 10242 20482 40962 (a) 2D 10 100 1000 0.1 1 10 100 50% 10% Puissance (GFLOPS) Intensité opérationnelle (FLOP/Byte) 1283 2563 5123 (b) 3D Figure 5.18. – Modèle roofline pour les noyaux d’advection et remaillage pour un schéma RK2 Les performances individuelles des différents noyaux se retrouvent directement dans les exécutions du code complet. Ainsi, nous exposons la validité de la méthode et de l’implé- mentation à travers quelques exemples simples de transport de scalaire. Dans un premier exemple, la vitesse est donnée par une fonction analytique dépendant de l’espace et du temps alors qu’elle ne dépend pas du temps dans le second exemple. Le cas multiéchelle est illustré sur l’exemple 3D. Les résultats des exemples sont analysés de manière qualitative permettant une validation de la méthode. Les résultats en terme de temps de calcul sont présentés et comparés entre les différentes fonctions. Dans tous les cas, la vitesse est donnée en entrée sous la forme des valeurs aux points de grille, permettant ainsi de se placer dans un cadre général indépendant de la manière dont est calculé le champ de vitesse. 5.3. Application simple GPU 5.3.1. Transport de scalaire 2D Un premier exemple d’utilisation de la méthode compète sur GPU est réalisé pour le transport d’une fonction levelset dans un champ de vitesse analytique 2D. Ce champ correspond à un mouvement de rotation incompressible périodique en temps. Ainsi, la fonction levelset est déformée au cours du temps puis retrouve sa valeur initiale après un nombre entier de périodes. Le champ de vitesse est défini par l’expression suivante : a(x, y, t) =  − sin2 (πx) sin(2πy) sin(2πx) sin2 (πy)  cos  πt 12 (5.9) 1075. Mise en œuvre sur cartes graphiques Le scalaire est initialisé par une fonction indicatrice d’un disque de rayon 0,15 centré au point de coordonnée (0, 5; 0, 75). À chaque itération de la méthode, le champ de vitesse analytique est évalué sur les points de grille puis la méthode décrite précédemment s’applique avec une étape d’advection suivie d’un remaillage des particules. Le contour de niveau 0,5 de la fonction transportée est représenté à différents instants sur la figure 5.19. À l’instant t = 12, soit après une période, le contour a retrouvé sa forme initiale. La difficulté de cet exemple réside en la représentation du contour à l’extrémité de la spirale. En effet, selon la qualité de la méthode employée, la séparation du contour ainsi que l’apparition d’éventuelles oscillations numériques ne permettent plus de retrouver la condition initiale. Nous rappelons que le pas de temps est contraint par la condition de CFL Lagrangienne suivante : ∆t 6 M |∇a|∞ . La simulation suivante a été réalisée en utilisant 1 0242 points de grille. La constante M est prise égale à 0,35, ce qui pour cette résolution, conduit à une CFL équivalente de |a|∞∆t/∆x = 57. Ainsi, une première validation de l’implémentation est effectuée car à l’instant t = 12, on retrouve bien la condition initiale en utilisant de grands pas de temps, comme le montre la figure 5.19. La simulation est réalisée en utilisant un schéma d’intégration RK2 et une formule de remaillage Λ6,4. Les temps de calcul par particule, hors initialisation et hors calcul du champ de vitesse, sont donnés en figure 5.20 pour différentes formules de remaillage et schémas d’advection. Comme prévu par les performances individuelles des noyaux, les petites résolutions conduisent à des temps de calcul assez grands. Nous les considérons comme non signifi- catives car elles ne sont jamais utilisées en pratique dans les applications. Un temps de traitement compris entre 1,5 et 3 ns est obtenu pour un remaillage avec la formule Λ2,1 et augmente avec l’ordre et la complexité de la formule pour atteindre des valeurs entre 2 et 4 ns pour Λ8,4. Les autres formules conduisent à des temps intermédiaires. Cette figure propose également une comparaison de la version à un seul noyau de calcul avec celle à deux noyaux séparés. Cette dernière conduit à des temps de calculs plus élevés mais permet de traiter des problèmes de plus grande taille. Cela est dû, à l’utilisation d’une plus grande zone de mémoire partagée pour la version à un noyau. Enfin, la hausse des temps de calcul lorsque les problèmes traités sont de taille supérieure à 2 0482 est conforme avec la chute de puissance observée dans la section précédente. Là encore, l’utilisation de la mémoire partagée est à l’origine de cette évolution notamment à travers une baisse de l’occupation des multiprocesseurs dans les étapes de calcul. La figure 5.21 donne la répartition du temps de calcul dans les différentes fonctions présentées dans la section précédente. Les couleurs claires correspondent à l’étape de splitting dans la direction X et occupent 2/3 du temps de calcul alors que les teintes foncées représentent la direction Y et occupent le 1/3 restant. Ces simulations ont été réalisées avec un splitting de Strang où deux étapes sont nécessaires dans la direction X. Les portions du temps de calcul attribuées à l’hôte deviennent négligeables lorsque la taille dépasse 4 0962 . Elles correspondent à des opérations réalisées par le CPU pour la gestion des étapes de splitting et des lancements de kernels OpenCL. Les opérations d’initialisation à l’aide de copies et de transpositions n’occupent que 10 à 20% du temps de calcul. 1085.3. Application simple GPU t = 0 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 t = 3 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 t = 6 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 t = 12 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 Figure 5.19. – Exemple de transport de fonction levelset 2D 1095. Mise en œuvre sur cartes graphiques 2 4 8 1 10 1282 10242 20482 40962 61442 Temps de calcul par particule (ns) Taille des tableaux 1k : RK2, Λ2,1 2k : RK2, Λ2,1 1k : RK4, Λ2,1 2k : RK4, Λ2,1 1k : RK2, Λ8,4 2k : RK2, Λ8,4 1k : RK4, Λ8,4 2k : RK4, Λ8,4 Figure 5.20. – Performances globales de la méthode pour un transport de scalaire 2D Copie Transposition XY Hôte Advection Remaillage Advection et remaillage 0 10 20 30 40 50 60 70 80 90 100 1024 2 2048 2 4096 2 6144 2 1024 2 2048 2 1024 2 2048 2 4096 2 6144 2 1024 2 2048 2 1024 2 2048 2 4096 2 6144 2 1024 2 2048 2 1024 2 2048 2 4096 2 6144 2 1024 2 2048 2 RK2, Λ2,1 RK4, Λ2,1 RK2, Λ8,4 RK4, Λ8,4 X Y % du temps de calcul Taille des problèmes Figure 5.21. – Répartition du temps de calcul des différentes fonctions pour un transport de scalaire 2D 1105.3. Application simple GPU 5.3.2. Transport de scalaire 3D Une application similaire est réalisée en 3D. Le scalaire est initialisé comme la fonction caractéristique d’une sphère de centre (0, 35; 0, 35; 0, 35) et de rayon 0,15. Le champ de vitesse, correspondant à une rotation incompressible, est défini par : a(x, y, z, t) =   2 sin2 (πx) sin(2πy) sin(2πz) − sin(2πx) sin2 (πy) sin(2πz) − sin(2πx) sin(2πy) sin2 (πz)   (5.10) Nous nous intéressons ici à l’évolution de la surface de niveau 0,5 au cours du temps qui est soumise à une déformation de plus en plus forte. Nous comparons les effets des différentes formules de remaillage à travers l’évolution du volume représenté par cette surface. La figure 5.22 représente la surface de niveau 0,5 à l’instant t = 4, pour deux formules de remaillage différentes. L’utilisation d’une formule d’ordre plus élevé, sur la figure 5.22b, retarde l’apparition de « trous » ainsi que leur disparition comparativement à l’utilisation de la formule Λ2,1, sur la figure 5.22a. (a) Remaillage par Λ2,1 (b) Remaillage par Λ8,4 Figure 5.22. – Exemple de transport de fonction levelset en 3D L’évolution du volume délimité par la surface de niveau 0,5 est donnée en fonction du temps pour quelques noyaux de remaillage sur la figure 5.23. Ainsi, les formules d’ordre élevé préservent mieux le volume ce qui est conforme à l’observation des figures 5.22. Ces simulations ont été réalisées pour une constante LCFL égale à 0,35 et pour une résolution de 3203 . Cela équivaut à une CFL de 17,8. Les temps de calcul pour cette simulation sont donnés sur les figures 5.24 en fonction de la taille du problème pour différentes formules de remaillage dans les cas simple échelle et multiéchelle. Les temps de calculs sont indépendants de la taille du problème et sont de l’ordre de 1 à 2 ns, excepté pour les petites tailles non significatives. Comme pour le cas 2D, seules les formules de remaillage Λ2,1 et Λ8,4 sont représentées, les autres se répartissent sur des temps de calculs intermédiaires. Là encore, la version avec un seul noyau de calcul pour l’advection et le remaillage donne de meilleurs temps de calcul. Contrairement au 1115. Mise en œuvre sur cartes graphiques 0.0105 0.011 0.0115 0.012 0.0125 0.013 0.0135 0.014 0.0145 0 0.5 1 1.5 2 2.5 3 3.5 4 75 80 85 90 95 100 Volume % du volume initial Temps Volume initial Λ2,1 Λ4,2 Λ6,4 Λ8,4 Figure 5.23. – Évolution du volume défini par le niveau 0,5 d’une fonction levelset cas 2D, cette version permet de traiter des résolutions plus grandes car l’empreinte en mémoire globale est plus faible et la mémoire partagée n’est pas limitante. Ainsi la résolution maximale en simple échelle est de 4483 mais il est possible de traiter une résolution de 5123 pour le scalaire lorsque la résolution de la vitesse est inférieure à 3843 . Copie Transposition XY Transposition XZ Hôte Advection Remaillage Advection et remaillage 0 10 20 30 40 50 60 70 80 90 100 128 3 256 3 128 3 256 3 128 3 256 3 128 3 256 3 Λ2,1 Λ8,4 % du temps de calcul Taille des problèmes (a) Simple échelle 0 10 20 30 40 50 60 70 80 90 100 128 3 256 3 512 3 128 3 256 3 512 3 128 3 256 3 512 3 128 3 256 3 512 3 Λ2,1 Λ8,4 % du temps de calcul Taille des problèmes (b) Multiéchelle (Nu = 43Na) Figure 5.25. – Temps de calcul des différentes fonctions pour un transport de scalaire 3D 1125.3. Application simple GPU 1k : RK2, Λ2,1 2k : RK2, Λ2,1 1k : RK4, Λ2,1 2k : RK4, Λ2,1 1k : RK2, Λ8,4 2k : RK2, Λ8,4 1k : RK4, Λ8,4 2k : RK4, Λ8,4 2 4 8 1 10 643 1283 2563 3843 5123 Temps de calcul par particule (ns) Taille des tableaux (a) Simple échelle 2 4 8 1 10 643 1283 2563 3843 5123 Temps de calcul par particule (ns) Taille des tableaux (b) Multiéchelle (Nu = 43Na) Figure 5.24. – Performances globales de la méthode pour un transport de scalaire 3D Comme pour le cas 2D, nous donnons, sur la figure 5.25, les répartitions du temps de calcul à travers les différentes fonctions de la méthode. Les contributions issues des différentes directions de splitting sont différenciées par les nuances de couleurs. Comme pour le cas 2D, les directions X, Y et Z se partagent le temps de calcul total et en occupent respectivement les 2/5, 2/5 et 1/5. Les deux premières sont traitées deux fois sur des demi pas de temps. Les opérations d’initialisation occupent entre 15 et 30% du temps de calcul. Conclusion Dans ce chapitre, nous avons présenté une implémentation spécifique aux architectures multicœurs telle que les cartes graphiques de la méthode semi-Lagrangienne. La straté- gie d’implémentation a été élaborée en se basant sur les études similaires existantes. Les différentes fonctions de la méthode ont été étudiées à travers leurs performances respectivement à des optimisations génériques basées sur les caractéristiques techniques des cartes graphiques. Ces optimisation peuvent également conduire à de bonnes performances sur d’autres cartes que celle présentée ici. Les performances individuelles des noyaux d’initialisation, comme fonctions de manipulation de données, atteignent jusqu’à 73% de la bande passante maximale pour la copie. Les transpositions permettent d’obtenir une bande passante respectivement de 64%, 71% et 63% pour la transposition XY en 2D et 3D et pour la transposition XZ. Ces performances sont assez satisfaisantes en comparaison avec celles obtenues pour la copie. En effet, les bandes passantes atteintes pour les transpositions sont supérieures à 86% de celle de la meilleure 1135. Mise en œuvre sur cartes graphiques copie. Comme pour les noyaux d’initialisation, les performances des noyaux de calcul sont fortement dépendantes des tailles de tableaux traitées. Pour les tailles les plus adaptées, les puissances de calcul développées par les noyaux d’advection dans le modèle roofline sont supérieures 50% de la puissance maximale atteignable et légèrement inférieures dans les cas multiéchelle. L’augmentation de l’ordre des formules de remaillage implique une augmentation de puissance de calcul des kernels de remaillage pour obtenir des performances proches de 50% de la puissance maximale. Pour ce qui est des noyaux réalisant les opérations d’advection et de remaillage en une seule passe, les performances se situent au voisinage de 20% de la puissance maximale. Toutefois, ces noyaux montrent un temps de calcul global géné- ralement meilleur que lorsque deux noyaux séparés sont employés. La quantité de mémoire partagée requise par ce noyau interdit son usage pour les grandes tailles en 2D. Au contraire, en 3D, ce noyau permet de traiter de plus grandes résolutions du fait de l’utilisation d’une plus faible quantité de mémoire globale. Par conséquent, il est préférable d’utiliser la version en deux noyaux pour les simulations 2D du fait de la limitation en mémoire partagée. De même, le noyau complet est mieux adapté aux problèmes 3D car il permet de diminuer l’empreinte en mémoire globale. Enfin, les deux exemples de transport de fonction levelset proposent une validation qualitative de la méthode. Bien que ces résultats soient obtenus sur une machine de calcul, des expériences conduisant à l’obtention de performances similaires sont menées sur des machines de bureau ou portables, montrant ainsi la portabilité de notre implémentation. Toutefois, nous ne présentons pas ces résultats dans ce manuscrit par souci de simplification car ces machines sont dotées de cartes d’anciennes générations n’offrant pas les même facilités de développement. De plus les cartes sont utilisées par les systèmes d’exploitation pour l’affichage à l’écran. Sur ces configurations, le calcul est en concurrence avec l’affichage pour l’utilisation des ressources, ce qui donne lieu à des variations de performances non reproductibles et pouvant être importantes. 1146. Implémentation sur architectures hétérogènes Nous avons vu dans le chapitre 5 que la méthode semi-Lagrangienne, telle que présentée au chapitre 2 avec splitting dimensionnel et formules de remaillage d’ordre élevé, est bien adaptée pour tirer profit de l’architecture des cartes graphiques. En effet, l’analyse des performances dans un modèle roofline montre des puissances de calcul généralement supérieures à 50% de la puissance maximale atteignable. Les temps de calculs ainsi obtenus sont assez faibles et incitent à passer à l’échelle avec une exécution parallèle sur plusieurs cartes graphiques. L’objectif de ce chapitre est de réaliser des simulations de transport de scalaire passif dans un écoulement turbulent tel que décrit dans le chapitre 1. La stratégie de résolution, exposée dans le chapitre 3, vise à exploiter les différentes ressources des machines de calcul hétérogène en réalisant le calcul du fluide sur des architectures multi-CPU et le transport du scalaire sur plusieurs GPU. La conception de la librairie, détaillée au chapitre 4, facilite l’intégration des méthodes de résolution des autres éléments des équations du problème complet de transport de scalaire passif dans un écoulement turbulent tels que les termes de d’étirement, de diffusion et l’équation de poisson. Dans un premier temps, nous détaillerons l’architecture hétérogène considérée ainsi que les différentes stratégies de parallélisme usuelles. Notre approche se base sur l’exploitation de toutes les ressources de calcul disponibles en maximisant leur occupation. Cela se traduit par l’emploi combiné de parallélismes à mémoire distribuée et partagée. Dans un second temps, nous détaillerons l’adaptation de la méthode à la résolution d’un problème de transport de scalaire sur une architecture multi-GPU. L’accent sera mis sur l’analyse des performances des communications entre les cartes à travers l’illustration sur l’exemple de transport de fonction levelset 3D du chapitre 5. Enfin, nous présenterons la méthode de résolution pour l’application au transport turbulent de scalaire passif à travers un exemple d’application à la simulation d’un jet plan turbulent. 1156. Implémentation sur architectures hétérogènes 6.1. Lien entre la méthode et l’architecture hybride 6.1.1. Description d’une machine hybride Comme nous l’avons évoqué dans le chapitre 1, les machines de calcul parallèles actuelles sont caractérisées par des architectures hétérogènes regroupant de nombreux processeurs multicœurs et accélérateurs. Généralement, elles présentent une organisation hiérarchique de leurs composants. Une machine de calcul est constituée d’un ensemble de nœuds connectés par un réseau local à très haut débit permettant des vitesses de transfert de plusieurs dizaines de GByte/s. Un nœud de calcul possède les mêmes caractéristiques qu’un ordinateur personnel utilisé comme serveur. Ainsi, il est constitué, au minimum, d’un processeur, de mémoire vive et d’un espace disque. Ces ressources sont gérées par un système d’exploitation qui lui est propre. Les composants présents sur un nœud varient d’une machine à l’autre et éventuellement d’un type de nœud à l’autre sur une même machine. De manière générale, ils contiennent plusieurs processeurs multicœurs et éventuellement des accélérateurs tels que les cartes graphiques ou des coprocesseurs. Un exemple d’une telle architecture est donnée en figure 6.1 où les nœuds sont connectés à travers le même réseau et certains contiennent des accélérateurs. Cœur CPU CPU multicœur Mémoire vive Accélérateur Réseau local Nœud Figure 6.1. – Exemple d’architecture hybride Dans la suite de ce chapitre, nous utilisons la machine de calcul Froggy du mésocentre CIMENT 1 qui possède notamment sept nœuds contenant chacun deux processeurs octocœurs Intel Sandy Bridge EP E5-2670 partageant 32 GByte de mémoire vive et deux cartes graphiques Nvidia K20m. 1. http://ciment.ujf-grenoble.fr 1166.1. Lien entre la méthode et l’architecture hybride 6.1.2. Différents niveaux de parallélisme Parmi les paradigmes de programmation parallèle usuels, le parallélisme de données et le parallélisme par tâches se distinguent par l’organisation des calculs par rapport aux données à traiter (Dongarra et al., 2003). Dans le premier, on réalise l’exécution simultanée de tâches identiques sur des données différentes. En revanche, le second consiste en l’exécution simultanée de tâches différentes sur des données identiques ou non. Ces deux approches sont couramment employées pour l’exploitation de machines de calcul parallèles hétérogènes, à travers l’utilisation des librairies telles que MPI et OpenMP. Différentes techniques sont à considérer pour la mise en œuvre de ces paradigmes selon la nature de la mémoire, partagée ou distribuée. La littérature étant abondante sur le sujet, dans cette section nous ne donnerons que quelques éléments concernant l’implémentation de ces paradigmes. Au sein d’un nœud, la mémoire est partagée par l’ensemble des cœurs des processeurs. Dans ce contexte, les taches sont distribuées sur l’ensemble des cœurs physiques à l’aide d’une librairie telle que OpenMP. Ce paradigme permet l’exploitation, au maximum, de l’ensemble des cœurs CPU d’un seul nœud car les données manipulées doivent être référencées dans le même espace d’adressage En complément de cette stratégie se trouve le parallélisme par envoi de message tel que proposé par le standard MPI. Il permet de réaliser des communications d’un processus à un autre dans un contexte de mémoire distribuée. Dans le cas général, il n’est pas possible à un processus de lire ou d’écrire dans une zone mémoire attribuée à un autre processus. Le principe de ce paradigme est que les données à transmettre sont empaquetées dans un message qui est envoyé au processus destinataire à travers le réseau de la machine. Une gestion fine de l’envoi et de la réception de ces messages est nécessaire afin que les données soient correctement traitées, éventuellement par l’utilisation de zones mémoires temporaires. Une très grande précision des communications est possible à travers l’utilisation des nombreuses variantes proposées par la librairie telles que, entre autres, les communications point à point ou globales ainsi que leurs versions bloquantes ou non. Ce paradigme s’utilise dans un environnement à mémoire distribuée mais fonctionne également avec une mémoire partagée. Une implémentation hybride associe plusieurs stratégies de parallélisme pour exploiter au mieux une architecture donnée. Ainsi, sans tenir compte des accélérateurs dans un premier temps, les utilisations courantes suivent deux stratégies distinctes pour l’exploitation de l’ensemble des cœurs CPU d’une machine. L’intégration d’une librairie d’envoi de message permet une utilisation d’un ensemble de processeurs multicœurs de plusieurs nœuds d’une machine. Ce fonctionnement se base sur fait que les librairies d’envoi de message, comme MPI, sont utilisables dans un contexte mixte de mémoire partagée et distante. Cependant, l’intégration d’un tel parallélisme implique généralement d’importants changements dans le code. Une réécriture de certaines parties est nécessaire lorsque l’utilisation de ce paradigme n’a pas été prévue à la conception. La seconde stratégie consiste combiner des paradigmes spécifiques à un environnement à mémoire partagée et à mémoire distribuée. Une approche basée sur les librairies MPI et OpenMP est couramment utilisée. Ces deux stratégies que l’on notera respectivement MPI et MPI+OpenMP permettent d’utiliser l’ensemble des cœurs CPU d’une machine de calcul. La principale différence est que la mé- moire partagée par les processus d’un même nœud est gérée par un parallélisme spécifique dans le cas MPI+OpenMP, ce qui permet une plus grande finesse d’optimisation et donc 1176. Implémentation sur architectures hétérogènes potentiellement l’obtention de meilleures performances. En revanche, le développement et le débogage sont généralement plus complexes. L’ensemble des processus déployés sur les cœurs physiques des nœuds peuvent ne pas réaliser des opérations similaires sur des données différentes. Un paradigme de parallélisme par tâches permet d’affecter des ensembles de processus à différentes tâches. Dans ce cas, au sein d’un même groupe, une tâche est traitée de manière collaborative. En revanche, deux processus associés à deux tâches distinctes sont amenés à exécuter des instructions totalement différentes. Toutefois, des communications sont généralement nécessaires pour échanger des données entre les processus des différentes tâches lorsqu’elles ne sont pas totalement indépendantes. L’exploitation des cartes graphiques comme accélérateurs se réalise de manière identique au cas d’une utilisation exclusive de l’accélérateur, comme présentée au chapitre 5. Un processus peut exploiter un accélérateur à l’aide des différentes techniques telles que CUDA ou OpenCL. Les cartes graphiques récentes sont capables de gérer l’exécution d’un ensemble de tâches provenant de plusieurs processus. Par conséquent, tous les processus placés sur un même nœud peuvent exploiter une même carte graphique. De même, dans le cas où plusieurs cartes sont présentes, un même processus peut utiliser simultanément l’ensemble des cartes graphiques. Ainsi, les machines hybrides doivent être exploitées en utilisant à la fois un parallélisme à mémoire distribuée, à mémoire partagée ainsi que des accélérateurs. On complète les notations précédentes par MPI+OpenCL ou MPI+OpenMP+OpenCL si OpenCL est utilisé sur les accélérateurs. 6.1.3. Stratégie d’utilisation La stratégie que nous employons dans ce travail se limite à une exploitation des processeurs multicœurs à l’aide du seul niveau de parallélisme par envoi de message. Cette approche, complétée par l’utilisation de la librairie OpenCL, nous permet de traiter à la fois les cas multi-GPU et hétérogènes. En effet, pour une exploitation de plusieurs cartes graphiques, il est nécessaire de placer un processus par nœud pour exploiter l’ensemble des cartes du nœud. Ces différents processus, se situent nécessairement dans un environnement à mémoire distribuée, d’où le choix de l’utilisation de MPI pour la gestion du parallélisme des processus hôtes. En pratique, dans notre implémentation, chaque GPU n’est géré que par un et un seul processus hôte. En effet, des études préliminaires ont montré une dégradation des performances lorsque plusieurs processus exploitent la même carte graphique de manière concurrente comparativement au cas où une carte est associée à un processus. Ce phénomène est en partie dû au fait que notre implémentation est plus efficace pour traiter de grandes tâches comparativement au traitement de plusieurs tâches plus petites. D’autre part, il nous semble plus avantageux de ne pas exploiter plusieurs cartes à partir du même processus hôte car le découpage des tâches est déjà réalisé au niveau des différents processus hôtes. Il apparaît donc inutile d’ajouter un second niveau de découpage interne au processus. Ainsi, l’exploitation de n cartes graphiques est obtenue par le placement de n processus MPI répartis sur l’ensemble des nœuds contenant les cartes. 1186.2. Application multi-GPU L’inconvénient majeur de cette stratégie est qu’un nœud de calcul dispose généralement d’un plus grand nombre de cœurs CPU que de cartes graphiques. Dans l’exemple de la machine Froggy, le rapport est de 8. Lors d’une utilisation multi-GPU, de nombreux cœurs CPU sont inutilisés. L’approche que nous proposons dans la section 6.3 à travers la mise en œuvre de la méthode hybride nous permettra d’explorer une solution à ce problème d’occupation. La suite de ce chapitre est consacrée à la mise en œuvre de cette stratégie dans un cadre multi-GPU puis hybride multi-CPU et multi-GPU. 6.2. Application multi-GPU 6.2.1. Mécanisme de communication La résolution de l’équation de transport sur plusieurs cartes graphiques nécessite des communications entre ces GPU. À chaque carte est associée une partie du domaine de calcul. Ainsi, le domaine de calcul est séparé le long de plans orthogonaux à une direction de découpe. Nous appelons direction de découpe une direction dont le traitement nécessite des communications. Le principal avantage de ce découpage est de conserver une méthode de résolution identique au cas simple GPU lors du traitement des directions de l’espace autres que celles de découpe. Dans ces dernières, les données correspondant aux sous-problèmes 1D sont distribuées sur plusieurs cartes ce qui implique des communications entre ces cartes. Nous distinguons alors les données locales calculées par une carte et les données non locales qui sont calculées par une autre carte et qui doivent être transférées. Deux communications sont nécessaires : une pour l’étape d’advection et l’autre pour le remaillage. Pour l’advection, les interpolations du champ de vitesse nécessaires au calcul des positions des particules sont faites sur des données non locales pour les particules ayant quitté le domaine. Ces données devront être transférées au préalable depuis les cartes voisines. La quantité de ces données dépend directement du champ de vitesse lui-même. Toutefois, une majoration de leur taille est possible à partir du nombre CFL maximal. En effet, ce dernier correspond au nombre maximal de cellules traversées par les particules en une itération. Une particule au bord du domaine n’aura pas besoin de plus de données distantes qu’elle ne peut traverser de cellules. Cet algorithme est schématisé sur la figure 6.2a. De la même manière, lors du remaillage, la taille des zones de communications dépend du nombre CFL maximal ainsi que de la largeur du support de la formule de remaillage employée. Lors du calcul, le domaine local est bordé par des zones mémoire qui représentent les points de grille voisins distants et récupèrent les contributions des particules sur ces points. Ces derniers sont parfois appelés points fantômes ou ghosts. Les données de ces zones sont ensuite envoyées aux processus voisins puis ajoutées aux données locales. L’adaptation de cet algorithme est schématisé sur la figure 6.2b. Les communications se font exclusivement avec les processus voisins dans la direction de calcul. Dans les deux algorithmes, une utilisation de la mémoire partagée comme un cache similaire au cas simple GPU est employée pour les données du champ de vitesse non local ainsi que pour les points de grille exté- rieurs. Les échanges de données à l’issue du remaillage se caractérisent par un ajout des 1196. Implémentation sur architectures hétérogènes valeurs distantes du scalaire aux valeurs locales, alors que pour le champ de vitesse, il s’agit simplement d’une copie des données qui sont utilisées en lecture uniquement. GPUn GP Un−1 GPUn+1 Intégration Interpolations Vitesse (grille) Mémoire partagée Position (particules) Copies de données Utilisation des données Communication inter-GPU Données non locales (a) Advection GPUn GPUn−1 GPUn+1 Scalaire (particules) Position (particules) Scalaire (grille) Mémoire partagée += += += += Λp,r Copies de données Utilisation des données Communication inter-GPU Données non locales (b) Remaillage Figure 6.2. – Adaptation des algorithmes d’advection et remaillage au cas multi-GPU Ces communications inter-GPU consistent en des échanges de données entre les mé- moires globales des cartes graphiques. Généralement, les implémentations MPI ne sont pas capables de lire et écrire des données directement dans la mémoire des cartes sans faire intervenir l’hôte. Toutefois, certaines implémentations spécifiques telles que MPI-ACC (Aji et al., 2012) ou MVAPICH (Wang et al., 2011) permettent de réaliser des envois de messages directement de la mémoire d’une carte à l’autre. Dans cette dernière, les transferts utilisent les technologies telles que proposées par les versions récentes de CUDA sur les cartes Nvidia (GPUDirect). La librairie MVAPICH est disponible au téléchargement 2 mais ne permet qu’une exploitation des seules cartes NVIDIA et, à notre connaissance, la librairie générique MPI-ACC n’a pas été encore distribuée. Ces travaux font état de gains en termes de per- 2. http ://mvapich.cse.ohio-state.edu/downloads/ 1206.2. Application multi-GPU formances des communications pouvant atteindre 30% par rapport à des transferts naïfs. En l’absence de telles librairies, la méthode naïve consiste en une succession de transferts depuis la mémoire globale de la carte vers le CPU, entre les CPU hôtes et enfin du CPU vers la mémoire de la carte de destination. Ce mécanisme est illustré sur la figure 6.3 par l’enchaînement des flèches vertes et bleues. Réseau local host - device MPI GPU-aware MPI Figure 6.3. – Schémas de communications inter-GPU Les résultats de cette thèse sont obtenus à l’aide de transferts naïfs combinant explicitement un usage des fonctions OpenCL pour les transferts entre les cartes et les CPU hôtes ainsi que des envois de message MPI entre CPU. Nous précisons que l’utilisation technologies spécifiques aux cartes Nvidia n’a pas encore été intégré au standard OpenCL. De manière générale, ces transferts peuvent être optimisés par un découpage des données en blocs dont les envois sont traités en chaîne (Aji et al., 2013), comme illustré par la fi- gure 6.4. Ainsi, le message original est traité par un ensemble d’envois de plus petite taille permettant un recouvrement des opérations. La taille des blocs est un des paramètres qui doit être ajusté en fonction du matériel utilisé (PCIe et réseau). Transfert manuel GPU vers CPU MPI CPU vers GPU Transfert par blocs en chaîne temps Figure 6.4. – Optimisation des communications inter-GPU 6.2.2. Performances Les performances de cette implémentation dans un contexte multi-GPU sont étudiées à travers l’exemple de transport de fonction levelset 3D présenté en section 5.3.2. Des études de scalabilité, dont le principe a été introduit en section 1.2.2, permettent d’observer l’évolution du temps de calcul face à l’augmentation du volume total de communication induite par l’augmentation du nombre de ressources utilisées. La scalabilité forte d’un code démontre sa capacité à traiter un problème plus rapidement lorsque le nombre de 1216. Implémentation sur architectures hétérogènes ressources augmente. Idéalement, on attend que le temps de calcul soit réduit d’un facteur n lorsque les ressources sont augmentées d’un facteur n. Cette étude n’est pas adaptée à notre implémentation multi-GPU car elle conduit à la résolution de problèmes de tailles de plus en plus petite à mesure que le nombre de cartes utilisées augmente. Dans ce type d’étude, la taille du problème total est fixée et doit pouvoir être traitée par un seul GPU. De plus, comme nous avons vu dans le chapitre précédent, les meilleures performances sont obtenues lorsque le problème traité sur un GPU est suffisamment grand. Une étude de scalabilité faible est préférable dans ce contexte. Elle conduit à l’étude de l’évolution du temps de calcul lorsque le nombre de ressources augmente en conservant une charge de travail par GPU constante. Ainsi, en partant d’une taille de problème compatible avec les caractéristiques d’une carte graphique, l’influence des communications est directement mesurée. Les résultats de scalabilité, présentés sur la figure 6.5, sont obtenus en en utilisant un schéma RK2 et une formule de remaillage Λ6,4 pour résoudre des problèmes de taille (NX, NY , nNZ) où n est le nombre de GPU employés. Ainsi, chaque GPU est chargé d’un problème de taille (NX, NY , NZ). Nous ne considérons ici qu’une seule direction de découpe, dans la direction Z. La figure 6.5 représente l’évolution de la scalabilité en fonction du nombre de cartes graphiques utilisées. Deux cas sont considérés : le premier est une résolution identique de 2563 points de grille par GPU pour la vitesse et le scalaire. Le second est un cas multiéchelle où la vitesse est connue sur une grille de taille 1283 alors que le scalaire est résolu sur 5123 points. Les oscillations qui apparaissent pour les cas à 2563 par GPU sont dues à la distance variable entre deux cartes voisines. En effet, les communications au sein d’un même nœud sont plus rapides que d’un nœud à l’autre. En pratique, lorsqu’un GPU est ajouté à un nombre impair, on ajoute la seconde carte du dernier nœud à l’ensemble des cartes utilisées. Dans ce cas, les communications supplémentaires sont réalisées entre les deux cartes du même nœud, ce qui conduit à une amélioration de la scalabilité. La perte importante de scalabilité entre 1 et 2 GPU provient de l’absence totale de communications dans le cas 1 GPU ainsi que du manque d’optimisation des cas multi-GPU. Comme nous l’avons évoqué précédemment, leur taille dépend du nombre CFL de la simulation. Pour les cas Na = Nu = 2563 , le nombre CFL maximal est égal à 8 et implique des communications de taille 8×2562 éléments par voisins pour le champ de vitesse et le scalaire. Dans le cas multiéchelle Na = 1283 et Nu = 5123 , le pas de temps est identique et les tailles de communications par voisins sont de 4 × 1283 et 15 × 5123 respectivement pour la vitesse et le scalaire. D’autre part, dans l’état actuel du code, nous n’avons pas encore mis en place de stratégies de recouvrement des communications par des calculs, ce qui implique que les temps de calculs sont augmentés de la totalité des temps de communications. Ainsi la scalabilité du cas 2 GPU par rapport au cas 1 GPU est assez faible car elle revient à comparer les temps de communications à un cas sans aucune communication. Toutefois, la scalabilité par rapport au cas utilisant 2 GPU est satisfaisante car supérieure à 0.85 jusqu’à 12 GPU. La version avec un seul kernel donne des résultats similaires à celle avec deux kernels séparés avec des temps de calcul inférieurs de 3%. D’autre part, la chute de scalabilité entre 1 et 2 GPU peut être atténuée en diminuant le volume de communications par une réduction du pas de temps. La répartition du temps de calcul pour quelques cas tirés de l’étude précédente est représentée sur la figure 6.6. Elle donne la répartition du temps de calcul global d’une 1226.2. Application multi-GPU 0.4 0.5 0.6 0.7 0.8 0.9 1 2 2(N a , N u ) 4 4(N a , N u ) 6 6(N a , Nu ) 8 8(N a , N u ) 10 10(N a , Nu ) 12 12(N a , Nu ) Scalabilité : ˜S = T(1) 1 /Tn Nombre de GPU / Taille du problème 2 kernels, N a = N u = 2563 2 kernels, N a = 1283 , Nu = 5123 1 kernel, N a = N u = 2563 1 kernel, N a = 1283 , Nu = 5123 Figure 6.5. – Performances du transport de scalaire 3D multi-GPU itération entre les différentes directions. Comme annoncé précédemment, les temps de calcul issus des communications dans la direction Z apparaissent comme ajoutés au temps de calcul obtenu sans communications et sont inclus dans la partie associée à l’hôte pour cette direction. Ainsi, seul le temps de communication varie avec le nombre de GPU et les temps d’exécutions des kernels restent constants. Nous détaillons sur la figure 6.7a les éléments constituant la direction Z en distinguant les kernels OpenCL pour l’initialisation, les kernels d’advection et de remaillage ainsi que les étapes de transferts de données. Les communications entre CPU sont notées MPI et celles entre les cartes et les hôtes sont notées D→H ou H→D selon le sens de transfert. Enfin, l’étape d’ajout des contributions provenant des processus voisins est notée += et est effectuée par l’hôte de chaque carte. Les dépendances entre toutes ces étapes sont représentées sur la figure 6.8. Cette représentation de l’enchaînement des différentes étapes lors du traitement d’une direction de découpe montre que certaines peuvent être réalisées simultanément. En effet, l’initialisation des particules est indépendante du transfert des données du champ de vitesse. De même, la copie des données du scalaire correspondant à une partie du domaine local est indépendante des communications des contributions pour les domaines voisins. Le parallélisme par tâches OpenCL permet de démarrer ces opérations sans en attendre la complétion. Les détails du profilage des temps de calculs pour la figure 6.7a sont réalisés en forçant une synchronisation explicite des tâches permettant leur comparaison. Comme le montre la figure 6.7a, les étapes de calculs ne suffisent pas à couvrir les communications. La figure 6.7b illustre cette remarque en reprenant la figure 6.7a avec un code de couleur indiquant les étapes de calcul et celles de communication. Ces résultats suggèrent la nécessité d’une réduction des temps de communications. Une optimisation 1236. Implémentation sur architectures hétérogènes 8 4 2 1 0 0.02 0.04 0.06 0.08 0.1 0.12 Nombre de GPU Simple échelle : N a = N u = 2563 Initialisation X Calcul X Host X Initialisation Y Calcul Y Host Y Initialisation Z Calcul Z Host Z 8 4 2 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Nombre de GPU Temps de calcul par itération (s) Multiéchelle : N a = 1283 , Nu = 5123 Figure 6.6. – Temps de calcul par itération envisageable consiste à améliorer les temps de transfert entre GPU en utilisant, par exemple, un traitement par blocs en chaîne. Après cette première optimisation, une stratégie de recouvrement des communications par les calculs pourra être envisagée. En particulier, les étapes de calculs peuvent être séparées en deux parties à l’issue d’un redécoupage du domaine local. Une première partie entièrement locale, ne nécessitant pas l’usage de données distantes, peut s’exécuter pendant les communications. La seconde partie consiste à traiter le reste du domaine à l’aide des données transférées. L’optimisation des communications ainsi que leur recouvrement constituent une des perspectives immédiates de ce travail. Les résultats présentés ici sont réalisés uniquement dans le cas d’une seule direction de découpe, par plans XY . L’implémentation que nous proposons ne se restreint pas à cette approche et permet notamment de considérer une découpe dans autre direction ainsi que dans plusieurs directions. Cette dernière est utile essentiellement dans les cas où un grand nombre de cartes graphiques est employé afin de réduire les disparités de nombre de points des domaines locaux. Par exemple, pour la résolution d’un problème global de taille (NX, NY , NZ) sur n cartes graphiques la résolution des domaines locaux est égale à (NX, NY , NZ/n) dans le cas d’une découpe dans la direction Z. Elle passe à (NX, NY /n1, NZ/n2), avec n = n1n2 pour une découpe dans les directions Y et Z. L’avantage est de conduire à des résolutions plus grandes dans les directions de découpes que dans le premier cas. En revanche un plus grand nombre de communication est nécessaire. Les configurations considérées dans ce manuscrit ne nécessitent pas l’utilisation d’un découpage dans plusieurs directions car le nombre de cartes graphiques reste relativement faible. Cette implémentation multi-GPU pour le transport de scalaire peut être employée en parallèle d’une résolution CPU de l’écoulement pour la simulation du problème complet. 1246.2. Application multi-GPU 8 4 2 1 Nombre de GPU N a = 1283 , Nu = 5123 Transposition XZ (kernel) Advection (kernel) Remaillage (kernel) Advec. et Remail. (kernel) Advection D→H Advection MPI Advection H→D Remaillage D→H Remaillage D→H local Remaillage MPI Remaillage += (hôte) Remaillage H→D local 8 4 2 1 0 10 20 30 40 50 60 70 80 90 100 Nombre de GPU Proportion de la direction Z (% du temps de calcul) N a = N u = 2563 (a) Étapes de l’algorithme 8 4 2 1 Nombre de GPU N a = 1283 , Nu = 5123 Communications H↔D Communications MPI Calcul 8 4 2 1 0 10 20 30 40 50 60 70 80 90 100 Nombre de GPU Proportion de la direction Z (% du temps de calcul) N a = N u = 2563 (b) Calculs et communications Figure 6.7. – Profilage de la direction de découpe 1256. Implémentation sur architectures hétérogènes Initialisation Vitesse D→H Vitesse MPI Vitesse H→D Advection Remaillage Scalaire local D→H Scalaire D→H Scalaire MPI Scalaire += Scalaire local H→D Figure 6.8. – Dépendances des étapes de communication multi-GPU 6.3. Transport turbulent d’un scalaire passif 6.3.1. Application hybride Le problème que nous considérons dans cette partie est le transport de scalaire passif dans un jet plan turbulent tridimensionnel, tel que présenté par Magni et al. (2012). Le domaine de calcul est une boite unitaire périodique [0; 1]3 . Le problème est modélisé par le couplage entre les équations de Navier-Stokes, en formulation vitesse vorticité, et d’une équation de transport du scalaire θ, rappelé ci-après :    div u = 0, ω = rotu, Dω Dt =  ∂ω ∂t + (u · ∇) ω  = (ω · ∇)u + ν∆u, Dθ Dt = ∂θ ∂t + (u · ∇)θ = κ∆θ. (6.1) L’écoulement est constitué d’un jet plan, modélisé par un champ de vitesse initialement nul dans tout le domaine excepté dans une région d’épaisseur w le long d’un plan XZ. Le champ de vitesse initial est perturbé par un champ aléatoire P de magnitude 0,05. Le scalaire passif est initialisé de la même manière que le champ de vitesse. Les valeurs initiales du champ de vitesse et du scalaire sont données par les expressions : θ(x, y, z) = (1 + 0.3 sin(8πx))  1 + tanh  0.1 − 2|y − 0.5| 4w  /2 (6.2) u X(x, y, z) = θ(x, y, z)P X, u Y (x, y, z) = P Y u Z (x, y, z) = P Z (6.3) La condition initiale du champ de vitesse est représentée en figure 6.9 pour la composante u X. L’écoulement se développe dans le plan du jet, dans la direction X. Les perturbations provoquent l’établissement d’un régime turbulent qui se traduit par l’évolution tridimensionnelle de l’écoulement. Le scalaire est ainsi transporté dans tout le domaine. L’écoulement est caractérisé par la largeur du jet w = 0.1, ce qui donne un nombre de Reynolds égal à 103 pour une viscosité ν = 10−4 . Différentes valeurs de nombre de Schmidt 1266.3. Transport turbulent d’un scalaire passif Figure 6.9. – Champ de vitesse initial, composante u X 1276. Implémentation sur architectures hétérogènes seront considérées en fonction du rapport d’échelle entre les grilles de résolutions du fluide et du scalaire. En effet, comme nous l’avons décrit au chapitre 1, le rapport des échelles de dissipation d’énergie est lié au nombre de Schmidt : ηκ √ Sc = ην, avec Sc = ν/κ où ν est la viscosité du fluide et κ la diffusivité du scalaire. Ces différentes échelles sont prises en compte par la résolution des discrétisations des variables. Le champ de vitesse est résolu sur une grille plus grossière que celle du scalaire. Nous rappelons que la méthode numérique hybride employée pour résoudre ces problèmes consiste en l’utilisation d’une méthode semi-Lagrangienne pour le transport du scalaire et de différences finies pour sa diffusion. L’écoulement est résolu en employant une méthode semi-Lagrangienne pour le transport de vorticité, des différences finies pour le terme d’étirement et une méthode spectrale pour la diffusion de vorticité. L’équation de Poisson pour le calcul du champ de vitesse est également résolue par une méthode spectrale. 6.3.2. Exploitation d’une machine hétérogène Comme nous l’avons évoqué précédemment, le transport du scalaire et le fluide sont suffisamment indépendants pour être résolus simultanément sur différents matériels. En effet, le couplage de ces sous-problèmes consiste simplement en une communication du champ de vitesse en début d’itération de la partie fluide vers le transport. Pour l’exemple de l’utilisation de la machine Froggy présentée en section 6.1, nous utilisons n GPU et les n cœurs CPU hôtes associés pour résoudre le transport du scalaire ainsi que les 7n cœurs CPU disponibles sur les nœuds pour calculer le champ de vitesse de l’écoulement. Cette distribution des tâches est représentée sur la figure 6.10. Réseau local Transport Navier-Stokes Figure 6.10. – Distribution des tâches pour l’application hybride En pratique, nous introduisons une notion de parallélisme par tâche. Les différents processus MPI sont associés à une tâche à travers un découpage du communicateur global. Une synchronisation globale est effectuée à l’occasion de la communication du champ de vitesse. Dans cette exemple, deux tâches sont définies : une pour l’écoulement et l’autre pour le transport. Pour simplifier la distribution des tâches sur l’ensemble des processus, la résolution globale du scalaire doit être un multiple de n. De même, les résolutions de la vitesse et de la vorticité doivent être égales et multiples du nombre de cœurs CPU associés à leur calcul. D’autre part, les opérations de FFT du solveur spectral donnent de meilleures performances pour des résolutions multiples d’une puissance de 2. Ainsi, sauf 1286.3. Transport turbulent d’un scalaire passif mention contraire, la résolution du fluide sera égale à un multiple de 4n et seulement 4 des 7 cœurs seront utilisés. 6.3.3. Résultats et performances L’évolution du jet est caractérisée par une phase de diffusion suivie d’une phase de création d’enstrophie qui correspond à l’apparition d’instabilités tridimensionnelles s’accompagnant de la production de petites échelles. L’enstrophie E décrit l’évolution des pertes d’énergie cinétique de l’écoulement E par la relation : dE dt = −νE, (6.4) avec E = 1 2 Z Ω ||u||2 dx et E = Z Ω ||ω||2 dx La figure 6.11a donne la variation de l’enstrophie de l’écoulement dont l’augmentation rapide, vers t = 2, indique l’apparition du régime turbulent. Les effets de dissipation d’énergie par diffusion deviennent ensuite prépondérants et se traduisent par une diminution de l’enstrophie et des valeurs extrêmes du champ de vitesse. Ces simulations sont réalisées en employant des formules de remaillage Λ6,4 et une intégration en temps par un schéma Runge-Kutta d’ordre deux pour les transports de la vorticité et du scalaire. Des schémas aux différences finies sont utilisés à l’ordre 4 pour le terme d’étirement et au premier ordre pour la diffusion du scalaire. Enfin, le pas de temps est calculé à chaque itération de manière à être maximal, tout en vérifiant la condition de CFL Lagrangienne : ∆t 6 M |∇u|∞ . Le choix de la constante M < 1 est laissé à l’utilisateur. Pour de grandes valeurs il peut conduire, selon les problèmes traités, à l’apparition d’instabilités numériques pouvant perturber l’écoulement de manière non physique. En pratique, une calibration de cette constante par rapport au problème et à ses conditions initiales est nécessaire. Dans cet exemple, nous constatons expérimentalement que des valeurs M > 0.2 ne permettent plus de capter la physique de l’écoulement surtout lorsque le régime turbulent est établi, pour t > 3. D’autre part, la perturbation aléatoire appliquée à la condition initiale conduit à des valeurs du gradient du champ de vitesse peu représentatives de l’écoulement, en début de simulation, et entraîne l’utilisation de pas de temps trop grands. Dans ce cas, il est nécessaire d’employer une stratégie de calcul différente en début de simulation. En particulier, une technique simple consiste à fixer le pas de temps à une valeur arbitraire. Une autre idée est d’ajouter une contrainte supplémentaire sous la forme d’une condition de CFL par rapport au champ de vitesse. L’évolution du pas de temps et du nombre CFL maximal de l’écoulement sont présentés sur la figure 6.11b pour deux modifications du calcul du pas de temps. Lorsque l’écoulement n’a pas encore atteint un régime turbulent, nous appliquons une condition de type CFL (cas 1) tel que : ∆t 6 1.5∆x u/|u|∞ ou bien (cas 2) une restriction à un pas de temps inférieur à 0.011. Dans tous les cas, le pas de temps utilisé vérifie la condition de CFL Lagrangienne. 1296. Implémentation sur architectures hétérogènes Cette dernière devient la contrainte la plus restrictive à partir de l’instant t = 1.5 et conduit à une diminution du pas de temps. Enfin, il augmente à nouveau sur la fin de la simulation, à mesure que l’énergie est dissipée par les petites échelles. Toutefois, les pas de temps obtenus sont assez grands et le nombre CFL varie entre 2 et 13, par rapport à la grille fine de résolution 1 0243 . L’avantage de l’approche couplant une condition de CFL et la condition Lagrangienne est qu’elle permet de conserver l’intérêt d’un pas de temps adaptatif en suivant la dynamique de l’écoulement. 20 40 60 80 100 120 140 0 1 2 3 4 5 Enstrophie : E = R ||ω|| 2d x Temps Cas 1 : M = 0.15, CF L 6 1.5 Cas 2 : M = 0.15, ∆t 6 0.011 (a) Enstrophie 0.002 0.004 0.006 0.008 0.01 0.012 ∆t 0 2 4 6 8 10 12 14 0 1 2 3 4 5 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 Nombre CFL maximal |u|∞ ∆t/ ∆ x θ |u|∞ ∆t/ ∆ x u Temps (b) Pas de temps et CFL max. Figure 6.11. – Configuration du jet turbulent Le nombre CFL obtenu pour le transport du scalaire peut paraître relativement faible pour une méthode particulaire. En effet, dans cet exemple, nous employons le même pas de temps à la fois pour la résolution du fluide et celle du scalaire. Théoriquement, une condition moins restrictive que celle employée ici pour le transport du scalaire est envisageable et permettrait d’utiliser de plus grands pas de temps. Cela est illustré par les exemples de transports de fonctions levelset donnés dans le chapitre 5 où le nombre CFL atteint des valeurs de plusieurs dizaines. Une solution, exploitée notamment par Lagaert et al. (2014), consiste à réaliser des sous-itérations pour la partie fluide. Elle permet d’ajuster les contraintes sur le pas de temps indépendemment pour chaque sous-problème. En pratique, une condition LCFL est imposée pour la résolution du transport du scalaire, avec M grand, et un nombre de sous-itérations est calculé afin d’obtenir un pas de temps suffisamment petit pour la résolution du fluide. Dans cet exemple, il serait envisageable d’employer des pas de temps 6 fois plus grands pour le transport du scalaire, en prenant M = 0.9. Toutefois, l’intérêt de cette approche est limité ici car une itération du transport du scalaire est, dans la majorité des cas, totalement recouverte par le calcul de l’écoulement. Par conséquent, relativement au temps total de simulation, des sous-itérations pour la partie fluide condui- 1306.3. Transport turbulent d’un scalaire passif raient à un renforcement du déséquilibre de charge entre les CPU et les GPU, comme nous le verrons plus loin. Les figures 6.12 donnent les valeurs de la norme de la vorticité et du scalaire dans un plan XZ au centre du jet à l’instant t = 4.5. L’écoulement est complètement turbulent et on observe de nombreuses structures de tailles variables. Une comparaison de ces deux images permet d’illustrer les différentes échelles qui caractérisent ce problème pour un nombre de Schmidt élevé. En effet, les plus petites structures de la figure de gauche, correspondant au fluide, sont bien plus grandes que celles de la figure de droite, pour le scalaire. Le rapport entre les tailles des structures est égal à √ Sc et est égal à 8 dans cet exemple. ||ω|| 0 40 (a) Norme de la vorticité θ 0 1 (b) Scalaire Figure 6.12. – Champs instantanés dans le plan XZ, au centre du jet, à t = 4.5. Nu = 1283, Nθ = 1 0243, Sc = 64 Cette simulation a été réalisée en employant 32 cœurs CPU pour la résolution de l’écoulement et 8 GPU pour le transport du scalaire à raison de 1,4 secondes par itérations, soit 23 minutes de calcul pour atteindre t = 5. La répartition des temps de calcul pour les différentes parties de la résolution sont présentées en figure 6.13 pour différentes résolutions et configurations. Par notre stratégie de programmation hybride, les résolutions des deux parties du problème sont exécutées simultanément sur différentes ressources. Ainsi, le temps de calcul total est donné par la plus longue des parties. Les trois premières lignes de la figure correspondent à une étude de scalabilité forte car les résolutions restent identiques. La troisième ligne fait apparaître une large part de communication pour l’advection multi-GPU dans la direction Z. Le temps de calcul associé à cette étape est encore augmenté lorsque la résolution du scalaire passe à 1 0243 points. La nécessité d’une optimisation des communications entre GPU telle que suggérée par les résultats de la section 6.2 est ici moins prononcée. En effet, dans la plupart des confi- gurations employées pour cette application, la résolution du fluide est la partie limitante du temps de calcul global. Ainsi, les communications, même non optimisées, générées par 1316. Implémentation sur architectures hétérogènes le transport multi-GPU sont recouvertes par les calculs de l’écoulement sur CPU. Comme nous l’avons détaillé précedemment, notre implémentation se base sur une majoration de la quantité de données à échanger pour les communications inter-GPU. Dans ces exemples, cela conduit à un volume de communications par GPU pour les cas Nu = 1283 et Nu = 2563 respectivement de 2 × 1282 et 4 × 2562 points pour les données du champ de vitesse. Pour le scalaire, le nombre de points est de 10 × 5122 et 17 × 1 0242 pour les cas Nθ = 5123 et Nθ = 1 0243 . Cette estimation des tailles de communications est réalisée à priori par l’utilisateur à partir d’une majoration du pas de temps et du champ de vitesse. Une limite à cette approche est que les données échangées ne sont pas toujours entièrement utilisées. En effet, au gré de l’évolution du pas de temps, la taille des données nécessaires peut diminuer par rapport à l’estimation. De même, le maximum de vitesse n’est pas nécessairement atteint au voisinage des bords du domaine local. La mise en place d’un calcul de la taille des données à échanger à chaque itération a été envisagé mais n’a pas été retenu. En effet, la complexité algorithmique supplémentaire ne permet pas nécessairement de conduire à une réduction des temps de calcul liés à la diminution du volume des communications. Le code GPU que nous développons exploite des tableaux en mémoire partagée dans laquelle l’allocation dynamique n’est pas possible. Par conséquent, un changement dans la taille de ces tableaux nécessite une recompilation des noyaux OpenCL au cours de l’exécution. Cette recompilation peut être réalisée seulement dans les cas où la taille des tableaux augmente. Cependant, les communications et les transferts seraient effectués sur des données non contiguës, ce qui nuit aux performances. On notera que le temps de calcul associé aux communications induites par le découpage par tâches de l’implémentation hybride sont assez faibles car elles ne concernent que le champ de vitesse. Enfin, les temps de calculs pour l’advection de la vorticité sont assez longs relativement à la résolution du champ de vitesse. Une des causes de ce comportement est que l’implémentation multi-CPU développée par Lagaert et al. (2014) que nous utilisons est plutôt destinée à traiter de larges résolutions sur un très grand nombre de processeurs, jusqu’à 3 0643 points sur 2 048 cœurs. De plus, traiter un problème de taille 1283 sur 32 cœurs conduit à une charge par cœur de seulement 1282 × 4 points. Le volume de communications généré dans la direction Z devient relativement important car toutes les particules nécessitent un envoi, le support de la formule de remaillage étant plus large que le domaine local. Le cas 4 est le seul où le calcul du transport du scalaire est plus long que le calcul de l’écoulement sur CPU. Ce déséquilibre sera vraisemblablement atténué par une optimisation des communications entre GPU. Comme pour l’étude dans le cas multi-GPU, nous réalisons une étude de scalabilité faible, sur la figure 6.14a, dont les temps de calculs sont donnés sur la figure 6.14b. Deux cas d’occupation des nœuds sont considérés. Le premier consiste en la résolution d’un problème de taille Nu = 1283 et Nθ = 5123 pour un ensemble de ressources composé de 4 cœurs CPU pour la résolution du fluide et 1 GPU pour le transport du scalaire, ce qui correspond à une occupation de 5/8 = 62, 5%. Le second cas nous permet d’atteindre une occupation maximale en utilisant 7 cœurs. La taille du sous-problème de la partie fluide Nu = 1123 = (7 × 16)3 est ajustée pour être multiple de 7. Comme prévu par les résultats précédents, la résolution du fluide est effectuée en un temps plus long que le transport du scalaire. Dans les deux cas, l’évolution du temps de calcul du solveur multi-GPU donne lieu à une 1326.3. Transport turbulent d’un scalaire passif Cas 5 : N u = 2563 -32CPU N θ = 1 0243 -8GPU Cas 4 : N u = 1283 -32CPU N θ = 1 0243 -8GPU Cas 3 : N u = 1283 -32CPU N θ = 5123 -8GPU Cas 2 : N u = 1283 -8CPU N θ = 5123 -1GPU Cas 1 : N u = 1283 -4CPU N θ = 5123 -1GPU 0 0.5 1 1.5 2 2.5 3 3.5 Temps de calcul par itération Temps total Calcul de ∆t Advection ω Étirement Diffusion ω Poisson Advection θ (dir. X) Advection θ (dir. Y) Advection θ (dir. Z) Advection θ (comm. dir. Z) Diffusion θ Comm. hybride Figure 6.13. – Répartition du temps de calcul pour le cas hybride scalabilité similaire à celle obtenue pour la figure 6.5. Les communications entre GPU sont pénalisées par la présence des communications induites par la résolution de l’écoulement sur CPU, en plus des raisons évoquées en section 6.2. En effet, toutes les communications internœuds passent nécessairement par le même réseau et se partagent sa bande passante, ce qui limite les performances en comparaison au cas où seuls les GPU sont utilisés. En revanche, la scalabilité reste supérieure à 85 et 70% respectivement dans les deux cas sur 48 et 84 cœurs pour le calcul de l’écoulement. Conclusion Dans ce chapitre nous avons vu comment les mécanismes habituels utilisés pour l’exploitation des CPU multicœurs des machines à mémoire distribuée s’étendent au cas des accélérateurs. L’approche étudiée consiste à compléter le parallélisme classique pour la gestion de la mémoire distribuée par un niveau de parallélisme spécifique à l’utilisation des accélérateurs. Ainsi, notre implémentation est capable d’exploiter l’ensemble des ressources d’une machine hétérogène, composée de CPU multicœurs et de cartes graphiques. Dans le modèle de programmation OpenCL, les cartes graphiques sont associées à un processus hôte sur le CPU. Dans le cas d’une utilisation seule des GPU, un grand nombre de cœurs sont donc inutilisés. Nous avons exploré une solution à ce problème d’occupation à l’occasion de l’exemple de transport de scalaire dans un écoulement turbulent. L’idée est de placer des processus sur l’ensemble des cœurs des nœuds et de les associer à différentes tâches. Un ensemble de processus est identifié comme hôtes des cartes graphiques permettent de 1336. Implémentation sur architectures hétérogènes Cas 1 : 1283 |5123 Ressources unitaires : (4CPU + 1GPU) Temps total Fluide Scalaire Cas 2 : 1123 |5123 Ressources unitaires : (7CPU + 1GPU) Temps total Fluide Scalaire 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 2 4 6 8 10 12 Scalabilité faible : ˜S = T(1) 1 /Tn Quantité de ressources (a) Scalabilité faible 0 0.5 1 1.5 2 2.5 3 2 4 6 8 10 12 Temps de calcul par itération (s) Quantité de ressources (b) Temps de calcul Figure 6.14. – Scalabilité faible pour le cas hybride calculer le transport du scalaire alors que les autres processus sont affectés à la résolution de l’écoulement. Ce chapitre nous a permis d’analyser les performances de la méthode dans un cadre multi-GPU à travers une étude de scalabilité faible. Il apparaît dans les résultats que la part de temps de calcul induite par les communications entre cartes graphiques nécessite des optimisations. En effet, diverses stratégies ont été évoquées telles qu’un découpage en blocs pour un traitement en chaîne ou encore un recouvrement par les calculs ne nécessitant pas de communications. Toutefois, lors de la résolution hybride du problème complet, le temps de calcul est généralement limité par la résolution du fluide sur les cœurs CPU. Le problème de transport de scalaire passif par un jet plan turbulent a été réalisé sur diverses configurations matérielles jusqu’à l’exploitation de 6 nœuds complets de la machine Froggy, soit 96 cœurs CPU et 8 GPU et pour des résolution de 2563 points pour le fluide et 1 0243 pour le scalaire. Une limitation de cette approche est que l’équilibrage de la charge entre les CPU et les GPU n’est pas possible autrement que par une modification des résolutions ou des paramètre des méthodes. Ainsi, le meilleur équilibrage de charge est obtenu dans le cas 4 de la figure 6.13 et pourrait être amélioré par l’optimisation des communications inter-GPU. Pour ce qui est du cas 5, correspondant aux résolutions les plus importantes, une solution consisterait à employer des ressources CPU supplémentaires, des nœuds sans GPU par exemple. 134Conclusion générale L’objectif principal de cette thèse était d’explorer les possibilités d’une exploitation de machines de calcul hétérogènes par une méthode hybride pour la résolution de problèmes multiéchelles de transport de scalaire passif. La méthode de résolution employée repose sur une méthode particulaire avec remaillage. Elle s’identifie à une classe de méthodes semi-Lagrangiennes dans laquelle les particules suivent les trajectoires de l’écoulement mais en traitant l’interpolation particule-grille de manière explicite par remaillage. L’intérêt majeur est de combiner les avantages des mé- thodes Lagrangiennes et Eulériennes. En effet, cette méthode permet l’utilisation de pas de temps plus grands que ceux obtenus sous une contrainte de CFL classique pour les méthodes de grille. De plus, elle est parfaitement adaptée à la résolution d’équations de conservation et permet une montée en ordre des schémas numériques lorsque des formules de remaillages conservant un grand nombre de moments et suffisamment régulières sont utilisées. Nous avons exposé, dans le chapitre 2, une méthode de construction de telles formules dont les caractéristiques influent directement sur l’ordre de la méthode. Dans ce même chapitre, nous avons exploité l’analogie avec la méthode des différences finies pour démontrer la consistance et la stabilité des schémas numériques ainsi obtenus. Le principe d’une méthode hybride tel que rappelé dans le chapitre 3 est de coupler différentes méthodes de résolution adaptées aux différents aspects physiques et numériques du problème considéré. Dans cette thèse, nous avons repris l’idée d’un couplage de la méthode semi-Lagrangienne avec des schémas aux différences finies et des méthodes spectrales pour la résolution de problèmes de transport de scalaire passif dans un écoulement turbulent. Cette approche consiste à combiner les trois niveaux d’hybridation : grilles de résolutions différentes pour l’écoulement et le transport du scalaire, méthodes numériques de diverses natures et calcul sur architectures hétérogènes. Le calcul hybride est un aspect émergent du calcul à hautes performances et découle directement de la volonté de s’adapter aux architectures des machines de calcul parallèles. Le constat de leur évolution rapide nous a poussé à développer un code multiarchitecture dans lequel l’accent a été mis sur la portabilité et la souplesse d’utilisation (chapitre 4). Ce code est ainsi capable de s’exécuter sur divers types d’architectures (CPU multicœur et GPU) et de machines (d’un portable jusqu’à un serveur de calcul parallèle). Le langage Python a été choisi pour sa portabilité, sa simplicité d’interfaçage avec d’autres langages et ses performances. Il nous permet d’orchestrer les simulations en utilisant, entre autres, les librairies MPI et OpenCL ainsi que des routines en Fortran. 135Conclusion générale L’utilisation de cartes graphiques est particulièrement bien adaptée à la méthode particulaire avec remaillage d’ordre élevé. En effet, comme nous l’avons montré dans le chapitre 5, la régularité des structures de données ainsi que l’intensité opérationnelle des schémas numé- riques nous permettent d’obtenir des performances de calcul intéressantes. En particulier, dans une analyse par le modèle roofline, elles atteignent des performances généralement supérieures à 50% de la puissance de calcul maximale atteignable. Les faibles temps de calculs ainsi obtenus incitent à traiter des résolutions importantes. Cependant, elles sont rapidement limitées par les tailles des différents niveaux de mémoire des cartes graphiques. C’est pourquoi, nous avons développé une version multi-GPU de la méthode dont les performances, en termes de scalabilité, ont été analysées dans le chapitre 6. Les résultats ont montré un fort potentiel de réduction du temps de calcul induit par les communications entre GPU sous réserve de leur optimisation et de leur recouvrement par des calculs. Cette implémentation multi-GPU nous permet d’atteindre l’objectif principal de réalisation de simulations de transport d’un scalaire passif dans un écoulement turbulent en exploitant une méthode hybride et une architecture hétérogène multi-CPU et multi-GPU. Nous avons proposé une approche permettant d’augmenter l’occupation des nœuds de calcul basée sur un parallélisme par tâches. Elle conduit à la résolution simultanée du transport du scalaire sur plusieurs cartes graphiques et de l’écoulement sur les cœurs CPU disponibles. Malgré des temps de communications entre GPU relativement importants, le calcul du transport du scalaire reste généralement plus rapide que celui de l’écoulement. Une limite à cette stratégie est que la résolution de deux sous-problèmes sur des architectures différentes peut conduire à un déséquilibre de charge qu’il est possible d’ajuster par une modification des paramètres des méthodes et des tailles de grilles. De nombreuses perspectives se dégagent des aspects mathématiques, numériques et applicatifs de ce travail. Au niveau de la méthode numérique, il serait intéressant d’étendre l’étude de montée en ordre aux schémas d’intégration des trajectoires des particules et de splitting dimensionnel. Pour les premiers, nous avons réalisé l’analyse de consistance pour des schémas d’advection d’ordre 1 et 2 ainsi que l’analyse de stabilité au premier ordre. Une poursuite de ces études pour le cas de schémas d’ordres plus élevés serait nécessaire afin de s’assurer de la validité de l’utilisation de schémas de type Runge-Kutta d’ordre 4, par exemple. En ce qui concerne le splitting, nous avons essentiellement employé un splitting de Strang d’ordre 2. La mise en œuvre d’un splitting d’ordre 3 ou 4 serait intéressante du point de vue numérique et algorithmique. D’autre part, lors de l’étude de la construction de formules de remaillage d’ordre élevés Λp,r, nous avons tenté, de produire des formules diffusives, sans obtenir de résultats satisfaisants. En pratique de telles formules ont été obtenues seulement à partir des noyaux Λ2,r. L’intérêt de ces formules serait de réaliser une diffusion de la quantité transportée par les particules directement dans l’étape de remaillage et ainsi d’éviter un second calcul dédié. En effet, le traitement de la diffusion du scalaire passif, par différences finies dans nos simulations, nécessite un parcours de l’ensemble des données en lecture et écriture dont la suppression conduirait à une diminution du temps de calcul. Cette amélioration serait vraisemblablement significative sur GPU mais devrait également être sensible sur des architectures CPU plus classiques. La méthode de construction des formules, développée dans le chapitre 2, consiste à résoudre un système linéaire dont les inconnues sont les coefficients polynômiaux. Ce système traduit l’expression des différentes contraintes parmi lesquelles la conservation des p premiers moments. Une étude plus fine que la simple modification de la 136contrainte de conservation du moment d’ordre 2 serait nécessaire pour la prise en compte de la diffusion. Du point de vue numérique, une perspective se dégage directement de l’analyse des performances de la résolution du transport de scalaire dans un cas multi-GPU. Comme nous l’avons souligné dans le chapitre 6, les communications entre cartes graphiques font état d’un temps de traitement assez long comparativement au temps de calcul total. Une réduction de ce temps de traitement est envisageable en deux étapes. Dans une première étape, il serait intéressant d’optimiser les transferts de données entre GPU en utilisant une approche similaire à celle employée dans la librairie MPI-ACC (Aji et al., 2012). L’idée est de traiter les messages en plusieurs envois successifs. Ce traitement par blocs en chaîne devrait permettre un recouvrement des différentes étapes et ainsi accélérer la communication. En effet, pendant l’envoi du message correspondant à un bloc, il est possible de réaliser la copie depuis l’hôte vers la carte de destination du bloc précédent ainsi que celle du bloc suivant depuis la carte vers l’hôte émetteur. Dans une seconde étape, un recouvrement de ces transferts par des calculs est possible en réalisant, par exemple, le calcul en deux passes. Les calculs locaux, indépendants des données distantes, peuvent être réalisés pendant leurs transferts. En ce qui concerne l’implémentation multi-GPU, l’occupation des ressources CPU est un problème délicat pour lequel nous avons proposé une solution dans le chapitre 6. En effet, les nœuds de calculs présentent généralement plus de cœurs CPU que de GPU et comme notre implémentation se base sur l’exploitation d’une carte par un seul processus, cela conduit à une inutilisation des cœurs restants. L’approche basée sur un parallélisme par tâches consiste, dans notre application, à réaliser le calcul de l’écoulement sur ces cœurs CPU disponibles. Sur l’exemple d’utilisation de la machine Froggy, le fluide est calculé sur 4 des 7 cœurs disponibles, soit une occupation de 5/8 = 62.5%. Une occupation maximale a été obtenue artificiellement en distribuant cette tâche sur l’ensemble des 7 cœurs en ajustant la taille de la grille de résolution. De même, une tentative de placement de 8 processus pour cette même tâche sur les 8 cœurs physiques sur lesquels est ajouté un 9e processus pour le calcul du scalaire a conduit à des performances largement dégradées. Nous atteignons ainsi les limites de notre parallélisme par tâche qui, par choix de simplification des communications, se restreint à la possibilité d’une seule tâche par processus. Cependant, une autre stratégie pour l’augmentation de l’occupation est envisageable. Dans le cas des octocœurs utilisés, les meilleurs résultats ont été obtenus en employant 1 cœur CPU associé à 1 GPU pour le calcul du scalaire et 4 cœurs CPU pour le calcul de l’écoulement. Les trois cœurs restants peuvent être assignés à d’autres tâches que celles de calcul telles que des opérations de post-traitement, de sorties sur fichiers ou encore pour la gestion de reprises des calculs en cours de simulation. D’autre part, l’implémentation que nous avons proposé est basée exclusivement sur un parallélisme par envoi de messages pour les tâches n’utilisant pas de GPU. Une perspective intéressante serait d’envisager l’ajout d’un paradigme à mémoire partagée pour l’exploitation des cœurs CPU. Ainsi, les cœurs d’un même nœuds seraient utilisés à travers un parallélisme spécifique tel que OpenMP, ou même OpenCL. Un parallélisme à trois niveaux serait donc obtenu en combinant l’utilisation de MPI entre les nœuds, OpenMP (ou OpenCL) pour les cœurs CPU d’un même nœud et OpenCL pour les GPU. La conception a été réalisée dans le but d’obtenir un code robuste dans lequel ces modifications peuvent 137Conclusion générale être apportées sans impacter l’ensemble de la librairie et de manière transparente pour l’utilisateur. Enfin, une perspective à ce travail, en termes d’application, serait de réaliser des simulations de transport de scalaire actif ayant un effet sur l’écoulement. Par exemple, lorsque le scalaire représente une densité dans un écoulement de fluide multiphasique. Ce problème se modélise par une équation de transport de la densité dont la vitesse est donnée par les équations de Navier-Stokes. Dans ces dernières un terme barotrope apparaît pour permettre la prise en compte de la densité comme force extérieure au modèle. En pratique la résolution du transport de la densité est toujours envisagée sur GPU et celle du terme barotrope sera mise en œuvre soit directement sur GPU soit sur CPU, selon la nature de la méthode numérique utilisée. Dans le premier cas, cela implique une modification du champ de vitesse sur GPU et donc son transfert vers le CPU pour la résolution de l’écoulement. Dans le second cas, un simple transfert de la densité vers le CPU est nécessaire. L’intérêt de cette application serait de conserver le caractère multiéchelle du problème en utilisant des grilles de résolutions différentes pour l’écoulement et la densité. Dans ce cas, il serait nécessaire de filtrer la densité, après son transport, à l’échelle de l’écoulement. Ce filtre serait réalisé sur les GPU afin de ne transférer vers les CPU qu’une densité filtrée, donc de taille réduite. 138Bibliographie Aji, A. M., J. Dinan, D. Buntinas, P. Balaji, W.-c. Feng, K. R. Bisset et R. Thakur (2012). « MPI-ACC: An Integrated and Extensible Approach to Data Movement in Acceleratorbased Systems ». IEEE 14th International Conference on High Performance Computing and Communication & IEEE 9th International Conference on Embedded Software and Systems. Aji, A. M., L. S. Panwar, F. Ji, M. Chabbi, K. Murthy, P. Balaji, K. R. Bisset, J. Dinan, W.-c. Feng, J. Mellor-Crummey, X. Ma et R. Thakur (2013). « On the Efficacy of GPUIntegrated MPI for Scientific Applications ». Proceedings of the 22nd international symposium on High-performance parallel and distributed computing. Baqais, A., M. Assayony, A. Khan et M. Al-Mouhamed (2013). « Bank Conflict-Free Access for CUDA-Based Matrix Transpose Algorithm on GPUs ». International Conference on Computer Applications Technology. Batchelor, G. K. (1958). « Small-scale variation of convected quantities like temperature in turbulent fluid Part 1. General discussion and the case of small conductivity ». Journal of Fluid Mechanics 5.1. Bergdorf, M., G.-H. Cottet et P. Koumoutsakos (2005). « Multilevel Adaptive Particle Methods for Convection-Diffusion Equations ». Multiscale Modeling & Simulation 4.1. Bergdorf, M. et P. Koumoutsakos (2006). « A Lagrangian Particle-Wavelet Method ». Multiscale Modeling & Simulation 5.3. Bergman, K., S. Borkar, D. Campbell, W. Carlson, W. Dally, M. Denneau, P. Franzon, W. Harrod, K. Hill, J. Hiller, S. Karp, S. Keckler, D. Klein, R. Lucas, M. Richards, A. Scarpelli, S. Scott, A. Snavely, T. Sterling, R. S. Williams et K. Yelick (2008). ExaScale Computing Study : Technology Challenges in Achieving Exascale Systems. Rapport technique. DARPA IPTO. Büyükkeçeci, F., O. Awile et I. F. Sbalzarini (2012). « A portable OpenCL implementation of generic particle–mesh and mesh–particle interpolation in 2D and 3D ». Parallel Computing 39.2. Canuto, C., M. Y. Hussaini, A. Quarteroni et T. A. Zang (1987). Spectral Methods in Fluid Dynamics (Scientific Computation). Chen, S. et G. D. Doolen (1998). « Lattice boltzmann method for fluid flows ». Annual Review of Fluid Mechanics 30.0. Cheng, H., L. Greengard et V. Rokhlin (1999). « A Fast Adaptive Multipole Algorithm in Three Dimensions ». Journal of Computational Physics 155.2. Chorin, A. J. (1968). « Numerical Solution of the Navier-Stokes Equations ». Mathematics of Computation 22. 139Bibliographie Chorin, A. J. (1973). « Numerical study of slightly viscous flow ». Journal of Fluid Mechanics 57.4. Cocle, R., G. Winckelmans et G. Daeninck (2008). « Combining the vortex-in-cell and parallel fast multipole methods for efficient domain decomposition simulations ». Journal of Computational Physics 227.21. Coquerelle, M. et G.-H. Cottet (2008). « A vortex level set method for the two-way coupling of an incompressible fluid with colliding rigid bodies ». Journal of Computational Physics 227.21. Cottet, G.-H. (1991). « Particle-grid domain decomposition methods for the Navier-Stokes equations in exterior domains ». Lectures in Applied Mathematics 28. Cottet, G.-H. et S. Mas-Gallic (1990). « A particle method to solve the Navier-Stokes system ». Numerische Mathematik 57.1. Cottet, G.-H., P. Koumoutsakos et M. L. Ould Salihi (2000). « Vortex Methods with Spatially Varying Cores ». Journal of Computational Physics 162.1. Cottet, G.-H., B. Michaux, S. Ossia et G. VanderLinden (2002). « A Comparison of Spectral and Vortex Methods in Three-Dimensional Incompressible Flows ». Journal of Computational Physics 175.2. Cottet, G.-H. et L. Weynans (2006). « Particle methods revisited: a class of high order finite-difference methods ». Comptes Rendus Mathematique 343.1. Cottet, G.-H., G. Balarac et M. Coquerelle (2009a). « Subgrid particle resolution for the turbulent transport of a passive scalar ». Advances in Turbulence XII, Proceedings of the 12th EUROMECH European Turbulence Conference, September, 2009 132.1. Cottet, G.-H. et A. Magni (2009b). « TVD remeshing formulas for particle methods ». Comptes Rendus de l’Academie des Sciences Paris Serie I 34.23. Cottet, G.-H., J.-M. Etancelin, F. Perignon et C. Picard (2014). « High order semi-lagrangian particles for transport equations: numerical analysis and implementations issues. » ESAIM: Mathematical Modelling and Numerical Analysis 48.4. Crouseilles, N., T. Respaud et E. Sonnendrücker (2009). « A forward semi-Lagrangian method for the numerical solution of the Vlasov equation ». Computer Physics Communications 180.10. Degond, P. et S. Mas-Gallic (1989). « The Weighted Particle Method for ConvectionDiffusion Equations Part 1 : The Case of an Isotropie Viscosity ». Mathematics of Computation 53.188. Dolbeau, R., S. Bihan et F. Bodin (2007). « HMPP: A hybrid multi-core parallel programming environment ». Workshop on General Purpose Processing on Graphics Processing Units. Dongarra, J., I. Foster, G. Fox, W. Gropp, K. Kennedy, L. Torczon et A. White (2003). The Sourcebook of Parallel Computing. Dongarra, J., P. Beckman, T. Moore, P. Aerts, G. Aloisio, J.-C. Andre, D. Barkai, J.- Y. Berthou, T. Boku, B. Braunschweig, F. Cappello, B. Chapman, A. Choudhary, S. Dosanjh, T. Dunning, S. Fiore, A. Geist, B. Gropp, R. Harrison, M. Hereld, M. Heroux, A. Hoisie, K. Hotta, Y. Ishikawa, F. Johnson, S. Kale, R. Kenway, D. Keyes, B. Kramer, J. Labarta, A. Lichnewsky, T. Lippert, B. Lucas, B. Maccabe, S. Matsuoka, P. Messina, P. Michielse, B. Mohr, M. S. Mueller, W. E. Nagel, H. Nakashima, M. E. Papka, D. Reed, M. Sato, E. Seidel, J. Shalf, D. Skinner, M. Snir, T. Sterling, R. Stevens, F. Streitz, B. Sugar, S. Sumimoto, W. Tang, J. Taylor, R. Thakur, A. Trefethen, M. Valero, A. van der Steen, J. Vetter, P. Williams, R. Wisniewski et K. Yelick (2011). « The Internatio- 140Bibliographie nal Exascale Software Project roadmap ». International Journal of High Performance Computing Applications 25.1. Dongarra, J., J. Hittinger, J. Bell, L. Chac\’{o}n, R. Falgout, M. Heroux, P. Hovland, E. Ng, C. Webster et S. Wild (2014). Applied Mathematics Research for Exascale Computing. Rapport technique. U.S. Department of Energy, Office of Science, Advanced Scientific Computing Research Program. Fermi, E., J. Pasta et S. Ulam (1955). Studies of nonlinear problems. Rapport technique. Gotoh, T., S. Hatanaka et H. Miura (2012). « Spectral compact difference hybrid computation of passive scalar in isotropic turbulence ». Journal of Computational Physics 231.21. Green500 (2014). http://www.green500.org/. Gustafson, J. L. (1988). « Reevaluating Amdahl’s Law ». Communications of the ACM 31.5. Higham, N. J. (2002). Accuracy and Stability of Numerical Algorithms. Second edi. SIAM. Ishiyama, T., K. Nitadori et J. Makino (2012). « 4.45 Pflops astrophysical N-body simulation on K computer - The gravitational trillion-body problem ». International Conference for High Performance Computing, Networking, Storage and Analysis, SC. Jansson, N., J. Hoffman et M. Nazarov (2011). « Adaptive simulation of turbulent flow past a full car model ». State of the Practice Reports on - SC ’11 0. Khronos (2014). The OpenCL Specification, version 2.0. Klöckner, A., N. Pinto, Y. Lee, B. Catanzaro, P. Ivanov et A. Fasih (2012). « PyCUDA and PyOpenCL: A Scripting-Based Approach to GPU Run-Time Code Generation ». Parallel Computing 38.3. Kong, X., M. C. Huang, C. Ren et V. K. Decyk (2011). « Particle-in-cell simulations with charge-conserving current deposition on graphic processing units ». Journal of Computational Physics 230.4. Koumoutsakos, P. (1997). « Inviscid Axisymmetrization of an Elliptical Vortex ». Journal of Computational Physics 138.2. Koumoutsakos, P. et A. Leonard (1995). « High-resolution simulations of the flow around an impulsively started cylinder using vortex methods ». Journal of Fluid Mechanics 296. Kuczaj, A., E. Komen et M. Loginov (2010). « Large-Eddy Simulation study of turbulent mixing in a T-junction ». Nuclear Engineering and Design 240.9. Labbé, S., J. Laminie et V. Louvet (2004). Méthodologie et environment de développement orientés objets : de l’analyse mathématique à la programmation. Lagaert, J.-B., G. Balarac, G.-H. Cottet et P. Bégou (2012). « Particle method: an efficient tool for direct numerical simulations of a high Schmidt number passive scalar in turbulent flow ». Center for Turbulence Research Proceedings of the Summer Program 2012. 1959. Lagaert, J.-B., G. Balarac et G.-H. Cottet (2014). « Hybrid spectral-particle method for the turbulent transport of a passive scalar ». Journal of Computational Physics 260.0. Leonard, A. (1980). « Vortex methods for flow simulation ». Journal of Computational Physics 37.3. Lesieur, M. (2008). Turbulence in fluids. Lesieur, M., O. Métais et P. Comte (2005). Large-Eddy Simulations of Turbulence. Liu, M. B. et G. R. Liu (2010). « Smoothed Particle Hydrodynamics (SPH): an Overview and Recent Developments ». Archives of Computational Methods in Engineering 17.1. Logg, A., K.-A. Mardal et G. Wells (2012). Automated Solution of Differential Equations by the Finite Element Method. 141Bibliographie Magni, A. et G.-H. Cottet (2012). « Accurate, non-oscillatory, remeshing schemes for particle methods ». Journal of Computational Physics 231.1. Mernik, M., J. Heering et A. M. Sloane (2005). « When and how to develop domain-specific languages ». ACM Computing Surveys 37.4. Michioka, T. et F. K. Chow (2008). « High-Resolution Large-Eddy Simulations of Scalar Transport in Atmospheric Boundary Layer Flow over Complex Terrain ». Journal of Applied Meteorology and Climatology 47.12. Monaghan, J. (1985). « Extrapolating B splines for interpolation ». Journal of Computational Physics 60.2. Moore, G. E. (1998). « Cramming More Components onto Integrated Circuits ». Proceedings of the IEEE. Tome 86. 1. Moore, G. E. (2005). Excerpts from A Conversation with Gordon Moore : Moore’s Law. Murtis, J., J. S. Elkinton et R. T. Cardé (1992). « Odor plumes and how insects use them ». Annual review of entomology 37.1. Nvidia (2012a). Kepler GK110. Rapport technique. Nvidia (2012b). Tesla K20 GPU accelerator, board specification. Rapport technique. Nvidia (2014). Cuda C programming guide. OpenACC (2013). The OpenACC Application Programming Interface. Ould Salihi, M. L. (1998). « Couplage de méthodes numériques en simulation directe d’écoulements incompressibles ». Thèse de doctorat. Université Joseph Fourier. Ould Salihi, M. L., G.-H. Cottet et M. El Hamraoui (2000). « Blending finite-difference and vortex methods for incompressible flow computations ». SIAM Journal on Scientific Computing 22.5. Pérez, F., B. E. Granger et J. D. Hunter (2011). « Python: An Ecosystem for Scientific Computing ». Computing in Science & Engineering 13.2. Pitsch, H., O. Desjardins, G. Balarac et M. Ihme (2008). « Large-eddy simulation of turbulent reacting flows ». Progress in Aerospace Sciences 44.6. Rashed, G. et R. Ahsan (2012). « Python in computational science: applications and possibilities ». International Journal of Computer Applications 46.20. Rees, W. M. van, A. Leonard, D. I. Pullin et P. Koumoutsakos (2011). « A comparison of vortex and pseudo-spectral methods for the simulation of periodic vortical flows at high Reynolds numbers ». Journal of Computational Physics 230.8. Rodgers, D. P. (1985). « Improvements in Multiprocessor System Design ». SIGARCH Computer Architecture News 13.3. Rossi, F., P. Londrillo, A. Sgattoni, S. Sinigardi et G. Turchetti (2012). « Towards robust algorithms for current deposition and dynamic load-balancing in a GPU particle in cell code ». AIP Conference Proceedings. Tome 184. Rossinelli, D. et P. Koumoutsakos (2008). « Vortex methods for incompressible flow simulations on the GPU ». The Visual Computer 24.7-9. Rossinelli, D., M. Bergdorf, G.-H. Cottet et P. Koumoutsakos (2010). « GPU accelerated simulations of bluff body flows using vortex particle methods ». Journal of Computational Physics 229.9. Rossinelli, D., C. Conti et P. Koumoutsakos (2011). « Mesh-particle interpolations on graphics processing units and multicore central processing units. » Philosophical transactions. Series A, Mathematical, physical, and engineering sciences 369.1944. Rossinelli, D., B. Hejazialhosseini, P. Hadjidoukas, C. Bekas, A. Curioni, A. Bertsch, S. Futral, S. J. Schmidt, N. A. Adams, P. Koumoutsakos et L. Livermore (2013). « 11 142Bibliographie PFLOP/s Simulations of Cloud Cavitation Collapse ». Proceedings of the International Conference on High Performance Computing, Networking, Storage and Analysis (SC ’13). Ruetsch, G. et P. Micikevicius (2009). Optimizing Matrix Transpose in CUDA. Rapport technique January. NVIDIA. Sagaut, P. (2006). Large Eddy Simulation for Incompressible Flows - An introduction. Sbalzarini, I. F., J. H. Walther, M. Bergdorf, S. E. Hieber, E. M. Kotsalis et P. Koumoutsakos (2006). « PPM – A highly efficient parallel particle–mesh library for the simulation of continuum systems ». Journal of Computational Physics 215.2. Schoenberg, I. J. (1946). « Contributions to the problem of approximation of equidistant data by analytic functions ». Quarterly of Applied Mathematics 4.2. Sethian, J. a. et P. Smereka (2003). « Level set methods for fluid interfaces ». Annual Review of Fluid Mechanics 35.1. Shalf, J., S. Dosanjh et J. Morrison (2010). « Exascale Computing Technology Challenges ». High Performance Computing for Computational Science–VECPAR 2010. Shraiman, B. I. et E. D. Siggia (2000). « Scalar turbulence ». Nature 405.6787. Staniforth, A. et J. Côté (1991). « Semi-Lagrangian Integration Schemes for Atmospheric Models - A Review ». Monthly weather review 119.9. Stantchev, G., W. Dorland et N. Gumerov (2008). « Fast parallel Particle-To-Grid interpolation for plasma PIC simulations on the GPU ». Journal of Parallel and Distributed Computing 68.10. Subramaniam, B., W. Saunders, T. Scogland et W.-c. Feng (2013). « Trends in energyefficient computing: A perspective from the Green500 ». 4th International Green Computing Conference. Taylor, J. R. et R. Stocker (2012). « Trade-offs of chemotactic foraging in turbulent water. » Science 338.6107. Temam, R. (1968). « Une méthode d’approximation de la solution des équations de NavierStokes ». Bulletin de la Société Mathématique de France 96. Top500 (2014). http://www.top500.org/. Tryggvason, G., R. Scardovelli et S. Zaleski (2011). Direct Numerical Simulations of Gas–Liquid Multiphase Flows. Cambridge : Cambridge University Press. Volkov, V. (2010). « Better performance at lower occupancy ». Proceedings of the GPU Technology Conference, Wang, H., S. Potluri, M. Luo, A. K. Singh, S. Sur et D. K. Panda (2011). « MVAPICH2- GPU: optimized GPU to GPU communication for InfiniBand clusters ». Computer Science - Research and Development 26.3-4. Weynans, L. et A. Magni (2013). « Consistency, accuracy and entropic behaviour of remeshed particle methods ». ESAIM: Mathematical Modelling and Numerical Analysis 47.1. Williams, S., A. Waterman et D. Patterson (2009). « Author : Roofline : An Insightful Visual Performance Model for Floating-Point Programs and Multicore Architectures ». Communications of the ACM 52.4. Yokota, R., L. A. Barba, T. Narumi et K. Yasuoka (2013). « Petascale turbulence simulation using a highly parallel fast multipole method on GPUs ». Computer Physics Communications 184.3. 143A. Formules de remaillage de type Λp,r Cette annexe décrit l’ensemble des formules de remaillage de type Λp,r construites par la méthode décrite dans la section 2.2. Les caractéristiques des formules sont résumées dans le tableau A.1. Les formules sont regroupées en fonction de la largeur de leur support et pour chaque noyau, nous donnons leur expression. Les poids de remaillage sont également donnés et exprimés en fonction de la distance y de la particule au point de grille le plus proche à gauche. A.1. Formules de type Λ2,r y w0 w1 w2 w3 Figure A.1. – Poids de remaillage pour les formules de type Λ2,r Formule Λ2,1 Λ2,1(x) = M0 4 (x) =    1 − 5 2 |x| 2 + 3 2 |x| 3 0 6 |x| < 1 2 − 4|x| + 5 2 |x| 2 − 1 2 |x| 3 1 6 |x| < 2 0 2 6 |x| (A.1) w[0] = (y * (y * (-y + 2.) - 1.)) / 2. w[1] = (y * y * (3. * y - 5.) + 2.) / 2. w[2] = (y * (y * (-3. * y + 4.) + 1.)) / 2. w[3] = (y * y * (y - 1.)) / 2. 145A. Formules de remaillage de type Λp,r Nom Moment maximal conservé Régularité Support Degré Λ2,1 2 C 1 [−2; 2] 3 Λ2,2 2 C 2 [−2; 2] 5 Λ2,3 2 C 3 [−2; 2] 7 Λ2,4 2 C 4 [−2; 2] 9 Λ4,2 4 C 2 [−3; 3] 5 Λ4,3 4 C 3 [−3; 3] 7 Λ4,4 4 C 4 [−3; 3] 9 Λ6,3 6 C 3 [−4; 4] 7 Λ6,4 6 C 4 [−4; 4] 9 Λ6,5 6 C 5 [−4; 4] 11 Λ6,6 6 C 6 [−4; 4] 13 Λ8,4 8 C 4 [−5; 5] 9 Tableau A.1. – Comparatif des formules de remaillage de type Λp,r. Formule Λ2,2 Λ2,2(x) =    1 − |x| 2 − 9 2 |x| 3 + 15 2 |x| 4 − 3|x| 5 0 6 |x| < 1 −4 + 18|x| − 29|x| 2 + 43 2 |x| 3 − 15 2 |x| 4 + |x| 5 1 6 |x| < 2 0 2 6 |x| (A.2) w[0] = (y * (y * (y * (y * (2. * y - 5.) + 3.) + 1.) - 1.)) / 2. w[1] = (y * y * (y * (y * (-6. * y + 15.) - 9.) - 2.) + 2.) / 2. w[2] = (y * (y * (y * (y * (6. * y - 15.) + 9.) + 1.) + 1.)) / 2. w[3] = (y * y * y * (y * (-2. * y + 5.) - 3.)) / 2. 146A.2. Formules de type Λ 4,r Formule Λ2,3 Λ2,3(x) = 1 − |x|2 − 15|x|4 + 752 |x|5 − 632 |x|6 + 9|x|7 0 6 |x| < 1 32 − 168|x| + 376|x|2 − 460|x|3 + 330|x|4 − 2772 |x|5 + 632 |x|6 − 3|x|7 1 6 |x| < 2 0 2 6 |x| (A.3) w[0] = (y * (y * (y * y * (y * (y * (-6. * y + 21.) - 25.) + 10.) + 1.) - 1.)) / 2. w[1] = (y * y * (y * y * (y * (y * (18. * y - 63.) + 75.) - 30.) - 2.) + 2.) / 2. w[2] = (y * (y * (y * y * (y * (y * (-18. * y + 63.) - 75.) + 30.) + 1.) + 1.)) / 2. w[3] = (y * y * y * y * (y * (y * (6. * y - 21.) + 25.) - 10.)) / 2. Formule Λ2,4 Λ2,4(x) = 1 − |x|2 − 1052 |x|5 + 3572 |x|6 − 231|x|7 + 135|x|8 − 30|x|9 0 6 |x| < 1 −208 + 1432|x| − 4304|x|2 + 7420|x|3 − 8085|x|4 +11543 2 |x|5 − 5397 2 |x|6 + 797|x|7 − 135|x|8 + 10|x|9 1 6 |x| < 2 0 2 6 |x| (A.4) w[0] = (y * (y * (y * y * y * (y * (y * (y * (20. * y - 90.) + 154.) - 119.) + 35.) + 1.) - 1.)) / 2. w[1] = (y * y * (y * y * y * (y * (y * (y * (-60. * y + 270.) - 462.) + 357.) - 105.) - 2.) + 2.) / 2. w[2] = (y * (y * (y * y * y * (y * (y * (y * (60. * y - 270.) + 462.) - 357.) + 105.) + 1.) + 1.)) / 2. w[3] = (y * y * y * y * y * (y * (y * (y * (-20. * y + 90.) - 154.) + 119.) - 35.)) / 2. 147A. Formules de remaillage de type Λp,r y w 0 w 1 w 2 w 3 w 4 w 5 Figure A.2. – Poids de remaillage pour les formules de type Λ4,r A.2. Formules de type Λ4,r Formule Λ4,2 Λ4,2(x) = M06(x) = 1 − 54 |x|2 − 3512 |x|3 + 214 |x|4 − 2512 |x|5 0 6 |x| < 1 −4 + 754 |x| − 2458 |x|2 + 545 24 |x|3 − 638 |x|4 + 2524 |x|5 1 6 |x| < 2 18 − 1534 |x| + 2558 |x|2 − 313 24 |x|3 + 218 |x|4 − 524 |x|5 2 6 |x| < 3 0 3 6 |x| (A.5) w[0] = (y * (y * (y * (y * (-5. * y + 13.) - 9.) - 1.) + 2.)) / 24. w[1] = (y * (y * (y * (y * (25. * y - 64.) + 39.) + 16.) - 16.)) / 24. w[2] = (y * y * (y * (y * (-50. * y + 126.) - 70.) - 30.) + 24.) / 24. w[3] = (y * (y * (y * (y * (50. * y - 124.) + 66.) + 16.) + 16.)) / 24. w[4] = (y * (y * (y * (y * (-25. * y + 61.) - 33.) - 1.) - 2.)) / 24. w[5] = (y * y * y * (y * (5. * y - 12.) + 7.)) / 24. 148A.2. Formules de type Λ 4,r Formule Λ4,3 Λ4,3(x) = 1 − 54 |x|2 − 283 |x|4 + 1456 |x|5 − 245 12 |x|6 + 356 |x|7 0 6 |x| < 1 31 − 1945 12 |x| + 2905 8 |x|2 − 5345 12 |x|3 + 1281 4 |x|4 − 1615 12 |x|5 + 2458 |x|6 − 3512 |x|7 1 6 |x| < 2 −297 + 3501 4 |x| − 8775 8 |x|2 + 3029 4 |x|3 − 3731 12 |x|4 + 911 12 |x|5 − 245 24 |x|6 + 712 |x|7 2 6 |x| < 3 0 3 6 |x| (A.6) w[0] = (y * (y * (y * (y * (y * (y * (14. * y - 49.) + 58.) - 22.) - 2.) - 1.) + 2.)) / 24. w[1] = (y * (y * (y * (y * (y * (y * (-70. * y + 245.) - 290.) + 111.) + 4.) + 16.) - 16.)) / 24. w[2] = (y * y * (y * y * (y * (y * (140. * y - 490.) + 580.) - 224.) - 30.) + 24.) / 24. w[3] = (y * (y * (y * (y * (y * (y * (-140. * y + 490.) - 580.) + 226.) - 4.) + 16.) + 16.)) / 24. w[4] = (y * (y * (y * (y * (y * (y * (70. * y - 245.) + 290.) - 114.) + 2.) - 1.) - 2.)) / 24. w[5] = (y * y * y * y * (y * (y * (-14. * y + 49.) - 58.) + 23.)) / 24. Formule Λ4,4 Λ4,4(x) = 1 − 54 |x|2 + 14 |x|4 − 1003 |x|5 + 4554 |x|6 − 2952 |x|7 + 3454 |x|8 − 1156 |x|9 0 6 |x| < 1 −199 + 5485 4 |x| − 32975 8 |x|2 + 28425 4 |x|3 − 61953 8 |x|4 + 33175 6 |x|5 −20685 8 |x|6 + 3055 4 |x|7 − 1035 8 |x|8 + 115 12 |x|9 1 6 |x| < 2 5913 − 89235 4 |x| + 297585 8 |x|2 − 143895 4 |x|3 + 177871 8 |x|4 − 54641 6 |x|5 +19775 8 |x|6 − 1715 4 |x|7 + 3458 |x|8 − 2312 |x|9 2 6 |x| < 3 0 3 6 |x| (A.7) w[0] = (y * (y * (y * (y * (y * (y * (y * (y * (-46. * y + 207.) - 354.) + 273.) - 80.) + 1.) - 2.) - 1.) + 2.)) / 24. w[1] = (y * (y * (y * (y * (y * (y * (y * (y * (230. * y - 1035.) + 1770.) - 1365.) + 400.) - 4.) + 4.) + 16.) - 16.)) / 24. w[2] = (y * y * (y * y * (y * (y * (y * (y * (-460. * y + 2070.) - 3540.) + 2730.) - 800.) + 6.) - 30.) 149A. Formules de remaillage de type Λp,r + 24.) / 24. w[3] = (y * (y * (y * (y * (y * (y * (y * (y * (460. * y - 2070.) + 3540.) - 2730.) + 800.) - 4.) - 4.) + 16.) + 16.)) / 24. w[4] = (y * (y * (y * (y * (y * (y * (y * (y * (-230. * y + 1035.) - 1770.) + 1365.) - 400.) + 1.) + 2.) - 1.) - 2.)) / 24. w[5] = (y * y * y * y * y * (y * (y * (y * (46. * y - 207.) + 354.) - 273.) + 80.)) / 24. A.3. Formules de type Λ6,r y w 0 w 1 w 2 w 3 w 4 w 5 w 6 w 7 Figure A.3. – Poids de remaillage pour les formules de type Λ6,r Formule Λ6,3 Λ6,3(x) = 1 − 4936 |x|2 − 959 144 |x|4 + 2569 144 |x|5 − 727 48 |x|6 + 623 144 |x|7 0 6 |x| < 1 1385 − 8617 60 |x| + 12873 40 |x|2 − 7912 |x|3 + 4557 16 |x|4 − 9583 80 |x|5 + 2181 80 |x|6 − 623 240 |x|7 1 6 |x| < 2 −440 + 25949 20 |x| − 117131 72 |x|2 + 2247 2 |x|3 − 66437 144 |x|4 + 81109 720 |x|5 − 727 48 |x|6 + 623 720 |x|7 2 6 |x| < 3 3632 5 − 7456 5 |x| + 58786 45 |x|2 − 633|x|3 + 26383 144 |x|4 − 22807 720 |x|5 + 727 240 |x|6 − 89 720 |x|7 3 6 |x| < 4 0 4 6 |x| (A.8) w[0] = (y * (y * (y * (y * (y * (y * (-89. * y + 312.) - 370.) + 140.) + 15.) + 4.) - 12.)) / 720. w[1] = (y * (y * (y * (y * (y * (y * (623. * y - 2183.) + 2581.) - 955.) - 120.) - 54.) + 108.)) / 720. w[2] = (y * (y * (y * (y * (y * (y * (-1869. * y + 6546.) - 7722.) + 2850.) + 195.) + 540.) - 540.)) / 720. w[3] = (y * y * (y * y * (y * (y * (3115. * y - 10905.) + 12845.) - 4795.) - 980.) + 720.) / 720. 150A.3. Formules de type Λ6,r w[4] = (y * (y * (y * (y * (y * (y * (-3115. * y + 10900.) - 12830.) + 4880.) - 195.) + 540.) + 540.)) / 720. w[5] = (y * (y * (y * (y * (y * (y * (1869. * y - 6537.) + 7695.) - 2985.) + 120.) - 54.) - 108.)) / 720. w[6] = (y * (y * (y * (y * (y * (y * (-623. * y + 2178.) - 2566.) + 1010.) - 15.) + 4.) + 12.)) / 720. w[7] = (y * y * y * y * (y * (y * (89. * y - 311.) + 367.) - 145.)) / 720. Formule Λ6,4 Λ6,4(x) =    1 − 4936 |x| 2 + 7 18 |x| 4 − 3521 144 |x| 5 + 12029 144 |x| 6 − 15617 144 |x| 7 + 1015 16 |x| 8 − 1015 72 |x| 9 0 6 |x| < 1 −877 5 + 72583 60 |x| − 145467 40 |x| 2 + 18809 3 |x| 3 − 54663 8 |x| 4 + 390327 80 |x| 5 −182549 80 |x| 6 + 161777 240 |x| 7 − 1827 16 |x| 8 + 203 24 |x| 9 1 6 |x| < 2 8695 − 656131 20 |x| + 3938809 72 |x| 2 − 158725 3 |x| 3 + 2354569 72 |x| 4 − 9644621 720 |x| 5 +523589 144 |x| 6 − 454097 720 |x| 7 + 1015 16 |x| 8 − 203 72 |x| 9 2 6 |x| < 3 −142528 5 + 375344 5 |x| − 3942344 45 |x| 2 + 178394 3 |x| 3 − 931315 36 |x| 4 + 5385983 720 |x| 5 −1035149 720 |x| 6 + 127511 720 |x| 7 − 203 16 |x| 8 + 2972 |x| 9 3 6 |x| < 4 0 4 6 |x| (A.9) w[0] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-1006. * y + 5533.) - 12285.) + 13785.) - 7829.) + 1803.) - 3.) - 5.) + 15.) + 4.) - 12.)) / 720. w[1] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (7042. * y - 38731.) + 85995.) - 96495.) + 54803.) - 12620.) + 12.) + 60.) - 120.) - 54.) + 108.)) / 720. w[2] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-21126. * y + 116193.) - 257985.) + 289485.) - 164409.) + 37857.) - 15.) - 195.) + 195.) + 540.) - 540.)) / 720. w[3] = (y * y * (y * y * (y * y * (y * (y * (y * (y * (35210. * y - 193655.) + 429975.) - 482475.) + 274015.) - 63090.) + 280.) - 980.) + 720.) / 720. w[4] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-35210. * y + 193655.) - 429975.) + 482475.) - 274015.) + 63085.) + 15.) - 195.) - 195.) + 540.) + 540.)) / 720. w[5] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (21126. * y - 116193.) + 257985.) - 289485.) + 164409.) - 37848.) - 12.) + 60.) + 120.) - 54.) - 108.)) / 720. w[6] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-7042. * y + 38731.) - 85995.) + 96495.) - 54803.) 151A. Formules de remaillage de type Λp,r + 12615.) + 3.) - 5.) - 15.) + 4.) + 12.)) / 720. w[7] = (y * y * y * y * y * y * (y * (y * (y * (y * (1006. * y - 5533.) + 12285.) - 13785.) + 7829.) - 1802.)) / 720. Formule Λ6,5 Λ6,5(x) =    1 − 4936 |x| 2 + 7 18 |x| 4 − 701 8 |x| 6 + 54803 144 |x| 7 − 32165 48 |x| 8 + 9555 16 |x| 9 − 38731 144 |x|10 + 3521 72 |x|11 0 6 |x| < 1 1233 − 617533 60 |x| + 1544613 40 |x| 2 − 515179 6 |x| 3 + 502579 4 |x| 4 − 3809911 30 |x| 5 +3618099 40 |x| 6 − 10894163 240 |x| 7 + 251685 16 |x| 8 − 172123 48 |x| 9 + 38731 80 |x|10 − 3521 120 |x|11 1 6 |x| < 2 −181439 + 16709441 20 |x| − 125352311 72 |x| 2 + 13002493 6 |x| 3 − 64445353 36 |x| 4 + 30912301 30 |x| 5 −3373567 8 |x| 6 + 88345523 720 |x| 7 − 1194095 48 |x| 8 + 160657 48 |x| 9 − 38731 144 |x|10 + 3521 360 |x|11 2 6 |x| < 3 1188352 − 19108864 5 |x| + 250837216 45 |x| 2 − 14600752 3 |x| 3 + 25437902 9 |x| 4 − 17195278 15 |x| 5 +13253241 40 |x| 6 − 49136309 720 |x| 7 + 471205 48 |x| 8 − 45083 48 |x| 9 + 38731 720 |x|10 − 503 360 |x|11 3 6 |x| < 4 0 4 6 |x| (A.10) w[0] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-1006. * y + 5533.) - 12285.) + 13785.) - 7829.) + 1803.) - 3.) - 5.) + 15.) + 4.) - 12.)) / 720. w[1] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (7042. * y - 38731.) + 85995.) - 96495.) + 54803.) - 12620.) + 12.) + 60.) - 120.) - 54.) + 108.)) / 720. w[2] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-21126. * y + 116193.) - 257985.) + 289485.) - 164409.) + 37857.) - 15.) - 195.) + 195.) + 540.) - 540.)) / 720. w[3] = (y * y * (y * y * (y * y * (y * (y * (y * (y * (35210. * y - 193655.) + 429975.) - 482475.) + 274015.) - 63090.) + 280.) - 980.) + 720.) / 720. w[4] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-35210. * y + 193655.) - 429975.) + 482475.) - 274015.) + 63085.) + 15.) - 195.) - 195.) + 540.) + 540.)) / 720. w[5] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (21126. * y - 116193.) + 257985.) - 289485.) + 164409.) - 37848.) - 12.) + 60.) + 120.) - 54.) - 108.)) / 720. w[6] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-7042. * y + 38731.) - 85995.) + 96495.) - 54803.) 152A.3. Formules de type Λ6,r + 12615.) + 3.) - 5.) - 15.) + 4.) + 12.)) / 720. w[7] = (y * y * y * y * y * y * (y * (y * (y * (y * (1006. * y - 5533.) + 12285.) - 13785.) + 7829.) - 1802.)) / 720. Formule Λ6,6 Λ6,6(x) =    1 − 4936 |x| 2 + 7 18 |x| 4 − 1 36 |x| 6 − 46109 144 |x| 7 + 81361 48 |x| 8 − 544705 144 |x| 9 + 655039 144 |x|10 −223531 72 |x|11 + 81991 72 |x|12 − 6307 36 |x|13 0 6 |x| < 1 −44291 5 + 1745121 20 |x| − 15711339 40 |x| 2 + 32087377 30 |x| 3 − 7860503 4 |x| 4 + 38576524 15 |x| 5 −24659323 10 |x| 6 + 84181657 48 |x| 7 − 74009313 80 |x| 8 + 17159513 48 |x| 9 − 7870247 80 |x|10 +438263 24 |x|11 − 81991 40 |x|12 + 6307 60 |x|13 1 6 |x| < 2 3905497 − 424679647 20 |x| + 3822627865 72 |x| 2 − 2424839767 30 |x| 3 + 3009271097 36 |x| 4 − 930168127 15 |x| 5 +305535494 9 |x| 6 − 9998313437 720 |x| 7 + 203720335 48 |x| 8 − 137843153 144 |x| 9 + 22300663 144 |x|10 −6126883 360 |x|11 + 81991 72 |x|12 − 6307 180 |x|13 2 6 |x| < 3 −255622144 5 + 971097344 5 |x| − 15295867328 45 |x| 2 + 5442932656 15 |x| 3 − 2372571796 9 |x| 4 + 2064517469 15 |x| 5 −9563054381 180 |x| 6 + 2210666335 144 |x| 7 − 796980541 240 |x| 8 + 76474979 144 |x| 9 − 43946287 720 |x|10 +343721 72 |x|11 − 81991 360 |x|12 + 901 180 |x|13 3 6 |x| < 4 0 4 6 |x| (A.11) w[0] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (3604. * y - 23426.) + 63866.) - 93577.) + 77815.) - 34869.) + 6587.) + 1.) - 3.) - 5.) + 15.) + 4.) - 12.)) / 720. w[1] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-25228. * y + 163982.) - 447062.) + 655039.) - 544705.) + 244083.) - 46109.) - 6.) + 12.) + 60.) - 120.) - 54.) + 108.)) / 720. w[2] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (75684. * y - 491946.) + 1341186.) - 1965117.) + 1634115.) - 732249.) + 138327.) + 15.) - 15.) - 195.) + 195.) + 540.) - 540.)) / 720. w[3] = (y * y * (y * y * (y * y * (y * (y * (y * (y * (y * (y * (-126140. * y + 819910.) - 2235310.) + 3275195.) - 2723525.) + 1220415.) - 230545.) - 20.) + 280.) - 980.) + 720.) / 720. 153A. Formules de remaillage de type Λp,r w[4] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (126140. * y - 819910.) + 2235310.) - 3275195.) + 2723525.) - 1220415.) + 230545.) + 15.) + 15.) - 195.) - 195.) + 540.) + 540.)) / 720. w[5] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-75684. * y + 491946.) - 1341186.) + 1965117.) - 1634115.) + 732249.) - 138327.) - 6.) - 12.) + 60.) + 120.) - 54.) - 108.)) / 720. w[6] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (25228. * y - 163982.) + 447062.) - 655039.) + 544705.) - 244083.) + 46109.) + 1.) + 3.) - 5.) - 15.) + 4.) + 12.)) / 720. w[7] = (y * y * y * y * y * y * y * (y * (y * (y * (y * (y * (-3604. * y + 23426.) - 63866.) + 93577.) - 77815.) + 34869.) - 6587.)) / 720. A.4. Formules de type Λ8,r y w 0 w 1 w 2 w 3 w 4 w 5 w 6 w 7 w 8 w 9 Figure A.4. – Poids de remaillage pour les formules de type Λ8,r 154A.4. Formules de type Λ8,r Formule Λ8,4 Λ8,4(x) =    1 − 205 144 |x| 2 + 91 192 |x| 4 − 6181 320 |x| 5 + 6337 96 |x| 6 − 2745 32 |x| 7 + 28909 576 |x| 8 − 3569 320 |x| 9 0 6 |x| < 1 −154 + 12757 12 |x| − 230123 72 |x| 2 + 264481 48 |x| 3 − 576499 96 |x| 4 + 686147 160 |x| 5 −96277 48 |x| 6 + 14221 24 |x| 7 − 28909 288 |x| 8 + 3569 480 |x| 9 1 6 |x| < 2 68776 7 − 1038011 28 |x| + 31157515 504 |x| 2 − 956669 16 |x| 3 + 3548009 96 |x| 4 − 2422263 160 |x| 5 +197255 48 |x| 6 − 19959 28 |x| 7 + 144545 2016 |x| 8 − 3569 1120 |x| 9 2 6 |x| < 3 −56375 + 8314091 56 |x| − 49901303 288 |x| 2 + 3763529 32 |x| 3 − 19648027 384 |x| 4 + 9469163 640 |x| 5 −545977 192 |x| 6 + 156927 448 |x| 7 − 28909 1152 |x| 8 + 3569 4480 |x| 9 3 6 |x| < 4 439375 7 − 64188125 504 |x| + 231125375 2016 |x| 2 − 17306975 288 |x| 3 + 7761805 384 |x| 4 − 2895587 640 |x| 5 +129391 192 |x| 6 − 259715 4032 |x| 7 + 28909 8064 |x| 8 − 3569 40320 |x| 9 4 6 |x| < 5 0 5 6 |x| (A.12) w0 = (y * (y * (y * (y * (y * (y * (y * (y * (-3569. * y + 16061.) - 27454.) + 21126.) - 6125.) + 49.) - 196.) - 36.) + 144.)) / 40320. w1 = (y * (y * (y * (y * (y * (y * (y * (y * (32121. * y - 144548.) + 247074.) - 190092.) + 55125.) - 672.) + 2016.) + 512.) - 1536.)) / 40320. w2 = (y * (y * (y * (y * (y * (y * (y * (y * (-128484. * y + 578188.) - 988256.) + 760312.) - 221060.) + 4732.) - 9464.) - 4032.) + 8064.)) / 40320. w3 = (y * (y * (y * (y * (y * (y * (y * (y * (299796. * y - 1349096.) + 2305856.) - 1774136.) + 517580.) - 13664.) + 13664.) + 32256.) - 32256.)) / 40320. w4 = (y * y * (y * y * (y * (y * (y * (y * (-449694. * y + 2023630.) - 3458700.) + 2661540.) - 778806.) + 19110.) - 57400.) + 40320.) / 40320. w5 = (y * (y * (y * (y * (y * (y * (y * (y * (449694. * y - 2023616.) + 3458644.) - 2662016.) + 780430.) - 13664.) - 13664.) + 32256.) + 32256.)) / 40320. w6 = (y * (y * (y * (y * (y * (y * (y * (y * (-299796. * y + 1349068.) - 2305744.) + 1775032.) - 520660.) + 4732.) + 9464.) - 4032.) - 8064.)) / 40320. w7 = (y * (y * (y * (y * (y * (y * (y * (y * (128484. * y - 578168.) + 988176.) - 760872.) + 223020.) - 672.) - 2016.) + 512.) + 1536.)) / 40320. 155A. Formules de remaillage de type Λp,r w8 = (y * (y * (y * (y * (y * (y * (y * (y * (-32121. * y + 144541.) - 247046.) + 190246.) - 55685.) + 49.) + 196.) - 36.) - 144.)) / 40320. w9 = (y * y * y * y * y * (y * (y * (y * (3569. * y - 16060.) + 27450.) - 21140.) + 6181.)) / 40320. 156B. Publications 157ESAIM: M2AN 48 (2014) 1029–1060 ESAIM: Mathematical Modelling and Numerical Analysis DOI: 10.1051/m2an/2014009 www.esaim-m2an.org HIGH ORDER SEMI-LAGRANGIAN PARTICLE METHODS FOR TRANSPORT EQUATIONS: NUMERICAL ANALYSIS AND IMPLEMENTATION ISSUES G.-H. Cottet1, J.-M. Etancelin1, F. Perignon1 and C. Picard1 Abstract. This paper is devoted to the definition, analysis and implementation of semi-Lagrangian methods as they result from particle methods combined with remeshing. We give a complete consistency analysis of these methods, based on the regularity and momentum properties of the remeshing kernels, and a stability analysis of a large class of second and fourth order methods. This analysis is supplemented by numerical illustrations. We also describe a general approach to implement these methods in the context of hybrid computing and investigate their performance on GPU processors as a function of their order of accuracy. Mathematics Subject Classification. 65M12, 65M75, 65Y05, 65Y20. Received October 22, 2013. Revised January 28, 2014. Published online June 30, 2014. 1. Introduction Particle methods are Lagrangian methods that have been designed for advection dominated problems, with applications mostly in plasma physics [10], incompressible flows [4,7,16], or gas dynamics [20]. Following [12, 13], particle methods are often associated with remeshing, in order to maintain the regularity of the particle distribution and, as a consequence, to control the accuracy of the method in presence of strong strain in the flow carrying the particles. Remeshing removes the grid free nature of particle methods but maintains some of its features like conservation, locality, and stability. It not only guarantees accuracy but also allows to combine in a seamless fashion particle methods with grid-based techniques, like domain decomposition methods and fast FFT-based Poisson solvers for field evaluations [5, 22], multi-resolution and adaptive mesh refinement [1, 2]. In practice particle remeshing occurs every few time steps. In that case, and as long as the remeshing frequency does not increase when the discretization parameters tend to zero, Remeshed Particle Methods (RPM in the sequel) can be viewed as conservative forward semi-lagrangian methods. Classical semi-lagrangian methods for transport equations combine tracking of trajectories originating at grid points and interpolation from the grid. Because they operate on local point values, semi-lagrangian methods in general do not conserve mass, unless some specific treatment is done. By contrast, particle methods transport masses which makes them inherently conservative. Keywords and phrases. Advection equations, particle methods, semi-Lagrangian methods, GPU computing. 1 Universit´e Grenoble Alpes and CNRS, Laboratoire Jean Kuntzmann, BP 53 38041, Grenoble Cedex 9, France. georges-henri.cottet@imag.fr Article published by EDP Sciences c EDP Sciences, SMAI 2014 Proposition d’une architecture de surveillance ”active” `a base d’agents intelligents pour l’aide `a la maintenance de syst`emes mobiles - Application au domaine ferroviaire Antoine Le Mortellec To cite this version: Antoine Le Mortellec. Proposition d’une architecture de surveillance ”active” `a base d’agents intelligents pour l’aide `a la maintenance de syst`emes mobiles - Application au domaine ferroviaire. Automatic Control Engineering. Universit´e de Valenciennes et du Hainaut-Cambresis, 2014. French. . HAL Id: tel-00947981 https://tel.archives-ouvertes.fr/tel-00947981v2 Submitted on 4 Apr 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Thèse de doctorat Pour obtenir le grade de Docteur de l’Université de VALENCIENNES ET DU HAINAUT-CAMBRESIS Spécialité Automatique et Génie Informatique Présentée et soutenue par Antoine LE MORTELLEC Le 30/01/2014 à Valenciennes Ecole doctorale : Sciences Pour l’Ingénieur (SPI) Equipe de recherche, Laboratoire : Laboratoire : Thermique Ecoulement Mécanique Matériaux Mise en Forme Production (TEMPO) Equipe : Production, Services, Information (PSI) Proposition d’une architecture de surveillance “active” à base d’agents intelligents pour l’aide à la maintenance de systèmes mobiles Application au domaine ferroviaire JURY Président du jury Pierre Castagna. Professeur à l’Université de Nantes. Rapporteurs Zineb Simeu-Abazi. Maître de conférences HDR à l’Université Joseph Fourier de Grenoble. Benoît Iung. Professeur à l’Université de Lorraine. Samir Lamouri. Professeur à l’Ecole Nationale Supérieure d’Arts et Métiers Paris Tech. Examinateur Audine Subias. Maître de conférences HDR à l’Université de Toulouse. Directeur de thèse Damien Trentesaux. Professeur à l’Université de Valenciennes et du Hainaut Cambrésis. Co-encadrants de thèse Yves Sallez. Maître de conférences HDR à l’Université de Valenciennes et du Hainaut Cambrésis. Thierry Berger. Maître de conférences à l’Université de Valenciennes et du Hainaut Cambrésis. Membre invité Frédéric Grzesiak. Directeur technique de la société PROSYST de Valenciennes. N° Ordre : 14/06 Page 2 Page 3 Avant-propos Cette thèse s’inscrit dans le cadre du projet SURFER (SURveillance active FERroviaire) conduit par Bombardier-Transport, en collaboration avec la société PROSYST, le groupe HIOLLE INDUSTRIES, l'Université de Valenciennes et du Hainaut-Cambrésis (UVHC) et l'Institut Français des Sciences et Technologies des Transports, de l'Aménagement et des Réseaux (IFSTTAR). Elle a été financée dans le cadre d’un contrat de collaboration de Recherche entre le laboratoire TEMPO EA4542 et la société PROSYST. Le temps de travail a été partagé entre ces deux entités. Le projet SURFER est supporté financièrement par le Fonds Unique Interministériel (FUI) et la région Nord Pas-de-Calais, et sponsorisé par les Pôles de compétitivité i-Trans et Advancity. Les accords de consortium établis entre les différents partenaires du projet SURFER ont restreint la divulgation de certains développements scientifiques et technologiques réalisés pendant mes travaux de Recherche. Ces éléments ne sont donc pas publiés dans ce manuscrit. Page 4 Remerciements Les travaux présentés dans ce manuscrit ont été réalisés au sein de l’équipe PSI du laboratoire TEMPO de l’Université de Valenciennes et du Hainaut Cambrésis en collaboration avec la société PROSYST. Je tiens à remercier en premier lieu le professeur Damien Trentesaux, responsable de l’équipe PSI, qui a dirigé cette thèse pour la qualité de son encadrement, ses conseils pertinents et son aide tout au long de ces trois années de doctorat. Je remercie mes co-encadrants de thèse, M. Yves Sallez, Maître de Conférences HDR, et M. Thierry Berger, Maître de Conférences, pour leur disponibilité, leurs critiques constructives et leurs encouragements, ainsi que pour le temps qu’ils ont consacré à relire et à corriger ce manuscrit. J’exprime toute ma gratitude à Mme Zineb Simeu-Abazi, Maître de Conférences HDR au laboratoire G-SCOP de Grenoble, à M. Benoît Iung, professeur au CRAN de Nancy et à M. Samir Lamouri, professeur à l’École Nationale Supérieure d’Arts et Métiers Paris Tech, qui m’ont fait l’honneur de rapporter cette thèse. J’ai été particulièrement sensible à leur lecture attentive de ce manuscrit, aux nombreuses discussions et perspectives scientifiques qu’ils ont apportées à mes travaux. Je remercie vivement Mme Audine Subias, Maître de Conférences HDR au LAAS de Toulouse pour avoir accepté d’examiner cette thèse et M. Pierre Castagna, professeur à l’IRCCyN de Nantes, pour avoir accepté de présider ce jury. Mes remerciements s’adressent également à l’ensemble du personnel de la société PROSYST et à son dirigeant, M. Abdallah Asse, pour leur accueil et leur sympathie. Je remercie chaleureusement M. Frédéric Grzesiak, directeur technique et M. Khaled El Sanwar, ingénieur de Recherche et Développement, pour leur aide, la vision qu’ils m’ont transmise sur les différents aspects du sujet de thèse et la confiance qu’ils m’ont accordée. Je tiens à remercier M. Guillaume Branger, ingénieur de Recherche et Développement au sein de Bombardier-Transport France et pilote du projet SURFER, pour son soutien, l’expérience qu’il m’a apportée et l’intérêt qu’il a porté à l’égard de mes travaux. Je remercie évidemment les membres de l’équipe TEMPO-PSI ainsi que tous les “surfeurs” qui ont contribué à la concrétisation de cette thèse. Je pense en particulier à Joffrey Clarhaut, Rebiha Bekrar, Jean Gandibleux, Quentin Coutadeur et Vivien Basselot. Je remercie ma famille pour m’avoir soutenu pendant toutes ces années d’études. Merci à mes sœurs, Cécile et Aurore, sans qui cette thèse n’existerait probablement pas. Je n’oublie pas mes amis, notamment mes amis Rennais, qui m’ont toujours encouragé et motivé pendant ces années passées dans le “ch’Nord”. Merci à vous. REMERCIEMENTS Page 5 À ma maman..., Page 6 Table des matières Introduction générale ............................................................................................................................................. 9 Ch. I Problématique de la surveillance pour l’aide à la maintenance ............................................................... 12 Introduction ...................................................................................................................................................... 12 1. Contexte général ........................................................................................................................................... 13 1.1 Approche systémique adoptée ................................................................................................................ 13 1.2 Propriétés des systèmes cibles considérés .............................................................................................. 14 1.3 Terminologie relative à la maintenance .................................................................................................. 16 1.4 Activités de la maintenance .................................................................................................................... 17 2. Fonctions d’un système de surveillance ....................................................................................................... 20 2.1 Détection ................................................................................................................................................ 22 2.2 Diagnostic ............................................................................................................................................... 22 2.3 Pronostic ................................................................................................................................................. 23 2.4 Elaboration de conseils ........................................................................................................................... 23 3. Modèle d’architecture de surveillance .......................................................................................................... 24 3.1 Standards d’architectures de surveillance ............................................................................................... 24 3.2 Problématiques de la surveillance des systèmes cibles considérés ......................................................... 30 4. Conclusion .................................................................................................................................................... 34 Ch. II Surveillance de systèmes mobiles : état de l’art et approches de surveillance active .............................. 35 Introduction ...................................................................................................................................................... 35 1. Etat de l’art des architectures de diagnostic .................................................................................................. 35 1.1 Diagnostic distant ................................................................................................................................... 36 1.2 Diagnostic embarqué .............................................................................................................................. 38 1.3 Typologie des architectures de diagnostic .............................................................................................. 43 2. Approches de surveillance active.................................................................................................................. 45 2.1 Concept de surveillance active ............................................................................................................... 46 2.2 Approche multi-agents ........................................................................................................................... 47 2.3 Approche holonique ............................................................................................................................... 49 2.4 Comparaison des approches ................................................................................................................... 52 3. Conclusion .................................................................................................................................................... 53 Ch. III Proposition d’une architecture holonique pour la surveillance active de systèmes cibles mobiles ...... 54 Introduction ...................................................................................................................................................... 54 1. Système de surveillance holonique ............................................................................................................... 54 1.1 Approche de modélisation du système cible à surveiller ........................................................................ 55 1.2 Spécification d’une architecture holonique de surveillance ................................................................... 58 1.3 Architecture de surveillance proposée .................................................................................................... 61 2. Structure interne d’un holon de surveillance ................................................................................................ 66 2.1 Données exploitées par la fonction de surveillance d’un holon ............................................................. 66 2.2 Hypothèses pour l’élaboration d’un diagnostic ...................................................................................... 67 2.3 Modules internes d’une fonction de surveillance ................................................................................... 67 2.4 Niveaux de diagnostic d’une fonction de surveillance ........................................................................... 69 3. Conclusion .................................................................................................................................................... 71 Ch. IV Mise en œuvre de l’architecture holonique de surveillance active ......................................................... 72 Introduction ...................................................................................................................................................... 72 1. Diagnostic PSC individuel non-contextualisé ............................................................................................... 73 1.1 Nature des systèmes diagnostiqués ......................................................................................................... 73 1.2 Méthode de diagnostic mise en œuvre ................................................................................................... 73 1.3 Limitations de la méthode de diagnostic mise en œuvre ........................................................................ 74 2. Contextualisation du diagnostic .................................................................................................................... 75 2.1 Contextualisation individuelle ................................................................................................................ 76 2.2 Contextualisation collective ................................................................................................................... 78 3. Description comportementale des holons de surveillance ............................................................................ 80 3.1 Comportements des holons élémentaires................................................................................................ 82TABLE DES MATIÈRES Page 7 3.2 Comportements des holons composés .................................................................................................... 84 4. Mise en œuvre des holons de surveillance .................................................................................................... 87 4.1 Implémentation de la partie informationnelle d’un holon ...................................................................... 87 4.2 Implantation physique des holons de surveillance ................................................................................. 88 5. Conclusion .................................................................................................................................................... 89 Ch. V Application au domaine ferroviaire .......................................................................................................... 90 Introduction ...................................................................................................................................................... 90 1. Contexte industriel du projet SURFER ......................................................................................................... 90 1.1 Objectifs du projet SURFER .................................................................................................................. 90 1.2 Utilisateurs du système SURFER ........................................................................................................... 91 2. Application de notre proposition pour un système train ............................................................................... 92 2.1 Instanciation de l’architecture holonique de surveillance ....................................................................... 93 2.2 Algorithmes des holons de surveillance ................................................................................................. 95 2.3 Exemples de scénarios de diagnostic ...................................................................................................... 99 3. Plateforme expérimentale ........................................................................................................................... 102 3.1 Architecture de la plateforme PEMAS ................................................................................................. 103 3.2 Implémentation des agents dans Jade ................................................................................................... 105 4. Résultats obtenus ........................................................................................................................................ 108 4.1 Implémentation de la couche acquisition embarquée ........................................................................... 108 4.2 Mise en œuvre de la méthode de diagnostic à base de modèle ............................................................. 109 4.3 Contextualisation du diagnostic............................................................................................................ 110 5. Conclusion .................................................................................................................................................. 110 Références .......................................................................................................................................................... 117 Liste des figures .................................................................................................................................................. 129 Annexes .............................................................................................................................................................. 131 Annexe A : Complément sur l’approche systémique ...................................................................................... 132 Annexe B : Etude comparative des méthodes de diagnostic ........................................................................... 133 B.1 Méthodes à base de modèles (MBD) ................................................................................................... 134 B.2 Méthodes basées sur des données historiques...................................................................................... 139 B.3 Comparaison des méthodes de diagnostic ........................................................................................... 141 Annexe C : Méthode de diagnostic mise en œuvre ......................................................................................... 144 Annexe D : Prototype SURFER ..................................................................................................................... 146 TABLE DES MATIÈRES Page 8 Page 9 Introduction générale Pour se démarquer et rester compétitif, les industriels misent notamment sur le développement et l’intégration rapide de nouvelles fonctionnalités offertes par les évolutions technologiques de l’information et de la communication. Ces deux dernières décennies, les systèmes embarqués ont été introduits dans de nombreux domaines d’application (transport, industrie, habitat, médical...). Ces systèmes se sont vu confier des tâches plus importantes pour délivrer de nouveaux services aux utilisateurs avec des délais de mise sur le marché toujours plus courts et à moindre coût. Dans certains domaines, ces systèmes ont également permis de répondre aux exigences accrues en matière de sécurité et de fiabilité. Paradoxalement, le développement de ces équipements embarqués a contribué à accroitre le nombre de pannes des systèmes dans lesquels ils sont enfouis. Ces pannes, aux conséquences généralement coûteuses, voir catastrophiques, sont devenues inacceptables pour les industriels qui commercialisent ces produits ainsi que pour leurs clients. L’identification des causes de certaines pannes représente actuellement un véritable challenge dans les activités de la maintenance. Elles entrainent une indisponibilité excessive des équipements. Dans le domaine des transports, ces constats ont conduit un acteur majeur de l’industrie ferroviaire à améliorer la disponibilité de ses véhicules sur rail à travers une approche innovante visant à optimiser la maintenance. Ainsi, le projet SURFER, qui est à l’origine des travaux présentés dans ce manuscrit, a été proposé. Ce projet repose sur la conception et le déploiement d’une architecture évoluée pour la surveillance de matériels roulants ferroviaires. Cette thèse se situe à la rencontre de plusieurs communautés de Recherche, dans laquelle la notion d’intelligence (ou activité) rattachée à un produit a pour objet l’évaluation et la gestion de la santé des équipements. Elle regroupe notamment des concepts relatifs à la surveillance dans un contexte de maintenance, au diagnostic et au développement de produits “actifs” tout au long de son cycle de vie. Notre contribution principale concerne la proposition d’une architecture générique de surveillance “active” pour l’aide à la maintenance de systèmes mobiles, basée sur des entités de surveillance “intelligentes”. Cette architecture a vocation à supporter des méthodologies de diagnostic développées par différentes communautés de Recherche. L’élaboration d’une nouvelle méthode de diagnostic n’est donc pas l’objet de notre proposition. Le projet SURFER étant le cadre applicatif de nos travaux, le domaine des transports est une référence pour illustrer notre approche, sans pour autant restreindre l’application de notre contribution à ce domaine. Nous avons choisi de structurer ce manuscrit en cinq chapitres, dont l’organisation est illustrée par la figure 1. INTRODUCTION GÉNÉRALE Page 10 Figure 1. Organisation des chapitres de ce manuscrit. Le chapitre I introduit le contexte général de nos travaux en présentant tout d’abord les caractéristiques des systèmes à maintenir. Ce chapitre positionne ensuite notre étude par rapport à un modèle d’architecture de surveillance de la littérature. Les différents verrous liés à la surveillance des systèmes considérés sont alors exposés et les exigences à satisfaire dans le cadre de nos travaux sont définies. Le chapitre II dresse un état de l’art des approches de la littérature pour la surveillance de systèmes mobiles, en proposant une typologie des architectures de diagnostic. Une classe d’architecture est retenue dans le contexte de notre étude. Suivant ce type d’architecture, ce chapitre s’oriente par la suite vers une approche de surveillance “active” en adoptant une approche de modélisation à base d’entités autonomes et communicantes. Le chapitre III est consacré à notre proposition. Une architecture générique pour la surveillance de systèmes mobiles est proposée. Cette architecture repose sur les choix réalisés dans le précédent chapitre. Ce chapitre spécifie l’architecture proposée et détaille la structure interne des entités de surveillance qui composent cette architecture de surveillance. Le chapitre IV met en œuvre l’architecture de surveillance proposée. Dans ce chapitre, les processus internes aux entités de surveillance et les comportements attendus de ces entités sont définis. Par la suite, une approche est adoptée pour implémenter ces entités de surveillance. INTRODUCTION GÉNÉRALE Page 11 Le chapitre V applique les propositions des deux chapitres précédents au domaine ferroviaire dans le cadre du projet SURFER. Dans un premier temps, ce chapitre instancie l’architecture proposée pour la surveillance d’un train de passagers. Par la suite, la plateforme expérimentale conçue pour implémenter cette architecture et valider notre approche est détaillée. Enfin, les résultats obtenus dans ce cadre applicatif sont présentés. Suite à ce dernier chapitre, la conclusion de nos travaux et les perspectives de Recherche envisagées sont exposées. Page 12 Chapitre I Problématique de la surveillance pour l’aide à la maintenance Introduction Dans un contexte économique hautement concurrentiel, les fabricants et intégrateurs de produits à haute valeur technologique sont contraints de concevoir des systèmes à des coûts de plus en plus faibles sur l’ensemble des phases du cycle de vie. L’objectif étant de proposer des produits compétitifs en terme de coûts d’acquisition, d’exploitation et de maintenance (coût global de possession ou LCC : Life Cycle Cost). Par conséquent, limiter les coûts de maintenance et d’exploitation tout en améliorant la disponibilité des systèmes est une préoccupation majeure des industriels. La maintenance est l’un des éléments clef dans la réduction de l’indisponibilité. Elle représente également un point sensible, soumise notamment à des contraintes financières, sécuritaires et énergétiques (Rabatel et al., 2009). Ainsi, la maintenance est un levier stratégique de compétitivité et d’innovation pour les industriels (Muller et al., 2008). Elle permet de préserver les caractéristiques fonctionnelles des systèmes et vise à améliorer leurs disponibilités dans des conditions économiques acceptables. L’optimisation de la maintenance se traduit par une réduction des temps d’immobilisation du système maintenu et repose donc sur la pertinence des actions réalisées sur le système lors des interventions de maintenance. Un système de maintenance efficace doit permettre d’orienter au mieux le personnel de maintenance, en délivrant des informations directement exploitables et précises sur les opérations de maintenance à réaliser. Dans ce contexte, un système de surveillance observant en permanence un système à maintenir lors de son fonctionnement et assurant la tâche de diagnostic de manière autonome offre une aide précieuse aux services de maintenance (Jardine et al., 2006). Les informations fournies par un tel système contribuent notamment à anticiper les pannes et à accélérer la remise en service du système maintenu après l’occurrence de la défaillance. Ces informations de surveillance peuvent apporter des précisions sur l’origine des dysfonctionnements observés et sur les interventions de maintenance à réaliser. Ce premier chapitre présente les systèmes à maintenir considérés dans nos travaux et introduit les principales notions relatives à la surveillance dans un contexte de maintenance. Par la suite, les différentes fonctions d’un système de surveillance seront présentées et les problématiques inhérentes à la surveillance des systèmes étudiés seront exposées. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 13 1. Contexte général Les avancées technologiques de l’information et de la communication ont favorisé l’intégration massive de fonctions automatisées au sein de produits industriels (BrahimDjelloul et al., 2012 ; Kiencke et al., 2006). Ces fonctions permettent de délivrer de nouveaux services aux utilisateurs et d’atteindre des objectifs de plus en plus élevés en termes de sécurité et de fiabilité. Ainsi, de nombreuses fonctionnalités sont assurées par des systèmes embarqués. Un système embarqué est un système complexe intégrant une partie logicielle et une partie matérielle conçues conjointement pour fournir des fonctionnalités données (Simeu, 2005). Ces équipements embarqués peuvent réaliser des fonctions plus évoluées lorsqu’ils interagissent entre eux au sein d’un système plus vaste (système de transport, bâtiment industriel, systèmes de production, par exemple). Ces équipements interconnectés forment alors un système réparti (Dievart et al., 2010). La complexité croissante des systèmes dotés de ces équipements embarqués tend à rendre leurs opérations de maintenance bien plus délicates. Par exemple, une intervention de maintenance sur un tel système nécessite une connaissance approfondie du fonctionnement de l’ensemble du système et des différents équipements embarqués qui le composent. Pour faire face à cette complexité, des approches de maintenance dites “intelligentes” ont été rendues possibles grâce aux évolutions de l’informatique, de l’électronique et des télécommunications (Campos, 2009). Ces approches de maintenance innovantes visent à évaluer l’état d’un système et à déterminer les interventions de maintenance nécessaires en fonction de cet état. Les objectifs attendus de ces nouvelles approches de maintenance sont d’accroitre la durée de fonctionnement des équipements, de réduire les coûts de maintenance, d’exploitation et de possession, et d’améliorer la sécurité (Vachtsevanos et Lewis, 2006). Cette partie positionne tout d’abord les systèmes considérés dans nos travaux en adoptant une approche systémique. Par la suite, les propriétés des systèmes à maintenir considérés sont définies et la terminologie adoptée dans nos travaux est présentée. Enfin, cette partie décrit les différents types de maintenance et précise le rôle de la surveillance au sein d’un système de maintenance. 1.1 Approche systémique adoptée Ce mémoire se focalise sur l’aide à la maintenance de systèmes constitués d’équipements embarqués répartis, désignés ci-après sous-systèmes, et organisés suivant une structure hiérarchisée de contrôle. Par la suite, un système constitué de ces sous-systèmes sera nommé système cible. Un système cible est supposé être maintenu par un système de maintenance. Un système de maintenance regroupe différentes entités en charge de planifier et de réaliser les interventions de maintenance (centre de maintenance, personnel de maintenance, par exemple). La figure 1.1 ci-dessous présente un exemple de système cible supposé être situé dans son environnement. Ce système cible se compose de différents sous-systèmes organisés suivant une structure hiérarchisée de contrôle : un sous-système commande un ou plusieurs soussystèmes de niveau inférieur. De plus, les sous-systèmes interagissent entre eux dans le domaine physique et dans le domaine informationnel. Les relations maître-esclave illustrées dans cet exemple représentent les liens “logiques” de subordination entre sous-systèmes. Les liens “physiques” entre ces sous-systèmes peuvent être réalisés par différentes technologies (bus ou réseaux, par exemple). CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 14 Figure 1.1. Exemples de système cible et de système de maintenance considérés. Le système de maintenance est supposé disposer d’un centre de maintenance, dont l’objectif est de maintenir le système cible tout au long de son usage. Lorsqu’une approche de maintenance doit être appliquée à un système cible, des exigences sont alors à allouer au système de maintenance comme au système cible. La section suivante définit les propriétés des systèmes cibles considérées dans nos travaux. 1.2 Propriétés des systèmes cibles considérés Les systèmes cibles considérés dans nos travaux sont caractérisés par les propriétés suivantes : · Décomposition : le système cible est supposé être décomposable en un ensemble fini de sous-systèmes. · Hétérogénéité technologique : chaque sous-système est supposé être constitué d’une partie contrôle et d’une partie sous-contrôle. Ces sous-systèmes sont supposés exploiter différentes technologies (électrique, électronique, mécanique, hydraulique ou pneumatique, par exemple). · Variabilité : un sous-système est supposé varier d’un même système cible à un autre (évolution de la technologie, modification de composants, modernisation, par exemple). · Interactions : les sous-systèmes sont supposés interagir entre eux dans le domaine physique (échanges de flux de matière ou d’énergie, par exemple) et/ou dans le domaine informationnel (relations de type maître-esclave ou échanges d’informations, par exemple). · Environnement : le système cible est supposé être situé dans un environnement. Par conséquent, le système cible comme chaque sous-système est supposé opérer dans un contexte opérationnel spécifique. Ce contexte peut être de nature physique (température, vibrations, par exemple) et/ou informationnelle (mode de fonctionnement, état du système, par exemple). · Maintenabilité : le système cible est supposé être réparable et être maintenu au sein du système de maintenance par un centre de maintenance. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 15 Le tableau 1.1 ci-après présente les domaines d’applications les plus représentatifs des systèmes cibles considérés dans nos travaux. Les principales caractéristiques associées à ces systèmes cibles sont également mentionnées. Tableau 1.1. Exemples de systèmes cibles considérés, inspiré de (Simeu, 2005). Application Mobilité Sévérité de l'environnement Intervention immédiate sur le système Haut niveau de fiabilité Transport Automobile P P - P Ferroviaire P P - P Aérien P P - P Maritime P P - P Aérospatial Fusée navette P P - P Satellites P P - P Industrie Systèmes de production - P P P Centrales nucléaires - P P P Habitat Bâtiments (immotique) - - P - Habitations (domotique) - - P - - : caractéristique absente ou négligeable P : caractéristique présente Dans certains domaines d’applications, la mobilité du système cible entraine des contraintes spécifiques en termes de maintenabilité. En effet, lorsque le système cible est mobile, celui-ci doit communiquer avec un centre de maintenance distant (Jianjun et al., 2007). Par exemple, un système de transport (automobile, ferroviaire, aérien ou maritime) est un système cible mobile évoluant dans un environnement changeant (climat, état de l’infrastructure, profil du conducteur, par exemple). Les interventions de maintenance ne peuvent être exécutées immédiatement sur ce système (système en service commercial et éloigné du centre de maintenance, par exemple) (Umiliacchi et al., 2011). Aussi, un système de transport doit répondre à des exigences strictes en matière de fiabilité. La disponibilité d’un système cible repose sur les objectifs de fiabilité fixés lors de sa conception et sur l’efficacité des interventions de maintenance réalisées au cours de sa phase LégendeCHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 16 d’utilisation. Les sections suivantes présentent la terminologie et les principaux concepts associés à la maintenance. 1.3 Terminologie relative à la maintenance La maintenance est définie comme l’ensemble de toutes les actions techniques, administratives et de management durant le cycle de vie d’un bien, destinées à le maintenir ou à le rétablir dans un état dans lequel il peut accomplir la fonction requise (NF-EN-13306, 2010). Un bien désigne un élément, composant, mécanisme, sous-système, unité fonctionnelle, équipement ou système qui peut être décrit et considéré individuellement. Différents événements peuvent compromettre le fonctionnement désiré d’un bien ou la mission pour laquelle un bien a été conçu. Les entraves au bon fonctionnement d’un bien sont les fautes, les erreurs et les défaillances (Isermann et Ballé, 1997). Une faute est une déviation non acceptable d’au moins une propriété caractéristique exprimée par le cahier des charges ou d’un paramètre d’un bien. Une erreur représente un changement d’état d’un bien pouvant entraîner une défaillance. Elle est produite par une ou plusieurs fautes et peut engendrer de nouvelles erreurs. Une défaillance est la cessation de l'aptitude d'un bien à accomplir une fonction requise et peut être causée par une ou plusieurs erreurs. Après la défaillance, le bien est en état de panne, c’est-à-dire qu’il est inapte à accomplir une fonction requise. Une panne peut être complète ou partielle et résulte toujours d’une défaillance. Dans les travaux présentés dans cette thèse, le système cible considéré est supposé être affecté par des fautes physiques (fautes matérielles) et informationnelles (fautes logicielles) survenant dans les différentes phases de son cycle de vie (fautes de développement et fautes opérationnelles, par exemple). Ces fautes induisent une ou plusieurs erreurs lorsqu’elles sont actives (états non désirés du système). Dès lors que le service délivré aux utilisateurs est impacté par ces erreurs et ne correspond plus au service attendu, une défaillance survient. La figure 1.2 ci-dessous illustre la relation entre les concepts de faute, erreur et défaillance survenant au sein d’un système cible. La présence d’une faute dans un sous-système du système cible engendre une erreur interne lors de son activation, qui conduit à la défaillance de ce sous-système. Cette défaillance peut constituer une faute pour un autre sous-système du système cible en provoquant à son tour une erreur interne et une défaillance de ce soussystème. Cette seconde défaillance entraine par la suite la défaillance du système cible en impactant le service délivré aux utilisateurs. Figure 1.2. Relation causale entre faute, erreur et défaillance. Il est à noter que les fautes et les défaillances peuvent se manifester de manière progressive dans le temps (phénomènes d’usures, par exemple), de manière soudaine (rupture d’une CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 17 liaison électrique, par exemple), ou présenter un caractère non permanent (défaillances temporellement bornées ou furtives, par exemple). Une défaillance produit des effets perceptibles par les utilisateurs du système et éventuellement décelables par un moyen de détection. Le terme symptôme sera utilisé par la suite pour désigner les effets observables d’une défaillance. La tâche de diagnostic de défaillances consiste alors à analyser ces symptômes dans le but de rechercher les éléments défectueux du système cible responsables de la défaillance (fautes). Elle peut être réalisée par un opérateur de maintenance ou être exécutée par un système d’aide à la maintenance. Les différentes activités de la maintenance sont exposées ci-après. 1.4 Activités de la maintenance La définition de la maintenance évoquée précédemment englobe différentes activités mises en œuvre tout au long du cycle de vie d’un produit. Ces activités concernent aussi bien des aspects opérationnels de la maintenance (expertise métier, diagnostic de défaillances, par exemple) que des aspects organisationnels (planification des interventions, approvisionnement des pièces de rechanges, par exemple). Dans ce mémoire, les aspects opérationnels de la maintenance seront principalement abordés. Cette section présente les différentes approches de maintenance et précise le rôle de la surveillance au sein des activités de la maintenance. 1.4.1 Typologie de la maintenance L’étude des différentes approches de maintenance repose sur trois concepts : l’événement déclencheur d’une opération de maintenance, le type de maintenance correspondante et la nature des opérations de maintenance réalisées sur le système (Ribot, 2009). Selon la norme (NF-EN-13306, 2010), les approches de maintenance sont classées en deux catégories : la maintenance préventive et la maintenance corrective. La première vise à initier des opérations de maintenance sur un système avant que des défaillances ne se produisent, tandis que la seconde consiste à intervenir sur un système en état de panne. La figure 1.3 ci-dessous résume les principaux types de maintenance recensés dans la littérature selon ces deux catégories et précise les événements déclencheurs des interventions de maintenance. Figure 1.3. Différents types de maintenance, inspirée de (Alali Alhouaij, 2010). CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 18 La maintenance préventive est exécutée à intervalles prédéterminés ou selon des critères prescrits. Elle est destinée à réduire l’occurrence de défaillances et à éviter les pannes lors de la sollicitation du système. La maintenance préventive se décline en trois sous-types normalisés, détaillés ci-après : la maintenance préventive à caractère systématique, conditionnelle et prévisionnelle (NF-EN-13306, 2010). · Systématique (Predetermined Maintenance) : maintenance préventive exécutée conformément à un échéancier, établi à partir d’un nombre d’unités d’usage (durée de fonctionnement, par exemple) ou suivant des données statistiques (recommandations constructeurs, par exemple). Elle vise principalement à rajeunir le matériel (remplacement périodique, par exemple) ou à limiter les dégradations (tâches d’entretiens courants), quel que soit l’état réel du bien maintenu (Zille, 2009). Seule la périodicité des interventions peut être ajustée pour optimiser ce type de maintenance. · Conditionnelle (Condition Based Maintenance) : maintenance préventive subordonnée à l’analyse de l’évolution surveillée de paramètres significatifs de la dégradation ou de la baisse de performance d’un bien (Deloux, 2008). Les paramètres significatifs de dégradations concernent par exemple des mesures de caractéristiques physiques d’un système et précurseurs de pannes (bruit, vibration, vitesse anormale, épaisseur trop faible d’un matériau, par exemple). Ce type de maintenance nécessite d’établir des seuils à priori pour les différents paramètres mesurés (seuils prédéterminés). Le dépassement d’un seuil indique alors la nécessité d’une opération de maintenance (par exemple, le remplacement d’un pneumatique est nécessaire lorsque son épaisseur atteint la limite fixée par son témoin d’usure). Bien que la maintenance conditionnelle soit plus dynamique que la maintenance systématique puisqu’elle considère l’état d’un bien, le temps restant avant l’occurrence de la défaillance reste indéterminée avec ce type de maintenance. · Prévisionnelle (Predictive Maintenance) : maintenance conditionnelle effectuée suivant les prévisions extrapolées de l’analyse et de l’évaluation de paramètres significatifs de la dégradation d’un bien (El koujok, 2010). Ce type de maintenance vise à prédire l’évolution de paramètres significatifs de dégradations d’un bien dans le futur et à estimer le temps de fonctionnement restant avant la défaillance (pronostic). Elle peut être qualifiée de maintenance prédictive, reposant sur les évolutions de paramètres surveillés dans le futur, et de maintenance proactive, qui consiste à déterminer les causes à l’origine des dégradations et des défaillances (Deloux, 2008). La maintenance corrective a pour objectif de remettre un bien en état de panne dans un état fonctionnel. Elle peut prendre la forme d’une maintenance palliative ou curative (Ribot, 2009) : · Palliative : maintenance corrective assurant une remise en état provisoire d’un bien (dépannage temporaire d’un pneumatique, par exemple). Ce type de maintenance consiste également à intervenir sur les effets néfastes d’une défaillance. Une action de maintenance palliative doit être suivie systématiquement d’une action de maintenance curative. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 19 · Curative : maintenance corrective permettant une remise en état de manière durable et définitive d’un bien. Contrairement à la maintenance palliative, la maintenance curative a pour objectif de supprimer les causes des défaillances. La maintenance préventive et la maintenance corrective sont complémentaires. En pratique, une politique de maintenance combinant ces deux approches est généralement appliquée aux systèmes. En effet, une maintenance préventive permet de diminuer la probabilité de défaillances, mais une part de maintenance corrective incompressible subsiste (défaillances imprévisibles). Ainsi, différentes politiques de maintenance mixte ont été définis (Ly et al., 2013). L’élaboration d’une politique de maintenance repose notamment sur un équilibre économique amenant à un meilleur compromis (coût et disponibilité, par exemple). La soussection suivante positionne la surveillance suivant ces deux types de maintenance. 1.4.2 Rôle de la surveillance Dans une approche de maintenance innovante, la surveillance occupe une place fondamentale (Raccoceanu, 2006). La surveillance est considérée dans nos travaux comme un dispositif passif, informationnel, qui n’influence pas le comportement du système cible sous surveillance. Ainsi, un système de surveillance est non-intrusif vis-à-vis d’un système cible. Ce dispositif délivre des informations pertinentes sur l’état d’un système cible pour déclencher des interventions de maintenance (maintenance préventive conditionnelle) et assister au mieux un opérateur de maintenance pour rétablir un système en panne (maintenance corrective). Par exemple, une défaillance ayant conduit à une panne d’un système cible peut être décryptée spontanément par un système de surveillance. Le système de surveillance transmet ainsi des informations sur l’état de ce système au centre de maintenance (figure 1.4). Ces informations concernent, par exemple, les éléments potentiellement responsables de la panne ainsi que des actions de maintenance à réaliser sur le système cible pour le rétablir dans un état fonctionnel. Le centre de maintenance génère alors une demande d’intervention aux opérateurs de maintenance chargés d’intervenir sur le système cible (tâche de maintenance corrective, par exemple). Les interventions de maintenance corrective sont alors mieux préparées et les durées des réparations sont maîtrisées. Figure 1.4. Système de surveillance pour l’aide à la maintenance.CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 20 Dans une approche de maintenance préventive conditionnelle (maintenance prédictive ou CBM : Condition Based Maintenance), l’objectif d’un système de surveillance est d’émettre des alertes avant la défaillance du système cible pour prévenir les pannes. Cette surveillance prédictive (ou dynamique) se focalise ainsi sur les tendances de l’évolution de l’état du système sous surveillance dans le temps. Les informations transmises aux personnels de maintenance permettent alors de signaler des dégradations ou des baisses de performance des éléments du système à un stade précoce de leur développement. La nature des informations fournies par un système de surveillance dépend des profils des utilisateurs finaux et diffère donc selon leur expertise (opérateurs de maintenance, concepteurs du système, par exemple) (Alanen et al., 2006). Dans le cadre d’une surveillance pour l’aide à la maintenance au sens intervention, un système de surveillance doit incriminer des éléments à remplacer ou à réparer bien connus des opérateurs de maintenance. Par exemple, certains systèmes cibles comportent des Unités Remplaçables en Ligne (URL ou LRU : Line Replaceable Unit). Une URL peut être déposée et échangée rapidement pour optimiser les interventions de maintenance et réduire ainsi les temps d’indisponibilité des systèmes (Dievart et al., 2010). Par conséquent, une tâche de maintenance associée à une URL constitue une information pertinente pour un opérateur de maintenance. Néanmoins, suivant le niveau de complexité de la tâche de maintenance à réaliser, un opérateur de maintenance peut être habilité ou non à intervenir sur le système cible. Les informations de surveillance doivent donc être adaptées au niveau de qualification des utilisateurs du système de surveillance. La surveillance est généralement réalisée en-ligne, pendant le fonctionnement du système cible sous surveillance, mais certaines fonctions de la surveillance peuvent être exécutées hors-ligne. C’est le cas notamment du diagnostic, dont l’exécution a posteriori peut être possible sur la base des symptômes détectés sur le système (Azarian et al., 2010). La partie suivante décrit les principales fonctions d’un système de surveillance. 2. Fonctions d’un système de surveillance Un système de surveillance regroupe deux composantes essentielles : “voir” et “comprendre” (Basseville et Cordier, 1996). La première permet d’observer et de détecter des déviations du comportement du système sous surveillance par rapport à un comportement de référence (perception). La seconde détermine les composants potentiellement responsables des phénomènes observés et recherche les causes (interprétation). Dans cette partie, les principales fonctions d’un système de surveillance mises en œuvre pour des approches de maintenance de type conditionnelle (maintenance prédictive ou CBM) et corrective sont présentées. Les fonctions assurées par un système de surveillance s’inscrivent dans différentes communautés de Recherche, et sont notamment au centre des thématiques SHM (System Health Management) et PHM (Pronostics and Health Management) (Medina-Oliva et al., 2012 ; Reed et al., 2011). Dans ce cadre, un système de surveillance comprend généralement l’acquisition de données, la détection d’anomalies de fonctionnement, le diagnostic, le pronostic et l’élaboration de recommandations de maintenance (Guillén et al., 2013 ; Vachtsevanos et Lewis, 2006). Ces différentes fonctions ont pour but de convertir un flux de données brutes, difficilement exploitable pour un opérateur de maintenance, en informations pertinentes, relatives à l’état de santé du système sous surveillance et aux opérations de maintenance à réaliser selon cet état (Abichou, 2013). Ainsi, un système de surveillance CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 21 permet de déterminer l’état d’un système (état normal ou anormal d’un système cible, par exemple) et lorsque ce système présente des anomalies de fonctionnement, il exécute les tâches de diagnostic et de pronostic. Selon les symptômes du système et les conclusions du diagnostic et du pronostic, il prescrit des recommandations de maintenance ou suggère des changements opérationnels afin que le système puisse accomplir sa mission. La première tâche d’un système de surveillance consiste à recueillir des données brutes sur le système sous surveillance. Cette fonction d’acquisition de données est généralement réalisée à l’aide de méthodes dites non-destructives, n’altérant pas le fonctionnement du système sous surveillance (IAEA, 2007). Suivant l’état de santé du système sous surveillance, différentes fonctions sont par la suite sollicitées. L’activité d’un système de surveillance diffère selon la présence ou non d’une défaillance au sein du système sous surveillance. La figure 1.5 cidessous présente les principales fonctions d’un système de surveillance avant l’occurrence d’une défaillance (surveillance dynamique) et après la défaillance du système sous surveillance (surveillance classique). Figure 1.5. Fonctions de surveillance dynamique et classique, adaptée de (Raccoceanu, 2006). Comme évoqué précédemment, la surveillance dynamique vise à éviter la défaillance du système sous surveillance. Elle consiste alors à détecter et à diagnostiquer des dégradations ou des baisses de performance du système sous surveillance (Bengtsson, 2003). Par la suite, l’objectif est de pouvoir prédire (pronostiquer) des défaillances dans le futur, en projetant l’état de santé actuel du système sous surveillance dans le temps (Tobon-Mejia et al., 2012). La surveillance dynamique regroupe ainsi les fonctions de détection prédictive de dégradations, de diagnostic prédictif et de pronostic. Notons que les résultats du diagnostic et du pronostic doivent être délivrés dans un temps opportun aux personnels de maintenance afin que des actions de maintenance puissent être exécutées sur le système avant la panne. De plus, cette surveillance dynamique doit être suffisamment robuste pour ne pas délivrer des alertes intempestives aux opérateurs de maintenance. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 22 La surveillance classique intervient après l’occurrence d’une défaillance. Dans ce cas, cette surveillance consiste à détecter les défaillances survenues dans le système sous surveillance et à les diagnostiquer. Lorsque le système sous surveillance est en état de panne, le diagnostic permet de rechercher les causes et de localiser les éléments défaillants du système. Cette tâche peut s’avérer laborieuse pour un opérateur de maintenance, notamment lorsqu’il s’agit d’un système cible constitué de multiples éléments (Azarian et al., 2010 ; Khol et Bauer, 2010). Un diagnostic difficile peut conduire un opérateur de maintenance à déposer des éléments non contributeurs de la panne ou à remplacer des éléments non défaillants, engendrant des coûts excessifs de maintenance. Différentes approches ont ainsi été proposées pour automatiser cette tâche devenant trop complexe pour un opérateur de maintenance (Feldman, 2010). Enfin, un système de surveillance s’appuie sur les informations de diagnostic et de pronostic pour élaborer des recommandations de maintenance et délivrer ces informations aux personnels de maintenance. Les différentes fonctions de surveillance illustrées sur la figure 1.5 sont détaillées dans les sections suivantes. 2.1 Détection La détection relève de la composante “voir” d’un système de surveillance. A partir de données recueillies sur le système sous surveillance, la fonction détection permet de déceler la présence de dégradations (surveillance dynamique) ou de défaillances (surveillance classique) dans ce système, et donc de qualifier le comportement observé du système de normal ou d’anormal. La fonction détection génère des signaux porteurs de symptômes à partir des observations, également nommés résidus ou discordances par certaines communautés (Cordier et al., 2000 ; Roth et al., 2011). Par exemple, une approche usuelle permettant de générer des symptômes consiste à comparer certaines grandeurs observées à des seuils caractérisant une situation anormale. Le franchissement d’un seuil indique une anomalie de fonctionnement et provoque le déclenchement d’une alarme (Basseville et Cordier, 1996). Les inconvénients de ces tests de dépassement de seuils résident dans la génération de fausses alarmes (seuil trop faible) et dans la non-détection de certains symptômes (seuil trop élevé). Certains équipements exécutent ce type de test pendant leur fonctionnement pour générer des alarmes et fournir une aide aux opérateurs de maintenance lors de la phase de diagnostic (Lefebvre, 2000). Cependant, les alarmes générées par ces tests intégrés (BIT : Built-In Test) représentent essentiellement des symptômes sans informations relatives à leurs causes. Le diagnostic établi par un opérateur de maintenance sur la base de ces événements est parfois erroné (Pecht et al., 2001). 2.2 Diagnostic Le diagnostic prend en charge l’interprétation des anomalies de fonctionnement du système sous surveillance et constitue la composante “comprendre” d’un système de surveillance. La fonction diagnostic doit permettre de lever l’ambiguïté sur le phénomène à l’origine d’une dégradation ou d’une défaillance particulière à partir des symptômes délivrés par la fonction détection. Pour ce faire, la fonction diagnostic fait appel à une connaissance du système sous surveillance. Cette connaissance intègre, par exemple, une référence du fonctionnement normal (comportement nominal) ou du fonctionnement anormal (comportement en présence de défaillances) du système sous surveillance (Ribot, 2009). Les principales méthodes de diagnostic développées par différentes communautés de Recherche sont présentées en annexes de ce manuscrit. La fonction diagnostic évalue l’état de santé actuel d’un système en recherchant les causes (fautes) à l’origine d’une dégradation (diagnostic prédictif) ou d’une défaillance particulière CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 23 (diagnostic de défaillances) et en localisant les éléments du système à remplacer ou à réparer. Il s’agit d’une fonction commune à la maintenance prédictive et à la maintenance corrective permettant d’incriminer des éléments défectueux et de déterminer les actions à entreprendre (IAEA, 2007). Le diagnostic prédictif se focalise avant tout sur l’analyse de défaillances progressives (dégradations) pour éviter la panne et planifier à l’avance les interventions de maintenance (commande de pièces de rechanges et gestion du personnel de maintenance, par exemple). Néanmoins, il existe toujours des défaillances soudaines (imprévisibles) ne pouvant être anticipées et devant faire l’objet d’un diagnostic (Jardine et al., 2006). Contrairement aux signaux émis par la fonction détection, la fonction diagnostic est en mesure de fournir des informations de haut niveau à un opérateur de maintenance, en précisant les causes probables des dysfonctionnements détectés (Basseville et Cordier, 1996). Suivant les besoins des utilisateurs du système de surveillance, le résultat d’un diagnostic peut permettre d’identifier par exemple un composant physique défectueux ou un mode de défaillance (Mathur et al., 2001). 2.3 Pronostic La fonction pronostic se concentre sur l’évolution des défaillances progressives et exploite généralement l’état de santé actuel d’un système (résultats du diagnostic prédictif) pour évaluer son état de santé futur. Bien qu’il n’existe aucune définition stabilisée et unanime du concept de pronostic, différentes définitions convergent vers une fonction capable de déterminer la durée de vie restante avant la défaillance d’un système, nommée RUL (Remaining Useful Life), ou la probabilité d’un système à fonctionner pendant un certain temps (El koujok, 2010). Le pronostic est spécifique à la maintenance prédictive et essentielle dans une approche CBM (Alanen et al., 2006). Il permet d’anticiper au mieux les interventions de maintenance suivant la prédiction de l'état futur d’un équipement (Gulledge et al., 2010). Par nature, le pronostic vise à anticiper l’état d’un système dans le futur et amène des incertitudes (Medina-Oliva et al., 2012). En effet, le pronostic de l’état futur d’un système doit non seulement considérer l’état actuel du système, mais également des données relatives à ce système dans le futur (prévisions d’utilisation du système, informations sur l’environnement futur du système, futures opérations de maintenance exécutées sur le système, par exemple), qui influent sur son état de dégradation. Ainsi, le pronostic doit prévoir l’état futur d’un système et fournir une durée de vie résiduelle à partir d’une connaissance à priori sur ce système (lois de dégradations, par exemple), d’une connaissance d’informations passées (historique des modes de fonctionnement passés), présentes (état courant) et futures (Cocheteux et al., 2007). Cette durée de vie résiduelle avant la défaillance peut être exprimée, par exemple, en unités de temps (heures de fonctionnement), en distances à parcourir (nombre de kilomètres) ou en nombre de sollicitations (nombre de cycles) (Ribot, 2009). 2.4 Elaboration de conseils En fonction de l’état de santé actuel et de la prévision de l’état de santé du système, délivrés respectivement par les fonctions de surveillance classique et dynamique, le système de surveillance élabore des recommandations sur les opérations de maintenance à réaliser (actions préventives et correctives), ou privilégie un mode de fonctionnement ou une configuration à adopter pour que le système puisse achever sa mission en évitant la panne (Bengtsson, 2003). L’état de santé d’un système est le support principal pour orienter les services de maintenance sur les interventions à effectuer, et peut être défini par le diagnostic et le pronostic du système (Dievart, 2010). La fonction d’élaboration de conseils assiste principalement l’opérateur de maintenance dans le choix des actions de maintenance à CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 24 entreprendre (remplacement d’un élément du système en priorité selon son état de santé ou son RUL, par exemple). Par ailleurs, le bilan de santé dressé par cette fonction peut également alerter les services de conception, pour améliorer la qualité du système, revoir sa conception, ou impacter la conception et la fabrication d’une future génération de produits (Gulledge et al., 2010 ; Vichare et al., 2007). Cette fonction d’aide à la maintenance s’inscrit également dans les activités de gestion de la santé des équipements (Equipment Health Management) dans le cycle de vie des produits. 3. Modèle d’architecture de surveillance Après avoir décrit précédemment les principales fonctions d’un système de surveillance, cette partie présente deux architectures considérées comme des références dans la littérature pour le développement de systèmes de surveillance. Une architecture sera retenue en tant que modèle dans nos travaux pour la surveillance des systèmes cibles considérés. Un modèle d’architecture de surveillance doit être suffisamment générique pour supporter de nombreux algorithmes de traitement et de diagnostic (Park et al., 2006). Parmi les architectures de surveillance recensées dans la littérature s’insérant dans les thématiques SHM-PHM (System Health Management - Pronostics and Health Management), une architecture apparaît comme un standard de référence (Gucik-Derigny, 2011 ; Kunche et al., 2012 ; Sreenuch et al., 2013). Il s’agit du standard OSA-CBM (Open System Architecture - Condition-Based Maintenance) diffusé par le consensus MIMOSA (Machinery Information Management Open Systems Alliance) (OSA-CBM, 2006). Le standard OSA-CBM résulte initialement des travaux de Recherche de (Lebold et Thurston, 2001) et (Lebold et al., 2003), impliquant différents industriels et visant à définir un modèle d’architecture de surveillance. Ces travaux ont permis d’établir un modèle d’architecture pour le développement de systèmes de surveillance dans un cadre de maintenance CBM. Le modèle d’architecture proposé repose sur différentes couches fonctionnelles implémentées sous forme de modules. Ce modèle générique a donné lieu à une série de normes enregistrées sous le numéro ISO 13374 et à une implémentation de référence nommée OSA-CBM. Dans cette partie, ces deux standards complémentaires d’architectures seront dans un premier temps présentés. Par la suite, les différentes problématiques liées à la surveillance des systèmes cibles seront exposées. Enfin, les principales exigences attendues d’un système de surveillance seront définies. 3.1 Standards d’architectures de surveillance Les sous-sections suivantes précisent les différentes couches fonctionnelles définies par la norme ISO 13374, ainsi que les interfaces spécifiées par le standard OSA-CBM. Certains standards additionnels et spécifiques à la mise en œuvre d’un système de surveillance ne seront pas abordés dans nos travaux (interfaces physiques, configurations, interopérabilité, diffusion des informations, par exemple) (Sheppard et al., 2009). 3.1.1 Norme ISO 13374 Depuis 2003, la norme ISO 13374 établit les lignes directrices générales des spécifications pour la surveillance et le diagnostic d’état des machines. Ces spécifications logicielles portent sur le traitement, la communication et la présentation de données de surveillance indépendamment de la technologie utilisée (ISO13374-1, 2003). La première partie de cette norme (partie 1 : lignes directrices générales) définit un modèle d’architecture de surveillance CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 25 en six couches successives de traitement et deux couches d’interface transversales (figure 1.6). Les couches de traitement #1 à #3 sont liées à la technologie du système sous surveillance et les couches #4 à #6, de plus haut niveau, assurent les tâches de diagnostic, de pronostic et d’aide à la maintenance. Cette norme définit également deux couches d’interface (#7 et #8) permettant de présenter des informations issues des différentes couches de traitement aux utilisateurs, et d’assurer une liaison avec des systèmes externes (transmission et stockage des données, paramétrage des différentes couches, par exemple). Figure 1.6. Modèle d’architecture ISO 13374, adaptée de (ISO 13374-1, 2003). Les couches fonctionnelles définies par cette norme sont détaillées ci-après. Les termes associés aux différentes couches sont repris de la version originale de la norme. · Data Acquisition (#1-DA) : cette couche d’acquisition de données permet de convertir un signal délivré par un capteur ou un transducteur en un paramètre numérique représentant une quantité physique, auquel est associé différentes informations (datation, données de calibration, configuration du capteur utilisé, par exemple). · Data Manipulation (#2-DM) : cette couche de manipulation de données analyse des signaux, effectue un calcul de descripteurs significatifs (caractéristiques), et réalise des traitements et transformations de signaux à partir de mesures brutes. · State Detection (#3-SD) : cette couche de détection d’état recherche des anomalies sur les signaux traités et doit déterminer la zone d’anomalie correspondante (si elle existe) sur laquelle se situe ces signaux, dans le but de générer des alertes ou des alarmes.CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 26 · Health Assessment (#4-HA) : cette couche d’évaluation de la santé réalise le diagnostic des fautes détectées et détermine l’état de santé courant de l’équipement ou du processus, en considérant l’ensemble des informations d’états. · Pronostic Assessment (#5-PA) : cette couche d’évaluation pronostic détermine les états de santé et les modes de défaillances futurs à partir de l’évaluation de l’état de santé courant et de la projection de l’utilisation de l’équipement ou du processus, et détermine des prédictions de durées de vie résiduelle (Remaining Useful Life). · Advisory Generation (#6-AG) : cette couche de génération de conseils fournit des informations claires et concrètes sur des actions de maintenance nécessaires ou concernant des modifications opérationnelles à apporter pour optimiser la durée de vie du processus et/ou de l’équipement. · Information Presentation (#7) : cette couche est une interface permettant de présenter des données pertinentes issues des différentes couches à des personnels qualifiés, telles que des courbes de tendances et des zones d’anomalies associées. Elle doit fournir aux analystes les données nécessaires pour identifier, confirmer ou comprendre un état anormal. Par ailleurs, cette couche assure une transformation de données en une forme présentant clairement les informations nécessaires pour prendre des décisions sur les actions de maintenance à réaliser. · External Systems (#8) : cette couche permet une liaison rapide avec des systèmes externes, et notamment avec un système de maintenance (accès à l’historique des interventions de maintenance, transmission des recommandations de maintenance ou de requêtes d’intervention de maintenance, par exemple), et avec un système de contrôle d’exploitation (accès aux prévisions de l’utilisation de l’équipement, transmission de requêtes de changements opérationnels ou de mise hors service de l’équipement, par exemple). Le concept d’état de santé mentionné dans la norme ISO 13374 (health state) n’est pas clairement défini. L’état de santé d’un équipement repose généralement sur l’expertise métier et dépend des traitements réalisés par les couches #4 à #6 du modèle. Néanmoins, la première partie de cette norme évoque un indice de santé associé à un équipement (health index) allant de 0 (défaillance complète de l’équipement) à 10 (équipement comme neuf). La seconde partie de la norme ISO 13374 (partie 2 : traitement des données) caractérise les différents modules associés aux couches successives de traitement présentées sur la figure 1.6 (ISO 13374-2, 2007). Un module peut implémenter des fonctionnalités relatives à une ou plusieurs couches de traitement du modèle. De plus, cette norme suggère la manière dont ces modules peuvent être agencés pour former une architecture opérationnelle de surveillance. Ces modules peuvent notamment être répartis sur différents supports d’exécution interconnectés entre eux. La figure 1.7 ci-dessous illustre un exemple d’architecture opérationnelle, dans laquelle chaque module est supporté par un dispositif matériel et implémente les fonctionnalités d’une couche du modèle. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 27 Figure 1.7. Exemple d’architecture opérationnelle, adaptée de (ISO 13374-2, 2007). Le medium de communication situé au centre de la figure 1.7, représente le support des différentes communications entre ces modules et peut être réalisé au travers de différentes technologies. Ainsi, les modules de l’architecture ne résident pas nécessairement sur le même support et peuvent être distants les uns des autres. Cette approche permet également d’intégrer des modules développés par différents fournisseurs pour former un système de surveillance modulaire. Des exemples d’échanges d’informations entre ces modules sont proposés dans la troisième partie de la norme (partie 3 : échange), diffusée en 2012 (ISO 13374-3, 2012). 3.1.2 OSA-CBM Le standard OSA-CBM implémente précisément les six couches de traitement définies par la norme ISO 13374 (figure 1.5). Comme la norme ISO 13374, le standard OSA-CBM ne spécifie pas les traitements et les algorithmes internes aux différents modules. En revanche, ce standard définit les types et les structures de données à utiliser pour le traitement et la communication des résultats, ainsi que la manière dont les informations doivent être transférées entre les modules et les lieux de stockage (OSA-CBM, 2006). Il s’agit d’un standard d’interface, imposant des interfaces entre les modules d’un système de surveillance suivant une approche CBM, et favorisant l’interopérabilité entre ces modules. Ainsi, différents fournisseurs peuvent proposer des algorithmes propriétaires sous forme de modules au standard OSA-CBM. Ce standard permet de dissocier les algorithmes de traitements encapsulés dans les modules (algorithmes propriétaires) des interfaces génériques des modules (figure 1.8). CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 28 Figure 1.8. Exemple de module OSA-CBM, adaptée de (OSA-CBM, 2006). Les spécifications du standard OSA-CBM sont diffusées sous forme de diagrammes de classes UML (Unified Modeling Language) et sont indépendantes de la technologie mise en œuvre pour le développement des modules de traitement. Le concepteur du système de surveillance doit alors sélectionner une technologie spécifique pour la mise en œuvre des modules de traitement et définir les communications nécessaires entre ces modules. Le standard OSA-CBM définit une typologie des échanges possibles entre modules sur la base des recommandations de la norme ISO 13374 (partie 3 : communication). La figure 1.9 cidessous illustre les différents types de communications définis par le standard OSA-CBM. Figure 1.9. Interfaces entre modules, adaptée de (OSA-CBM, 2006). CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 29 Un module OSA-CBM peut communiquer avec un ou plusieurs modules selon quatre types d’interface : · Synchrone (type 1) : ce mécanisme permet un échange direct entre un module producteur d’informations (serveur) et un module consommateur (client). Un module consommateur indique à un module producteur les informations qu’il souhaite recevoir et attend que ces informations soient disponibles et transmises par le module producteur avant de poursuivre ses traitements. · Asynchrone (type 2) : ce mécanisme permet à deux modules d’entretenir et de maintenir une communication bidirectionnelle. Dans ce mode, un module consommateur souhaitant obtenir des données de la part d’un module producteur n’attend pas que ces données soient disponibles avant de continuer ses traitements (dialogue de type requêtes-réponses entre deux modules, par exemple). Par ailleurs, un module producteur peut transmettre spontanément des informations à un ou plusieurs modules consommateurs de manière périodique ou événementielle. · Service (type 3) : ce mécanisme permet une communication unidirectionnelle entre un ou plusieurs modules producteurs d’informations et un module consommateur. Cette interface peut être mise en œuvre, par exemple, pour des besoins de stockage d’informations (archivage des informations par un module consommateur), ou pour la gestion des requêtes d’intervention de maintenance (transmission des ordres de maintenance vers un système de maintenance consommateur). · Souscription (type 4) : ce mécanisme permet à un module consommateur de souscrire à des informations auprès d’un module producteur. Le module consommateur souscripteur reçoit alors ces informations de manière asynchrone (régulièrement ou sur alertes), dès que les informations élaborées par le module producteur sont disponibles. Les modules de traitement sont généralement successifs, afin de transformer des données brutes collectées sur un système sous surveillance en informations pertinentes. Cependant, ces liens logiques entre modules ne sont pas imposés par le standard OSA-CBM ou la norme ISO 1337. Ainsi, un module peut en principe accéder à n’importe quel autre module lorsque ces modules partagent un même medium de communication. Le standard OSA-CBM a été développé sur la base d’un autre standard MIMOSA, décrit selon un même système d’information relationnel commun (CRIS) : le standard OSA-EAI (Open System Architecture Enterprise Application Integration). Il s’agit d’un standard visant à faciliter l’échange d’informations entre différentes applications métiers d’une entreprise, y compris des informations relatives à la maintenance, au diagnostic et au pronostic (OSA-EAI, 2010). La norme ISO 13374 étant moins restrictive sur la mise en œuvre des couches fonctionnelles du modèle que le standard OSA-CBM, elle sera retenue dans la suite de nos travaux. La section suivante soulève les différentes problématiques liées à la surveillance des systèmes cibles suivant les spécifications de cette norme. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 30 3.2 Problématiques de la surveillance des systèmes cibles considérés La norme ISO 13374 a été initialement développée pour la surveillance de machines ou d’équipements industriels isolés (machine tournante, processus d’usinage, par exemple). En l’absence de standards dédiés à la surveillance des systèmes cibles considérés dans nos travaux, ce modèle offre une décomposition fonctionnelle générique d’un système de surveillance. De plus, cette norme constitue un modèle de référence pour la surveillance de certains systèmes cibles, notamment dans les domaines des transports et de l’industrie (Gorinevsky et al., 2010 ; Naedele et al., 2004). Cependant, des difficultés se présentent lorsque ce modèle d’architecture doit être instancié pour la surveillance d’un système cible. La figure 1.10 ci-dessous illustre les principales difficultés à appréhender pour la surveillance d’un tel système suivant ce modèle d’architecture. A partir des six couches fonctionnelles de ce modèle, plusieurs alternatives se présentent aux concepteurs d’un système de surveillance. Ces couches fonctionnelles peuvent être réparties selon deux axes : · répartition “verticale” des couches (1) : les traitements associés aux couches fonctionnelles ISO 13374 peuvent être réalisés au plus près du système cible (traitements embarqués) ou être pris en charge par le centre de maintenance (traitements distants). · répartition “horizontale” des couches (2) : la surveillance d’un système cible passe par la surveillance de ses sous-systèmes. Par conséquent, les traitements associés aux couches fonctionnelles ISO 13374 doivent être déployés suivant les sous-systèmes du système cible, dont la technologie diffère d’un sous-système à un autre. Figure 1.10. Surveillance d’un système cible suivant les couches fonctionnelles ISO 13374. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 31 Les sous-sections suivantes précisent les principales contraintes à considérer pour la surveillance de systèmes cibles. Notons que ces contraintes dépendent des domaines d’applications des systèmes cibles introduits au début de ce chapitre. Dans ces travaux, le domaine des transports ferroviaires a été retenu comme cadre applicatif. Par conséquent, la suite de ce manuscrit se concentre sur la surveillance de systèmes cibles mobiles. 3.2.1 Contraintes liées à la mobilité du système cible En considérant la répartition “verticale” des couches du modèle, une séparation des couches doit être établie suivant les traitements à effectuer à bord du système cible et les traitements à réaliser au centre de maintenance. La première couche du modèle (#1-Data Acquisition) doit au minimum être implémentée à bord du système cible, pour permettre la collecte des données et la transmission de ces données au centre de maintenance. Lorsque la quantité de données à transmettre est importante, il est préférable d’inclure la couche #2 du modèle à bord (Alanen et al., 2006). Ainsi, plus les couches du modèle résident à bord du système cible, plus les traitements embarqués sont évolués et permettent de délivrer des informations pertinentes au centre de maintenance. Cependant, il est nécessaire de tenir compte des performances requises pour mettre en œuvre les traitements associés aux couches fonctionnelles du modèle (puissance de calcul disponible à bord, capacités de stockage et de communication, par exemple). Dans le but d’optimiser les interventions de maintenance, les données relatives à la géolocalisation du système cible peuvent également être transmises au centre de maintenance. De ce fait, le système cible peut être acheminé vers l’atelier de maintenance le plus proche en fonction de son état de santé (Umiliacchi et al., 2011). Aussi, certains traitements nécessitent des données fournies par le centre de maintenance (historique des tâches de maintenance, prévisions d’utilisation du système cible, par exemple). Lorsque ces traitements sont embarqués, le centre de maintenance doit transmettre ces données au système cible. Une communication bidirectionnelle entre le système cible mobile et le centre de maintenance est alors nécessaire. 3.2.2 Contraintes liées aux sous-systèmes du système cible Suivant les couches à implémenter à bord du système cible, la répartition “horizontale” des couches concerne l’affectation des modules de traitement aux différents sous-systèmes. Comme abordé précédemment, un module de traitement peut implémenter les fonctionnalités de une ou de plusieurs couches du modèle ISO 13374. De ce fait, un module de traitement peut être affecté à un sous-système, à un groupe de sous-systèmes, ou à l’ensemble des soussystèmes. Les contraintes associées à la mise en œuvre de ces modules de traitement sont précisées ci-après. · Répartition spatiale des sous-systèmes : les sous-systèmes sont généralement implantés dans différentes zones du système cible et peuvent interagir entre eux (interactions physiques et/ou informationnelles). L’affectation des modules de traitement aux sous-systèmes peut alors être orientée suivant l’implantation de ces sous-systèmes. Aussi, les interactions entre les sous-systèmes sont à considérer lors de la mise en œuvre des modules de traitements. Par exemple, une défaillance peut engendrer des dysfonctionnements au niveau de plusieurs sous-systèmes d’un système cible (Lefebvre et al., 2000). De multiples alarmes peuvent ainsi être générées CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 32 lorsqu’un module relatif à la couche détection du modèle ISO 13374 (#3-State Detection) est affecté à chaque sous-système. · Hétérogénéité technologique des sous-systèmes : les sous-systèmes reposent sur des technologies différentes. Par conséquent, un sous-système basé sur une certaine technologie doit être associé à un module de traitement compatible avec cette technologie. De plus, le modèle ISO 13374 se concentre sur la surveillance de parties physiques d’un équipement. Cependant, les sous-systèmes considérés sont constitués de parties physiques et informationnelles. En effet, les défaillances logicielles non abordées dans la norme ISO 13374 ont un impact direct sur la disponibilité du système cible. Notons que la surveillance de parties logicielles peut être abordée de la même manière que la surveillance de parties physiques (Pipatsrisawat et al., 2009). Néanmoins, les défaillances logicielles se manifestent principalement de manière soudaine et peuvent difficilement être anticipées. · Variabilité des sous-systèmes : les sous-systèmes sont conçus par différents fournisseurs et peuvent varier entre plusieurs systèmes cibles d’une même génération (changement de fournisseur, obsolescence de composants, ajout de fonctionnalités, par exemple) (Azarian et al., 2011). La répartition “horizontale” des couches du modèle doit alors être adaptée aux évolutions des différents sous-systèmes du système cible. Par exemple, un même sous-système peut présenter des caractéristiques différentes entre deux systèmes cibles, ou ne pas être implanté sur un autre système cible. Dans ce cas, une modification doit pouvoir être apportée aux modules de traitement sans impliquer une refonte de l’architecture de surveillance. Aussi, certains modules de traitement peuvent être réutilisés pour la surveillance de sous-systèmes ayant les mêmes caractéristiques. 3.2.4 Contraintes liées à l’environnement du système cible Lorsque le système cible est immergé dans un environnement, il est soumis à différents contextes opérationnels (Monnin et al., 2011). L’environnement du système cible peut potentiellement provoquer des défaillances lors de son fonctionnement. Ces défaillances sont alors signalées au centre de maintenance par le système de surveillance associé au système cible. La figure 1.11 ci-après illustre un exemple de système cible mobile situé dans son environnement. Dans cet exemple, les couches #1 à #3 du modèle ISO 13374 sont implémentées à bord du système cible et les couches #4 à #6 sont assurées par le centre de maintenance (répartition “verticale” des couches). La défaillance du système cible est supposée apparaitre sous l’effet de perturbations provenant de son environnement. Cette défaillance déclenche alors des alarmes au niveau de la couche #3 du modèle. Ces alarmes sont par la suite transmises au centre de maintenance et analysées par un opérateur de maintenance ou traitées par les couches #4 à #6 du modèle lorsqu’elles sont implémentées au sol. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 33 Figure 1.11. Exemple de surveillance d’un système cible mobile dans son environnement. L’analyse de ces alarmes au sol est délicate pour un opérateur de maintenance. Le contexte opérationnel du système cible n’étant pas connu, l’opérateur n’est pas en mesure de déterminer si ces alarmes sont liées à l’environnement du système cible ou si le système cible nécessite réellement une intervention de maintenance. Ainsi, le diagnostic établi au sol par la quatrième couche du modèle à partir de ces alarmes risque d’être erroné. En effet, les informations de contextes non exploitées par la couche diagnostic (#4- Health Assesment) sont essentielles pour interpréter les dysfonctionnements du système cible. De plus, lorsque le système cible arrive au centre de maintenance, aucun dysfonctionnement ne peut être constaté. Le système cible n’opérant plus dans le même contexte opérationnel, il est alors difficile de reproduire les conditions d’exploitation ayant conduit à une anomalie de fonctionnement. Ce phénomène nommé NFF (No Fault Found) favorise le remplacement à tort d’éléments du système cible et engendre des coûts importants de maintenance (Lanigan et al., 2011). A titre d’exemple, il peut être judicieux d’associer à une défaillance la localisation précise du système cible, qui peut être fournie aisément par un dispositif de géolocalisation (Bengston, 2003). Ceci permet d’écarter certaines défaillances liées à l’environnement du système cible. 3.2.5 Exigences d’un système de surveillance Les principales exigences associées à un système de surveillance peuvent être établies à partir du modèle d’architecture proposé par la norme ISO 13374. Une exigence fondamentale concerne la surveillance d’un système cible lors de son fonctionnement (surveillance enligne). Un système de surveillance ne doit pas altérer la performance du système cible sous surveillance. Par conséquent, les moyens d’acquisition de données associés à la première couche du modèle ISO 13374 doivent être non-intrusifs vis-à-vis du système cible sous surveillance. Dans nos travaux, un système de surveillance doit également répondre aux exigences suivantes : · Précision : le système de surveillance doit identifier précisément des éléments défectueux à remplacer ou à réparer du système cible parmi les différents soussystèmes qui composent ce système cible. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE Page 34 · Facilité d’explication : le système de surveillance doit faciliter la compréhension des informations de surveillance fournies aux opérateurs de maintenance (présentation de données brutes ayant conduit à un résultat de diagnostic, par exemple). · Adaptabilité : le système de surveillance doit être suffisamment modulaire pour faire face aux changements survenant dans le système cible (remplacement de soussystèmes, ajout ou suppression de composants, par exemple). · Réactivité : les informations de surveillance doivent être transmises dans un temps opportun au centre de maintenance afin d’optimiser les interventions de maintenance (planification d’une opération de maintenance suivant l’état de certains sous-systèmes du système cible, par exemple). · Confiance : le système de surveillance doit être suffisamment robuste pour ne pas générer de fausses alarmes (diagnostic erroné transmis à un opérateur de maintenance, par exemple). 4. Conclusion Ce premier chapitre a permis d’introduire les propriétés des systèmes cibles considérés dans nos travaux ainsi que les différentes notions relatives à la surveillance dans un contexte de maintenance. Au sein d’un système de maintenance, la surveillance peut permettre d’optimiser efficacement les interventions de maintenance préventive et corrective et accroître ainsi la disponibilité d’un système cible. Un système de surveillance assure deux composantes principales : percevoir les dysfonctionnements survenant dans un système sous surveillance et interpréter ces dysfonctionnements. Le diagnostic prend en charge l’interprétation des dysfonctionnements observés sur le système sous surveillance. Cette fonction essentielle doit permettre de déterminer les éléments défectueux du système à remplacer ou à réparer qui seront présentés aux opérateurs de maintenance. Dans ce chapitre, deux standards complémentaires d’architectures de surveillance ont été présentés : un modèle proposé par la norme ISO 13374 et une implémentation de référence de ce modèle nommé OSA-CBM. Ces deux standards décomposent un système de surveillance en six couches fonctionnelles successives. Le modèle prescrit par la norme ISO 13374 s’avère plus générique que le standard OSA-CBM et a été retenu dans le cadre de nos travaux. Cependant, la surveillance d’un système cible suivant ce modèle présente certaines difficultés exposées à la fin de ce chapitre. En effet, un système cible est constitué de sous-systèmes hétérogènes et soumis à différents contextes opérationnels. De plus, un système cible mobile est rattaché à un centre de maintenance distant. La problématique principale est de concevoir une architecture de surveillance reposant sur la norme ISO 13374 et répondant aux exigences listées en 3.2.5. Cette architecture doit permettre de surveiller un système cible mobile qui est lui-même composé de systèmes. Cette problématique constitue le verrou scientifique auquel nos travaux s’adressent. Le chapitre suivant se focalise sur la surveillance de systèmes cibles mobiles et recense les différentes approches de la littérature pour établir le diagnostic d’un tel système suivant la quatrième couche (Health Assesment) définie par la norme ISO 13374. Page 35 Chapitre II Surveillance de systèmes mobiles : état de l’art et approches de surveillance active Introduction Le précédent chapitre a mis en évidence un ensemble de problématiques et contraintes à considérer pour concevoir une architecture de surveillance associée à un système cible. Ce chapitre explore les différentes approches pour la surveillance de systèmes cibles mobiles (système de transport aérien, maritime ou ferroviaire, par exemple). Comme évoqué dans le précédent chapitre, ces systèmes cibles évoluent dans différents contextes opérationnels et communiquent avec un centre de maintenance distant. La première partie de ce chapitre présente un état de l’art des architectures de diagnostic et propose une typologie des architectures pour diagnostiquer un système cible mobile. A partir des exigences d’un système de surveillance établies dans le précédent chapitre, une architecture de diagnostic sera retenue dans la suite de nos travaux. La seconde partie de ce chapitre s’appuie sur le concept de surveillance active pour proposer des approches de modélisation de l’architecture de diagnostic choisie. Une approche de modélisation sera adoptée et reprise dans le chapitre suivant afin de proposer une architecture générique pour la surveillance de systèmes cibles mobiles. 1. Etat de l’art des architectures de diagnostic La norme ISO 13374 détaillée dans le précédent chapitre définit un modèle générique d’architecture de surveillance en six couches fonctionnelles successives, dont la quatrième couche (#4-Health Assesment) élabore le diagnostic à partir de données fournies par les couches de niveaux inférieurs. Le diagnostic joue un rôle décisif dans la performance d’une architecture de surveillance, et peut également impacter la sécurité du système cible (Koutsoukos et al., 2010). En effet, le diagnostic incrimine des éléments potentiellement responsables d’une défaillance ou d’une dégradation particulière et implique des actions de maintenance bien précises. De notre point de vue, deux alternatives se dégagent pour réaliser le diagnostic d’un système cible mobile rattaché à un centre de maintenance distant. La première consiste à collecter des données brutes sur le système cible et à transférer ces données vers un centre de maintenance, où le diagnostic est exécuté. Dans cette première approche, le système cible peut être vu comme un dispositif d’acquisition de données, générant un flux de données brutes envoyé vers le centre de maintenance. Dans la seconde approche, le système cible est considéré comme un dispositif de calcul, capable de traiter et d’interpréter ces données brutes. Le diagnostic réside alors à bord du système cible, et seules des informations pertinentes de diagnostic sont délivrées au centre de maintenance (Alanen et al., 2006 ; Bengtson, 2003). CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 36 Ces deux approches, nommées respectivement diagnostic distant et diagnostic embarqué sont illustrées par la figure 2.1. Lorsque le diagnostic est distant (figure 2.1 a), les couches #1 à #3 du modèle ISO 13374 sont implémentées à bord du système cible, tandis que les couches #4 à #6 sont prises en charge par le centre de maintenance. Dans une approche de diagnostic embarqué (figure 2.1 b), les couches #1 à #4 du modèle sont implémentées à bord du système cible et les couches #5 et #6 sont assurées par le centre de maintenance. Figure 2.1. Partitionnement du diagnostic : diagnostic distant (a) et diagnostic embarqué (b). Suivant cette dichotomie, cette partie recense les principales architectures de diagnostic pour la surveillance de systèmes cibles mobiles, en faisant abstraction des méthodes de diagnostic mises en œuvre. Ainsi, une typologie des architectures de diagnostic sera établie indépendamment des traitements internes réalisés par les couches du modèle ISO 13374. 1.1 Diagnostic distant Cette approche consiste à réaliser le diagnostic à distance dans un centre de maintenance, à partir de données collectées et prétraitées à bord du système cible par les couches #1 à #3 du modèle. Les alarmes et autres signaux brutes du système cible sont alors transférés et analysés au centre de maintenance. Le diagnostic distant est généralement réalisé de manière centralisé et doit traiter une masse de données brutes pour rechercher les causes des symptômes détectés à bord du système cible. Cette architecture, nommée Diagnostic Distant Centralisé (DDC), permet d’exploiter pleinement les capacités de stockage et de traitement disponibles au centre de maintenance. Cependant, le diagnostic peut difficilement être établi pendant le fonctionnement du système cible en raison des contraintes de communication. En effet, des volumes de données importants doivent être transférés du système cible mobile vers le centre de maintenance, impliquant des délais de transmission et de traitement. Par conséquent, les données nécessaires à l’élaboration d’un diagnostic sont généralement stockées à bord du système cible et transmises de manière périodique ou événementielle au centre de maintenance (Jianjun et al., 2007). Ces données sont alors enregistrées en-ligne pendant le CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 37 fonctionnement du système et le diagnostic est exécuté hors-ligne à posteriori (approche de type “boîte noire”). L’architecture DDC permet également d’assurer le diagnostic de plusieurs systèmes cibles mobiles (flotte de trains ou de navires, par exemple) (Monnin et al., 2011). D’un point de vue fiabilité, cette architecture présente un inconvénient majeur. Le diagnostic des différents systèmes cibles repose sur un seul et unique centre de maintenance. L’occurrence d’une défaillance en ce point sensible de l’architecture entraine une interruption du diagnostic pour l’ensemble des systèmes cibles (Ferrari, 2009). Par ailleurs, en examinant les exigences d’un système de surveillance établies dans le précédent chapitre, l’architecture DDC présente les limitations suivantes : · Précision : les données traitées au centre de maintenance représentent essentiellement des symptômes émis sous forme d’alarmes. L’interprétation de ces événements par une fonction de diagnostic au sol est parfois erronée (Azarian et al., 2011). Dans certains domaines applicatifs des systèmes cibles, le diagnostic est couramment achevé manuellement au sol par un expert à partir des alarmes générées à bord du système cible (De Ambrosi et al., 2008). · Réactivité : cette approche implique des quantités de données considérables à transférer au centre de maintenance, par exemple, par le biais de liaisons sans fil (technologies GPRS, GSMR ou Wifi) (Schwarzenbach et al., 2010). Ces transferts de données introduisent des retards non négligeables dans l’élaboration d’un diagnostic, et par conséquent, dans la planification des opérations de maintenance. · Confiance : les symptômes détectés à bord du système cible ne sont pas contextualisés. Ainsi, une alarme peut être déclenchée par l’environnement du système cible ou être provoquée par des interférences entre certains sous-systèmes (défaillances fugitives, par exemple). Notons également que certaines données peuvent être superflues (alarmes redondantes, alarmes liées aux actions du conducteur ou émises lors des interventions de maintenance, par exemple) (Sammouri et al., 2012). Ces données sont néanmoins transmises et archivées au centre de maintenance, engendrant des coûts injustifiés de transmission et de stockage. Ainsi, le contexte opérationnel du système cible n’est pas considéré lors de l’élaboration d’un diagnostic sur la base de ces alarmes. Néanmoins, cette architecture est relativement simple à mettre en œuvre et permet à des systèmes d’informations externes d’exploiter aisément les données collectées. Plusieurs implémentations de l’architecture DDC ont été réalisées dans le domaine des transports. Par exemple, la première génération de systèmes HUMS (Health and Usage Monitoring System), apparue au début des années 90, était limitée à la collecte de données et à la génération d’alarmes sur certains aéronefs (Wiig, 2006). Les principaux inconvénients de ce système résident dans la génération de fausses alarmes et dans l’interprétation de ces masses de données brutes au centre de maintenance. Dans le domaine ferroviaire, le projet Européen TrainCom a contribué à standardiser les échanges de données entre un matériel roulant ferroviaire et un centre de maintenance distant (Gatti, 2002). La communication entre le véhicule ferroviaire et un centre de maintenance au sol (ROGS : Railway Open Ground Station) est assurée par une interface de communication nommée ROGate (Railway Open Gateway). Ces spécifications ont permis à différentes applications situées au centre de maintenance de traiter les données collectées à bord des trains. Cette infrastructure de CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 38 communication a été expérimentée en Europe dans le cadre du projet EuRoMain (European Railway Open Maintenance System) (Euromain, 2002). Le principal objectif de ce projet était de définir un système d’aide à la maintenance de véhicules ferroviaires en réalisant le diagnostic à distance des différents équipements embarqués. Actuellement, les deux principaux constructeurs mondiaux de matériels ferroviaires ont adopté une architecture DDC. Les systèmes Orbita (Orbita, 2006) et TrainTracer (TrainTracer, 2006) développés respectivement par Bombardier-Transport et AlstomTransport permettent de prélever des données en temps réel sur des véhicules ferroviaires et de les transférer vers un système central (figure 2.2). Figure 2.2. Architecture du système TrainTracer, adaptée de (Sammouri et al., 2012). Les données relatives aux différents équipements implantés à bord des véhicules (accès voyageurs, climatisations, tractions, par exemple) sont transmises et stockées systématiquement sur un serveur de données (figure 2.2). Ces données brutes (états et alarmes des différents équipements embarqués, par exemple) sont exploitées par le personnel de maintenance ou traitées par différentes applications (extraction de données, analyse de tendances, diagnostic, par exemple). Ces applications sont développées par les constructeurs ou les exploitants de matériels ferroviaires. 1.2 Diagnostic embarqué Lorsque la quatrième couche du modèle ISO 13374 (#4-Health Assesment) est intégrée au sein du système cible, le diagnostic est embarqué. Cette approche vise à exécuter le diagnostic pendant le fonctionnement du système cible et offre plus d’autonomie et de réactivité. Contrairement à une architecture DDC, les données brutes sont converties en informations de CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 39 diagnostic à bord du système cible (figure 2.3). Les délais et coûts de transmission sont alors réduits car seules des informations pertinentes émanent du système cible. De plus, le diagnostic embarqué permet d’exploiter des informations contextuelles disponibles à bord du système cible. Ces informations complémentaires contribuent largement à améliorer la performance du diagnostic embarqué (Byington et al., 2003). Figure 2.3. Exemple de diagnostic embarqué, adaptée de (Hunter et al., 2013). Le diagnostic d’un système cible repose sur le diagnostic des différents sous-systèmes qui le composent (Kurien et al., 2002). Une première approche permettant de réaliser le diagnostic à bord d’un tel système consiste à déployer une couche de diagnostic sur l’ensemble des soussystèmes. Ainsi, une entité centrale de diagnostic interprète les données relatives aux différents sous-systèmes et délivre un diagnostic global du système cible. Une seconde approche envisage de fractionner la couche de diagnostic en autant d’entités de diagnostic qu’il existe de sous-systèmes. Dans cette approche, une entité de diagnostic est affectée à chaque sous-système du système cible. Le diagnostic global du système cible est alors obtenu à partir des résultats produits par les entités locales de diagnostic. Inspiré des approches de la littérature pour diagnostiquer des systèmes répartis, nous proposons de distinguer trois classes d’architectures pour réaliser le diagnostic embarqué de systèmes cibles (figure 2.4). Le diagnostic peut être centralisé, décentralisé ou réparti (également nommé distribué : distributed diagnosis) (Fabre, 2007 ; Ferrari, 2009 ; Roychoudhury et al., 2009 ; Subias, 2006). Notons que le diagnostic décentralisé ou réparti est généralement associé à une méthode de diagnostic particulière dans la littérature (Genc et Lafortune, 2003 ; Pencolé et Cordier, 2005). CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 40 Figure 2.4. Diagnostic centralisé (a), décentralisé (b) et distribué (c), adaptée de (Ferrari, 2009). Dans la première classe d’architecture, nommée Diagnostic Embarqué Centralisé (DEC), une seule entité de diagnostic est implémentée à bord du système cible et réalise le diagnostic des différents sous-systèmes. Dans une architecture de Diagnostic Embarqué Décentralisé (DED), une entité de diagnostic est implémentée pour chaque sous-système. Ces entités réalisent le diagnostic de manière indépendante et ne peuvent communiquer entre elles. Lorsque le diagnostic est distribué, chaque sous-système est également associé à une entité de diagnostic, mais ces entités peuvent communiquer entre elles. Le terme distribué fait généralement référence au medium de communication utilisé pour interconnecter ces entités de diagnostic. Dans les travaux présentés dans ce manuscrit, cette troisième classe d’architecture est nommée Diagnostic Embarqué Décentralisé et Coopératif (DEDC), afin de dissocier l’organisation de ces entités de diagnostic des solutions technologiques utilisées pour mettre en œuvre ce type d’architecture. Les sous-sections suivantes précisent ces trois catégories d’architectures. 1.1.1 Diagnostic embarqué centralisé Le diagnostic embarqué d’un système cible est généralement réalisé par une entité centrale de diagnostic, en charge de traiter les données brutes des différents sous-systèmes (Dievart et al., 2010). L’architecture DEC suppose qu’une seule entité de diagnostic puisse intégrer une connaissance de l’ensemble des sous-systèmes et établir le diagnostic global du système cible (Kurien et al., 2002). Aussi, cette entité doit être capable d’absorber et de traiter de grandes quantités de données à bord du système cible. Cette architecture peut s’avérer irréaliste pour un système cible constitué de multiples sous-systèmes. En effet, les données relatives aux sous-systèmes doivent être centralisées en un même point à bord du système cible pour être analysées. Le système cible doit alors disposer de ressources suffisantes pour supporter ces flux de données et réaliser les traitements nécessaires (volume de données important à traiter en un temps donné, par exemple). Par ailleurs, cette architecture présente des limitations en termes de fiabilité et de modularité. Par exemple, l’ajout d’un sous-système entraine systématiquement une modification des traitements réalisés par cette entité centrale de diagnostic. Un exemple d’implémentation d’une architecture DEC dans le domaine des transports aériens est le système de maintenance centralisé (CMS : Central Maintenance System). Dans cette architecture, une unité centrale effectue des traitements à partir de symptômes et autres données brutes pour élaborer un diagnostic (Balin et Stankunas, 2013). Ce système permet d’identifier les causes des anomalies de fonctionnement et élabore des recommandations pour CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 41 le personnel de bord. Les résultats du diagnostic sont archivés et peuvent également être consultés par des techniciens de maintenance. Néanmoins, ce système central doit être suffisamment performant (puissance de calcul et taille mémoire notamment) pour fournir des informations dans des délais acceptables (situation d’urgence, par exemple). 1.1.2 Diagnostic embarqué décentralisé L’architecture DED favorise le traitement des données au plus près des sous-systèmes à diagnostiquer. Dans cette architecture, chaque sous-système est diagnostiqué localement par une entité de diagnostic. Les résultats des diagnostics délivrés par ces différentes entités sont généralement transmis de manière disjointe au centre de maintenance. Le diagnostic global du système cible peut être envisagé de plusieurs manières. Il peut être considéré, par exemple, comme une juxtaposition des résultats des diagnostics locaux (Biteus, 2004). De ce fait, le diagnostic global correspond aux diagnostics des différentes parties du système cible, ce qui permet de présenter des informations plus compréhensibles aux opérateurs de maintenance. Aussi, le diagnostic global peut résulter d’une fusion des résultats de diagnostic locaux. Dans ce cas, une ou plusieurs entités supplémentaires sont chargées de collecter les résultats des diagnostics locaux et de les fusionner. Cependant, les entités de diagnostic opèrent de manière indépendante et exploitent uniquement les observations limitées de leurs sous-systèmes. En d’autres termes, ces entités de diagnostic ne communiquent pas entre elles (Qiu et Kumar, 2004). Par conséquent, une entité de diagnostic n’est pas en mesure de considérer les interactions entre les sous-systèmes lors de l’élaboration d’un diagnostic (Ferrari, 2009). Ainsi, une entité peut émettre un diagnostic erroné lorsque le sous-système auquel elle est associée est influencé par d’autres sous-systèmes. Cette catégorie d’architecture a notamment été expérimentée pour réaliser le diagnostic à bord de véhicules routiers. Par exemple, dans (Nasri et al., 2012) les auteurs proposent une architecture DED limitée au diagnostic d’une fonction sécuritaire d’un véhicule. Cette architecture met en œuvre différentes entités locales de diagnostic (diagnostiqueurs) qui intègrent une méthode de diagnostic spécifique, et dont les résultats de diagnostic sont communiqués à une entité supérieure nommée coordinateur. Ce coordinateur est implémenté à bord du véhicule et délivre un diagnostic final en fusionnant les résultats des diagnostics locaux à partir de règles. Les entités de diagnostic mises en œuvre sont intégrées aux équipements embarqués existants faisant l’objet d’un diagnostic (unités de contrôle des soussystèmes du véhicule). Les informations contextuelles relatives aux différents sous-systèmes diagnostiqués ne sont pas considérées par ces entités de diagnostic. Les résultats évoqués par les auteurs concernent l’influence des entités de diagnostic sur la fiabilité de l’architecture global du système et ne précisent pas réellement la performance du diagnostic obtenu. 1.1.3 Diagnostic embarqué décentralisé et coopératif Dans cette catégorie d’architecture, les entités de diagnostic sont agencées de la même manière que dans une architecture DED, c’est-à-dire, une entité de diagnostic est affectée à chaque sous-système du système cible. A la différence d’une architecture DED, ces entités opèrent de manière proactive et peuvent dialoguer entre elles (Zhang et Zhang, 2013). Par exemple, une entité de diagnostic peut coopérer avec d’autres entités. Elle obtient ainsi des informations complémentaires pour enrichir ses observations locales et fournir un diagnostic plus robuste. Ces informations concernent, par exemple, les états et contextes d’autres sous-CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 42 systèmes (symptômes ou modes de fonctionnement de sous-systèmes évoluant dans le même environnement, par exemple). L’architecture DEDC permet d’établir un diagnostic global du système cible suivant un schéma de communication défini entre les différentes entités de diagnostic (Provan, 2002). Les échanges entre ces entités sont généralement calqués sur les interactions existantes entre les différents sous-systèmes diagnostiqués (interactions physiques et informationnelles, par exemple) (Fabre, 2007). Les communications entre entités limitent le nombre de fausses alarmes transmises aux opérateurs de maintenance. Néanmoins, cette architecture implique des flux d’informations supplémentaires à bord du système cible par rapport aux architectures DEC et DED. Cette contrainte est compensée par un allégement des capacités de calcul requises pour réaliser le diagnostic, et par une augmentation de la fiabilité et de la modularité de l’architecture (Ferrari, 2009). Par ailleurs, cette approche est adaptée à l’architecture des systèmes cibles, dans laquelle les sous-systèmes interagissent entre eux et présentent un dispositif de calcul local (unité de contrôle disposant de processeurs et de mémoires, par exemple) (Roychoudhury et al., 2009). Les architectures DEDC développées pour la surveillance de systèmes mobiles sont relativement peu nombreuses. Par exemple, une architecture de type DEDC est proposée dans (Dievart et al., 2010) pour la surveillance d’un système de transport. Cette architecture est basée sur des entités de diagnostic reliées à une base de données commune et pouvant s’échanger des informations par le biais d’une mémoire partagée (tableau noir). Certaines entités sont autorisées à communiquer directement entre elles. Cependant, une méthode de diagnostic spécifique est exécutée par les différentes entités qui composent cette architecture. Par ailleurs, les informations contextuelles des sous-systèmes surveillés ne sont pas considérées pour améliorer la performance du diagnostic. Plus récemment, certaines architectures DEDC ont été développées dans le cadre du programme IVHM (Integrated Vehicle Health Management), introduit à l’origine dans les secteurs aéronautique et spatial (Benedettini et al., 2009). Ce concept vise à accroitre la sécurité et la fiabilité de certains systèmes de transports (avions de ligne, véhicules aériens, par exemple) et à optimiser leurs coûts de maintenance, en implémentant à leur bord des fonctions avancées de diagnostic et de pronostic (Ferreiro et al., 2012 ; Schoeller et al., 2007). Avec la création d’un centre de Recherche en collaboration avec différents industriels (IVHM-Center, 2008), la communauté IVHM contribue activement à l’élaboration de nouveaux standards (SAE-HM1, 2013). Cette communauté s’appuie notamment sur la norme ISO 13374 pour concevoir et mettre en œuvre des modules de surveillance embarqués. Par exemple, le projet VIPR (Vehicle Integrated Prognostic Reasoner) a permis de définir un modèle d’architecture pour la surveillance de véhicules aérospatiaux (Bharadwaj et al., 2013). L’architecture VIPR combine différentes entités interagissant entre elles pour établir un diagnostic global d’un véhicule. Ces entités nommées HM (Health Manager) adhérent à la structure du véhicule à diagnostiquer et sont réparties suivant trois niveaux hiérarchiques (niveau équipement, niveau régional et niveau véhicule) (figure 2.5). Au niveau hiérarchique le plus bas, chaque entité élabore des informations locales de diagnostic et de pronostic (DP) relatives à un équipement (LRU HM). Ces informations sont ensuite confiées aux entités de niveau supérieur (Area HM), capables d’analyser ces résultats en considérant les différentes régions du véhicule (implantation géographique des équipements, interdépendances entre équipements, par exemple). Enfin, les conclusions établies par ces entités sont exploitées par une entité située au niveau supérieur (Vehicle HM) chargée de délivrer un diagnostic final du véhicule. CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 43 Figure 2.5. Architecture VIPR, adaptée de (Cornhill et al., 2013). Cette architecture permet d’établir un diagnostic performant au niveau véhicule, dont le taux de fausses alarmes est faible (Cornhill et al., 2013). Néanmoins, ces entités sont généralement associées à des technologies spécifiques. De plus, le contexte opérationnel associé aux équipements n’est pas exploité par les entités qui composent cette architecture (informations relatives aux organes de contrôle des sous-systèmes, par exemple). 1.3 Typologie des architectures de diagnostic A partir des architectures exposées précédemment, une typologie des architectures de diagnostic peut être articulée autour de trois axes. · Le premier axe concerne l’implantation du diagnostic vis-à-vis du système cible à diagnostiquer. Par exemple, le diagnostic peut être exécuté à bord du système cible, à proximité du système cible (outil de diagnostic portatif, par exemple), ou être réalisé à distance dans un centre de maintenance (Alanen et al., 2006). · Le deuxième axe précise la distribution de la couche diagnostic en fonction des différents sous-systèmes à diagnostiquer. Ainsi, une entité de diagnostic peut être affectée à l’ensemble des sous-systèmes (diagnostic centralisé), ou à chaque soussystème du système cible (diagnostic décentralisé). Il est également possible d’affecter plusieurs entités de diagnostic à un même sous-système. Certains auteurs mentionnent alors une distribution spatiale ou sémantique du diagnostic (Fröhlich et al., 1999 ; Roos et al., 2003). La distribution spatiale fait référence à une répartition géographique des entités de diagnostic, où chaque entité est affectée à une certaine partie du système cible et prend en charge le diagnostic de cette partie. Une partie peut correspondre, par exemple, à un sous-système ou à un regroupement de plusieurs sous-systèmes. Dans une distribution sémantique du diagnostic, des entités de diagnostic hétérogènes sont affectées à une même partie du système cible et réalisent CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 44 conjointement le diagnostic de cette partie. Une entité de diagnostic peut être focalisée sur certains aspects de cette partie ou être spécialisée dans la résolution de certains types de problèmes (analyse de défaillances particulières, par exemple). · Le troisième axe de cette typologie détermine l’organisation des entités de diagnostic au niveau social. Suivant la structure organisationnelle des entités de diagnostic, une entité peut être autorisée ou non à coopérer avec d’autres entités. Par exemple, une entité peut interagir avec l’ensemble des entités ou avec un nombre restreint d’entités (Atlas et al., 2001). La figure 2.6 ci-dessous illustre la typologie proposée et positionne les différentes classes d’architectures définies auparavant. Le deuxième et le troisième axe concernent uniquement les architectures permettant de réaliser le diagnostic à bord de systèmes cibles. En effet, les architectures implémentant le diagnostic à distance impliquent des délais significatifs dans l’analyse des données et dans l’exécution des opérations de maintenance (temps de transmission, de stockage et de traitement des données collectées). Par exemple, l’architecture RCD souffre d’un manque de robustesse et de précision (taux de fausses alarmes important, informations de diagnostic erronées, non pertinentes ou non contextualisées). Par conséquent, les architectures pour lesquelles le diagnostic est exécuté à distance ne seront pas retenues dans la suite de nos travaux. Figure 2.6. Positionnement des architectures de diagnostic suivant la typologie proposée. Parmi les architectures de diagnostic embarqué, l’architecture DEDC s’avère être une approche pertinente pour élaborer le diagnostic de systèmes cibles mobiles. Cette architecture permet d’établir un diagnostic global du système cible à partir des informations délivrées par différentes entités de diagnostic implantées à bord du système cible et pouvant interagir entre CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 45 elles. En considérant les exigences d’un système de surveillance établies dans le précédent chapitre, cette architecture présente les avantages suivants : · Précision : les données brutes sont traitées au plus près des équipements surveillés, ce qui permet de garantir la qualité des observations et par conséquent la précision du diagnostic. · Adaptabilité : les changements survenant dans un sous-système du système cible (modification, ajout ou suppression de composants, par exemple) impactent uniquement l’entité de diagnostic qui lui est associée. · Réactivité : les délais d’interventions de maintenance sont réduits car le système cible est capable de transmettre des informations de diagnostic directement exploitables par les services de maintenance en ciblant des actions de maintenance précises. · Confiance : les informations contextuelles disponibles à bord du système cible peuvent être exploitées par les différentes entités de diagnostic. De plus, ces entités sont capables de communiquer entre elles pour obtenir davantage d’informations sur leur environnement et limiter ainsi le nombre de fausses alarmes. Ces travaux se positionnent dans cette dernière catégorie d’architecture. Dans la suite de ce manuscrit, une architecture de type DEDC est retenue pour la surveillance de systèmes cibles mobiles. La partie suivante propose des approches permettant de modéliser les entités qui composent cette architecture en s’appuyant sur le concept de surveillance active. 2. Approches de surveillance active L’architecture DEDC retenue précédemment requiert la définition de différentes entités en interaction dont l’objectif est de réaliser le diagnostic à bord d’un système cible. Ainsi, cette approche implique une augmentation des capacités informationnelles, décisionnelles et communicationnelles des sous-systèmes à diagnostiquer. Dans ce cadre, les travaux de Recherche menés au sein de notre équipe sur le développement de produits “actifs” ont permis de faire émerger la notion d’activité associée à un produit tout au long de son cycle de vie (Sallez, 2012). Cette notion d’activité s’oppose au caractère passif d’un produit classique, contraint de subir les interventions d’un système de soutien externe (système de distribution ou de maintenance, par exemple) et n’ayant pas la capacité de prendre des initiatives vis-à-vis de ce système. L’activité associée à un système cible (ou produit) est supportée par un système d’augmentation. Ce dernier réalise un ensemble de fonctions d’augmentation au plus près du système cible et lui confère, au minimum, la capacité de déclencher un événement. Cette faculté permet au système cible devenu “actif” d’exprimer un besoin en émettant un signal (demande d’une intervention ou d’un service particulier, par exemple). Bien entendu, cette activité minimale peut être complétée par d’autres activités plus complexes (mémorisation, apprentissage, coopération entre produits actifs, par exemple). Le concept d’augmentation consiste à associer un système d’augmentation à un produit passif lui permettant d’être “actif” pendant une ou plusieurs phases de son cycle de vie (phase de fabrication, de distribution et d’usage, par exemple) (Sallez et al., 2010). Cette partie décrit le concept de surveillance active reposant sur le concept d’augmentation et suggère des approches permettant de modéliser l’activité associée à un système cible.CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 46 2.1 Concept de surveillance active La surveillance active est une application du concept d’augmentation en phase d’usage qui consiste à doter un système cible de capacités d’auto-surveillance (Sallez et al., 2011). Ce concept implique une augmentation des sous-systèmes du système cible par des fonctions de surveillance. Ces fonctions sont supportées par différents systèmes d’augmentations situés au plus près des sous-systèmes surveillés. Le système cible constitué de sous-systèmes “actif” est donc lui-même “actif”. Ce système cible “actif” peut alors délivrer des informations de surveillance de manière spontanée pendant son exploitation (état de santé, résultats de diagnostic, par exemple). Dans une perspective d’évolution du système cible (développement de nouvelles fonctionnalités, par exemple), les fonctions de surveillance supportées par un système d’augmentation pourront être prises en charge de façon native par le système cible. Dans l’architecture DEDC retenue dans nos travaux, chaque sous-système réalise les couches fonctionnelles #1 à #4 du modèle ISO 13374. Un système d’augmentation peut alors être défini pour supporter les fonctionnalités associées à ces couches et élaborer le diagnostic d’un sous-système (figure 2.7). Ce système d’augmentation présente des capacités décisionnelles et interactionnelles lui permettant de dialoguer avec d’autres systèmes d’augmentation et de transmettre des informations de diagnostic à un centre de maintenance. Figure 2.7. Exemple de surveillance active basée sur le concept d’augmentation. Le concept de surveillance active est particulièrement adapté pour aborder la surveillance d’un système cible mobile suivant une architecture de type DEDC. En effet, chaque sous système du système cible peut être associé à une entité de surveillance “active” autonome, capable d’interagir avec d’autres entités. Inspiré des modèles d’architectures de systèmes de pilotage manufacturiers (Trentesaux, 2009), les sections suivantes présentent les principales approches permettant de modéliser ces entités de surveillance “actives” : l’approche multiagents et l’approche holonique.CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 47 2.2 Approche multi-agents L’intelligence artificielle distribuée (IAD), axe de l’intelligence artificielle (IA), s’intéresse aux domaines pour lesquels une seule entité est inadaptée ou inefficace pour résoudre certains types de problèmes. Cette communauté a introduit le concept de systèmes constitués d’entités autonomes ayant la capacité d’agir sur leur environnement et de communiquer avec d’autres entités pour atteindre un objectif donné. Un système constitué de ces entités ou agents est nommé Système Multi-Agents (SMA). 2.2.1 Notion d’agent De nombreuses définitions du terme agent sont apparues depuis l’émergence des systèmes multi-agents. En effet, cette notion est utilisée dans de nombreux domaines (Tweedale et al., 2007). Bien qu’aucune définition précise ne soit acceptée, nous pouvons citer les deux définitions suivantes couramment rencontrées dans la littérature. · Un agent est un système informatique, situé dans un environnement, et qui agit d'une façon autonome et flexible pour atteindre les objectifs (buts) pour lesquels il a été conçu (Wooldrige et Jennings, 1995). · Un agent est une entité autonome, réelle ou abstraite, qui est capable d’agir sur ellemême et sur son environnement, qui, dans un univers multi-agents, peut communiquer avec d’autres agents, et dont le comportement est la conséquence de ses observations, de ses connaissances et des interactions avec les autres agents (Ferber, 1995). Les agents sont décrits dans un système et diffèrent donc d’un système à un autre. La plupart des typologies d’agents établies dans la littérature sont axées sur le degré de raisonnement des agents. Un agent peut être vu comme un processus permettant de lier ses perceptions à ses actions. Une classification usuelle dissocie deux catégories d’agents définies ci-après : les agents réactifs et les agents cognitifs (Demazeau et Briot, 2001). · Agents réactifs : ces agents sont des entités très simples, n’ayant quasiment pas de capacité de raisonnement et ne disposant pas de mémoire. Ils perçoivent leur environnement mais n’ont pas la capacité de le représenter symboliquement. Leurs capacités limitées répondent uniquement à des stimuli provenant de l’environnement. Les actions d’un agent sont directement liées à ses perceptions par une fonction reflexe (stimulation-exécution). Par conséquent, les agents réactifs adoptent des mécanismes de communication restreints. L’interaction entre ces agents et l’environnement fait émerger une organisation cohérente et intelligente au niveau d’un système d’agents. Ces agents sont qualifiés d’intelligents au niveau d’un groupe d’agents réactifs (Müller, 2000). · Agents cognitifs : ces agents, au contraire, plus complexes, possèdent des capacités de raisonnement individuelles et une base de connaissance. Ces agents ont la capacité de percevoir et de constituer une représentation explicite de leur environnement (Ferber, 1995). Un agent cognitif peut être amené à raisonner suivant ses perceptions passées, ses interactions avec d’autres agents, ses actions antérieurement initiées, pour planifier au mieux ses actions futures. Ils ont potentiellement la capacité d’apprendre et de reconnaître certaines situations. Un agent cognitif adopte un langage de CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 48 communication plus élaboré (mécanismes d’envois de messages et requêtes, par exemple). Dans une organisation d’agents cognitifs, les agents accomplissent leur propre but en cherchant à optimiser leur utilité au sein du collectif d’agents. Jusqu’à présent, cette approche a donné lieu aux travaux les plus avancés. Les agents réactifs et cognitifs sont généralement décrits comme deux entités antagonistes. Cependant, certains agents hybrides peuvent posséder des propriétés réactives et cognitives. A titre d’exemple, un agent hybride peut mener un raisonnement à l’aide de ses connaissances et présenter certaines aptitudes à réagir aux évènements. 2.2.2 Architectures à base d’agents Un agent a généralement pour vocation d’agir au sein d’une organisation d’agents. Un système multi-agents (SMA) est un ensemble d’agents qui évoluent dans un même environnement. Un SMA peut être constitué, par exemple, d’agents purement réactifs, cognitifs ou hybrides. Dans une approche “voyelle” (Demazeau, 2001), on distingue quatre dimensions permettant d’élaborer un système multi-agents : l’Agent, l’Environnement, l’Interaction et l’Organisation (AEIO). L’organisation décrit les relations entre les agents du système suivant un modèle organisationnel (modèles bio-inspirés, par exemple). Dans un SMA, la communication est primordiale pour assurer les différentes interactions entre agents. Elle peut être assimilée à une forme d’action locale, par exemple, d’un agent vers un autre agent, ou d’un agent vers plusieurs agents (diffusion de messages au sein d’un groupe d’agents, par exemple). Figure 2.8. Exemple de SMA appliqué à la surveillance de systèmes, adaptée de (Ferber, 1995). CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 49 L’architecture interne d’un agent, c’est à dire, la décomposition modulaire utilisée pour relier les perceptions d’un agent à ses actions permet également de différencier les systèmes multiagents. Les types d’architectures les plus connues sont les architectures suivantes (Grondin, 2008) : · l’architecture horizontale monocouche : l’agent est constitué d’un seul module ayant accès à la perception et à l’action (figure 2.9a), · l’architecture horizontale avec plusieurs couches : l’agent est constitué de plusieurs modules où chaque module a accès simultanément à la perception et à l’action (figure 2.9b), · l’architecture verticale modulaire : l’agent est constitué de plusieurs modules, dont le premier accède à la perception et le dernier module accède à l’action (figure 2.9c), · l’architecture verticale en couches : l’agent est constitué de plusieurs modules dont un seul module peut accéder à la perception et à l’action (figure 2.9d). Figure 2.9. Exemples d’architectures internes d’un agent, adaptée de (Müller et al., 1995). Les architectures horizontales sont majoritairement employées pour le développement d’agents réactifs, comme l’architecture de subsumption (Brooks, 1986), tandis que des architectures verticales sont plutôt associées à des agents cognitifs, telle que l’architecture BDI (Belief Desire Intention) (Rao et Georgeff, 1995). Un agent hybride peut présenter une architecture verticale ou horizontale. Par exemple, l’architecture InteRRaP est une architecture verticale modulaire d’agents hybrides qui comporte plusieurs couches fonctionnelles (Müller et al., 1995). L’approche multi-agents a notamment été exploitée pour la surveillance de systèmes répartis dans (Albert et al., 2001 ; Mangina et al., 2001 ; Naedele et al., 2004). 2.3 Approche holonique Les systèmes holoniques ont été introduits par le philosophe hongrois Arthur Koestler (Koestler, 1967). Ces systèmes sont basés sur le concept de “holon”, terme formé par le préfixe grec Holos (le tout) et du suffixe on qui suggère une particule élémentaire ou partie d’un tout. Une propriété importante de ces systèmes est la récursivité des entités mises en œuvre nommées holons. L’approche holonique peut s’appliquer à de nombreux systèmes, qui peuvent être naturels (systèmes biologiques) ou artificiels (systèmes conçus par l’homme). CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 50 2.3.1 Concept de holon Un holon est décrit comme une entité autonome faisant partie d’un tout qui présente un caractère individuel et coopératif pour atteindre un objectif donné (Koestler, 1967). Le concept de holon repose sur la notion de récursivité (Suaréz et al., 2013). Un holon peut être vu comme une partie constitutive d’un holon de niveau supérieur, et comme un tout, composé lui-même de holons de niveaux inférieurs. Cette dualité associée au holon est appelée effet Janus par Koestler, en référence au nom de la divinité romaine regardant dans deux directions opposées. Ainsi, les deux principales propriétés d’un un holon sont l’autonomie et la coopération. La première confère au holon une identité propre d’un ensemble autonome et cohérent. La seconde représente l’aspect social d’un holon, contribuant partiellement au fonctionnement global du système suivant des mécanismes de coopérations avec d’autres holons. 2.3.2 Architectures holoniques Un système de holons qui peuvent coopérer pour atteindre un but ou un objectif donné est nommé holarchie. Comme l’illustre la figure 2.10, une holarchie est formée par des holons récursifs organisés de manière hiérarchisée. Naturellement, un holon peut être composé d’autres holons, être lui-même considéré comme une holarchie et également appartenir à une holarchie plus vaste. Dans une holarchie, un holon peut interagir avec d’autres holons situés au niveau inférieur ou supérieur (interactions “verticales”) et avec des holons situés au même niveau que lui (interactions “horizontales” représentées sur la figure 2.10) dans un espace de coopération. Figure 2.10. Exemple de système de holons ou holarchie, adaptée de (Gaud, 2007). L’holarchie définit les règles de base pour la coopération entre holons et de ce fait limite leur autonomie (Tanaya et al., 1997). Les conflits résultants d’une coopération entre holons au sein d’un même espace de coopération peuvent être résolus par un holon de niveau supérieur. Ce holon émet alors une décision à partir des observations de ses holons subordonnés. CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 51 L’approche holonique a notamment été appliquée au pilotage de systèmes manufacturiers dans le cadre du projet HMS (Holonic Manufacturing System) entrepris par la communauté internationale IMS (Intelligent Manufacturing System) (IMS, 2013). Dans ce domaine, l’approche holonique a permis de concevoir de nouveaux modèles d’architectures, reposant sur une décentralisation des capacités de traitement et de décision à travers des entités autonomes et communicantes (Blanc et al., 2008 ; Deen, 2003). Les travaux importants proposés par cette communauté représentent une rupture avec les architectures centralisées de pilotage de systèmes manufacturiers et se proposent de répondre aux nouveaux besoins et contraintes des industriels (flexibilité, personnalisation de masse des produits, traçabilité des produits, par exemple) (Pujo et al., 2009). Un HMS est une holarchie dans laquelle les holons sont autonomes, coopératifs et entretiennent des liens de subordinations avec des holons hiérarchiquement supérieurs (commandes, instructions, par exemple). Suivant les modèles d’architectures holoniques proposés (ou holarchies), différents types de holons ont été définis pour désigner des entités d’un système manufacturier. Les architectures PROSA (Van Brussel et al., 1998) et ADACOR (Leitão et Restivo, 2006) proposent par exemple d’associer des holons aux machines de production (holon ressource, holon machine), aux produits manufacturés (holon produit), aux opérations à effectuer (holon ordre, holon tâche), ou encore aux tâches de supervision (holon staff, holon supervision). La figure 2.11 présente une architecture générique de holon adoptée par cette communauté. Dans ce modèle, un holon comporte une partie “traitement de l’information” et une partie “traitement physique” (optionnelle). La partie “traitement de l’information” est subdivisée en trois modules : une interface de communication nécessaire pour interagir avec les autres holons (interface inter-holons), une intelligence décisionnelle pour élaborer un raisonnement interne et disposer d’une certaine autonomie (centre de décision), et une interface pour interagir avec des opérateurs humains (interface homme-holon). Figure 2.11. Architecture interne d’un holon, adaptée de (Bussman, 1998). La partie “traitement physique” se compose d’un module de commande (contrôle physique) et d’un module opérant (traitement physique). Cette partie est décrite comme facultative, dans la mesure où un holon peut être constitué uniquement d’une partie “traitement de l’information”.CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 52 2.4 Comparaison des approches Les communautés holoniques et agents convergent vers des spécifications communes, car ces deux approches reposent sur les mêmes principes fondamentaux d’autonomie et de coopération en explorant la distribution et la décentralisation des entités et des fonctions (Leitão, 2004). Un holon possède des propriétés similaires à celles d’un agent, mais se distingue de par sa récursivité (Giret et Botti, 2004). En effet, dans la plupart des modèles d’agents, un agent est considéré comme une entité atomique (Gaud, 2007). Néanmoins, certaines approches considèrent que des agents peuvent se regrouper pour former un agent de niveau supérieur. Suivant ce concept, un système multi-agents holonique (holomas) est un SMA ayant une structure récursive. Les agents d’un certain niveau sont regroupés en organisations qui sont considérées comme des entités individuelles à un niveau supérieur. La communauté agent s’intéresse aux comportements des entités qui composent un SMA (agent réactif ou cognitif, par exemple) et au comportement global émergent d’un SMA. Dans une approche holonique, un holon est récursif et associé à une partie matérielle (tangible), qui n’est pas abordée dans les modèles d’agents. L’approche holonique est donc complémentaire à l’approche multi-agents. D’un point de vue conceptuel, le holon est un concept et l’agent est à la fois un concept et une technologie associée. Un modèle à base d’agents est approprié pour implémenter la modularité et la décentralisation des structures holoniques (Leitão, 2004 ; Marík et al., 2002). Ainsi, la technologie agent peut fournir les outils nécessaires pour mettre en œuvre les traitements informationnels associés aux holons tout comme les mécanismes d’interactions entre ces entités. Dans le cadre de nos travaux, une approche à base d’agents peut être exploitée pour modéliser les entités de surveillance de l’architecture DEDC. Comme l’illustre l’exemple présenté sur la figure 2.12, une entité de surveillance “active” peut être décrite par un agent. Sur ce même exemple, en considérant une approche holonique, un holon permet de considérer à la fois la partie physique surveillée d’un système cible et l’entité de surveillance “active” qui lui est associée. Cette seconde approche permet également de décrire la récursivité du système cible. Figure 2.12. Périmètres de modélisation considérés dans le cadre de notre étude. Une approche holonique est retenue dans la suite de nos travaux pour modéliser les soussystèmes surveillés d’un système cible mobile suivant une architecture DEDC. Cette approche qui considère les aspects matériels et immatériels des systèmes a notamment été expérimentée pour la surveillance de systèmes naturels (Louati et al., 2012 ; Unland, 2003) et artificiels (Jarvis et Jarvis, 2003 ; McFarlane et al., 1995 ; Silva et al., 2012 ; Stecca et al., 2013). CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART ET APPROCHES DE SURVEILLANCE ACTIVE Page 53 3. Conclusion Ce chapitre a dressé tout d’abord un état de l’art des architectures de diagnostic pour la surveillance de systèmes cibles mobiles. La surveillance d’un tel système nécessite une prise en charge de fonctions de surveillance par le système cible mobile et par un centre de maintenance distant. La première partie de ce chapitre a défini quatre classes d’architectures de diagnostic et a proposé une typologie des architectures de diagnostic. Afin de répondre aux exigences exprimées dans le précédent chapitre, une architecture de diagnostic dans laquelle le diagnostic est embarqué et réalisé de manière décentralisée et coopérative a été retenue pour la surveillance de systèmes cibles mobiles (architecture DEDC). Dans la littérature, les applications relatives à ce type d’architecture sont généralement spécifiques à une méthode de diagnostic et manquent de généricité. Par ailleurs, les informations contextuelles disponibles à bord d’un système cible ne sont pas suffisamment valorisées et considérées pour améliorer la performance du diagnostic embarqué. En s’appuyant sur le concept de surveillance active, la seconde partie de ce chapitre a présenté deux approches pertinentes pour modéliser les entités qui composent cette architecture : les systèmes multi-agents et les systèmes holoniques. Une étude comparative de ces deux approches a favorisée l’adoption d’une approche holonique pour la surveillance de système cibles mobiles. Le chapitre suivant propose une architecture générique de surveillance “active” de type DEDC reposant sur une approche holonique. Cette architecture représente la composante surveillance d’un système de maintenance associé à un système cible. Page 54 Chapitre III Proposition d’une architecture holonique pour la surveillance active de systèmes cibles mobiles Introduction Dans le précédent chapitre, une étude comparative des architectures de diagnostic pour la surveillance de systèmes cibles mobiles a été présentée. Cette analyse a permis de retenir une catégorie d’architecture dans laquelle le diagnostic est implanté à bord du système cible et élaboré de manière décentralisée et coopérative (architecture DEDC). Ce chapitre est consacré à la proposition d’une architecture de type DEDC pour la surveillance de systèmes cibles mobiles. L’approche proposée s’appuie sur le concept de surveillance active décrit dans le précédent chapitre en adoptant une approche holonique. Dans ce chapitre, une architecture de surveillance active basée sur des entités de surveillance autonomes et coopératives est proposée. La première partie de ce chapitre présente tout d’abord une approche de modélisation d’un système cible à surveiller. Ce modèle permettra de caractériser les entités de surveillance qui lui sont associées et de proposer par la suite notre architecture holonique de surveillance. La deuxième partie se concentre sur la structure interne des entités qui composent cette architecture holonique de surveillance. Elle détaille notamment les fonctionnalités supportées par ces entités. 1. Système de surveillance holonique L’adoption d’une architecture de type DEDC pour la surveillance de systèmes cibles mobiles nécessite une identification des sous-systèmes à surveiller qui composent un système cible. Un partitionnement du système cible en sous-systèmes est alors nécessaire avant de définir les entités de surveillance qui concourent à l’élaboration d’un diagnostic. Cette décomposition peut être abordée par une approche analytique, qui consiste à décomposer un problème en différents sous-problèmes indépendants. Cependant, cette approche connait certaines limitations, notamment en raison du niveau de complexité croissant des systèmes actuels et à la manière dont ces systèmes sont conçus (Fabre, 2007). Une approche complémentaire, se focalisant non seulement sur une analyse séparée des soussystèmes d’un système cible, mais considérant également un système cible dans son ensemble s’avère nécessaire. L’approche systémique adoptée au début de ce manuscrit (cf. chapitre I, section 1.1) peut ainsi remédier aux difficultés de compréhension d’un système cible. Elle permet de conserver une vision globale d’un système cible, constitué de sous-systèmes en interaction, eux-mêmes considérés comme des systèmes. CHAPITRE III : PROPOSITION D’UNE ARCHITECTURE HOLONIQUE POUR LA SURVEILLANCE ACTIVE DE SYSTÈMES CIBLES MOBILES Page 55 Dans cette partie, la décomposition d’un système cibles en sous-systèmes est abordée en adoptant une approche systémique. Après un rappel des principaux concepts de la systémique, la section 1.1 présente un modèle de système cible à surveiller basé sur cette approche. La section 1.2 spécifie les entités de surveillance associées à ce modèle suivant une approche holonique. La section 1.3 propose notre architecture holonique de surveillance basée sur ces entités de surveillance. 1.1 Approche de modélisation du système cible à surveiller La systémique a pour objet l’étude et la compréhension de systèmes dont l’analyse par une approche analytique s’avère difficile ou impossible, et vise à établir une représentation du système étudié par le biais de modèles qualitatifs (Donnadieu et al., 2003). Elle s’appuie notamment sur les interactions entre les éléments constituant un système pour en comprendre son comportement global. Ces liens portent aussi bien sur de simples relations de causes à effets que sur des échanges d’informations, de flux de matière ou d’énergie. Ces interactions s’opèrent à des niveaux hiérarchiques différents, formant plusieurs niveaux organisationnels structurés de manière hiérarchisée. La systémique met en œuvre trois points de vue nécessaires à l’analyse et à la représentation d’un système (c.f. annexe A). Cette triangulation systémique regroupe les visions fonctionnelle, organique et historique du système étudié dans le but d’approfondir sa compréhension (Le Moigne, 1994). Outre ces différents axes d’analyse d’un système, la démarche systémique préconise une identification des soussystèmes (sous-ensembles ou composants) d’un système, afin de mettre en évidence les relations que ces entités entretiennent entre elles et leurs rôles au sein d’un système. Contrairement à une approche analytique, ces entités ne coïncident pas nécessairement avec des composants élémentaires d’un système tangible à analyser. Aussi, cette décomposition soulève la question du partitionnement d’un système en sous-systèmes défini par le modélisateur. Bien que subjectif, l’établissement de frontières (ou périmètres) des soussystèmes peut être dicté par certains critères, notamment à partir des différents points de vue d’un système abordés précédemment. La dimension fonctionnelle, s’intéressant aux fonctions assurées par le système, et la dimension organique, basée sur la structure des éléments constituant le système et leurs répétitivités, sont deux exemples de critères permettant de décomposer un système cible. La systémique proposant un cadre méthodologique d’analyse et de conception de systèmes cibles, conformément à un fonctionnement désiré ou à une finalité du système, elle peut également être exploitée pour comprendre les dysfonctionnements survenant dans de tels systèmes (Belhadaoui, 2011). Cette section propose une modélisation d’un système cible basée sur une approche systémique. Ce modèle de système cible à surveiller servira par la suite de socle à l’élaboration d’une architecture de surveillance. Le modèle proposé repose sur les hypothèses établies dans le premier chapitre et plus précisément : · décomposition : le système cible à surveiller est supposé être organisé suivant une structure hiérarchisée de contrôle et décomposable structurellement en un ensemble fini de sous-systèmes. Le partitionnement du système cible en sous-systèmes est supposé être établi sans chevauchements entre les frontières des sous-systèmes. Chaque sous-système est supposé être contrôlé par un système de niveau supérieur, · hétérogénéité technologique : le système cible et ses sous-systèmes sont supposés être conçus avec des technologies hétérogènes. Néanmoins, le système cible comme chaque sous-système présente une structure interne identique. Il se compose d’une partie contrôle (partie décisionnelle) et d’une partie sous-contrôle (partie opérante), CHAPITRE III : PROPOSITION D’UNE ARCHITECTURE HOLONIQUE POUR LA SURVEILLANCE ACTIVE DE SYSTÈMES CIBLES MOBILES Page 56 · environnement : les parties contrôle et sous-contrôle sont supposées interagir dans un environnement spécifique. Un contexte opérationnel de nature physique (température, champ électrique, par exemple) ou informationnelle (mode de fonctionnement, identifiant de l’utilisateur du système, par exemple) est supposé être une propriété intrinsèque du système cible comme de chaque sous-système constituant ce système. La figure 3.1 présente un modèle organique du système cible considéré. Ce modèle est inspiré de l’architecture de systèmes constitués d’une partie contrôle et d’une partie sous-contrôle (Isermann, 2008). En accord avec nos hypothèses, ce modèle présente les propriétés suivantes : · une partie contrôle : entité de traitement de l’information et de commande, en charge d’assurer un comportement cohérent de la partie sous-contrôle, conformément aux spécifications fonctionnelles imposées par le concepteur, · une partie sous-contrôle : ensemble d’éléments soumis aux commandes de la partie contrôle, comprenant notamment des éléments matériels (capteurs, transducteurs, par exemple) ou informationnels (estimateurs, observateurs logiciels, par exemple) rendant compte de l’état de cette partie, · des signaux de commandes (U) : ensemble d’ordres délivrés par la partie contrôle dans le but de commander la partie sous-contrôle, · des signaux de mesures (Y) : ensemble de signaux fournis par des dispositifs de la partie sous-contrôle et exploités par la partie contrôle pour l’élaboration des signaux de commandes, · un contexte opérationnel (C) : ensemble d’informations relatif à l’environnement du système et/ou au système lui-même caractérisant une situation de fonctionnement. Figure 3.1. Modèle organique du système cible considéré. Le système cible à surveiller, représenté suivant une vision systémique et noté Σ sur la figure 3.1, comporte deux parties en interaction opérant dans un contexte opérationnel. Ce modèle organique correspond à une vue globale du système cible considéré, au plus haut niveau de sa structure hiérarchique. De par ses propriétés récursives, ce système englobe un ensemble fini de sous-systèmes de niveaux inférieurs ayant une structure interne identique. Les soussystèmes sont organisés en niveaux et contrôlés par un système de niveau supérieur. Dans le modèle proposé, chaque système est caractérisé par la position qu’il occupe dans la composition d’un système plus vaste. Par la suite, le sous-système ݆ du système Σ௜ sera noté Σ௜Ȁ௝, et le ݇ ème sous-système du sous-système Σ௜Ȁ௝ sera noté Σ௜Ȁ௝Ȁ௞. La figure 3.2 ci-dessous propose un modèle organique arborescent du système cible représenté sur la figure 3.1. Suivant ce modèle, le système global, noté Σ௜ sur la figure 3.2, est décomposé en une succession de sous-systèmes situés à différents niveaux. Chaque sous-système est décomposé en sous-systèmes de niveau inférieur, eux-mêmes décomposés en sous-systèmes. CHAPITRE III : PROPOSITION D’UNE ARCHITECTURE HOLONIQUE POUR LA SURVEILLANCE ACTIVE DE SYSTÈMES CIBLES MOBILES Page 57 Par exemple sur la figure 3.2, le système Σ௜ de niveau n est décomposé en trois sous-systèmes (Σ௜Ȁ௝, Σ௜Ȁ௝ឬ et Σ௜Ȁ௝̶) de niveau n-1, et le sous-système Σ௜Ȁ௝ est lui-même décomposé en deux sous-systèmes de niveau n-2 (Σ௜Ȁ௝Ȁ௞ et Σ௜Ȁ௝Ȁ௞ឬ). Le sous-système Σ௜Ȁ௝Ȁ௞ឬ est décomposé de nouveau en sous-systèmes élémentaires de niveau inférieur (Σ௜Ȁ௝Ȁ௞ឬȀ௟ et Σ௜Ȁ௝Ȁ௞ឬȀ௟ឬ). Figure 3.2. Modèle organique arborescent du système cible considéré. Comme évoqué précédemment chaque système est immergé dans un contexte opérationnel. Le contexte du système Σ௜ et de son sous-système Σ௜Ȁ௝ seront par la suite notés respectivement ௜ et ௜Ȁ௝ . Une propriété importante de l’approche systémique proposée est l’agrégation des informations de contexte entre les différents sous-systèmes constituant un système cible. En effet, le contexte opérationnel d’un sous-système caractérise la situation de fonctionnement de ce sous-système et également de ses sous-systèmes de niveaux inférieurs. Par ailleurs, les sous-systèmes sont soumis à un même contexte relatif au niveau hiérarchique le plus élevé. Par exemple, sur le modèle de la figure 3.2, les sous-systèmes Σ௜Ȁ௝Ȁ௞ឬȀ௟ et Σ௜Ȁ௝Ȁ௞ឬȀ௟ឬ opèrent tous deux dans le contexte ௜Ȁ௝Ȁ௞ឬ , relatif au sous-système Σ௜Ȁ௝Ȁ௞ឬ , et également dans ௜Ȁ௝ , contexte commun aux sous-systèmes Σ௜Ȁ௝Ȁ௞ et Σ௜Ȁ௝Ȁ௞ឬ . Les différents sous-systèmes du système Σ௜sont soumis au même contexte ௜ . La structure hiérarchisée de contrôle du système cible considéré implique nécessairement des interactions “verticales” de nature informationnelle entre les différents niveaux de décomposition du système cible (relations d’autorités entre un sous-système et son soussystème de niveau inférieur, par exemple). De plus, des interactions “horizontales” de nature informationnelle et physique sont envisageables au sein d’un même niveau (échanges d’informations ou influences physiques entre sous-systèmes, par exemple). Simulations num´eriques m´eso- et micro-´echelles des circulations locales g´en´er´ees par des ˆıles tropicales : cas de l’archipel de la Guadeloupe avec une application `a la dispersion de polluants (WRF-LES-FLEXPART) Rapha¨el C´ec´e To cite this version: Rapha¨el C´ec´e. Simulations num´eriques m´eso- et micro-´echelles des circulations locales g´en´er´ees par des ˆıles tropicales : cas de l’archipel de la Guadeloupe avec une application `a la dispersion de polluants (WRF-LES-FLEXPART). Meteorology. Universit´e des Antilles et de la Guyane, 2014. French. HAL Id: tel-01074600 https://hal.archives-ouvertes.fr/tel-01074600 Submitted on 14 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Universite des Antilles et de la Guyane ´ THESE ` En vue de l’obtention du grade de DOCTEUR DE L’UNIVERSITE DES ANTILLES ´ ET DE LA GUYANE Ecole doctorale pluridisciplinaire ´ Sp´ecialit´e : Physique de l’atmosph`ere Pr´esent´ee et soutenue par Rapha¨el C´ec´e le 10 juillet 2014 Simulations num´eriques m´eso- et micro-´echelles des circulations locales g´en´er´ees par des ˆıles tropicales : cas de l’archipel de la Guadeloupe avec une application `a la dispersion de polluants (WRF-LES-FLEXPART) Composition du jury : Herv´e Delbarre (Pr, LPCA, Universit´e du Littoral) Pr´esident Evelyne Richard (Directeur de recherche, LA, CNRS Toulouse) Rapporteur ´ Blaise Nsom (Pr, LBMS, Universit´e de Bretagne Occidentale) Rapporteur Narcisse Zahibo (Pr, LaRGE, Universit´e des Antilles et de la Guyane) Directeur Didier Bernard (MCF, LaRGE, Universit´e des Antilles et de la Guyane) Co-encadrant Jean-Fran¸cois Dorville (Dr, Lecturer, Universit´e des West Indies, Jama¨ıque) Co-encadrant Philippe Palany (Ing´enieur, Direction Interr´egionale de M´et´eo-France) Invit´e”Les philosophes n’ont fait qu’interpr´eter le monde de diff´erentes mani`eres, ce qui importe c’est de le transformer.“ Karl Marx, Th`eses sur Feuerbach (1845)UNIVERSITE DES ANTILLES ET DE LA GUYANE ´ R´esum´e Facult´e des Sciences Exactes et Naturelles D´epartement de Physique Docteur de l’Universit´e des Antilles et de la Guyane Simulations num´eriques m´eso- et micro-´echelles des circulations locales g´en´er´ees par des ˆıles tropicales : cas de l’archipel de la Guadeloupe avec une application `a la dispersion de polluants (WRF-LES-FLEXPART) par Rapha¨el C´ec´e Ce travail est l’expression d’une volont´e de chercheurs, de la Cara¨ıbe d’am´eliorer les connaissances scientifiques m´eso- et micro-m´et´eorologiques appliqu´ees aux milieux insulaires sous influence des aliz´es et de d´evelopper la recherche dans ces domaines. On sait que le ph´enom`ene m´et´eorologique le plus remarquable impactant les ˆıles de la Cara¨ıbe reste le cyclone tropical. Mais d’autres ph´enom`enes, `a des ´echelles inf´erieures, telles que les pluies intenses, les houles, la d´egradation de la qualit´e de l’air ont une importance aig¨ue en termes de risques naturels ou de risques sur la sant´e. Ces exemples attestent la n´ecessit´e d’utiliser des m´ethodes de descente d’´echelle pour exploiter l’information m´et´eorologique et/ou climatique de grande ´echelle et d´eriver des sc´enarios locaux et r´egionaux appliqu´es aux territoires insulaires. Ce d´efi est important car l’attente d’analyses scientifiques pertinentes dans ces domaines est grande. Les travaux pr´esent´es dans ce m´emoire ont pour principaux objectifs la simulation num´erique puis l’analyse des m´ecanismes m´eso- et micro-´echelles qui induisent des circulations locales diurnes et nocturnes sur l’archipel de la Guadeloupe `a l’aide de codes num´eriques m´et´eorologiques ´eprouv´es car largement utilis´es en recherche et en pr´evision op´erationnelle. Ils constituent donc la premi`ere ´etude de mod´elisation num´erique `a haute r´esolution en basse atmosph`ere, par descente d’´echelle dynamique, pour des intervalles d’espace compris entre 1 km et 111 m sur cet archipel. Le mod`ele atmosph´erique Weather Research and Forecasting ARW V3.4 (WRF ARW), non-hydrostatique, a ´et´e utilis´e pour l’ensemble des simulations pour mod´eliser la troposph`ere depuis l’´echelle globale `a l’´echelle de la turbulence.Trois situations m´et´eorologiques classiques r´eelles d’une dur´ee de 48 heures, correspondant `a 80 % des situations m´et´eorologiques observ´ees dans la zone, aliz´es soutenus (AS), aliz´es moyens (AM), aliz´es faibles (AF) ont ´et´e examin´ees. Ces situations sont caract´eris´ees par les valeurs du nombre de Froude local suivantes : 0,82 (AS), 0,41 (AM) et 0,21 (AF). Six domaines de mod´elisation ont ´et´e s´electionn´es pour effectuer les descentes d’´echelle dynamiques : D01 (maille de 27 km), D02 (maille de 9 km), D03 (maille de 3 km), D04 (maille de 1 km), D05 (maille de 333 m) et D06 (maille de 111 m) avec soixante-dix niveaux verticaux. Les quatre premiers domaines (D01 `a D04) couvrent l’archipel de la Guadeloupe et sont utilis´es en mode m´eso-´echelle `a l’aide d’un sch´ema d’ensemble de couche limite plan´etaire YSU. Les domaines D05 (couvrant l’ˆıle de la Basse-Terre et le centre de l’archipel) et D06 (couvrant la zone littorale et rurale du Petit Cul-de-Sac Marin et la zone urbaine de l’agglom´eration pointoise) sont utilis´es en mode Large Eddy Simulation avec une fermeture de la turbulence 1,5 TKE 3D. Le mod`ele WRF a ´et´e forc´e toutes les six heures par l’assimilation des champs d’analyses globales du mod`ele NCEP FNL (1➦ de r´esolution). Les simulations effectu´ees ont permis d’obtenir des champs de variables m´et´eorologiques 10-minutes `a tr`es hautes r´esolutions spatiales. Les r´esultats des simulations m´eso- et micro-´echelles ont ´et´e confront´es aux valeurs exp´erimentales obtenues `a l’aide de capteurs plac´es sur des mˆats m´et´eorologiques (campagne Atmo-Mangrov et r´eseau de mesure M´et´eo-France). Il s’agissait d’optimiser l’utilisation des couplages de codes num´eriques tout en conservant la possibilit´e de les confronter aux observations exp´erimentales. Les r´esultats des simulations num´eriques micro-´echelles, des diff´erents cas (AS, AM, AF) sont utilis´ees pour forcer (c’est-`a-dire d´efinir les conditions limites) un mod`ele lagrangien de dispersion de particules : FLEXPART. Le syst`eme coupl´e FLEXPART-WRF a ´et´e employ´e dans le domaine D06 pour ´etudier la dispersion du panache d’oxydes d’azote ´emis par la principale usine de production d’´electricit´e de l’ˆıle. La concordance entre les s´eries spatio-temporelles simulation/exp´erimental a ´et´e qualifi´ee `a l’aide d’outils statistiques de comparaison (MAE, MBE, IOA). Ces estimateurs montrent que pour les champs m´et´eorologiques classiques, il y a une bonne ad´equation entre les mesures exp´erimentales et les simulations obtenues aux fines ´echelles. Les simulations retrouvent le comportement du vent et les principales circulations observ´ees exp´erimentalement. L’´etude des effets des conditions aux limites, particuli`erement le changement de carte d’occupation des sols, am´eliore sensiblement les r´esultats. En aliz´es faibles, les coupes verticales pointant l’´energie cin´etique turbulente, la temp´erature virtuelle et la masse volumique t´emoignent de l’existence d’un ´ecoulement catabatique. Il se caract´erise par un front bien d´efini amenant des vents maximums situ´es dansles premiers niveaux en arri`ere de la surface frontale et des tourbillons verticaux en aval de l’´ecoulement. Cette circulation d’ouest prend naissance, en fin d’apr`es-midi, sur les reliefs de la Soufri`ere, descend les pentes au vent de l’ˆıle de la Basse-Terre et passe sur la zone littorale d’Arnouville 2 `a 3 h apr`es son initiation. Pendant la nuit, ce front oscille horizontalement sur la surface maritime du Petit Cul-deSac Marin en s’accroissant verticalement. En effet, le front s’´etant r´echauff´e en passant au-dessus de la surface maritime, sa propagation est frein´ee sur l’ˆıle de la Grande-Terre, au sol fortement refroidi par le rayonnement infra-rouge. Les simulations micro-´echelles ont ´et´e utiles pour caract´eriser l’aptitude de cet ´ecoulement catabatique nocturne `a se propager en aval, d’Arnouville vers la r´egion pointoise, et pr´eciser sa capacit´e `a d´egrader la qualit´e de l’air dans la zone urbaine. Les pics de concentration de NOx simul´ees surviennent aux mˆemes p´eriodes que les observations exp´erimentales mais sont surestim´ees et d´ecal´es temporellement d’une heure. Des surestimations des vitesses de vent ont ´et´e observ´ees en condition nocturne. Ces impr´ecisions sont dues au manque de r´ealisme des conditions limites (occupation des sols, topographie, temp´erature de surface de la mer) et pourront ˆetre am´elior´ees dans le futur. Les estimateurs statistiques ont montr´e une bonne ad´equation entre les mesures exp´erimentales, les comparaisons graphiques (en s´eries temporelles et profils de concentration) ont quant `a elles permis de mieux caract´eriser la dynamique des concentrations de polluants et leurs possibles interactions avec les circulations locales. Ces r´esultats num´eriques laissent envisager de nombreuses applications dans les domaines de la pr´evention de risques environnementaux, dans l’aide `a la caract´erisation des ressources d’´energie renouvelables solaire, ´eolienne voire houlo-motrice. Ils peuvent ˆetre ais´ement transposables aux autres ˆıles des petites Antilles.Abstract Meso-scale and micro-scale numerical simulations of local circulations induced by tropical islands : Case of the Guadeloupe archipelago with a pollutant dispersion case (WRF-LES-FLEXPART) by Rapha¨el C´ec´e The present work expresses the will of Caribbean researchers to improve the meso- and micro-meteorological scientific knowledge of the trade winds influenced island areas, and to develop research in these domains. It is well known that tropical hurricanes remain the most remarkable meteorological phenomena that affect the Caribbean islands. But some other phenomena, of smaller scale, such as intense rainfall events, swells, or air quality degradation, are of extreme importance for natural or health hazards. These examples show the need to use downscaling methods to exploit large scale meteorological or climatic information, and to obtain local and regional scenarios for the island areas. This is an important challenge, as sound scientific studies in these matters are eagerly expected. The aim of the research works exposed in the present dissertation is numerical simulation and analysis of the meso- and microscale mechanisms that induce diurnal and nocturnal local circulations in the Guadeloupe archipelago, using numerical meteorological models that are widely used in research and in operational forecasting. These works represent the first high-resolution (1 km to 111 m) numerical study of the lower atmosphere over the Guadeloupe archipelago. The Weather Research and Forecasting ARW 3.4 (WRF-ARW) model is used to simulate the troposphere from global scale to turbulence scale. Real cases of three typical weather types (80% of cases during a year) are examined during 48 hours : strong trade winds (STW), medium trade winds (MTW) and weak trade winds (WTW). These weather types are characterized by values of the local Froude number : 0.82 (STW), 0.41 (MTW) and 0.21 (WTW). Six domains have been selected for the dynamical downscaling : D01 (grid spacing of 27 km), D02 (grid spacing of 9 km), D03 (grid spacing of 3 km), D04 (grid spacing of 1 km), D05 (grid spacing of 333 m) and D06 (grid spacing of 111 m), including 70 vertical levels. The first four domains (D01 to D04) cover the Guadeloupe archipelago and are used in the meso-scale simulations with the planetary boundary layer scheme YSU (ensemble mean). Domain D05 (covering the Basse-Terre island and the middle of the archipelago) and domain D06 (covering the coastal and rural area of Le Petit Cul-de-Sac Marin and the urban area of Pointe-`a-Pitre), are employed in the micro-scale simulation(LES) with the 3D TKE 1.5 order closure scheme. WRF has been 6 hourly reinitialized with the NCEP FNL global analyses (resolution of 1➦). These simulations permitted to obtain 10-minutes meteorological variable fields with a very high resolution (111 m). Meso-scale and micro-scale model results have been evaluated with observational data from meteorological stations (field campaign Atmo-Mangrov, French Met Office). Once validated, the micro-scale model outputs have been used for the assimilation of the lagrangian particle dispersion model : FLEXPART. The coupling FLEXPART-WRF has been employed in domain D06, in order to analyze the dispersion of the nitrogen oxide plume emitted by the main power plant of the archipelago. Agreements between model/observations time series have been evaluated with error statistical tools (MAE, MBE, IOA). The error statistical tools show that simulated typical meteorological variables have a good agreement with observational data. The model simulates well wind patterns and local circulations observed at the stations. The use of accurate land cover data significantly improves the results. During the weak trade winds, vertical cross sections of the turbulent kinetic energy, virtual temperature and density indicate the occurrence of a katabatic flow with a well defined front. This westerly circulation starts at the end of the afternoon in the area of the volcano of La Soufri`ere. The katabatic flow extends to the windward coast of the Basse-Terre island and reaches the coastal area of Arnouville 2 to 3 hours after its onset time. During the night, the katabatic front oscillates over the marine area of Le Petit Cul-de-Sac Marin. Due to its warming over the marine area, the front cannot extend on the Grande-Terre colder land surface. The micro-scale simulations permitted to study the ability of this gravity flow to extend to the urban area of Pointe-`a-Pitre, and its ability to induce pollution events in this area. The simulated and the observed NOx concentration peaks occur nearly at the same time, but the model overestimates them, with a one hour lag. Overestimations of the wind speeds have been observed at nighttime. These inaccuracies are linked with the lack of realism of the boundary conditions (land cover, topography, sea surface temperature). These biases will be corrected in the future. The error statistical tools showed a good agreement with observational data. The graphical evaluations (time series, concentration vertical profiles) allowed a better understanding of the pollution dispersions under local circulations. These numerical results can be useful in many fields : to prevent environmental risks, to help characterizing renewable energy sources such as solar, wind or wave energy. They can be easily transferred to other islands of the Lesser Antilles.Remerciements Je remercie le professeur Narcisse Zahibo, directeur du laboratoire LaRGE (Laboratoire de Recherche en G´eosciences et Energies), mon directeur de th`ese, de m’avoir fait con- ´ fiance pour ce projet. Je remercie chaleureusement Didier Bernard, maˆıtre de conf´erences `a l’Universit´e des Antilles de la Guyane, mon encadrant, qui a suivi mon travail et qui m’a soutenu avec un grand d´evouement et beaucoup d’efficacit´e, y compris lorsqu’il a dˆu traverser des moments difficiles. Je remercie particuli`erement Jean-Fran¸cois Dorville, lecturer `a l’Universit´e des West Indies, qui m’a fait d´ecouvrir le monde de la recherche lorsque j’´etais en master, et qui malgr´e l’´eloignement s’est toujours rendu disponible pour m’aider dans ces pr´esents travaux. J’exprime mes remerciements `a Jacques Laminie, Rapha¨el Pasquier et Patrick Siarras, du Centre Commun de Calcul Intensif (C3I) de l’Universit´e des Antilles et de la Guyane, qui m’ont aid´e `a installer le mod`ele num´erique WRF sur les calculateurs Orca et Wahoo de l’Universit´e. De mˆeme, je remercie Richard Emilion, professeur `a l’Universit´e d’Orl´eans, qui m’a permis ´ d’avoir acc`es au calculateur Phoebus du Centre de Calcul Scientifique en r´egion Centre (CCSC) de l’Universit´e d’Orl´eans, ainsi que Laurent Catherine qui m’a aid´e `a utiliser efficacement ce calculateur. Philippe Palany, de M´et´eo-France, m’a donn´e acc`es aux donn´ees m´et´eorologiques d’observation qui m’ont permis d’´evaluer mes r´esultats. Qu’il en soit remerci´e. Je tiens aussi `a remercier les jeunes chercheurs de mon laboratoire, Ma¨ına Andr´e, St´ephanie Monjoly, Christophe D’Alexis, Vanessa Clotaire, Christelle Dixit, Fr´ed´eric Dondin, Sandrine Samot et sp´ecialement Thomas Plocoste, grˆace `a qui j’ai b´en´efici´e d’une ambiance de travail stimulante et sympathique. Mes remerciements s’adressent aussi `a mes coll`egues de l’Universit´e - et particuli`erement Andr´e Roussas - qui m’ont aid´e `a affronter des conditions de travail parfois difficiles, ainsiqu’`a Dani`ele Frison pour son aide `a la r´edaction en anglais. Je dois finalement remercier de nombreuses personnes qui ont contribu´e, mˆeme directement, `a ce travail. Tout d’abord mes parents, Pierre-Robert et Marie-Claude C´ec´e, qui m’ont aid´e et encourag´e `a poursuivre mes ´etudes universitaires jusqu’au doctorat, ainsi que ma soeur, Mellissa C´ec´e qui m’a soutenu malgr´e la distance. Ensuite mes camarades de Combat Ouvrier et du journal Rebelle ! avec lesquels je milite pour construire un monde meilleur, et sp´ecialement Ren´e Cuillierier qui m’a transmis son enthousiasme r´evolutionnaire. Et enfin ma compagne, Delphine Prudhomme, pour son ind´efectible soutien et son importante contribution `a ces travaux.Table des Mati`eres Citation i R´esum´e ii Abstract v Remerciements vii Table des Mati`eres ix Liste des Figures xiv Liste des Tableaux xx Liste des Abr´eviations xxi Introduction 1 1 Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 6 1.1 Echelles des circulations atmosph´eriques ´ . . . . . . . . . . . . . . . . . . . 6 1.2 M´eso-´echelle et micro-´echelle : circulations locales de couche limite atmosph´erique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2.1 Couche limite atmosph´erique (CLA) . . . . . . . . . . . . . . . . . 8 1.2.1.1 D´efinition . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2.1.2 Structure de la CLA associ´ee au cycle diurne . . . . . . . 8 Couche de m´elange . . . . . . . . . . . . . . . . . . . . . . . 9 Couche r´esiduelle . . . . . . . . . . . . . . . . . . . . . . . . 9 Couche limite stable . . . . . . . . . . . . . . . . . . . . . . 10 1.2.1.3 Vent moyen, ondes et turbulence . . . . . . . . . . . . . . 10 1.2.2 Circulations locales g´en´er´ees par les conditions de terrain . . . . . . 11 1.2.2.1 R´egions cˆoti`eres : brises de mer–terre . . . . . . . . . . . . 11 Brises de mer . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Brises de terre . . . . . . . . . . . . . . . . . . . . . . . . . . 11 ixTable des Mati`eres x 1.2.2.2 R´egions orographiques : vents anabatiques–catabatiques . 12 Vents anabatiques . . . . . . . . . . . . . . . . . . . . . . . . 12 Vents catabatiques . . . . . . . . . . . . . . . . . . . . . . . 12 1.3 Simulations num´eriques de la descente dynamique de la m´eso-´echelle `a la micro-´echelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.3.1 Descente d’´echelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3.2 Spectre de la turbulence : ” terra incognita ” (Wyngaard, 2004) . . 13 1.3.3 M´eso-´echelle : principaux sch´emas de moyenne d’ensemble 1D (Shin and Hong, 2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.3.1 Sch´ema YSU : fermeture au premier ordre avec un m´elange non-local . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.3.2 Sch´ema MYJ : fermeture TKE `a l’ordre 1,5 avec un m´elange local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3.4 Micro-´echelle : sch´emas Large Eddy Simulation (LES) 3D (Mirocha et al., 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3.4.1 Fermeture SFS Smagorinsky . . . . . . . . . . . . . . . . . 17 1.3.4.2 Fermeture SFS TKE d’ordre 1.5 . . . . . . . . . . . . . . . 17 1.3.5 Descente d’´echelle : couplage d’un sch´ema d’ensemble et d’un sch´ema LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.4 Simulation num´erique de la dispersion de polluants : applications du mod`ele FLEXPART-WRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.4.1 G´en´eralit´es sur les mod`eles lagrangiens de dispersion de particules (Hegarty et al., 2013a,b) . . . . . . . . . . . . . . . . . . . . . . . . 20 1.4.2 Quelques applications du mod`ele FLEXPART-WRF . . . . . . . . . 20 1.5 Etat de l’art sur les circulations locales g´en´er´ees par des ˆıles tropicales ´ . . . 21 1.5.1 Circulations g´en´er´ees par les ˆıles tropicales larges (Fr ≥ 1 et une largeur > 50 km) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.5.2 Circulations g´en´er´ees par les ˆıles tropicales montagneuses (Fr < 1) . 22 1.5.3 Circulations g´en´er´ees par les petites ˆıles (Fr ≥ 1 et une largeur ≤ 50 km) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.6 Etat de l’art sur l’archipel de la Guadeloupe ´ . . . . . . . . . . . . . . . . . 23 1.6.1 Contexte m´et´eorologique synoptique . . . . . . . . . . . . . . . . . 23 1.6.2 Contexte m´et´eorologique local . . . . . . . . . . . . . . . . . . . . . 24 1.6.2.1 Quelques aspects des vents locaux d’apr`es Br´evignon (2003) 25 1.6.2.2 Campagne exp´erimentale dans la zone cˆoti`ere d’Arnouville (ARN, D’Alexis et al. (2011)) . . . . . . . . . . . . . . . . 26 1.6.2.3 Campagne exp´erimentale dans la zone urbaine de Pointe- `a-Pitre (DCH, Plocoste (2013); Plocoste et al. (2014)) . . 27 1.6.2.4 Variabilit´e diurne et spatiale des champs de surface . . . . 28 1.6.3 Impacts des circulations locales nocturnes sur la dispersion de polluants industriels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.6.3.1 Centrale EDF diesel Jarry nord . . . . . . . . . . . . . . . 29 1.6.3.2 Observations du panache de la centrale durant des retournements nocturnes du vent . . . . . . . . . . . . . . . . . 30Table des Mati`eres xi 2 M´ethodologie et outils de simulation 32 2.1 M´ethodologie g´en´erale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2 S´election des trois situations m´et´eorologiques ´etudi´ees . . . . . . . . . . . . 36 2.2.1 Classification des types de temps . . . . . . . . . . . . . . . . . . . 36 2.2.2 Circulations synoptiques de basses couches pour les dates simul´ees . 37 2.3 Mod`ele num´erique m´eso-´echelle de pr´evision m´et´eorologique : WRF ARW V3.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.3.1 Description du mod`ele d’apr`es les ´etudes de Skamarock et al. (2008) et Wang et al. (2010) . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.3.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.3.1.2 Principales ´equations r´esolues . . . . . . . . . . . . . . . . 42 Coordonn´ee verticale η et variables associ´ees . . . . . . . . . 42 Equations d’Euler incluant l’humidit´e ´ . . . . . . . . . . . . . 43 Maillage ARW d´ecal´e : Arakawa-C . . . . . . . . . . . . . . . 44 2.3.1.3 Sch´emas de param´etrisation physique . . . . . . . . . . . . 45 2.3.2 Configurations utilis´ees . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.3.2.1 Preprocessing WPS . . . . . . . . . . . . . . . . . . . . . . 47 Domaines de simulation . . . . . . . . . . . . . . . . . . . . . 47 Topographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Occupation des sols . . . . . . . . . . . . . . . . . . . . . . . 49 Donn´ees m´et´eorologiques globales pour l’assimilation du mod`ele WRF ARW . . . . . . . . . . . . . . . . . . . . . 52 2.3.2.2 Param´etrisations WRF ARW . . . . . . . . . . . . . . . . 52 Caract´erisation des niveaux verticaux . . . . . . . . . . . . . 52 P´eriodes simul´ees et intervalles de temps des sorties mod`eles 53 Param´etrisations physiques m´eso- et micro-´echelles . . . . . . 54 Pas de temps de calcul . . . . . . . . . . . . . . . . . . . . . 55 Conditions initiales . . . . . . . . . . . . . . . . . . . . . . . 55 Conditions aux limites . . . . . . . . . . . . . . . . . . . . . 56 2.4 Mod`ele lagrangien de dispersion de particules : FLEXPART-WRF . . . . . 57 2.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.4.1.1 Int´egration des donn´ees m´et´eorologiques WRF . . . . . . . 57 2.4.1.2 Param´etrisation de la couche limite atmosph´erique et de la turbulence . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.4.1.3 Calcul de la trajectoire des particules . . . . . . . . . . . . 59 2.4.2 Configurations de nos simulations . . . . . . . . . . . . . . . . . . . 60 2.4.2.1 P´eriodes de simulation et intervalles de temps des sorties mod`eles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.4.2.2 Caract´erisation des niveaux verticaux . . . . . . . . . . . . 61 2.4.2.3 Param´etrisation du panache de NOx de la centrale EDF . 61 2.4.2.4 Param´etrisations physiques . . . . . . . . . . . . . . . . . 62 2.5 Donn´ees m´et´eorologiques d’observation pour l’´evaluation du mod`ele WRF ARW3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.5.1 Radiosondages journaliers (Universit´e du Wyoming) . . . . . . . . . 62Table des Mati`eres xii 2.5.2 Bou´ees m´et´eorologiques du National Data Buoy Center . . . . . . . 63 2.5.3 Stations m´et´eorologiques de l’archipel de la Guadeloupe (M´et´eo France et LaRGE) . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 2.6 Donn´ees d’observation de la qualit´e de l’air pour l’´evaluation du mod`ele FLEXPART-WRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.7 Estimateurs d’erreur utilis´es pour l’´evaluation statistique des simulations . 67 3 R´esultats des simulations et discussion 69 3.1 Simulations num´eriques m´eso-´echelles des circulations g´en´er´ees par l’archipel de la Guadeloupe (WRF) . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.1.1 Simulation M´eso-A : r´esum´e et article publi´e . . . . . . . . . . . . . 69 3.1.2 Simulation M´eso-A’ : effets du changement de carte d’occupation des sols dans le domaine D04 . . . . . . . . . . . . . . . . . . . . . 89 3.1.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 89 3.1.2.2 Nouvelles cat´egories d’occupation des sols `a ARN, RZT, DES, MOU et GBD . . . . . . . . . . . . . . . . . . . . . 89 3.1.2.3 Evaluation statistique des variables de surface simul´ees : ´ comparaison M´eso-A et M´eso-A’ . . . . . . . . . . . . . . 90 3.1.2.4 Evaluation graphique des cycles diurnes dans les simula- ´ tions M´eso-A et Meso-A’ . . . . . . . . . . . . . . . . . . . 93 Station d’Arnouville (ARN) : effets du biais spatial . . . . . 93 Station du Moule (MOU) : am´eliorations de la simulation M´eso-A’ par rapport `a M´eso-A . . . . . . . . . . 94 3.1.2.5 Comparaison des cartes de circulations locales entre M´esoA’ et M´eso-A . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.1.2.6 Comparaison des cartes de flux de chaleur sensible HFX et de temp´erature du sol Ts entre M´eso-A’ et M´eso-A . . . 97 3.1.2.7 Conclusion sur les effets de la carte CLC24 dans le domaine D04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.1.3 Conclusion sur les simulations num´eriques m´eso-´echelles des circulations locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.2 Simulations num´eriques micro-´echelles des circulations g´en´er´ees par l’archipel de la Guadeloupe (WRF-LES) . . . . . . . . . . . . . . . . . . . . . . . 103 3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 3.2.2 Evaluation du mod`ele ´ . . . . . . . . . . . . . . . . . . . . . . . . . 104 3.2.2.1 Evaluation statistique avec les observations 10 min du mˆat ´ instrument´e ARN . . . . . . . . . . . . . . . . . . . . . . . 104 3.2.2.2 Evaluation graphique avec les observations du mˆat instru- ´ ment´e ARN : cas des AF (Fr = 0, 21) . . . . . . . . . . . . 105 3.2.3 Ecoulement catabatique nocturne sur la cˆote au vent de la Basse- ´ Terre durant AF (Fr = 0, 21) . . . . . . . . . . . . . . . . . . . . . . 107 3.2.3.1 Evolution temporelle des variables de surface `a VER, ARN, ´ EDF et PAP . . . . . . . . . . . . . . . . . . . . . . . . . 109 3.2.3.2 Structure horizontale du front de l’´ecoulement simul´e (domaine D06) . . . . . . . . . . . . . . . . . . . . . . . . . . 111Table des Mati`eres xiii 3.2.3.3 Structure verticale du front de l’´ecoulement simul´e (domaine D06) . . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.2.4 Conclusion sur les simulations num´eriques micro-´echelles des circulations locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.3 Application de la mod´elisation micro-´echelle WRF-LES `a la dispersion d’un panache de polluants industriels : couplage WRF-LES-FLEXPART . . . . 116 3.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 3.3.2 Cas des aliz´es soutenus (AS, Fr = 0, 82) . . . . . . . . . . . . . . . . 117 3.3.3 Cas des aliz´es moyens (AM, Fr = 0, 41) . . . . . . . . . . . . . . . . 118 3.3.4 Cas des aliz´es faibles (AF, Fr = 0, 21) . . . . . . . . . . . . . . . . . 120 3.3.4.1 Comparaisons des s´eries temporelles simul´ees et observ´ees `a la station PAP . . . . . . . . . . . . . . . . . . . . . . . 121 3.3.4.2 Etude des coupes verticales de concentration simul´ee aux ´ points PAP et EDF . . . . . . . . . . . . . . . . . . . . . 122 Conclusion et perspectives 123 3.3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 3.3.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A Article publi´e 129 B Communications internationales 130 C Communication nationale 135 Bibliographie 137Liste des Figures 1.1 Classification des ph´enom`enes atmosph´eriques en fonction de leur ´echelle spatio-temporelle (Orlanski, 1975; Stull, 1988). . . . . . . . . . . . . . . . . 7 1.2 Evolution temporelle de la structure verticale de la couche limite atmosph´erique ´ terrestre dans des r´egions anticycloniques (Stull, 1988). . . . . . . . . . . . 9 1.3 Sch´ema du spectre de l’´energie en fonction de la taille des structures turbulentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.4 Carte topographique GeBCO 08 (General Bathymetric Chart of the Oceans IOC et al. (2003), 30 secondes d’arc de r´esolution) en m : (a) zone de la Cara¨ıbe ; (b) l’Arc des Petites Antilles. . . . . . . . . . . . . . . . . . . . . 24 1.5 Carte topographique (IGN, 50 m de r´esolution), avec la zone la plus peupl´ee de l’archipel (rectangle noir), la d´echarge DCH (carr´e marron), la centrale EDF (croix rouge), le campus de Fouillole (carr´e jaune), le mˆat instrument´e du laboratoire LaRGE (ARN, triangle vert) et les 4 stations M´et´eo-France, Raizet (RZT, disque rouge), Moule (MOU, ´etoile magenta), D´esirade (DES, carr´e bleu), Grand-Bourg de Marie-Galante (GBD, losange noir). . . . . . 25 1.6 Cartes de circulations cˆoti`eres autour de la Guadeloupe durant des vents synoptiques d’est (d’apr`es Br´evignon (2003)). . . . . . . . . . . . . . . . . 26 1.7 Photo des chemin´ees de la centrale ´electrique EDF Jarry nord, [cr´edit photo : R. C´ec´e 2014]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.8 Photo satellite Google earth (8/04/2013) : localisation de la centrale EDF et du campus UAG, les fl`eches rouges correspondant aux directions (a) et (b) du panache durant une circulation nocturne d’ouest (Fig. 1.9). . . . . . 30 1.9 Photos du panache de la centrale EDF de Jarry (prise de vue depuis le campus de Fouillole UAG, Fig. 1.8) : (a) direction du vent nord-ouest, photo prise le 14/09/2010 `a 7 h 21 LT ; (b) direction du vent sud-ouest, photo prise le 4/11/2009 `a 7 h 11 LT [cr´edits photos : D. Bernard 2009-2010]. 31 2.1 Sch´ema r´ecapitulatif de la m´ethodologie adopt´ee. . . . . . . . . . . . . . . 35 2.2 Donn´ees d’observation du radar de M´et´eo-France (250 m de r´esolution) `a 16 h LT : (a) le 15 d´ecembre 2007 (AS), (b) le 24 d´ecembre 2007 (AM) et (c) le 3 d´ecembre 2007 (AF). . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.3 Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AF le 3/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal `a 10 m en m.s-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.4 Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AS le 14/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal `a 10 m en m.s-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 xivListe des Figures xv 2.5 Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AM le 24/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal `a 10 m en m.s-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.6 Architecture du mod`ele WRF ARW (d’apr`es Wang et al. (2010)). . . . . . 42 2.7 Niveaux verticaux η dans WRF ARW avec pht et phs, respectivement, les pressions hydrostatiques au sommet et `a la surface (d’apr`es Skamarock et al. (2008)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.8 Maille individuelle de la grille Arakawa-C avec les grandeurs vectorielles (U, V , W, Ω et φ) et les scalaires (µ, θ, qv et ql) (Skamarock and Dudhia, 2014). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.9 Interactions entre les sch´emas de param´etrisation physique du mod`ele WRF ARW (Dudhia, 2014). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.10 Cartes des domaines imbriqu´es : en blanc D01 (27 km de r´esolution), en cyan D02 (9 km de r´esolution), en gris D03 (3 km de r´esolution), en jaune D04 (1 km de r´esolution), en vert D05 (333 m de r´esolution) et en rouge D06 (111 m de r´esolution). . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.11 Cartes topographiques (m AMSL) interpol´ees `a partir des donn´ees IGN (50 m de r´esolution) : (a) D04 (1 km de r´esolution), (b) D05 (333 m de r´esolution), (c) D06 (111 m de r´esolution) ; avec la station num´erique VER (triangle jaune), le mˆat instrument´e ARN (triangle vert) et la centrale ´electrique EDF (croix rouge). . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.12 Carte d’occupation des sols de l’archipel de la Guadeloupe CLC24 (23 m de r´esolution) : Corine Land Cover 2006 dont les 50 cat´egories ont ´et´e converties en 24 cat´egories USGS, avec le rectangle noir repr´esentant l’agglom´eration pointoise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.13 Comparaison des cartes d’occupation des sols de l’archipel de la Guadeloupe `a 1 km de r´esolution (D04) avec la ligne de cˆote World Vector Shoreline (NOAA, 2014), (1) les zones urbaines, (2) les terres cultiv´ees non irrigu´ees, (6) les m´elanges de terres cultiv´ees et de forˆets, (7) les pelouses, (8) les arbustes, (9) les m´elanges d’arbustes et de pelouses, (10) les savanes, (11) les forˆets de feuillus, (13) les forˆets denses, (14) les forˆets de conif`eres, (15) les forˆets m´elang´ees mangroves incluses, (16) les surfaces d’eau, (17) les v´eg´etations basses en zones inond´ees, (18) les surfaces bois´ees en zones inond´ees, (21) la toundra bois´ee : (a) USGS ULC24 (M´eso-A), (b) Corine CLC24 (M´eso-A’). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.14 Niveaux verticaux m´edians (WRF) pour les exp´eriences M´eso-A (croix bleues) et M´eso-A’ (cercles rouges) : (a) profils lin´eaires en fonction du niveau de pression (hPa) et (b) profils logarithmiques en fonction de l’altitude (km). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.15 Profil vertical des 38 niveaux verticaux FLEXPART-WRF. . . . . . . . . . 61 2.16 G´eolocalisation des radiosondages (TRI, BAR, RZT, SXM, PTR, et SDM : carr´es rouges), des bou´ees du r´eseau NDBC-NOAA (ATL, CAR, POR, et BAH : cercles bleus) au sein des quatre premiers domaines (D01, D02, D03, D04) employ´es dans les simulations WRF m´eso-´echelles, de r´esolutions respectives de 27, 9, 3 et 1 km. . . . . . . . . . . . . . . . . . . . . . 63Liste des Figures xvi 2.17 Carte topographique (IGN, 50 m de r´esolution), avec le mˆat instrument´e du laboratoire LaRGE (ARN, triangle vert) et les 4 stations M´et´eo-France, Raizet (RZT, disque rouge), Moule (MOU, ´etoile magenta), D´esirade (DES, carr´e bleu), Grand-Bourg de Marie-Galante (GBD, losange noir). . . . . . 64 2.18 Description du mˆat instrument´e du laboratoire LaRGE `a ARN (sch´ema extrait de D’Alexis (2011)), avec, (a) le capteur barom´etrique PTB101B, (b) la centrale d’acquisition Campbell CR3000, (c) le capteur HR capacitif (HMP45C) pour l’humidit´e et la temp´erature (2 m AGL), (d) l’an´emom`etre `a coupelles (2 m AGL), (e) la girouette (2 m AGL), (f) l’an´emom`etre sonique 3D (CSAT3) pour le calcul des flux turbulents (5 m AGL) et (g) l’an´emom`etre sonique 2D (WindSonic) pour le vent horizontal (10 m AGL). 66 2.19 Carte de localisation de la station Gwad’air PAP (losange violet) et de la centrale ´electrique EDF (croix rouge) : (a) Topographie (en m AMSL) du domaine D05 (maille de 333 m) avec l’agglom´eration pointoise (contour violet), (b) image satellite Google earth de la zone d’´etude (4/8/2013). . . 67 3.1 Carte d’occupation des sols de l’archipel de la Guadeloupe utilis´ee dans la simulation M´eso-A’, `a 1 km de r´esolution avec les 5 stations (ARN, RZT, DES, MOU et GBD) : (1) zones urbaines, (2) terres cultiv´ees non irrigu´ees, (6) terres cultiv´ees–forˆets, (9) arbustes–pelouses, (11) forˆets de feuillus, (15) forˆets m´elang´ees mangroves incluses, (16) surfaces d’eau et (17) v´eg´etations basses en zones inond´ees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.2 Comparaison des s´eries temporelles (48 h) `a ARN, avec les observations (triangles verts), M´eso-A (carr´es bleus)et M´eso-A’ (cercles rouges) : (a1)– (a3) la temp´erature T2 (en ➦C), (b1)–(b3) la vitesse UU `a 10 m AGL (en m.s-1), (c1)–(c3) la direction DD `a 10 m AGL (en ➦N) ; (a1)–(c1) pour AS, (a2)–(c2) pour AM et (a3)–(c3) pour AF. . . . . . . . . . . . . . . . . . . . 93 3.3 Comparaison des s´eries temporelles (48 h) `a MOU, avec les observations (triangles verts), M´eso-A (carr´es bleus) et M´eso-A’ (cercles rouges) : (a1)– (a3) la temp´erature T2 (en ➦C), (b1)–(b3) la vitesse UU `a 10 m AGL (en m.s-1), (c1)–(c3) la direction DD `a 10 m AGL (en ➦N) ; (a1)–(c1) pour AS, (a2)–(c2) pour AM et (a3)–(c3) pour AF. . . . . . . . . . . . . . . . . . . . 95 3.4 Comparaison du vent `a 10 m AGL (M´eso-A’–M´eso-A), avec la direction du vent pour M´eso-A’ (fl`eches rouges), la direction du vent pour M´esoA (fl`eches noires), la diff´erence de vitesse du vent, UUA0 − UUA en m.s-1 (contours de couleur), la ligne de cˆote pour M´eso-A’ (ligne noire), la ligne de cˆote pour M´eso-A (ligne magenta) : (a) le 14/12/2007 `a 14 h LT,(b) le 15/12/2007 `a 04 h LT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 3.5 Comparaison du vent `a 10 m AGL (M´eso-A’–M´eso-A), avec la direction du vent pour M´eso-A’ (fl`eches rouges), la direction du vent pour M´esoA (fl`eches noires), la diff´erence de vitesse du vent, UUA0 − UUA en m.s-1 (contours de couleur), la ligne de cˆote pour M´eso-A’ (ligne noire), la ligne de cˆote pour M´eso-A (ligne magenta) : (a) le 24/12/2007 `a 14 h LT, (b) le 25/12/2007 `a 04 h LT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Liste des Figures xvii 3.6 Comparaison du vent `a 10 m AGL (M´eso-A’–M´eso-A), avec la direction du vent pour M´eso-A’ (fl`eches rouges), la direction du vent pour M´esoA (fl`eches noires), la diff´erence de vitesse du vent, UUA0 − UUA en m.s-1 (contours de couleur), la ligne de cˆote pour M´eso-A’ (ligne noire), la ligne de cˆote pour M´eso-A (ligne magenta) : (a) le 3/12/2007 `a 14 h LT, (b) le 4/12/2007 `a 04 h LT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.7 Comparaison M´eso-A’–M´eso-A pour le cas des AS, le 14/12/2007 `a 14 h LT (a) et le 15/12/2007 `a 04 h LT (b) : la diff´erence de flux de chaleur sensible HF XA0 − HF XA en W.m-2 (a1, b1) et la diff´erence de temp´erature de surface T sA0 − T sA en ➦C (a2, b2). . . . . . . . . . . . . . . . . . . . . . . 98 3.8 Comparaison M´eso-A’–M´eso-A pour le cas des AF, le 24/12/2007 `a 14 h LT (a) et le 25/12/2007 `a 04 h LT (b) : la diff´erence de flux de chaleur sensible HF XA0 − HF XA en W.m-2 (a1, b1) et la diff´erence de temp´erature de surface T sA0 − T sA en ➦C (a2, b2). . . . . . . . . . . . . . . . . . . . . . . 99 3.9 Comparaison M´eso-A’–M´eso-A pour le cas des AF, le 3/12/2007 `a 14 h LT (a) et le 4/12/2007 `a 04 h LT (b) : la diff´erence de flux de chaleur sensible HF XA0 − HF XA en W.m-2 (a1, b1) et la diff´erence de temp´erature de surface T sA0 − T sA en ➦C (a2, b2). . . . . . . . . . . . . . . . . . . . . . . 100 3.10 S´eries temporelles 10 min `a ARN durant les 48 h de la simulation des AF (3/12/2007–5/12/2007), avec les sorties du domaine D05 (333 m de r´esolution) en bleu, les sorties du domaines D06 (111 m de r´esolution) en rouge et les donn´ees observ´ees en noir ; (a), (b), (c), (d) et (e) repr´esentant respectivement les variables, temp´erature de l’air `a 2 m AGL T2 (➦C), vitesse du vent horizontal UU `a 10 m AGL (m.s-1), direction du vent DD `a 10 m AGL (➦N), flux de chaleur sensible HFX (W.m-2) et ´energie cin´etique turbulente de surface TKE (en noir, l’´energie cin´etique turbulente totale observ´ee, et , en rouge et en bleu, l’´energie cin´etique turbulente sous-maille simul´ee, es , m2 .s-2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.11 Cartes des champs de vent (10 m AGL) du domaine D05, durant la nuit du 3 au 4 d´ecembre 2007 : (a) 19 h LT, (b) 22 h LT, (c) 04 h LT et (d) 09 h LT ; avec la vitesse du vent horizontal en m.s-1, VER (cercle magenta), ARN (triangle vert), EDF (carr´e blanc) et PAP (losange violet). . . . . . . 108 3.12 S´eries temporelles WRF-LES (10 min) durant la p´eriode du 3/12/2007 12 h LT au 4/12/2007 12 h LT, avec VER (D05) en noir, ARN (D06) en vert, EDF (D06) en rouge et PAP (D06) en bleu ; (a), (b), (c) et (d) repr´esentent respectivement les variables, flux de chaleur sensible HFX (W.m-2), temp´erature de l’air `a 2 m AGL T2 (➦C), vitesse du vent horizontal UU `a 10 m AGL (m.s-1) et direction du vent DD `a 10 m AGL (➦N). . . . . . . . 110 3.13 Cartes des variables de surface simul´ees le 3/12/2007 `a 22 h LT : (a) vitesse du vent horizontal UU `a 60 m AGL (m.s-1), (b) vitesse du vent vertical `a 60 m AGL (m.s-1), (c) ´energie cin´etique turbulente sous-maille es `a 60 m AGL (m2 .s-2) et (d) flux de chaleur sensible HFX (W.m-2) ; avec ARN, EDF et PAP, respectivement repr´esent´es par le triangle vert, le carr´e blanc et le losange violet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Liste des Figures xviii 3.14 Cartes des variables de surface simul´ees le 4/12/2007 `a 04 h LT : (a) vitesse du vent horizontal UU `a 60 m AGL (m.s-1), (b) vitesse du vent vertical `a 60 m AGL (m.s-1), (c) ´energie cin´etique turbulente sous-maille es `a 60 m AGL (m2 .s-2) et (d) flux de chaleur sensible HFX (W.m-2) ; avec ARN, EDF et PAP, respectivement repr´esent´es par le triangle vert, le carr´e blanc et le losange violet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.15 Coupe verticale suivant la latitude de la station ARN (16.223➦N) le 3 d´ecembre 2007 `a 19 h LT : (a) la masse volumique ρ (kg.m-3), (b) la temp´erature virtuelle Tv (K). . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 3.16 Coupe verticale suivant la latitude de la station ARN (16.223➦N) le 3 d´ecembre 2007 `a 22 h LT : (a) la vitesse du vent suivant les composantes x et z (m.s-1), (b) l’´energie cin´etique turbulente sous-maille es (m2 .s-2). . . 113 3.17 Coupe verticale suivant la latitude de la station ARN (16.223➦N) le 4 d´ecembre 2007 `a 04 h LT : (a) la vitesse du vent suivant les composantes x et z (m.s-1), (b) l’´energie cin´etique turbulente sous-maille es (m2 .s-2). . . 114 3.18 Profil vertical spatio-temporel logarithmique de l’´energie cin´etique turbulente sous-maille es (m2 .s-2) simul´ee `a ARN : la valeur des contours d’es est limit´ee `a 0.2 m2 .s-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 3.19 Cartes du vent (m.s-1) et des concentrations de NOx (µg.m-3) simul´es `a 10 m AGL durant les AS le 14 d´ecembre `a 16 h LT (a1),(a2) et le 15 d´ecembre `a 07 h LT (b1),(b2) `a l’aide de FLEXPART ; les points ARN, EDF et PAP sont respectivement repr´esent´es par un triangle blanc, un carr´e blanc et un losange blanc. . . . . . . . . . . . . . . . . . . . . . . . . 117 3.20 Comparaison du vent (m.s-1) et des concentrations de NOx (µg.m-3) observ´ees et simul´ees sur le site de la station PAP durant les AS entre le 14 et le 15 d´ecembre 2007 : NO Obs. (ligne noire), NO2 Obs. (ligne bleue), NO+NO2 Obs. (ligne verte) et NOx Flexpart `a 10 m AGL (ligne rouge). . 118 3.21 Cartes du vent (m.s-1) et des concentrations de NOx (µg.m-3) simul´es `a 10 m AGL durant les AM le 24 d´ecembre `a 16 h LT (a1),(a2) et le 25 d´ecembre `a 07 h LT (b1),(b2) `a l’aide de FLEXPART ; les points ARN, EDF et PAP sont respectivement repr´esent´es par un triangle blanc, un carr´e blanc et un losange blanc. . . . . . . . . . . . . . . . . . . . . . . . . 119 3.22 Comparaison des concentrations de NOx (µg.m-3) observ´ees et simul´ees sur le site de la station PAP durant les AM entre le 24 et le 25 d´ecembre 2007 : NO Obs. (ligne noire), NO2 Obs. (ligne bleue), NO+NO2 Obs. (ligne verte) et NOx Flexpart `a 10 m AGL (ligne rouge). . . . . . . . . . . . . . . . . . 119 3.23 Cartes du vent (m.s-1) et des concentrations de NOx (µg.m-3) simul´es `a 10 m AGL durant les AF le 3 d´ecembre `a 16 h LT (a1),(a2) et le 4 d´ecembre `a 07 h LT (b1),(b2) `a l’aide de FLEXPART ; les points ARN, EDF et PAP sont respectivement repr´esent´es par un triangle blanc, un carr´e blanc et un losange blanc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 3.24 Comparaison des concentrations de NOx (µg.m-3) observ´ees et simul´ees sur le site de la station PAP durant les AF entre le 3 et le 4 d´ecembre 2007 : NO Obs. (ligne noire), NO2 Obs. (ligne bleue), NO+NO2 Obs. (ligne verte) et NOx Flexpart `a 10 m AGL (ligne rouge). . . . . . . . . . . . . . . . . . 121Liste des Figures xix 3.25 Profils spatio-temporels logarithmiques de la concentration de NOx (µg.m-3) simul´ee durant les AF entre le 3 et le 4 d´ecembre 2007 : (a) site de la centrale EDF, (b) site de la station de la qualit´e de l’air PAP. . . . . . . . . . . . . 123Liste des Tableaux 2.1 Equivalences entre les 50 classes de la Corine Land Cover 2006 DOM et les ´ 24 classes de l’USGS AVHRR 1992 (Pineda et al., 2004). . . . . . . . . . . 50 2.2 Configuration des six domaines de simulation. . . . . . . . . . . . . . . . . 52 2.3 Pas de temps de calcul pour les six domaines de simulation. . . . . . . . . 55 2.4 Conditions aux limites des simulations WRF pour les six domaines ´etudi´es. 56 2.5 Variables des sorties WRF requises et optionnelles pour le for¸cage du mod`ele FLEXPART-WRF (Brioude et al., 2013). . . . . . . . . . . . . . . . . . . . 58 3.1 Comparaison des occupations des sols utilis´ees dans les simulations M´eso-A et M´eso-A’ pour les 5 stations (1 km de r´esolution). . . . . . . . . . . . . . 90 3.2 Evaluation statistique des variables de surface simul´ees : comparaison M´eso- ´ A et M´eso-A’. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.3 Evaluation statistique des variables de surface simul´ees (10 min) par rap- ´ port aux observations ARN. . . . . . . . . . . . . . . . . . . . . . . . . . . 105 xxListe des abr´eviations Nombres sans dimension Fr Nombre de Froude local, d´efini par U/Nhm, avec U la vitesse du vent [m.s-1], N la flottabilit´e [s-2] et hm la hauteur de l’obstacle [m] Pr Nombre de Prandtl, d´efini par µCp/λ, avec µ la viscosit´e dynamique [kg.m-1.s-1], Cp la capacit´e thermique massique [J.kg-1.K-1] et λ la conductivit´e thermique [W.m-1.K-1] Re Nombre de Reynolds, d´efini par V L/ν, avec V la vitesse caract´eristique du fluide [m.s-1], L la dimension caract´eristique [m] et ν la viscosit´e cin´ematique du fluide [m2 .s-1] Variables DD Direction du vent horizontal [➦N] er Energie cin´etique turbulente r´esolue [m ´ 2 .s-2] es Energie cin´etique turbulente sous-maille [m ´ 2 .s-2] et Energie cin´etique turbulente totale, e ´ t = er + es [m2 .s-2] GFX Flux de chaleur du sol, de l’anglais : Ground Heat Flux [W.m-2] HCLA Hauteur de la couche limite atmosph´erique [m] HFX Flux de chaleur sensible, de l’anglais : Heat Flux [W.m-2] LH Flux de chaleur latente, de l’anglais : Latent Heat [W.m-2] LW Rayonnement des ondes longues re¸cu au sol, de l’anglais : Long Wave [W.m-2] PMER Pression au niveau de la mer [hPa] QVAP Rapport de m´elange de vapeur d’eau [g.kg-1] SW Rayonnement des ondes courtes re¸cu au sol, de l’anglais : Short Wave [W.m-2] xxiListe des Abr´eviations xxii T2 Temp´erature de l’air `a 2 m AGL [➦C] TKE Energie cin´etique turbulente, de l’anglais : Turbulent Kinetic Energy [m ´ 2 .s-2] Ts Temp´erature de la surface du sol ou de la mer [➦C] UU Vitesse du vent horizontal [m.s-1] Stations d’observation ARN Mˆat m´et´eorologique LaRGE de la zone d’Arnouville, Petit-Bourg, Guadeloupe ATL Bou´ee m´et´eorologique du National Data Buoy Center (ID 41040, 14,516➦N, 53,024➦W) BAH Bou´ee m´et´eorologique du National Data Buoy Center (ID 41046, 23,838➦N, 68,333➦W) BAR Station m´et´eorologique de la Barbade (ID 78954) CAR Bou´ee m´et´eorologique du National Data Buoy Center (ID 42059, 14,058➦N, 67,528➦W) DES Station m´et´eorologique M´et´eo France de la D´esirade, Guadeloupe GBD Station m´et´eorologique M´et´eo France de Grand-Bourg, Marie-Galante, Guadeloupe MOU Station m´et´eorologique M´et´eo France du Moule, Guadeloupe PAP Station de qualit´e de l’air Gwad’air du centre-ville de Pointe-`a-Pitre, Guadeloupe POR Bou´ee m´et´eorologique du National Data Buoy Center (ID 41043, 21,061➦N, 64,966➦W) PTR Station m´et´eorologique de Porto Rico (ID 78526) RZT Station m´et´eorologique M´et´eo France du Raizet, Guadeloupe (ID 78897) SDM Station m´et´eorologique de la R´epublique Dominicaine (ID 78486) SXM Station m´et´eorologique de Saint Martin (ID 78866) TRI Station m´et´eorologique de Trinidad (ID 78970) Stations num´eriques WRF EDF Station num´erique WRF `a la position de la centrale ´electrique EDF de Jarry, Guadeloupe PCM Station num´erique WRF de la zone du Petit Cul-de-Sac Marin, Guadeloupe VER Station num´erique WRF de la zone de Vernou, Petit-Bourg, Guadeloupe Domaines de simulation D01 Domaine 1 de la descente d’´echelle avec une r´esolution de 27 km (m´eso-´echelle)Liste des Abr´eviations xxiii D02 Domaine 2 de la descente d’´echelle avec une r´esolution de 9 km (m´eso-´echelle) D03 Domaine 3 de la descente d’´echelle avec une r´esolution de 3 km (m´eso-´echelle) D04 Domaine 4 de la descente d’´echelle avec une r´esolution d’1 km (m´eso-´echelle) D05 Domaine 5 de la descente d’´echelle avec une r´esolution de 333 m (micro-´echelle) D06 Domaine 6 de la descente d’´echelle avec une r´esolution de 111 m (micro-´echelle) Divers 2D Etude en deux dimensions ´ 3D Etude en trois dimensions ´ AF Aliz´es Faibles (avec une vitesse de 3 m.s-1 et un nombre de Froude, Frm = 0, 21) AGL Au-dessus du sol, de l’anglais : Above Ground Level AM Aliz´es Moyens (avec une vitesse de 6 m.s-1 et un nombre de Froude, Frm = 0, 41) AMSL Au-dessus du niveau moyen de la mer, de l’anglais : Above Mean Sea Level ARW Coeur dynamique Advanced Research du mod`ele WRF AS Aliz´es Soutenus (avec une vitesse de 12 m.s-1 et un nombre de Froude, Frm = 0, 82) CLA Couche Limite Atmosph´erique compos´ee de la CLS et de la CLP (du bas vers le haut) CLC24 Carte d’occupation des sols Corine Land Cover (2006) convertie aux 24 cat´egories d´efinies par l’USGS CLP Couche Limite Plan´etaire, partie haute de la CLA (≈ entre le sommet de la CLS et la HCLA) CLS Couche Limite de Surface, partie basse de la CLA (≈ entre 0 et 150 m AGL) e.g. Par exemple, du latin : exempli gratia Eq. Equation ´ Fig. Figure FNL Mod`ele d’analyse m´et´eorologique globale, NCEP FNL (Final) Operational Global Analysis GFS Global Forecast System, mod`ele de pr´evision num´erique du temps `a l’´echelle globale GRIB GRIdded Binary, format binaire utilis´e pour le stockage des donn´ees m´et´eorologiques, format d´efini par la World Meteorological OrganizationListe des Abr´eviations xxiv i.e. C’est-`a-dire, du latin : id est IGN Institut National de l’Information G´eographique et Foresti`ere IOA Indice d’ad´equation du mod`ele qui varie avec l’erreur quadratique moyenne, de l’anglais : Index Of Agreement IOA2 Indice d’ad´equation du mod`ele qui varie avec l’erreur moyenne absolue, de l’anglais : Index Of Agreement 2 LaRGE Laboratoire de Recherche en G´eosciences et Energies, Universit´e des Antilles et ´ de la Guyane LES Simulation aux grandes ´echelles, de l’anglais : Large Eddy Simulation LT Temps local, de l’anglais : Local Time ; en Guadeloupe l’heure LT correspond `a l’heure UTC−4 MAE Erreur moyenne absolue, de l’anglais : Mean Absolute Error MBE Erreur du biais moyen, de l’anglais : Mean Bias Error MSL Mean Sea Level (niveau moyen de la mer) MYJ Sch´ema de turbulence 1D Mellor-Yamada-Janji´c M´eso-A Simulation m´eso-´echelle utilisant la carte d’occupation des sols ULC24 dans le domaine D04 M´eso-A’ Simulation m´eso-´echelle utilisant la carte d’occupation des sols CLC24 dans le domaine D04 NCAR National Center for Atmospheric Research (institut am´ericain de recherche sur l’atmosph`ere) Obs. Donn´ees observ´ees RMSE Erreur quadratique moyenne, de l’anglais : Root-Mean-Square Error Tab. Tableau ULC24 Carte d’occupation des sols USGS global land cover avec 24 cat´egories (1992) USGS Institut d’´etudes g´eologiques des Etats-Unis, de l’anglais : United States Geological ´ Survey UTC Temps universel coordonn´e, de l’anglais : Universal Time Coordinated ; en Guadeloupe l’heure UTC correspond `a l’heure LT+4Liste des Abr´eviations xxv WRF Mod`ele m´et´eorologique Weather Research and Forecasting YSU Sch´ema de turbulence 1D Yonsei University ZCIT Zone de Convergence IntertropicaleA la r´evolution mondiale du prol´etariat ` xxviIntroduction Motivations et objectifs de la th`ese La litt´erature a montr´e qu’en fonction de leur taille et de leur relief, les ˆıles tropicales sont capables de g´en´erer leurs propres circulations dans les basses couches atmosph´eriques (Br´evignon, 2003; Carlis et al., 2010; C´ec´e et al., 2014; D’Alexis, 2011; D’Alexis et al., 2011; Feng and Chen, 1998; Jury et al., 2009; Lef`evre et al., 2010; Lesou¨ef et al., 2011; Mahrer and Pielke, 1976; Malkus, 1955; Matthews et al., 2007; Minder et al., 2013; Nguyen et al., 2010; Oliphant et al., 2001; Plocoste, 2013; Plocoste et al., 2014; Reisner and Smolarkiewicz, 1994; Savij¨arvi and Matthews, 2004; Smith et al., 1997; Smith and Grubiac, 1993; Smith et al., 2012; Souza, 1972; Whitehall et al., 2013; Yang and Chen, 2005). Le contexte tropical insulaire, avec une forte irradiation solaire et des ˆıles montagneuses, est propice `a de nombreux ph´enom`enes m´et´eorologiques locaux tels que les vents catabatiques–anabatiques en zone montagneuse, les brises de mer-terre sur la cˆote, la convection thermique-orographique ´evoluant en orages, les effets du relief sur des vents cycloniques... Ces ph´enom`enes se produisent aux ´echelles sub-kilom´etriques, infra-journali`eres, voir infrahoraires. Ils engendrent des changements brusques qui peuvent g´en´erer des rafales de vent localis´ees, des pr´ecipitations extrˆemes, des ´episodes de pollution atmosph´erique dans les basses couches, ou des perturbations de l’´etat de la mer. Il est donc essentiel d’am´eliorer les connaissances `a ces ´echelles fines, pour r´eduire les risques sur la sant´e, les biens et les personnes. L’application de la mod´elisation de l’atmosph`ere `a la micro-´echelle (inf´erieure au km, infra-horaire) b´en´eficierait aussi `a la recherche sur la pr´ediction des ´energies renouvelables fluctuantes, comme l’´eolien ou le solaire. La bibliographie traitant des circulations locales g´en´er´ees par l’archipel de la Guadeloupe est tr`es peu document´ee. Br´evignon (2003) a d´ecrit une cartographie grossi`ere des r´egimes de vents locaux. D’apr`es Br´evignon (2003), il n’y aurait pas de retournement du 1Introduction 2 vent jour–nuit mais une simple variation dans la direction du vent. Il a estim´e que les brises thermiques seraient principalement observ´ees le long de la cˆote sous le vent de la Basse-Terre. Pourtant, durant des aliz´es faibles `a mod´er´es, ces retournements nocturnes du vent des basses couches ont ´et´e observ´es : sur la cˆote au vent de la Grande-Terre (Br´evignon, 2003), sur la cˆote au vent de la Basse-Terre (D’Alexis, 2011; D’Alexis et al., 2011) et sur la cˆote sous le vent de la Grande-Terre (Plocoste, 2013; Plocoste et al., 2014). Dans le premier cas, il s’agirait d’une brise de terre (Br´evignon, 2003). L’environnement cˆotier et orographique du deuxi`eme cas sugg´ererait un ´ecoulement catabatique et/ou une brise de terre (D’Alexis, 2011; D’Alexis et al., 2011). Enfin Plocoste et al. (2014) ont d´efini la circulation nocturne d’ouest comme une brise urbaine induite par un ˆılot de chaleur urbain dans l’agglom´eration pointoise. D’apr`es nous, l’origine purement urbaine de cet ´ecoulement serait discutable. Les mesures exp´erimentales de D’Alexis et al. (2011) effectu´ees dans les mˆemes conditions m´et´eorologiques sur la cˆote au vent de la Basse-Terre ( station ARN), sugg´ereraient que l’´ecoulement d’ouest observ´e dans les travaux de Plocoste et al. (2014) soit g´en´er´e, en amont, sur la cˆote au vent de la Basse-Terre avec une extension vers la Grande-Terre. Les observations du panache de la centrale EDF de Jarry (Fig. 1.7, 1.8, 1.9) confirmeraient cette extension de l’´ecoulement vers la cˆote ouest de la Grande-Terre. Cet ´ecoulement local nocturne d’ouest, soufflant en direction de la partie la plus peupl´ee de l’archipel en passant par la zone industrielle de Jarry (o`u l’on trouve de nombreuses sources d’´emissions de polluants), n´ecessite une analyse 3D de sa structure et de ses m´ecanismes de formation. Quels sont les effets pr´edominants `a prendre en compte, selon les conditions m´et´eorologiques, pour comprendre ce cycle particulier du vent ? Quels sont les ordres de grandeur (extensions verticale et horizontale, direction et intensit´e) pour les variations observ´ees ? Quelles sont les influences de l’occupation des sols et de la zone maritime ? Quel est le rˆole du flux de chaleur sensible dans les cycles diurnes observ´es ? Actuellement, le mod`ele num´erique de pr´evision du temps, employ´e par M´et´eo-France en Guadeloupe et en Martinique, a une r´esolution limit´ee `a 8 km (mod`ele Aladin). Cette ´echelle ne correspond pas aux ph´enom`enes m´et´eorologiques locaux qui apparaissent sur ces petites ˆıles de l’Arc antillais. Depuis une d´ecennie, le d´eveloppement des moyens de calcul a permis la mise en place de mod`eles num´eriques de pr´evision du temps `a l’´echelle r´egionale. D’autres mod`eles m´et´eorologiques, comme le mod`ele Weather Research and Forecasting WRF (Skamarock et al., 2008), ont montr´e leur efficacit´e `a pr´edire les conditions atmosph´eriques m´eso-´echelles `aIntroduction 3 partir des donn´ees synoptiques des mod`eles globaux (Carlis et al., 2010; C´ec´e et al., 2014; Jury et al., 2009; Lef`evre et al., 2010; Nguyen et al., 2010; Seaman et al., 2012; Yang and Chen, 2005). Ce mod`ele est capable d’effectuer la descente d’´echelle depuis la m´eso-´echelle (sch´ema d’ensemble de couche limite plan´etaire 1D) vers la micro-´echelle (Large Eddy Simulation, LES 3D). C’est un axe de recherche r´ecent qu’on se propose d’appliquer `a notre sujet d’´etude. Cette ´etude viendra compl´eter les validations de ce type de couplage entre ces deux sch´emas de mod´elisation de la turbulence. Ce m´emoire de th`ese constitue donc la premi`ere ´etude de mod´elisation num´erique `a haute r´esolution de l’atmosph`ere dans les petites ˆıles montagneuses de l’archipel de la Guadeloupe (avec des mailles m´eso-´echelles de 3 km et 1 km et des mailles micro-´echelles de 333 m et 111 m). Le mod`ele m´et´eorologique WRF ARW V3.4.1 (Skamarock et al., 2008) ainsi que son module WRF-LES (micro-´echelle) ont ´et´e utilis´es pour simuler trois situations m´et´eorologiques r´eelles de 48 heures, associ´ees `a des aliz´es faibles (AF), des aliz´es moyens (AM), et des aliz´es forts (AS). Ces situations correspondent respectivement aux valeurs du nombre de Froude local ´egales `a 0,21, 0,41 et 0,82 (Fr est d´efini par U/Nhm avec des vitesses de vent horizontal U = 3, 6, 12 m.s-1, une flottabilit´e N de 0,01 s-1 et la hauteur de la Soufri`ere hm = 1460 m). Les travaux pr´esent´es ont pour principal objectif la simulation num´erique et l’analyse des m´ecanismes m´eso- et micro-´echelles qui induisent des circulations locales diurnes et nocturnes sur les ˆıles de la Guadeloupe et plus principalement dans la zone la plus peupl´ee de l’archipel (l’agglom´eration pointoise situ´ee au centre de l’archipel autour du Petit Culde-Sac Marin). A l’heure actuelle, o`u la mod´elisation de la descente d’´echelle depuis les ` sch´emas de moyenne d’ensemble (m´eso-´echelle) vers les sch´emas LES (micro-´echelle) reste peu document´ee, notre ´etude permettra d’am´eliorer les connaissances sur cette imbrication. Les observations de circulations nocturnes, apparaissant dans l’agglom´eration pointoise et la zone industrielle de l’archipel, peuvent g´en´erer des pics de pollution, li´es aux sources industrielles comme la production d’´electricit´e. Pour tenter d’´evaluer et de pr´evenir les risques de pollution associ´es au passage de cette circulation, une analyse plus fine en temps et en espace, est n´ecessaire. Cette analyse a pu ˆetre r´ealis´ee grˆace au couplage du mod`ele lagrangien de dispersion de particules FLEXPART(Brioude et al., 2013) avec les sorties WRF-LES. Les simulations micro-´echelles de la dispersion d’un panache de NOx seront analys´ees. Le for¸cage du mod`ele FLEXPART avec des sorties micro-´echelles WRF-LES (avec des r´esolutions spatiales de 333 m et 111 m) toutes les 10 minutes permettra d’´evaluer laIntroduction 4 capacit´e de ce dernier `a repr´esenter la dispersion de polluants dans des ´ecoulements turbulents. Ces premiers r´esultats de dispersion du panache de polluants issus de la zone industrielle de Jarry pourraient aider `a l’´elaboration de plans de pr´evention de la pollution atmosph´erique. L’ensemble des champs simul´es WRF, WRF-LES et WRF-LESFLEXPART contribueront aussi `a combler le manque de donn´ees d’observation et de mod´elisation (mod`ele Aladin de M´et´eo-France avec une maille de 8 km) locales sur l’archipel de la Guadeloupe dans le domaine de la m´et´eorologie et de la pollution. Cette ´etude pourra ˆetre g´en´eralis´ee et appliqu´ee `a des environnements proches car l’Arc des Petites Antilles est compos´e d’un ensemble d’ˆıles dont les tailles, les reliefs et les situations m´et´eorologiques synoptiques sont similaires `a ceux retrouv´es en Guadeloupe. Organisation du rapport Nous pr´esenterons dans le chapitre 1, une synth`ese bibliographique des connaissances dans le domaine de la mod´elisation des circulations atmosph´eriques, ainsi que l’´etat de l’art sur des ´etudes exp´erimentales traitant des circulations particuli`eres d´ej`a observ´ees sur l’archipel de la Guadeloupe. La section 2.1 est consacr´e `a la description de la m´ethodologie et des principaux outils employ´es. Les configurations du mod`ele m´et´eorologique r´egional WRF ARW et du mod`ele lagrangien de dispersion de particules FLEXPART-WRF sont pr´esent´ees respectivement dans les sections 2.3 et 2.4. Nous d´ecrivons les donn´ees d’observation disponibles pour l’´evaluation des champs m´et´eorologiques simul´es et des sorties de concentration de polluants dans les sections respectives, 2.5 et 2.6. La section 2.7 pr´esente les formulations des estimateurs d’erreur statistiques. Les r´esultats des simulations num´eriques m´eso-´echelles WRF (avec 4 domaines de r´esolutions respectives 27, 9, 3 et 1 km), micro-´echelles WRF-LES (avec 2 domaines de r´esolutions respectives 333 et 111 m) et de la dispersion de polluants WRF-LES-FLEXPART (mˆemes domaines que WRF-LES) sont d´ecrits et discut´es dans le chapitre 3. La publication traitant des sorties num´eriques de l’exp´erience M´eso-A (avec la carte d’occupation des sols de la Guadeloupe USGS AVHRR 1992), est incluse dans la section 3.1.1. La section 3.1.2 pr´esente les effets de la carte d’occupation des sols Corine Land Cover 2006 sur les circulations locales g´en´er´ees par l’archipel (exp´erience M´eso-A’). Dans la section 3.2, nous analysons les circulations micro-´echelles WRF-LES, simul´ees `a partir du for¸cage des sorties M´eso-A’ (1 km de r´esolution). Les simulations micro-´echelles de la dispersion duIntroduction 5 panache de la centrale EDF de Jarry (WRF-LES-FLEXPART) sont examin´ees `a la section 3.3. Enfin dans la partie Conclusion et perspectives, nous r´esumons les principaux r´esultats et enseignements de ces travaux, et nous pr´esentons leurs perspectives futures.Chapitre 1 Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 1.1 Echelles des circulations atmosph´eriques ´ Comme d´ecrit par Malardel (2009) dans son livre de r´ef´erence Fondamentaux de M´et´eorologie, l’atmosph`ere subit plusieurs types d’excitations ext´erieures comme les variations cycliques du rayonnement solaire durant l’ann´ee, ou des excitations plus irr´eguli`eres et complexes comme les interactions avec la surface terrestre ou oc´eanique. Il en r´esulte une forte variabilit´e spatio-temporelle de l’´etat du fluide atmosph´erique. Dans l’atmosph`ere excit´ee, des circulations se mettent en place et permettent un retour `a l’´equilibre. Ces circulations pr´esentent un large champ d’´echelles spatiales et temporelles : du millim`etre `a la taille de la plan`ete, et de la seconde `a plusieurs ann´ees (Malardel, 2009). D’apr`es Stull (2000), les ´echelles de temps de la plupart des ph´enom`enes sont approximativement proportionnelles aux ´echelles horizontales avec un coefficient proche d’1 s.m-1. Par exemple, dans la couche limite atmosph´erique, les vents thermiques d’1 km de diam`etre ont une dur´ee de circulation de 15 min. Les cellules orageuses qui ont une taille de 10 km peuvent durer une demi-journ´ee tandis que les perturbations cycloniques de l’ordre de 1000 km ont des dur´ees de vie allant de quelques jours `a quelques semaines (Stull, 2000). Stull (1988) a propos´e une classification des ph´enom`enes atmosph´eriques en fonction de leur ´echelle spatio-temporelle (Fig. 1.1). Les ´echelles (larges) plan´etaires et synoptiques ne sont pas d´ecrites dans ce sch´ema. L’´echelle plan´etaire est caract´eris´ee par une dimension 6Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 7 Figure 1.1: Classification des ph´enom`enes atmosph´eriques en fonction de leur ´echelle spatio-temporelle (Orlanski, 1975; Stull, 1988). spatiale de l’ordre de grandeur de 10.000 km (la circonf´erence de la Terre repr´esentant 4 fois cette valeur) et une dimension temporelle allant de plusieurs semaines `a plusieurs ann´ees. Les ph´enom`enes d’´echelle plan´etaire sont associ´es aux climats et incluent les circulations li´ees aux ondes de Rossby, `a l’ENSO (” El Ni˜no-Southern Oscillation ”), ou les circulations d’Hadley. L’´echelle synoptique a une dimension spatiale d’un millier de kilom`etres et une dimension temporelle de plusieurs jours. Elle correspond aux circulations g´en´er´ees par l’intensit´e et la position des centres anticycloniques et d´epressionnaires (comme les aliz´es). La m´eso-´echelle s’´etend sur un espace horizontal allant de 200 km `a plusieurs centaines de m`etres et un espace temporel allant de quelques jours `a la demi-heure (Fig. 1.1). Plusieurs sous-´echelles sont d´efinies dans la m´eso-´echelle : la m´eso-α (les cyclones et les fronts), la m´eso-γ (les jets de basses couches, les amas de nuages), la m´eso-δ (les orages, les effets urbains) et la micro-α (les couches limites atmosph´eriques, les nuages cumuliformes). Les ph´enom`enes comme la turbulence, avec des ´echelles spatiales inf´erieures `a 3 km et des ´echelles de temps inf´erieures `a l’heure, sont class´es dans la micro-´echelle. La m´eso-´echelle et la micro-´echelle semblent confondues dans les sous-´echelles : m´eso-δ et micro-α (Fig. 1.1). Cette zone d’imbrication inclut les ´ecoulements locaux de la couche limite atmosph´erique (comme les brises de terre–mer et les ´ecoulements catabatiques–anabatiques). Les ´etudes de pollution atmosph´erique comme la dispersion de panaches de polluants s’appliquent aussi dans le domaine de la micro-´echelle. L’ensemble des ph´enom`enes m´et´eorologiques sont bien class´es dans des ´echelles d’espace et de temps, leur mod´elisation est donc simplifi´ee.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 8 1.2 M´eso-´echelle et micro-´echelle : circulations locales de couche limite atmosph´erique Dans cette partie, la description des ph´enom`enes de couche limite atmosph´erique, se produisant `a la m´eso- et `a la micro-´echelle, est bas´ee sur les d´efinitions de Stull (1988). 1.2.1 Couche limite atmosph´erique (CLA) 1.2.1.1 D´efinition La troposph`ere est la r´egion dense et habitable de l’atmosph`ere (elle regroupe 80% de sa masse totale). La troposph`ere s’´etend du sol jusqu’`a une altitude moyenne de 11 km, cependant seuls les premiers kilom`etres sont en g´en´eral modifi´es par les ph´enom`enes se produisant `a la surface de la Terre. Stull (1988) a d´efini la couche limite atmosph´erique (CLA) comme la partie de la troposph`ere qui est directement influenc´ee par la pr´esence de la surface de la Terre avec un temps de r´eponse inf´erieur ou ´egal `a l’heure. Les for¸cages incluent la friction, l’´evapo-transpiration, le bilan radiatif, la topographie. La hauteur de la CLA varie en fonction des variables spatio-temporelles, avec des valeurs comprises entre quelques centaines de m`etres `a quelques kilom`etres. Les variations diurnes de la temp´erature de la CLA sont dues aux processus de transports, induits par le r´echauffement et le refroidissement du sol (rayonnement solaire). La turbulence est un processus de transport majeur. 1.2.1.2 Structure de la CLA associ´ee au cycle diurne Stull (1988) a ´etudi´e l’´evolution diurne de la structure de la CLA terrestre dans des r´egions anticycloniques (Fig. 1.2). La CLA passe par trois ´etats principaux : la couche m´elang´ee, la couche r´esiduelle et la couche limite stable. La couche m´elang´ee peut ˆetre divis´ee en couche nuageuse et une couche sous-nuageuse. La partie basse de la CLA, la couche de surface, est d´efinie comme une couche de flux 1 constants donc avec des flux turbulents relativement uniformes sur l’axe vertical. Une zone d’entrainement fortement stable, de turbulence intermittente, s´epare la couche m´elang´ee de l’atmosph`ere libre. Durant la nuit, cette zone d’entrainement laisse place `a une couche d’inversion non turbulente (aussi appel´ee “capping”, Fig. 1.2). 1. Transport de mati`ere ou d’´energie `a travers une surfaceChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 9 Figure 1.2: Evolution temporelle de la structure verticale de la couche limite ´ atmosph´erique terrestre dans des r´egions anticycloniques (Stull, 1988). Couche de m´elange La couche de m´elange se d´eveloppe durant la journ´ee avec une hauteur maximale atteinte avant midi (Fig. 1.2). Dans cette couche, la turbulence est g´en´eralement induite par la convection. Les sources de convection sont : le transfert de chaleur provenant du sol irradi´e par les rayons du soleil et le refroidissement radiatif (dans les fr´equences de l’infra-rouge) au sommet des nuages. Couche r´esiduelle Environ une heure avant le coucher du soleil, en absence d’advection d’air froid, les thermiques de la couche de m´elange ne se d´eveloppent plus. A cet instant, la couche de ` m´elange commence `a se d´ecomposer en une couche r´esiduelle et une couche dite nocturne (Fig. 1.2). La couche r´esultante est appel´ee couche r´esiduelle parce que ses conditions thermodynamiques initiales sont les mˆemes que celles de la couche de m´elange en train de disparaˆıtre.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 10 Couche limite stable Au cours de la nuit, la partie basse de la couche r´esiduelle se transforme en une couche limite stable (Fig. 1.2). Cette couche est caract´eris´ee par une turbulence quasi-nulle et un vent calme au niveau du sol. En cons´equence, les polluants ´emis dans la couche limite stable se dispersent peu sur l’axe vertical. Pour ces conditions de stabilit´e, des ´ecoulements particuliers peuvent se produire comme des vents catabatiques dans des r´egions orographiques ou des brises de terre dans des r´egions cˆoti`eres. Ces deux ´ecoulements particuliers seront d´ecrits dans la sous-section 1.2.2. 1.2.1.3 Vent moyen, ondes et turbulence Les ´ecoulements locaux (se produisant sur un site d´efini) peuvent ˆetre divis´es en trois cat´egories : le vent moyen, les ondes et la turbulence. Chacune de ces cat´egories existe dans la CLA, o`u le transport des quantit´es comme la vapeur d’eau (humidit´e), la chaleur, les mouvements (tourbillons) et les polluants, est domin´e par le vent moyen sur l’axe horizontal et par la turbulence sur l’axe vertical. Le vent moyen est responsable de l’advection assurant le transport horizontal rapide. Les ordres de grandeur classiques de vitesse du vent sont compris entre 2 et 10 m.s-1. La friction induite pr`es du sol, g´en`ere un profil de vitesse particulier (r´eduction continue de la vitesse en se rapprochant du sol), et donc une vitesse du vent moyen plus faible. Les vitesses verticales du vent moyen sont de l’ordre du millim`etre au centim`etre par seconde. Les ondes transportent principalement la quantit´e de mouvement et l’´energie. Ces ondes peuvent ˆetre localement g´en´er´ees par le cisaillement du vent moyen et du vent orographique. La CLA se distingue du reste de l’atmosph`ere par la forte fr´equence de la turbulence au voisinage du sol. La turbulence modifie les conditions de la CLA en fonction des for¸cages de surface. Elle est superpos´ee au vent moyen, et se manifeste par des mouvements tourbillonnaires (dits “eddies“ en anglais) de diff´erente taille imbriqu´es les uns dans les autres. Les tourbillons les plus grands ont une taille proche de la hauteur de la CLA et sont entretenus directement par les transferts de chaleur g´en´er´es par le sol irradi´e (pour les vents thermiques de la CLA), par la friction du sol ou par le franchissement d’obstacle (pour les sillages turbulents). Ces grands tourbillons peuvent ˆetre observ´es avec les boucles form´ees par un panache de fum´ee. Les plus petits tourbillons, de l’ordre du millim`etre, sont tr`es faibles `a cause des effets dissipatifs de la viscosit´e (friction inter-mol´eculaire qui transforme les mouvements en chaleur).Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 11 Dans la litt´erature, les ´etudes de la turbulence et des ondes de CLA s´eparent les variables (comme la temp´erature ou le vent) en une composante moyenne et une composante de perturbation en respectant les r`egles dites de Reynolds (Boussinesq, 1887; Reynolds, 1947). La partie moyenne repr´esente les effets de la temp´erature moyenne ou du vent moyen, tandis que la partie de perturbation repr´esente l’effet des ondes ou celui de la turbulence. 1.2.2 Circulations locales g´en´er´ees par les conditions de terrain Stull (1988) a d´ecrit les circulations locales dans des conditions de vents faibles et calmes. 1.2.2.1 R´egions cˆoti`eres : brises de mer–terre L’importante capacit´e calorifique des oc´eans inhibe les variations diurnes de la temp´erature de surface de l’eau tandis que la surface de la terre, caract´eris´ee par une faible capacit´e calorifique et une faible conductivit´e mol´eculaire, se r´echauffe et se refroidit consid´erablement durant le cycle diurne. Donc, durant la journ´ee, la terre est plus chaude que la mer et durant la nuit, la terre est plus froide. Brises de mer Pendant la matin´ee, apr`es la disparition de la couche limite stable, l’air commence `a s’´elever au-dessus du sol chaud et l’air provenant de la mer, plus froid, commence `a le remplacer. La brise de mer se met en place. L’extension de la brise de mer `a l’int´erieur des terres est d´elimit´ee par un front. Ce front est marqu´e par une zone de convergence, une chute de la temp´erature de quelques degr´es Celsius, une augmentation de l’humidit´e et des mouvements ascendants de l’ordre de 0,5 `a 2,5 m.s-1. Un ´ecoulement de retour vers la mer peut apparaˆıtre au-dessus pour fermer la circulation de brise de mer. En absence de vent synoptique, le front de brise peut progresser `a l’int´erieur des terres (entre 20 km et 50 km de distance `a la cˆote), avec une vitesse comprise entre 1 m.s-1 et 5 m.s-1 . Brises de terre La nuit, la surface de la terre se refroidissant plus rapidement que celle de l’eau de la mer, le gradient horizontal de temp´erature est invers´e. Une brise de terre se met en place : l’air froid terrestre souffle en direction de la mer plus chaude. Une circulation de retourChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 12 peut apparaˆıtre au-dessus : l’air chaud marin s’´el`eve et souffle en direction de la terre. La circulation de brise de terre est moins intense que celle de la brise de mer. 1.2.2.2 R´egions orographiques : vents anabatiques–catabatiques Ces ´ecoulements orographiques sont associ´es `a une diff´erence de temp´erature horizontale entre l’air `a la surface des pentes de la montagne et l’air environnant `a la mˆeme altitude. Vents anabatiques Pendant la journ´ee, la surface des pentes de la montagne chauff´ees par le rayonnement solaire r´echauffe `a son tour l’air proche du sol, qui devient plus chaud que l’air environnant pour une mˆeme altitude. La flottabilit´e positive induit qu’un ´ecoulement anabatique se d´eveloppe : l’air chaud va longer les pentes jusqu’au sommet de la montagne. L’air chaud peut ensuite s’´elever au-dessus de la crˆete de la montagne et former des cumulus dans certaines conditions d’humidit´e. Vents catabatiques La nuit, le refroidissement radiatif des pentes de la montagne refroidit l’air proche de la surface. Une masse d’air plus froide que l’air environnant s’accumule sur le relief. La flottabilit´e n´egative g´en`ere un ´ecoulement de gravit´e descendant les pentes : le vent catabatique. Cet ´ecoulement a, en g´en´eral, une faible ´epaisseur de quelques dizaines de m`etres et des vitesses de l’ordre de 1 `a 5 m.s-1 (Simpson, 1999). 1.3 Simulations num´eriques de la descente dynamique de la m´eso-´echelle `a la micro-´echelle Dans la section 1.1, nous avons montr´e que l’ensemble des ph´enom`enes m´et´eorologiques sont class´es dans des ´echelles d’espace et de temps. Par cons´equent, leur mod´elisation num´erique est simplifi´ee : chaque ph´enom`ene est simul´e aux ´echelles d’espace et de temps lui correspondant. Pour des raisons de coˆut des calculs num´eriques, il est plus simple de simuler des ph´enom`enes de large ´echelle, car ils sont associ´es `a des espaces importants qui peuvent ˆetre repr´esent´es par un nombre plus faible de grandes mailles. A ces grandes `Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 13 ´echelles, les fluctuations sur les circulations sont tr`es faibles. Il en r´esulte des pas de temps de calcul plus importants. Les ph´enom`enes m´et´eorologiques associ´es `a des ´echelles spatio-temporelles diff´erentes, interagissent entre eux (e.g. les circulations m´eso-´echelles dans un cyclone et les tourbillons turbulents qui l’animent `a la micro-´echelle). Pour ´etudier ces interactions d’´echelles, il est n´ecessaire d’effectuer une mod´elisation avec une imbrication d’´echelles. La notion de descente d’´echelle est un terme g´en´erique pour d´efinir le passage d’une simulation `a l’´echelle donn´ee `a une autre simulation `a l’´echelle plus fine (Fig. 2.10). 1.3.1 Descente d’´echelle En simulation m´et´eorologique, il existe deux types de descentes d’´echelle dynamique entre un domaine parent et son domaine imbriqu´e de r´esolution plus ´elev´ee. La descente d’´echelle sans retour d’information du domaine imbriqu´e vers le domaine parent est appel´ee ” oneway ”. La descente d’´echelle avec un retour d’information du domaine imbriqu´e vers le domaine parent est appel´ee ” two-way ”. Le transfert des conditions atmosph´eriques du domaine imbriqu´e vers le domaine parent permettrait d’am´eliorer les simulations m´et´eorologiques. Dans les mod`eles m´et´eorologiques m´eso-´echelles comme le Weather Research and Forecasting WRF, le rapport de r´esolution entre le domaine imbriqu´e et le domaine parent, est pr´econis´e `a [3 :1] (Skamarock et al., 2008). 1.3.2 Spectre de la turbulence : ” terra incognita ” (Wyngaard, 2004) Dans la mod´elisation m´eso-´echelle, l’´echelle l de la turbulence contenant l’´energie et les flux, est tr`es petite devant l’´echelle ∆ du filtre spatial de r´esolution des ´equations du mouvement, donc la turbulence ne peut pas ˆetre r´esolue (Wyngaard, 2004). Dans ce cas la turbulence est enti`erement mod´elis´ee par la fermeture des sch´emas de moyenne d’ensemble. Dans la mod´elisation micro-´echelle Large Eddy Simulation (LES), c’est le cas contraire, l est grand devant ∆, la turbulence de grande ´echelle est r´esolue et celle de petite ´echelle (dissipation) est mod´elis´ee. Les mod`eles de fermeture de la turbulence ne sont pas con¸cus pour ˆetre utilis´es quand l et ∆ sont du mˆeme ordre de grandeur, Wyngaard (2004) a appel´e cet intervalle num´erique : la ” terra incognita ”.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 14 1.3.3 M´eso-´echelle : principaux sch´emas de moyenne d’ensemble 1D (Shin and Hong, 2011) La couche limite atmosph´erique se compose de la couche limite de surface (CLS, comprise entre 0 et 150 m AGL 2 ) et de la couche limite plan´etaire (CLP, comprise entre le sommet de la CLS et le sommet de la CLA). Dans les mod`eles m´et´eorologiques, les ph´enom`enes de couche limite atmosph´erique sont param´etr´es par un sch´ema de couche limite de surface et un sch´ema de couche limite plan´etaire. Comme d´ecrit par Shin and Hong (2011), dans les sch´emas de couche limite plan´etaire, les flux turbulents sous-mailles sont calcul´es en utilisant les variables moyennes pronostiqu´ees (comme la temp´erature, le rapport de m´elange, les vitesses horizontales), suivant les ´equations de diffusion verticale du type : ∂C ∂t = − ∂ ∂zw0c 0 = ∂ ∂z  Kc  ∂C ∂z  (1.1) o`u Kc est la diffusivit´e turbulente pour la variable moyenne C, t le temps, z la coordonn´ee verticale, et w 0 la fluctuation de la vitesse verticale. 1.3.3.1 Sch´ema YSU : fermeture au premier ordre avec un m´elange non-local Le sch´ema YSU (Hong et al., 2006) ne n´ecessite pas l’addition de nouvelles ´equations pronostiques pour exprimer les effets de la turbulence sur les variables moyennes (Shin and Hong, 2011). En couche limite convective, ce sch´ema est bas´e sur le profil K en d´eterminant la diffusivit´e turbulente Kc (fonction du cisaillement du vent local et du nombre de Richardson local dans l’atmosph`ere libre). En addition de la diffusion locale (Eq. 1.1), le sch´ema YSU consid`ere le m´elange non-local par des grands tourbillons convectifs (Shin and Hong, 2011). Pour exprimer ce m´elange non-local, un terme d’ajustement de gradient non-local (γc) est ajout´e : ∂C ∂t = ∂ ∂z  Kc  ∂C ∂z − γc  − (w0c 0 )h z h 3  (1.2) avec h la hauteur de la couche limite convective. Le sch´ema YSU traite explicitement les processus d’entrainement au sommet de la couche limite plan´etaire. En couche limite stable, la version du sch´ema YSU am´elior´ee par Hong (2010) est bas´ee sur le nombre de Richardson global entre la couche de surface et le sommet de la couche limite (Shin and Hong, 2011). 2. Au-dessus du sol, de l’anglais : Above Ground LevelChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 15 1.3.3.2 Sch´ema MYJ : fermeture TKE `a l’ordre 1,5 avec un m´elange local Le sch´ema MYJ (Janji´c, 1990) n´ecessite l’addition d’une ´equation pronostique de l’´energie cin´etique turbulente, exprim´ee par l’accronyme anglais TKE (Turbulent Kinetic Energy) : Kc = l √ eSc (1.3) avec e la TKE, l la longueur de m´elange (d´efinie par Prandtl comme la distance sur laquelle une perturbation transporte des propri´et´es d’une parcelle d’air) et Sc le coefficient de proportionnalit´e (Shin and Hong, 2011). Le sch´ema MYJ applique le m´elange local en tenant compte de la diffusivit´e turbulente locale existant entre le plus bas et le plus haut niveau vertical, en couche limite convective et stable. L’entrainement est param´etr´e par le calcul de Kc pr`es du sommet de la couche limite plan´etaire. 1.3.4 Micro-´echelle : sch´emas Large Eddy Simulation (LES) 3D (Mirocha et al., 2010) Figure 1.3: Sch´ema du spectre de l’´energie en fonction de la taille des structures turbulentes. Les simulations aux grandes ´echelles (LES, de l’anglais : Large Eddy Simulation) ont pour principe de calculer par r´esolution num´erique directe les structures turbulentes de grande taille et de mod´eliser celles de petite taille (Fig. 1.3). Dans la CLA, les grands tourbillons sont de l’ordre d’une centaine de m`etres, mais leur structure varie selon l’´ecoulement,Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 16 tandis que les petits tourbillons ont un caract`ere universel. Les m´ethodes LES ont pour avantages : la simulation des ´ecoulements complexes de la micro-´echelle et la r´eduction de la puissance de calcul requise par rapport `a la simulation num´erique directe (DNS, de l’anglais : Direct Numerical Simulation). La mod´elisation LES repose sur la r´esolution explicite en 3D des ´echelles de production et de transport de l’´energie turbulente atmosph´erique, tandis que la partie petite ´echelle du spectre de la turbulence, correspondant `a la dissipation de l’´energie turbulente, est ´elimin´ee par l’interm´ediaire d’un filtre spatial (Mirocha et al., 2010). Les effets du filtrage des structures de ces ´echelles, sur le composant r´esolu de l’´ecoulement, sont mod´elis´es par un mod`ele de fermeture dit ” sub-filter scale ” (SFS). Mirocha et al. (2010) ont d´ecrit les ´equations LES de la mani`ere suivante, les variables r´esolues des structures grandes ´echelles ´etant not´ees avec un tilde, nous avons : ∂u˜i ∂t + ∂(˜uiu˜j ) ∂xj = − 1 ρ˜ ∂p˜ ∂xi − ∂τij ∂xj , (1.4) avec τij = (ugiuj ) − (˜uju˜i). (1.5) u˜i,j sont les vitesses r´esolues (i, j = 1, 2, 3, correspondant aux 3 composantes de la vitesse, respectivement, u, v et w) ; ˜p est la pression r´esolue ; ˜ρ est la densit´e r´esolue ; xi , xj font r´ef´erence aux coordonn´ees spatiales avec i, j = 1, 2, 3 indiquant respectivement les composants, x, y et z. τij d´efinit la contrainte de cisaillement `a la sous-´echelle du filtre (SFS) induit par les petites structures (petits tourbillons). Cette force de surface est param´etr´ee par un mod`ele de contrainte SFS. Les deux mod`eles de contrainte SFS principalement utilis´es dans la bibliographie sont : le mod`ele de Smagorinsky (Lilly, 1967; Smagorinsky, 1963) et le mod`ele bas´e sur la fermeture SFS TKE d’ordre 1,5 (Lilly, 1967). Chacun de ces mod`eles est de la forme de viscosit´e turbulente (les effets de la turbulence sont d´ecrits par une analogie avec la viscosit´e mol´eculaire) : τij = −2νT S˜ ij , (1.6) avec νT le coefficient de viscosit´e turbulente et S˜ ij = 1/2[(∂u˜i/∂x˜j )+ (∂u˜j/∂x˜i)] le tenseur de d´eformation des grandes structures (Mirocha et al., 2010).Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 17 1.3.4.1 Fermeture SFS Smagorinsky Le coefficient de viscosit´e d’eddy de Smagorinsky est calcul´e d’apr`es la formule : νT = (CSl) 2max[0,(S˜ ijS˜ ij − Pr−1N 2 ) 1/2 ]. (1.7) CS est le coefficient de Smagorinsky. L’´echelle de longueur est donn´ee par l = (∆x∆y∆z) 1/3 . Le nombre de Prandtl turbulent Pr est d´efini par µCp/λ, avec µ la viscosit´e dynamique (kg.m-1.s-1), Cp la capacit´e thermique massique (J.kg-1.K-1) et λ la conductivit´e thermique (W.m-1.K-1). Le nombre de Prandtl repr´esente le rapport entre la diffusivit´e de la quantit´e de mouvement et la diffusivit´e thermique. N2 est la fr´equence de Brunt-V¨ais¨al¨a. Elle repr´esente la stabilit´e de la couche d’air : si la parcelle d’air d´eplac´ee verticalement oscille autour de sa position d’´equilible N2 est positive, dans le cas contraire N2 est inf´erieure ou ´egale `a 0. L’´equation 1.7 induit une r´eduction de la contrainte quand la stabilit´e augmente jusqu’`a une limite de la disparition du m´elange, quand N2 est tr`es important par rapport aux d´eformations. Ceci limiterait l’utilisation du mod`ele Smagorinsky dans des conditions de forte stabilit´e (Mirocha and Kirkil, 2010). 1.3.4.2 Fermeture SFS TKE d’ordre 1.5 Dans ce mod`ele le coefficient de viscosit´e d’eddy est d´efini par : νT = Cl√ es , (1.8) o`u es est l’´energie cin´etique turbulente sous-maille, et C = 0, 15. Quand cette fermeture est s´electionn´ee, le mod`ele WRF int`egre l’´equation pronostique suivante, de la TKE du SFS (Mirocha et al., 2010) : ∂t(µdes)+Transport = µd(Production cisaillement+Production thermique+Dissipation) (1.9) avec µd, la masse de la colonne d’air sec et le terme de dissipation mod´elis´e par l’expression −Ce 3/2 s /l.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 18 1.3.5 Descente d’´echelle : couplage d’un sch´ema d’ensemble et d’un sch´ema LES Les simulations num´eriques des circulations locales incluant une descente d’´echelle (” oneway ” et ” two-way ”) depuis les dimensions synoptiques jusqu’`a celles de la m´eso-echelle sont largement r´epandues dans la litt´erature et ont montr´e leur efficacit´e (Carlis et al., 2010; C´ec´e et al., 2014; Jury et al., 2009; Lef`evre et al., 2010; Nguyen et al., 2010; Seaman et al., 2012; Yang and Chen, 2005). En revanche la descente d’´echelle (” one-way ” et ” two-way ”) depuis la m´eso-´echelle (sch´ema de moyenne d’ensemble 1D) vers la micro-´echelle (Large Eddy Simulation 3D) est tr`es r´ecente et peu document´ee (Mirocha and Kirkil, 2010). Cette imbrication d’´echelle n´ecessite d’importants moyens de calcul en comparaison avec les simulations m´eso-´echelles. Ces besoins ´elev´es de calcul sont principalement li´es au maillage. La r´esolution minimale requise en LES est de l’ordre de la centaine de m`etres, alors que les sch´emas de moyenne d’ensemble sont limit´es `a la r´esolution du kilom`etre. En g´en´eral, le rapport de r´esolution d’imbrication entre deux domaines est de 3 :1. Dans le cas de l’imbrication m´eso-LES, il sera donc n´ecessaire d’utiliser des domaines interm´ediaires situ´ees dans la ” terra incognita ” (Wyngaard, 2004) du spectre de la turbulence. Enfin, la finesse du maillage LES induit des dur´ees de calcul plus longues, associ´ees `a la diminution du pas de temps et `a l’augmentation de la fr´equence d’appel des sch´emas de mod´elisation de la physique. La plupart des ´etudes traitant le sujet ont ´et´e r´ealis´ees `a partir de l’utilisation du syst`eme coupl´e WRF-LES. Dans le cas d’imbrication id´ealis´ee (sans couplage avec la m´eso-´echelle) de deux domaines LES en ” two-way ”, Moeng et al. (2007) ont montr´e un bon transfert des conditions turbulentes du domaine imbriqu´e vers le domaine parent. Moeng et al. (2007) ont ´enonc´e les probl`emes qui seraient rencontr´es dans le cas du transfert de ces conditions turbulentes d’un domaine LES 3D vers un domaine de moyenne d’ensemble 1D m´eso-´echelle : la diff´erence de pr´ediction du transport turbulent entre les deux domaines (induisant des biais sur les champs de vent et de temp´erature) et le temps de latence aux conditions limites (passage des mouvements turbulents LES dans les ´ecoulements laminaires m´eso- ´echelles). Zhu (2008b) a analys´e un cas r´eel de transport turbulent dans l’ouragan Ivan. Il a utilis´e simultan´ement 6 domaines avec une r´esolution horizontale comprise entre 8100 m et 100 m. Dans les 3 premiers domaines (m´eso-´echelle), les circulations de la couche limite cyclonique ont ´et´e r´esolues par le sch´ema YSU. Dans les 3 autres domaines (micro-´echelle), le mod`ele LES de Smagorinsky a ´et´e s´electionn´e pour r´esoudre les grands tourbillons deChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 19 la turbulence. Les r´esultats WRF-LES du vent de surface (moyenn´e toutes les 10 min) ont montr´e une bonne ad´equation avec les donn´ees d’observation. Par une ´etude similaire WRF-LES, Zhu (2008a) a montr´e que les vents d´evastateurs de l’ouragan Katrina, lors de son arriv´ee sur les cˆotes am´ericaines, avaient pour principale origine les grands tourbillons de la turbulence. L’´evaluation de la ressource ´eolienne, la pr´evision de la puissance ´electrique g´en´er´ee, la conception d’une ferme ´eolienne, n´ecessitent l’analyse, en conditions m´et´eorologiques r´eelles, des ´ecoulements moyens et turbulents. L’imbrication m´eso-´echelle – ´echelle large eddy (” one-way ” et ” two-way ”) commence aussi `a ˆetre appliqu´ee dans le domaine de l’´energie ´eolienne (Liu et al., 2010; Lundquist et al., 2010; Marjanovic et al., 2010). Liu et al. (2010) ont montr´e la capacit´e du syst`eme WRF-LES, incluant l’assimilation de donn´ees d’observation non-maill´ees, `a pr´edire les effets locaux du vent dans une ferme ´eolienne. Talbot et al. (2012) ont men´e les travaux les plus r´ecents sur l’imbrication de domaines LES (dont la plus haute r´esolution est de 50 m) dans les domaines WRF m´eso-´echelles. Ils ont analys´e les performance du syst`eme WRF-LES pour des situations m´et´eorologiques r´eelles. Talbot et al. (2012) ont r´ealis´e la descente d’´echelle en deux ´etapes, `a l’aide de trois domaines m´eso-´echelles (de r´esolutions respectives, 12150 m, 4050 m et 1350 m) et de trois domaines micro-´echelles (de r´esolutions respectives, 450 m, 150 m et 50 m). Le mod`ele de moyenne d’ensemble YSU a ´et´e utilis´e pour la m´eso-´echelle. Les sorties du domaine m´eso-´echelle de plus haute r´esolution (1350 m) ont ensuite ´et´e interpol´ees lin´eairement en temps et en espace pour le for¸cage du domaine LES de plus faible r´esolution (450 m). Les mod`eles sous-mailles TKE ordre 1,5 et Smagorinsky ont ´et´e test´es en LES. Dans le domaine de plus haute r´esolution (50 m), Talbot et al. (2012) ont constat´e que les variations de temp´erature ´etaient bien simul´ees contrairement `a celles de l’humidit´e sp´ecifique. Les vitesses et les directions du vent simul´e pr´esentaient d’importantes erreurs particuli`erement durant la nuit. Talbot et al. (2012) n’ont pas remarqu´e de diff´erences significatives entre les simulations micro-´echelles Smagorinsky et TKE ordre 1,5. 1.4 Simulation num´erique de la dispersion de polluants : applications du mod`ele FLEXPART-WRF L’analyse du transport de polluants dans l’air est essentiel dans la pr´evention des risques sur la sant´e, le suivi de la qualit´e de l’air (pic de pollution r´ecent `a Paris, poussi`eres du Sahara dans l’arc des Petites Antilles), et la s´ecurit´e a´erienne (´eruptions en 2010 duChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 20 volcan Eyjafj¨oll en Islande et du volcan de la Soufri`ere de Montserrat). La connaissance des champs de vent aux diff´erentes ´echelles, macroscopiques et microscopiques, permet de pr´edire les trajectoires des particules. Les deux m´ethodes principalement connues sont : la m´ethode eul´erienne et la m´ethode lagrangienne. La m´ethode eul´erienne consiste `a suivre l’ensemble des concentrations de particule en chaque point du domaine. Cette approche est tr`es gourmande en m´emoire et en temps de calcul. La m´ethode lagrangienne consiste `a suivre une particule ou un groupe de particule. Dans cette section, nous nous focaliserons sur les m´ethodes lagrangiennes et leurs couplages avec le mod`ele m´et´eorologique m´eso- ´echelle WRF. 1.4.1 G´en´eralit´es sur les mod`eles lagrangiens de dispersion de particules (Hegarty et al., 2013a,b) Les mod`eles lagrangiens de dispersion de particules suivent un ensemble de particules en sens direct (” forward ”) depuis une r´egion source et en sens indirect (” backward ”) depuis un r´ecepteur (lieu de mesures) (Hegarty et al., 2013a). Le transport de chacune des particules est bas´e sur les champs de vents moyens (provenant d’un mod`ele num´erique de pr´evision m´et´eorologique) et la composante turbulente du vent obtenue par un mod`ele sous-maille (Hegarty et al., 2013a). L’´evaluation des mod`eles lagrangiens les plus utilis´es, HYSPLIT (Hybrid Single Particle Lagrangian Integrated Trajectory), STILT (Stochastic Time-Inverted Lagrangian Transport) et FLEXPART (FLEXible PARTicle), a montr´e que ces mod`eles ont les mˆemes performances et que la pr´ecision des simulations d´epend principalement des donn´ees m´et´eorologiques utilis´ees comme condition initiale et limite (Hegarty et al., 2013a,b). 1.4.2 Quelques applications du mod`ele FLEXPART-WRF Le syst`eme FLEXPART-WRF (Brioude et al., 2013) repr´esente le mod`ele lagrangien de dispersion de particules FLEXPART (Stohl et al., 2005) qui int`egre les champs m´et´eorologiques m´eso-´echelles du mod`ele WRF (Skamarock et al., 2008) avec le pas de temps souhait´e. Nous d´ecrirons le mod`ele FLEXPART-WRF dans la section 2.4 du rapport. Landgren (2011) a utilis´e le mod`ele FLEXPART-WRF (incluant 3 domaines imbriqu´es de r´esolutions respectives, 9, 3 et 1 km) pour examiner les ´emissions de gaz de trois volcans : Popocat´epetl (Mexique), Tungurahua (Equateur) et Nyiragongo (R´epublique ´ d´emocratique du Congo). Landgren (2011) a constat´e que le mod`ele FLEXPART-WRFChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 21 simulait bien les ´emissions de gaz volcaniques mˆeme pour des petites ´echelles (1 km). Globalement, les mesures de concentration de SO2 ont montr´e une bonne performance du mod`ele dans deux tiers des cas. Cependant les hauteurs et largeurs du panache ´etaient biais´ees, le mod`ele pr´esentait une importante propagation du panache. D’apr`es Landgren (2011), l’am´elioration des donn´ees m´et´eorologiques d’entr´ee pourrait r´eduire ces biais. Dans une ´etude exp´erimentale et num´erique, de Foy et al. (2011) ont examin´e les panaches de polluants affectant le bassin du centre-ville de Mexico. Les mesures lidar ont ´et´e compar´ees aux sorties mod`eles FLEXPART-WRF pour plusieurs groupes d’´emissions : les ´emissions urbaines, les feux de forˆet et les poussi`eres soulev´ees par le vent. Le mod`ele ´etait suffisamment performant pour caract´eriser correctement les types d’a´erosols et leur ˆage (de Foy et al., 2011). A l’aide de FLEXPART-WRF, ` Angevine et al. (2013) ont aussi men´e une ´etude du transport de polluants multi-sources. Ces travaux concernent plusieurs r´egions de la Californie et deux types de traceurs : les ´emissions automobiles (CO) et l’´emission agricole d’ammoniac. Sur plusieurs sites de comparaison, les sorties mod`eles ´etaient qualitativement fid`eles aux observations. Sandeepan et al. (2013) ont montr´e la capacit´e du mod`ele FLEXPART-WRF `a reproduire l’effet de serpentement d’un panache bi-modal (p´eriodicit´e de 30 min) durant un ´ecoulement catabatique. 1.5 Etat de l’art sur les circulations locales g´en´er´ees ´ par des ˆıles tropicales Les effets m´ecaniques des ˆıles sur le flux d’aliz´es continu sont caract´eris´es par un nombre de Froude local Fr qui est d´efini par (U/Nhm), o`u U est la vitesse du vent, hm est la hauteur de l’obstacle, et N est la fr´equence de flottabilit´e. De mani`ere g´en´erale, la litt´erature et en particulier Beucher (2010) analyse les circulations locales pour chacun des trois types d’ˆıles tropicales suivants : les ˆıles larges (avec Fr ≥ 1 et une largeur > 50 km), les ˆıles montagneuses (avec Fr < 1), ou les ˆıles petites (avec Fr ≥ 1 et une largeur ≤ 50 km).Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 22 1.5.1 Circulations g´en´er´ees par les ˆıles tropicales larges (Fr ≥ 1 et une largeur > 50 km) Les effets des ˆıles larges sur les vents synoptiques ont ´et´e examin´es pour les ˆıles Tiwi (Oliphant et al., 2001) et Porto Rico (Jury et al., 2009; Malkus, 1955). Oliphant et al. (2001) ont montr´e qu’avec une topographie plate de 8000 km2 , les ˆıles Tiwi g´en`erent leur propre r´egime de circulations locales d’origine thermique, associ´e avec des brises de mer le jour, et des brises de terre la nuit. Les simulations de la m´et´eorologie m´eso-´echelle de Porto Rico, `a l’aide du mod`ele Weather Research and Forecast (WRF), ont indiqu´e comment le r´echauffement diurne et l’orographie agissent sur la structure de la couche limite convective et le flux d’aliz´es (Jury et al., 2009). 1.5.2 Circulations g´en´er´ees par les ˆıles tropicales montagneuses (Fr < 1) En g´en´eral, les ˆıles montagneuses comme l’archipel d’Hawaii (Carlis et al., 2010; Feng and Chen, 1998; Nguyen et al., 2010; Reisner and Smolarkiewicz, 1994; Smith and Grubiac, 1993; Yang and Chen, 2005), la Nouvelle-Cal´edonie (Lef`evre et al., 2010), l’ˆıle de la R´eunion (Lesou¨ef et al., 2011), ou les ˆıles des Petites Antilles comme Saint-Vincent (Smith et al., 1997) et la Dominique (Minder et al., 2013; Smith et al., 2012) auraient principalement des effets m´ecaniques sur le flux incident (blocage sur la cˆote au vent et contournements, effets d’acc´el´eration de Venturi, panne de vent et tourbillons dans le sillage) avec dans certains cas des circulations thermiques apparaissant sur leurs cˆotes sous le vent. Les r´esultats de l’´etude num´erique id´ealis´ee de Lesou¨ef et al. (2011) ont montr´e que le r´egime des ´ecoulements locaux au-dessus de l’ˆıle de la R´eunion variait avec l’intensit´e des aliz´es. Dans le cas de vitesse de vent synoptique nulle, des circulations thermiques sont g´en´er´ees par les contrastes de temp´erature entre la terre et la mer, et entre l’air et les pentes des montagnes. Pour une vitesse de vent synoptique de 5 m.s-1, le r´egime de vent local est caract´eris´e par une convergence diurne et une divergence nocturne. Des brises thermiques peuvent se produire sur la cˆote sous le vent. Pour une vitesse de vent synoptique de 10 m.s-1, la convergence et la divergence de la circulation sont moins marqu´ees. Les effets thermiques sont inhib´es par les forts aliz´es, cependant il y a des occurrences de brises sur la cˆote sous le vent. Durant la campagne de terrain Dominica Experiment (DOMEX), Minder et al. (2013);Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 23 Smith et al. (2012) ont observ´e que deux types de r´egimes de vent local apparaissaient sur la cˆote sous le vent de l’ˆıle montagneuse de la Dominique en fonction de l’intensit´e des aliz´es. Des vitesses de vent synoptique inf´erieures `a 5 m.s-1 ´etaient associ´ees `a des ´ecoulements anabatiques sur les pentes au vent et sous le vent tandis que celles sup´erieures `a 8 m.s-1 ´etaient associ´ees `a des fort courants descendant les pentes sous le vent du relief. 1.5.3 Circulations g´en´er´ees par les petites ˆıles (Fr ≥ 1 et une largeur ≤ 50 km) Les impacts thermiques des petites ˆıles sur la couche limite atmosph´erique marine ont ´et´e analys´es par des observations et des simulations num´eriques au-dessus de l’ˆıle de la Barbade, dont le diam`etre est de 40 km (Mahrer and Pielke, 1976; Souza, 1972; Whitehall et al., 2013) et au-dessus de l’ˆıle de Nauru, dans le Pacifique, dont le diam`etre est de 5 km (Matthews et al., 2007; Savij¨arvi and Matthews, 2004). Ces ´etudes ont montr´e qu’avec un important r´echauffement de la surface du sol, les petites ˆıles tropicales peuvent g´en´erer leurs propres circulations d’origine convective. Whitehall et al. (2013) ont men´e des simulations WRF d’un ph´enom`ene d’inondations extrˆemes sur l’ˆıle de la Barbade, durant les aliz´es faibles (vitesse de vent inf´erieure `a 5 m.s-1). Les r´esultats de la mod´elisation ont indiqu´e que le d´eveloppement de nuages de convection profonde ´etait conditionn´e par deux m´ecanismes de circulation locale. Premi`erement, un syst`eme de brise de mer induisait une convergence de l’humidit´e dans les basses couches. Deuxi`emement, la topographie de l’ˆıle (sommet `a 366 m AMSL), entraˆınait une ´el´evation m´ecanique de cette masse d’air humide. 1.6 Etat de l’art sur l’archipel de la Guadeloupe ´ 1.6.1 Contexte m´et´eorologique synoptique L’archipel de la Guadeloupe est un ensemble d’ˆıles localis´e `a 61,5➦W et 16,3➦N dans la partie centrale de l’Arc des Petites Antilles (Fig. 1.4). Ces ˆıles travers´ees par les aliz´es ont un climat tropical insulaire caract´eris´e par deux saisons pr´edominantes (Br´evignon, 2003). La premi`ere est une saison relativement s`eche avec des pr´ecipitations tr`es peu intenses, appel´ee le carˆeme. Elle s’´etend de mi-janvier `a mars. La seconde, appel´ee l’hivernage, s’´etend de juillet `a novembre. Elle se caract´erise par des cumuls de pluie plus ´elev´es. L’intensit´e desChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 24 Figure 1.4: Carte topographique GeBCO 08 (General Bathymetric Chart of the Oceans IOC et al. (2003), 30 secondes d’arc de r´esolution) en m : (a) zone de la Cara¨ıbe ; (b) l’Arc des Petites Antilles. pr´ecipitations est le facteur marquant principalement la diff´erence entre ces deux saisons. Les donn´ees d’observation de la station m´et´eorologique du Raizet (RZT, disque rouge, Fig. 1.5), localis´ee en zone convective, indiquent qu’en f´evrier le cumul moyen mensuel est de l’ordre de 60,6 mm tandis qu’en octobre il atteint 214,5 mm. Le cycle saisonnier est une cons´equence de la variation annuelle de la latitude de la zone de convergence intertropicale (ZCIT). Le cycle annuel des pr´ecipitations observ´ees `a la station m´et´eorologique du Raizet indique que le carˆeme correspond `a la position la plus australe de la ZCIT, soit 5➦S, et l’hivernage, `a la position la plus nord soit 10➦N. Br´evignon (2003) a d´ecrit le r´egime des aliz´es arrivant sur l’Arc antillais. Les aliz´es sont g´en´er´es par l’anticyclone des A¸cores dans l’Atlantique nord et soufflent vers les basses pressions ´equatoriales en subissant une d´eviation vers la droite de leur mouvement, li´ee `a la force de Coriolis. La direction et la force des aliz´es d´epend principalement de la position et de l’intensit´e des centres anticycloniques et d´epressionnaires sur l’Atlantique. Durant l’ann´ee, les aliz´es sont en g´en´eral mod´er´es (vitesse de l’ordre de 6 m.s-1). Le passage de perturbations tropicales, subtropicales ou de fronts peut induire dans leur queue une panne d’aliz´es caract´eris´ee par des vents tr`es faibles (vitesse inf´erieure `a 5 m.s-1). Le passage des cyclones tropicaux peut g´en´erer de puissants vents tournants qui ont des vitesses comprises entre 20 et 70 m.s-1 . 1.6.2 Contexte m´et´eorologique local L’archipel de la Guadeloupe comprend deux ˆıles principales (Fig. 1.5) : la Basse-Terre, une ˆıle volcanique montagneuse avec une topographie complexe qui s’´el`eve jusqu’`a 1467 m (le sommet du volcan de la Soufri`ere) et la Grande-Terre, un plateau calcaire avec une faibleChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 25 topographie qui s’´el`eve jusqu’`a 135 m. Ces deux ˆıles sont s´epar´ees par un canal ´etroit, la Rivi`ere sal´ee. Ce dernier est bord´e par deux zones d’eaux peu profondes : Le Petit Cul-de-sac Marin au sud et le Grand Cul-de-sac Marin au nord. D´esirade, Marie-Galante et Les Saintes sont des petites ˆıles de l’archipel. La particularit´e de la Guadeloupe est la combinaison de deux types de topographie (Fig. 1.5) : l’ˆıle montagneuse de la Basse-Terre (Fr < 1 et une largeur ≤ 50 km) et la petite ˆıle, relativement plate, de la Grande-Terre (Fr > 1 et une largeur ≤ 50 km). Il y a tr`es peu d’´etudes traitant des circulations locales au-dessus de la Guadeloupe. Dans la bibliographie, les donn´ees m´et´eorologiques d’observation proviennent principalement de quatre stations M´et´eo-France (Raizet, D´esirade, Moule, et Grand-Bourg) et d’une station cˆoti`ere du Laboratoire de Recherche en G´eosciences et Energie (LaRGE), situ´ee `a ´ Arnouville. Ces stations sont respectivement nomm´ees RZT, DES, MOU, GBD, et ARN (Fig. 1.5). Figure 1.5: Carte topographique (IGN, 50 m de r´esolution), avec la zone la plus peupl´ee de l’archipel (rectangle noir), la d´echarge DCH (carr´e marron), la centrale EDF (croix rouge), le campus de Fouillole (carr´e jaune), le mˆat instrument´e du laboratoire LaRGE (ARN, triangle vert) et les 4 stations M´et´eo-France, Raizet (RZT, disque rouge), Moule (MOU, ´etoile magenta), D´esirade (DES, carr´e bleu), Grand-Bourg de Marie-Galante (GBD, losange noir). 1.6.2.1 Quelques aspects des vents locaux d’apr`es Br´evignon (2003) En se basant sur des observations en mer et des donn´ees de stations terrestres, Br´evignon (2003) a pr´esent´e quelques aspects du vent sur l’archipel. Ils ont d´efini trois r´egimes de circulation locale. Le r´egime au vent : les vents synoptiques continus soufflent sans panneChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 26 de vent nocturne (cas de DES et MOU, Fig. 1.5). Le r´egime continental insulaire au milieu de l’archipel, dans les zones terrestres autour du Grand Cul-de-Sac Marin et du Petit Culde-Sac Marin (cas de ARN, RZT, GBD, Fig. 1.5), avec la nuit, le refroidissement radiatif du sol qui induit une panne de vent dans les basses couches. Le r´egime sous le vent (incluant le r´egime orographique), qui est gouvern´e par des effets thermiques et dynamiques locaux. Le vent est en g´en´eral faible et perturb´e dans la zone sous le vent. Sous des vents synoptiques faibles, la nuit, des apparitions de faibles brises de terre sur la cˆote au vent de la Grande-Terre (MOU, Fig. 1.5) ont ´et´e observ´ees. Br´evignon (2003) a publi´e des cartes de circulations cˆoti`eres (Fig. 1.6) en se basant sur les observations marines empiriques. Pour un vent d’est, les circulations diurnes et les circulations nocturnes semblent similaires (Fig. 1.6). On peut observer, de jour comme de nuit, des effets dynamiques de contourneFigure 1.6: Cartes de circulations cˆoti`eres autour de la Guadeloupe durant des vents synoptiques d’est (d’apr`es Br´evignon (2003)). ment et d’acc´el´eration du vent, ainsi que des retournements du vent qui apparaissent sur la cˆote sous le vent de la Basse-Terre. D’apr`es Br´evignon (2003), le ph´enom`ene de brise de mer–terre serait tr`es discret en Guadeloupe `a cause de la petitesse du territoire. Il a indiqu´e qu’il n’y aurait pas de retournement du vent jour–nuit mais une simple variation dans la direction du vent. Les brises thermiques seraient principalement observ´ees le long de la cˆote sous le vent de la Basse-Terre (Br´evignon, 2003). 1.6.2.2 Campagne exp´erimentale dans la zone cˆoti`ere d’Arnouville (ARN, D’Alexis et al. (2011)) D’Alexis (2011) a men´e une campagne exp´erimentale de terrain pour analyser les ph´enom`enes de micro-´echelle dans la couche de surface de mangrove 3 . Entre avril 2007 et avril 3. Milieu naturel cˆotier avec une v´eg´etation semi-immerg´ee domin´ee par les pal´etuviers.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 27 2008, la station m´et´eorologique du Laboratoire de Recherche en G´eosciences et Energie ´ (LaRGE) a enregistr´e des mesures `a 1 Hz et `a 20 Hz. Cette station ´etait localis´ee dans la zone cˆoti`ere d’Arnouville sur la cˆote au vent de la Basse-Terre (ARN, Fig. 1.5). Les donn´ees recueillies sur une ann´ee ont montr´e qu’en g´en´eral, sous des aliz´es faibles `a mod´er´es, il y a des apparitions d’un renversement nocturne du vent dans les bas niveaux verticaux. Cet ´ecoulement nocturne d’ouest est associ´e `a une chute soudaine de la temp´erature de l’air `a 2 m AGL. La localisation (une zone cˆoti`ere en bas des pentes au vent de la chaˆıne de montagnes), pourrait sugg´erer un vent catabatique et–ou une brise de terre. Durant 261 jours de mesure (entre avril 2007 et avril 2008), D’Alexis et al. (2011) ont observ´e 121 jours d’occurrence de cet ´ecoulement nocturne (i.e. une fr´equence d’apparition d’un jour sur deux). Cette observation indiquerait que durant la campagne exp´erimentale, pr`es de la moiti´e des nuits ont ´et´e marqu´ees par cet ´ecoulement. Sur l’ann´ee, d´ecembre est le mois de fr´equence maximale du ph´enom`ene, alors que juin est celui de fr´equence minimale. D’Alexis et al. (2011) ont constat´e que cet ´ecoulement inverse du vent pouvait s’´etablir pendant toute la nuit, ou ˆetre intermittent avec le retour des ´ecoulements classiques des aliz´es. Les circulations nocturnes particuli`eres observ´ees par Br´evignon (2003); D’Alexis et al. (2011), ont une direction ouest, une vitesse de vent inf´erieure `a 2 m.s-1, et semblent repousser au large les aliz´es des basses couches. 1.6.2.3 Campagne exp´erimentale dans la zone urbaine de Pointe-`a-Pitre (DCH, Plocoste (2013); Plocoste et al. (2014)) Plocoste (2013) a men´e une campagne exp´erimentale sur la dispersion des compos´es organiques volatils de la d´echarge de la Gabarre (DCH, Fig. 1.5) situ´ee dans l’agglom´eration pointoise, sur la cˆote ouest de la Grande-Terre `a 7 km de ARN. Durant des aliz´es faibles, Plocoste et al. (2014) ont observ´e la pr´esence d’un renversement nocturne du vent qui adopte une direction ouest et une vitesse inf´erieure `a 2 m.s-1. Ce flux ´etait associ´e `a une baisse locale de la temp´erature de l’air. Les mesures de la station RZT (entre 2000 et 2012) ont montr´e que ce ph´enom`ene ´etait plus fr´equent durant le mois de d´ecembre et bien moins fr´equent au cours du mois de juin (Plocoste, 2013). Cette mˆeme variation annuelle avait ´et´e constat´ee par D’Alexis et al. (2011) `a la station ARN. Plocoste et al. (2014) ont attribu´e l’origine de cet ´ecoulement `a la pr´esence d’un ˆılot de chaleur urbain dans la zone et l’ont d´efini comme une brise urbaine. D’apr`es nous, l’origine purement urbaine de cet ´ecoulement serait discutable pour les raisons suivantes. Les mesures exp´erimentales de D’Alexis et al. (2011) effectu´ees dans les mˆemes conditions m´et´eorologiques, sugg´ereraient que l’´ecoulement d’ouest observ´e par Plocoste (2013) est g´en´er´e, en amont, sur la cˆoteChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 28 au vent de la Basse-Terre avec une extension vers la Grande-Terre. Les observations du panache de la centrale EDF de Jarry (Fig. 1.7, 1.8, 1.9) confirmeraient cette extension de l’´ecoulement vers la cˆote ouest de la Grande-Terre (sous-section 1.6.3). 1.6.2.4 Variabilit´e diurne et spatiale des champs de surface Au-dessus des ˆıles de l’archipel de la Guadeloupe, la temp´erature de l’air `a 2 m augmente en g´en´eral de 5➦C entre 6 h et 10 h LT 4 et atteint sa valeur maximale `a 13 h LT (Br´evignon, 2003). Le refroidissement radiatif commence `a la fin de l’apr`es-midi (17 h LT) et la temp´erature minimale est atteinte le lendemain matin `a 5 h LT. Durant ses travaux de th`ese, D’Alexis (2011) a examin´e la relation entre le cycle diurne (moyenn´e sur les six mois de la saison s`eche de l’ann´ee 2008) de la temp´erature de l’air `a 2 m et celui de la vitesse du vent `a 10 m. La station m´et´eorologique de la D´esirade, DES, est caract´eris´ee par des vents soutenus (7–8 m.s-1) avec une absence de variations diurnes de la vitesse du vent `a 10 m. Les donn´ees de vent de cette station peuvent ˆetre utilis´ees pour d´ecrire de mani`ere grossi`ere le vent synoptique incident. Pour les stations du Raizet et d’Arnouville, respectivement, RZT et ARN, qui sont sous l’influence du r´egime continental insulaire, les temp´eratures et les vitesses de vent semblent avoir une ´evolution horaire quasiment synchronis´ee. Les cycles diurnes de temp´erature et la moyenne annuelle de la temp´erature de l’air audessus de la mer (27➦± 0,5➦C) indiquent que le contraste thermique le plus important entre la terre et la mer apparaˆıt durant la nuit (le contraste mer–RZT atteint 4,7➦C `a 5 h LT). De plus, les cycles diurnes de la vitesse du vent `a 10 m montrent que les diff´erences majeures entre le vent synoptique (station DES) et le vent local (stations continentales insulaires) se produisent `a partir de l’heure du d´ebut de refroidissement radiatif. Ceci peut sugg´erer que durant la nuit, les circulations locales sont mieux marqu´ees que durant le jour. Dans le cas de RZT, `a partir de minuit, le plus souvent, il y a une absence totale de vent. A` cause du refroidissement nocturne, une couche froide de surface se d´eveloppe au-dessus de la Grande-Terre, et les aliz´es plus chauds sont oblig´es de passer au-dessus de cette couche (Br´evignon, 2003). 4. Temps local, de l’anglais : Local Time ; en Guadeloupe l’heure LT correspond `a l’heure UTC−4Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 29 1.6.3 Impacts des circulations locales nocturnes sur la dispersion de polluants industriels 1.6.3.1 Centrale EDF diesel Jarry nord Malgr´e le d´eveloppement des ´etudes sur la caract´erisation de ressources ´energ´etiques renouvelables dans l’Arc des Petites Antilles (comme l’´energie marine, l’´eolien ou le solaire), l’´electricit´e est presque exclusivement produite `a partir de sources fossiles. En Guadeloupe, la principale usine de production d’´electricit´e est la centrale EDF diesel Jarry nord (Fig. 1.7), situ´ee dans la zone industrielle de Jarry (Petit Cul-de-Sac Marin, Fig. 1.5 et Fig. 1.8). Cette centrale constitue la premi`ere source industrielle d’´emissions de polluants. Figure 1.7: Photo des chemin´ees de la centrale ´electrique EDF Jarry nord, [cr´edit photo : R. C´ec´e 2014]. D’apr`es le Registre fran¸cais des Emissions polluantes ´ , la centrale EDF Jarry nord ´emet en moyenne chaque ann´ee, 0,5 M´egatonnes de dioxyde de carbone (CO2), 10 kilotonnes d’oxydes d’azote (NOx) et 3 kilotonnes d’oxydes de soufre (SOx). La dispersion de ces rejets importants doit ˆetre examin´ee pour pr´evenir les risques sanitaires.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 30 Figure 1.8: Photo satellite Google earth (8/04/2013) : localisation de la centrale EDF et du campus UAG, les fl`eches rouges correspondant aux directions (a) et (b) du panache durant une circulation nocturne d’ouest (Fig. 1.9). 1.6.3.2 Observations du panache de la centrale durant des retournements nocturnes du vent Des observations du panache de la centrale EDF Jarry nord nous ont permis de d´etecter, en d´ebut de matin´ee, le renversement nocturne du vent dans la couche limite stable (Fig. 1.9). Dans le cas du 14 septembre 2010 `a 7 h 21 LT, le vent dans les basses couches a une direction nord-ouest, le panache se dirige vers le campus universitaire de Fouillole (Fig. 1.9a, 1.8). Le radiosondage du jour (lanc´e `a 7 h LT depuis la station RZT) indique une faible vitesse du vent dans les basse couches (< 0,5 m.s-1, `a 125 m AGL) et une ´epaisseur de la couche limite stable de 400 m. Dans le cas du 4 novembre 2009 `a 7 h 11 LT, le vent de basses couches a une direction sud-ouest, le panache se dirige vers le pont de la Gabarre (Pointe-`a-Pitre, Fig. 1.9b, 1.8). Comme pour la pr´ec´edente situation, l’analyse du radiosondage correspondant montre de faibles vitesses du vent dans les basses couches (≈ 3 m.s-1 `a 325 m AGL) et une couche limite stable plus d´evelopp´ee (550 m). Ces observations confirment la pr´esence d’une circulation d’ouest dans le Petit Cul-de-Sac Marin, en amont de la zone urbaine de Pointe-`a-Pitre. Cet ´ecoulement local nocturne d’ouest, soufflant en direction de la partie la plus peupl´ee de l’archipel en passant par la zone industrielle de Jarry, dans laquelle plusieurs sources d’´emissions de polluants sont pr´esentes, n´ecessite une analyse 3D de sa structure et des m´ecanismes de sa formation dans les basses couches de l’atmosph`ere surplombant l’archipel.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude bibliographique 31 Figure 1.9: Photos du panache de la centrale EDF de Jarry (prise de vue depuis le campus de Fouillole UAG, Fig. 1.8) : (a) direction du vent nord-ouest, photo prise le 14/09/2010 `a 7 h 21 LT ; (b) direction du vent sud-ouest, photo prise le 4/11/2009 `a 7 h 11 LT [cr´edits photos : D. Bernard 2009-2010].Chapitre 2 M´ethodologie et outils de simulation 2.1 M´ethodologie g´en´erale Les travaux de mod´elisations num´eriques pr´esent´es ont deux objectifs principaux. Premi`erement, l’analyse des m´ecanismes m´eso- et micro-´echelles qui induisent des circulations locales diurnes et nocturnes sur les ˆıles de la Guadeloupe. Deuxi`emement, l’´etude des effets de ces circulations sur la dispersion du panache de la source industrielle la plus polluante de l’archipel. Pour atteindre ces objectifs, la m´ethodologie suivante a ´et´e adopt´ee (Fig. 2.1). Nous avons choisi trois situations m´et´eorologiques r´eelles d´ependant de la vitesse du flux incident des aliz´es et excluant les perturbations synoptiques pluvieuses : les aliz´es faibles (AF), les aliz´es soutenus (AS), et les aliz´es moyens (AM), correspondant aux p´eriodes respectives, 3/12/2007 6 h UTC–5/12/2007 6 h UTC 1 , 14/12/2007 6 h UTC–16/12/2007 6 h UTC, et 24/12/2007 6 h UTC–26/12/2007 6 h UTC. Pour ces trois types de temps nous avons simul´e, `a l’aide du mod`ele WRF ARW V3.4.1, une descente d’´echelle ” two-way ” jusqu’`a 1 km de r´esolution (m´eso-´echelle), avec l’assimilation des donn´ees d’analyse mondiale FNL NCEP (NCEP (ment), 110 km de r´esolution) aux conditions limites du domaine de plus basse r´esolution. Quatre domaines imbriqu´es, D01, D02, D03 et D04 (de r´esolutions respectives 27, 9, 3 et 1 km) ont ´et´e employ´es, le domaine D04 couvrant la totalit´e de l’archipel de la Guadeloupe (Fig. 2.10). L’intervalle de temps des sorties mod`eles est horaire. La turbulence de la CLP est mod´elis´ee par le sch´ema 1. Temps universel coordonn´e, de l’anglais : Universal Time Coordinated ; en Guadeloupe l’heure UTC correspond `a l’heure LT+4 32Chapitre 2. M´ethodologie et principaux outils de simulation 33 d’ensemble 1D YSU (Hong et al., 2006). Les ´echanges sol–atmosph`ere gouvernent le bilan ´energ´etique de surface et sont succeptibles d’induire des circulations locales d’origine thermique et dynamique. Afin d’obtenir des simulations pertinentes, il est n´ecessaire de disposer de cartes d’occupation des sols r´ealistes, d´ecrivant avec pr´ecision les diff´erentes cat´egories succeptibles d’exister dans le territoire `a ´etudier. Pour la descente d’´echelle m´eso-´echelle, deux exp´eriences num´eriques ont ´et´e r´ealis´ees. La premi`ere, ” M´eso-A ”, inclut dans le domaine D04 la carte d’occupation des sols USGS Advanced Very High Resolution Radiometer (AVHRR) d’1 km de r´esolution qui r´esulte d’analyses d’images satellites datant de 1992 (Anderson et al., 1976; Eidenshink and Faundeen, 1994). La seconde, ” M´eso-A’ ”, inclut dans le domaine D04 la carte d’occupation des sols Coordination of Information on the Environment (Corine Land Cover, CLC2006), de 23 m de r´esolution qui a ´et´e produite `a partir d’images satellites plus r´ecentes, de 2006 (EEA, 2007). Les r´esultats de l’exp´erience M´eso-A ont ´et´e publi´es par C´ec´e et al. (2014). L’article est pr´esent´e dans la section 3.1.1 du rapport. Les r´esultats de l’exp´erience M´eso-A’ nous permettent d’´evaluer l’impact de la carte d’occupation des sols Corine 2006 sur les circulations locales g´en´er´ees par la Guadeloupe. Les champs de surface simul´es dans le domaine D04 sont ´evalu´es `a l’aide des donn´ees d’observation de 5 stations m´et´eorologiques. Les simulations micro-´echelles WRF-LES sont r´ealis´ees `a l’aide de deux nouveaux domaines (Fig. 2.10) : D05 (333 m de r´esolution) et D06 (111 m de r´esolution). Le domaine D05 inclut l’ˆıle de la Basse-Terre et la cˆote ouest de la Grande-Terre. Le domaine D06 couvre la zone du Petit Cul-de-Sac Marin incluant la zone d’Arnouville (ARN), la zone industrielle de Jarry et Pointe-`a-Pitre. Les domaines D05 et D06 ont une imbrication ” one-way ”. Les conditions limites du domaine D05 sont d´efinies par les sorties horaires du domaine m´eso-´echelle D04 via une fonction d’interpolation WRF ” NDOWN ” (avec une m´ethode spline cubique). WRF-LES r´esoud explicitement en 3D les ´echelles de production et de transport de l’´energie cin´etique turbulente tandis que sa dissipation est mod´elis´ee par le mod`ele de fermeture TKE d’ordre 1,5. L’intervalle de temps des sorties WRF-LES pour les deux domaines est de 10 minutes. Le choix de cet intervalle de temps repose sur deux contraintes, le volume des donn´ees de sortie (150 Mo par sortie) et la possibilit´e de comparer les donn´ees num´eriques avec des donn´ees d’observations de station. Ces champs simul´es infra-horaires sont ´evalu´es `a l’aide des donn´ees d’observation du mˆat instrument´e ARN (la direction DD et la vitesse UU du vent horizontal `a 10 m AGL, la temp´erature de l’air `a 2 m AGL T2, le flux de chaleur sensible HFX, l’´energie cin´etique turbulente TKE, etc.). Enfin, nous avons utilis´e un couplage WRF-LES-FLEXPART pour ´etudier la pollution de la centrale diesel EDF de Jarry. La dispersion du panache de NOx de la centrale estChapitre 2. M´ethodologie et principaux outils de simulation 34 simul´ee pour des p´eriodes de 24 h pour chaque type de temps. Le mod`ele lagrangien FLEXPART-WRF est forc´e toutes les 10 minutes avec les sorties WRF-LES. Les simulations WRF-LES-FLEXPART sont r´ealis´ees dans le domaine LES D06. Les concentrations de NOx simul´ees par le syst`eme WRF-LES-FLEXPART sont moyenn´ees et sauv´ees toutes les 10 minutes. Ces sorties sont compar´ees, graphiquement, avec les donn´ees d’observation de l’unique station de mesure de la qualit´e de l’air dans la zone (station de Pointe-`a-Pitre de l’association agr´e´ee de surveillance de la qualit´e de l’air en Guadeloupe, Gwad’air).Chapitre 2. M´ethodologie et principaux outils de simulation 35 Figure 2.1: Sch´ema r´ecapitulatif de la m´ethodologie adopt´ee.Chapitre 2. M´ethodologie et principaux outils de simulation 36 2.2 S´election des trois situations m´et´eorologiques ´etudi´ees 2.2.1 Classification des types de temps Nous utiliserons la classification climatologique des types de temps dans les Petites Antilles et la Guyane, d´ecrite dans le rapport de stage de K. Morvan (R´ealisation d’une climatologie et dune classification en type de temps sur les Petites Antilles et la Guyane, Universit´e des Antilles et de la Guyane, M´et´eo-France, 2011). Cette classification obtenue par des k-moyennes est fond´ee sur 20 ans d’observations des stations m´et´eorologiques locales et sur les champs de r´e-analyses Era-Interim du Centre europ´een pour les pr´evisions m´et´eorologiques `a moyen terme (CEPMMT, en anglais : European Center for Medium range Weather Forecasting, ECMWF). Elle utilise les variables r´e-analys´ees suivantes : la vitesse du vent horizontal `a 850 hPa, la vitesse du vent vertical `a 600 hPa, la divergence du vent horizontal `a 200 hPa, la pression au niveau de la mer (Pmer), la temp´erature de l’air `a 2 m, la temp´erature de l’air `a 925 hPa et la temp´erature potentielle du thermom`etre mouill´e `a 850 hPa. Pour simuler et examiner les circulations du vent local g´en´er´ees par l’archipel de la Guadeloupe, trois types de temps issus de cette classification ont ´et´e choisis. Le for¸cage principal est la vitesse du flux incident des aliz´es, en conformit´e avec la m´ethode pr´esent´ee par Lesou¨ef et al. (2011) et Smith et al. (2012). Les aliz´es faibles (AF), les aliz´es moyens (AM), et les aliz´es soutenus (AS) sont associ´es `a des vitesses de vent respectives de 3, 6, et 12 m.s-1. D’apr`es Br´evignon (2003) les AM repr´esentent le type de temps le plus fr´equent durant l’ann´ee (60% des cas). Les AS et AF constituent chacun 10% des cas durant l’ann´ee, les 20% des cas restants correspondent aux fortes perturbations pluvieuses (les fronts d´epressionnaires, les ondes d’est, les cyclones, etc.). Dans le but d’´etudier les m´ecanismes qui induisent les retournements nocturnes du vent des basses couches `a ARN, les jours simul´es ont ´et´e s´electionn´es durant la p´eriode de la campagne exp´erimentale de D’Alexis (2011), soit d’avril 2007 `a juin 2008. Le mois de d´ecembre a ´et´e choisi car ce mois, correspondant `a l’initiation de la saison s`eche, inclut aussi bien l’apparition des trois types de temps (AS, AM et AF), l’absence de fortes perturbations synoptiques que des fr´equences ´elev´ees des retournements nocturnes du vent. A partir de ces crit`eres, nous avons s´electionn´e trois p´eriodes de 48 heures, correspondant `Chapitre 2. M´ethodologie et principaux outils de simulation 37 respectivement aux situations m´et´eorologiques, AF, AS, et AM : 3/12/2007 6 h UTC– 5/12/2007 6 h UTC, 14/12/2007 6 h UTC–16/12/2007 6 h UTC, et 24/12/2007 6 h UTC– 26/12/2007 6 h UTC (avec le temps UTC correspondant `a LT+4). Les observations effectu´ees `a partir des images radar M´et´eo-France montrent une couverture nuageuse tr`es faibles durant ces trois p´eriodes (Fig. 2.2). La couverture nuageuse pr´esente sur la chaˆıne de montagne de la Basse-Terre, durant les AS (Fig. 2.2a) est caract´eristique d’un r´egime orographique. Figure 2.2: Donn´ees d’observation du radar de M´et´eo-France (250 m de r´esolution) `a 16 h LT : (a) le 15 d´ecembre 2007 (AS), (b) le 24 d´ecembre 2007 (AM) et (c) le 3 d´ecembre 2007 (AF). 2.2.2 Circulations synoptiques de basses couches pour les dates simul´ees Pour d´ecrire les circulations synoptiques de basses couches correspondant `a chaque type de temps (AF, AS, et AM), les champs de surface FNL (NCEP (ment), 1➦ de r´esolution) sont examin´es dans la zone centrale de l’oc´ean Atlantique (latitudes comprises entre 5➦N et 35➦N et longitudes comprises entre 70➦W et 10➦W). Le flux d’aliz´es arrivant sur les Antilles est principalement conditionn´e par la position et la force des cellules anticycloniques des A¸cores et des Bermudes. Durant les AF, le 3 d´ecembre 2007 `a 12 h UTC, la faible cellule anticyclonique des Bermudes est s´epar´ee de celle des A¸cores par un creux barom´etrique (avec une Pmer minimale de 1005 hPa). Nous observons un front d´epressionnaire de 1012 hPa (22➦N, 54➦W, Fig. 2.3a) qui induit, dans sa queue, une zone de vents faibles affectant la Martinique, la Dominique et la Guadeloupe (Fig. 2.3b). Sur l’Arc des Petites Antilles, le gradient de pression horizontale a une faible valeur de 0,2 hPa sur 100 km (Fig. 2.3a). Les aliz´es arrivant sur la Guadeloupe ont une direction nord-est et une vitesse inf´erieure `a 5 m.s-1 (Fig. 2.3b).Chapitre 2. M´ethodologie et principaux outils de simulation 38 Figure 2.3: Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AF le 3/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal `a 10 m en m.s-1 . Durant les AS, le 14 d´ecembre 2007, le fort anticyclone des Bermudes est en position basse, l’isobare 1024 hPa est positionn´ee `a 25➦N (Fig. 2.4a). Il y a un resserrement des isobares, le gradient de pression horizontale atteint sur l’Arc des Petites Antilles, la valeur de 0,6 hPa sur 100 km. Les aliz´es incidents ont des vitesses ´elev´ees de 12 m.s-1 et une direction est-nord-est quasi-uniforme (Fig. 2.4b). La l´eg`ere d´ec´el´eration du vent autour de la Martinique, de la Dominique et de la Guadeloupe pourrait sugg´erer un freinage du flux par l’orographie de ces ˆıles montagneuses. Durant les AM, le 24 d´ecembre 2007, les deux cellules anticycloniques sont en position haute (Fig. 2.5a). Elles sont s´epar´ees par un faible creux barom´etrique (avec une Pmer minimale de 1018 hPa). Les AM sont caract´eris´es par des vents d’est mod´er´es arrivant sur les Petites Antilles (7 m.s-1, Fig. 2.5b). Sur l’Arc, le gradient de pression horizontale a une valeur moyenne de 0,4 hPa sur 100 km. Au passage de l’Arc antillais, le flux d’aliz´es subit une d´ec´el´eration de 2 m.s-1 (Fig. 2.5b).Chapitre 2. M´ethodologie et principaux outils de simulation 39 Figure 2.4: Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AS le 14/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal `a 10 m en m.s-1 .Chapitre 2. M´ethodologie et principaux outils de simulation 40 Figure 2.5: Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AM le 24/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal `a 10 m en m.s-1 .Chapitre 2. M´ethodologie et principaux outils de simulation 41 2.3 Mod`ele num´erique m´eso-´echelle de pr´evision m´et´eorologique : WRF ARW V3.4.1 2.3.1 Description du mod`ele d’apr`es les ´etudes de Skamarock et al. (2008) et Wang et al. (2010) Le mod`ele Weather Research and Forecasting ARW (WRF ARW, Skamarock et al. (2008)) est un mod`ele atmosph´erique non-hydrostatique et compressible con¸cu par le National Center for Atmospheric Research (NCAR). WRF ARW est largement utilis´e en recherche scientifique et en pr´evision op´erationnelle. C’est un code num´erique dit open-source (libre de t´el´echargement, d’utilisation et de d´eveloppement). WRF est principalement support´e et d´evelopp´e par la Mesoscale and Microscale Meteorology Division du NCAR. Ce mod`ele m´et´eorologique permet une grande vari´et´e de mod´elisations de l’atmosph`ere : des applications depuis l’´echelle globale jusqu’`a l’´echelle LES, des descentes d’´echelle dynamiques ” one-way ” ou ” two-way ”, des simulations id´ealis´ees ou r´eelles incluant le for¸cage par des champs de mod`eles globaux (type GFS, FNL, ou des r´e-analyses Era-Interim), des assimilations de donn´ees d’observation en temps r´eel pour la pr´ediction... Il contient plusieurs conditions de limites lat´erales avec un ensemble d’options de param´etrisation physique. 2.3.1.1 Architecture Wang et al. (2010) ont d´ecrit l’architecture du mod`ele WRF (Fig. 2.6). Pour des simulations de cas r´eels, le programme WRF Preprocessing System (WPS) est utilis´e. Ses fonctions permettent : de d´efinir les domaines de simulation ; d’interpoler les donn´ees terrestres statiques (comme la topographie et l’occupation des sols) sur les domaines de simulation ; et d’interpoler les donn´ees m´et´eorologiques maill´ees d’un autre mod`ele (GFS, FNL NCEP, Era-Interim, ...). Les donn´ees d’observation non maill´ees (stations m´et´eorologiques, radar, ...) peuvent ˆetre ´egalement int´egr´ees, filtr´ees et valid´ees par le syst`eme d’assimilation WRF-Var ou le syst`eme d’analyse OBSGRID. Le coeur dynamique ARW utilise les sch´emas de second et troisi`eme ordre de Runge-Kutta pour g´en´erer les pr´evisions. Les sorties WRF peuvent ˆetres lues et trait´ees par plusieurs outils de visualisation (VAPOR, NCAR Command Language (NCL), ou RIP4). Le programme MET permet de les formater pour leur assimilation dans WPS.Chapitre 2. M´ethodologie et principaux outils de simulation 42 Figure 2.6: Architecture du mod`ele WRF ARW (d’apr`es Wang et al. (2010)). 2.3.1.2 Principales ´equations r´esolues Le coeur dynamique ARW r´esout les ´equations d’Euler non-hydrostatiques et compressibles (Skamarock et al., 2008). Le mod`ele suit la philosophie de Ooyama (1990), ces ´equations sont exprim´ees sous forme de flux de variables conservatrices (i.e., la chaleur, la quantit´e de mouvement, etc.). Les ´equations sont formul´ees en utilisant une coordonn´ee verticale hydrostatique, η, qui d´epend des variations topographiques (Kasahara, 1974; Laprise, 1992). Coordonn´ee verticale η et variables associ´ees La coordonn´ee verticale d´ependant de la pression hydrostatique (ph = ρgH) et donc de la topographie, est appel´ee η et d´efinie par : η = (ph − pht)/µd o`u µd = phs − pht. (2.1) ph est la pression hydrostatique, pht et phs, repr´esentent respectivement, les pressions hydrostatiques au sommet et `a la surface. Les valeurs de η sont normalis´ees et varient entre 1 `a la surface et 0 au sommet du mod`ele (Fig. 2.7). Avec µd(x,y) repr´esentant laChapitre 2. M´ethodologie et principaux outils de simulation 43 masse de la colonne d’air sec par unit´e de surface au point (x,y), les variables s’´ecrivent : V = µdv = (U, V, W), Ω = µdη,˙ Θ = µdθ. (2.2) v = (u, v, w) sont les vitesses covariantes en 3D (base vectorielle), ω = ˙η est la vitesse verticale contravariante (vitesse associ´ee au changement de coordonn´ee verticale), θ est la temp´erature potentielle. Dans les ´equations gouvernantes de ARW, les variables nonconserv´ees suivantes apparaissent : le g´eopotentiel φ = gz (avec g l’acc´el´eration de la pesanteur), la pression p, et le volume massique α = 1/ρ. Figure 2.7: Niveaux verticaux η dans WRF ARW avec pht et phs, respectivement, les pressions hydrostatiques au sommet et `a la surface (d’apr`es Skamarock et al. (2008)). Equations d’Euler incluant l’humidit´e ´ En utilisant la coordonn´ee verticale adimensionnelle η et les variables associ´ees d´ecrites ci-dessus, Skamarock et al. (2008) ont ´ecrit les ´equations d’un fluide parfait compressible, le long de la colonne d’air (axe-η). Ces ´equations sont dites d’Euler et ont ´et´e pr´esent´eesChapitre 2. M´ethodologie et principaux outils de simulation 44 par Laprise (1992), pour les avantages qu’elles offrent en simulation atmosph´erique nonhydrostatique : ∂tU + (∇.Vu) + µdα∂xp + (α/αd)∂ηp∂xφ = FU (2.3) ∂tV + (∇.Vv) + µdα∂yp + (α/αd)∂ηp∂yφ = FV (2.4) ∂tW + (∇.Vw) − g[(α/αd)∂ηp − µd] = FW (2.5) ∂tΘ + (∇.Vθ) = FΘ (2.6) ∂tµd + (∇.V) = 0 (2.7) ∂tφ + µ −1 d [(V.∇φ) − gW] = 0 (2.8) ∂tQm + (∇.Vqm) = FQm (2.9) en incluant la relation diagnostique pour le volume massique d’air sec, ∂ηφ = −αdµd, (2.10) et l’´equation d’´etat des gaz atmosph´eriques p = p0(Rdθm/p0αd) γ . (2.11) γ = cp/cv = 1.4 est le rapport de capacit´e thermique pour l’air sec, Rd est la constante des gaz parfaits pour l’air sec, et p0 est la pression de r´ef´erence (1000 hPa). Les termes FU , FV , FW , FΘ et FQm repr´esentent les for¸cages provenant de la physique du mod`ele, du m´elange turbulent, de la vapeur d’eau, des projections sph´eriques et de la rotation de la Terre. Les ´equations 2.3 et 2.4 repr´esentent les ´equations de la quantit´e de mouvement horizontale. Les ´equations 2.5, 2.6, 2.7, 2.8 et 2.9 d´ecrivent respectivement, la quantit´e de mouvement verticale, l’´equation thermodynamique, l’´equation de continuit´e, l’´equation de la hauteur du g´eopotentiel et l’´equation de l’humidit´e. Skamarock et al. (2008) ont exprim´e ces ´equations eul´eriennes humides sous forme de perturbations par rapport `a un ´etat de r´ef´erence (avec les variables d´efinies suivant la d´ecomposition de Reynolds (1947) p = ¯p(¯z)+p 0 , φ = φ¯(¯z)+φ 0 , α = ¯α(¯z)+α 0 , µd = ¯µd(x, y)+µ 0 d ) et en utilisant des facteurs d’´echelle et des termes rotationnels. Maillage ARW d´ecal´e : Arakawa-C La r´esolution num´erique des ´equations d´efinies dans la section pr´ec´edente (Eq. 2.3-2.8) se fait `a l’aide d’un maillage d´ecal´e. Les grandeurs vectorielles (U, V , W, Ω et φ) sontChapitre 2. M´ethodologie et principaux outils de simulation 45 moyenn´ees sur les arˆetes de la maille et les grandeurs scalaires (µ, θ, qv et ql) sont moyenn´ees au centre de la maille (Fig. 2.8). Ce sch´ema est d´enomm´e Arakawa de type C du nom d’un de ses cr´eateurs (Arakawa and Lamb, 1977), il est particuli`erement utilis´e dans les r´esolutions d’´ecoulements g´eophysiques (oc´ean et atmosph`ere). Figure 2.8: Maille individuelle de la grille Arakawa-C avec les grandeurs vectorielles (U, V , W, Ω et φ) et les scalaires (µ, θ, qv et ql) (Skamarock and Dudhia, 2014). 2.3.1.3 Sch´emas de param´etrisation physique Les cat´egories de param´etrisation physique disponibles dans WRF sont : la microphysique, la convection, la couche de surface, la surface du sol (canop´ee), le rayonnement et la couche limite plan´etaire (CLP) (Skamarock et al., 2008). Les interactions entre les sch´emas de param´etrisation ont ´et´e r´esum´ees par Dudhia (2014) dans la Fig. 2.9. La microphysique r´esout explicitement 2 les processus suivants : les changements d’´etats de la vapeur d’eau, la formation nuageuse et les pr´ecipitations. Les sch´emas de convection sont responsables de la prise en compte des ph´enom`enes se produisant `a l’´echelle de la sous-maille, provenant de nuages de convection profonde et peu profonde : repr´esentation des flux verticaux associ´es aux mouvements ascendants et descendants. Ces sch´emas sont importants car ils permettent de r´eduire le coˆut de calcul qui serait n´ecessaire `a la r´esolution de ces ph´enom`enes avec un maillage plus fin. 2. L’´etat actuel est calcul´e uniquement `a l’aide des ´etats pr´ec´edents.Chapitre 2. M´ethodologie et principaux outils de simulation 46 Figure 2.9: Interactions entre les sch´emas de param´etrisation physique du mod`ele WRF ARW (Dudhia, 2014). Les sch´emas de couche de surface calculent les vitesses de friction et les coefficients d’´echange. Ces variables permettent le calcul des flux de chaleur et d’humidit´e dans les mod`eles de surface et le calcul du tenseur des contraintes de surface dans les sch´emas de couche limite plan´etaire (CLP). Les mod`eles de surface utilisent l’information atmosph´erique fournie par la couche de surface, le rayonnement et la microphysique (pr´ecipitations) pour produire les flux de chaleur et d’humidit´e associ´es aux variables d’´etat du sol et aux propri´et´es de surface (rugosit´e, alb´edo, ...). Les sch´emas de CLP d´eterminent les profils de flux dans la couche limite de m´elange et la couche stable. Ces sch´emas fournissent des ´evolutions spatio-temporelles de la temp´erature, de l’humidit´e et de la quantit´e de mouvement horizontal dans la colonne atmosph´erique. Enfin, les sch´emas de rayonnement mod´elisent la divergence du flux radiatif (r´eflexion, diffusion, effets des nuages) et les flux des grandes et courtes longueurs d’onde arrivant `a la surface.Chapitre 2. M´ethodologie et principaux outils de simulation 47 2.3.2 Configurations utilis´ees 2.3.2.1 Preprocessing WPS Domaines de simulation Les simulations WRF incluent 6 domaines imbriqu´es dont les zones de couverture et les r´esolutions ont ´et´e s´electionn´ees en fonction des objectifs de la mod´elisation et des recommandations de Skamarock et al. (2008) (comme le rapport de r´esolution entre un domaine parent et un domaine imbriqu´e de [3 :1]). Dans le but de simuler les circulations locales m´eso-´echelles induites par les interactions entre les vents synoptiques et des petites ˆıles comme la Guadeloupe, nous avons utilis´e une descente d’´echelle ” two way ” avec quatre domaines (D01, D02, D03, D04, de r´esolutions respectives en km : 27, 9, 3, 1)(Fig. 2.10). Le domaine de plus basse r´esolution, D01, couvre une grille de 80 x 80 mailles [longitude x latitude] dans la zone centrale de l’Atlantique (de l’Am´erique du Sud `a la R´epublique Dominicaine). Le domaine D02 couvre une grille de 121 x 109 mailles dans l’Arc des Petites Antilles. Le domaine D03 couvre une grille de 112 x 91 mailles dans la zone d´elimit´ee par la Dominique et les ˆıles de Saint Kitts et N´evis. Le dernier domaine imbriqu´e, D04, couvre une grille de 130 x 112 mailles sur l’archipel de la Guadeloupe. Figure 2.10: Cartes des domaines imbriqu´es : en blanc D01 (27 km de r´esolution), en cyan D02 (9 km de r´esolution), en gris D03 (3 km de r´esolution), en jaune D04 (1 km de r´esolution), en vert D05 (333 m de r´esolution) et en rouge D06 (111 m de r´esolution). Dans le but d’´etudier, `a la micro-´echelle, les circulations nocturnes particuli`eres observ´ees `a ARN et leurs effets dans la zone la plus peupl´ee de l’archipel, deux autres domaines ont ´et´e associ´es `a notre ´etude (Fig. 2.10) : le D05 et le D06 (de r´esolutions respectives,Chapitre 2. M´ethodologie et principaux outils de simulation 48 333 m et 111 m). Le domaine D05 couvre une grille de 120 x 129 mailles sur l’ˆıle de la Basse-Terre et la cˆote ouest de la Grande-Terre. Enfin le dernier domaine imbriqu´e D06 est compos´e de 165 x 69 mailles sur la zone du Petit Cul-de-Sac Marin, incluant la zone d’Arnouville, la zone industrielle de Jarry et Pointe-`a-Pitre. Topographie La topographie des trois domaines de plus faibles r´esolutions (D01, D02 et D03) a ´et´e interpol´ee `a partir des donn´ees fournies par l’US Geological Survey 3 (USGS, 30 secondes d’arc de r´esolution). La topographie des trois autres domaines (D04, D05 et D06) a ´et´e interpol´ee depuis la carte topographique de l’Institut G´eographique National 4 (IGN) dont la r´esolution est de 50 m. L’impact de la r´esolution sur la repr´esentation du relief de la Guadeloupe est illustr´e par la comparaison de la topographie des domaines D04, D05 et D06 (Fig. 2.11). Figure 2.11: Cartes topographiques (m AMSL) interpol´ees `a partir des donn´ees IGN (50 m de r´esolution) : (a) D04 (1 km de r´esolution), (b) D05 (333 m de r´esolution), (c) D06 (111 m de r´esolution) ; avec la station num´erique VER (triangle jaune), le mˆat instrument´e ARN (triangle vert) et la centrale ´electrique EDF (croix rouge). 3. Institut d’´etudes g´eologiques des Etats-Unis, de l’anglais : United States Geological Survey ´ 4. Institut National de l’Information G´eographique et Foresti`ereChapitre 2. M´ethodologie et principaux outils de simulation 49 Occupation des sols Les circulations locales sont g´en´eralement g´en´er´ees par des contrastes thermiques de surface. Donc leur mod´elisation num´erique implique une bonne repr´esentation de la carte d’occupation des sols. Pour notre application au cas de l’archipel de la Guadeloupe, nous avons pr´ealablement utilis´e une carte d’occupation des sols tr`es bien r´ef´erenc´ee dans la bibliographie : les donn´ees globales USGS 5 (ULC24) avec 1 km de r´esolution (Anderson et al., 1976; Eidenshink and Faundeen, 1994). Cette carte d’occupation des sols, r´ealis´ee `a partir des donn´ees satellites du Radiom`etre Avanc´e `a Tr`es Haute R´esolution AVHRR (1992–1993, Eidenshink and Faundeen (1994)), a ´et´e employ´ee dans l’exp´erience M´eso-A. Dans le cadre des simulations micro-´echelles, il ´etait pr´ef´erable de disposer de donn´ees dont la r´esolution est sup´erieure ou ´egale `a la taille d’une maille du domaine D06 (111 m). De plus, dans un souci de r´ealisme, la date de la carte d’occupation des sols devait correspondre avec notre p´eriode de simulation (2007). Les donn´ees de la carte d’occupation des sols Corine Land Cover 2006 (EEA, 2007) pour les d´epartements d’outremer, bas´ee sur l’interpr´etation des images des satellites SPOT et Landsat, ont ´et´e r´ecemment mises en ligne. Ces donn´ees, qui incluent une classification en 50 classes d’occupation des sols, ont une r´esolution 1 : 100000 (un pixel de 23 m pour la Guadeloupe). Le sch´ema de canop´ee Noah-LSM (Chen and Dudhia, 2001), utilis´e dans la configuration de nos simulations WRF, est param´etr´e `a partir des 24 cat´egories USGS d’occupation du sol. Pour int´egrer la nouvelle carte d’occupation des sols, la conversion des 50 classes Corine en 24 classes USGS est n´ecessaire. Pineda et al. (2004) ont propos´e un tableau d’´equivalences entre les cat´egories Corine et les cat´egories USGS (Tab. 2.1). En nous basant sur l’analyse de Pineda et al. (2004), nous avons donc converti les 50 classes de la carte d’occupation des sols de la Guadeloupe Corine 2006 en 24 classes USGS pour obtenir la carte CLC24 6 (Fig. 2.12). Cette repr´esentation de tr`es haute r´esolution est tr`es r´ealiste (Fig. 2.12) : on y observe l’agglom´eration pointoise (au centre de l’archipel), la domination des forˆets de feuillus sur l’ˆıle de la Basse-Terre et celle des terres cultiv´ees sur la Grande-Terre. La pr´ecision de la carte nous permet aussi d’observer la zone aride du crat`ere de la Soufri`ere (Fig. 2.12). La comparaison, `a 1 km de r´esolution (domaine D04), des cartes USGS AVHRR (ULC24) (Fig. 2.13a) et Corine CLC24 (Fig. 2.13b) montre d’importants biais dans l’occupation des sols ULC24. Tout d’abord, contrairement `a la repr´esentation CLC24, la ligne de cˆote ULC24 semble avoir un d´ecalage sud-est avec la ligne de cˆote World Vector Shoreline 5. Carte d’occupation des sols USGS global land cover avec 24 cat´egories (1992) 6. Carte d’occupation des sols Corine Land Cover (2006) convertie aux 24 cat´egories d´efinies par USGSChapitre 2. M´ethodologie et principaux outils de simulation 50 Tableau 2.1: Equivalences entre les 50 classes de la Corine Land Cover 2006 DOM ´ et les 24 classes de l’USGS AVHRR 1992 (Pineda et al., 2004). Corine Description Corine USGS Description USGS Albedo Rugosit´e 1–11 Zones urbaines, industrielles 1 Zones urbaines, industrielles 0,15 1,00 12 Terres cultiv´ees non irrigu´ees 2 Terres cultiv´ees non irrigu´ees 0,19 0,07 13-14 Terres irrigu´ees en permanence, 3 Terres cultiv´ees irrigu´ees 0,15 0,07 rizi`eres 15–21 Vignobles, vergers et petits fruits, 6 Terres cultiv´ees/forˆets 0,15 0,07 oliveraies, canne `a sucre, bananeraies, palmeraies, caf´eiers 22 Prairies 2 Terres cultiv´ees non irrigu´ees 0,19 0,07 23–26 Cultures annuelles et permanentes, 6 Terres cultiv´ees/forˆets 0,15 0,07 syst`emes complexes de culture, zones agricoles et espaces naturels, territoires agro-forestiers 27 Forˆets de feuillus 11 Forˆets de feuillus 0,12 0,80 28 Forˆets de conif`eres 14 Forˆets de conif´eres 0,10 1,09 29–30 Forˆets m´elang´ees, mangroves 15 Forˆets m´elang´ees 0.12 0.80 31 Pelouses et pˆaturages naturels 7 Pelouses 0,19 0,08 32–34 Landes et broussailles, v´eg´etation 9 Arbustes et pelouses 0,23 0,05 V´eg´etation scl´erophylle, forˆet et v´eg´etation arbustive 35–38 Plages, dunes et sable, roches nues 19 Zones arides et 0,12 0,01 V´eg´etation clairsem´ee, v´eg´etation clairsem´ee zones incendi´ees 39 Glaciers et neiges ´eternelles 24 Neige et glacier 0,70 0,001 40–44 Marais int´erieurs, salines, tourbi`eres 17 v´eg´etation basse 0,12 0,04 Marais maritimes, marais salants, en zones innond´ees zones intertidales 45–50 Eaux continentales, eaux maritimes 16 Surfaces d’eau 0,19 0,001 (NOAA, 2014). De plus, la domination de l’occupation des sols de l’archipel par les savanes et les terres cultiv´ees non irrigu´ees semble irr´ealiste (Fig. 2.13a). Cette carte ne montre pas les diff´erences entre la v´eg´etation de l’ˆıle plate de la Grande-Terre et celle du relief de la Basse-Terre qui est soumis `a un r´egime pluvieux plus intense. Enfin les zones urbaines de la carte ULC24 semblent tr`es mal repr´esent´ees. Suite `a cette comparaison graphique, le choix a ´et´e fait d’effectuer de nouvelles simulations m´eso-´echelles (M´eso-A’) en int´egrant l’occupation des sols CLC24 dans le domaine D04. Les effets de la CLC24 sur les circulations locales de l’archipel (1 km de r´esolution) sont examin´es `a la section 3.1.2. La CLC24 est aussi utilis´ee dans les domaines micro-´echelles : D05 et D06. La configuration des donn´ees g´eographiques pour les six domaines de simulation estChapitre 2. M´ethodologie et principaux outils de simulation 51 Figure 2.12: Carte d’occupation des sols de l’archipel de la Guadeloupe CLC24 (23 m de r´esolution) : Corine Land Cover 2006 dont les 50 cat´egories ont ´et´e converties en 24 cat´egories USGS, avec le rectangle noir repr´esentant l’agglom´eration pointoise. Figure 2.13: Comparaison des cartes d’occupation des sols de l’archipel de la Guadeloupe `a 1 km de r´esolution (D04) avec la ligne de cˆote World Vector Shoreline (NOAA, 2014), (1) les zones urbaines, (2) les terres cultiv´ees non irrigu´ees, (6) les m´elanges de terres cultiv´ees et de forˆets, (7) les pelouses, (8) les arbustes, (9) les m´elanges d’arbustes et de pelouses, (10) les savanes, (11) les forˆets de feuillus, (13) les forˆets denses, (14) les forˆets de conif`eres, (15) les forˆets m´elang´ees mangroves incluses, (16) les surfaces d’eau, (17) les v´eg´etations basses en zones inond´ees, (18) les surfaces bois´ees en zones inond´ees, (21) la toundra bois´ee : (a) USGS ULC24 (M´eso-A), (b) Corine CLC24 (M´eso-A’). r´esum´ee dans le tableau 2.2.Chapitre 2. M´ethodologie et principaux outils de simulation 52 Tableau 2.2: Configuration des six domaines de simulation. D01 D02 D03 D04 D05 D06 R´esolution [m] 27000 9000 3000 1000 333 111 Nombre de mailles [lon. x lat.] 80 x 80 121 x 109 112 x 91 130 x 112 120 x 129 165 x 69 Superficie [km2 ] 4665600 1068309 91728 14560 1584 140 Topographie USGS 30 s IGN 50 m Occupation des sols M´eso-A ULC24 30 s ULC24 30 s CLC24 23 m Occupation des sols M´eso-A’ ULC24 30 s CLC24 23 m CLC24 23 m Sch´ema de turbulence Sch´ema de moyenne d’ensemble 1D Sch´ema LES 3D Donn´ees m´et´eorologiques globales pour l’assimilation du mod`ele WRF ARW Les donn´ees globales du syst`eme NCEP FNL (Final) Operational Global Analysis (NCEP, ment) ont ´et´e int´egr´ees toutes les 6 heures, dans le mod`ele WRF. Ces champs de donn´ees, dont la maille est de 1➦(≈ 110 km) et le pas de temps de six heures, sont en t´el´echargement libre. Les analyses NCEP FNL sont disponibles pour des dates post´erieures au 30/07/1999 18 h UTC. Les donn´ees proviennent du syst`eme d’assimilation de donn´ees mondiales (GDAS), qui recueille, en continu, les donn´ees d’observation depuis le syst`eme de t´el´ecommunications globales (GTS). Les sorties d’analyses FNL incluent des champs `a la surface et sur 26 niveaux verticaux levels entre 1000 mb et 10 mb. Les param`etres disponibles comprennent la pression de surface, la pression au niveau de la mer, la hauteur du g´eopotentiel, la temp´erature, la temp´erature de surface du sol et de la mer, l’humidit´e relative, les composantes horizontales du vent, les mouvements verticaux, la vorticit´e et la teneur en ozone. 2.3.2.2 Param´etrisations WRF ARW Caract´erisation des niveaux verticaux Les exp´eriences M´eso-A et M´eso-A’ comportent respectivement 71 et 70 niveaux verticaux m´edians (centres des mailles verticales) avec un premier niveau vertical `a une altitude de 13 m AGL (Fig. 2.14b). Le sommet du mod`ele est limit´e au niveau de pression 50 hPa dans l’exp´erience M´eso-A et `a la tropopause 100 hPa dans l’exp´erience M´eso-A’ (Fig. 2.14a). Le mod`ele fournit les variables de surface classiques avec la temp´erature `a 2 m AGL (T2) qui est calcul´ee `a partir de la temp´erature du premier niveau vertical et de celle de la surface du sol, tandis que pour le vent `a 10 m AGL, le calcul est bas´e sur la th´eorie des similitudes de Monin-Obukhov. Suivant les recommandations de Skamarock et al. (2008), la distance entre les niveauxChapitre 2. M´ethodologie et principaux outils de simulation 53 Figure 2.14: Niveaux verticaux m´edians (WRF) pour les exp´eriences M´eso-A (croix bleues) et M´eso-A’ (cercles rouges) : (a) profils lin´eaires en fonction du niveau de pression (hPa) et (b) profils logarithmiques en fonction de l’altitude (km). verticaux est inf´erieure `a 900 m (Fig. 2.14b). Dans le but d’´etudier les circulations locales induites dans la CLA par l’orographie et les contrastes thermiques de surface, nous avons d´efini dans les deux exp´eriences 43 niveaux verticaux dans les couches inf´erieures `a 3000 m AGL, en incluant 23 niveaux dans les 1000 premiers m`etres (Fig. 2.14b). Les simulations WRF-LES micro-´echelles (D05 et D06) comportent les mˆemes niveaux verticaux que ceux de l’exp´erience M´eso-A’. P´eriodes simul´ees et intervalles de temps des sorties mod`eles A m´eso- et micro-´echelle, la dur´ee des p´eriodes simul´ees est de 60 heures pour les trois ` cas, AF (du 2 d´ecembre 2007 18 h UTC au 5 d´ecembre 2007 6 h UTC), AS (du 13 d´ecembre 2007 18 h UTC au 16 d´ecembre 2007 6 h UTC) et AM (du 23 d´ecembre 2007 18 h UTC au 26 d´ecembre 2007 6 h UTC). Aussi bien en m´eso-´echelle qu’en micro-´echelle, les r´esultats des 12 premi`eres heures ne sont pas pris en compte dans notre analyse, car ils correspondent `a la p´eriode classique du temps de latence du mod`ele, appel´ee ” spin-up ” (Hu et al., 2010). Les sorties mod`eles m´eso-´echelles (D01, D02, D03 et D04) sont sauvegard´ees toutes les heures. Suivant la m´ethode de Talbot et al. (2012), les champs simul´es horaires du domaine D04 sont utilis´es par la suite comme conditions limites du domaine LES D05 via une fonction d’interpolation spline cubique, appel´ee ” NDOWN ”. Les sorties WRF-LES des domaines D05 et D06 sont sauvegard´ees toutes les 10 minutes.Chapitre 2. M´ethodologie et principaux outils de simulation 54 Param´etrisations physiques m´eso- et micro-´echelles Les sch´emas de physique utilis´es dans nos travaux `a la m´eso-´echelle et `a la micro-´echelle correspondent aux param´etrisations les plus fr´equemment employ´ees dans les ´etudes num´eriques utilisant le mod`ele WRF. Dans les domaines m´eso-´echelles (D01, D02, D03 et D04), la couche limite plan´etaire (CLP) est mod´elis´ee par le sch´ema de moyenne d’ensemble non-local-K YSU (Hong et al., 2006) associ´e `a la diffusion horizontale Smagorinsky du premier ordre. Les ´etudes comparatives des sch´emas de CLP du mod`ele WRF ont montr´e que le sch´ema YSU ´etait le plus performant en couche limite convective (Hu et al., 2010; Shin and Hong, 2011). Cependant, en condition de stabilit´e nocturne, le sch´ema YSU (versions WRF ant´erieures `a la 3.4.1 utilis´ee ici) avait tendance `a inhiber le gradient de vent vertical, ceci ´etant en parti dˆu `a un m´elange vertical excessif (Hu et al., 2013). La r´eduction du m´elange vertical nocturne dans la version 3.4.1 du code WRF ARW a permis d’am´eliorer la pr´ediction des vitesses du vent des basses couches durant la nuit (Hu et al., 2013). Le sch´ema YSU a aussi montr´e de bonnes performances dans les ´etudes de couplage micro-´echelle WRF-LES (Talbot et al., 2012; Zhu, 2008a,b). Dans les domaines micro-´echelles (D05 et D06), la couche limite plan´etaire (CLP) est r´esolue explicitement par le sch´ema LES 3D avec la fermeture 3D TKE d’ordre 1.5 (d´ecrit `a la sous-section 1.3.4). Dans les six domaines de simulation, la param´etrisation de la couche de surface est bas´ee sur la th´eorie des similitudes de Monin-Obukhov. La microphysique est mod´elis´ee par le sch´ema WRF Single-Moment 6-class WSM6 (Hong and Lim, 2006) qui est pr´ef´erable pour les simulations de haute r´esolution au sch´ema WRF Single-Moment 3-class WSM3 utilis´e par Lef`evre et al. (2010). Pour la param´etrisation du rayonnement `a ondes longues et du rayonnement `a ondes courtes, les sch´emas RRTM (Mlawer et al., 1997) et Dudhia (Dudhia, 1989) sont respectivement s´electionn´es. Les ˆıles volcaniques des Petites Antilles, comme la Martinique, la Dominique et la Guadeloupe ont une topographie complexe. Dans le but de mieux simuler les for¸cages radiatifs, les effets de pente et d’ombre ont ´et´e ajout´es pour les domaines D03, D04, D05 et D06. Le mod`ele de surface Noah Land Surface Model (Chen and Dudhia, 2001) est s´electionn´e. Il inclut le calcul de l’humidit´e et de la temp´erature dans quatre couches du sol. Dans le domaine D01, le sch´ema Kain-Fritsch (Kain, 2004) est ajout´e pour mod´eliser la convection. Dans les 5 autres domaines, le mod`ele r´esout explicitement la convection. D’apr`es Skamarock et al. (2008), les sch´emas de convection doivent ˆetre appliqu´es sur des mailles de taille sup´erieure `a 10 km.Chapitre 2. M´ethodologie et principaux outils de simulation 55 L’option de variation de la temp´erature de surface de la mer en fonction du rayonnement est activ´ee. Cette option permet de simuler le cycle diurne de la temp´erature de surface de la mer. Pas de temps de calcul Pour maximiser les pas de temps de calcul tout en maintenant le mod`ele num´eriquement stable, nous avons utilis´e une m´ethode de pas de temps adaptatif bas´ee sur les conditions de stabilit´e Courant-Friedrichs-Lewy (CFL). Trois param`etres doivent ˆetre pr´ealablement d´efinis en fonction de la r´esolution du domaine (∆x, en km). Skamarock et al. (2008) recommandent un pas de temps de d´epart de 6∆x, un pas de temps minimal de 4∆x et un pas de temps maximal de 8∆x. Le pas de temps adaptatif a ´et´e employ´e pour les simulations m´eso-´echelles (Tab. 2.3). Son utilisation pour les simulations LES entraˆınait des erreurs et des interruptions de calcul. Nous avons donc fix´e les pas de temps de calcul des domaines D05 et D06 (Tab. 2.3). Tableau 2.3: Pas de temps de calcul pour les six domaines de simulation. D01 D02 D03 D04 D05 D06 ∆x = 27 km ∆x = 9 km ∆x = 3 km ∆x = 1 km ∆x = 0.3 km ∆x = 0.1 km Pas de temps de d´epart (s) 162 54 18 6 ∅ ∅ ∆t = 6∆x Pas de temps minimal (s) 108 36 12 4 ∅ ∅ ∆t = 4∆x Pas de temps maximal (s) 216 72 24 8 ∅ ∅ ∆t = 8∆x Pas de temps constant (s) ∅ ∅ ∅ ∅ 1,2 0,4 ∆t = 4∆x Conditions initiales Les conditions initiales incluent aussi bien les conditions au sol (topographie, occupation des sols, ...) que les champs m´et´eorologiques interpol´es provenant des analyses globales du mod`ele NCEP FNL (NCEP, ment), dont la maille est de 110 km. Ces champs maill´es comportent des variables 2D au sol et des variables 3D qui seront interpol´ees sur les niveaux verticaux de la simulation.Chapitre 2. M´ethodologie et principaux outils de simulation 56 Conditions aux limites Les conditions aux limites lat´erales des six domaines de simulation sont configur´ees par une zone de sp´ecification (zone entourant le domaine d’´epaisseur ´egale `a une maille) et par la zone de relaxation (zone suivant entourant le domaine d’´epaisseur ´egale `a quatre mailles). Les valeurs des conditions sont impos´ees dans la zone de sp´ecification, puis propag´ees dans la zone de relaxation (Davies and Turner, 1977) permettant d’´eviter les instabilit´es induits par d’´eventuels gradients ´elev´es. Tableau 2.4: Conditions aux limites des simulations WRF pour les six domaines ´etudi´es. D01 D02 D03 D04 D05 D06 Sommet Vitesse verticale w nulle Surface Conditions du sol (topographie, rugosit´e, alb´edo, ...) Bords lat´eraux NCEP-FNL Sorties D01 Sorties D02 Sorties D03 Sorties D04 Sorties D05 Intervalle de temps 6 h ∆tD01 ∆tD02 ∆tD03 1 h ∆tD05 Imbrication Two-way One-way Dans le cas des simulations `a la m´eso-´echelle, les conditions aux limites lat´erales du premier domaine (D01, 27 km de maille) proviennent des champs m´et´eorologiques NCEP-FNL (NCEP, ment) interpol´es, 2D et 3D, toutes les six heures (Tab. 2.4). Pour les trois autres domaines (D02, D03 et D04), les conditions aux limites sont ´etablies par imbrication : c’est le domaine parent qui fixe les conditions lat´erales du domaine fils `a chaque pas de temps. Dans le cas des simulations `a la micro-´echelle, les conditions aux limites lat´erales du premier domaine (D05, 333 m de maille) sont ´etablies par les sorties interpol´ees, 2D et 3D, du domaine D04 (1 km de r´esolution), toutes les heures. Les conditions limites du domaine D06 sont d´efinies par les r´esultats du domaine D05. Le sommet de l’atmosph`ere, d´efini respectivement dans les simulations M´eso-A et M´esoA’, `a 50 hPa et 100 hpa, est param´etr´e par une condition de vitesse verticale nulle.Chapitre 2. M´ethodologie et principaux outils de simulation 57 2.4 Mod`ele lagrangien de dispersion de particules : FLEXPART-WRF 2.4.1 Description Le mod`ele lagrangien de dispersion de particules FLEXPART (Stohl et al., 2005) a ´et´e con¸cu initialement pour simuler, aux larges et moyennes ´echelles, la dispersion de polluants provenant de sources industrielles, tels les accidents au sein d’une centrale nucl´eaire, les incendies de plateforme industrielle, etc. FLEXPART simule le transport, la diffusion, les d´epˆots secs et humides, et la d´esint´egration radioactive des traceurs lib´er´es depuis des sources (point, ligne, surface ou volume). La dynamique de ce code permet des simulations directes (la dispersion des traceurs depuis leur source), ou indirectes (d´etermination des sources potentielles pour des r´ecepteurs connus). Ce mod`ele utilise les donn´ees m´et´eorologiques mondiales comme les pr´edictions du mod`ele Global Forecast System (GFS, Han and Pan (2011); Yang et al. (2006)) fournies avec une r´esolution sup´erieure ou ´egale `a 0,5➦. Dans le cas des moyennes et petites ´echelles, c’est le mod`ele coupl´e FLEXPART-WRF qui a ´et´e d´evelopp´e pour mod´eliser la dispersion de particules (Brioude et al., 2013). Tout comme FLEXPART, le code FLEXPART-WRF ´ecrit en Fortran 95 est en libre t´el´echargement sous la licence GNU General Public Licence (GPL). 2.4.1.1 Int´egration des donn´ees m´et´eorologiques WRF Le transport des polluants dans le code num´erique FLEXPART-WRF est forc´e par des champs de variables m´et´eorologiques WRF (Tab. 2.5). Les sorties du mod`ele WRF sont maill´ees sur une grille Arakawa C-grid avec des niveaux verticaux η suivant la topographie. Les composantes du vent horizontal et vertical sont d´efinies sur grille d´ecal´ee. Dans le mod`ele FLEXPART-WRF, les vents sont interpol´es sur le centre des mailles, de telle sorte que toutes les donn´ees m´et´eorologiques soient sur la mˆeme grille. Les donn´ees WRF 3-D sont interpol´ees dans FLEXPART-WRF, sur des niveaux cart´esiens suivant la topographie.Chapitre 2. M´ethodologie et principaux outils de simulation 58 Tableau 2.5: Variables des sorties WRF requises et optionnelles pour le for¸cage du mod`ele FLEXPART-WRF (Brioude et al., 2013). Variable WRF Dimension Description ZNW 1D Valeur Eta des niveaux verticaux Eta ZNU 1D Valeur Eta `a la moiti´e des niveaux verticaux PB 3D Valeur de la pression `a l’´etat de r´ef´erence en Pa P 3D Perturbation sur la pression en Pa PHB 3D Valeur du g´eopotentiel `a l’´etat de r´ef´erence en m2 .s-2 PH 3D Perturbation sur le g´eopotentiel en m2 .s-2 T 3D Perturbation de temp´erature potentielle en K QVAP 3D Rapport de m´elange de vapeur d’eau en kg.kg-1 TKE 3D Energie cin´etique turbulente en m ´ 2 .s-2 (optionnel) XLAT 2D Latitude en degr´e nord XLONG 2D Longitude en degr´e est MAPPAC M 2D Facteur d’´echelle de la carte PSFC 2D Pression `a la surface en Pa U10 2D Vitesse du vent horizontal `a 10 m suivant l’axe x V10 2D Vitesse du vent horizontal `a 10 m suivant l’axe y T2 2D Temp´erature `a 2 m en K Q2 2D Humidit´e sp´ecifique `a 2 m en kg.kg-1 SW 2D Rayonnement solaire incident en W.m-2 (optionnel) RAINNC 2D Pr´ecipitation r´esolue explicitement en mm (optionnel) RAINC 2D Pr´ecipitation convective en mm (optionnel) HFX 2D Flux de chaleur sensible `a la surface en W.m-2 (optionnel) UST 2D Vitesse de friction en m.s-1 (optionnel) HCLA 2D Hauteur de la couche limite atmosph´erique en m (optionnel) Type 1 des variables de vent int´egr´ees U 3D Vitesse du vent horizontal suivant l’axe x en m.s-1 V 3D Vitesse du vent horizontal suivant l’axe y en m.s-1 W 3D Vitesse du vent suivant l’axe z en m.s-1 Type 2 des variables de vent int´egr´ees AVGFLX RUM 3D Vitesse du vent horizontal suivant l’axe x, pond´er´ee sur la masse et moyenn´ee sur l’intervalle de temps, en Pa.m.s-1 AVGFLX RVM 3D Vitesse du vent horizontal suivant l’axe y, pond´er´ee sur la masse et moyenn´ee sur l’intervalle de temps, en Pa.m.s-1 AVGFLX WWM 3D Mouvement vertical, pond´er´e sur la masse et moyenn´e sur l’intervalle de temps, en Pa.m.s-1 MU 2D Perturbation de la masse d’air dans la colonne en Pa MUB 2D Masse d’air de r´ef´erence dans la colonne en Pa Type 3 des variables de vent int´egr´ees U 3D Vitesse du vent horizontal suivant l’axe x en m.s-1 V 3D Vitesse du vent horizontal suivant l’axe y en m.s-1 WW 3D Mouvement vertical de la masse d’air en Pa.s-1 2.4.1.2 Param´etrisation de la couche limite atmosph´erique et de la turbulence Par d´efaut, deux param`etres de couche limite WRF sont utilis´es : la vitesse de friction et le flux de chaleur sensible. Stohl et al. (2005) ont indiqu´e que ces param`etres peuvent ˆetre calcul´es dans FLEXPART en appliquant la m´ethode du profil (Berkowicz and Prahm, 1982) au vent (10 m et second niveau vertical) et `a la temp´erature (2 m et second niveau vertical). Une option (SFC OPTION) permet d’int´egrer la hauteur de la couche limite simul´ee par WRF ou d’effectuer son calcul dans FLEXPART par la m´ethode de la valeur critique du nombre de Richardson (Stohl et al., 2005; Vogelezang and Holtslag, 1996). Dans ce cas, la HCLA est atteinte pour le premier niveau vertical pour lequel le nombre de Richardson d´epasse la valeur critique de 0,25.Chapitre 2. M´ethodologie et principaux outils de simulation 59 Quatre options sont disponibles pour la param´etrisation du vent turbulent dans la couche limite (Brioude et al., 2013) : 1. Le traitement de la turbulence est d´esactiv´e. 2. Le m´elange turbulent de la couche limite est trait´e par le sch´ema de turbulence Hanna (Hanna, 1982). Ce sch´ema est bas´e sur les param`etres suivants : la hauteur de couche limite (HCLA), la longueur de Monin-Obukhov, l’´echelle de la vitesse de convection, la longueur de rugosit´e et la vitesse de friction. En fonction du r´egime de la couche limite, instable, stable ou neutre, diff´erents profils turbulents sont utilis´es. Le sch´ema de turbulence Hanna peut ˆetre associ´e `a une param´etrisation de couche limite convective. Dans ce cas la turbulence gaussienne est remplac´ee par la formulation de Luhar et al. (1996). 3. Les composantes du vent turbulent sont calcul´ees `a partir de l’´energie cin´etique turbulente (TKE) fournie par WRF. La TKE est r´epartie entre les composantes horizontales et verticales suivant la couche de surface et la stabilit´e locale param´etr´ee par le sch´ema de turbulence Hanna. 4. La TKE des sorties WRF est utilis´ee. La TKE est r´epartie d’apr`es l’´equilibre entre l’´energie turbulente de production et celle de dissipation. Au-dessus de la CLP, la turbulence est bas´ee sur une diffusivit´e verticale constante de 0,1 m2 .s-1 dans la stratosph`ere et une diffusivit´e horizontale de 50 m2 .s-1 dans la troposph`ere libre (Stohl et al., 2005). La stratosph`ere et la troposph`ere sont diff´erenci´ees par une valeur seuil de 2 pvu (potential vorticity units). 2.4.1.3 Calcul de la trajectoire des particules Comme d´ecrit par Stohl et al. (2005), FLEXPART utilise un sch´ema du type ” acc´el´eration nulle ”. L’´equation de la trajectoire (Stohl et al., 1998) est une ´equation diff´erentielle du premier ordre, dX dt = v[X(t)] (2.12) qui est int´egr´ee `a l’aide d’un sch´ema d’int´egration num´erique du premier ordre de type Euler : X(t + ∆t) = X(t) + v(X, t)∆t, (2.13) o`u t est le temps, ∆t l’incr´ement de temps, X le vecteur position et v = ¯v + vt + vm, le vecteur du vent incluant le vent de la maille ¯v, les fluctuations du vent turbulent vt et les fluctuations du vent `a la m´eso-´echelle vm.Chapitre 2. M´ethodologie et principaux outils de simulation 60 Le transport des particules est calcul´e `a partir des donn´ees m´et´eorologiques (principalement les vents) interpol´ees `a la position de la particule (Stohl et al., 2005) tandis que la dispersion turbulente est bas´ee sur la r´esolution des ´equations de Langevin. 2.4.2 Configurations de nos simulations L’objectif principal des simulations WRF-LES-FLEXPART est d’analyser les effets des circulations locales sur la dispersion d’un panache de polluants industriels dans la zone la plus peupl´ee de l’archipel pour trois cas r´eels de situation m´et´eorologique (AS, AM et AF). Nous nous sommes int´eress´es `a la source industrielle la plus polluante de l’ˆıle : la centrale diesel EDF de Jarry nord, situ´ee dans le Petit Cul-de-Sac Marin (Fig. 1.5, 1.7, 1.8, 1.9). D’apr`es le Registre fran¸cais des Emissions polluantes ´ , la centrale EDF Jarry nord ´emet chaque ann´ee, 10 kilotonnes d’oxydes d’azote en ´equivalent NO2 (NOx = NO + NO2). Seules les ´emissions de NOx sont r´epertori´ees dans ce registre, le rapport du m´elange NO– NO2 n’est pas disponible. Nous avons donc analys´e les concentrations d’oxyde d’azote NOx produites par la combustion du diesel dans la centrale, durant les trois types de temps (AS, AM et AF). La couleur brune, caract´eristique du NO2, nous permet d’´evaluer visuellement la structure du panache depuis des photos d’observation (Fig. 1.7, 1.9). Les simulations de la dispersion du NOx ´emis depuis les chemin´ees de la centrale sont effectu´ees dans le domaine LES D06 (Fig. 2.10, 2.11) `a l’aide de FLEXPART. 2.4.2.1 P´eriodes de simulation et intervalles de temps des sorties mod`eles Les dur´ees des p´eriodes simul´ees sont de 24 heures pour les trois cas : AF (du 3 d´ecembre 2007 16 h UTC au 4 d´ecembre 2007 16 h UTC), AS (du 14 d´ecembre 2007 16 h UTC au 15 d´ecembre 2007 16 h UTC) et AM (du 24 d´ecembre 2007 16 h UTC au 25 d´ecembre 2007 16 h UTC). Les sorties WRF-LES du domaine D06 sont utilis´ees pour forcer toutes les 10 minutes le mod`ele FLEXPART. Les sorties de concentration de NOx sont moyenn´ees sur 10 minutes et sauvegard´ees toutes les 10 minutes. Nous avons choisi d’employer le mˆeme intervalle de temps pour l’int´egration dans FLEXPART des sorties WRF-LES et pour les sauvegardes des concentrations WRF-LES-FLEXPART, pour limiter toute mod´elisation suppl´ementaire des champs m´et´eorologiques par FLEXPART et les ´eventuels biais associ´es.Chapitre 2. M´ethodologie et principaux outils de simulation 61 2.4.2.2 Caract´erisation des niveaux verticaux Pour simuler les effets des circulations locales sur la dispersion du panache de NOx, 38 niveaux verticaux, allant de 10 `a 3000 m AGL ont ´et´e employ´es (Fig. 2.15). Tout comme dans le mod`ele WRF, les niveaux verticaux FLEXPART suivent les variations de la topographie. Figure 2.15: Profil vertical des 38 niveaux verticaux FLEXPART-WRF. 2.4.2.3 Param´etrisation du panache de NOx de la centrale EDF D’apr`es le site internet du Registre fran¸cais des Emissions polluantes ´ , la centrale EDF Jarry nord a ´emis en 2007 9,790 kilotonnes d’oxydes d’azote en ´equivalent NO2. En partant de ce chiffre, la masse totale de NOx ´emise par la centrale durant les simulations de 24 heures est de 26,820 tonnes. Le nombre total de particules simul´ees durant les 24 heures, est ´etabli `a 100000 avec un taux d’´emission constant (toutes les 10 minutes). Les dimensions de la colonne d’´ejection des particules, sont d´etermin´ees en fonction des coordonn´ees g´eographiques des chemin´ees de la centrale, de leur hauteur et des observations de l’extension verticale du panache en couche limite atmosph´erique neutre. La distance entre les deux chemin´ees est inf´erieure `a la taille de la maille du domaine D06 (111 m). Nous consid´erons donc, une unique colonne d’´ejection pour les deux chemin´ees sur la grille du domaine. La colonne d’´ejection s’´etend horizontalement sur un rectangle d´elimit´e par le coin inf´erieur gauche (16.23518➦N, 61.5543➦W) et le coin sup´erieur droit (16.23559➦N, 61.5537➦W). La colonne d’´ejection s’´etend verticalement depuis la hauteur des chemin´ees (≈ 60 m AGL) jusqu’`a la hauteur du panache observ´ee en couche limite neutre (≈ 600 m AGL).Chapitre 2. M´ethodologie et principaux outils de simulation 62 2.4.2.4 Param´etrisations physiques Brioude et al. (2012) ont montr´e que l’utilisation des champs de vitesse verticale instantan´ee WRF, entrainait des biais dans les zones de topographie complexe. Pour pr´evenir ces incertitudes, les simulations ont ´et´e effectu´ees en int´egrant les champs de vitesses moyenn´ees WRF : les composantes horizontales et verticales de la vitesse sont pond´er´ees sur la masse et moyenn´ees sur l’intervalle de temps. Dans notre cas, ces champs de vitesses sont moyenn´ees sur 10 minutes. D’apr`es Brioude et al. (2013), les champs de vitesses moyenn´ees WRF permettent de r´eduire les incertitudes sur la mod´elisation de la trajectoire des particules dans FLEXPART. Les sorties num´eriques WRF-LES n’incluent pas la hauteur de la couche limite atmosph´erique (HCLA), FLEXPART d´etermine ce param`etre en se basant sur la valeur critique du nombre de Richardson. Nous avons utilis´e les deux param´etrisations de turbulence qui permettent l’int´egration des champs de TKE produits par WRF-LES (description dans la partie 2.4.1.2). Durant nos simulations, l’activation de la param´etrisation de la turbulence bas´ee sur l’´equilibre entre la production et la dissipation de la TKE, a entrain´e des instabilit´es num´eriques g´en´erant des valeurs invalides. Donc nous avons finalement opt´e pour l’utilisation d’une seule param´etrisation : la r´epartition de la TKE WRF-LES suivant des coefficients de stabilit´e du sch´ema Hanna (Hanna, 1982). 2.5 Donn´ees m´et´eorologiques d’observation pour l’´evaluation du mod`ele WRF ARW3 2.5.1 Radiosondages journaliers (Universit´e du Wyoming) Pour ´evaluer nos premi`eres simulations nous avons jug´e utile d’effectuer des comparaisons des param`etres sur toute la troposph`ere `a l’aide des donn´ees fournies par les radiosondages. Cependant un seul radiosondage est disponible une fois par jour pour la zone de la Guadeloupe (station RZT de l’a´eroport du Raizet), soit pour les trois simulations de 48 heures, seulement six profils observ´es. Pour avoir des points de comparaison suppl´ementaires, d’autres stations de radiosondage (12 h UTC) ont ´et´e utilis´ees : BAR (ID 78954, Barbade) et SXM (ID 78866, Saint-Martin) qui sont localis´ees dans le domaine D02, TRI (ID 78970, Trinidad), PTR (ID 78526, Porto-Rico), et SDM (ID 78486, R´epublique Dominicaine) qui sont localis´ees dans le domaine D01 (Fig. 2.16).Chapitre 2. M´ethodologie et principaux outils de simulation 63 Il faut noter que les radiosondages ont approximativement la moiti´e du nombre des niveaux verticaux simul´es par WRF. Pour calculer les estimateurs d’erreur pr´esent´es dans la section 2.7, les radiosondages observ´es et les profils verticaux mod´elis´es sont interpol´es (avec une m´ethode spline cubique) aux mˆemes niveaux de pression (1000, 950, 925, 900, 850, 800, 700, 650, 600, 500, 400, 300, 250, 200, 150, et 100 hPa). Le mod`ele int`egre les profils d’observation via les analyses NCEP FNL `a 12 h UTC. Pour estimer la capacit´e du mod`ele WRF `a pr´edire la stratification, les profils verticaux WRF `a 11 h UTC sont ´evalu´es. Les r´esultats des 35 comparaisons (TRI a un radiosondage manquant) `a chaque niveau, entre les profils interpol´es observ´es et simul´es sont pr´esent´es dans la section 3.1.1 du rapport. Figure 2.16: G´eolocalisation des radiosondages (TRI, BAR, RZT, SXM, PTR, et SDM : carr´es rouges), des bou´ees du r´eseau NDBC-NOAA (ATL, CAR, POR, et BAH : cercles bleus) au sein des quatre premiers domaines (D01, D02, D03, D04) employ´es dans les simulations WRF m´eso-´echelles, de r´esolutions respectives de 27, 9, 3 et 1 km. 2.5.2 Bou´ees m´et´eorologiques du National Data Buoy Center Les donn´ees d’observation de la surface de la mer sont extraites de quatre bou´ees du National Data Buoy Center (http://www.ndbc.noaa.gov/) : la bou´ee POR (ID 41043, 21,061➦N, 64,966➦W, au nord de Porto-Rico) localis´ee dans le domaine 2, la bou´ee BAH (ID 41046, 23,838➦N, 68,333➦W, au large des Bahamas), la bou´ee CAR (ID 42059, 15,058➦N, 67,528➦W, en mer des Cara¨ıbes) et la bou´ee ATL (ID 41040, 14,516➦N, 53,024➦W, dansChapitre 2. M´ethodologie et principaux outils de simulation 64 l’oc´ean Atlantique), qui sont localis´ees dans le domaine 1 (Fig. 2.16). Les donn´ees d’observation horaires ´etudi´ees sont les moyennes 10 min des variables suivantes : la temp´erature de la surface de la mer, la temp´erature de l’air `a 4 m au-dessus du niveau de la mer (AMSL), la vitesse et la direction du vent `a 5 m AMSL. Les quatre bou´ees ont une pr´ecision de 1➦C pour la temp´erature de surface de la mer, 1➦C pour la temp´erature de l’air, 1 m.s-1 pour la vitesse du vent et 10➦ pour la direction du vent. Les variables des sorties WRF sont extraites au point de maille le plus proche de chaque bou´ee. Les observations, temp´erature de surface de la mer, temp´erature de l’air `a 4 m AMSL, et vitesse et direction du vent `a 5 m AMSL, sont respectivement compar´ees avec les variables WRF, ”skin temperature”, temp´erature de l’air `a 2 m AMSL et vitesse et direction du vent `a 10 m AMSL. L’´evaluation des champs de surface marins WRF est pr´esent´ee `a la section 3.1.1 du rapport. 2.5.3 Stations m´et´eorologiques de l’archipel de la Guadeloupe (M´et´eo France et LaRGE) Les donn´ees d’observation `a la surface terrestre sont extraites des cinq stations m´et´eorologiques de l’archipel de la Guadeloupe (domaine 4), en fonctionnement durant la p´eriode ´etudi´ee (d´ecembre 2007). RZT, DES, MOU, et GBD sont des stations du r´eseau M´et´eoFigure 2.17: Carte topographique (IGN, 50 m de r´esolution), avec le mˆat instrument´e du laboratoire LaRGE (ARN, triangle vert) et les 4 stations M´et´eo-France, Raizet (RZT, disque rouge), Moule (MOU, ´etoile magenta), D´esirade (DES, carr´e bleu), Grand-Bourg de Marie-Galante (GBD, losange noir).Chapitre 2. M´ethodologie et principaux outils de simulation 65 France, localis´ees respectivement, au Raizet, `a la D´esirade, au Moule et `a Grand-Bourg (Fig. 2.17). Les donn´ees horaires utilis´ees sont les moyennes 10 min des variables suivantes : la temp´erature de l’air `a 2 m AGL, la vitesse et la direction du vent `a 10 m AGL. Ces quatre stations M´et´eo-France ont une pr´ecision de 0,1➦C pour la temp´erature, 1 m.s-1 pour la vitesse du vent, et 10➦ pour la direction du vent. D’Alexis (2011) a men´e une campagne exp´erimentale de terrain pour analyser les ph´enom`enes de micro-´echelle dans la couche de surface de mangrove. Entre avril 2007 et juin 2008, la station m´et´eorologique du Laboratoire de Recherche en Energie et G´eosciences ´ (LaRGE) a enregistr´e des mesures `a 1 Hz et `a 20 Hz. Ce mˆat instrument´e ARN, localis´e dans la zone cˆoti`ere d’Arnouville de Petit-Bourg (Fig. 2.17) est muni d’un capteur barom´etrique PTB101B (Fig. 2.18a), d’une centrale d’acquisition Campbell CR3000 (Fig. 2.18b), d’un capteur HR capacitif (HMP45C) pour l’humidit´e et la temp´erature `a 2 m AGL (Fig. 2.18c), d’un an´emom`etre `a coupelles `a 2 m AGL (Fig. 2.18d), d’une girouette `a 2 m AGL (Fig. 2.18e), d’un an´emom`etre sonique 3D (CSAT3) pour le calcul des flux turbulents `a 5 m AGL (Fig. 2.18f) et d’un an´emom`etre sonique 2D (WindSonic) pour le vent horizontal `a 10 m AGL (Fig. 2.18g). La station ARN a une pr´ecision de 0,2➦C pour la temp´erature, 2% (avec une r´esolution de 0,01 m.s-1) pour la vitesse du vent, et 3➦ pour la direction du vent. En plus de ces variables classiques, la station ARN, avec ses mesures `a 20 Hz nous permettra d’´evaluer les simulations de flux turbulents comme le flux de chaleur sensible (HFX) et l’´energie cin´etique turbulente (TKE). Les champs de surface WRF-LES (10 minutes) seront ´evalu´es avec les donn´ees mesur´ees par ARN.Chapitre 2. M´ethodologie et principaux outils de simulation 66 Figure 2.18: Description du mˆat instrument´e du laboratoire LaRGE `a ARN (sch´ema extrait de D’Alexis (2011)), avec, (a) le capteur barom´etrique PTB101B, (b) la centrale d’acquisition Campbell CR3000, (c) le capteur HR capacitif (HMP45C) pour l’humidit´e et la temp´erature (2 m AGL), (d) l’an´emom`etre `a coupelles (2 m AGL), (e) la girouette (2 m AGL), (f ) l’an´emom`etre sonique 3D (CSAT3) pour le calcul des flux turbulents (5 m AGL) et (g) l’an´emom`etre sonique 2D (WindSonic) pour le vent horizontal (10 m AGL). 2.6 Donn´ees d’observation de la qualit´e de l’air pour l’´evaluation du mod`ele FLEXPART-WRF Nous avons utilis´e les donn´ees d’observation de concentration en NOx enregistr´ees par la station du r´eseau Gwad’air (association agr´e´ee de surveillance de la qualit´e de l’air, AASQA) situ´ee `a Pointe-`a-Pitre (PAP) donc dans l’agglom´eration pointoise (Fig. 2.19). Cette agglom´eration compos´ee de quatre communes (Pointe-`a-Pitre, Baie-Mahault, Les Abymes et Le Gosier) inclut la zone industrielle la plus importante de l’archipel (zone deChapitre 2. M´ethodologie et principaux outils de simulation 67 Jarry, not´ee EDF sur la Fig. 2.19). L’agglom´eration pointoise est la zone la plus peupl´ee de l’archipel : 133000 habitants pour une superficie de 175 km2 (Plocoste, 2013). Figure 2.19: Carte de localisation de la station Gwad’air PAP (losange violet) et de la centrale ´electrique EDF (croix rouge) : (a) Topographie (en m AMSL) du domaine D05 (maille de 333 m) avec l’agglom´eration pointoise (contour violet), (b) image satellite Google earth de la zone d’´etude (4/8/2013). Plocoste (2013) a d´ecrit les ´equipements de mesure de cette station : un analyseur d’oxyde d’azote NOX 2000 G, un analyseur de poussi`eres TEOM 1400A, un analyseur d’ozone OZ 2000 G et un calibrateur SONIMIX 3022-2000TM et un analyseur de dioxyde de soufre SF 2000 G. 2.7 Estimateurs d’erreur utilis´es pour l’´evaluation statistique des simulations C´ec´e et al. (2014) ont d´ecrit les estimateurs d’erreur (MBE, RMSE, MAE, IOA and IOA2) qui ont ´et´e employ´es pour l’´evaluation statistique des simulations. Les outils d’´evaluation statistique les plus utilis´es dans les ´etudes de mod´elisation m´et´eorologiques, ont ´et´e d´evelopp´es par Willmott (1981); Willmott and Matsuura (2005). Les erreurs individuelles de pr´ediction du mod`ele sont d´efinies comme ei = Pi − Oi (i = 1, 2, ..., n), o`u Pi et Oi sont respectivement les pr´edictions mod`eles et les observations in situ. L’erreur du biais moyen est d´efinie comme MBE = n −1 Pn i=1 ei = P¯ − O¯. L’erreur moyenne absolue est d´efinie par MAE = n −1 Pn i=1 |ei |. L’erreur quadratique moyenne est bas´ee sur la somme du carr´e des erreurs : RMSE =  n −1 Pn i=1 |ei | 2 1/2 . Willmott (1981) aChapitre 2. M´ethodologie et principaux outils de simulation 68 d´efini un indice de performance des mod`eles (IOA) comme IOA = 1 − Pn i=1 |ei | 2 Pn i=1 [|Pi − O¯| + |Oi − O¯|] 2 (2.14) avec une valeur comprise entre 0 et 1. Les valeurs sup´erieures `a 0,5 sont consid´er´ees comme bonnes. Willmott et al. (2011) ont reformul´e un indice de performance dont la valeur suit les variations de croissance ou d´ecroissance de la MAE. L’intervalle de valeur est [-1,1]. Ils ont exprim´e ce nouvel indice comme IOA2 =    1 − Pn i=1 |ei| 2 Pn i=1 |Oi−O¯| , quand Pn i=1 |ei | ≤ 2 Pn i=1 |Oi − O¯| 2 Pn i=1 |Oi−O¯| Pn i=1 |ei| − 1, quand Pn i=1 |ei | > 2 Pn i=1 |Oi − O¯| (2.15) . D’apr`es l’´equation (2.15), une valeur de IOA2 ´egale `a 0,5 indique que la somme des erreurs repr´esente la moiti´e de la somme des variations du mod`ele parfait plus celles ajout´ees des observations. A l’oppos´e, une valeur de IOA2 ´egale `a -0,5 signifie que la somme des ` erreurs repr´esente le double de la somme des variations du mod`ele parfait plus celles des observations. La RMSE et l’IOA sont les outils les plus utilis´es dans la lit´erature pour exprimer les diff´erences entre les pr´evisions et les donn´ees observ´ees. Cependant, comme ´ecrit par Willmott and Matsuura (2005), du fait qu’ils sont caract´eris´es par la somme du carr´e des erreurs, les erreurs importantes ont relativement plus d’influence sur l’erreur totale, que les plus faibles (contrairement `a la MAE). Nos simulations num´eriques de courte dur´ee, avec peu de points spatiaux de comparaison (nombre faible de stations m´et´eorologiques dans la zone d’´etude) seraient d’autant plus affect´ees par ce probl`eme. Pour le r´esoudre, suivant la recommandation de Willmott and Matsuura (2005); Willmott et al. (2011), la MAE and l’IOA2 sont choisis `a la place de la RMSE et du IOA. Les valeurs suivantes de IOA2 : n´egative, comprise entre 0 et 0,5, et sup´erieure `a 0,5, sont respectivement consid´er´ees comme mauvaises, bonnes et tr`es bonnes.Chapitre 3 R´esultats des simulations et discussion 3.1 Simulations num´eriques m´eso-´echelles des circulations g´en´er´ees par l’archipel de la Guadeloupe (WRF) Dans cette partie, nous pr´esentons les r´esultats des simulations num´eriques m´eso-´echelles incluant les quatre domaines : D01, D02, D03 et D04 (Fig. 2.10). Deux configurations du domaine D04 sont analys´ees : la configuration M´eso-A (carte d’occupation des sols USGS 1992, ULC) et la configuration M´eso-A’ (carte d’occupation des sols Corine 2006, CLC24). 3.1.1 Simulation M´eso-A : r´esum´e et article publi´e Les r´esultats des simulations num´eriques m´eso-´echelles (M´eso-A) ont ´et´e publi´es dans la revue scientifique ” Monthly Weather Review ”. Le mod`ele Weather Research and Forecast (WRF) est utilis´e pour simuler une descente d’´echelle dynamique `a l’aide des quatre domaines imbriqu´es (D01, D02, D03, D04), de r´esolutions respectives : 27, 9, 3, 1 km. Les trois situations m´et´eoroloqiques, correspondant aux aliz´es faibles, moyens et soutenus, sont simul´ees : AF, AM et AS (respectivement li´es aux valeurs du nombre de Froude local 69Chapitre 3. R´esultats des simulations et discussion 70 de 0,21, 0,41 et 0,82). Pour les trois types de temps, les variables m´et´eorologiques classiques pr´esentent une bonne ad´equation avec les donn´ees d’observations, sur plusieurs sites. C’est aussi le cas des champs simul´es `a 1 km sur l’archipel de la Guadeloupe, malgr´e l’utilisation dans le mod`ele WRF de la carte d’occupation des sols ULC24 dont les biais ont ´et´e d´ecrits dans le chapitre 2 du rapport. Les r´esultats de la simulation M´eso-A ont permis de compl´eter la cartographie des r´egimes m´et´eorologiques locaux observ´es par Br´evignon (2003). Ces descriptions peu pr´ecises n’incluaient pas des donn´ees maill´ees de vent, de temp´erature de surface, de couverture nuageuse et de flux de chaleur sensible sur l’ensemble de l’archipel. Les r´egimes attendus du vent local (au vent, continental insulaire, sous le vent) et la pr´edominance des effets thermiques et orographiques (respectivement au-dessus de la Grande-Terre et de la Basse-Terre) sont retrouv´es dans les sorties simul´ees. Dans le cas des AS, la convection est inhib´ee et les circulations locales sont g´en´er´ees par l’orographie. Durant les AM, dans les zones de faibles topographies, les circulations locales sont gouvern´es par le contraste thermique de surface qui induit, durant la journ´ee, une convergence des vents marins vers la terre et, durant la nuit, une divergence des vents de la terre vers la mer. Dans le cas des AF, le mod`ele simule correctement un vent catabatique nocturne induisant un ´ecoulement d’ouest observ´e exp´erimentalement par D’Alexis (2011); D’Alexis et al. (2011) sur la cˆote au vent de la Basse-Terre. Durant la nuit, cette circulation s’opposant aux aliz´es semble s’´etendre en mer (dans le Petit Cul-de-Sac Marin), puis sur la zone industrielle de Jarry et enfin sur la cˆote ouest de la Grande-Terre. Cet ´ecoulement a une vitesse de vent maximale de 4.7 m s-1 . Les r´esultats de l’exp´erience M´eso-A sugg`erent que cet ´ecoulement particulier, apparaissant dans l’agglom´eration pointoise et la zone industrielle de Jarry, pourrait g´en´erer une d´egradation de la qualit´e de l’air, li´ee aux sources industrielles de polluants (comme la centrale diesel de production d’´electricit´e).Numerical Simulations of Island-Induced Circulations and Windward Katabatic Flow over the Guadeloupe Archipelago RAPHAE¨ L CE´ CE´ , DIDIER BERNARD, AND CHRISTOPHE D’ALEXIS Department of Physics, University of the French West Indies and French Guiana, Pointe-a-Pitre, Guadeloupe
JEAN-FRANC¸ OIS DORVILLE Department of Physics, University of West Indies, Kingston, Jamaica (Manuscript received 8 April 2013, in final form 18 September 2013) ABSTRACT This article deals with the first high-resolution numerical modeling of the weather over the small and high islands of the Guadeloupe archipelago. Its main goal is to analyze the mechanisms that drive local-scale airflow circulations over this archipelago, using the 1-km Weather Research and Forecasting Model (WRF). Three meteorological situations corresponding to weak trade winds (WTW), medium trade winds (MTW), and strong trade winds (STW) have been selected and are linked with local Froude number values of 0.21, 0.41, and 0.82, respectively. For these three weather types, simulated typical meteorological variables present a good agreement with observational data at several locations. The 48-h simulations allow the completion of the previous coarse observational descriptions that did not include a map of the wind, skin temperature, cloud cover, and sensible heat flux for the whole archipelago. The expected local wind regime areas (windward, inland, and leeward) are retrieved in the model outputs, including the predominance of thermal and orographic effects over Grande-Terre Island and Basse-Terre Island, respectively. Under STW, the convection is inhibited and the local circulations are driven by the orography. In the case of WTW, the model simulates well a katabatic wind, inducing cold nocturnal reversed flow on the windward coast of Basse-Terre. This circulation, opposing the trade winds, extends to the sea and Grande-Terre Island. This flow has a maximum wind speed of 4.7 m s21 . This particular flow occurring in the most densely populated area produces an important nocturnal pollution period due to industrial sources (the diesel power plants of the archipelago). 1. Introduction Many authors have shown that strong radiative and high topography forcings may induce local circulations over tropical islands. Mechanical effects of islands on the steady trade winds is characterized by the local Froude number Frm which is defined by (U/Nhm), where U is the wind speed, hm is the height of the mountain, and N is the buoyancy frequency. The literature dealing with this subject is generally concerned with one of three types of island: large (i.e., Frm $ 1, width .50 km), high (i.e., Frm , 1), or small (i.e., Frm $ 1, width #50 km). Effects of large islands on synoptic winds have been examined for the Tiwi Islands (Oliphant et al. 2001) and Puerto Rico (Malkus 1955; Jury et al. 2009). Oliphant et al. (2001) showed that with a flat area of 8000 km2 , the Tiwi Islands generate their own thermal airflow regime associated with sea/land-breeze systems. The Weather Research and Forecasting Model (WRF) simulation over Puerto Rico (Jury et al. 2009), indicated how diurnal heating and orography act on the convective boundary layer structure and trade wind airstream. In general, high islands like the Hawaiian Islands (Smith and Grubiac 1993; Reisner and Smolarkiewicz 1994; Feng and Chen 1998; Yang and Chen 2005; Carlis et al. 2010; Nguyen et al. 2010), New Caledonia (Lef
evre et al. 2010), Reunion Island (Lesoue¨f et al. 2011), or Lesser Antilles islands like St. Vincent (Smith et al. 1997) and Dominica (Smith et al. 2012) would have mainly mechanical effects on the impinging airflow with in some cases thermal circulations occurring on the lee side. During the Dominica Experiment field campaign (DOMEX), Smith et al. (2012) observed that two types Corresponding author address: Raphae¨l Cece, Faculty of Sciences, Department of Physics, University of the French West Indies and French Guiana, Fouillole campus, Pointe-
a-Pitre 97110, Guadeloupe. E-mail: raphael.cece@univ-ag.fr 850 MONTHLY WEATHER REVIEW VOLUME 142 DOI: 10.1175/MWR-D-13-00119.1
2014 American Meteorological Society 71 Influence du mapping sur la reconnaissance d’un syst`eme de communication Marion Bellard To cite this version: Marion Bellard. Influence du mapping sur la reconnaissance d’un syst`eme de communication. Information Theory. Universit´e Pierre et Marie Curie, 2014. French. . HAL Id: tel-00959782 https://tel.archives-ouvertes.fr/tel-00959782v2 Submitted on 17 Mar 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THÈSE DE DOCTORAT DE l’UNIVERSITÉ PIERRE ET MARIE CURIE Spécialité Informatique École doctorale Informatique, Télécommunications et Électronique (Paris) Présentée par Marion Bellard Pour obtenir le grade de DOCTEUR de l’UNIVERSITÉ PIERRE ET MARIE CURIE Sujet de la thèse : Influence du mapping sur la reconnaissance d’un système de communication soutenue le 30 janvier 2014 devant le jury composé de : Thierry Berger Université de Limoges Rapporteur Pierre Loidreau DGA-MI Rapporteur Gilles Burel Université de Bretagne Occidentale Examinateur Jean-Pierre Tillich INRIA Paris-Rocquencourt Examinateur Annick Valibouze Université Pierre et Marie Curie Examinateur Nicolas Sendrier INRIA Paris-Rocquencourt Directeur de thèseMarion Bellard Influence du mapping sur la reconnaissance d’un système de communication INRIA-équipe-projet SECRET Domaine de Voluceau 78153 Le ChesnayRemerciements Je tiens à remercier ici toutes les personnes qui m’ont permis d’effectuer cette thèse dans d’excellentes conditions, aussi bien pour leurs qualités techniques que humaines. Je tiens d’abord à remercier Nicolas Sendrier mon directeur de thèse pour ses conseils et ses idées qui ont été précieuses et nécessaires au bon déroulement de ces trois années de thèse. Je tiens également à remercier Jean-Pierre Tillich, avec qui j’ai eu la chance de travailler, pour son exigence et sa patience. Merci ensuite à mes deux rapporteurs Pierre Loidreau et Thierry Berger qui ont donné de leur temps pour la relecture de ce manuscrit. Je devrais d’ailleurs remercier doublement Thierry Berger, je lui dois en effet ma découverte des codes correcteurs au cours de mes deux années de Master. Merci également à Gilles Burel et Annick Valibouze d’avoir accepté de faire partie de mon jury. Je ne saurais remercier les gens qui m’ont aidée et soutenue durant cette thèse sans remercier Audrey, avec qui j’ai partagé de multiples interrogations et rebondissements, pour sa disponibilité. Je lui souhaite bonne chance pour la suite. Mes pensées vont ensuite vers Maxime et Jérôme sans qui cette thèse n’aurait pas eu lieu et bien sûr Florine, Denis, Marc, Pierre, Angélique et François pour leur accueil et leur sympathie. Je ne doute pas que j’aurai le plaisir de les revoir. Un grand merci à tous les membres et anciens du projet SECRET que j’ai eu l’occasion de côtoyer Anne, Pascale, María, Christelle, André, Anthony, Ayoub, Baudoin, Céline, Christina, Denise, Gaë- tan, Grégory, Joëlle, Mamdouh, Matthieu, Rafael, Stéphane, Valentin, Vincent, Virginie et Yann. Je garderai d’excellents souvenirs des trois années que j’ai passées au projet. Je dois une dédicace particulière à Christelle qui est d’un grand secours et qui nous aide toujours avec le sourire, à Ayoub, Baudoin, Céline, Christina et Valentin avec qui j’ai partagé mes séances de footing et à Christina de nouveau en tant que pâtissière en chef du projet et ancienne collègue de bureau, merci à elle pour ses excellents gâteaux et sa bonne humeur. Merci également à tous ceux avec qui j’ai appris l’art des mots croisés. Mes prochains remerciements vont à mes collègues Grégory, Valentin et Virginie qui font du bureau 1 un endroit où il fait bon travailler. Mille mercis à Grégory pour tous ses conseils et son aide précieuse, à Valentin pour sa disponibilité sans faille et à Virginie pour sa gentillesse et sa présence. Merci ensuite à mes proches pour leur soutien et leur patience, mes amies Amanda et Adeline, ma famille Fanny, Michael, Fredo, Ingrid, Christine, mes parents bien sûr et enfin Nicolas.iiNotations Notations mathématiques H⊤ la transposée de la matrice H dH( . , . ) la distance de Hamming de( . , . ) la distance euclidienne WH( . ) le poids de Hamming Fq le corps à q éléments, q puissance d’un nombre premier GL(a, F2) l’ensemble des matrices inversibles de taille a × a à coefficients dans F2 pgcd le plus grand diviseur commun ppcm le plus petit multiple commun degg(x) le degré du polynôme g(x) Notations relatives aux mappings a le nombre de bits par symboles binaires de la modulation C une constellation CL(f) la classe linéaire de f CA(f) la classe affine de f f un mapping Gp la pénalité de Gray moyenne Gpk la pénalité de Gray maximum Notations relatives aux codes correcteurs C un code n la longueur du code k la dimension du code G une matrice génératrice H une matrice duale iiiChapitre 1 A0 l’amplitude de l’onde porteuse A et B des alphabets de modulation b(t) un bruit blanc gaussien f0 la fréquence de l’onde porteuse g(t) une impulsion élémentaire M le nombre de points de la constellation M − ASK,M − P SK, M − QAM une modulation à M points p(t) une onde porteuse r(t) le signal reçu sI (t) la porteuse en phase sQ(t) la porteuse en quadrature s(t) le signal émis ϕ0 la phase de l’onde porteuse Chapitre 4 C\I code poinçonné aux positions indéxées par I HI matrice duale restreinte aux positions indixées par I p la probabilité d’erreur du canal binaire symétrique PC la probabilité de collisions pour des données codées Paléa la probabilité de collisions pour des données aléatoires R = PC Paléa le rapport des probabilités de collisions t la taille des blocs de lecture d’une séquence binaire Xobs le nombre de collisions observées sur une séquence binaire xobs la probabilité de collisions observée sur une séquence biniareRésumé Ce document présente les travaux effectués durant ma thèse au sein de l’Equipe-projet SECRET à INRIA Paris-Rocquencourt. Nous nous intéressons à la reconstruction d’un système de communication dans un contexte non coopératif. Nous cherchons d’une part à reconstruire l’association réalisée entre symboles binaires et symboles physiques lors de la conversion de données binaires en un signal modulé (éventuellement bruité). On appelle cette opération le mapping. Dans un canal hertzien, une modulation M-aire peut transmettre M symboles distincts formant une constellation dans un espace euclidien multidimensionnel (par exemple bidimensionnel, représentant la phase et l’amplitude des symboles transmis). Nous regardons essentiellement les modulations de 4 à 256 − QAM (Quadrature Amplitude Modulation). En l’absence de redondance il est impossible de décider quel mapping a été utilisé, aussi nous supposons ici que les données binaires sont codées. Nous nous intéressons particulièrement aux mappings respectant le critère de Gray (deux symboles de la constellation, voisins pour la distance euclidienne, correspondront à des symboles binaires à distance de Hamming de 1). Ce type de mapping est en effet couramment utilisé car il permet de limiter l’impact des erreurs d’interprétations lors de la démodulation. La recherche exhaustive du mapping pour ce type de constellations devient impossible lorsque le nombre de points de celles-ci augmente, alors que les grandes constellations possèdent l’avantage d’augmenter les débits de transmission. Nous définissons alors deux types de classes d’équivalences de mappings : linéaires et affines. Nous définissons de plus un test basé sur la reconnaissance de codes convolutifs et le taux d’erreur du canal. Nous construisons un algorithme de reconstruction, en appliquant ce test, de manière appropriée, à un ensemble de représentants des classes d’équivalences définies. Nous verrons que le résultat d’un tel parcours n’est pas unique mais qu’il permet de réduire significativement le nombre de mappings possibles tout en réduisant le coût de la recherche. D’autre part nous définissons une méthode de détection des paramètres d’un code convolutif ainsi qu’une méthode de reconstruction du dual d’un tel code. Nous regardons une séquence binaire codée et bruitée par blocs de taille t. Deux blocs identiques définissent ce que l’on appelle une collision. La cardinalité de l’ensemble des blocs observés pour des données codées est inférieure à celle observée pour des données aléatoires. Donc la donnée de la probabilité de collisions pour différentes tailles de blocs permet de distinguer des données codées de données aléatoires. Des blocs glissants sont utilisés pour caractériser la présence d’un code convolutif. Cela permet d’obtenir la longueur, la dimension du code et le degré maximum des polynômes générateurs du dual ainsi que la taille de chacune des équations de parité. De plus en poinçonnant des bits dans chacun des blocs observés nous déduisons de la probabilité de collisions des équations de parité du code et une matrice génératrice du dual. La probabilité de collision est de plus invariante pour le changement de mapping lorsque la taille de bloc est un multiple de la taille des symboles du mapping. Nous sommes alors en mesure de détecter la longueur du code sans connaître le mapping qui a été utilisé lors de la modulation. vTable des matières Notations iii Résumé v Introduction 1 1 Introduction à la Transmission du signal Numérique 3 1.1 Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1 Transmission du signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.2 Constellations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3 Canal de transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4 Démodulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 Mappings 13 2.1 Codages Gray réfléchis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Codages Gray non réfléchis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 Codages Gray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 Mappings Gray P SK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5 Mappings Gray QAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.6 Mappings quasi-Gray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3 Codes Convolutifs et Codes de Reed-Solomon 23 3.1 Introduction aux codes correcteurs d’erreurs . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2 Codes cycliques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3 Codes convolutifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.1 Représentation binaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.2 Équations de parité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.3 Représentation en série . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.4 Codeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4 Reconstruction de codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.4.1 Codes Convolutifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.4.2 Codes Reed-Solomon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 vii4 Signature de codes convolutifs et recherche du dual par tests statistiques 39 4.1 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1.1 Test de profondeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1.2 Test de Burrows-Wheeler et Runs . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2 Test de collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3 Espérance du nombre de collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.1 Code de parité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.2 Équation de parité de poids u . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4 Distingueur de code convolutif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.5 Détection des paramètres d’un code convolutif par un teststatistique . . . . . . . . . . 52 4.5.1 Détection de la longueur de code . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.5.2 Détection de la dimension de code . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.5.3 Détection de la longueur des équations de parité . . . . . . . . . . . . . . . . . 58 4.5.4 Résultats de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.6 Application à la reconstruction du dual . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.6.1 Reconstruction du dual d’une matrice binaire . . . . . . . . . . . . . . . . . . . 60 4.6.2 Reconstruction du dual d’un code convolutif . . . . . . . . . . . . . . . . . . . . 62 4.7 Signature de codes convolutifs à mapping inconnu . . . . . . . . . . . . . . . . . . . . 64 5 Classes de Mappings 65 5.1 Relations d’équivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.2 Partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.3 Représentants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.4 Classification des mappings Gray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4.1 Partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4.2 Représentants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.5 Classification des mappings quasi-Gray . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6 Reconstruction de mappings en présence de données codées et bruitées 79 6.1 Classes d’équivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.1.1 Équivalence linéaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.1.2 Équivalence affine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.1.3 Nombre de solutions par classe affine . . . . . . . . . . . . . . . . . . . . . . . . 85 6.1.4 Unicité de la classe affine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.2 Algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.3 Applications aux mappings Gray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.4 Résultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.5 Application au cas des codes Reed-Solomon . . . . . . . . . . . . . . . . . . . . . . . . 91 A Rapport de probabilités de collisions avec une équation de parité 93Introduction La transmission d’une information numérique nécessite notamment un codage, à l’aide de codes correcteurs d’erreurs, puis une adaptation au canal de transmission que l’on appelle modulation. La modulation est composée de deux parties. La première appelée le mapping permet d’associer des symboles binaires à des paramètres physiques comme une amplitude et une phase. La seconde partie de la modulation permet elle d’utiliser ces valeurs pour modifier ponctuellement un signal porteur. Lors de la réception d’un signal il faut effectuer les opérations inverses de celles appliquées en émission afin de retrouver l’information émise. Un signal reçu doit donc avant toute chose être démodulé. On parle de contexte non coopératif lorsqu’un observateur doit recouvrer la séquence binaire émise à partir du seul signal transmis. Dans ce contexte il faut donc démoduler le signal observé pour associer aux symboles physiques une information binaire et enfin reconstruire le codage canal utilisé. Nous nous intéressons ici à ce problème de reconstruction d’un système de communication. Retrouver la modulation correspond au problème de la démodulation aveugle pour lequel il existe de nombreux travaux académiques, cependant cette démodulation n’inclut pas la reconstruction du mapping. Nous étudions alors le problème de la reconstruction du mapping. Retrouver le codage utilisé correspond au problème de la reconstruction de codes correcteurs d’erreurs pour lequel il existe également de nombreux travaux de recherche. On pourra citer notammant le travail de A. Valembois sur la reconstruction du dual d’un code correcteur d’erreur. Son algorithme se base sur la méthode de Canteaut-Chabaud de recherche de mots de petits poids dans un code. Des travaux spécifiques sur la reconstruction des codes convolutifs existent comme les thèses de E. Filiol, J. Barbier et M. Côte. Nous sommes intéressés à résoudre le problème de la reconnaissance de mapping lorsque les données sont codées par un codeur convolutif et nous utilisons le travail de M. Côte pour notre étude. Cela nous permet d’obtenir une matrice géné- ratrice du code correcteur utilisé à partir d’une séquence codée bruitée. Cependant, si l’on ne connaît pas l’association réalisée entre symboles binaires et symboles physiques, le mapping, on ne connaît pas le comportement de l’algorithme de reconnaissance de code convolutif. Nous nous intéressons à ce problème et étudions l’interaction entre la reconnaissance de codes convolutifs et la recherche de mapping. Dès lors que la transmission d’un signal s’effectue grâce à un protocole de communication, la sé- quence composée des mots de code transmis est encapsulée. De ce fait, il est possible de s’appuyer sur des balises pour connaître la synchronisation des mots de codes, c’est-à-dire que l’on connait le début des mots. Nous considérons alors dans ces travaux que la synchronisation est connue et qu’on n’avons pas à la rechercher. Nous avons abordé nos travaux selon deux axes. Le premier objectif est de décrire une méthode de reconstruction du mapping à partir de données démodulées avec un mapping par défaut. Le second axe consiste à obtenir des informations sur le code de manière invariante pour le mapping. 1Le second axe nous conduit à l’utilisation d’un test statistique basé sur le comptage de collisions dans une séquence binaire observée par blocs. Ce test permet d’estimer le cardinal de l’ensemble observé et donne une information à la fois quantitative et qualitative sur l’espace des blocs observés. Nous définissons alors une méthode de détection de la longueur d’un code convolutif invariante pour le changement de mapping. C’est-à-dire que nous sommes en mesure de dire si un code convolutif à été utilisé pour coder les données observées et le cas écheant d’en donner la longueur et ce sans connaître le mapping utilisé. Nous définissons de plus une méthode de détection des paramètres d’un code convolutif et de reconstruction du dual connaissant le mapping. C’est l’objet du Chapitre 4. Ce travail a été soumis à publication. Le premier axe concerne la reconstruction du mapping lorsque les données observées sont codées. Nous nous sommes principalement intéressés au cas des codes convolutifs. Lorsque l’on parcourt les divers mappings possibles on peut observer une multitude de séquences codées correspondant à divers codes correcteurs. Nous explicitons alors les liens qui relient les différents codes observés. Des classes d’équivalences de mapping peuvent être définies. Elles seront présentées dans le Chapitre 5. Ceci nous conduit à l’élaboration d’une méthode de reconstruction de mappings permettant de diminuer le nombre de mappings à parcourir pour les petites tailles de constellations. Pour des constellations à 16 points et plus, nous considérons uniquement les mappings de type Gray et quasi-Gray. La méthode s’étend naturellement à ces mappings. Celle-ci est applicable dans le cas où le signal transmis est un signal bruité. Nous regardons également le comportement des codes de Reed-Solomon vis-à-vis du changement de mapping. Ceci est vu au Chapitre 6. Cette partie du travail à fait l’objet d’une publication à ISITA’2012 [7]. 2Chapitre 1 Introduction à la Transmission du signal Numérique On peut représenter un système de communication (Figure 1.1) par la suite des traitements appliqués aux données binaires, en émission et en réception, afin d’assurer leur transmission. Codage source Codage canal Modulation Décodage source Décodage Canal Démodulation Canal de transmission Bruit Figure 1.1 – Synoptique d’une transmission numérique Codage source : Le codage de source consiste à éliminer la redondance de manière à réduire la quantité de données à transmettre. Codage canal : Quel que soit le type de canal de transmission utilisé, le signal transmis est soumis à des perturbations, que l’on appelle bruit, pouvant entraîner une altération des données. Afin d’y remédier, il est d’usage d’ajouter de la redondance à l’information dans le but de détecter puis corriger les erreurs de transmission. Nous utilisons pour cela des codes correcteurs d’erreurs. Modulation : La modulation consiste à transformer un message en un signal adapté à la transmission sur un support physique. Une introduction aux codes correcteurs d’erreurs est donnée au Chapitre 3. Nous nous intéressons à présent à différents types de modulations. Nous définissons ici ce qu’est une constellation et introduisons la notion de mapping, avant d’aborder les modèles de canaux de transmission. Ce chapitre est basé sur les ouvrages [19], [39] et [22]. 3Chapitre 1. Introduction à la Transmission du signal Numérique 1.1 Modulation Nous nous intéressons ici à la transmission de données numériques. L’information à véhiculer est donc une séquence binaire, tandis qu’un support physique permet de transmettre une information sous forme d’un signal continu. La modulation consiste alors à transformer l’information binaire en un signal continu adapté au support de transmission. Nous verrons qu’il existe deux possibilités pour transmettre un signal numérique : la transmission en bande de base ou la modulation d’une onde porteuse. La transmission en bande de base consiste à associer à la séquence binaire d’entrée un signal physique qui est transmis dans une plage de fréquence contenant la fréquence nulle. Elle s’utilise dans le cas d’une transmission filaire. La modulation par onde porteuse consiste à modifier un ou plusieurs paramètres d’une onde porteuse, en fonction du symbole binaire à transmettre (un bloc de bits de longueur donnée), et à l’émettre dans une plage de fréquence donnée qui peut être différente pour différents utilisateurs. Une démarche commune aux deux méthodes de transmission est l’association d’une information physique et d’un symbole binaire. C’est ce que nous appelons le mapping. 1.1.1 Transmission du signal Transmission en bande de base La notion de transmission en bande de base ne sera pas utile en tant que telle mais sera utile pour la compréhension du mécanisme de modulation présenté dans le paragraphe suivant. L’information à transmettre étant une séquence binaire, la première approche est d’associer au bit 0 un état significatif (par exemple une tension positive) et d’associer au bit 1 un autre état significatif (par exemple une tension négative). On appelle cette opération le codage, même si ce terme peut porter à confusion. Un exemple de codage : le codage NRZ (No Return to Zero) Le codage NRZ associe au bit 0 une valeur α et associe au bit 1 la valeur −α. La transmission de la séquence 0110101 se traduira alors par la transmission du signal suivant : +α −α 0 1 1 1 1 0 0 Figure 1.2 – Exemple de transmission suivant un codage NRZ Cet exemple ne constitue pas une règle générale, le bit 0 pouvant être codé par une valeur α positive ou négative et inversement pour le bit 1. 41.1 Modulation On dit alors que l’ensemble A = {α, −α} est un alphabet pour le codage NRZ. De manière générale, la suite de bits constituant le message est mise sous forme de symboles binaires, en créant des paquets de a bits. Il existe donc 2a symboles binaires distincts auquels sont associés des valeurs αi appartenant à un alphabet A de cardinal 2a . Le signal émis est de la forme s(t) = P j αjg(t − jT) où αj est la j ème valeur à transmettre et appartient à l’alphabet A choisi et g(t) est une impulsion élémentaire de durée T. Dans l’exemple du codage NRZ, l’impulsion utilisée est telle que g(t) = ( 1 si 0 ≤ t < T 0 sinon . On détaille le calcul de s(t) pour la transmission de la séquence binaire 0110101 dans le tableau ci-dessous : j bit à transmettre αj s(t) 0 0 −α −αg(t) = −α, ∀ 0 ≤ t < T 1 1 α αg(t − T) = α, ∀ T ≤ t < 2T 2 1 α αg(t − 2T) = α, ∀ 2T ≤ t < 3T 3 0 −α −αg(t − 3T) = −α, ∀ 3T ≤ t < 4T 4 1 α αg(t − 4T) = α, ∀ 4T ≤ t < 5T 5 0 −α −αg(t − 5T) = −α, ∀ 5T ≤ t < 6T 6 1 −α −αg(t − 6T) = −α, ∀ 6T ≤ t < 7T Modulation par onde porteuse On définit une onde porteuse par l’expression p(t) = A0cos(2πf0t + ϕ0) où A0 est l’amplitude du signal, f0 sa fréquence et ϕ0 sa phase. La modulation par onde porteuse consiste à transmettre de l’information en modifiant un ou plusieurs paramètres de cette onde porteuse. Le signal en bande de base est alors transposé en fréquence afin d’assurer la transmission dans une bande de fréquence adaptée. C’est-à-dire que le signal en bande de base devient le signal modulant. De plus le signal est transmis à une fréquence donnée qui peut être différente pour différents utilisateurs. Il existe différents types de modulation utilisant des paramètres distincts de la porteuse comme : – la modulation ASK (Amplitude Shift Keying), une modulation d’amplitude – la modulation PSK (Phase Shift Keying), une modulation de phase – la modulation FSK (Frequency Shift Keying), une modulation de fréquence – la modulation QAM (Quadrature Amplitude Modulation), une modulation de phase et d’amplitude Nous ne nous intéressons ici qu’aux modulations d’amplitude et/ou de phase. On note a le nombre de bits par symbole binaire. On a donc M = 2a symboles possibles. Nous supposons ici, pour simplifier 5Chapitre 1. Introduction à la Transmission du signal Numérique l’écriture des signaux modulés, que l’amplitude A0 des porteuses est égale à 1. Modulation ASK Le signal modulé s’écrit s(t) = X j αjg(t − jT)cos(2πf0t) En notant sI (t) = X j αjg(t − jT) on a s(t) = cos(2πf0t)sI (t) Le signal sI (t) modifie alors l’amplitude de la porteuse p(t) = cos(2πf0t). On prendra a priori comme alphabet {±α, ±3α, . . . , ±(M − 1)α}. Modulation PSK Le signal modulé s’écrit s(t) = X j cos(2πf0t + αj )g(t − jT) En notant sI (t) = X j cos(αj )g(t − jT) et sQ(t) = X j sin(αj )g(t − jT) on a s(t) = cos(2πf0t)sI (t) − sin(2πf0t)sQ(t) Le signal sI (t) modifie l’amplitude de la porteuse p(t) = cos(2πf0t) tandis que le signal sQ(t) modifie l’amplitude de la porteuse sin(2πf0t) = cos(2πf0t + π 2 ). On appelle la première porteuse la porteuse en phase, la seconde la porteuse en quadrature. On pourra prendre, pour M = 4, l’un des deux alphabets suivants { iπ 4 |i = 1, 3, 5, 7} ou { iπ 2 |k = 0, 1, 2, 3}. On prendra pour M = 8 l’alphabet { iπ 4 |i = 0, 1, 2, . . . , 7}. Modulation QAM La modulation d’amplitude et de phase simultanée nécessite l’utilisation de deux alphabets A et B de cardinal respectif 2b et 2b ′ . À un symbole binaire de b + b ′ bits on associe un couple (αi , βi ′) ∈ A × B. Et le signal modulé s’écrit s(t) = X j αjcos(2πf0t + βj )g(t − jT) (αj , βj ) ∈ A × B étant la j ème valeur à transmettre. En écrivant sI (t) = X j αjcos(βj )g(t − jT) 61.1 Modulation sI (t) sQ(t) −(M − 1)α −3α −α α 3α (M − 1)α b b b b b b Figure 1.3 – Constellation d’une modulation M-ASK ayant pour alphabet {±α, ±3α, . . . , ±(M −1)α} et sQ(t) = X j αjsin(βj )g(t − jT) on a s(t) = cos(2πf0t)sI (t) − sin(2πf0t)sQ(t) Comme pour la modulation de phase, sI (t) et sQ(t) modifient respectivement l’amplitude de la porteuse en phase et de la porteuse en quadrature. Les trois modulations présentées ici s’écrivent sous la forme s(t) = cos(2πf0t)sI (t)−sin(2πf0t)sQ(t) avec des expressions différentes pour sI (t) et sQ(t) (avec sQ(t) = 0 pour une modulation ASK). À ce titre on peut classer chacune de ces modulations comme des cas, particuliers ou non, de modulation de type QAM. Nous étudierons pour ces modulations les divers mappings possibles. Nous allons voir à présent la notion de constellation et leur forme pour ces modulations. On note M − ASK, M − P SK et M − QAM des modulations à M = 2a points, c’est-à-dire admettant log2M bits par symbole binaire. 1.1.2 Constellations Pour un temps tj fixé, il existe (αj , βj ) tel que : ( sI (tj ) = αj sQ(tj ) = 0 pour une modulation ASK ( sI (tj ) = cos(αj ) sQ(tj ) = sin(αj ) pour une modulation PSK ( sI (tj ) = αj cos(βj ) sQ(tj ) = αj sin(βj ) pour une modulation QAM On représente alors l’ensemble des sI (tj ) et sQ(tj ) dans le plan, formant ainsi une constellation, représentée par la Figure 1.3 dans le cas d’une modulation M-ASK. Définition 1.1.1 (Constellation) Une constellation est la représentation des différents états de la modulation On peut faire de même pour les modulations de type PSK et QAM. On obtient pour une modulation PSK un ensemble de points répartis sur un cercle. (Le rayon du cercle étant déterminé par l’amplitude A0 de la porteuse, que nous avons supposé normalisée à 1 afin de simplifier l’écriture des signaux modulés). Un exemple de constellation PSK pour un nombre de bits par symbole égal à 3 est donné par la Figure 1.5. 7Chapitre 1. Introduction à la Transmission du signal Numérique t t t t Figure 1.4 – Constellation d’une modulation 4-PSK b b b b b b b b αk sI (t) sQ(t) Figure 1.5 – Constellation 8-PSK r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r Figure 1.6 – Constellations correspondant à des modulations (de gauche à droite) : 16-QAM, 32- QAM, 64-QAM, 128-QAM et 256-QAM Le choix de l’alphabet (ou des alphabets) détermine la forme de la constellation. Les modulations 32 et 128−QAM sont d’ailleurs ici cruciformes contrairement aux modulations à 2a points avec a pair. Nous étudions ici les mappings des constellations données par la Figure 1.6 pour les modulations QAM de 16 à 256 points, par la Figure 1.5 pour une constellation à 8 points et enfin par la Figure 1.4 pour une constellation à 4 points, soit de 2 à 8 bits par symbole binaire. La représentation sous forme de constellation sera à présent l’unique représentation pour une modulation donnée. 1.2 Mapping La modulation est l’opération qui permet de convertir une séquence d’information binaire en un signal adapté au support de transmission. Le nombre de bits que l’on souhaite transmettre à chaque intervalle de temps détermine la taille de l’alphabet à utiliser et donc le nombre de points de la constellation pour une modulation donnée. 81.3 Canal de transmission Définition 1.2.1 (Mapping 1) On appelle mapping l’association réalisée entre un symbole binaire et un élément de l’alphabet correspondant à la modulation choisie. Un exemple de mapping Prenons une modulation 2−ASK d’alphabet A = {−α, α}, on peut définir un mapping en associant au bit 0 la valeur −α, et au bit 1 la valeur α. On peut représenter cette association directement sur la constellation. Mais un second mapping est possible en faisant l’association inverse, c’est-à-dire en associant au bit 0 la valeur α et au bit 1 la valeur −α. On peut alors considérer l’opération de mapping comme l’association d’un point de la constellation et d’un symbole binaire. Définition 1.2.2 (Mapping 2) Soit C une constellation à M = 2a points. On appelle mapping toute bijection, f, de C dans {0, 1} a , qui à un point P de C associe un symbole binaire de longueur a. Naturellement d’après la définition 1.2.2, le nombre de mappings possible pour une constellation donnée est de (2a )!. Ce nombre est décrit pour différentes tailles de constellations par la Table 1.1. Table 1.1 – Nombre de mappings pour a = 2, 3, 4 a Nombre de mappings 2 24 3 40 320 4 > 2 ∗ 1013 Nous utiliserons à présent cette définition du mapping. Notons qu’il existe cependant certains mappings ayant des propriétés permettant de limiter les erreurs de transmission, comme les mappings de type Gray [30] que nous utiliserons par la suite. 1.3 Canal de transmission Lors de la transmission d’un signal, celui-ci est soumis à des atténuations et déformations propres au canal (par exemple dû à la distance entre deux antennes pour une communication sans-fil). Il est également soumis à des perturbations externes que l’on appelle couramment du bruit. Différents supports de transmission permettent de véhiculer une information (câble électrique, fibre optique, liaison sans-fil . . .). Chaque type de transmission possède un modèle de propagation qui lui est propre. Une liaison sans-fil est en particulier sensible aux obstacles entraînant des réflexions, diffractions du signal. À ce titre, ces liaisons sont les plus difficiles à modéliser et il existe différents modèles de canaux de transmission. Les deux modèles les plus couramment utilisés sont le canal à bruit blanc additif gaussien et le canal binaire symétrique. Ils sont tous deux des canaux dits sans mémoire. Il existe cependant d’autres modèles simulant notamment les canaux multi-trajets tels que les canaux de Rayleigh et de Rice, utilisés pour modéliser les radiocommunications, auxquels nous ne nous intéressons pas ici. Le canal à bruit blanc additif gaussien : le signal reçu r(t) s’écrit comme l’addition du signal émis s(t) et du bruit blanc gaussien b(t). b(t) est modélisé, dans une bande de fréquence limitée, par un processus aléatoire centré de moyenne nulle, de variance σ 2 , dont la densité de probabilité est : 9Chapitre 1. Introduction à la Transmission du signal Numérique p(b) = 1 √ 2πσ2 e −b 2 2σ2 La qualité d’une transmission analogique se mesure à l’aide du rapport signal à bruit, noté SNR (Signal to Noise Ratio) et exprimé généralement en décibels. Il mesure le rapport de puissance entre le signal et le bruit. Plus le bruit est élevé plus le rapport signal à bruit diminue. La qualité d’une transmission numérique se mesure quant à elle à l’aide de deux outils distincts qui sont le rapport signal à bruit par bit, Eb/N0, et le Taux d’Erreur Binaire (TEB ou BER pour Bit Error Rate). Le rapport signal à bruit par bit mesure le rapport entre l’énergie véhiculée par un bit, Eb, et la densité spectrale de puissance du bruit, N0. Le taux d’erreur binaire définit la probabilité pour un bit d’être faux : BER = nombre de bit f aux nombre de bits transmis Il est possible de calculer le taux d’erreur binaire en fonction du rapport signal à bruit par bit. Ce calcul dépend fortement de la modulation choisie et du mapping utilisé. On trouve ce calcul dans la littérature pour différents types de modulation ([22, 39, 40]). Le canal binaire symétrique : les entrées et sorties du canal binaire symétrique sont des valeurs binaires. Il est caractérisé par la probabilité d’erreur p qu’un bit (0 ou 1) soit modifié (en son opposé) lors de la transmission. La probabilité qu’un bit ne soit pas modifié lors de la transmission est alors 1 − p. Il est représenté par la Figure 1.7. 0 0 1 1 p p 1 − p 1 − p Figure 1.7 – Canal binaire symétrique de probabilité d’erreur p On considère que le canal binaire symétrique regroupe alors la modulation, le canal et la démodulation dans le schéma d’un système de communication. Il est courant de considérer deux modèles de canaux de transmission : – Un modèle dit interne AWGN (Additive White Gaussian Noise), pour lequel est calculé le taux d’erreur binaire (en fonction de la modulation et du mapping). – Un modèle dit externe BSC (Binary Symetric Channel) ayant pour probabilité d’erreur p la probabilité définie par le BER du canal interne. Ce qui rend transparent la modulation et la démodulation pour le codage canal. 1.4 Démodulation On appelle démodulation l’extraction des paramètres αk et βk contenus dans les composantes sI (t) et sQ(t) d’un signal émis s(t). Le signal reçu s ′ (t) correspond au signal s(t) transformé par le bruit du 101.4 Démodulation canal de transmission. Les composantes s ′ I (t) et s ′ Q(t) reçues correspondent alors à des modifications des composantes sI (t) et sQ(t) et la donnée d’un couple (s ′ I (t), s′ Q(t)) donnera lieu à interprétation, dans le sens où l’on évaluera la distance entre le point de coordonnées (s ′ I (t), s′ Q(t)) et les points de la constellation. En effet, l’objectif est de retourner les symboles les plus probablement émis. Un détecteur a maximum de vraisemblance (ML pour Maximum Likelihood) fait l’hypothèse que les symboles émis sont équiprobables. Il calcule alors la distance euclidienne entre les symboles reçus et les symboles possibles. La décision se fait, pour un symbole reçu donné, en faveur du symbole de l’alphabet le plus proche au sens de la distance euclidienne. De cette manière une erreur de décision peut être commise si le point de coordonnées (s ′ I (t), s′ Q(t)) est plus proche géométriquement d’un point de la constellation différent de celui correspondant au signal émis à l’instant t. Lorsqu’une telle erreur se produit, le plus souvent, un point de la constellation est interprété comme étant un de ses plus proches voisins. 11Chapitre 1. Introduction à la Transmission du signal Numérique 12Chapitre 2 Mappings Le mapping est l’association réalisée entre les points d’une constellation et les différents symboles binaires possibles pour une taille de constellation donnée. La taille d’une constellation en désigne le nombre de points, elle détermine alors le débit de transmission. À une constellation de M = 2a points, est associé un ensemble de 2a symboles binaires de longueur a. Nous utilisons tout au long de ce manuscrit la notation a pour désigner le nombre de bits par symbole binaire du mapping. Nous rappelons la définition de mapping comme étant une bijection de la constellation C dans {0, 1} a . Définition 2.0.1 (Mapping) Soit C une constellation à M = 2a points. On appelle mapping toute bijection f, de C dans {0, 1} a , qui à un point P de C associe un symbole binaire de longueur a. Nous rappelons que le nombre de mappings, pour une constellation donnée, est le nombre de permutations de {0, 1} a , c’est-à-dire (2a )!. Nous pouvons alors décrire l’ensemble des mappings en décrivant l’ensemble de ces permutations, pour de petites tailles de constellations (ie a = 2 ou a = 3). Il existe cependant des mappings permettant de limiter le Taux d’Erreur Binaire (T EB ou BER pour Bit Error Rate) en réception. Il définit le nombre d’erreurs de transmission ou d’écriture pour une information numérique. Un taux d’erreur de 10−2 signifie qu’un bit sur 100 est erroné. Les mappings Gray [30] permettent de limiter les erreurs de transmission et donc de diminuer le BER. Définition 2.0.2 (Mapping Gray) Soit C une constellation à M = 2a points. Soit f un mapping de C. On dit que f est un mapping Gray si pour tous points Pi , Pj de C, voisins pour la distance euclidienne, alors f(Pi) et f(Pj ) sont à distance de Hamming de 1. Le terme mapping est essentiellement utilisé pour désigner l’association des symboles binaires et des points d’une constellation en dimension 2. Il est alors courant d’utiliser le terme codage dans le cas d’une constellation en dimension 1. La décision réalisée lors de la démodulation consiste à associer le point reçu, à l’instant t, au point de la constellation le plus proche, au sens de la distance euclidienne. Si le symbole binaire, correspondant au point de la constellation le plus proche, est à distance de Hamming de 1, du symbole binaire émis à l’instant t, alors un seul bit est erroné à cet instant. F. Gray a introduit en 1953 ce type de codage. Il a pour but de limiter les erreurs de transmission. Le code Gray impose des éléments successifs ayant un seul bit différent. Nous pouvons par exemple coder les entiers de 0 à 7 en binaire naturel : 000, 001 , 010 , 011, 100, 101, 110, 111 ou selon le codage 13Chapitre 2. Mappings Gray : 000, 001, 011, 010, 110, 111, 101, 100. Le codage Gray assure de plus un minimum d’opérations lors du passage d’un élément au suivant. Ce codage, également appelé binaire réfléchi, est le codage initialement introduit par F. Gray. Il existe d’autres codages que nous pouvons qualifier de codage Gray puisqu’ils respectent la distance de Hamming de 1 entre deux symbole successifs. Nous voyons en effet dans ce chapitre différents types de codage Gray, réfléchis ou non réfléchis et de quelle façon les générer d’après les travaux de E.N. Gilbert [29]. Ces codages sont utilisés pour construire des mappings Gray pour des constellations P SK, QAM carrées. Les travaux de R.D. Wesel, X. Liu, J.M Cioffi et C. Komminakis [56] ont permis de décrire la méthode de construction de mappings Gray à partir du produit direct de deux codages Gray. Ainsi il nous est possible d’énumérer tous les mappings Gray. Ils ont également mis en avant l’impossibilité de construire un mapping Gray pour une constellation en croix. Nous décrivons alors des méthodes issues essentiellement de ces travaux [32, 56] d’une part et des travaux de J.G. Smith [45] d’autre part, permettant de définir des mappings approchant le critère de Gray. Ils sont communément appelés des mappings quasi-Gray. On pourra également citer les travaux de P.K. Vitthaladevuni, M.S. Alouini et J.C. Kieffer [51, 52] dans ce domaine. Cependant il n’existe pas de définition formelle des mappings quasi-Gray au sens où tous les mappings peuvent être considérés comme quasi-Gray avec des caractéristiques se rapprochant plus ou moins du critère de Gray. 2.1 Codages Gray réfléchis Nous définissons ici un codage Gray réfléchi et sa méthode de construction. Un tel codage est construit comme suit : à l’étape 0 on choisit un symbole parmi les 2a possibles. Ce symbole sert de labellisation pour le point le plus à gauche de la constellation. À l’étape i on choisit un bit à complémenter (non utilisé pendant les étapes précédentes). À cette étape, 2i points sont déjà labellisés. Nous labellisons alors les 2i suivants par symétrie en complémentant le bit précédemment choisi. L’exemple d’un codage Gray réfléchi pour une constellation unidimensionnelle à 8 points est donné ci-dessous, il permet d’illustrer cette construction. Le symbole d’origine est choisi : b b b b b b b b 001 Le 3ème bit est complémenté pour obtenir le symbole suivant : b b b b b b b b 001 000 Les deux symboles suivants sont obtenus par symétrie et en complémentant le 2ème bit de chaque symbole. b b b b b b b b 001 000 010 011 142.2 Codages Gray non réfléchis Les derniers symboles s’obtiennent alors en complémentant le 1er bit de chaque symbole, en utilisant également une symétrie : b b b b b b b b 001 000 010 011 111 110 100 101 Cette construction permet de décrire 23 .3! codages Gray réfléchis différents : 23 pour le choix du symbole d’origine et 3! pour le choix de l’ordre des bits à complémenter. Plus généralement, pour une constellation à 2a points il existe 2a .a! codages Gray réfléchis. 2.2 Codages Gray non réfléchis F. Gray a introduit les codes Gray réfléchis. Il existe cependant des codages également appelés codages Gray qui sont de type non réfléchis. Le codage donné ci-dessous en est un exemple. Nous pouvons cependant remarquer que les symboles situés aux extrémités sont à distance de Hamming de 1. Nous appelons de tels codages des codages Gray cycliques. Les codages Gray réfléchis sont d’ailleurs des codages cycliques. b b b b b b b b 101 001 000 010 011 111 110 100 Il existe donc trois familles de codages Gray : les codages Gray réfléchis, les codages Gray cycliques et enfin les codages qui ne sont ni réfléchis ni cycliques. 2.3 Codages Gray E.N. Gilbert [29] a décrit en 1957 une méthode de génération de l’ensemble des codages Gray basée sur la description de chemins dans un graphe. On définit Qa comme étant un graphe à 2a sommets où deux sommets sont reliés par une arête si leurs labels respectifs ne diffèrent que d’un bit. Une représentation de ces graphes dans le cas a = 2, 3, 4 est donnée par la Figure 2.1, où chaque sommet est labellisé par l’écriture binaire de son numéro. 0 1 2 3 0 1 2 3 4 5 6 7 Figure 2.1 – Représentation des graphes Qa, de gauche à droite a = 2, 3, 4 15Chapitre 2. Mappings Les cubes ainsi construits permettent d’obtenir d’une part le nombre de codages Gray pour a ∈ J1, 4K, et d’autre part les codages Gray en eux-mêmes. En effet, la description d’un codage Gray est équivalente à la description d’un chemin, de longueur 2a de Qa, ne parcourant qu’une seule fois chacun des sommets. Le chemin défini par les sommets 0, 1, 3, 2, dans Q2, permet d’obtenir, par le biais de ses labels, le codage Gray suivant : 00, 01, 11, 10. Le chemin 0, 2, 3, 1 définit également un codage Gray. Il existe deux chemins de longueur 4 parcourant chacun des sommets de Q2 et ayant pour origine le sommet 0, ainsi que pour chacune des origines possibles. Il y a donc 8 codages Gray à 2 bits. Nous pouvons déterminer le nombre de codages Gray cycliques pour a ∈ J1, 4K en posant la contrainte suivante : les chemins retenus sont ceux ayant pour extrémités des sommets voisins. Le nombre de codage Gray obtenu par simulation est : – pour a = 2 : 8 dont 8 cycliques – pour a = 3 : 144 dont 96 cycliques – pour a = 4 : 91392 dont 43008 cycliques Les codages Gray réfléchis sont utilisés pour la construction de mappings quasi-Gray, à savoir des mappings respectant “au maximum” le critère de Gray, dans le cas de constellation comme les 32 − QAM et 128 − QAM. Les codages Gray cycliques sont utilisés pour la construction de mappings Gray valides pour les constellations P SK. L’ensemble des codages Gray est également utilisé dans le cas des constellations QAM carrées ou rectangulaires. 2.4 Mappings Gray PSK Une constellation P SK est un ensemble de points dans le plan répartis sur un cercle de rayon A (l’amplitude du signal). Un codage Gray cyclique permet donc de définir un mapping Gray pour ce type de constellation en “enroulant” ce code sur lui-même. Ainsi il existe 96 mappings Gray P SK, dont 48 sont des mappings issus de codages Gray réfléchis. Nous remarquons que la notion de points voisins dans une constellation diffère selon sa configuration. Un point a uniquement deux voisins dans une constellation P SK tandis qu’il peut en avoir jusqu’à quatre dans une constellation QAM. 2.5 Mappings Gray QAM Nous décrivons ici la méthode de génération d’un mapping Gray, pour une constellation QAM carrée ou rectangulaire, issue des travaux Wesel, Liu, Cioffi, Komminakis. Cette méthode utilise le produit direct de deux codages Gray. Elle permet notamment la génération de l’ensemble des mappings Gray. Soit une constellation QAM à 2a × 2 b points. Soient deux codages Gray à 2a et 2b points respectivement. L’un est utilisé verticalement, l’autre horizontalement. Nous pouvons alors labelliser un point en adjoignant ses labels verticaux et horizontaux correspondants. En vue de générer l’ensemble des mappings Gray possibles sans parcourir deux fois le même mapping, il faut fixer la contrainte de ne pas inverser l’ordre des bits issus d’un même codage. Il y a alors a+b a
mappings possibles pour deux codages horizontaux et verticaux fixés. Deux exemples de tels mappings sont donnés par la Figure 2.2. 162.6 Mappings quasi-Gray b b b b b b b b 10 00 01 11 11 01 00 10 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111 b b b b b b b b b b b b b b b b 10 00 01 11 11 01 00 10 0000 0001 0100 0101 0010 0011 0110 0111 1000 1001 1100 1101 1010 1011 1110 1111 b b b b b b b b Figure 2.2 – Deux mappings Gray construits par produit direct de codes Gray On note nl (respectivement nc) le nombre de codages Gray lignes (respectivement colonnes). Le nombre de mappings Gray pour une constellation QAM rectangulaire de taille 2a × 2 b est de nl . nc . a + b a ! Le nombre de mappings Gray pour les constellations 4 − P SK, 8 − P SK, 16 − QAM, 64 − QAM et enfin 256 − QAM est donné par la Table 2.1. Constellation Nombre de mappings Gray 4 − P SK 8 8 − P SK 96 16 − QAM 384 64 − QAM 414 720 256 − QAM 584 674 836 480 Table 2.1 – Nombre de mappings Gray La génération de mappings Gray réfléchis pour les constellations QAM carrées ou rectangulaires peut se faire par une méthode similaire à celle définie pour les codages Gray. Elle peut également se faire par produit direct de deux codages Gray réfléchis. Les mappings Gray minimisent les erreurs de réception. Ils sont potentiellement très utilisés et sont à ce titre des cibles privilégiées pour la suite de notre travail. Il est impossible d’utiliser des mappings Gray pour les constellations en croix, 32−QAM et 128 − QAM, nous nous intéressons donc aux mappings dits quasi-Gray. 2.6 Mappings quasi-Gray Wesel & al. ont démontré qu’il n’est pas possible de construire de mappings Gray pour les constellations en croix, notamment 32−QAM et 128−QAM. Il est cependant possible d’utiliser des mappings dits quasi-Gray respectant autant que possible le critère de Gray. Il existe dans la littérature différents 17Chapitre 2. Mappings mappings quasi-Gray. Le but de cette section est d’en présenter quelques uns. La qualité d’un mapping quasi-Gray peut être jugée grâce aux deux critères suivants : la pénalité de Gray moyenne, la pénalité de Gray maximum. Comme il n’existe pas de définition formelle des mappings quasi-Gray, en pratique, on recherche des mappings qui minimisent les pénalités de Gray moyenne et maximum. Définition 2.6.1 (Pénalité de Gray moyenne) On définit la pénalité de Gray moyenne, notée Gp, comme le nombre moyen de bits différents entre deux symboles binaires voisins. Définition 2.6.2 (Pénalité de Gray maximum) On définit la pénalité de Gray maximum, notée Gp k , comme le nombre maximum de bits différents entre deux symboles binaires voisins. Mappings 32 − QAM Méthode par déplacement de labels La première approche se base sur la définition de mappings quasi-Gray à partir de mappings rectangles. Deux méthodes sont schématisées ici, la première issue de [56] est vue dans la Figure 2.3, la seconde issue de [45] est vue dans la Figure 2.4. b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b (2) (4) (1) (3) b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b (2) (4) (1) (3) Figure 2.3 – Construction d’un mapping 32 − QAM par la méthode de Wesel & al. b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b (2) (4) (1) (3) b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b (2) (4) (1) (3) Figure 2.4 – Construction d’un mapping 32 − QAM par la méthode de J.G. Smith Méthode par définition de transitions La seconde approche se base sur la notion de transition. On appelle transition entre deux symboles binaires s1 et s2, un vecteur v, de taille a tel que s2 = s1 + v. Les transitions pour les constellations 32 − QAM sont des vecteurs de taille 5. Wesel & al. ont étudié ces transitions pour en déterminer le nombre nécessaire à l’obtention d’un mapping 32 − QAM, ainsi que les agencements décrivant des mappings quasi-Gray raisonnables. Il en résulte qu’il est possible de labelliser entièrement une 182.6 Mappings quasi-Gray constellation, pour a impair, avec a + 1 transitions : les transitions unitaires (de poids de Hamming 1) et une transition combinaison linéaire des précédentes. Pour les mappings 32 − QAM, ils proposent ainsi six schémas (Figure 2.5). La construction d’un mapping avec cette méthode consiste à choisir le symbole binaire correspondant à l’un des points de la constellation et à appliquer les transitions successivement afin d’obtenir la labellisation de l’ensemble de la constellation. Nous avons matérialisé les transitions non unitaires en les soulignant de gris dans ces schémas de construction. Cela permet de remarquer les positions où les contraintes de Gray ne sont pas respectées. Le nombre de ces positions détermine en partie la qualité du mapping quasi-Gray ainsi défini. Le nombre de mappings quasi-Gray obtenus grâce à l’un des six schémas correspond à 5!.32 ( 5! pour le choix des transitions e1 à e5, e6 étant fixe, 32 pour le choix du symbole d’origine). Correspondance des méthodes Le premier schéma de la Figure 2.5 (en haut à gauche) correspond à un mapping Gray réfléchi pour lequel les points situés aux extrémités droite et gauche ont été déplacés. Ce schéma correspond à la construction de la Figure 2.3. On peut également représenter la construction de la Figure 2.4 sous forme de schéma de transition ( Figure 2.6) à partir du schéma de transition d’un mappings rectangulaire réfléchi (Figure 2.7). b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b e4 e2 e2 e6 e7 e7 e6 e5 e5 e1 e1 e2 e1 e1 e3 e1 e1 e2 e1 e1 e6 e7 e7 e6 e2 e2 e6 = e1 ⊕ e5, e7 = e2 ⊕ e5 Figure 2.6 – Schéma de transition des mappings quasi-Gray de J.G. Smith b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b e1 e5 e4 e1 e3 e2 e1 e1 e5 e2 Figure 2.7 – Schéma de transition d’un mappings Gray réfléchi rectangulaire 32 − QAM 19Chapitre 2. Mappings b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b e4 e2 e2 e6 e5 e5 e6 e5 e5 e1 e1 e2 e1 e1 e3 e1 e1 e2 e1 e1 e6 e5 e5 e6 e2 e2 e6 = e1 ⊕ e2 ⊕ e5 (a) Construction 1 b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b e1 e3 e3 e4 e5 e3 e3 e5 e4 e6 e5 e5 e6 e4 e3 e4 e4 e3 e2 e3 e4 e4 e3 e4 e6 e5 e5 e6 e4 e5 e3 e3 e5 e4 e3 e3 e6 = e3 ⊕ e4 ⊕ e5 (b) Construction 2 b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b e1 e4 e4 e2 e5 e4 e4 e5 e4 e6 e3 e3 e6 e4 e3 e5 e5 e3 e2 e3 e5 e5 e3 e4 e3 e5 e5 e3 e2 e5 e5 e6 = e3 ⊕ e4 ⊕ e5 (c) Construction 3 b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b e1 e6 e6 e2 e3 e6 e6 e3 e4 e4 e3 e3 e4 e4 e3 e5 e5 e3 e2 e3 e5 e5 e3 e4 e6 e4 e4 e6 e4 e5 e3 e3 e5 e2 e3 e3 e6 = e3 ⊕ e4 ⊕ e5 (d) Construction 4 b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b e5 e1 e5 e2 e4 e4 e5 e3 e3 e3 e3 e5 e6 e6 e2 e6 e6 e5 e4 e4 e4 e4 e5 e3 e3 e2 e6 = e3 ⊕ e4 ⊕ e5 (e) Construction 5 b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b e1 e6 e6 e2 e4 e6 e6 e4 e3 e5 e4 e4 e5 e3 e6 e3 e3 e6 e2 e6 e3 e3 e6 e3 e4 e5 e5 e4 e3 e5 e6 e6 e5 e2 e6 e6 e6 = e3 ⊕ e4 ⊕ e5 (f) Construction 6 Figure 2.5 – Six schémas de transitions pour générer des 32-QAM quasi-Gray. Les traits en pointillés signifient que toute la ligne, ou toute la colonne, est construite avec la même transition 202.6 Mappings quasi-Gray Pénalité de Gray Nous pouvons calculer pour chacun des schémas présentés ici la pénalité de Gray moyenne. Ainsi pour la méthode de la Figure 2.4 la pénalité moyenne est de 7 6 : A B D′ C ′ E I M Q U Y F J N R V Z G K O S W A′ H L P T X B′ D C E′ F ′ A E I M Q U Y C ′ B F J N R V Z D′ C G K O S W A′ E′ D H L P T X B′ F ′ Avec les notations précédentes, les points J, N, R, V , K, O, S, W puis E, F, G, H, Y , Z, A′ , B′ ont une pénalité moyenne de 1. En effet, ils respectent le critère de Gray. Les points A, C ′ , D et F ′ont une pénalité de 3 2 , les points B, D′ , C, E′ ont une pénalité de 4 3 et enfin les points restants ont une pénalité de 5 4 . La pénalité moyenne est donc de 7 6 . De la même manière, il est possible de calculer les pénalités de Gray pour les autres méthodes de construction, elles sont données par la Table 2.2 Figure 2.5a 2.5b 2.5c 2.5d 2.5e 2.5f 2.4 Gp 19 16 9 8 17 16 118 96 110 96 71 48 7 6 Gk p 3 3 3 3 3 3 2 Table 2.2 – Pénalité de Gray de mappings 32 − QAM Mappings 128 − QAM Nous présentons ici deux types de mappings quasi-Gray pour les constellations 128 − QAM cruciformes. Ces deux méthodes se basent sur la modification de mappings Gray rectangulaires. La seconde méthode est issue des travaux de P.K. Vitthaladevuni, M.S. Alouini et J.C. Kieffer [52]. Elles sont données par la Figure 2.8 et la Figure 2.9. 21Chapitre 2. Mappings b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b bb b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b bbb b bbbb b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b (1) (2) (3) (4) b b b b b b b b b b b b b b b (3) (4) (1) (2) Figure 2.8 – Construction d’un mapping 128 − QAM par la méthode de Wesel & al. b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b bb b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b bbb b bbbb b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b (1) (2) (3) (4) b b b b b b b b b b b b b b b (1) (2) (3) (4) (5) (6) (7) (8) (5) (6) (7) (8) Figure 2.9 – Construction d’un mapping 128 − QAM par la méthode de Vitthaladevuni & al. La pénalité de Gray du mapping présenté Figure 2.9 est donnée dans [52] est vaut 1 + 1 √ 2 ∗ 128 + 1 3 ∗ 128 ≃ 1.0651 Ces méthodes s’étendent au cas des constellations 512 − QAM. Dans la suite de ce travail nous utilisons les mappings quasi-Gray définis à partir de mappings Gray rectangles. Elles sont efficaces dans le sens où elles nécessitent peu de transformations alors que nous sommes déjà en mesure de générer les mappings Gray rectangulaires. 22Chapitre 3 Codes Convolutifs et Codes de Reed-Solomon Ce chapitre introductif a pour objectif de donner des notions de théorie des codes. Notamment nous présentons ce que sont les codes convolutifs et les codes de Reed-Solomon. Ces deux types de codes sont ceux utilisés dans le Chapitre 6 pour la reconnaissance du mapping bien que nous nous soyons essentiellement concentrés sur le cas des codes convolutifs. Nous présentons en effet de plus une méthode de détection des codes convolutifs dans le Chapitre 4. 3.1 Introduction aux codes correcteurs d’erreurs Les codes correcteurs d’erreurs sont des systèmes visant à réduire les erreurs de transmission. Le codage de l’information binaire à transmettre, par ce type de systèmes, permet d’ajouter de la redondance ; c’est-à-dire que l’on transmet plus de données que la quantité d’informations initiale. La redondance introduite est utilisée lors de la réception des données afin de détecter et corriger les erreurs de transmission. Il existe deux grandes familles de codes : les codes en blocs et les codes convolutifs. Pour chacune de ces deux familles, l’information est séparée en blocs de taille constante k appelés mots d’information. Les blocs obtenus par codage de ces mots d’informations sont appelés des mots de code. On note u = (u1, . . . , uk), ui ∈ Fq, un mot d’information et y = (y1, . . . , yn), yi ∈ Fq, le mot de code associé où n > k. On appelle n la longueur du code. Codes en blocs Nous allons à présent voir des exemples de codes en blocs et les premières définitions de codes, notamment de codes dits linéaires. Un exemple de code : le code à répétition Le principe du code à répétition est simplement de répéter un certain nombre de fois n chacun des bits du message à transmettre. Pour n = 3 le message 0110 devient 000111111000. Si une erreur se produit lors de la transmission alors on retrouvera le message initial par vote majoritaire. Cette méthode permet de corriger toutes les erreurs de poids 1 (un seul bit sur les trois répétés est faux). Ce code a l’avantage de pouvoir corriger autant d’erreurs que l’on souhaite en augmentant le nombre de répétition, mais le nombre de bits à transmettre est alors trop important. Pour n = 3 si le message à transmettre est de longueur m alors le message codé sera de longueur 3m. 23Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon On définit le rendement d’un code par le ratio k/n où k est la longueur des mots d’informations et n celle des mots de code. Dans l’exemple du code à répétition k = 1 et n = 3. On définit la distance minimale d’un code, noté d, comme la plus petite distance séparant deux mots de code (pour la distance de Hamming). Le code à répétition a pour distance minimale d = n. La question du décodage est liée à la notion de capacité de correction, c’est-à-dire pour un code donné, combien d’erreurs est-on en mesure de corriger. Soit C un code de longueur n, dont la longueur des mots d’informations est k et de distance minimale d. Soit y = (y1, . . . , yn), yi ∈ Fq un mot de code. Lors de la transmission du signal, ce mot de code peut être modifié. Le mot reçu s’écrit alors y ′ = y + e où e correspond à l’erreur ajoutée. On appelle décodage par maximum de vraisemblance le décodage qui consiste à associer à y ′ le mot de code y le plus proche (au sens de la distance de Hamming). Alors on peut décoder de manière unique tous mots reçus ayant au plus t = ⌊ d−1 2 ⌋ erreurs. t est appelé la capacité de correction. L’objectif de la théorie des codes est de définir des codes assurant à la fois de bon taux de transmission et de bonnes capacités de correction. Un exemple de code : le code de Hamming Soit G =   1 0 0 0 0 1 1 0 1 0 0 1 0 1 0 0 1 0 1 1 0 0 0 0 1 1 1 1   . Le code défini par l’ensemble des y = uG, avec u = (u1, u2, u3, u4), ui ∈ F2, a pour longueur 7, des mots d’informations de longueur 4 et une distance minimale de 3. Il a donc pour capacité de correction t = 1, pour un rendement de 4 7 . Il est ainsi un code de même distance minimale que le code à répétition mais a un meilleur rendement. Le code de Hamming présenté ici est défini par une matrice G de taille k × n, à coefficients dans F2, que l’on appelle une matrice génératrice. Il peut également être défini par une matrice dite de parité, notée H, de taille (n − k) × n, à coefficients dans F2, telle que GH⊤ = 0k×(n−k) . Alors, pour tout mot de code y de C on a yH⊤ = 0. On peut ainsi déterminer l’appartenance d’un mot à un code en connaissant une matrice de parité. Nous nous attachons maintenant à définir les notions de code, matrice génératrice et matrice de parité pour les codes dit linéaires. Définition 3.1.1 (Code) Un code C sur Fq de longueur n est un sous-ensemble de F n q Définition 3.1.2 (Code linéaire) Un code linéaire C sur Fq de longueur n et de dimension k est un sous-espace vectoriel de F n q de dimension k. On écrit [n, k, d]q les paramètres d’un code linéaire C de longueur n, dimension k, et distance minimale d défini sur Fq et [n, k, d] lorsque qu’il n’y a pas d’ambiguïté sur le corps de base. Définition 3.1.3 (Matrice génératrice) Une matrice génératrice d’un code linéaire C est une matrice dont les vecteurs lignes forment une base de C . 243.2 Codes cycliques Une matrice génératrice n’est donc pas unique et un code possède autant de matrices génératrices que de bases. Définition 3.1.4 (Code dual) Soit C une code linéaire de longueur n et dimension k. On note C ⊥ le code dual de C tel que C ⊥ = {y ∈ F n q | uy = 0, ∀u ∈ C } où uy = Pn i=1 uiyi , ui , yi ∈ Fq Lors de l’utilisation d’un code en bloc, chaque mot d’information est codé indépendamment des autres. Le mot de code y dépend uniquement du mot d’information u. On définit la fonction de codage pour les codes en blocs comme l’application linéaire injective φ : F k q → F n q qui à un mot d’information u associe un mot de code y = φ(u). On peut d’ailleurs définir un code en bloc comme l’ensemble des mots de code y = uG où G est une matrice de l’application φ dans une base donnée. D’autre part, lorsque l’on dispose d’une séquence binaire à coder, cette dernière est décomposée en blocs de taille k qui seront codés pour former des blocs de taille n, constituant ainsi la séquence codée. On note alors respectivement uj et yj les mots d’informations et de codes obtenus au temps j. On obtient donc la relation suivante : yj = ujG. Lorsque les séquences d’informations et les séquences codées sont vues comme des séquences infinies, on écrit U(D) = P j≥0 ujDj où D est une variable indéterminée et uj = (u0, . . . , uk)j = (u0,j , . . . , uk,j ). On a alors Y (D) = U(D)G avec Y (D) = P j≥0 yjDj . 3.2 Codes cycliques Soient c = (c0, c1, . . . , cn−1) appartenant à F n q et c ′ = (cn−1, c0, . . . , cn−2) le décalé de c. Un code de longueur n est dit cyclique si pour tout mot de code c = (c0, c1, . . . , cn−1) son décalé c ′ = (cn−1, c0, . . . , cn−2) est aussi un mot de code. Ce qui implique que (cn−2, cn−1, c0, . . . , cn−3), (cn−3, cn−2, cn−1, . . . , cn−4) et ainsi de suite sont aussi des mots de code. Pour les mots de codes d’un code cyclique on adopte usuellement l’écriture suivante c(x) = c0 + c1x + · · · + cn−1x n−1 D’où c ′ (x) = cn−1 + c0x + · · · + cn−2x n−1 D’autre part xc(x) = c0x + c1x 2 + · · · + cn−1x n = cn−1(x n − 1) + (c0x + c1x 2 + · · · + cn−2x n−1 + cn−1) et xc(x) mod (x n − 1) = cn−1 + c0x + · · · + cn−2x n−1 donc c ′ (x) = xc(x) mod (x n − 1) De même, si c est décalé de deux rangs vers la droite, on obtient (cn−2, cn−1, c0, . . . , cn−3), ce qui correspond à x 2 c(x) mod (x n − 1). C’est également vrai pour les décalés suivants. 25Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon L’ensemble des opérations sur c(x) se fait alors dans l’anneau quotient Fq[x]/(x n−1) et on identifie F n q à Fq[x]/(x n − 1). En montrant que C est un idéal de cet anneau, on obtient alors l’existence d’un unique polynôme unitaire g(x) de degré minimal et tel que g(x) est un générateur de C . De plus g(x) divise x n −1 dans Fq[x]. Notons r le degré de g(x) = g0 + g1x + · · · + grx r . Ce polynôme g(x) est un générateur du code alors tout mot de code c(x) est un multiple de g(x), c’est-à-dire c(x) = m(x)g(x) avec m(x) = m0 +m1x+· · · +mk−1x k−1 . Le code est de dimension k et {g(x), xg(x), x2 g(x), . . . , xk−1 g(x)} est une base de C . Le polynôme c(x) = m(x)g(x) de degré inférieur ou égal à n − 1 s’écrit : c(x) = m0g(x) + m1xg(x) + · · · + mk−1x k−1 g(x) ce qui se représente sous la forme matricielle suivante :  m0 m1 . . . mk−1    g(x) xg(x) . . . x k−1 g(x)   ou encore  m0 m1 . . . mk−1    g0 g1 . . . gr g0 g1 . . . gr . . . . . . . . . g0 g1 . . . gr   Cette matrice de taille k × n est une matrice génératrice de C . D’autre part soit h(x) tel que g(x)h(x) = x n − 1 alors H(n−k)×n =   hk hk−1 . . . h0 hk kk−1 . . . g0 . . . . . . . . . hk hk−1 . . . h0   est une matrice génératrice du dual où h(x) = h0 + h1x + · · · + hk−1x k−1 Codes cycliques raccourcis Soit C ′ le sous-ensemble de C composé de l’ensemble des mots de code c ′ (x) tels que c ′ (x) = m(x)g(x) avec m(x) = m0 + m1x + · · · + mk−i−1x k−i−1 et i un entier positif. C’est-à-dire m =  m0 m1 . . . mk−i−1 0 . . . 0  . Alors C ′ est un code de dimension k − i et de longueur n − i. Un tel code est dit raccourci. 263.2 Codes cycliques Codes Reed-Solomon Les codes Reed-Solomon font partie des codes cycliques les plus utilisés, ils permettent de corriger les erreurs se produisant par paquets. Il ont été inventés en 1960 par Reed et Solomon. Nous supposons à présent que n est premier avec q. Il existe deux façons de décrire un code de Reed-Solomon. La première que nous donnons est la première définie historiquement et permet de donner des résultats théoriques, la seconde est cependant utilisée pour décrire des codeurs et décodeurs de ces codes. Définition 3.2.1 Soient α un élément primitif de Fqm, n = q m − 1 et m(x) = m0 + m1x + · · · + mk−1x k−1 ∈ Fqm[x] un mot d’information sous forme polynomiale. Soit φ : m(x) → c tel que c = (c0, c1, . . . , cn−1) =  m(1), m(α), m(α 2 ), . . . , m(α n−1 )  Le code de Reed-Solomon de longueur n = q m −1 et de dimension k sur Fqm est l’ensemble des images, par φ, des polynômes de degré inférieur ou égal à k − 1 à coefficients dans Fqm. La seconde construction se rapproche de celle des codes BCH (ils doivent leur nom à Bose, Chaudury et Hocquenghem) que nous allons évoquer à présent. Rappelons que le polynôme minimal d’un élément de Fqm est le polynôme (non nul) de plus faible degré dont il est racine. De plus les éléments admettant le même polynôme minimal sont dits conjugués. Un polynôme primitif est un polynôme minimal dont au moins une racine est un élément primitif de Fqm. Un code BCH de longueur n capable de corriger au moins t erreurs se construit selon la procédure suivante : Prendre m le plus petit entier tel que Fqm a une racine n-ième primitive α. Choisir un entier b positif (souvent b = 1). Déterminer ensuite les polynômes minimaux de α b , αb+1, . . . , αb+2t−1 à coefficients dans Fq. Le polynôme générateur g(x) du code est le plus petit multiple commun de ces polynômes minimaux. Ainsi, les coefficients de g(x) sont dans Fq ainsi que les mots du code tandis que les racines de g(x) sont elles dans Fqm. De plus, certains des α i sont potentiellement conjugués donc g(x) est de degré au plus 2t. Le code ainsi construit est un code de longueur n, de dimension n − deg g(x) et de distance minimale supérieure ou égale à δ = 2t + 1. Les α b , αb+1, . . . , αb+2t−1 sont par définition racines de leur polynômes minimaux respectifs et sont alors racines de g(x) sur Fqm. Donc pour tout α i , (i = b, b + 1, . . . , b + 2t − 1 ), g(α i ) = 0 et par conséquent c(α i ) = m(α i )g(α i ) = 0. Ceci se traduit par c0 + c1α i + c2(α i ) 2 + · · · + cn−1(α i ) n−1 = 0, ∀i = b, b + 1, . . . , b + 2t − 1 27Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon Donc  c0 c1 . . . cn−1    1 α i (α i ) 2 . . . (α i ) n−1   = 0 et H =   1 α b (α b ) 2 . . . (α b ) n−1 1 α b+1 (α b+1) 2 . . . (α b+1) n−1 . . . . . . . . . . . . 1 α b+2t−1 (α b+2t−1 ) 2 . . . (α b+2t−1 ) n−1   est également une matrice génératrice du dual. Passons à présent aux codes de Reed-Solomon. Dans Fqm le polynôme minimal d’un élément α est égal à (x − α). Un tel code prend comme polynôme générateur g(x) = (x − α b )(x − α b+1)· · ·(x − α b+2t−1 ). g(x) est alors de degré exactement 2t. Donc n − k = 2t. Et le code est en mesure de corriger t erreurs. Un exemple de code Reed-Solomon : Nous décrivons ici un code de longueur 15 et de dimension 9 sur F2 4 . Ce code est en mesure de corriger 3 erreurs. De plus F2 4 est identifié à F2[x]/(x 4+x+1). Soit α dans F2 4 une racine de x 4 + x+ 1. Nous avons α 15 = 1. On peut d’autre part décrire l’ensemble des puissances successives de α. En effet α 4 = α + 1 puisque α est racine de x 4 + x + 1. Ensuite α 5 = α 2 + α. Les puissances suivantes se calculent de la même manière et dépendent uniquement de 1, α, α 2 et α 3 . On peut donc en donner une représentation vectorielle dans cette base. Les 7 premières puissances sont données dans le tableau ci-dessous : Puissance de α Représentation dans la base Représentation vectorielle 1 1 (1, 0, 0, 0) α α (0, 1, 0, 0) α 2 α 2 (0, 0, 1, 0) α 3 α 3 (0, 0, 0, 1) α 4 α + 1 (1, 1, 0, 0) α 5 α 2 + α (0, 1, 1, 0) α 6 α 3 + α 2 (0, 0, 1, 1) et α est bien un élément primitif de F2 4. Prenons b = 1, on a n = 15 et k = 9 donc 2t = 6 et g(x) = (x − α)(x − α 2 )(x − α 3 )(x − α 4 )(x − α 5 )(x − α 6 ). L’avantage de tels codes est que l’on maîtrise très bien la capacité de correction. De plus, les codes définis sur F2 8 sont souvent utilisés du fait de leur praticité. En effet, chaque élément de F2 8 se repré- sente dans la base {1, α, . . . α7} sur un octet. Par ailleurs, il est possible de donner des matrices systématiques pour les matrices génératrices de C ainsi que pour C ⊥. En effet, la division euclidienne de x n−k+i par g(x) pour i = 0, 1, . . . , k − 1 283.3 Codes convolutifs donne x n−k+i = qi(x)g(x) + ri(x) avec ri(x) = ri,0 + ri,1x + · · · + ri,n−k−1x n−k−1 . C’est-à-dire x n−k+i − ri(x) = qi(x)g(x) donc x n−k+i − ri(x) est un multiple de g(x) et est aussi un mot de code. Le polynôme ri(x) s’écrit sous forme matricielle  ri,0 ri,1 . . . ri,n−k−1 0 . . . 0  donc x n−k − r0(x) correspond à  −r0,0 −r0,1 . . . −r0,n−k−1 1 0 . . . 0  et on obtient la matrice génératrice suivante : G =   −r0,0 −r0,1 . . . −r0,n−k−1 1 0 0 . . . 0 −r1,0 −r1,1 . . . −r1,n−k−1 0 1 0 . . . 0 . . . . . . . . . . . . −rk−1,0 −rk−1,1 . . . −rk−1,n−k−1 0 0 0 . . . 1   et H =   1 0 0 . . . 0 r0,0 r1,0 . . . rk−1,0 0 1 0 . . . 0 r0,1 r1,1 . . . rk−1,1 . . . . . . . . . . . . 0 0 0 . . . 1 r0,n−k−1 r1,n−k−1 . . . rk−1,n−k−1   Les codes en blocs ont l’avantage d’être largement étudiés et permettent à ce titre des constructions variées. En revanche la complexité de codage et décodage peut varier selon le type de code. Les codes convolutifs sont eux implémentés sous forme de registres à décalage et présentent ainsi l’avantage d’offrir un codage simple et un décodage rapide au fur et à mesure de la réception de l’information. Cependant, ils fournissent généralement de plus faibles capacités de correction. On définit pour les codes convolutifs linéaires la notion de matrice génératrice de manière similaire à la notion de matrice génératrice pour les codes en blocs. Les définitions présentées dans le paragraphe suivant sont essentiellement issues de [38]. Nous parlerons ici uniquement de codes convolutifs linéaires, nous utiliserons donc le terme code convolutif pour signifier code convolutif linéaire. 3.3 Codes convolutifs Lors de l’utilisation d’un code convolutif, le mot de code yj dépend du mot d’information uj mais également des mots d’informations reçus aux instants précédents. yj dépend donc de uj , uj−1, . . . , uj−M où M correspond à la mémoire du codeur. On définit donc la fonction de codage d’un code convolutif comme l’application linéaire injective φ : F k 2 → F n 2 telle que yj = φ(uj , uj−1, . . . , uj−M). Ainsi, 29Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon k n G0 G1 G2 . . . G0 G1 G2 . . . G0 G1 . . . GM GM . . . GM . . . 0k×n 0k×n 0k×n 0k×n G2 Figure 3.1 – Matrice génératrice binaire d’un code convolutif la matrice G de cette application dans une base donnée prendra la forme d’une matrice shiftée infi- nie comme définie par la Figure 3.1 , où chacune des matrices Gi est une matrice binaire de taille k×n. On pourra également décrire la matrice G comme une matrice à coefficients dans F2(D). On note G(D) = G0 +G1D +G2D2 +. . . GM DM, G(D) est alors une matrice de taille k ×n à coefficients dans F2(D). On peut d’ailleurs voir les codes en blocs comme des codes convolutifs de mémoire nulle. On distinguera ici la notion de code et de codeur. Le code est l’ensemble des mots de code tandis que le codeur (ou encodeur) est la réalisation physique de la fonction de codage. D’autre part, la réalisation physique d’une fonction de codage correspond à l’implémentation de registres à décalage. Mais au même titre qu’un code dispose de plusieurs matrices génératrices, il existe différentes réalisations pour un même code généré. Les registres nécessitant le moins de mémoire sont à priori les plus utilisés et donc les plus intéressants du point de vue de la reconnaissance. Nous verrons alors que l’algorithme de reconnaissance de codes convolutifs que nous utilisons dans la suite se propose de retourner une des matrices génératrices correspondant à ces registres. On note alors (n, k) les paramètres d’un codeur convolutif ayant k entrées et n sorties. Nous ne décrirons pas précisément le fonctionnement de cet algorithme mais en donnerons les principales composantes. Cet algorithme sera ensuite pour nous un moyen de discriminer les mappings lors de la reconnaissance de mapping en présence de données codées par un codeur convolutif. Définition 3.3.1 (Code convolutif) Un (n, k) code convolutif C est un sous-espace vectoriel de dimension k de F2(D) n . Définition 3.3.2 (Matrice génératrice) Une matrice génératrice G(D) du code C de paramètres (n, k) est une matrice de taille k × n dont les lignes forment une base de C . Une matrice génératrice d’un code convolutif est donc une matrice à coefficients dans F2(D). On parle de matrice génératrice polynomiale lorsque les coefficients de G(D) appartiennent à F2[D]. On peut écrire U(D) = P j≥0 ujDj avec uj = (u0, . . . , uk)j = (u0,j , . . . , uk,j ) et Y (D) = P j≥0 yjDj . On a alors Y (D) = U(D)G(D). 303.3 Codes convolutifs (u0, u1, . . . , uM, uM+1, . . .) ×   G0 G1 . . . GM 0 . . . G0 G1 . . . GM 0 . . . . . . G0 G1 . . . GM 0 G0 G1 . . . GM . . . . . . . . .   |{z} |{z} |{z} |{z} . . . y0 y1 yM yM+1 Figure 3.2 – Codage d’une séquence par un code convolutif 3.3.1 Représentation binaire Rappelons que du point de vue binaire la séquence codée (composée des mots de code concaténés), notée y0y1 . . . yM . . . est telle que : y0 = u0G0 y1 = u0G1 + u1G0 . . . yM = u0GM + u1GM−1 + · · · + uM G0 yM+1 = u1GM + u2GM−1 + · · · + uM+1G0 où uj est le mot d’information à l’instant j et les Gi les blocs de la matrice génératrice binaire infinie de C présentée précédemment. Remarquons que dès lors que j ≥ M + 1, yj ne dépend plus de u0. En effet la mémoire du codeur est de M et yj = φ(uj , uj−1, . . . , uj−M). Lorsque j = 0, . . . , M − 1 , yj ne dépend pas de tous les Gi (i = 0, . . . , M). Cela constitue une phase d’initialisation. Dès lors que j ≥ M, yj dépend de tous les Gi et la sortie yj est obtenue en effectuant le produit de la séquence d’entrée par la matrice binaire infinie. Nous avons alors : yj = X M i=0 uj−iGi . Ce produit est représenté par la Figure 3.2 31Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon 3.3.2 Équations de parité Soit H =   H0 H1 . . . HM 0 . . . H0 H1 . . . HM 0 . . . . . . . . . H0 H1 . . . HM 0 H0 H1 . . . HM 0 . . . . . .   une matrice duale de C . On a  y0 y1 . . . yM  H0 . . . HM ⊤ = 01×(n−k) . On dit que  y0 y1 . . . yM  vérifie n−k équations de parité. Il en est de même pour  y1 y2 . . . yM+1 ,  y2 y3 . . . yM+2 et ainsi de suite. Les équations de parité s’appliquent à toutes les sous-séquences de longueur n(M + 1) par blocs glissants (avec un décalage de n). 3.3.3 Représentation en série La séquence d’information s’écrit comme étant la série U(D) = X j≥0 ujDj . Notons Y (D) = X j≥0 yjD j . Nous avons alors la relation Y (D) = U(D)G(D) avec G(D) = G0 + G1D + · · · + GMDM. En effet G(D) = G0 + G1D + · · · + GMDM donc   X j≥0 ujD j   G(D) = X j≥0 ujG0D j + X j≥0 ujG1D j+1 + · · · + X j≥0 ujGM D j+M = X j≥0 ujG0D j + X j≥1 uj−1G1D j + · · · + X j≥M uj−MGM D j = u0G0 + (u0G1 + u1G0)D + . . . + (u0GM + u1GM−1 + · · · + uMG0)D M +   X j>M X M i=0 uj−iGi   D j = X j≥0 yjD j = Y (D) 323.3 Codes convolutifs u1,t u2,t s1,t s2,t s3,t y1,t y3,t y2,t Figure 3.3 – Codeur de rendement 2/3 3.3.4 Codeurs Les sorties d’un codeur convolutif dépendent des entrées à différents instants. En termes d’implé- mentation, il faut donc stocker différents états de l’entrée dans des registres. Notons m ce nombre de registres. Les m registres représentent alors l’état interne du codeur, noté sj (sj est un vecteur binaire de taille m). Notons que dans le cas particulier où k = 1 alors m = M. L’entier m est également appelé la longueur de contrainte du codeur. Il est possible de déterminer une matrice génératrice du code C en fonction du vecteur d’entrée uj , du vecteur d’état sj et du vecteur de sortie yj pour un codeur donné. Le vecteur d’état sj dépend de l’état sj−1 à l’instant précédent et de l’entrée uj à l’instant j. La sortie yj dépend de l’entrée uj à l’instant j et de l’état interne sj . L’opération de codage se décrit alors comme suit : sj+1 = sjAm×m + ujBk×m yj = ujUk×n + sjVm×n avec Am×m, Bk×m, Uk×n, Vm×n des matrices binaires et s0 = 01×m. En posant E(D) = B.  D −1 Idm − A −1 nous obtenons Y (D) = U(D) [U + E(D)V ] d’où G(D) = U + E(D)V. 33Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon Nous proposons à présent un exemple de codeur convolutif de rendement 2/3 donné par la Figure 3.3. Notons uj = (u1, u2)j = (u1,j , u2,j ) yj = (y1, y2, y3)j = (y1,j , y2,j , y3,j ) sj = (s1, s2, s3)j = (s1,j , s2,j , s3,j ). Le codage est décrit comme suit : y1,j = u1,j + s3,j y2,j = s1,j + s2,j y3,j = u2,j + s2,j Nous obtenons alors Uk×n = 1 0 0 0 0 1 ! Vm×n =   0 1 0 0 1 1 1 0 0   Am×m =   0 0 1 0 0 0 0 0 0   Bk×m = 1 0 0 0 1 0 ! Et finalement E(D) = D 0 D2 0 D O ! d’où G(D) = 1 + D2 D O 0 D 1 + D ! Nous utilisons également dans ce manuscrit une notation décimale pour représenter les polynômes générateurs dont la représentation en base 2 donne les coefficients des polynômes dans l’ordre décroissant. Dans le cas de l’exemple nous obtenons 5 2 0 0 2 3! . 3.4 Reconstruction de codes La méthode décrite par A. Valembois dans [47] et [48] est actuellement utilisée pour la reconstruction de codes en blocs et de codes convolutifs. Cette méthode permet la reconstruction d’une matrice 343.4 Reconstruction de codes génératrice du dual. Elle s’appuie sur la méthode de Canteaut-Chabaud pour trouver des mots candidats du dual et décide selon un test statistique de leur appartenance au dual. Il existe de plus des méthodes spécifiques au type de codes recherchés. En effet, connaître une matrice binaire du dual n’est pas suffisant pour le décodage. Il faut d’une part retrouver une matrice génératrice du code puis en extraire la structure algébrique. B. Rice a initié des travaux sur la reconnaissance des codes convolutifs (n, 1) dans le cas non bruité dans [41]. E. Filiol a ensuite proposé une méthode de reconstruction des codes convolutifs lorsque les données observées sont bruitées dans [28] et [27]. Puis une méthode algébrique a été donnée par J. Barbier, G. Sicot et S. Houcke dans [5], elle est ensuite détaillée dans la thèse de J. Barbier [3]. De nombreuses autres études ont depuis été menées sur la reconstruction des codes convolutifs dont [14, 21, 24, 33, 35–37, 53, 59–61] 3.4.1 Codes Convolutifs Soit C un code tel que les polynômes générateurs soient premiers entre eux et de longueur de contrainte m. Le codeur utilisé nécessite m bits pour remplir ses registres. Une séquence d’information de taille ks + m s’envoie sur une séquence codée de taille ns. Soit Cs cette restriction : Cs : F ks+m 2 → F ns 2 Le théorème suivant, issue de [14], donne le rang de l’application Cs en fonction de s et montre qu’à partir de s > km n−k toutes les séquences de taille ns ne correspondent pas à une séquence codée. Le critère du rang est à la base de la plupart des résultats sur la reconnaissance de codes convolutifs. Théorème 3.4.1 Soit s ∈ N ∗ . Soit Cs : F ks+m 2 → F ns 2 l’application linéaire obtenue par restriction. Si tous les polynômes générateurs sont premiers entre eux alors rang(Cs) = ( ns si s ≤ km n−k k(s + m) si s ≥ km n−k Il en découle que la matrice dont les lignes sont des séquences codées de taille ns n’est pas de rang plein lorsque s > km n−k . Ce défaut de rang peut alors s’identifier par un pivot de Gauss. Malgré tout, lorsque la séquence observée est bruitée, cette méthode n’est plus envisageable. Les alternatives sont alors de chercher des plages non bruitées, d’utiliser une méthode appelée Gauss randomisé issue des travaux de G. Sicot et S. Houcke [42, 43] qui est applicable pour de faibles taux d’erreur ou encore d’utiliser la méthode introduite par A. Valembois [47, 48]. M. Cluzeau dans [15] a également repris et fait évoluer l’approche proposée par A. Valembois L’algorithme de reconnaissance de codes convolutifs linéaires dont nous disposons (issu de [20, 21]) utilise la méthode de A. Valembois et se propose alors de retourner une matrice génératrice correspondant à un codeur minimisant le nombre de registres nécessaires à l’implémentation, lorsque la séquence binaire observée est une séquence codée et bruitée. Cet algorithme retourne alors une matrice génératrice parmi les matrices génératrices polynomiales (à coefficients F2[D]) appelée une matrice canonique 35Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon (voir [20, 38]). Nous allons à présent décrire dans les grandes lignes le fonctionnement de cet algorithme. A partir d’une séquence, codée et bruitée, tronquée, nous cherchons à retrouver une matrice gé- nératrice du code utilisé ainsi que le taux d’erreur associé. Nous ne connaissons ni n (la longueur du code) ni k (la dimension du code), et effectuons alors cette recherche également. Nous avons vu précédemment que pour un mot observé, nous disposons d’un critère d’appartenance au code C utilisé ; à savoir y ∈ C si et seulement si yH⊤ = 01×(n−k) avec H une matrice génératrice du dual de C et si et seulement si pour tout h ∈ C ⊥ on a yh = 0 Cet algorithme procède en 3 étapes principales. Le premier objectif est de trouver une matrice gé- nératrice du dual de C , noté H, autrement appelée matrice de parité. Il utilise pour cela l’algorithme de A. Valembois et la méthode de Canteaut-Chabaud. Cette recherche s’effectue à partir d’une matrice formée de mots issus de la séquence observée. La séquence observée étant bruitée, cette première étape permet de sélectionner des mots du dual non bruités. La seconde étape utilise alors ces mots du dual non bruités pour reconstruire le dual du dual, à savoir une matrice génératrice du code lui-même. La dernière étape a pour but d’extraire une matrice canonique de la matrice reconstruite à l’étape 2. A ces étapes se rajoutent (entre la première et la deuxième étape) une étape de recherche de la longueur n du code et en fin d’algorithme une étape de recherche du taux d’erreur. La recherche du taux d’erreur consiste à décoder la séquence observée par l’algorithme de Viterbi avec la matrice génératrice retournée par l’algorithme de reconnaissance de codes. Première étape : Reconstruction d’une matrice H du dual de C Nous disposons d’une séquence observée S à partir de laquelle nous formons une matrice R˜ de la manière suivante : la séquence est découpée en blocs de taille n(m + 1) (quitte à itérer sur la taille des blocs lorsque ces paramètres sont inconnus), chacun de ces blocs constitue une ligne de R˜. Si R˜ n’est pas une matrice bruitée : pour h ∈ C ⊥, alors Rh˜ ⊤ vaut 0. C’est-à-dire h appartient au noyau de R˜. Si R˜ est bruitée : pour h ∈ C ⊥, alors Rh˜ ⊤ est de poids faible. L’algorithme de recherche de mots de poids faibles de Canteaut-Chabaud permet alors de retrouver des h candidats et l’algorithme de A. Valembois permet de décider s’ils appartiennent ou non à C ⊥ selon le poids de Hamming de Rh˜ ⊤ et de h. En sortie de cette première étape, nous disposons alors de mots du dual. Le produit d’une ligne de R˜ par h détermine une équation de parité. M. Côte et N. Sendrier [20] utilisent alors ces mots du dual h pour former une seconde matrice, que l’on notera R et reconstituer une matrice génératrice du dual. Cette reconstruction se base sur une élimination de Gauss. En effet, une application de l’élimination de Gauss sur la matrice R la transforme en une matrice de forme particulière dans laquelle il est possible d’identifier un bloc minimal : 363.4 Reconstruction de codes c’est-à-dire un ensemble de lignes et de colonnes adjacentes engendrant le sous-espace vectoriel décrit par R. Ce bloc, noté H, engendre C ⊥. Deuxième étape : Reconstruction d’une matrice génératrice de C à partir du dual Cette étape consiste à retrouver le dual du dual de C, c’est-à-dire à retrouver le code lui-même. La matrice H précédemment reconstituée est utilisée pour former une nouvelle matrice H′ sur laquelle est pratiquée également une élimination de Gauss afin de trouver le bloc minimal, noté G, engendrant le sous-espace vectoriel décrit par H′ . Troisième étape : Reconstruction d’une matrice génératrice polynomiale canonique de C Après utilisation d’algorithmes de basicité et réduction [20] sur la matrice G reconstruite à l’étape 2, une matrice G(D) polynomiale canonique de C est fournie. Les étapes présentées ici reposent sur le fait que la longueur n soit connue. N. Sendrier propose d’appliquer la méthode de Canteaut-Chabaud et l’algorithme de A. Valembois à une matrice R˜ pour quelques longueurs de blocs bien choisies de telle sorte que cette longueur puisse être un multiple de la longueur n du code. D’autre part, le calcul de wH(Rh˜ ⊤) fournit une indication sur le taux d’erreur potentiel du canal. Il est alors possible de distinguer la plus petite longueur de code fournissant pour l’ensemble des mots du dual un faible taux d’erreur. Cette longueur est la longueur n du code C . Cet algorithme de reconnaissance de codes convolutifs permet d’effectuer une reconnaissance de codes lorsque la séquence observée est bruitée. Des tests de résistance au bruit ont été effectués dans [20]. Il permet de plus d’effectuer cette recherche à paramètres inconnus. Cette méthode fournit également le taux d’erreur du canal en appliquant un décodage de la séquence observée. 3.4.2 Codes Reed-Solomon La difficulté de la reconstruction des codes de Reed-Solomon réside dans la recherche de la structure algébrique. En effet il existe des méthodes de reconstruction de codes en blocs permettant de reconstruire une base du code dual et ainsi de reconstruire une base du code. Il est possible notamment d’effectuer un pivot de Gauss sur une matrice contenant les données observées, de faire appel à le méthode de Gauss randomisé ou enfin d’utiliser la méthode A. Valembois ou de M. Cluzeau. Cependant ce n’est pas suffisant pour caractériser un code de Reed-Solomon. Les méthodes énoncées plus haut offrent la possibilité de reconstruire une base du code vu sous forme binaire mais ne permettent pas de donner la structure algébrique du code. Pour cela il existe des techniques spécifiques au type de code utilisé. L’algorithme de V.M. Sidelnikov et S.O. Shestakov [44] répond à ce problème pour les codes de Reed-Solomon. Il prend en entrée une matrice de taille génératrice k × n, contenant des éléments de Fq, mise sous forme systématique. Nous avons vu que la matrice systématique d’un tel code dispose d’une forme particulière, ceci permet d’écrire un ensemble d’équations qui après résolution fournissent les paramètres du code. Cet algorithme fonctionne de plus lorsque les coordonnées du code ont été permutées. Nous verrons que dans notre cas ce point fort sera à notre désavantage. Aussi nous utiliserons finalement un algorithme moins performant qui sera évoqué ultérieurement. 37Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon 38Chapitre 4 Signature de codes convolutifs et recherche du dual par tests statistiques Lors de l’étude d’un système de communication et de la partie codage canal qui le compose, nous souhaitons avant toute chose identifier la famille de codes utilisée, voire les paramètres du code. En effet, ces informations permettent respectivement d’utiliser un algorithme de reconnaissance de code approprié et d’accélérer la recherche. Nous nous intéressons alors dans ce chapitre à une méthode permettant de distinguer si une séquence observée est aléatoire ou codée par un codeur convolutif. Cette technique possède notamment l’avantage de fonctionner lorsque le mapping utilisé est inconnu. Elle permet alors de distinguer la longueur d’un code convolutif sans connaissance du mapping. De plus nous étendons cette méthode à une méthode de reconstruction du dual d’un code convolutif lorsque le mapping est connu. Nous appelons signature un biais observé via un test statistique, appliqué à une séquence codée et bruitée, permettant d’identifier l’utilisation d’un code correcteur d’erreurs. Nous supposons dans la suite que nous disposons d’une séquence codée éventuellement bruitée. Christophe Chabot [14] s’est intéressé à divers tests statistiques, dédiés aux générateurs pseudo-aléatoires, comme la série de test du NIST (National Institute of Standards and Technology) [1] . Ces tests ont été expérimentés dans le cadre de l’identification de séquences codées et bruitées par des codes en blocs, des codes convolutifs et des turbo-codes. Le résultat de ces tests a montré que les codes en blocs ne sont en général pas identifiables de cette façon sauf pour de petites longueurs et dimensions non réalistes. Cependant, le test de compression de Lempel-Ziv (méthode de compression par dictionnaire) s’est révélé adapté pour l’identification de codes convolutifs et turbo-codes et ce dans un contexte bruité également. Nous nous intéressons cependant dans la suite de ce chapitre aux codes convolutifs uniquement. Christophe Chabot s’est alors intéressé à d’autres méthodes de compression comme la compression utilisée dans bzip2, faisant appel à la transformée de Burrows-Wheeler [11]. Les meilleurs taux de compression étant obtenus avec bzip2, il a défini un test statistique basé sur le calcul du nombre de runs (séquences maximales de bits identiques) dans une séquence codée après application de la transformée de Burrows-Wheeler. Ce test permet l’identification des paramètres d’un code convolutif. Il existe également un test dit de profondeur permettant d’obtenir la longueur de contrainte d’un code convolutif de longueur 2. 39Chapitre 4. Signature de codes convolutifs et recherche du dual par tests statistiques Il est clair que les codes convolutifs offrent l’avantage d’être de petites longueurs n et dimensions k (pour que le décodage en treillis soit possible), et de degré d compris typiquement entre 2 et 10. Les objets que nous manipulons sont donc de tailles bien inférieures à celles nécessaires pour des codes en blocs. La méthode de détection que nous définissons dans ce chapitre s’applique en théorie pour des codes en blocs mais elle n’est cependant applicable en pratique que pour de petits codes et est donc particulièrement adaptée pour la détection des codes convolutifs. C’est pourquoi nous nous intéressons à ce type de code dans ce chapitre. Dès lors que nous observons une équation de parité sur une séquence, l’espace ambiant n’atteint pas l’ensemble de toutes les séquences possibles. Pour un code de longueur n et de degré maximum d, les séquences de taille t = n(d + 1) sont au nombre de 2t−1 au plus contre 2t pour une séquence aléatoire. En effet il existe au moins un bit de redondance donc au moins un bit est entièrement déterminé par les autres. Les tests qui sont décrits dans ce chapitre utilise ce phénomène. Nous l’utilisons également en définissant un test basé sur le comptage de blocs de taille t dans une séquence codée et bruitée. En itérant sur la taille des blocs, nous pouvons observer une diminution du nombre de blocs possibles sur certaines longueurs. Nous effectuons de plus cette mesure par comptage de collisions. Nous observons alors une probabilité de collisions différente pour des données codées et des données aléatoires. L’utilisation de blocs glissants permet de plus de caractériser la présence d’un code de type convolutif. Cette méthode autorise également la reconnaissance des paramètres du code utilisé dans un contexte bruité. Nous savons par ailleurs grâce au paradoxe des anniversaires que seulement 2t/2 blocs environ sont nécessaires à l’observation de collisions. Nous définissons ensuite une méthode de reconstruction du dual par comptage de collisions en poinçonnant la séquence observée de manière adéquate. Nous verrons enfin que la signature d’un code convolutif peut se détecter sans connaissance a priori du mapping utilisé. Ce qui offre un avantage considérable pour la reconnaissance de système de communication. En effet nous sommes en mesure grâce à ce test de déterminer la longueur du code convolutif utilisé sans avoir reconnu le mapping utilisé. Ceci permettra alors d’effectuer la recherche du mapping avec une information non négligeable sur le code à rechercher. La reconnaissance du mapping est l’objet du Chapitre 6. Cependant ce travail sur la détection de codes convolutifs a été effectué ultérieurement au travail sur la reconnaissance du mapping et n’a donc pas pu être utilisé alors. L’estimation du cardinal d’un observable, tout en minimisant la quantité de mémoire utilisée, est un défi primordial pour l’analyse de trafic internet par exemple. Marianne Durand s’intéresse dans sa thèse [26] à divers algorithmes d’estimation de cardinal. Nous n’avons pas exploré ces possibilités pour estimer la cardinalité d’une séquence codée vue par blocs mais il serait intéressant d’étudier l’efficacité de ces algorithmes dans le contexte de la reconstruction de codes. 404.1 État de l’art 4.1 État de l’art 4.1.1 Test de profondeur Le test de profondeur décrit dans [31] s’applique au cas d’un code convolutif de longueur 2 et donc de dimension 1. Dans ce cas la longueur de contrainte du code coïncide avec d + 1 où d est le degré maximum du code. Soit C tel que P1 et P2 soient des polynômes générateurs. Le codeur utilisé nécessite M bits pour remplir ses registres. Une séquence d’information de taille s + m s’envoie sur une séquence codée de taille 2s. Soit Cs cette restriction : Cs : F s+m 2 → F 2s 2 Le théorème suivant est à la base de la plupart des résultats sur la reconnaissance de codes convolutifs. Il donne en effet le rang de l’application Cs en fonction de s et montre qu’à partir de s > m toutes les séquences de taille 2s ne correspondent pas à une séquence codée. Théorème 4.1.1 ?? Soit s ∈ N ∗ . Soit Cs : F s+m 2 → F 2s 2 l’application linéaire obtenue par restriction. Si pgcd(P1,P2)=1 alors Cs est surjective ⇔ s ≤ m Cs est injective ⇔ s ≥ m et rang(Cs) = ( 2s si s ≤ m s + m si s ≥ m Dès lors que s > m, Cs est injective et non surjective, on cherche donc le plus petit s tel que Cs+1 n’est pas surjective. Il existe des séquences de longueur 2s qui ne sont pas des séquences codées dans ce cas. La distribution de ces séquences n’est pas uniforme lorsque s > m Le test de profondeur consiste alors à choisir un nombre significatif de séquences de longueur 2s (s peut être initialisé à 2). Pour chaque bloc de taille 2, on regarde la probabilité d’apparition des 2 bits suivants. Si la répartition est uniforme, on incrémente s de 1 sinon s correspond à la longueur de contrainte du code. Ce test est applicable pour un canal binaire symétrique de probabilité d’erreur allant jusqu’à 0,05. 4.1.2 Test de Burrows-Wheeler et Runs La transformée de Burrows-Wheeler effectue un arrangement sur les données tel que les motifs récurrents d’une séquence observée entraînent des suites de bits identiques en sortie de la transformée. Cette modification de la séquence facilite ensuite la compression par dictionnaire. Elle est ainsi utilisée dans bzip2. Les compressions obtenues en appliquant la transformée de Burrows-Wheeler à une séquence codée indiquent que le taux d’erreur et les paramètres de longueur de contrainte sont identifiables. Christophe Chabot a donc élaboré un test basé sur la transformée de Burrows-Wheeler et une Pvalue mesurant la variation entre le nombre de runs observés et le nombre de runs théoriques pour une séquence aléatoire. 41Chapitre 4. Signature de codes convolutifs et recherche du dual par tests statistiques Il a de plus remarqué que pour des séquences de longueur donnée, générées par des codes de paramètres n, k et m, les Pvalue observées sont identiques quel que soit le code de même paramètres utilisé (codes non dégénérés) et sont fonction du taux d’erreur du canal. Il obtient ainsi des courbes types pour différents paramètres. Ces courbes sont de plus toutes distinctes. Lorsque que la Pvalue observée correspond à plusieurs courbes, on peut augmenter artificiellement le bruit jusqu’à identifier une seule courbe. Ceci donne alors n, k et m ainsi que le taux d’erreur initial. Nous pouvons également tester le calcul de l’entropie sur une séquence codée lue par blocs de taille t. Lorsque t atteint la longueur nécessaire pour disposer d’une équation de parité, l’entropie calculée vaut bien t − 1. Les tests que l’on vient de voir se basent sur le fait que le cardinal des motifs observés lorsque l’on regarde une séquence codée lue par blocs de taille t ne vaut pas 2t lorsque l’on dépasse une certaine taille de blocs. Donc, pour mesurer cette diminution du nombre de motifs possibles, à partir d’un certain rang, il faut effectuer un comptage sur ces motifs. Mais l’inconvénient est la taille des données nécessaires pour obtenir ce résultat. C’est pourquoi nous nous sommes intéressés ensuite à élaborer une mesure de ce cardinal par comptage de collisions. Ce test repose alors sur le paradoxe des anniversaires. 4.2 Test de collisions L’objectif de ce chapitre est de décrire dans un premier temps une méthode de reconnaissance des paramètres d’un code convolutif. Elle s’appuie sur le comptage du nombre de collisions dans une séquence binaire lue par bloc. La probabilité de collisions entre deux symboles binaires de taille t, pour des données aléatoires, est de 1 2 t . Dès lors que les données sont codées, la probabilité de collisions augmente. Le comptage des collisions permet donc de distinguer des données aléatoires de données codées lorsque t est suffisamment grand pour correspondre à la taille d’une équation de parité. Nous pouvons lire la séquence par blocs disjoints ou par blocs glissants. Mais les équations de parité d’un code convolutif étant valides par blocs glissants (avec un décalage correspondant à la longueur du code) nous tirons parti de ce phénomène en effectuant le comptage par blocs glissants. Les paramètres du code sont alors identifiés en itérant sur la taille des blocs de lecture. Ce procédé a l’avantage d’avoir un faible coût et d’être résistant au bruit. Le test que nous effectuons repose sur le paradoxe des anniversaires. Nous observons une séquence binaire par blocs de taille t. Lorsqu’un symbole, de taille t, apparaît i fois dans la séquence on dit qu’il y a i.(i−1) 2 collisions. Nous comptons alors le nombre total de collisions que nous notons XN pour une séquence composée de N blocs. Dans un contexte non bruité cela correspond à XN = X N i=1 X j>i x(si , sj ) où x(si , sj ) = ( 1 si si = sj 0 sinon. 424.2 Test de collisions Nous pouvons alors comparer la probabilité de collisions observée et l’espérance de ce nombre pour des données aléatoires ou codées. En effet pour des données aléatoires, vues par bloc de taille t on a P(s = s ′ ) = 1 2 t et par linéarité de l’espérance on a : E [XN ] = X N i=1 X j>i E[x(si , sj )] = 1 2 t |{i, j ∈ J1, NK, j > i}| = N.(N − 1) 2 t+1 Le test statistique se déroule alors comme suit : Soit une séquence binaire observée, composée de N blocs de taille t. Nous comptons le nombre, noté Xobs, de collisions observées sur cette séquence. Après normalisation, la probabilité empirique, xobs, de collision, vaut xobs = 2.Xobs N.(N − 1) Pour observer de manière sûre une collision, pour des données aléatoires, il faut disposer d’au moins 2 t + 1 symboles soit t.(2t + 1) bits. Mais d’après le paradoxe des anniversaires on a une collision avec une probabilité supérieure ou égale à α pour cαt √ 2 t bits où cα = p −2 ln(1 − α). Lorsque nous avons i équations de parité, il faut disposer de cαt √ 2 t−i bits pour obtenir au moins une collision avec une probabilité supérieure ou égale à α. Le tableau suivant donne alors les quantités de données nécessaires pour différentes valeurs de α lorsque il existe une équation de parité avec t = 20. α Nombre de bits nécessaires 1/2 17 051 2/3 21 467 3/4 24 114 Nous nous plaçons dans le cas du canal binaire symétrique de probabilité d’erreur p et nous calculons dans la suite de ce chapitre la probabilité de collisions pour le code de parité ainsi que lorsque les données sont codées par un codeur convolutif et possèdent une équation de parité. Le cas du code de parité n’est pas utile en soit puisque nous nous intéressons uniquement aux codes convolutifs mais il facilite la compréhension de la probabilité de collisions en présence d’une équation de parité. Dans le cas non bruité, le modèle de probabilité de collisions s’étend lorsqu’il y a plusieurs équations de parité. Il est en revanche plus difficile d’établir des formules génériques pour les probabilités de collisions lorsqu’il existe plusieurs équations de parité. Nous verrons alors expérimentalement pour le canal binaire symétrique que la distinction entre des données codées possédant plusieurs équations de parité et des données aléatoires est claire. De plus, nous utilisons comme mesure le rapport entre la probabilité de collisions pour des données aléatoires et la probabilité de collisions empirique. 43Chapitre 4. Signature de codes convolutifs et recherche du dual par tests statistiques 4.3 Espérance du nombre de collisions Dans un contexte non bruité, deux symboles reçus sont égaux si et seulement si les symboles émis sont égaux. Cependant, dans un canal bruité, on peut obtenir une collision entre deux symboles reçus pour des symboles émis différents et inversement, deux symboles émis égaux peuvent correspondre à des symboles reçus différents. Nous pouvons donc observer des collisions sur la séquence reçue là où il n’y en avait pas sur la séquence non bruitée et inversement. Nous calculons alors la probabilité de collisions entre deux mots de code bruités pour le code de parité de longueur t. Ensuite, nous calculons cette même probabilité de collisions entre deux symboles ayant la taille d’une équation de parité. 4.3.1 Code de parité Nous supposons ici que la séquence émise est constituée de mots de code du code de parité de longueur t. Nous notons s et s ′ deux mots de code du code de parité choisis uniformément dans l’ensemble des mots de code. Ils sont émis dans un canal binaire symétrique de probabilités d’erreur p, et r et r ′ sont les symboles reçus correspondants. Nous calculons alors la probabilité que r soit égal à r ′ . Proposition 4.3.1 Soient r et r ′ deux mots de code du code de parité, de taille t, reçus après transmission à travers un canal binaire symétrique de probabilité d’erreur p alors P r = r ′
= 1 2 t−1 X t i=0 i pair  p 2 + (1 − p) 2 t−i (2p(1 − p))i t i ! Démonstration : Tout d’abord dans un bloc de taille t, le dernier bit dépend des t − 1 précédents par définition du code de parité. Donc il existe seulement 2t−1 blocs distincts. Lorsque le canal n’est pas bruité, c’est à dire p = 0, P(r = r ′ ) = P(s = s ′ ) = 1 2 t−1 . Notons s = s0s1 . . . st−i−1st−i . . . st−1 et s ′ = s ′ 0 s ′ 1 . . . s′ t−i−1 s ′ t−i . . . s′ t−1 Sans perdre de généralité on peut supposer que s et s ′ sont différents sur les i dernières positions et identiques sur les t−i premières. Appelons r et r ′ les versions bruitées de s et s ′ respectivement. Alors P(r = r ′ ) = P(r0 = r ′ 0 , . . . , rt−i−1 = r ′ t−i−1 , rt−i = r ′ t−i , . . . , rt−1 = r ′ t−1 ) Ces évènements sont indépendants dans un canal binaire symétrique donc P(r = r ′ ) = t Y−1 i=0 P(ri = r ′ i ) 444.3 Espérance du nombre de collisions Alors P(r0 = r ′ 0 ) = P(r0 = s0, r′ 0 = s ′ 0 ) + P(r0 = s0, r′ 0 = s0 ′ ) = (1 − p) 2 + p 2 et P(rt−1 = r ′ t−1 ) = P(rt−1 = st−1, r′ t−1 = st−1 ′ ) + P(rt−1 = st−1, r′ t−1 = s ′ t−1 ) = 2p(1 − p) De plus P(r0 = r ′ 0 ) = . . . = P(rt−i−1 = r ′ t−i−1 ) et P(rt−i = r ′ t−i ) = . . . = P(rt−1 = r ′ t−1 ). D’où pour s et s ′ fixé P(r = r ′ ) =  (1 − p) 2 + p 2 t−i (2p(1 − p))i . Or la différence de s et s ′ est de poids pair puisque la somme de deux mots de code est un mot de code. Donc il y a Pt i=0 i pair t i
possibilités de positionner cette différence. D’où P(r = r ′ ) = 1 2 t−1 X t i=0 i pair  (1 − p) 2 + p 2 t−i (2p(1 − p))i t i ! Remarque 4.3.2 Remarquons que lorsque p = 0 X t i=0 i pair  (1 − p) 2 + p 2 t−i (2p(1 − p))i t i ! = 1 donc on a bien P(r = r ′ ) = 1 2 t−1 dans ce cas. Ce qui correspond bien à l’intuition que l’on a. Donc, lorsque p = 0, la probabilité de collision est deux fois plus élevée pour le code de parité que pour des données aléatoires. Nous pouvons alors distinguer aisément des données codées par le code de parité, de données aléatoires, sur des blocs de taille t, quitte à itérer sur t. Dans ce cas, les blocs sont lus de manière disjointe naturellement. Notons PC la probabilité de collision pour le code de parité et Paléa la probabilité de collision, pour des données aléatoires. Le rapport PC Paléa est représenté dans la Figure 4.1 pour différents niveaux de bruit. Nous remarquons que lorsque le canal est bruité jusqu’à p = 10−3 , nous distinguons clairement la présence d’un code car le rapport des probabilités de collisions est proche de 2. Cependant, lorsque le bruit augmente, nous voyons qu’il sera toujours aisé de distinguer de très petits codes tandis que pour les codes de plus grandes longueurs (au delà de n = 10), cette distinction risque d’être moins claire voire impossible. Nous nous intéressons dans la suite de ce chapitre à la reconnaissance des paramètres d’un code convolutif. Soit C un code convolutif possédant une équation de parité de taille t, nous montrons à présent qu’il est possible de distinguer la présence d’une telle équation en observant la probabilité de collision sur des blocs de taille t. Nous établissons pour cela la probabilité de collisions attendue. 45 Caractérisation et d´etection de malware Android basées sur les flux d’information Radoniaina Andriatsimandefitra To cite this version: Radoniaina Andriatsimandefitra. Caract´erisation et d´etection de malware Android bas´ees sur les flux d’information. Cryptography and Security. Sup´elec, 2014. French. HAL Id: tel-01095994 https://hal.inria.fr/tel-01095994 Submitted on 16 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.2014 THÈSE DE DOCTORAT DOMAINE : STIC Spécialité : Informatique Ecole doctorale MATISSE présentée par Radoniaina Andriatsimandefitra Ratsisahanana préparée à l’unité de recherche CIDRE Confidentialité, Intégrité, Disponibilité, Répartition Supélec/INRIA Caractérisation et détection de malware Android basées sur les flux d’information Thèse soutenue à Supélec le (date) devant le jury composé de : Pascal Caron Maître de Conférence à l’université de Rouen / examinateur Anthony Desnos Ingénieur chez Google / examinateur invité Jean-Yves Marion Professeur à l’université de Lorraine / rapporteur Ludovic Mé Professeur à Supélec / directeur de thèse David Pichardie Professeur à l’ENS Rennes / examinateur Radu State Chercheur à l’université du Luxembourg/rapporteur Valérie Viet Triem Tong Professeur associé à Supélec / encadrant de thèseiiTable des mati`eres Table des figures vii Liste des tableaux xi 1 Introduction 1 2 Etat de l’art 5 ´ 2.1 Syst`eme Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Architecture du syst`eme Android . . . . . . . . . . . . . . 6 2.1.2 Applications Android . . . . . . . . . . . . . . . . . . . . 9 2.2 S´ecurit´e du syst`eme Android . . . . . . . . . . . . . . . . . . . . 16 2.2.1 M´ecanismes issus de Linux . . . . . . . . . . . . . . . . . 16 2.2.2 M´ecanismes propres `a Android . . . . . . . . . . . . . . . 17 2.3 Limites des m´ecanismes de s´ecurit´e Android . . . . . . . . . . . . 21 2.3.1 Abus de permission . . . . . . . . . . . . . . . . . . . . . 21 2.3.2 Permissions : attaques par d´el´egation et attaques par collusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.3 Communication entre composants via les intents . . . . 21 2.3.4 Failles logicielles : ´el´evation de privil`ege . . . . . . . . . . 23 2.4 Malware Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.1 D´efinitions . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.2 Malwares Android : 2010 `a 2011 [113] . . . . . . . . . . . 25 2.4.3 Malwares Android en 2013 . . . . . . . . . . . . . . . . . 28 2.5 Renforcement de la s´ecurit´e sous Android . . . . . . . . . . . . . 30 2.5.1 Protection des ressources sensibles . . . . . . . . . . . . . 30 2.5.2 Communication entre processus et entre composants . . . 35 2.5.3 Abus des permissions . . . . . . . . . . . . . . . . . . . . 39 2.6 Suivi de flux d’information . . . . . . . . . . . . . . . . . . . . . . 41 2.6.1 Suivi de flux au sein d’une application . . . . . . . . . . . 42 2.6.2 Suivi de flux au niveau syst`eme . . . . . . . . . . . . . . . 43 2.6.3 Suivi de flux au niveau hardware . . . . . . . . . . . . . . 44 2.7 Classification et d´etection de malware . . . . . . . . . . . . . . . 46 2.8 Analyse d’applications Android . . . . . . . . . . . . . . . . . . . 48 2.8.1 D´esassembleur, d´ecompilateur . . . . . . . . . . . . . . . . 48 iiiiv TABLE DES MATIERES ` 2.8.2 Comparaison d’applications . . . . . . . . . . . . . . . . . 49 3 Blare : un moniteur de flux d’information 55 3.1 Mod`ele th´eorique . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.1.1 Conteneurs d’information . . . . . . . . . . . . . . . . . . 56 3.1.2 Information et contenu courant d’un objet : itag . . . . . 56 3.1.3 Politique de flux d’information : pxqptag . . . . . . . . . . 57 3.1.4 Suivi et contrˆole de flux d’information . . . . . . . . . . . 59 3.2 D´efinition d’une politique de flux d’information . . . . . . . . . . 62 3.3 KBlare : suivi et contrˆole de flux via LSM . . . . . . . . . . . . . 65 3.4 AndroBlare : Blare sous Android . . . . . . . . . . . . . . . . . . 68 3.4.1 Communication entre processus : Binder . . . . . . . . . . 69 3.4.2 Suivi de flux d’information dans le Binder . . . . . . . . . 72 3.4.3 Ex´ecution des applications Android . . . . . . . . . . . . 74 3.4.4 Description des flux observ´es . . . . . . . . . . . . . . . . 84 3.4.5 Outils en espace utilisateur . . . . . . . . . . . . . . . . . 84 3.5 AndroBlare : analyse d’applications Android . . . . . . . . . . . 85 4 Graphes de flux syst`eme 89 4.1 Graphe de flux syst`eme . . . . . . . . . . . . . . . . . . . . . . . 89 4.2 Quelques op´erations utiles sur les SFG . . . . . . . . . . . . . . . 92 4.2.1 Intersection de deux SFG : g1 [ g2 . . . . . . . . . . . . . 92 4.2.2 Inclusion d’un SFG dans un autre : g1 Ď g2 . . . . . . . . 93 4.2.3 Nœuds et arcs d’un SFG . . . . . . . . . . . . . . . . . . . 93 4.3 Construction d’un graphe de flux syst`eme . . . . . . . . . . . . . 93 4.4 SFG : profil comportemental d’une application . . . . . . . . . . 95 4.4.1 Analyse de DroidKungFu1 avec AndroBlare . . . . . . . . 95 4.4.2 Analyse du SFG de DroidKungFu1 . . . . . . . . . . . . . 96 4.5 Politique de flux d’information `a partir d’un SFG . . . . . . . . . 100 5 Caract´erisation et d´etection de malware 107 5.1 Caract´erisation de malware Android . . . . . . . . . . . . . . . . 108 5.2 Evaluation de la m´ethode de classification . . . . . . . . . . . . . ´ 111 5.2.1 Jeu de donn´ee . . . . . . . . . . . . . . . . . . . . . . . . 111 5.2.2 Exp´erimentation et r´esultat . . . . . . . . . . . . . . . . . 112 5.3 De la n´ecessit´e du filtrage . . . . . . . . . . . . . . . . . . . . . . 118 5.4 D´etection d’ex´ecution de malware Android . . . . . . . . . . . . . 121 5.5 Evaluation de la capacit´e de d´etection . . . . . . . . . . . . . . . ´ 122 6 Conclusion 129 A Ev`enements d´eclencheurs de code malveillant 133 ´ A.1 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 A.2 BadNews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 A.3 DroidKungFu1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 A.4 DroidKungFu2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144TABLE DES MATIERES ` v A.5 jSMSHider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Publications 147 Bibliographie 149vi TABLE DES MATIERES `Table des figures 2.1 Architecture de la plateforme Android . . . . . . . . . . . . . . . 8 2.2 Fichier MANIFEST.MF de l’application HelloActivity . . . . . . . . 18 2.3 Fichier .SF de l’application HelloActivity . . . . . . . . . . . . . 19 3.1 Extrait de la sortie de la commande ps sous Android 4.4 . . . . . 58 3.2 Exemple de contrˆole de flux d’information effectu´e par Blare . . 61 3.3 Design de Linux Security Module . . . . . . . . . . . . . . . . . . 66 3.4 Appel d’une m´ethode distante grˆace au Binder . . . . . . . . . . 70 3.5 S´equence de d´emarrage d’Android . . . . . . . . . . . . . . . . . 75 3.6 M´ecanisme de notification de l’ex´ecution d’une application Android 77 3.7 Exemple de message lev´e par Blare sous Linux . . . . . . . . . . 84 3.8 Format des flux observ´es par Blare sous Android . . . . . . . . . 85 3.9 AndroBlare : environnement d’analyse d’application Android . . 87 4.1 Exemple de flux d’information causant l’apparition d’arcs parall`eles dans les SFG . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.2 Exemple de SFG avec des arcs parall`eles . . . . . . . . . . . . . . 90 4.3 Graphe de d´ependance et SFG repr´esentant les flux d’information ayant pr´ec´ed´e la corruption d’un fichier f ilex . . . . . . . . . . . 92 4.4 Permissions demand´ees par un ´echantillons de DroidKungFu . . . 96 4.5 Liste des applications dans le menu du t´el´ephone apr`es l’installation d’une nouvelle application par un ´echantillon de DroidKungFu 97 4.6 Extrait du SFG d’un ´echantillon de DroidKungFu . . . . . . . . 98 4.7 Extrait des alertes lev´ees par l’´echantillon de DroidKungFu1 lors de l’´evaluation de la politique de Finger Scaner . . . . . . . . . . 104 5.1 S0 : sous-graphe en commun des ´echantillons de BadNews . . . . 115 5.2 S1 : sous-graphe en commun des ´echantillons de DroidKungFu 1 116 5.3 S2 : sous-graphe en commun des ´echantillons de DroidKungFu 2 117 5.4 S3 : Sous-graphe en commun des ´echantillons de jSMSHider . . . 117 5.5 Profil calcul´e lorsqu’aucun filtrage n’est r´ealis´e . . . . . . . . . . 119 5.6 Premier profil calcul´e en utilisant aucune liste blanche . . . . . . 120 5.7 Second profil calcul´e en utilisant aucune liste blanche . . . . . . . 120 5.8 Troisi`eme profil calcul´e en utilisant aucune liste blanche . . . . . 120 viiviii TABLE DES FIGURES 5.9 Quatri`eme profil calcul´e en utilisant aucune liste blanche . . . . . 120 A.1 Extrait du graphe d’appel de fonction d’un ´echantillon de BadNews137 A.2 Extrait du graphe d’appel de fonction d’un ´echantillon de DroidKungFu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Liste des listings 2.1 Partage d’une page web grˆace `a un intent implicite. Extrait du code du navigateur par d´efaut d’Android . . . . . . . . . . . . . 11 2.2 Fichier AndroidManifest.xml d’Angry Birds Space . . . . . . . 15 2.3 Exempe de code Java avec et sans r´eflexion . . . . . . . . . . . . 29 2.4 Extrait du code de l’application JetBoy fourni avec le SDK Android 49 2.5 Extrait du code smali de l’application JetBoy . . . . . . . . . . . 52 2.6 Extrait du code r´esultant de la d´ecompilation de l’application JetBoy avec le d´ecompilateur par d´efaut d’Androguard . . . . . . 53 3.1 Exemple de politique App Armor . . . . . . . . . . . . . . . . . . 62 3.2 Liste des op´erations sur les fichiers support´ees par Binder . . . . 71 3.3 Signature de la fonction binder ioctl . . . . . . . . . . . . . . . 71 3.4 Fonction de chargement en m´emoire du code d’une application . 78 3.5 D´eclaration d’une famille Generic Netlink dans le noyau pour le m´ecanisme de coop´eration . . . . . . . . . . . . . . . . . . . . . . 79 3.6 D´efinition d’une commande Generic Netlink pour notifier l’ex´ecution d’une application . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.7 Enregistrement de la famille servant `a la notification d’ex´ecution des applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.8 Notification de l’ex´ecution d’une application par la machine virtuelle Dalvik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.1 Entr´ee dans le fichier packages.xml ajout´ee suite `a l’installation d’une nouvelle application par un ´echantillon de DroidKungFu . 99 4.2 Extrait de la politique BSPL de l’application Finger Scanner . . 105 5.1 Contenu du fichier sstimestamp.xml d’un ´echantillon de DroidKungFu1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.1 Fichier AndroidManifest.xml d’un ´echantillon de BadNews . . . 135 A.2 Code appel´e `a la r´eception d’un Intent par les composants de type Receiver d’un ´echantillon de BadNews . . . . . . . . . . . . 136 A.3 Extrait du code de la m´ethode sendRequest d’un ´echantillon de BadNews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 A.4 Code appel´e `a l’ex´ecution du composant AdvService d’un ´echantillon de BadNews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 A.5 Extrait du contenu du fichier AndroidManifest.xml d’un ´echantillon de DroidKungFu1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 ixx LISTE DES LISTINGS A.6 M´ethode onCreate du composant SearchService d’un ´echantillon de DroidKungFu1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 A.7 Contenu du fichier sstimestamp.xml d’un ´echantillon de DroidKungFu1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 A.8 M´ethode onCreate d’un composant service d’un ´echantillon de DroidKungFu2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Liste des tableaux 2.1 Types de permission Android . . . . . . . . . . . . . . . . . . . . 17 2.2 Exploits root connus et leur usage par les malware Android de 2010 `a 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1 Intervalle de valeur du type int selon sa taille en bits . . . . . . 56 3.2 Blare : m´ethode de suivi de flux . . . . . . . . . . . . . . . . . . . 60 3.3 Un extrait de la politique de flux d’information . . . . . . . . . . 64 3.4 Liste des hooks LSM utilis´es par KBlare pouvant engendrer un flux d’information . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.1 Nombre d’alertes lev´ees par Blare lors de l’ex´ecution des versions originales et infect´ees de trois applications en appliquant une politique BSPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.1 Classification des 19 ´echantillons de malware. . . . . . . . . . . . 114 5.2 Nombre de profils obtenus en variant le filtrage . . . . . . . . . . 118 5.3 R´esultat de d´etection sur les applications b´enignes provenant de Google Play. Taux de faux positif : 0% . . . . . . . . . . . . . . . 124 5.4 R´esultats de la d´etection sur 39 ´echantillons de malware. Taux de Vrai Positif : 100% . . . . . . . . . . . . . . . . . . . . . . . . 125 xixii LISTE DES TABLEAUXListe des algorithmes 1 Construction d’un SFG `a partir des entr´ees d’un journal de Blare 94 2 Calcul d’une politique de flux d’information Blare `a partir d’un SFG101 3 Calcul des parties communes de SFG d’application caract´erisant son comportement malveillant et regroupement de ces SFG . . . . 109 4 One-step-classification function . . . . . . . . . . . . . . . . . 109 5 D´etection de l’ex´ecution de malware Android bas´e sur les flux d’information caus´e dans le syst`eme . . . . . . . . . . . . . . . . . . . 122 xiiixiv LISTE DES ALGORITHMESRemerciements Avant d’aborder le pourquoi de ce document, je tenais avant tout `a remercier les membres du jury d’avoir accept´e d’´evaluer mon travail : David Pichardie pour avoir accept´e de pr´esider le jury de ma th`ese, Radu State et Jean-Yves Marion pour avoir accept´e d’ˆetre les rapporteurs de ce m´emoire, Pascal Caron et Anthony Desnos pour avoir accept´e d’examiner mon travail. Je tiens ´egalement `a remercier Ludovic M´e et Val´erie Viet Triem Tong pour leur encadrement et leur implication dans la r´ealisation de ma th`ese, ainsi que le reste de l’´equipe pour ces trois ann´ees pass´ees ensemble. Finalement, un grand merci aux membres de ma famille et aux amis qui m’ont soutenu tout au long de la th`ese. Kudos au Langomatic (organisateurs, participants et staff du O’Connell’s) pour toutes ces soir´ees du lundi riches en rencontres et en diversit´es culturelles. xvxvi LISTE DES ALGORITHMESChapitre 1 Introduction Lanc´e officiellement en 2008, Android est devenu en quelques ann´ees le syst`eme d’exploitation le plus r´epandu sur les plateformes mobiles de type smartphone et tablette [72, 107, 71]. Au del`a de sa large adoption par le grand public, il a ´egalement suscit´e l’int´erˆet des d´eveloppeurs d’applications malveillantes qui voient dans le syst`eme Android, une cible potentielle d’attaque au mˆeme niveau que les ordinateurs de bureau `a cause de la diversit´e des donn´ees et services qu’ils proposent. Les appareils tournant sous Android offrent diff´erentes fonctionnalit´es allant du simple t´el´ephone `a celles des ordinateurs de bureau et assistants num´eriques personnels (pockets PC ou PDA). La combinaisons de toutes ces fonctionnalit´es font de ces appareils un point de concentration de divers donn´ees et services sensibles (liste de contact, messages, donn´ees de g´eolocalisation, etc.) et en cons´equence une cible de valeur pour les d´eveloppeurs de malware. Ces derni`eres ann´ees, nous avons ainsi vu l’apparition d’un nombre toujours grandissant d’applications malveillantes qui cherchent `a voler les donn´ees du t´el´ephone, les corrompre, espionner l’utilisateur, abuser des services offerts par le t´el´ephone, etc. A la vue du nombre grandissant des malware Android, il ` devient n´ecessaire de d´evelopper des outils d’analyse de malware afin de comprendre leur fonctionnement et plus tard les d´etecter. L’une des raisons de la prolif´eration de ces malware est l’insuffisance des m´ecanismes de s´ecurit´e Android `a d´etecter et bloquer de telles attaques et la facilit´e d’acc`es `a une partie des ressources sensibles du t´el´ephone. Android propose un ensemble de m´ethodes pour acc´eder ces ressources et ces acc`es n´ecessite une autorisation de la part de l’utilisateur au moment de l’installation. L’application est install´ee uniquement si l’utilisateur valide toutes les autorisations demand´ees par l’application. Toute application install´ee sur le t´el´ephone a ainsi acc`es aux ressources dont elle a demand´e l’acc`es sans que le syst`eme ne contrˆole l’usage qui est fait des ressources. Les premiers travaux li´es `a la s´ecurit´e d’Android sont donc focalis´es sur l’analyse des limites de la s´ecurit´e sous Android et sur une mani`ere de les combler. Enck et al. proposent par exemple dans [47] une v´erification des permissions demand´ees par les applications afin de s’assurer qu’elles ne soient trop dangereuses. Ce type d’approche a cependant une prin- 12 CHAPITRE 1. INTRODUCTION cipale limitation qui est de ne d´etecter que ce que nous savons ˆetre dangereux. Il ne permet donc pas de d´etecter et d’apprendre de nouvelles attaques. Dans ce th`ese nous adoptons une approche diff´erente qui est bas´ee sur les flux d’information. Un flux d’information d´ecrit un transfert d’information entre deux objets. Au niveau du syst`eme d’exploitation, il d´ecrit par exemple des communications entre deux applications ou des acc`es `a un fichier. Au lieu de nous focaliser sur les limitations du syst`eme Android pour identifier les sc´enarios d’attaque et les d´etecter par la suite, nous proposons d’apprendre comment les attaques ont lieu en analysant directement les malware et utiliser la base de connaissance acquise durant l’apprentissage pour d´etecter les malware. Selon les travaux de Zhou et al. la m´ethode d’infection principale utilis´ee par les d´eveloppeurs de malware est d’ajouter leur code malicieux `a des applications existantes et proposer les versions infect´ees de ces applications en t´el´echargement sur les plateformes de t´el´echargement tels que Google Play. En supposant qu’un malware soit distribu´e sous la forme de diff´erentes applications, nous pouvons supposer que les applications infect´ees par le mˆeme code malveillant ont partiellement un comportement similaire. En analysant les ´echantillons des malware et en isolant ces comportements similaires, nous pouvons ainsi `a la fois apprendre le comportement malveillant d’un malware et calculer un profil pour ce malware afin de le d´etecter. Le reste de ce document est divis´e comme suit. Le chapitre 2 pr´esente le contexte de ce travail et est divis´e en deux parties. La premi`ere partie concerne le syst`eme Android : l’architecture du syst`eme, ses points communs et diff´erences avec les syst`emes Linux, la notion d’applications Android, l’analyse des limites du mod`ele de s´ecurit´e d’Android, les menaces que repr´esentent les malware Android et les travaux essayant de combler ces limites. La deuxi`eme partie du chapitre introduit les bases n´ecessaires `a l’accomplissement de notre objectif. Nous y pr´esentons dans un premier temps la notion de suivi de flux d’information et les diff´erents niveaux existant pour observer les flux d’information. Par la suite nous pr´esentons comment les m´ethodes d’apprentissage peuvent ˆetre utilis´ees afin de classifier et d´etecter des malware. Nous pr´esentons pour cela quelques travaux connus exploitant les traces d’ex´ecution des malware pour les classifier. Le chapitre 3 pr´esente Blare le moniteur de flux d’information et son portage pour le syst`eme Android. Blare est un outil de d´etection d’intrusion param´etr´e par une politique de flux d’information afin de d´etecter les intrusions dans un syst`eme. Ayant ´et´e d´evelopp´e pour les syst`emes Linux, il ne prenait ainsi pas en compte une partie des flux existant sous Android. Ces flux sont li´es `a des m´ecanismes propres `a Android qui n’existent pas sous Linux. Dans un premier temps, nous pr´esentons donc ces m´ecanismes et les flux d’information qu’ils causent qui ´etaient invisibles `a Blare. Ensuite, nous pr´esentons comment nous avons pris en compte ces m´ecanismes et am´elior´e ainsi l’observation des flux d’information sous Android. Le r´esultat de ces am´eliorations, AndroBlare, est ce qui nous sert d’environnement d’analyse durant cette th`ese. Le chapitre 4 introduit une structure de donn´ee appel´ee graphe de flux syst`eme ou System Flow Graph. Cette structure d´ecrit de mani`ere compacte et plus compr´ehensible les flux d’information que Blare observe dans les syst`emes.3 Un des objectifs de cette th`ese est de comprendre le fonctionnement d’un malware en l’analysant dans notre environnement d’analyse AndroBlare. Apr`es avoir pr´esent´e la structure, nous montrons dans ce chapitre, `a travers l’analyse d’un ´echantillon de malware, l’utilit´e de la structure pour repr´esenter le comportement d’un malware et comprendre son comportement. Cette structure repr´esentant le comportement d’une application, nous montrons ´egalement qu’elle peut assister un d´eveloppeur dans la cr´eation d’une politique de flux d’information pour son application. Enfin, le chapitre 5 pr´esente notre approche afin de classifier et d´etecter les malware Android. La classification consiste `a regrouper les ´echantillons d’un malware avec un comportement similaire et extaire un profil caract´erisant les ´echantillons d’un mˆeme groupe. Cette classification s’apparente `a un apprentissage non supervis´e et nous pr´esentons dans ce chapitre comment nous le r´ealisons puis l’´evaluons avec un ensemble d’´echantillons de malware. La d´etection consiste `a utiliser les profils calcul´es durant la classification pour d´etecter d’autres ´echantillons de malware. Nous pr´esentons ainsi en deuxi`eme partie de ce chapitre comment nous utilisons AndroBlare et les profils calcul´es pour d´etecter l’ex´ecution de malware et ´evaluons l’approche avec d’autres ´echantillons.4 CHAPITRE 1. INTRODUCTIONChapitre 2 Etat de l’art ´ L’objectif de cette th`ese est de d´evelopper une m´ethode afin de caract´eriser et d´etecter les malwares Android. La r´ealisation de cet objectif s’est faite en plusieurs ´etapes : le portage du moniteur de flux d’information Blare pour le syst`eme Android, la proposition d’une structure de donn´ee pour repr´esenter les profils d’une application et une m´ethode de calcul de profil des malwares Android ainsi que de leur d´etection. Dans ce premier chapitre, nous introduisons dans un premier temps le syst`eme Android : son architecture, la notion d’application Android et le mod`ele de s´ecurit´e d’Android. Ensuite, nous montrons en section 2.3 et 2.4 les limites du m´ecanisme de s´ecurit´e Android ainsi qu’un aper¸cu des menaces que repr´esentent les malware Android. La section 2.5 pr´esente ensuite les diff´erents travaux visant `a combler les limites du m´ecanisme de s´ecurit´e d’Android ainsi qu’`a d´etecter les attaques visant le syst`eme. L’approche pour laquelle nous avons opt´ee est bas´ee sur les flux d’information au niveau du syst`eme. La section 2.6 pr´esente ainsi diff´erents travaux li´es au suivi de flux d’information et une discussion sur les apports et limitations de ces approches. Une partie des exp´erimentations que nous menons dans cette th`ese consiste `a ex´ecuter des ´echantillons de malware Android et plus pr´ecis´ement leur code malveillant. Comme ´evoqu´e dans les travaux de Zhou et al. dans [113], certains malware v´erifient un nombre de conditions avant d’ex´ecuter leur code malveillant. Afin d’identifier ces conditions, il est n´ecessaire d’analyser statiquement les ´echantillons des malware concern´es. Nous pr´esentons ainsi en section 2.8 un ensemble d’outils d’analyse statique des applications Android. 2.1 Syst`eme Android Android partage une base commune aux syst`emes Linux qui est le noyau et un ensemble de commandes et utilitaires n´ecessaires. Dans cette section, nous pr´esentons dans un premier temps l’architecture du syst`eme Android, celle de ses applications et les m´ecanismes de s´ecurit´e fournis avec le syst`eme. 56 CHAPITRE 2. ETAT DE L’ART ´ 2.1.1 Architecture du syst`eme Android Le syst`eme Android est divis´e en plusieurs couches comme illustr´e sur la figure 2.1. La partie la plus basse repr´esente le cœur du syst`eme, c’est-`a-dire le noyau, et le reste l’espace utilisateur. 2.1.1.1 Noyau Android Le noyau Android est une version modifi´ee du noyau Linux 1 et repr´esente le cœur du syst`eme. Le noyau est le programme servant d’interface entre les diff´erents composants du syst`eme (p´eriph´eriques, processus, fichiers etc). Parmi les modifications notables apport´ees dans le noyau Android, nous pouvons citer les m´ecanismes binder, ashmem, wakelock, low memory killer, logger, RAM console et Paranoid Networking. Binder est un m´ecanisme de communication entre processus et d’appel de m´ethodes distantes. L’appel de m´ethodes distantes, appel´e Remote Procedure Call en anglais, consiste `a faire ex´ecuter une m´ethode par une entit´e distante. Il est inspir´e du projet OpenBinder [81]. Comme nous le verrons par la suite, il est un ´el´ement essentiel du fonctionnement du syst`eme Android. Ashmem pour Anonymous Shared Memory est un m´ecanisme de partage de m´emoire similaire `a celui du noyau Linux shm. Il est utilis´e pour partager les donn´ees entre applications Android. Parmi les ”nouveaut´es” apport´ees par ashmem il y a par exemple l’usage de compteur pour connaˆıtre le nombre de processus faisant r´ef´erence `a une zone de m´emoire partag´ee et ´eviter les fuites de m´emoire. Wakelock est un m´ecanisme servant `a notifier le noyau de ne pas se mettre en veille. Contrairement aux syst`emes Linux, le syst`eme Android essaie par d´efaut de se mettre en veille ´etant donn´e qu’il est destin´e `a tourner sur des appareils `a ressources limit´ees. Lors d’ex´ecution de code ne devant ˆetre interrompu, le wakelock est ainsi utilis´e pour dire au syst`eme de rester ´eveill´e. Low memory killer est un m´ecanisme utilis´e par le noyau pour lib´erer de la m´emoire lorsqu’il ne reste plus assez de m´emoire. Logger est un m´ecanisme de journalisation qui ´ecrit les ´ev`enements du syst`eme uniquement dans des zones allou´ees en m´emoire. Contrairement aux syst`emes Linux traditionnels, les ´ev`enements ´ecrits dans le journal du syst`eme ne sont ainsi jamais ´ecrits dans un fichier. RAM Console est un m´ecanisme qui pr´eserve en m´emoire le contenu des ´ev`enements syst`emes ajout´es par du code noyau (via la fonction printk) lors de la pr´ec´edente ex´ecution du syst`eme. Son contenu est accessible via le fichier /proc/last kmsg. Sous Linux, le contenu du journal des ´ev`enements syst`emes sont stock´es de mani`ere persistante dans les fichiers sous le r´epertoire /var/log/. Ce n’est pas le cas sous Android et en cas de crash du syst`eme par exemple, il devient impossible de r´ecup´erer les ´ev`enements qui ont amen´e au crash. RAM Console est ainsi ´et´e cr´e´e pour r´esoudre cette limitation du syst`eme de journalisation sous Android. 1. Noyau utilis´e par les distributions de type Linux telles que Debian et Ubuntu2.1. SYSTEME ANDROID ` 7 Paranoid Network est un m´ecanisme contrˆolant l’acc`es des applications au r´eseau. Sous Linux, toute application a le droit d’utiliser les sockets et acc´eder au r´eseau. La socket est la structure de base li´ee aux op´erations r´eseaux sous Linux. Sous Android, l’inverse est la r`egle car seule les applications avec une autorisation explicite sont autoris´ees `a cr´eer des sockets et communiquer sur le r´eseau. 2.1.1.2 Espace utilisateur L’espace utilisateur sous Android peut ˆetre divis´e en plusieurs parties comme illustr´e sur la figure 2.1. La couche Applications renferme les applications fournies par d´efaut sur le t´el´ephone ainsi que celles qui seront install´ees plus tard par l’utilisateur. Il s’agit des applications avec lesquelles l’utilisateur pourra interagir en g´en´eral (ex : application de messagerie et gestion des contacts). Les applications Android sont principalement ´ecrites en Java. Android donne cependant la possibilit´e d’´ecrire du code natif et de l’appeler au sein de l’application grˆace `a une interface appel´ee Java Native Interface dont le rˆole est d’interfacer du code Java avec du code natif ´ecrit en C. Android framework est l’ensemble des services et ressources fournies par le syst`eme Android. Il s’agit principalement de services tournant dans quelques processus cl´es du syst`eme Android tels que system server et mediaserver. La commande service list retourne sous Android la liste des services pr´esents dans le syst`eme. Sous Android 2.3, la commande retourne une liste de 50 services et sous Android 4.2 68 services. Parmi ces services nous pouvons citer ServiceManager, LocationManager. ServiceManager recense tous les autres services tournant sur le t´el´ephone et joue un rˆole d’annuaire pour les applications souhaitant acc´eder `a un service en particulier sur le t´el´ephone. Lorsqu’une application de navigation souhaite par exemple connaˆıtre la localisation de l’utilisateur, elle va dans un premier temps demander au Service-Manager la r´ef´erence de Location Service. Une fois cette r´ef´erence r´ecup´er´ee, elle pourra demander `a Location Service les donn´ees de g´eolocalisation. Surfaceflinger est un autre service avec un rˆole crucial sous Android. C’est lui qui est charg´e de composer et dessiner ce que les diff´erentes applications souhaitent afficher `a l’´ecran de l’appareil. Android runtime est l’environnement d’ex´ecution des applications Android. Il contient la biblioth`eque Java utilisable par les applications ainsi qu’une machine virtuelle appel´ee Dalvik. La biblioth`eque reprend une partie de la biblioth`eque Java standard plus quelques biblioth`eques suppl´ementaires propres `a Android. La machine virtuelle Dalvik elle interpr`ete le bytecode dans lequel les applications Android ont ´et´e compil´ees. Le bytecode dalvik est diff´erent du bytecode Java d’o`u l’usage de Dalvik `a la place des machines virtuelles Java standard. Depuis Android 4.4, une deuxi`eme machine virtuelle, ART [85, 99], qui est livr´ee sous forme exp´erimentale avec la plateforme. Libraries renferme les biblioth`eques natives du syst`eme. Elles sont g´en´eralement utilis´ees par les applications natives du syst`eme. Parmi les biblioth`eques nous8 CHAPITRE 2. ETAT DE L’ART ´ Kernel Libraries HAL Android framework Android runtime Applications Binder Audio driver ext4 Power management Ashmem Dalvik VM Bionic OpenGL Webkit SSL Camera HAL Audio HAL ... ... Surface Flinger Camera Service Package Manager Native tools and daemons Wakelock ... Core libraries Location Service ... Clock Contacts Launcher Email ... Display driver LSM Bluetooth driver SMS SQLite Service Manager Figure 2.1 – Architecture de la plateforme Android pouvons par exemple citer bionic qui renferme entre autres une biblioth`eque C et une biblioth`eque pour le support du C++. Selon la page Wikip´edia sur bionic [3], il s’agit d’une version modifi´ee de la biblioth`eque standard C de BSD et est propre `a Android. Si les applications utilisateurs sont des applications ´ecrites en Java, il existe tout de mˆeme quelques applications natives dans le syst`eme. Il s’agit de services propres au syst`eme et de quelques outils en ligne de commande qui peuvent s’av´erer utiles pour un d´eveloppeur. Ces applications n’ont pas pour but d’ˆetre utilis´ees par l’utilisateur lambda. HAL ou Hardware Abstraction Layer sert d’interface standard entre le syst`eme et les pilotes des p´eriph´eriques pr´esents sur l’appareil (ex : cam´era, capteur etc). Les constructeurs ´ecrivent ainsi les pilotes `a leur guise mais doivent fournir les m´ethodes correspondant aux interfaces HAL pour que le syst`eme puisse utiliser les p´eriph´eriques.2.1. SYSTEME ANDROID ` 9 2.1.1.3 Communications entre processus Android est un environnement d’ex´ecution o`u les applications sont pouss´ees `a collaborer pour fonctionner. Le but de cette collaboration est de limiter la duplication de code dans les applications et de proposer un ensemble assez grand de fonctionnalit´es aux diff´erentes applications du syst`eme. Un exemple illustrant cette collaboration est l’application cam´era. Pour utiliser la cam´era d’un appareil, une application doit connaˆıtre son mode de fonctionnement exact sachant qu’une cam´era peut ˆetre diff´erente d’un mod`ele de t´el´ephone `a un autre. Pour faciliter la tˆache au d´eveloppeur de l’application, l’application cam´era du t´el´ephone propose une interface permettant aux autres applications de prendre des photos ou enregistrer des vid´eos `a leur place puis leur transmettre le r´esultat. Ce syst`eme de collaboration repose plusieurs fonctionnalit´es du syst`eme. Du point de vue des d´eveloppeurs d’application, la collaboration repose sur l’usage des intents et des composants Content Provider pour ´echanger des messages et partager du contenu. Nous donnons plus de d´etail sur ces m´ecanismes dans la section 2.1.2.1. A un niveau plus bas, la collaboration repose sur deux fonc- ` tionnalit´es d’Android que sont Binder et Ashmem. Comme nous l’avons ´ecrit en section 2.1.1, ces deux m´ecanismes servent `a effectuer des appels distants de proc´edure et partager des zones de m´emoire entre processus. 2.1.2 Applications Android 2.1.2.1 Architecture d’une application : les diff´erents composants Une application Android est ´ecrite en Java. Contrairement aux applications Java standard, une application Android peut poss´eder plusieurs points d’entr´ee. Plus pr´ecis´ement, une application Android peut avoir plusieurs composants et chacun d’eux peut-ˆetre un point d’entr´ee dans le programme. Il existe quatre types de composants : Activity, ContentProvider, Service et BroadcastReceiver. Activity Un composant Activity est une interface utilisateur. Une application de messagerie ´electronique peut par exemple avoir trois composants Activity : un pour naviguer entre les r´epertoires de la messagerie, le deuxi`eme pour l’affiche d’un message et le dernier pour l’´edition et l’envoi. ContentProvider Un ContentProvider est un composant servant au partage de donn´ees d’une application. Son rˆole est de servir d’interface entre l’application souhaitant acc´eder aux donn´ees et les donn´ees. Ces donn´ees sont g´en´eralement stock´ees dans une base de donn´ees locale SQLite mais aucune restriction n’est impos´ee sur la mani`ere de stocker les donn´ees. La liste des contacts est par exemple stock´ee dans une base de donn´ees locales dont l’acc`es se fait `a travers un composant de type ContentProvider.10 CHAPITRE 2. ETAT DE L’ART ´ Service Un service est un composant effectuant des tˆaches en arri`ere plan. Il est utilis´e pour effectuer de longue tˆaches internes `a l’application ou `a ex´ecuter une tˆache `a la demande d’une application. Dans un client File Transfer Protocol, un service est utilis´e pour envoyer les donn´ees sur le r´eseau `a les recevoir. Cela ´evite de bloquer l’application jusqu’`a la fin de l’envoi. BroadcastReceiver Un BroadcastReceiver est un composant utilis´e pour ´ecouter les messages en large diffusion sur le syst`eme. Un exemple de ce type de message est la r´eception d’un nouveau SMS. Lorsqu’un nouveau SMS est re¸cu par le t´el´ephone, le syst`eme envoie un message en broadcast pour notifier les diff´erentes applications d’envoi et r´eception de SMS. Ce composant ne poss`ede aucune interface graphique et n’est pas cens´e ex´ecuter de longues tˆaches. 2.1.2.2 Intents : communication entre composants Un intent est un message utilis´e par les composants des applications pour communiquer entre eux. Plus pr´ecis´ement, il est utilis´e pour ex´ecuter que le destinataire ex´ecute une requˆete `a la demande de l’´emetteur. Le composant ´emettant l’intent et celui la recevant ne font pas forc´ement partie de la mˆeme application. Un intent a deux usages principaux : lancer un composant Activity ou Service et diffuser un message dans le syst`eme aux composants BroadcastReceiver. Nous parlerons alors dans ce cas de broadcast intent. Il existe diff´erentes m´ethodes fournies par l’API Android lancer un composant Activity ou Service et diffuser un intent dans le syst`eme. Ces m´ethodes peuvent ˆetre class´ees selon le type de composant cibl´e. Les m´ethodes utilis´ees pour envoyer un intent `a un composant de type Activity et Service sont les m´ethodes dont le nom commencent respectivement par startActivity et startService. Quant aux m´ethodes utilis´ees pour diffuser un intent `a des composants BroadcastReceiver, leur noms sont pr´efix´es par sendBroadcast. Un intent peut avoir plusieurs attributs dont quatre principaux : component name, action, data et category. Ces attributs servent `a d´efinir le(s) destinataire(s) de l’intent et les donn´ees `a transmettre. Component name d´esigne le nom du composant destin´e `a recevoir le message. Si une valeur est associ´ee `a cet attribut, l’intent est dit explicite. Dans le cas contraire, il est dit implicite et il appartient au syst`eme de d´efinir le destinataire du message. S’il existe plusieurs destinataires possibles, le syst`eme demandera `a l’utilisateur de choisir le destinataire `a qui le message sera envoy´e. Ce m´ecanisme est appliqu´e uniquement lorsque les destinataires possibles sont de type Activity. S’il s’agit de Service, le syst`eme fera lui-mˆeme le choix. Dans le code du listing 2.1 par exemple, la fonction sharePage ´emet un intent afin de partager une URL sans d´efinir le composant destinataire. A son ´emission, le syst`eme d´eterminera donc une liste ` de destinataires pouvant recevoir l’intent et proposera `a l’utilisateur de choisir parmi les ´el´ements de cette liste. Pour ce type d’action, Android proposera au moins dans la liste l’application de messagerie ´electronique, le presse papiers et le bluetooth. Pour les messages de type broadcast intent, le syst`eme enverra `a tous les composants Broadcast Receiver ´eligibles. Action est une2.1. SYSTEME ANDROID ` 11 chaˆıne de caract`ere et d´esigne l’action demand´ee par l’application. Data est une adresse pointant vers la donn´ee `a traiter ou le type de donn´ees `a traiter. Category d´esigne une ou plusieurs cat´egories de composants cens´es recevoir le message. Les cat´egories n’ont aucun lien avec les quatre types de composant d’une application Android. A partir de ces attributs, le syst`eme d´efinit le ou les ` destinataires de l’intent. Deux autres attributs peuvent s’ajouter aux quatre pr´ec´edents : les flags et les extras. Le syst`eme ne les utilise pas pour d´efinir le ou les destinaire(s) de l’intent. Les flags sont des attributs destin´es plus au syst`eme qu’au destinataire du message. Une analyse rapide de la liste des flags fournis par Android montre qu’ils ont un usage assez vari´e. Ils servent par exemple `a d´el´eguer une permission d’acc`es en lecture ou ´ecriture aux donn´ees associ´ees `a l’intent ou `a choisir des groupes d’applications pouvant recevoir le message. Nous ne donnerons pas plus de d´etail sur cet attribut dans cette th`ese mais la liste des flags fournis par Android sont disponibles dans la documentation de la m´ethode setFlags de la classe Intent [84]. Les extras permettent de transmettre des informations additionnelles au destinataire du message. Il s’agit d’une liste de couple cl´e valeur. Dans le code du listing 2.1, l’intent ´emis par la fonction contient quatre attributs de type extras. Ces attributs servent dans cet exemple `a transmettre des donn´ees li´ees `a l’URL de la page `a partager : le titre de la page, une icˆone et une capture d’´ecran. 1 static final void sharePage(Context c, String title, String url, 2 Bitmap favicon, Bitmap screenshot) { 3 Intent send = new Intent(Intent.ACTION_SEND); 4 send.setType("text/plain"); 5 send.putExtra(Intent.EXTRA_TEXT, url); 6 send.putExtra(Intent.EXTRA_SUBJECT, title); 7 send.putExtra(Browser.EXTRA_SHARE_FAVICON, favicon); 8 send.putExtra(Browser.EXTRA_SHARE_SCREENSHOT, screenshot); 9 try { 10 c.startActivity(Intent.createChooser(send, c.getString( 11 R.string.choosertitle_sharevia))); 12 } catch(android.content.ActivityNotFoundException ex) { 13 // if no app handles it, do nothing 14 } 15 } Listing 2.1 – Partage d’une page web grˆace `a un intent implicite. Extrait du code du navigateur par d´efaut d’Android Remarque : Afin qu’un composant A puisse recevoir un intent d’un composant appartenant `a une application autre que la sienne, il faut que ce composant A soit d´eclar´e avec l’attribut exported dans le fichier AndroidManifest.xml de12 CHAPITRE 2. ETAT DE L’ART ´ son application (section 2.1.2.4). Cet attribut est cependant implicite lorsqu’un intent filter est d´eclar´e pour ce composant. 2.1.2.3 Intent-filter Dans la section pr´ec´edente, nous avons pr´esent´e les intents, un type de message utilis´e par les composants d’une application pour communiquer avec d’autres composants. Lors de l’´emission de l’intent, le syst`eme calcule `a partir des attributs associ´es `a l’intent le(s) destinataire(s) du message. Deux cas peuvent se pr´esenter. Dans le premier cas, l’´emetteur a d´efini explicitement le destinataire (explicit intent). Le message est donc transmis directement au destinataire choisi par l’´emetteur. Dans le second cas, l’´emetteur n’a pas d´efini de destinataire et il appartient au syst`eme de le d´efinir (implicit intent). Lorsque ce cas se pr´esente, le syst`eme d´efinit la liste des destinataires possibles grˆace `a un filtre d´eclar´e par chaque application appel´ee intent filter. Ce dernier d´efinit pour chaque composant quels sont les intents que le composant souhaite recevoir et est d´eclar´e dans le fichier AndroidManifest.xml qui accompagne chaque application Android. Nous donnons plus de d´etail sur le contenu de ce fichier dans la section 2.1.2.4 et nous nous contentons ici d’expliquer la partie sur les intent filters. Chaque composant d’une application est d´eclar´ee dans ce fichier et chaque d´eclaration est accompagn´ee de diverses informations telles que l’intent filter. L’intent filter d´eclare au syst`eme les intents que chaque composant peut traiter. Ce filtrage est d´ecrit par une liste d’attributs d’intents que les intents transmis aux composants doivent avoir. Dans le listing 2.2 par exemple, l’application filtre les intents que deux de ses composants peuvent recevoir. Le premier composant, App, ne peut recevoir que les intents dont les attributs action et category ont respectivement comme valeur associ´ee android.intent.action.MAIN et android.intent.category.LAUNCHER. Quant au deuxi`eme composant, BillingReceiver, il ne peut recevoir que des intents auquel l’attribut action est associ´e `a la valeur com.android.vending.billing.RESPONSE CODE. 2.1.2.4 Android Package Android Package est la forme sous laquelle une application est propos´ee `a l’utilisateur. Il s’agit d’une archive, commun´ement appel´ee apk, contenant le code de l’application et les ressources qu’elle utilise. Nous pr´esentons dans ce qui suit le contenu principal d’un apk. AndroidManifest.xml AndroidManifest.xml est un fichier xml contenant les informations li´ees `a l’application qui sont n´ecessaires au syst`eme. Il est cr´e´e par le d´eveloppeur de l’application. Parmi les informations qu’il contient, nous pouvons citer : — le nom du package de l’application — le composant Activity `a lancer au lancement de l’application2.1. SYSTEME ANDROID ` 13 — la liste des composants de l’application et les informations qui sont li´es aux composants (ex : permission pour acc´eder `a un composant Service sensible, les Intents attendus par les composants de l’application etc) — les permissions demand´ees par l’application (ex : read sms pour lire les SMS) — les permissions d´eclar´ees par l’application — les biblioth`eques utilis´ees par l’application — le niveau minimal du SDK Android pour que l’application puisse fonctionner Le listing 2.2 pr´esente le fichier AndroidManifest.xml d’une version d’Angry Birds Space. A la deuxi`eme ligne, sont d´efinis l’endroit o`u l’application sera ` install´ee (ici laiss´e au choix du syst`eme) et le nom du package de l’application. De la ligne 4 `a la ligne 11 sont ensuite list´ees les permissions demand´ees par l’application. Ici l’application demande par exemple acc`es `a la m´emoire externe, au r´eseau, aux informations li´ees au t´el´ephone, aux donn´ees de g´eolocalisation et au syst`eme de payement propos´e par Google. La ligne 13 d´ecrit comment l’application sera pr´esent´ee dans le menu des applications une fois install´ee : l’icˆone `a utiliser et le nom `a afficher. Le reste du fichier liste les composants de l’application et les informations qui y sont li´ees. L’application a ainsi quatre composants dont deux de type Activity, un de type Service et un de type BroadcastReceiver. Comme expliqu´e pr´ec´edemment, filtrer les messages Intent `a destination des composants de l’application est possible. Dans AndroidManifest.xml, cela se fait via les entr´ees intent-filter. Ainsi le premier Activity ne recevra que les intents dont l’attribut action a la valeur android.intent.action.MAIN et la cat´egorie est android.intent.category.LAUNCHER. Cela signifie que c’est ce composant qui sera lanc´e lorsque l’utilisateur cliquera sur l’icˆone de l’application dans le menu de son t´el´ephone. Quant au Broadcast Receiver, il ne r´eagira qu’aux intents dont l’attribut action vaut com.android.vending.billing.RESPONSE CODE Classes.dex Le code de chaque classe d’une application Java standard est stock´e dans des fichiers .class diff´erents. Sous Android, ce n’est pas le cas. Tout est stock´e dans un seul et unique fichier qui est classes.dex. De plus, si le code des applications Java est lui compil´e en bytecode Java, celui des applications Android est lui compil´e dans un autre format qui est le bytecode dalvik. C’est le contenu de ce fichier, ou plus pr´ecis´ement une version optimis´ee de celui-ci, qui sera interpr´et´e par la machine virtuelle Dalvik pour ex´ecuter l’application. Autres Un apk contient d’autres entr´ees telles que les r´epertoires META-INF, res, jni et lib. Le r´epertoire META-INF contient ainsi des fichiers li´es au contrˆole d’int´egrit´e de l’application et `a l’identification de son d´eveloppeur. Le r´epertoire res contient les ressources utilis´ees par l’application telles que des images, sons, etc.14 CHAPITRE 2. ETAT DE L’ART ´ Les r´epertoires jni et lib contiennent les biblioth`eques utilis´ees par l’application. Nous avons pr´esent´e dans cette section le syst`eme Android : le noyau, l’espace utilisateur en insistant sur les applications et la mani`ere dont ils coop`erent. Dans la section qui suit, nous pr´esentons les diff´erents m´ecanismes de s´ecurit´e prot´egeant ce syst`eme.2.1. SYSTEME ANDROID ` 15 1 5 9 21 22 27 32 33 36 37 40 42 43 44 Listing 2.2 – Fichier AndroidManifest.xml d’Angry Birds Space16 CHAPITRE 2. ETAT DE L’ART ´ 2.2 S´ecurit´e du syst`eme Android Nous avons ´ecrit dans la section pr´ec´edente que le noyau d’Android ´etait un noyau Linux avec un ensemble de modifications et d’ajouts. Une partie des m´ecanismes de s´ecurit´e offerts par Android proviennent ainsi du syst`eme Linux auxquels s’ajoutent des m´ecanismes propres `a Android. Ces m´ecanismes ont pour but de prot´eger les applications les unes des autres, les communications entre applications et les ressources sensibles disponibles dans le syst`eme. 2.2.1 M´ecanismes issus de Linux Le noyau d’Android est une version modifi´ee du noyau Linux. Il b´en´eficie ainsi des m´ecanismes offerts par les noyaux et syst`emes Linux : syst`eme multiutilisateur, contrˆole d’acc`es (lecture, ´ecriture et ex´ecution) bas´e sur les utilisateurs et isolation par processus. 2.2.1.1 Syst`eme multi-utilisateur et contrˆole d’acc`es Android supporte l’existence de plusieurs utilisateurs dans le syst`eme et utilise le m´ecanisme de contrˆole d’acc`es fourni par Linux. L’acc`es aux diff´erentes ressources dans le syst`eme est ainsi d´efini par des droits d’acc`es en lecture, ´ecriture et ex´ecution. Ces acc`es sont d´efinis pour trois entit´es : le propri´etaire, le groupe propri´etaire et les autres. Il existe un ensemble pr´ed´efini d’utilisateurs par d´efaut sur les syst`emes Android dont une partie est associ´ee au fonctionnement interne du syst`eme. Parmi ces utilisateurs nous pouvons citer root qui est l’utilisateur avec les droits les plus ´elev´es dans les syst`emes de type Linux et Android et l’utilisateur system qui est associ´e aux diff´erentes ressources n´ecessaires au fonctionnement du syst`eme tels que les biblioth`eques natives partag´ees. Tout au long de l’ex´ecution du syst`eme, la liste des utilisateurs peut ensuite ´evoluer. En effet, d’autres utilisateurs sont cr´e´es `a chaque fois qu’une application est install´ee sur le syst`eme 2 . Ces utilisateurs ont g´en´eralement des droits restreints `a savoir qu’ils ont uniquement acc`es aux ressources appartenant `a l’application `a laquelle ils sont associ´es. Cette restriction ´evite ainsi que les donn´ees de fichier appartenant `a une application ne soit lues ou modifi´ees par une autre application. 2.2.1.2 Isolation des applications En plus d’associer des utilisateurs diff´erents `a chaque application, Android les cloisonne ´egalement en les ex´ecutant dans des processus diff´erents et en leur attribuant des r´epertoires diff´erents dans lesquels les applications stockent les donn´ees qu’il manipulent. Les processus associ´es `a chaque application s’ex´ecutent avec les droits de l’utilisateur associ´e `a l’application et les r´epertoires appartiennent ´egalement `a l’utilisateur auquel l’application est associ´ee. Ce cloison- 2. Il existe une exception `a cette r`egle o`u une application peut demander `a partager le mˆeme identifiant d’utilisateur que d’autres applications. Voir la section 2.1.2.4.2.2. SECURIT ´ E DU SYST ´ EME ANDROID ` 17 Type Description normal Valeur par d´efaut des permissions. Elle est automatiquement accord´ee a toute application la demandant. dangerous N´ecessite une validation de la part de l’utilisateur afin d’accorder la permission. Exemple : read sms pour l’acc`es aux SMS. signature Permission accord´ee uniquement si l’application la demandant est sign´ee avec le certificat du d´eveloppeur ayant d´eclar´ee la permission. signatureOrSystem Permission accord´ee uniquement aux applications system, plus pr´ecis´ement celles dans la partition system, ou `a celles ayant ´et´e sign´ees avec le mˆeme certificat que l’application ayant d´eclar´ee la permission. Table 2.1 – Types de permission Android nement ´evite ainsi qu’une application interf`ere avec l’ex´ecution d’une autre application ou qu’elle modifie les donn´ees d’une autre application. 2.2.1.3 Chiffrement de la partition de donn´ees Depuis la version 3.0 d’Android, le syst`eme offre la possibilit´e de chiffrer la partition data. Cette partition contient l’ensemble des applications du t´el´ephone, `a l’exception des applications fournies par d´efaut que l’utilisateur ne peut d´esinstaller, ainsi que les donn´ees qu’elles manipulent. Le chiffrement est r´ealis´e grˆace au module dm-crypt [15] fourni par le noyau. 2.2.2 M´ecanismes propres `a Android 2.2.2.1 Permissions Android propose un ensemble de ressources sensibles aux applications install´ees sur le t´el´ephone (r´eseau, cam´era, syst`eme de g´eolocalisation, bluetooth, etc.). Pour les utiliser, une application devra d´eclarer les permissions correspondantes. Une application souhaitant lire les sms devra par exemple avoir la permission read sms. A l’installation, l’utilisateur valide les permissions de- ` mand´ees par l’application. Pour que l’installation se fasse, il doit toutes les accepter. Une fois l’application install´ee, plus aucune validation n’est n´ecessaire de la part de l’utilisateur. La seule exception est l’envoi de messages `a des num´eros surtax´es o`u l’utilisateur doit valider 3 chaque envoi. Il existe quatre types de permission que nous r´esumons dans le tableau 2.1. 3. fonctionnalit´e disponible depuis Android 4.218 CHAPITRE 2. ETAT DE L’ART ´ Name: AndroidManifest.xml SHA1-Digest: 9FiHXTmeVecbFb3enszaSlXIZp0= Name: res/layout/hello_activity.xml SHA1-Digest: BJz/aHbKT/Or0LwKJZ/jxN+WzmE= Name: resources.arsc SHA1-Digest: khWw+6lJ8dfajIaKkvbCuQ7YYzI= Name: classes.dex SHA1-Digest: +aR5lPSRcAvOrX+OhsxELXB1qGg= Figure 2.2 – Fichier MANIFEST.MF de l’application HelloActivity 2.2.2.2 Signature des applications Android requiert que chaque application soit sign´ee afin d’ˆetre install´ee sur le t´el´ephone. Les d´eveloppeurs signent ainsi leur application avec un certificat dont la cl´e priv´ee leur est propre. Les applications Android sont sign´ees avec l’outil jarsigner. Il prend en entr´ee une archive jar ou zip et un certificat. Il donne en sortie l’archive `a laquelle ont ´et´e ajout´es deux fichiers : un fichier avec l’extension .sf et un autre fichier avec l’extension .rsa ou .dsa selon les cl´es utilis´ees. L’entˆete du premier fichier correspond au hash du fichier MANIFEST.MF. Le reste de son contenu est similaire au fichier meta-inf/manifest.mf qui est pr´esent dans chaque archive jar. MANIFEST.MF recense pour chaque fichier pr´esent dans l’archive son nom, son hash et l’algorithme de hachage utilis´e. La figure 2.2 est le fichier manifest.mf de l’application HelloActivity fourni en exemple avec le kit de d´eveloppement Android. Pour chaque fichier pr´esent dans l’archive nous avons son nom, un algorithme de hachage et le hash du fichier. Le fichier .SF contient les mˆemes types d’information que MANIFEST.MF. Pour chaque fichier pr´esent dans l’archive nous avons une entr´ee constitu´ee du nom du fichier, un algorithme de hachage et un hash. Contrairement `a un hash dans MANIFEST.MF, il s’agit cette fois-ci du hash de l’entr´ee correspondant au fichier dans MANIFEST.MF. La figure 2.3 liste le contenu du fichier cert.sf de l’application HelloActivity. Le fichier .rsa lui contient la signature du fichier .sf ainsi que la cl´e publique correspondant `a la cl´e priv´ee utilis´ee pour la signature. La signature des applications Android a plusieurs objectifs. Elle sert `a filtrer les applications qui peuvent ˆetre install´es sur le t´el´ephone. Par d´efaut, seules les applications provenant de Google Play peuvent ˆetre install´ees sur le t´el´ephone. Il s’agit plus pr´ecis´ement des applications dont le d´eveloppeur a un certificat reconnu sur Google Play. Toute application avec une signature inconnue sera bloqu´ee `a l’installation `a moins que l’utilisateur n’autorise explicitement l’installation d’applications provenant d’autres plateformes. La signature identifie ´egalement toutes les applications d’un mˆeme d´eveloppeur. Si celui-ci est malveillant, il est ainsi possible d’enlever ses applications de Google2.2. SECURIT ´ E DU SYST ´ EME ANDROID ` 19 Signature-Version: 1.0 Created-By: 1.0 (Android SignApk) SHA1-Digest-Manifest: Qenbz+ZjLsHBpHWbAHMYhLpfies= Name: AndroidManifest.xml SHA1-Digest: uziqi6KmjjgyRnooQ7j5ZHIKVTw= Name: res/layout/hello_activity.xml SHA1-Digest: who+PyjjYjRHN6maNog494Cr+CE= Name: resources.arsc SHA1-Digest: WlDZ0LWZ+zrAmxUTKZuz99hUoZo= Name: classes.dex SHA1-Digest: QjwcQAkf4iVckku4qf7kiLRSndo= Figure 2.3 – Fichier .SF de l’application HelloActivity Play et des t´el´ephones des utilisateurs. La signature assure ´egalement que l’application n’a pas ´et´e modifi´ee par une tierce personne avant d’ˆetre publi´ee. La v´erification se fait `a l’installation de l’application. Le syst`eme v´erifie que le fichier .SF a bien ´et´e g´en´er´e par le d´eveloppeur. Il v´erifie ensuite que le fichier MANIFEST.MF n’a pas ´et´e modifi´e en comparant son empreinte avec celui list´e dans le fichier .SF. Il v´erifie enfin l’int´egrit´e des fichiers dans l’archive en comparant leur empreite avec les valeurs list´ees dans le fichier MANIFEST.MF. L’installation est arrˆet´ee si une incoh´erence est d´etect´ee. Par d´efaut, les applications Android tournent avec des UIDs diff´erents dans des processus distincts. Un d´eveloppeur peut cependant vouloir faire tourner ses applications avec le mˆeme UID ou dans un seul processus. Il suffit pour cela qu’il le d´eclare dans le fichier AndroidManifest.xml de son application. Plus pr´ecis´ement, le d´eveloppeur d´eclare un alias d’UID qui sera partag´e s’il souhaite utiliser le mˆeme UID pour plusieurs de ses applications. S’il souhaite faire tourner ses applications au sein d’un mˆeme processus, il d´eclare un alias de nom de processus. Pour ´eviter que des d´eveloppeurs ne s’attribuent ´egalement le mˆeme UID ou ne s’attache au processus faisant tourner les applications d’un autre d´eveloppeur, le syst`eme v´erifie que l’application demandant `a partager le mˆeme UID ou `a ˆetre ex´ecut´e dans le processus qu’une autre application soit sign´ee par le mˆeme d´eveloppeur. 2.2.2.3 Analyse des applications Google analyse r´eguli`erement les applications propos´ees en t´el´echargement sur Google Play ainsi que celles en instance d’ˆetre install´ees sur les t´el´ephones des utilisateurs. Si aucune information sur la nature exacte des analyses n’est fournie20 CHAPITRE 2. ETAT DE L’ART ´ par Google, nous savons qu’une analyse statique et dynamique des applications sont faites pour d´etecter des motifs synonymes de menace dans l’application ou des comportements malveillants. J. Oberheide et C. Miller ont montr´e dans [78] que les applications soumises sur Google Play sont ex´ecut´ees dans une machive virtuelle et qu’il ´etait possible de construire un profil de cette machine. 2.2.2.4 Protection de l’appareil et de ses donn´ees Android poss`ede un ensemble d’outils destin´es aux d´eveloppeurs du syst`eme. Parmi ces outils nous pouvons citer adb et fastboot. La commande adb permet de communiquer avec un ´emulateur Android ou un t´el´ephone. Parmi les fonctions propos´ees, il y a l’ouverture d’un shell distant sur le t´el´ephone, l’installation ou la suppression d’application et le transfert de fichier. Pour prot´eger le t´el´ephone de tout usage malveillant de ces outils, la communication est possible uniquement si le mode debug est activ´e. Une authentification par cl´e de l’ordinateur aupr`es du t´el´ephone s’ajoute ´egalement `a cela depuis la version 4.2 d’Android afin de filtrer les machines pouvant communiquer avec le t´el´ephone via adb. La commande fastboot sert `a effacer/remplacer le contenu des diff´erentes partitions sur le t´el´ephone. Afin de l’utiliser, l’utilisateur doit dans un premier temps d´ebloquer cette fonctionnalit´e au d´emarrage et ce processus de d´eblocage implique la suppression du contenu de la partition data du t´el´ephone. Cette partition contient les donn´ees de l’utilisateur ainsi que des diff´erentes applications. L’action de remplacer le contenu d’une partition est souvent d´esigner par l’expression flasher une image, l’image ´etant le nouveau contenu de la partition. Un attaquant d´esirant ainsi remplacer une partie des composants logiciels du syst`eme via fastboot ne pourra ainsi acc´eder aux donn´ees de l’utilisateur. 2.2.2.5 Administration de l’appareil Android propose depuis sa version 2.2 une API permettant de d´evelopper des applications afin d’administrer les t´el´ephones [83]. L’API permet de renforcer la politique sur les mots de passe (ex : taille, expiration et nombre de tentatives), imposer le chiffrement des partitions, activer / d´esactiver la cam´era (fonctionnalit´e disponible depuis Android 4.0), demander la cr´eation d’un nouveau mot de passe, verrouiller le t´el´ephone et remettre le t´el´ephone `a la configuration d’usine. Nous avons pr´esent´e dans cette section les m´ecanismes de s´ecurit´e d’Android. Ces m´ecanismes ont pour but de prot´eger les applications, les ressources qu’elles utilisent et les communications entre ces processus. Ces m´ecanismes ne sont cependant pas parfaits et nous montrons dans la section qui suit leur limites ainsi qu’un aper¸cu des menaces que repr´esentent les malware Android.2.3. LIMITES DES MECANISMES DE S ´ ECURIT ´ E ANDROID ´ 21 2.3 Limites des m´ecanismes de s´ecurit´e Android 2.3.1 Abus de permission Les permissions donnent acc`es aux ressources sensibles du t´el´ephone aux applications. Si l’utilisateur souhaite installer une application, il doit lui accorder toutes les permissions qu’elle a demand´ees. Si les permissions filtrent l’acc`es aux ressources sensibles, il n’existe cependant aucune v´erification au niveau de l’usage de ces ressources. Seule la confiance aux d´eveloppeurs de l’application permet de s’assurer qu’il n’y aura aucun abus. Les attaques les plus simples utilisent ainsi les permissions de mani`ere abusive et c’est le cas de la plupart des malware ayant pour but de faire fuir des donn´ees sensibles du t´el´ephone. Un exemple r´ecent est une application ayant ´et´e d´etect´ee comme un logiciel espion 4 qui cible des manifestants `a Hong Kong [26]. L’application demande un ensemble assez large de permissions pour espionner les utilisateurs des t´el´ephones sur lesquels l’application est install´ee. Les permissions demand´ees donnent acc`es aux SMS, aux appels, `a la localisation de l’utilisateur, au micro pour enregistrer l’utilisateur, etc. Une application avec trop de permissions peut paraˆıtre suspecte aux yeux des utilisateurs avertis. Afin de ne pas ´eveiller la suspicion des utilisateurs, une solution pour les d´eveloppeurs de malware consiste `a utiliser d’autres applications pr´esentes sur le syst`eme pour mener l’attaque ou `a diviser l’attaque entre plusieurs applications qui collaboreront pour ex´ecuter l’attaque. 2.3.2 Permissions : attaques par d´el´egation et attaques par collusion Une attaque par d´el´egation [49] consiste `a d´el´eguer l’ex´ecution de la tˆache n´ecessitant une permission que l’application malveillante ne poss`ede pas `a une autre application qui elle la poss`ede. Par exemple, une application n’ayant pas la permission de communiquer sur le r´eseau pourrait se servir du navigateur pour poster des informations ou t´el´echarger des fichiers. Les ´echantillons de BadNews [91] font par exemple appel au navigateur du t´el´ephone afin de lancer le t´el´echargement d’applications sur le t´el´ephone. Une attaque par collusion consiste en une coop´eration entre plusieurs applications pour mener une attaque. Il n’existe aucun malware utilisant ce type d’attaque `a notre connaissance. Cependant, J. Boutet et T. Leclerc ont montr´e la faisabilit´e d’une telle attaque dans [28]. 2.3.3 Communication entre composants via les intents Les intents sont des messages ´echang´es entre les composants des applications pour transmettre des requˆetes. La possibilit´e d’envoyer des intents entre deux deux composants de deux applications diff´erentes apporte une surface d’attaque suppl´ementaire. Dans [34], Chin et al. d´ecrivent en se basant sur 4. Empreinte MD5 :15e5143e1c843b4836d7b6d5424fb4a522 CHAPITRE 2. ETAT DE L’ART ´ leur analyse du fonctionnement des ^ıntents des sc´enarios d’attaques qui pourraient exploiter cette surface d’attaque afin d’espionner les ´echanges de message entre application, les bloquer, les modifier, ´elever ses privil`eges et influencer sur le comportement d’une application. Interception des messages diffus´es dans le syst`eme Les broadcast intents sont des messages diffus´es dans tout le syst`eme. Ils peuvent ainsi avoir un ou plusieurs destinataires. L’une des vuln´erabilit´es qu’introduit ce type de communication est la possibilit´e d’observer les informations diffus´ees dans le syst`eme et ´eventuellement les intercepter, bloquer ou modifier. Lorsqu’une application diffuse un broadcast intent, elle d´efinit un ensemble d’attributs qui permettent au syst`eme d’identifier les composants BroadcastReceiver pr´esents dans le syst`eme qui attendent ce type de message. Pour observer les messages attendus par le composant BroadcastReceiver d’une application, il suffit ainsi `a une application malveillante de d´eclarer un composant du mˆeme type avec le mˆeme intent-filter. Pour observer les messages re¸cus par le composant BillingReceiver d´eclar´e dans le listing 2.2, une application malveillante n’a qu’`a d´eclarer un composant du mˆeme type en pr´ecisant que ce composant n’accepte que les intents avec un attribut action dont la valeur associ´ee est com.android.vending.billing.RESPONSE CODE. Un broadcast intent peut ˆetre transmis de mani`ere simultan´e `a tous les destinataires ou en suivant un ordre. Dans le cas de ce dernier, l’intent est transmis d’un composant `a l’autre dans un ordre d´efini par le syst`eme. Chaque composant BroadcastReceiver peut ainsi modifier ou bloquer les informations transmises avant que le message ne soit transmis au prochain destinataire. Si une application malveillante se trouve au milieu de la chaˆıne de transmission, elle peut donc modifier le contenu de l’intent ´emis et envoyer de fausses donn´ees aux composants en attente du message. Elle peut ´egalement d´ecider de ne pas faire suivre le message et empˆecher les autres composants de le recevoir. D´etournement des intents `a destination des composants Activity et Service Lorsqu’une application ´emet un intent, il peut soit d´efinir explicitement le destinataire soit laisser le syst`eme le d´efinir `a sa place. Dans le deuxi`eme cas, l’´emetteur n’a aucune garantie sur l’identit´e du destinataire ce qui donne ainsi la possibilit´e de d´etourner les messages du destinataire l´egitime. Une application malveillante souhaitant intercepter un implicit intent n’a donc qu’`a d´eclarer un composant ayant un intent filter correspondant `a l’intent qu’il souhaite d´etourner. Par exemple, une application malveillante souhaitant d´etourner le partage de page effectu´ee dans le listing 2.1 n’a qu’`a d´eclarer un composant Activity avec un intent filter correspondant aux attributs de l’intent `a intercepter : un attribut action et un attribut data auxquels sont associ´es respectivement les valeurs ACTION SEND et text/plain.2.3. LIMITES DES MECANISMES DE S ´ ECURIT ´ E ANDROID ´ 23 Si le d´etournement est th´eoriquement possible, il n’a en r´ealit´e qu’une probabilit´e de succ`es. Lorsqu’il existe plusieurs destinataires possibles de l’intent, un choix qui est ind´ependant de l’application malveillante est effectu´e. Si l’intent a ´et´e ´emis pour un composant de type Activity, le syst`eme demande `a l’utilisateur de choisir le destinataire parmi la liste des applications pouvant recevoir l’intent. Si l’intent a ´et´e ´emis pour un composant de type Service, le syst`eme effectuera lui-mˆeme le choix et ce choix est effectu´e de mani`ere al´eatoire. Vol/abus des permissions Nous avons ´ecrit en section 2.1.2.2 que les intents pouvaient ´egalement servir `a transmettre des permissions pour acc´eder `a des donn´ees au destinataire du message. Positionner le flasg FLAG GRANT WRITE URI PERMISSION donne par exemple l’acc`es en lecture aux donn´ees li´ees `a l’intent au destinataire du message. Une application malveillante interceptant des intents transmettant des permissions peut ainsi abuser de ces permissions et voler ou modifier les donn´ees auxquelles les permissions donnent acc`es. Intents malveillants Le but de cette attaque est d’envoyer des requˆetes malveillantes `a traiter par un composant cible. Un composant qui peut recevoir des intents d’autres applications n’est pas seulement expos´e aux applications que son d´eveloppeur pensait servir mais `a toutes applications sur le syst`eme. Cette exposition `a toutes les applications du syst`eme offre ainsi une surface d’attaque aux applications malveillantes qui elles aussi peut demander au composant de traiter une requˆete, mˆeme si cette requˆete est malicieuse. Les navigateurs web sous Android ont par exemple un composant Activity qui ouvre les URL `a la demande d’autres applications. Cette fonctionnalit´e peut ainsi ˆetre d´etourn´ee par une application qui n’a pas acc`es au r´eseau afin de faire fuir des donn´ees ou t´el´echarger des fichiers. Pour cela l’application malveillante ´emettra un intent `a destination du navigateur afin que ce dernier ouvre une adresse web. Les ´echantillons de BadNews [91] utilisent par exemple cette approche afin de t´el´echarger des applications sur le t´el´ephone. 2.3.4 Failles logicielles : ´el´evation de privil`ege Comme tout programme, le syst`eme Android a ´egalement des failles logicielles. Exploiter certaines d’entre elles permet d’´elever les privil`eges d’une application et ainsi ex´ecuter des op´erations sensibles que nous ne pouvions faire. Obtenir les droits root permet par exemple de modifier le contenu de la partition system sous Android pour installer des applications syst`eme ou les remplacer. Le noyau Android ´etant bas´e sur un noyau Linux, il h´erite ainsi de ses vuln´erabilit´es. Certaines d’entre elles [5, 4] ont par exemple ´et´e exploit´ees obtenir des acc`es root sur les t´el´ephones.24 CHAPITRE 2. ETAT DE L’ART ´ Des failles permettant d’´elever les privil`eges des applications existent ´egalement dans l’espace utilisateur. D’apr`es les travaux de Y. Zhou et X. Jiang [113], six vuln´erabilit´es permettant d’´elever les privil`eges des applications existaient au moment de leur analyse (voir tableau 2.2) et quatre d’entre elles ´etaient effectivement utilis´ees par les malware pour ´elever leurs privil`eges : Asroot [1], exploid [31], RATC / Zimperlich [93] et GingerBreak [32]. Plus r´ecemment, J. Forristal a pr´esent´e `a la Black Hat 2013 une vuln´erabilit´e [51] concernant la v´erification des signatures des applications Android `a l’installation. La vuln´erabilit´e permet d’installer une version modifi´ee d’une application dont la signature reste celle de la version originale. Si la vuln´erabilit´e ne permet pas d’obtenir les droits root (aucune application ne tourne avec l’UID root), elle rend cependant caduque les protections offertes par la signature en section 2.2.2. Un d´eveloppeur malveillant peut faire ex´ecuter son code avec les mˆemes droits que l’application originale qu’il a modifi´ee. Il peut ´egalement faire tourner son code dans le mˆeme processus ou avec le mˆeme UID qu’une autre application. S’il n’est pas possible d’obtenir les droits root, il est cependant possible d’obtenir les droits des applications system. Ces applications ont acc`es `a plus de permissions que les applications tierces et de plus sont persistantes sur le syst`eme. Un utilisateur ne peut les enlever sans avoir un acc`es root sur son t´el´ephone. Bien que Google mette `a jour r´eguli`erement le code d’Android, les constructeurs eux mettent plus de temps `a proposer des mises `a jour pour leur t´el´ephone. La fenˆetre d’exploitation des vuln´erabilit´es est ainsi bien plus large que sur les ordinateurs. Nous avons pr´esent´e dans cette section, les limitations des m´ecanismes de s´ecurit´e sous Android. Ces limitations peuvent ˆetre class´ees en trois groupes. Le premier groupe concerne les limites de la s´ecurit´e offerte par les permissions. Le second concerne les risques introduits par les communications entre composants via les intents. Le troisi`eme groupe concerne les failles logicielles dans le code d’Android qui permettent d’´elever les privil`eges des applications dans le syst`eme. Dans la section suivante, nous pr´esentons les malware Android et les menaces qu’ils repr´esentent. 2.4 Malware Android 2.4.1 D´efinitions Nous appelons malware un programme ou un code dont le but est de nuire `a un syst`eme donn´e. Dans le reste du document nous ferons souvent usage des termes ´echantillon de malware et famille de malware. Un ´echantillon d’un malware est une application, comprendre ici application Android correspondant `a un fichier apk, qui contient ce malware. Quant `a une famille de malware, il s’agit de l’ensemble des ´echantillons d’un malware. Analyser un malware revient ainsi2.4. MALWARE ANDROID 25 `a analyser un ou plusieurs de ses ´echantillons afin d’extraire des informations li´ees au malware et d´etecter un malware revient `a d´ecider si une application donn´ee est un ´echantillon d’un malware. Les premiers travaux qui ont consist´e `a dresser un bilan des menaces que repr´esentent les malwares Android sont les travaux de Y. Zhou et X. Jiang dans [113]. Leurs travaux sont bas´es sur l’analyse de plus de 1200 ´echantillons de malware qu’ils ont collect´e de 2010 `a 2011. Dans ce qui suit, nous pr´esentons les r´esultats de cette analyse et l’enrichissons avec une analyse plus r´ecente bas´ee sur les menaces que repr´esentent les malware Android en 2013. 2.4.2 Malwares Android : 2010 `a 2011 [113] M´ethode d’infection Pour infecter les t´el´ephones des utilisateurs, les d´eveloppeurs de malware ajoutent leur code malveillant `a des applications existantes et proposent leur version modifi´ee sur des plateformes de t´el´echargement : Google Play ou toute autre plateforme alternative. Les applications infect´ees sont pr´esent´ees comme une version gratuite d’une application payante ou des versions avec plus de fonctionnalit´es. 86% des ´echantillons r´ecolt´es sont ainsi des applications originales auxquelles un code malveillant a ´et´e ajout´e. Le type d’application infect´ee est vari´e : application payante, jeux populaires, outils tels que des mises `a jour de s´ecurit´e ainsi que des applications pour adultes. Un des ´echantillons de DroidKungFu2 est par exemple une version modifi´ee d’une application simulant un scanner d’empreinte pour d´everrouiller le t´el´ephone. En arri`ere plan, le code malveillant exploite une vuln´erabilit´e [92, 93] pour ´elever ses privil`eges et installer des binaires sur le t´el´ephone `a l’insu de l’utilisateur. Tout le code malveillant ne se trouve pas forc´ement ajout´e `a l’application originale. Certains ´echantillons ne contiennent ainsi qu’une partie du code malveillant dont le reste sera r´ecup´er´e `a l’ex´ecution. Ce dernier peut ˆetre stock´e en tant que ressource de l’application ou sur un serveur distant que l’application infect´ee devra t´el´echarger. L’avantage ´etant que le code malveillant ne pourra ˆetre d´etect´e lors de la soumission de l’application sur les plateformes de t´el´echargement. Les ´echantillons d’AnserverBot [112] ont ainsi une charge cach´ee en tant qu’image dans les ressources des applications et r´ecup`erent ´egalement une autre application malveillante sur un serveur distant. D´eclenchement du code malveillant Le d´eclenchement du code malveillant ne se fait pas forc´ement d`es le lancement de l’application. Le code malveillant peut attendre des ´ev`enements sp´ecifiques tels que l’arriv´ee d’un sms ou l’´ecoulement d’un certain laps de temps avant de s’ex´ecuter. Parmi les ´ev`enements les plus utilis´es pour d´eclencher le code malveillant, nous pouvons citer la fin d’initialisation au d´emarrage du26 CHAPITRE 2. ETAT DE L’ART ´ Programme vuln´erable Exploit Date Malware les utilisant Noyau Asroot 2009/08/16 Asroot init (ď 2.2) Exploid 2010/07/15 DroidDream, zHash, DroidKungFu* adbd (ď 2.2.1) zygote (ď 2.2.1) RATC / Zimperlich 2010/08/21 2011/02/24 DroidDream, BaseBridge, DroidKungFu, DroidDeluxe, DroidCoupon ashmem (ď 2.2.1) KillingInTheNameOf 2011/01/06 Aucun vold (ď 2.3.3) GingerBreak 2011/04/21 GingerMaster libsysutils (ď 2.3.6) zergRush 2011/10/10 Aucun Table 2.2 – Exploits root connus et leur usage par les malware Android de 2010 `a 2011 syst`eme. Quand le syst`eme est prˆet `a ex´ecuter des applications Android, il le signale en envoyant un intent avec le message boot completed `a tous les composants BroadcastReceiver `a l’´ecoute cet ´ev`enement. Les autres messages ´ev`enements servant de d´eclencheur sont la r´eception de message, les appels, les ´ev`enements li´es aux applications (ex : ajout, suppression, mise `a jour et red´emarrage), l’´etat de la batterie, l’´etat de la connectivit´e r´eseau, et des ´ev`enements syst`emes (ex : carte sim remplie, changement de clavier). Le d´eveloppeur du code malveillant ajoute un composant de type BroadcastReceiver pour intercepter l’un de ces ´ev`enements et ex´ecuter par la suite le code malveillant. Actions effectu´ees Les actions effectu´ees par les codes malveillants peuvent ˆetre r´eparties dans quatre groupes : ´el´evation de privil`ege, contrˆole `a distance, charge financi`ere et vol de donn´ees. Comme ´evoqu´e en section 2.2.2, Android poss`ede des vuln´erabilit´es qui sont exploit´ees par les d´eveloppeurs malveillants pour effectuer des op´erations sensibles. Le tableau 2.2 montre d’ailleurs une tendance `a utiliser les exploits exploid [31], RageAgainstTheCage [92] et Zimperlich [93] afin ´elever les privil`eges des applications malveillantes durant l’attaque. Le but de cette ´el´evation de privil`eges est d’effectuer des op´erations sensibles telles que monter la partition system avec l’option d’´ecriture pour y installer de nouvelles applications. 1172 ´echantillons soit 93% des ´echantillons analys´es sont contrˆolables `a distances. Plus pr´ecis´ement, 1171 ´echantillons utilisent le protocole HTTP pour recevoir des commandes des serveurs de commande et contrˆole C&C. Les adresses2.4. MALWARE ANDROID 27 des serveurs sont stock´ees en clair ou chiffr´ees dans le code. En dehors des ´el´evations de privil`eges et communication avec des serveurs de C&C, les ´echantillons analys´es peuvent imputer des charges financi`eres `a l’utilisateur. Android tournant principalement sur les smartphones, les applications ont ainsi acc`es aux fonctions d’appels et de sms. 4.4% des ´echantillons ´etudi´es envoient ainsi des messages `a des num´eros surtax´es. Les num´eros sont soit stock´es en dur dans le code de l’application soit r´ecup´er´es `a partir des serveurs de C&C. En plus des actions pr´ec´edentes, les malware r´ecup`erent ´egalement les donn´ees sensibles sur le t´el´ephone. Les donn´ees cibl´ees sont principalement les sms, la liste de contact, et les informations sur le compte de l’utilisateur. SndApps [62] collecte par exemple les adresses courriel de l’utilisateur et les envoie vers un serveur distant. Evolution des malware ´ Si les premiers malware Android sont simples, l’analyse effectu´ee dans [113] montre que les techniques utilis´ees tendent `a se complexifier : charge utile, techniques contre l’analyse d’application, serveurs C&C. Tout le code malveillant est int´egr´e dans une mˆeme application dans les premiers malware. L’analyse des ´echantillons r´ecolt´es montre une tendance `a le diviser, mettre une partie dans l’application servant `a l’infection et le reste des morceaux dans une ou plusieurs charges utiles. Ces charges sont int´egr´ees directement dans l’application ayant servi `a infecter le t´el´ephone ou t´el´echarger et apr`es l’installation de l’application. Les ´echantillons de DroidKungFu ont ainsi deux charges utiles cach´ees en tant que ressources des applications infect´ees qui seront install´ees dans la partition system une fois l’´echantillon lanc´e. L’installation de ces charges sur le t´el´ephone offre une pr´esence constante sur le t´el´ephone mˆeme si la premi`ere application est enlev´ee du t´el´ephone. De plus, si les applications sont install´ees sur la partition syst`eme, il n’existe aucun moyen pour l’utilisateur de les enlever sans avoir les droits root sur le t´el´ephone. Afin d’´eviter toute d´etection, les d´eveloppeurs de malware utilisent diverses techniques telles que le chiffrement des charges utiles, le chiffrement de certaines valeurs utilis´ees par le malware, l’usage de techniques d’obfuscation de code et l’usage de code natif. Le chiffrement permet de cacher la nature exacte des donn´ees manipul´ees (ex : adresses des serveur de C&C) par l’application et r´eduit ainsi la possibilit´e de d´etection. Les d´eveloppeurs de DroidKungFu1 chiffrent ainsi les charges utiles de leur malware afin que leur malware ne soit d´etect´e facilement. Si une cl´e de chiffrement diff´erente est utilis´ee par chaque ´echantillon, l’analyse sera encore plus compliqu´ee. Certains d´eveloppeurs de malware obfusquent ´egalement leur code afin de complexifier son analyse [39]. Ils modifient par exemple le nom des m´ethodes et des classes Java de l’application. Il est cependant `a noter que le kit de d´eveloppement Android (Android SDK) contient un outil fournissant le mˆeme type de service [87]. L’usage de code natif complexifie ´egalement l’analyse des applications. En effet, la plupart des outils d’analyse d’application Android se concentrent uniquement sur le code28 CHAPITRE 2. ETAT DE L’ART ´ ´ecrit en Java car c’est le langage principal pour d´evelopper une application Android. En utilisant du code natif, les d´eveloppeurs de malware se donnent ainsi la possibilit´e de cacher une partie du code malveillant durant l’analyse. Certains malware int`egrent ´egalement des modules cens´es pr´evenir toute d´etection. Les ´echantillons d’AnserveBot analysent ainsi son environnement d’ex´ecution `a la recherche d’antivirus pour Android. De plus, ces ´echantillons tirent ´egalement profit du chargement dynamique de code [36]. Le code des applications Android se trouve dans le fichier classes.dex de leur apk. Ce m´ecanisme permet de charger du code en dehors de ce fichier et ce de mani`ere dynamique rendant l’analyse de l’application plus difficile. D’autres malwares v´erifient ´egalement que le code n’a pas ´et´e modifi´e pour d´etecter toute tentative d’analyse du code. AnserveBot v´erifie par exemple l’int´egrit´e de son code avant de lancer le code malveillant. Enfin, l’analyse montre ´egalement l’usage des serveurs de C&C afin de contrˆoler le comportement des ´echantillons de malware. Le comportement exact des premiers malware sont dict´es `a l’avance par leur d´eveloppeur. Durant leur analyse, Y Zhou et X Jiang ont cependant constat´e que dans le cas de certains malware, leur comportement ´etait plutˆot dict´e par un serveur distant. Le malware se connectait ainsi p´eriodiquement au serveur qui lui envoyait par la suite l’action qu’il devait ex´ecuter. Sur les 49 malwares ´etudi´es, 27 utilisent ainsi un serveur de C&C pour recevoir les commandes `a ex´ecuter sur le t´el´ephone infect´e. L’usage de telles approches permet aux d´eveloppeurs de garder une flexibilit´e sur les diff´erentes actions `a ex´ecuter et les faire ´evoluer en cas de besoin. 2.4.3 Malwares Android en 2013 Si les travaux de [113] pr´esent´es pr´ec´edemment concernent uniquement les malwares de 2010 `a 2011, la r´ecente analye de V. Chebyshev et R. Unuchek dans [33] montre une continuit´e dans les types d’action men´ee par les malware. La distribution des malwares se fait toujours via les plateformes de t´el´echargement ou les serveurs de C&C. A cela s’ajoute, l’usage des techniques telles ` que le drive-by download qui consiste `a faire t´el´echarger automatiquement puis installer une application au t´el´ephone lorsque l’utilisateur visite une page web. L’usage de techniques contre les protections anti-malware s’intensifie ´egalement. L’´etude montre ainsi que les d´eveloppeurs de malware continuent leur investissement dans les diverses techniques d’obfuscation de code. Un outil commercial d’obfuscation de code aurait ´et´e par exemple utilis´e sur Opfak.bo et Obad.a [98]. Obad.a est consid´er´e comme le malware Android le plus complexe `a ce jour. Parmi les caract´eristiques de ce malware, nous pouvons citer l’introspection, le chiffrement de chaine des chaines de caract`eres, l’exploitation de vuln´erabilit´es qui affectent le syst`eme Android et dex2jar qui est un outil utilis´e pour analyser les applications Android. Plus pr´ecis´ement, cet outil transforme le bytecode dalvik en bytecode Java permettant par la suite d’obtenir un code Java “´equivalent“. Selon wikibooks [12], “la r´eflexion permet l’introspection des classes, c’est-`a-dire de charger une classe, d’en cr´eer une instance et d’acc´eder aux membres statiques ou non (appel de m´ethodes, lire et ´ecrire les attributs)2.4. MALWARE ANDROID 29 sans connaˆıtre la classe par avance“. Le listing 2.3 pr´esente un bout code en Java utilisant la r´eflexion et son ´equivalent sans r´eflexion. . La deuxi`eme ligne initialise la variable foo en une instance de la classe Foo et est ´equivalente `a la septi`eme ligne. La troisi`eme et la quatri`eme lignes initialisent r´ecup`erent la m´ethode hello de foo et l’invoque. Elles correspondent `a la huiti`eme ligne. 1 // Avec reflexion 2 Object foo = Class.forName("complete.classpath.and.Foo"). 3 newInstance(); 4 Method m = foo.getClass().getDeclaredMethod("hello", 5 new Class[0]); 6 m.invoke(foo); 7 8 // Sans reflexion 9 Foo foo = new Foo(); 10 foo.hello(); Listing 2.3 – Exempe de code Java avec et sans r´eflexion L’usage des vuln´erabilit´es reste toujours d’actualit´e au niveau des malware. Les raisons principales de cet usage est la n´ecessit´e d’effectuer des actions sensibles sans validation de l’utilisateur (ex : installation d’application sur le t´el´ephone) ou le maintien d’une pr´esence pertinente du malware sur l’appareil (ex : installation d’une application dans la partition system afin d’empˆecher sa d´esinstallation 5 ). Parmi les vuln´erabilit´es ´emun´er´es par les auteurs, il y a la vuln´erabilit´e Master Key [51] et celle li´ee aux applications avec les droits d’administration sur le t´el´ephone. La vuln´erabilit´e Master Key permet de modifier une application existante sans que la modification ne soit d´etect´ee lors de la v´erification de la signature de l’application (section 2.2.2.2). Pour exploiter cette vuln´erabilit´e, le d´eveloppeur malveillant ajoute de nouveaux fichiers `a l’apk tel que chaque nouveau fichier ait le mˆeme nom qu’un fichier existant dans l’apk d’origine. Il peut par exemple ajouter un autre fichier nomm´e classes.dex. Une fois les nouveaux fichiers ajout´es, il publie l’apk modifi´e tout en gardant la signature de l’apk d’origine. A cause de la vuln´erabilit´e, le syst`eme ne remarque pas l’existence des doublons ` dans l’apk et v´erifie uniquement l’int´egrit´e des fichiers qui ´etaient pr´esents dans l’apk d’origine tandis qu’`a l’installation il installera les fichiers ajout´es par le d´eveloppeur malveillant. Cette vuln´erabilit´e a deux cons´equences directes. La premi`ere est le vol de l’identit´e des d´eveloppeurs dont l’application a ´et´e modifi´ee. En gardant la signature de l’application originale, le d´eveloppeur malveillant se cache derri`ere l’identit´e des d´eveloppeurs des applications modifi´ees. Le risque pour ces derniers est d’ˆetre accus´e `a tord comme ´etant malveillant et voir toutes leurs applications supprim´ees des plateformes de t´el´echargement tels 5. Un utilisateur ne peut d´esinstaller les applications dans la partition system car cette partition est mont´ee en lecture seule30 CHAPITRE 2. ETAT DE L’ART ´ que Google Play. La deuxi`eme cons´equence de cette vuln´erabilit´e est la possibilit´e de contourner toutes les m´ecanismes de s´ecurit´e bas´ees sur les signatures de applications. En plus de servir `a la v´erification de l’int´egrit´e des applications `a leur installation, les signatures servent ´egalement `a appliquer des contraintes sur certaines demandes des applications. Ils peuvent par exemple servir `a restreindre les applications `a qui une permission peut ˆetre accord´ee (tableau 2.1) ou les applications qui ont le droit de partager le mˆeme utilisateur. En gardant la signature de l’application qu’il a modifi´ee, le d´eveloppeur malveillant s’assure ainsi que sa version modifi´ee de l’application ait les mˆemes privil`eges que l’application d’origine. La deuxi`eme vuln´erabilit´e permet de garder une pr´esence persistante sur le t´el´ephone grˆace aux droits d’administration. Lorsqu’une application obtient les droits d’administration sur le t´el´ephone, il devient impossible pour l’utilisateur de lui r´evoquer ces droits ou le d´esinstaller. Si jamais l’utilisateur tentait de r´evoquer les droits d’administration, le syst`eme se contentait de masquer le fait que l’application poss`ede ces droits mais ne les r´evoquait pas. L’application reste ainsi install´ee sur le t´el´ephone avec les droits d’administration sans que l’utilisateur ne soit au courant. Si les diff´erents types d’attaque pr´esent´es dans [113] restent toujours d’actutait´e, l’analyse montre cependant une tendance pour les attaques ayant un impact financier sur l’utilisateur. Aux applications abusant des services de SMS en envoyant des messages `a des num´eros surtax´es s’ajoutent ainsi les applications se faisant passer pour des applications bancaires afin de voler les donn´ees bancaires des utilisateurs telles que leur num´ero de compte. 2.5 Renforcement de la s´ecurit´e sous Android 2.5.1 Protection des ressources sensibles 2.5.1.1 TaintDroid Dans [46], Enck et al. pr´esentent TaintDroid une version modifi´ee d’Android capable de suivre les flux d’information dans le syst`eme. Le but de leur travail est d’´etudier si les applications Android font fuir des donn´ees sensibles vers des entit´es distantes. Pour cela, ils s´electionnent un ensemble d’informations qu’ils jugent sensibles telles que la liste de contact et les donn´ees de g´eolocalisation et observent comment elles se propagent dans le syst`eme. Ils ont analys´e 30 des applications les plus populaires de Google Play et ont montr´e que 2{3 d’entre elles faisaient fuir des informations sensibles vers des serveurs distants. Pour suivre les flux d’information dans le syst`eme, ils utilisent une m´ethode dite de tainting qui consiste `a marquer les informations sensibles afin d’en suivre la propagation. Chaque fois qu’une information sensible se propage, le conteneur destination re¸coit la marque de l’information sensible pour caract´eriser son nouveau contenu. Dans TaintDroid, le suivi de flux d’information se fait `a diff´erents niveaux : `a l’int´erieur de l’application, entre les applications et entre applications et fichiers du syst`eme. Pour suivre les flux `a l’int´erieur des applications, Enck et2.5. RENFORCEMENT DE LA SECURIT ´ E SOUS ANDROID ´ 31 al. ont modifi´e la machine virtuelle Dalvik. Lorsqu’une application Android est ex´ecut´ee, son code est interpr´et´e par la machine virtuelle Dalvik. TaintDroid suit ainsi les flux d’information entre les conteneurs d’information que la machine Dalvik utilisent. Ces conteneurs sont les variables locales d’une m´ethode, ses param`etres, les champs statiques d’une classe, les champs des instances d’une classe et les tableaux. A chaque fois qu’une instruction d´ecrivant un flux d’in- ` formation explicite entre deux ou plusieurs conteneurs est interpr´et´ee par la machine virtuelle Dalvik, TaintDroid consid`ere que le conteneur destination du flux contient le m´elange des informations provenant des conteneurs source. Par exemple, l’affectation `a la variable vs de la valeur de la variable vd une mise `a jour de la marque associ´ee vs. Lorsque cette affectation est interpr´et´ee par la machine virtuelle Dalvik, TaintDroid consid`ere que vs les informations contenues dans vs ont ´et´e remplac´ees par celles dans vd et TaintDroid affecte ainsi la marque associ´ee `a vd `a vs. Le suivi de flux d’information entre les applications et entre une application et un fichier est plus simple. Le suivi de flux d’information entre les applications est assez trivial. Comme il existe un ensemble de classes et de m´ethodes Java fourni par Android pour impl´ementer les m´ecanismes de communication, TaintDroid se contente de marquer les objets avec un contenu sensible quand ils sortent d’une application et `a marquer le destinataire d’une information provenant d’une application externe `a l’application. Les marques de chaque conteneur sont stock´es dans une m´emoire adjacente au conteneur et propag´ees `a chaque fois que ces conteneurs sont envoy´ees vers d’autres application. Quant aux flux d’information entre une application et un fichier, TaintDroid utilise les attributs ´etendus. Les attributs ´etendus sont des fonctionnalit´es offertes par les syst`emes de fichier tels que ext2/ext3/ext4 (syst`eme de fichier utilis´e principalement sur Android) permettant de stocker des m´eta-donn´ees li´ees aux fichiers. TaintDroid stocke ainsi dans les attributs ´etendus d’un fichier les marques des informations sensibles qu’il contient. Lorsqu’une application acc`ede `a un fichier, TaintDroid met `a jour la marque associ´ee au fichier (´ecriture) ou `a la variable recevant le contenu du fichier (lecture). Si TaintDroid est capable de suivre les flux d’information dans une application, entre les applications Android et entre une application et un fichier, sa port´ee est cependant limit´ee aux applications ´ecrites en Java. En effet, le m´ecanisme de suivi de flux dans TaintDroid repose principalement sur la machine virtuelle Dalvik. Or, il est possible d’utiliser du code natif sous Android. Cela se fait, soit en utilisant le m´ecanisme de JNI [86] soit en ex´ecutant une application compil´ee en code natif. Lorsque ces cas se pr´esentent, TaintDroid devient ainsi incapable de suivre les flux d’information caus´es par le code natif car il n’est pas interpr´et´e par la machine virtuelle Dalvik. 2.5.1.2 Contrˆole d’acc`es aux ressources sensibles `a l’ex´ecution : MockDroid et AppFence Sous Android, l’utilisateur valide les permissions `a l’installation des applications. A l’ex´ecution, il n’a plus aucun contrˆole sur les acc`es et ne peut que faire `32 CHAPITRE 2. ETAT DE L’ART ´ confiance aux applications pour ne pas utiliser de mani`ere malintentionn´ee les ressources et donn´ees auxquelles elles ont acc`es. Afin de palier cette limite d’Android, MockDroid [24] et AppFence [59] proposent `a l’utilisateur de contrˆoler l’acc`es effectu´e par les applications durant leur ex´ecution. Lorsqu’une application souhaite acc´eder `a une donn´ee ou ressource sensible, le syst`eme demande une validation de la part de l’utilisateur. L’acc`es aux informations et ressources sensibles se font via des fonctions de l’API Android. Les auteurs de MockDroid et d’AppFence ont ainsi modifi´e Android afin d’intercepter les appels `a ces fonctions et introduire le m´ecanisme de validation lors de leur appel. Selon l’information ou la ressource demand´ee par l’application, si l’utilisateur lui en refuse l’acc`es, le syst`eme soit lui notifiera son indisponibilit´e ou son inexistence, soit lui renverra une donn´ee factice. Les informations et ressources sensibles dont l’acc`es est renforc´e sont les donn´ees de g´eolocalisation, la liste de contact, les informations li´ees `a l’identit´e du t´el´ephone, les SMS, l’envoi de message de type broadcast intent (MockDroid), les journaux d’´ev`enement (AppFence) et les donn´ees de navigation internet (AppFence). En cas de refus d’un acc`es `a une information sensible, MockDroid et AppFence renvoient une donn´ee vide `a l’application. L’exception est l’acc`es aux donn´ees identifiant l’appareil. En cas de refus, le syst`eme renverra une donn´ee factice `a l’application. Dans AppFence l’exception s’´etend aux donn´ees de g´eolocalisation o`u le syst`eme enverra les mˆemes coordonn´ees factices `a chaque fois. En cas de refus d’un acc`es r´eseau, le syst`eme simule l’indisponibilit´e du r´eseau. AppFence fait par exemple croire `a l’application que le t´el´ephone est en mode avion. Si AppFence et MockDroid ont les mˆemes objectifs et approches, la diff´erence entre les deux r´eside dans le fait qu’AppFence propose ´egalement un meilleur m´ecanisme pour prot´eger les fuites de donn´ees vers des serveurs distant. Pour empˆecher toute fuite de donn´ee, MockDroid simulera l’indisponibilit´e du r´eseau `a toute tentative de connexion. AppFence propose une approche plus fine en demandant uniquement une validation quand une donn´ee sensible est susceptible de quitter le syst`eme. Pour ce faire, AppFence int`egre le m´ecanisme de suivi de flux d’information impl´ement´e dans TaintDroid [46]. TaintDroid est capable de suivre les flux d’information au sein d’une application, entre les applications et entre les applications et les fichiers. Ainsi AppFence ne demande la validation de l’utilisateur uniquement quand les flux observ´es au sein d’une application indiquent une fuite d’information vers l’ext´erieur. Si c’est le cas et en cas de refus de l’utilisateur, AppFence bloquera l’envoi en simulant l’indisponibilit´e du r´eseau ou omettra l’envoi des donn´ees sensibles tout en faisant croire le contraire `a l’application. 2.5.1.3 Protection de contenu : Porscha Dans [79], Ongtang et al. proposent un m´ecanisme de protection de contenu pour Android du nom de Porscha. Porscha permet de lier des donn´ees sensibles `a un appareil et un ensemble d´efini d’applications. A l’´emission d’un contenu ` sensible, sa source lui associe une politique de s´ecurit´e qui d´efinit les destina-2.5. RENFORCEMENT DE LA SECURIT ´ E SOUS ANDROID ´ 33 taires du contenu et les conditions sous lesquelles le contenu peut ˆetre acc´ed´e. Une politique peut par exemple ˆetre une liste d’empreinte MD5 des applications autoris´ees `a acc´eder au contenu prot´eg´e ainsi que des coordonn´ees GPS auxquelles le t´el´ephone doit se trouver au moment de l’acc`es au contenu. Le contrˆole d’acc`es aux donn´ees sensibles se fait `a diff´erents niveaux : `a la transmission des donn´ees vers le t´el´ephone et la transmission des donn´ees aux applications sur le t´el´ephone. Pour prot´eger le contenu lors de sa transmission vers un t´el´ephone, Ongtang et al. proposent de chiffrer le message en utilisant un syst`eme de chiffrement bas´e sur l’identit´e du destinataire [27]. Dans leur travail, l’identit´e est soit le num´ero du t´el´ephone soit une adresse mail. Les messages contenant un contenu prot´eg´e sont ainsi chiffr´es et ne peuvent ˆetre lus que par leurs destinataires. Sur le t´el´ephone, Porscha v´erifie l’acc`es aux donn´ees sensibles en ajoutant des points de contrˆole dans les m´ecanismes de communication Android : `a la transmission des donn´ees sensibles aux applications de messagerie et lors des communications entre applications. A la r´eception des MMS et des courriels, ` Porscha v´erifie si une politique de s´ecurit´e est associ´ee au contenu du message. Si c’est le cas, il transmet uniquement le contenu du message aux applications autoris´ees `a le recevoir. Dans le cas des MMS, les applications non autoris´ees ne recevront pas le message. Dans le cas des courriels, le message est transmis `a toutes les applications courriels mais celles qui ne sont pas autoris´ees `a acc´eder aux donn´ees sensibles ne recevront que le message vid´e de son contenu. Une fois les donn´ees sensibles stock´ees sur le t´el´ephone, une application peut souhaiter partager les donn´ees sensibles `a d’autres applications de confiance sur le syst`eme. Afin de contrˆoler ce partage, Porscha contrˆole les communications et partages de donn´ees utilisant les intents, les composants de type ContentProvider et les appels de m´ethodes distantes. Pour prot´eger les donn´ees transmises via ces m´ecanismes, une application attache la politique de s´ecurit´e des donn´ees au message servant `a transmettre les donn´ees. Lors de la transmission du message, Porscha v´erifie la pr´esence d’une politique de s´ecurit´e dans le message et si c’est le cas limite la transmission aux destinataires autoris´es par la politique. Pour r´esumer, le syst`eme de protection de contenu offert par Porscha permet de d´efinir de mani`ere plus fine `a qui des donn´ees sensibles peuvent ˆetre transmises et sous quelles conditions. Cependant, contrairement `a AppFence ou TaintDroid qui suivent la propagation des informations dans tout le syst`eme (applications ´ecrites en Java et fichiers), Porscha ne r´esout pas le probl`eme de l’usage de l’information. En effet, Porscha ne prot`ege les donn´ees que lorsqu’elles partent de leur application source (application partageant les donn´ees en leur associant une politique de s´ecurit´e). Une fois que les donn´ees sont transmises `a d’autres applications, il n’y a plus de contrˆole sur l’usage qui est en est fait. Le destinataire peut ainsi faire fuir les donn´ees sans que le syst`eme ne soit au courant.34 CHAPITRE 2. ETAT DE L’ART ´ 2.5.1.4 AppIntent Une fuite d’information ne signifie pas forc´ement qu’une attaque ait eu lieu. Selon les cas, la fuite peut ˆetre intentionnelle (ex : partage de coordonn´ees g´eographiques par messagerie), c’est-`a-dire faite par l’utilisateur mˆeme, ou ex´ecut´ee par l’application sans r´eelle intervention de l’utilisateur. Dans le cas d’une fuite intentionnelle, le risque d’une attaque est moindre. Dans le second cas, fuite des donn´ees sans que l’utilisateur n’ait initi´e l’action, la probabilit´e qu’une attaque ait lieu est ´elev´ee car l’utilisateur n’a pas conscience de la fuite. Dans [106], Yang et al. pr´esentent AppIntent, un outil qui analyse les applications Android afin de d´eterminer les ´ev`enements et entr´ees attendus par une application et entraˆınant une fuite d’information. Le but d’AppIntent est de fournir `a un analyste les ´ev`enements et entr´ees attendus par une application menant `a la fuite d’une information afin que l’analyste puisse statuer de la nature de la fuite : intentionnelle ou non (risque d’une attaque). Pour calculer les ´ev`enements et entr´ees entraˆınant une fuite, l’outil analyse statiquement le code de l’application. Dans un premier temps, il construit son graphe de flux de contrˆole puis d´etermine `a partir de ce graphe les chemins d’ex´ecution contenant une fuite d’information. Une fuite d’information est un ensemble d’instruction qui r´ecup`erent une donn´ee sensible puis la fait fuir. Une fois ces chemins calcul´es, AppIntent calcule la suite d’´ev`enements ainsi que les entr´ees attendues qui m`enent `a l’ex´ecution de la fuite d’information. Les ´ev`enements sont les cr´eations et ex´ecutions des composants d’une application (ex : cr´eation et ex´ecution d’un composant Activity ou la reprise d’ex´ecution du composant) ainsi que les interactions avec l’interface utilisateur (ex : validation d’un formulaire) et les entr´ees sont les donn´ees li´ees `a ces ´ev`enements tels que les attributs d’un intent utilis´e pour lancer l’ex´ecution d’un composant ou les valeurs des champs d’un formulaire. A partir des ´ev`enements et entr´ees calcul´es, AppIntent cr´ee ensuite des tests ` unitaires qui correspondent qui ex´ecutent ces suites d’´ev`enement et donnent `a l’application les entr´ees menant `a la fuite d’une information. Pour d´eterminer de la nature des fuites d’information, l’analyste n’a ainsi qu’`a ex´ecuter ces tests unitaires et statuer si lors de l’observation d’une fuite, les actions men´ees `a cette fuite sont intentionnelles ou non. Pour ´evaluer leur outil, Yang et al. ont analys´e 750 ´echantillons de malware et 1000 applications parmi les plus populaires dans la section des applications gratuites sur Google Play. Sur les 750 ´echantillons malware, AppIntent a d´etect´e 219 fuite de donn´ees non intentionnelles et 17 fuites intentionnelles (faites par l’utilisateur). Quant aux applications de GooglePlay, AppIntent a d´etect´e 26 cas de fuites de donn´ees non intentionnelles et 29 cas de fuites intentionnelles. En comparaison, TaintDroid a d´etect´e moins de fuites de donn´ees : 125 dans le cas des ´echantillons de malware et 40 pour les applications de Google Play.2.5. RENFORCEMENT DE LA SECURIT ´ E SOUS ANDROID ´ 35 2.5.2 Communication entre processus et entre composants La d´el´egation d’une partie de l’attaque `a d’autres applications pr´esentes sur le syst`eme et la collaboration entre applications permettent aux applications malveillantes de cacher leur v´eritable nature aux yeux des utilisateurs. Par exemple, une application demandant acc`es aux photos, aux donn´ees de g´eolocalisation, `a la liste de contacts et `a internet paraˆıt suspecte car elle poss`ede assez de permission pour faire fuir les donn´ees li´ees `a l’utilisateur. Par contre, la mˆeme application avait l’acc`es internet en moins paraˆıt moins suspecte car rien n’indique qu’elle pourrait communiquer avec une entit´e distante. Or comme nous l’avons expliqu´e dans la section ??, les applications peuvent utiliser d’autres applications ou collaborer avec d’autres applications pour mener une action qu’elles ne pouvaient faire toutes seules. Dans ce qui suit, nous pr´esentons ainsi les travaux visant `a bloquer ce type d’attaque sur Android en contrˆolant les communications entre applications. 2.5.2.1 ComDroid Nous avons pr´esent´e en section 2.3.3 le r´esultat d’une analyse sur les vuln´erabilit´es introduites par les communications bas´ees sur les intents. Pour d´etecter ces vuln´erabilit´es, Chin et al. ont ainsi pr´esent´e dans [34] un outil d’analyse d’application du nom de ComDroid. ComDroid effectue deux types d’analyse sur le code des applications et leur fichier AndroidManifest.xml. La premi`ere analyse consiste `a analyser le code des applications. Durant cette analyse, ComDroid ´etudie comment les intents sont cr´e´es puis ´emis par une application. ComDroid ´emet une alerte `a chaque fois qu’il d´etecte qu’un implicit intent est ´emis avec une restriction trop faible sur les destinataires. Une restriction est faible si aucun filtrage bas´e sur les permissions du destinataire n’est impos´e ou si les permissions impos´ees sont de type normal (voir tableau 2.1). Une permission de type normal est une permission automatiquement accord´ee `a toute application la demandant. La deuxi`eme analyse consiste `a analyser les composants des applications afin de d´eterminer s’il y a un risque que les composants re¸coivent des requˆetes malveillantes via les intents. ComDroid consid`ere qu’il y a une possibilit´e pour qu’un composant soit vuln´erable si ce dernier peut recevoir des intents provenant d’autres applications 6 telles qu’il n’y ait aucune restriction bas´ee sur les permissions ou une restriction trop faible sur les ´emetteurs de l’^ıntent. Tout comme dans la premi`ere analyse, une restriction trop faible bas´ee sur les permissions est une restriction bas´ee uniquement sur les permissions de type normal. Si l’analyse des communications via les intents montre les risques que ces communications introduisent, il n’existe cependant pas de m´ethode pour d´eterminer si ce qui a ´et´e d´etect´e comme un risque de s´ecurit´e est une vuln´erabilit´e de l’application ou une fonctionnalit´e impl´ement´ee par le d´eveloppeur. En effet, le fait qu’un implicit intent soit utilis´e ou qu’un composant soit expos´e au reste du syst`eme peut traduire une volont´e de s’adapter aux applications 6. Un attribut exported ou un intent filter est d´efini pour le composant36 CHAPITRE 2. ETAT DE L’ART ´ pr´esentes dans le syst`eme. L’exemple typique est l’ouverture d’une page web `a partir d’une application autre que le navigateur. Du cˆot´e du d´eveloppeur de l’application demandant l’ouverture de la page web, le choix d’envoyer un implicit intent au lieur de d´efinir explicitement le navigateur permet de s’assurer que le lien soit ouvert qu’importe le navigateur sur le syst`eme. Il existe plusieurs navigateurs web sur Android (ex : Google Chrome et Firefox) et l’utilisateur a la possibilit´e de choisir quel navigateur installer et utiliser sur le t´el´ephone. D´efinir explicitement le destinataire de la requˆete pour ouvrir le lien revient ainsi `a courir le risque que le lien ne soit pas ouvert car le navigateur cibl´e n’est pas pr´esent sur le t´el´ephone. Au contraire, en envoyant un implicit intent que tous les navigateurs peuvent recevoir, le d´eveloppeur s’assure que le lien sera ouvert s’il existe un navigateur sur le t´el´ephone. Le mˆeme choix se pr´esente ´egalement aux d´eveloppeurs de navigateurs web. En exposant leur navigateur `a toute application pr´esente dans le syst`eme, les d´eveloppeurs s’assurent que leur application soit compatible avec toute application souhaitant ouvrir une page web. 2.5.2.2 Saint Les permissions sont les bases du filtrage des communications entre applications Android pour prot´eger l’acc`es `a des ressources sensibles. Le contrˆole de leur attribution et de leur usage est cependant assez faible sur Android. En effet, une application ne peut restreindre l’attribution d’une permission qu’elle a d´eclar´ee `a l’installation d’une nouvelle application qu’en d´eclarant la permission comme ´etant signature. Dans ce cas, la permission n’est accord´ee que si l’application la demandant a ´et´e sign´ee par le mˆeme d´eveloppeur que celui de l’application l’ayant d´eclar´ee. Une fois l’application demandant la permission install´ee sur le t´el´ephone, il n’existe ´egalement aucune restriction sur son usage. Le d´eveloppeur d’une application pourrait par exemple souhaiter que les applications communiquant avec la sienne ne puisse le faire que dans des contextes pr´ecis tels qu’une plage d’horaire. Partant de ce constat, Ongtang et al. proposent dans [80] une extension de s´ecurit´e `a Android du nom de Saint dont le but est de donner plus de contrˆole sur l’attribution des permissions et leur usage. L’apport de Saint consiste en un module permettant des restrictions suppl´ementaires en plus des permissions `a l’installation des applications et `a leur ex´ecution, ou plus pr´ecis´ement lors des communications entre processus. Saint permet aux applications de d´efinir une politique de s´ecurit´e qui contrˆole l’attribution des permissions prot´egeant leurs interfaces `a l’installation. Par d´efaut, la seule mani`ere de limiter l’´eligibilit´e d’une application pour l’obtention d’une permission est de d´eclarer cette derni`ere comme ´etant de type signature 7 . Ce type de permission n’est accord´ee qu’aux applications sign´ees avec la mˆeme cl´e que l’application ayant d´eclar´e la permission. Grˆace `a Saint, les 7. Voir le tableau 2.1 pour la liste des types de permission2.5. RENFORCEMENT DE LA SECURIT ´ E SOUS ANDROID ´ 37 applications peuvent d´eclarer des restrictions plus fine sur l’attribution des permissions `a l’installation. Elles peuvent ainsi imposer une restriction sur une liste d´eveloppeurs au lieu d’un seul qui est le d´eveloppeur de l’application ayant d´eclar´ee la permission, les autres permissions demand´ees par l’application, son num´ero de version, etc. La politique d’attribution d´efinit un comportement par d´efaut (attribuer ou refuser) et les crit`eres qui y font exception. Une application peut ainsi d´eclarer qu’une permission n’est accord´ee `a une autre application que si elle satisfait un ensemble de conditions ou `a l’inverse d´eclarer que la permission est accord´ee `a toute application sauf celles qui satisfont cet ensemble de conditions. A l’ex´ecution, Saint permet aussi de contrˆoler les communications entre ` applications en d´efinissant grˆace aux mˆemes types de politique de s´ecurit´e. L’´emetteur et le destinataire peuvent tout deux d´efinir cette politique. Comme `a l’installation, l’application d´efinit un comportement par d´efaut (autoriser ou bloquer) et les conditions qui y font exception. La diff´erence par rapport `a l’installation est que l’application peut d´efinir des contextes d’ex´ecution comme condition dans la politique. Ces contextes peuvent par exemple ˆetre des plages horaires, l’´etat de connexion au r´eseau ; la localisation du t´el´ephone, etc. Saint offre aux applications un contrˆole plus fin sur l’attribution et l’usage des permissions qu’ils d´eclarent pour prot´eger leurs composants. A l’ex´ecution, Saint ` souffre cependant des mˆemes limitations que Porscha [79]. En effet, la protection offerte par Saint se limite `a l’acc`es direct au composant de l’application prot´eg´ee par la politique de s´ecurit´e. Si une application autoris´ee par la politique de s´ecurit´e est par exemple utilis´ee lors d’une attaque par d´el´egation pour acc´eder au composant prot´eg´e, Saint ne verrait pas que l’acc`es est en fait r´ealis´e par une autre application qui elle n’est peut-ˆetre pas autoris´ee par la politique de s´ecurit´e. 2.5.2.3 Quire Pour prot´eger les acc`es `a des composants sensibles, les travaux pr´ec´edents se contentent de contrˆoler l’acc`es direct au composant. Ces solutions sont ainsi inefficaces pour lutter contre les attaques par d´el´egation. Dans [42], Dietz et al. proposent Quire une extension de s´ecurit´e `a Android dont le but est de d´etecter et bloquer les attaques par d´el´egation. Quire modifie les m´ecanismes de communication entre applications afin qu’`a chaque requˆete ´emise, l’´emetteur puisse joindre la chaine d’appel ayant men´e `a l’´emission de cette requˆete et que le destinataire de la requˆete puisse v´erifier que tous les ´el´ements de la chaine d’appel ont les permissions n´ecessaires pour demander le traitement de la requˆete. Par exemple, si une application A envoie une requˆete `a une application B qui `a la suite de la r´eception de la requˆete envoie une requˆete `a l’application C alors la chaine d’appel une fois arriv´ee `a C est A Ñ B. Si C `a la r´eception de la requˆete effectue une op´eration sensible, elle peut v´erifier si les applications dans la chaine d’appel ayant men´e `a l’ex´ecution cette op´eration ont les permissions n´ecessaires. Aini, en supposant que B ait la permission n´ecessaire pour envoyer la requˆete et que A ne l’ait pas, C peut d´ecider en connaissance de cause si oui ou38 CHAPITRE 2. ETAT DE L’ART ´ non elle ex´ecute l’op´eration demand´ee. Si l’op´eration sensible ex´ecut´ee par C est par exemple l’´edition de la liste de contact, alors C v´erifiera que les applications A et B poss`edent la permission pour ´editer les contacts (WRITE CONTACTS). 2.5.2.4 IPC Inspection Porter et al. ont adopt´e une approche similaire `a Quire pour bloquer les attaques par d´el´egation. Dans [49], ils pr´esentent IPC Inspection un m´ecanisme qui contrˆole les communications entre applications sous Android. Quand une application re¸coit un message, le syst`eme consid`ere que ses permissions sont r´eduites `a l’intersection de l’ensemble de ses permissions avant la r´eception du message et l’ensemble des permissions de l’´emetteur. En agissant ainsi, le destinataire ne peut plus effectuer d’action sensible `a la demande de l’´emetteur si ce dernier n’a pas la permission n´ecessaire pour effectuer l’action. Le destinataire des messages voit ainsi ses permissions `a l’ex´ecution se r´eduire au fur et `a mesure qu’elle re¸coit des messages de diff´erente applications avec des permissions diff´erentes. Quelques r`egles existent afin d’´eviter que les applications destinataires des messages ne perdent leur permission d´efinitivement et deviennent inutilisables. Les applications syst`emes font partie de la base de confiance. Tout message provenant de ces applications n’entraˆınent donc aucune r´eduction des permissions. Un intent peut servir `a demander d’ex´ecuter une action particuli`ere et `a ˆetre notifi´e `a la fin d’ex´ecution de cette tˆache. La notification se fait par l’envoi d’un intent `a l’´emetteur du pr´ec´edent message. Lors de la r´eception de la notification, le syst`eme consid`ere qu’il n’y a pas risque d’attaque et n’effectue aucune r´eduction de permission. Enfin, IPC Inspection force l’usage de multiples instances d’une mˆeme application pour traiter les messages qui lui sont adress´es. Le destinataire d’un message a ainsi une instance avec ses permissions d’origine et d’autres instances qui traiteront chacun des messages et dont les permissions seront r´eduites. 2.5.2.5 Pr´evention des attaques par d´el´egation et par collusion Quire [42] et IPC Inspection [49] ne ciblent que les attaques par d´el´egation. De plus, le seul m´ecanisme de communication pris en compte est celui bas´e sur binder en utilisant les intents. Dans [30], Bugiel et al. pr´esentent une nouvelle extension de s´ecurit´e `a Android qui est param´etr´ee par une politique de s´ecurit´e et dont le but est de bloquer les attaques par d´el´egation ainsi que les attaques par collusion. Contrairement aux travaux pr´ec´edents, ils prennent en compte la possibilit´e que la communication entre les applications se fasse ´egalement `a travers les m´ecanismes standard de communication sous Linux (fichiers et sockets). Ils ´etendent un framework de s´ecurit´e pour Android d´evelopp´e dans un travail ant´erieur [29] afin d’observer les interactions entre les applications, composants du syst`eme (ContentProvider et services), fichiers et sockets. A` chaque fois qu’une interaction est observ´ee, ils v´erifient qu’il n’y a pas un risque d’attaque. La d´etection des attaques utilisent une repr´esentation sous forme2.5. RENFORCEMENT DE LA SECURIT ´ E SOUS ANDROID ´ 39 de graphe des interactions entre les applications, les fichiers, les sockets et des composants du syst`eme (ContentProvider et services). La politique de s´ecurit´e d´ecrit des propri´et´es sur ce graphe qui permettent de statuer si une interaction correspond `a une attaque ou non. Par exemple, une attaque par d´el´egation est d´ecrite par le fait qu’il existe un chemin `a partir du nœud repr´esentant une application A vers le nœud repr´esentant une application B tel que B poss`ede des permissions critiques que A ne poss`ede pas. Une attaque par collusion est d´ecrite par le fait qu’il existe une chemin entre les nœuds de deux applications A et B tel que l’union des permissions de A et B soit critique. Les auteurs ne d´efinissent pas ce qu’est un ensemble critique de permissions et laisse plutˆot le soin de le d´efinir `a l’utilisateur qui d´efinit la politique de s´ecurit´e. Contrairement `a Quire, Bugiel et al. laissent le choix `a l’utilisateur de d´efinir ce qu’est une attaque via la politique de s´ecurit´e, ce qui apporte `a la fois un avantage et un inconv´enient `a l’approche. La possibilit´e de d´efinir avec pr´ecision les sc´enarios d’attaque a l’avantage de limiter les faux positifs lors de l’ex´ecution du syst`eme, c’est-`a-dire des communications jug´ees comme dangereuses alors qu’elles ne le sont pas. Un des cas souvent ignor´e dans les travaux pr´ec´edents est qu’une application puisse intentionnellement fournir un service `a une autre application. L’inconv´enient dans cette approche est que l’utilisateur n’a pas forc´ement les comp´etences n´ecessaires pour d´efinir une bonne politique de s´ecurit´e ce qui pourrait ˆetre exploiter par une application malveillante afin d’´echapper `a la d´etection. 2.5.3 Abus des permissions 2.5.3.1 Kirin L’approche basique utilis´ee par les applications malveillantes sous Android est de demander toutes les permissions qui leur sont n´ecessaires pour effectuer leur tˆache malveillante. Par exemple, les applications espions dont le but est de tracer l’utilisateur du t´el´ephone demande l’acc`es aux donn´ees de g´eolocalisation et l’acc`es `a internet. Afin de bloquer ce type d’attaque, Enck et al. proposent un syst`eme nomm´e Kirin dans [47]. Le but de Kirin est de v´erifier qu’une application n’a pas un ensemble de permissions jug´e dangereux. Par exemple, l’acc`es aux donn´ees de g´eolocalisation et `a internet permet de faire fuir les d´eplacements de l’utilisateur de t´el´ephone. Ainsi, Kirin v´erifie `a l’installation les permissions demand´ees par une application. Si elle contient un ensemble dangereux, l’installation est bloqu´ee. Il appartient `a l’utilisateur ou `a l’administrateur de l’appareil de d´efinir les ensembles de permission dangereux. 2.5.3.2 Woodpecker Les permissions filtrent l’acc`es aux ressources sensibles sous Android. Une application sans la permission READ SMS ne peut par exemple lire la base de donn´ees des SMS. Dans [54], Grace et al. ont analys´e les applications livr´ees avec40 CHAPITRE 2. ETAT DE L’ART ´ 8 t´el´ephones Android et montr´e que certaines exposaient sans aucune restriction les ressources sensibles. Les auteurs ont identifi´e deux m´ethodes. La premi`ere m´ethode, qu’ils disent explicite, consiste `a exposer les m´ethodes pour acc´eder aux ressources sensibles via des interfaces publiques dont l’acc`es est plus laxiste que celui de la m´ethode prot´eg´ee. Ils consid`erent comment interface les composants expos´es publiquement `a d’autres applications. La deuxi`eme m´ethode, cette fois-ci implicite, consiste `a partager le mˆeme identifiant d’utilisateur entre deux applications. Cela est possible en associant la mˆeme valeur `a l’attribut sharedUserId dans le fichier AndroidManifest.xml des deux applications. Les deux applications tournant avec le mˆeme identifiant utilisateur, elles se retrouvent ainsi `a l’ex´ecution avec l’union des permissions que les deux applications poss`edent. Grace et al. ont ainsi d´evelopp´e Woodpecker un outil pour analyser les applications et trouver d’´eventuelles expositions de ressources sensibles. Woodpecker d´efinit les points d’entr´ee de l’application `a partir de son fichier AndroidManifest.xml, construit son graphe de flux de contrˆole (Control Flow Graph en anglais) et `a partir du CFG calcule tous les chemins d’ex´ecution possibles. L’outil consid`ere qu’une ressource sensible est expos´ee explicitement si un chemin d’ex´ecution partant d’une interface non prot´eg´ee contient un appel `a une fonction sensible et qu’aucun contrˆole n’est fait avant l’appel. Pour le deuxi`eme cas, une alerte est lev´ee si une application indique partager son identifiant utilisateur et s’il existe un appel `a une fonction sensible dans le code de l’application telle que la partie contenant cette fonction puisse ˆetre atteinte. 2.5.3.3 Aurasium La plupart des approches visant `a contrˆoler le comportement des applications se font en modifiant le syst`eme. Dans [105], Xu et al. proposent cette fois-ci de laisser le syst`eme intact et d’ajouter le code n´ecessaire au contrˆole dans l’application. Ils ont ainsi d´evelopp´e un service appel´e Aurasium 8 qui prend en entr´ee une application et retourne sa version renforc´ee. Cette version renforc´ee int`egre du code interceptant les appels aux fonctions sensibles sous Android afin de renforcer une politique de s´ecurit´e. Les fonctions concern´ees servent `a acc´eder `a des ressources sensibles sur le t´el´ephone et internet, et `a ex´ecuter des op´erations potentiellement dangereuses telles que le chargement d’une biblioth`eque ou l’ex´ecution d’un binaire. Bien que ce genre de fonctions soient d´efinies au sein de l’API Java d’Android, Aurasium intercepte leur appel `a un niveau plus bas, plus pr´ecis´ement au niveau des fonctions de la biblioth`eque C du syst`eme et de la machine virtuelle dalvik. Il existe par exemple diff´erentes fonctions dans l’API pour communiquer sur le r´eseau. Cependant, au niveau syst`eme tout cela se traduit par un ensemble restreint d’appels syst`eme tels que connect et sendmsg. Il en est de mˆeme pour les IPCs bas´es sur le binder qui se font via l’appel syst`eme ioctl /dev/binder/. Lorsque l’appel `a une fonction sensible est d´etect´ee, l’application 8. http://aurasium.com2.6. SUIVI DE FLUX D’INFORMATION 41 en informe l’utilisateur et demande `a l’utilisateur de valider l’appel s’il souhaite qu’il se poursuive. Pour ´evaluer la capacit´e de leur service `a instrumenter les applications et `a fournir une version toujours fonctionnelle, ils ont soumis un ensemble de 3491 applications de Google Play et 1260 ´echantillons de malware `a leur service. Nous entendons par version fonctionnelle, une application qui se lance sans erreur au d´emarrage et qui `a l’ex´ecution montre bien des interceptions `a des appels de fonction sensible. Leur ´evaluation a montr´e qu’Aurasium ´etait capable de fournir une version fonctionnelle des applications dans plus de 99% des cas. Aucune ´evaluation ne permet cependant d’appr´ecier la capacit´e d’Aurasium `a intercepter les appels de fonction correspondant aux attaques sur un syst`eme. Nous avons pr´esent´e dans cette section diff´erents travaux inh´erents `a la s´ecurit´e d’Android. Partant du constat des limites des m´ecanismes de s´ecurit´e Android, principalement celles li´ees `a l’acc`es aux ressources sensibles et aux communications entre applications, les auteurs de ces travaux ont propos´e des extensions de s´ecurit´e `a Android et des outils d’analyse d’application. Ces extensions et outils ont pour but de d´etecter les tentatives exploitant les limites du m´ecanisme de s´ecurit´e du syst`eme ainsi que les risques de s´ecurit´e introduit par les m´ecanismes de communication Android. Parmi les attaques cibl´ees, ils ciblent principalement le vol de donn´ees sensibles, l’usage malveillant des permissions accord´ees aux applications, les attaques par d´el´egation et les attaques par collusion. Ces travaux concernent ainsi des classes d’attaque connue et essayent de les d´etecter ou les pr´evenir. Dans cette th`ese, nous avons une approche diff´erente. Au lieu de d´etecter les malware en nous basant sur les limites connues du m´ecanisme de s´ecurit´e d’Android, nous souhaitons dans un premier temps caract´eriser les malware (comment leur attaque fonctionne) et nous baser sur ce que nous aurons appris pour les d´etecter. Notre approche est bas´ee sur les flux d’information que causent les malware dans le syst`eme. Dans la section qui suit, nous introduisons ainsi la notion de flux d’information et pr´esentons quelques travaux utilisant le suivi de flux d’information pour d´etecter des attaques. 2.6 Suivi de flux d’information Suivre les flux d’information consiste `a observer comment les informations se propagent dans un environnement donn´e. En s´ecurit´e, le suivi de flux d’information est utilis´e pour d´etecter des attaques visant soit la confidentialit´e soit l’int´egrit´e de donn´ees dans un environnement donn´e. En plus de d´etecter des attaques, il peut ´egalement servir `a les bloquer. Il s’agit dans ce cas de contrˆole de flux d’information.42 CHAPITRE 2. ETAT DE L’ART ´ 2.6.1 Suivi de flux au sein d’une application Suivre les flux d’information au sein d’une application permet d’avoir une vue fine de la mani`ere dont les informations sensibles sont trait´ees par un programme. A l’exception du langage Perl, les langages de programmation ` n’int`egrent cependant pas de m´ecanisme de suivi ou de contrˆole de flux d’information. Divers travaux se sont ainsi concentr´es sur le suivi et le contrˆole de flux dans les applications soit en proposant une extension au langage de programmation utilis´e soit en instrumentant l’environnement dans lequel l’application tourne. Les applications Android sont principalement ´ecrites en Java. Dans [74, 73], Myers et Liskov pr´esentent un mod`ele de suivi de flux d’information qu’ils impl´ementent dans Jif [75], une extension du langage Java capable de contrˆoler les flux d’information `a l’int´erieur d’une application. Techniquement, Jif est un pr´eprocesseur effectuant une analyse statique du code source pour contrˆoler la conformit´e des flux d’information dans un programme par rapport `a une politique de flux. La politique est repr´esent´ee par des labels qui sont associ´es aux variables et fonctions dans le code. A chaque objet est assign´e un label o`u sont ` d´eclar´es l’ensemble des propri´etaires de l’information et les entit´es que chaque propri´etaire autorise `a acc´eder `a l’information. Etant donn´e que chaque pro- ´ pri´etaire d´eclare une liste de lecteurs autoris´es, la liste des lecteurs effectifs est ensuite calcul´ee en faisant l’intersection de la liste que chaque propri´etaire a d´eclar´ee. Le label L “ to1 : r1, r2; o2 : r2, r3u signifie par exemple que l’objet auquel il est attach´e contient des informations dont o1 et o2 sont propri´etaires. o1 et o2 n’autorisent respectivement que r1 ou r2 et r2 ou r3 `a acc´eder `a l’information. Le lecteur effectif est donc ici r2. Lors pr´etraitement du code, Jif, qui est un pr´eprocesseur Java, calcul les flux d’information dans le programme et v´erifie que les politiques de s´ecurit´e associ´ees aux variables sont v´erifi´ees. L’approche propos´ee par Myers et Liskov est une approche statique qui consiste `a annoter le code source des applications puis `a l’analyser pour contrˆoler les flux d’information dans l’application. Un des avantages de l’analyse statique par rapport `a l’analyse dynamique est qu’il couvre tous les chemins d’ex´ecution possibles et permet en une seule analyse d’identifier toutes les violations `a une politique de flux d’information. Une limite `a cette approche est cependant la n´ecessit´e d’avoir acc`es au code source de l’application pour l’analyser, ce qui est rarement le cas pour les applications Android et limite l’usage de cette approche. Le code des applications Android est livr´e sous la forme de dalvik bytecode et il est parfois obfusqu´e afin d’empˆecher des entit´es tierces de retrouver le code original `a partir duquel le dalvik bytecode a ´et´e g´en´er´e. Ce bytecode est obtenu en compilant dans un premier temps le code source de l’application en bytecode Java puis en compilant ce dernier en bytecode compr´ehensible par la machine virtuelle Dalvik. Si les travaux pr´ec´edents s’attachent `a ajouter une extension de contrˆole de flux d’information dans le langage de programmation et contrˆoler les flux d’information de mani`ere statique, d’autres se sont pench´es sur une modification de l’environnement d’ex´ecution pour suivre et contrˆoler les flux d’information `a2.6. SUIVI DE FLUX D’INFORMATION 43 l’ex´ecution des applications. Dans [46], Enck et al. proposent TaintDroid, une version modifi´ee d’Android avec un m´ecanisme de suivi de flux d’information `a l’ex´ecution des applications. Leur but ´etait d’´etudier si les applications Android font fuir des donn´ees sensibles du t´el´ephone via le r´eseau ou par SMS. Ils ont d´efini dans leur outil un ensemble d’information `a surveiller (ex : identifiants de l’appareil et donn´ees de g´eolocalisation) et s´electionn´e les 30 applications Android les plus populaires pour les analyser. Ils ont montr´e que plus de 2{3 d’entre elles faisaient fuir des donn´ees sensibles, principalement les identifiants du t´el´ephone. Pour suivre les flux d’information, Enck et al. ont modifi´e la machine virtuelle Dalvik. Ils ont impl´ement´e une m´ethode dite de tainting qui consiste `a marquer les objets selon la nature de leur contenu. Dans la machine virtuelle Dalvik, les objets pouvant contenir des informations sont les variables d’une m´ethode, ses param`etres et les champs d’une classe ainsi que des ses instances. Lorsqu’un flux est obser´e, les marques associ´ees aux objets dont le contenu a ´et´e modifi´e est mis `a jour pour prendre en compte la nature de leur nouveau contenu. Contrairement `a Myers et Liskov, Enck et al. ont opt´e pour une approche dynamique pour suivre les flux d’information au sein d’une application durant son ex´ecution. A cause de la nature de l’analyse (dynamique), une des principales ` limitations de TaintDroid est l’impossibilit´e d’observer tous les flux d’information possibles en une seule analyse. Seuls les flux d’information explicites qui ont lieu durant l’ex´ecution de l’application sont d´etect´es. Si TaintDroid a une vue plus limit´ee des flux d’information dans une application, il poss`ede cependant un avantage non n´egligeable par rapport aux approches statiques qui est qu’il ne n´ecessite pas l’acc`es au code source des applications analys´ees. Il est donc plus adapt´e pour analyser les applications destin´ees `a tourn´ees dans un environnement tels qu’Android. 2.6.2 Suivi de flux au niveau syst`eme Un autre niveau d’observation des flux d’information est le syst`eme d’exploitation o`u les objets du syst`eme tels que les processus et les fichiers sont vus comme des conteneurs d’information et les interactions entre eux des flux d’information. Dans [109, 110], Zeldovich et al. proposent HiStar, un syst`eme d’exploitation qui int`egre un m´ecanisme de contrˆole de flux d’information au niveau syst`eme. Le but de HiStar est de fournir un syst`eme capable de bloquer les attaques visant `a voler ou corrompre les donn´ees sur le syst`eme. Pour suivre et contrˆoler les flux d’information, HiStar utilise les labels Asbetos [45]. Un label ´etablit une correspondance entre une cat´egorie d’information et un niveau marquage. Par exemple, le label L “ tw3, c2, 1u signifie que le niveau associ´e aux cat´egories w et c sont respectivement 3 et 2. Le niveau par d´efaut est 1. Un label est associ´e `a chaque objet du syst`eme pouvant contenir de l’information. Le label repr´esente pour chaque objet son niveau d’acc`es pour les diff´erentes cat´egories d’information. Lorsqu’un flux d’information d’un objet A vers un objet B a lieu, HiStar v´erifie que le niveau d’acc`es de B pour les cat´egories d’information d´efinies dans le label de A est sup´erieur ou ´egal au niveau d’acc`es44 CHAPITRE 2. ETAT DE L’ART ´ de A pour ces mˆemes cat´egories. Si c’est le cas, le flux est autoris´e. Dans le cas contraire, il est bloqu´e. Par exemple, si le label de A vaut tw3, c2, 1u et que celui de B vaut tw2, c3, h2, 1u alors B ne peut acc´eder au contenu de A car le niveau d’acc`es de B aux `a la cat´egorie d’information w, ici 2, est inf´erieur au niveau d’acc`es de A, ici 3, `a la mˆeme cat´egorie. Pour contrˆoler les flux d’information dans le syst`eme, HiStar associe des niveaux d’acc`es aux diff´erents objets du syst`eme. Contrairement `a TaintDroid ou AppFence, il se contente d’´etablir des niveaux d’acc`es aux informations mais ne suit pas leur propagation dans le syst`eme. Cela limite son utilit´e pour analyser comment les donn´ees d’une application se propagent dans le syst`eme, ce qui est l’un des nos objectifs. Dans cette th`ese, nous utilisons un moniteur de flux d’information au niveau du syst`eme pour observer les flux d’information. Ce moniteur est la version Android d’un moniteur de flux d’information pour Linux, Blare [37], dont la version actuelle a ´et´e d´evelopp´ee par Christophe Hauser. Plus pr´ecis´ement, Blare est un outil de d´etection d’intrusion pour les syst`emes Linux param´etr´e par une politique de flux d’information. La politique d´efinit les flux autoris´es dans le syst`eme et toute violation de cette politique constitue une intrusion. Pour suivre et contrˆoler les flux d’information, Blare utilise deux labels, itag et ptag, qui sont attach´es aux objets du syst`eme. L’itag repr´esente la contamination courante d’un objet et le ptag repr´esente sa contamination maximale autoris´ee. L’itag d’un objet est ainsi mis `a jour `a chaque fois qu’un flux d’information modifiant le contenu de l’objet a lieu tandis que le ptag est d´efini lors de la cr´eation de la politique de flux. Lorsqu’un flux d’information d’un objet A vers un objet B a lieu, Blare consid`ere que les informations de A vont dans B et v´erifie si l’itag de A est autoris´e par le ptag de B. Si c’est le cas, il met `a jour l’itag de B pour prendre en compte son nouveau contenu. Sinon il l`eve une alerte. Blare ne pr´evient pas les intrusions mais les d´etecte. Il ne bloque pas le flux en cas de violation d’une politique mais se contente de lever une alerte. Comme HisTar, le niveau d’observation de Blare se limite au niveau syst`eme. Il voit les objets du syst`eme comme des boˆıtes noires et effectue une surapproximation des flux observ´es. Quand un flux d’un objet A vers un objet B est observ´e par Blare, il consid`ere que toutes les informations dans A se propagent dans B. Cette vision est moins fine que ce que proposerait un suivi de flux au niveau des applications. Cependant il a l’avantage de ne pas d´ependre d’un langage en particulier tel que le Java et ne se limite pas aux instances d’une machine virtuelle. Il a ainsi une vue compl`ete des flux d’information directs entre les objets du syst`eme par rapport `a TaintDroid qui est limit´e aux flux impliquant uniquement les applications ´ecrites en Java. 2.6.3 Suivi de flux au niveau hardware Dans [108], Yin et al. proposent un environnement virtuel bas´e sur Quemu d’analyse dynamique d’application Windows appel´e Panorama. Panorama suit les flux d’information au niveau machine tout en ayant connaissance des informations li´ees aux objets du syst`eme tels que les processus et les fichiers. Le but du2.6. SUIVI DE FLUX D’INFORMATION 45 travail r´ealis´e est de d´eterminer si une application acc`ede `a une donn´ee sensible du syst`eme et si c’est le cas comment elle l’utilise. Les donn´ees sensibles peuvent ˆetre des donn´ees frapp´ees au clavier, des donn´ees du disque ou le contenu de paquets r´eseaux. Dans le cadre de l’analyse, ces donn´ees sont suppos´ees ne pas ˆetre acc´ed´ees par l’application analys´ee. Pour analyser une application, ils installent ainsi l’application dans l’environnement d’analyse, introduisent des donn´ees sensibles dans le syst`eme, et suivent comment ces donn´ees se propagent. A partir ` des flux observ´es, ils construisent un graphe de flux d’information repr´esentant comment les donn´ees sensibles se sont propag´ees dans le syst`eme. Les nœuds et les arcs du graphe repr´esentent respectivement les objets du syst`eme et les flux d’information entre eux. L’application analys´ee est consid´er´ee comme malveillante si un nœud la repr´esentant est pr´esent dans le graphe. Cela signifie qu’`a un moment donn´e, l’application a acc´ed´ee aux donn´ees sensibles. Si c’est le cas, ils analysent ensuite o`u les donn´ees se propagent `a partir du nœud repr´esentant l’application analys´ee. Dans des travaux plus r´ecents, Yin et al. ont propos´e DroidScope [106] qui est un environnement d’analyse d’application Android qui est l’´equivalent de Panorama pour Android. DroidScope suit ´egalement les flux d’information au niveau hardware mais contrairement `a Panorama, il n’a pas seulement acc`es aux informations li´ees aux objets du syst`eme mais ´egalement `a des donn´ees li´ees `a l’ex´ecution des applications dans la machine virtuelle Dalvik. Il a ainsi une vue plus fine de ce qui se passe dans une application telle que les m´ethodes qui sont utilis´ees pour acc´eder `a une information. Suivre les flux d’information au niveau hardware permet d’avoir une vue fine des flux d’information s’op´erant sur un syst`eme. Le niveau de granularit´e pour le stockage et l’acc`es `a une information peut-ˆetre r´eduit `a un octet ou un bit, ce qui est l’unit´e de stockage des donn´ees. Avoir une telle granularit´e a cependant un coˆut ´elev´e en terme de temps d’ex´ecution qui limite cette approche aux environnements virtuels d’analyse d’application. Les auteurs de Panorama ont mesur´e un temps d’ex´ecution des applications de 30 `a 40 fois plus lents que leur temps d’ex´ecution normal. Notre but est de capturer le comportement malveillant des malware Android et de les d´etecter. Sachant que certains malware essayent de d´etecter la pr´esence d’environnement virtuels pour ´echapper `a toute d´etection, ce niveau d’observation ne nous paraˆıt donc pas comme un choix viable. Il existe diff´erents niveaux d’observation pour suivre les flux d’information sur un syst`eme : application, syst`eme d’exploitation et hardware. Dans ce th`ese, nous optons pour un suivi de flux au niveau du syst`eme d’exploitation afin d’avoir une vue compl`ete des flux d’information entre les diff´erents composants du syst`eme. Suivre les flux d’information `a l’int´erieur des applications a une meilleure granularit´e mais suppose que nous ayons, soit acc`es au code source de toutes les applications `a analyser, soit que toutes les applications soient ´ecrites en Java et interpr´et´ees par la machine virtuelle Dalvik. Aucune de ces suppositions ne s’av`ere ˆetre vraie dans la r´ealit´e. Suivre les flux d’information au niveau46 CHAPITRE 2. ETAT DE L’ART ´ du hardware apporte ´egalement une vue plus fine et contrairement au niveau application ne n´ecessite pas d’acc`es au code source ou l’usage d’un seul langage pour ´ecrire toutes les applications. Cependant, comme nous l’avons ´ecrit pr´ec´edemment, il n’est adapt´e qu’aux environnements virtuels, ce qui pose le probl`eme de la d´etection de l’environnement d’analyse [68]. Dans cette th`ese, nous avons ainsi fait le choix de suivre les flux d’information au niveau syst`eme afin d’ˆetre ind´ependant de la disponibilit´e du code source des applications et du langage utilis´e pour les d´evelopper tout en ayant une vue compl`ete des flux d’information entre les objets du syst`eme. A partir des flux d’information observ´es ` dans le syst`eme, nous proposons de calculer le profil d’un malware et apprendre son comportement. L’approche est similaire `a de l’apprentissage. Dans la section qui suit, nous pr´esentons donc comment des m´ethodes d’apprentissage ont ´et´e appliqu´es pour classifier et d´etecter des malware. 2.7 Classification et d´etection de malware La d´etection de malware se fait g´en´eralement en utilisant des signatures ou des profils comportementaux. La signature d’un malware est un ensemble de propri´et´es communes aux fichiers des ´echantillons du malware. Dans le cas des applications Android, ces fichiers sont les apk. Le profil comportemental d’un malware est un ensemble de propri´et´es communes `a l’ex´ecution des ´echantillons du malware. Ces signatures et profils sont construits `a partir des informations obtenues en analysant, statiquement ou dynamiquement, les ´echantillons de malware. La tendance actuelle consiste `a utiliser des m´ethodes d’apprentissage afin de classifier et d´etecter des malwares. Dans notre cas, nous souhaitons extraire le profil d’un malware et son comportement `a partir des flux d’information qu’ils causent dans le syst`eme. Dans ce qui suit, nous pr´esentons ainsi quelques travaux ayant adopt´e cette approche. L’apprentissage consiste `a apprendre des propri´et´es li´ees `a un jeu de donn´ees. Il existe diff´erents travaux sur l’analyse statique d’application afin de d´etecter des instances de malware (ex : [35] et [58]). Les signatures sont des propri´et´es li´ees au malware telles que des chaines de caract`eres, des ressources dans l’application, des appels `a des fonctions sp´ecifiques, ou simplement l’empreinte d’un fichier. Sous Android, Arp et al. ont propos´e DREBIN [22] pour d´etecter les ´echantillons de malware Android sur les t´el´ephones. Les propri´et´es prises en compte lors de l’analyse d’une application sont les permissions demand´ees, les composants mat´eriels requis, ses composants, les filtres d’intent pour activer les composants, les appels aux fonctions sensibles, les permissions utilis´ees, les appels de fonction suspects et les adresses de serveur pr´esents dans le code de l’application. Pour classifier les applications, ils utilisent une machine `a vecteurs de support [41, 48] qui est une m´ethode d’apprentissage supervis´ee. Un apprentissage supervis´e consiste `a calculer `a partir d’ensembles distincts un mod`ele permettant de d´efinir l’appartenance d’un ´el´ement `a un de ces ensembles. A` partir de deux ensembles distincts d’applications, l’une contenant des applications malveillantes et l’autre contenant des applications b´enignes, ils calculent2.7. CLASSIFICATION ET DETECTION DE MALWARE ´ 47 ainsi un mod`ele de d´etection qui diff´erencie les applications malveillantes des applications b´enignes. Ce mod`ele est ensuite utilis´e sur le t´el´ephone afin de d´etecter les applications malveillantes. L’´evaluation effectu´ee par les auteurs de DREBIN sur la capacit´e de d´etection montre que leur outil atteint un taux de d´etection de 93.90% sur un ensemble de 1834 ´echantillons de malware. Le taux de d´etection d´efinir pourcentage d’´echantillons d´etect´es sur tout le jeu de donn´ees. Le r´esultat est proche des meilleurs r´esultats obtenus par les produits anti-virus qu’ils ont test´e sur le mˆeme jeu de donn´ees. Les meilleurs taux de d´etection sont de 96.41% et de 93.71% tandis que le pire est de 3.99%. La d´etection par analyse statique montre cependant ses limites lorsque les d´eveloppeurs de malware utilisent des techniques d’obfuscation [21, 23, 70] afin de cacher la v´eritable nature de leurs application ou des techniques de polymorphisme et de m´etamorphisme [50] afin de changer l’aspect du code des diff´erentes instances d’un malware. Les d´eveloppeurs du malware Obad.a [98] utilisent par exemple des chaines al´eatoires pour les noms de variables, m´ethode et classes. Ils utilisent ´egalement des fonctions de chiffrement afin de masquer les chaines de caract`eres utilis´ees dans le malware et ces fonctions changent d’un ´echantillon `a l’autre. Contrairement `a l’approche statique, l’approche dynamique repose uniquement sur l’ex´ecution des applications pour d´etecter les ´echantillons de malware et n’est pas ainsi affect´ee par ces m´ethodes d’´evasion. Dans [67], Bayer et al. appliquent une m´ethode d’apprentissage non supervis´ee afin de classifier les applications et d´etecter les ´echantillons de malware. L’apprentissage non supervis´ee consid`ere qu’il n’y a pas de groupement pr´ed´efinis des ´el´ements dans le jeu de donn´ees et calcule lui-mˆeme les regroupements possibles de ces ´el´ements. Les applications `a classifier sont analys´ees dans Anubis [69] afin d’en extraire un profil. Le profil est constitu´e des diverses interactions avec le syst`eme tels que les acc`es aux fichiers et registres ainsi que les communications r´eseaux. Ils appliquent ´egalement une m´ethode de tainting afin d’observer comment les informations issues du syst`eme sont utilis´ees dans les prochains appels syst`eme. Cela s’av`ere utile pour filtrer les informations `a extraire. Par exemple, si le programme utilise la date du syst`eme pour g´en´erer le nom d’un nouveau fichier, il ne sert `a rien de stocker le nom car il sera diff´erent `a chaque ex´ecution. Dans [90], Rieck et al. proposent d’utiliser les interactions entre les applications analys´ees et le reste du syst`eme afin de les classifier et de se servir du mod`ele obtenu lors de l’apprentissage pour d´etecter d’autres ´echantillons de malware. Pour obtenir les interactions des applications avec le reste du syst`eme, ils ex´ecutent les applications dans CWSandbox [101], un environnement d’analyse dynamique d’application. Ils construisent ensuite un vecteur repr´esentant le comportement de l’applications analys´ee `a partir des interactions observ´ees o`u chaque dimension repr´esente une suite d’interaction et utilisent ces vecteurs afin de classifier de mani`ere non supervis´ee les applications analys´ees. Les classes obtenues `a la suite de cette ´etape servent ensuite de mod`ele afin de d´etecter de nouvelles instances de malware. Rieck et al. ont compar´e la qualit´e des classes cr´ees durant l’apprentissage rapport `a celle de Bayer et al. et ont montr´e que leur approche obtient un48 CHAPITRE 2. ETAT DE L’ART ´ meilleur score, 0.950, par rapport `a celle de Bayer et al., 0.881. Le score calcul´e, appel´e F-Score [8], combine `a la fois la qualit´e de la pr´ecision ainsi que du rappel des classes calcul´ees durant l’apprentissage. La pr´ecision mesure la correspondance entre les classes calcul´ees et les familles de malware tandis que le rappel mesure l’´eparpillement des ´echantillons d’un malware dans plusieurs classes. Une pr´ecision ´elev´ee signifie que chaque classe correspond `a une famille de malware. Un rappel ´elev´e signifie que chaque famille de malware correspond `a une classe. La valeur maximale du F-score est de 1 tandis que la pire est de 0. Plus le score est ´elev´e, plus la qualit´e de l’apprentissage est meilleure. Les travaux pr´esent´es ont mont´e que l’apprentissage pouvait servir `a calculer des mod`eles afin de classifier et d´etecter des malware. Cet apprentissage est effectu´e `a partir des propri´et´es li´ees aux fichiers contenant les applications `a analyser ou de leurs traces d’ex´ecution. Dans notre cas, l’apprentissage est effectu´e sur les flux engendr´es par les ´echantillons de malware dans le syst`eme. Nous ex´ecutons ainsi chaque ´echantillon de malware pour capturer ces flux d’information. Un des buts de notre approche est d’identifier le comportement malveillant des malware. Pour cela, il faut capturer ce comportement durant l’analyser. Pour nous en assurer, nous avons analys´e statiquement les ´echantillons de certains malware pour identifier les ´ev`enements d´eclenchant l’ex´ecution du code malveillant. Dans la section qui suit, nous pr´esentons donc un ensemble d’outils li´es `a l’analyse d’applications Android. 2.8 Analyse d’applications Android Analyser une application a pour but d’extraire des informations li´ees `a l’application telles que son comportement, les ressources qu’elle utilise et les ´ev`enements attendus pour ex´ecuter une partie de son code. 2.8.1 D´esassembleur, d´ecompilateur Afin de comprendre le fonctionnement d’une applications sans avoir `a l’ex´ecuter, un analyste a souvent recours `a un d´esassembleur ou un d´ecompilateur. D´esassembler le code d’une application consiste `a le retranscrire dans un langage bas niveau dont les instructions et celles de l’architecture cens´ee interpr´et´ee le code `a d´esassembler ont une forte correspondance. L’architecture interpr´etant le code d’une application Android est la machine virtuelle Dalvik. Parmi les outils pour d´esassembler les applications Android, nous pouvons citer dedexer [6], apktool, qui utilise smali [13], Androguard [97] et IDA Pro [9]. Le listing 2.4 est un extrait du code de l’application JetBoy disponible dans le SDK Android. Le listing 2.5 est la partie correspondante, ´ecrite en smali, apr`es avoir d´esassembl´e l’application avec apktool. La syntaxe des langages utilis´es par ces outils est assez explicite pour comprendre ce que fait l’application et avoir une id´ee de l’aspect du code Java d’origine. Nous remarquons par exemple que l’instruction `a la ligne 4 dans le listing 2.4 correspond aux instructions de la ligne 24 `a 28 du listing 2.5.2.8. ANALYSE D’APPLICATIONS ANDROID 49 1 public void onClick(View v) { 2 // this is the first screen 3 if (mJetBoyThread.getGameState() == JetBoyThread.STATE_START) { 4 mButton.setText("PLAY!"); 5 mTextView.setVisibility(View.VISIBLE); 6 7 mTextView.setText(R.string.helpText); 8 mJetBoyThread.setGameState(JetBoyThread.STATE_PLAY); 9 } 10 ... 11 } Listing 2.4 – Extrait du code de l’application JetBoy fourni avec le SDK Android D´ecompiler une application revient `a le retranscrire dans un langage haut niveau (ex : Java et C). Les applications Android ´etant ´ecrites en Java, le but de la d´ecompilation sera ici d’obtenir un code Java `a partir du dalvik bytecode. Parmi les outils notables nous pouvons citer Androguard et la combinaison dex2jar [43] et JD-Gui [10]. Androguard int`egre un d´ecompilateur natif, dad, mais il peut ´egalement faire appel `a d’autres d´ecompilateurs. dex2jar est un outil qui transforme le dalvik bytecode en java bytecode et JD-Gui est un outil graphique de d´ecompilation de java bytecode. D´ecompiler une application Android en optant pour la combinaison de ces outils revient ainsi `a extraire le fichier classes.dex de l’apk, cr´eer avec dex2jar un fichier jar (Java Archive) et `a d´ecompiler ce dernier avec JD-Gui. Un avantage que JD-Gui a sur Androguard est la possibilit´e d’exporter le r´esultat de la d´ecompilation dans les fichiers .class. Le listing 2.6 liste le code produit par la d´ecompilation de l’application JetBoy avec Androguard. Une diff´erence notable avec le code orignal est l’usage des valeurs `a la place des variables constantes pr´esentes dans le code original. Si le r´esultat de la d´ecompilation a le m´erite d’ˆetre dans un langage haut niveau, cette op´eration int`egre cependant le risque d’une erreur de transcription. Lors de la d´ecompilation de certaines applications, nous avons ainsi d´etecter des erreurs dans le r´esultat de la d´ecompilation pour les deux outils. 2.8.2 Comparaison d’applications Une autre fonctionnalit´e int´eressante d’Androguard est sa capacit´e `a ´evaluer la similarit´e entre deux applications. Androguard compare le code des deux applications et calcule quelles sont les m´ethodes qui sont identiques, similaires et celles qui sont pr´esentes dans l’une mais pas dans l’autre. L’un des cas d’usage de cette fonctionnalit´e est par exemple de trouver le code rajout´e `a une application entre deux versions. Elle peut ´egalement servir `a identifier les applications vol´ees `a leur auteur original.50 CHAPITRE 2. ETAT DE L’ART ´ 2.8.2.1 Extraction de m´etadonn´ees L’analyse peut ´egalement avoir pour but d’extraire des m´etadonn´ees li´ees `a l’application. Dans le cas de applications Android, ces donn´ees sont g´en´eralement le contenu du fichier AndroidManifest.xml. Ce fichier contient diff´erentes informations : permissions utilis´ees par l’application, son num´ero de version, la liste de ses composants, etc. L’acc`es `a son contenu ne n´ecessite pas forc´ement un outil particulier car il s’agit d’un fichier XML. Androguard ou les outils d’analyse dynamique d’application tels que Andrubis propose cependant d’extraire automatiquement ces donn´es. 2.8.2.2 Scanner de virus Il existe plusieurs scanners de virus sous Android dont certains sont disponibles directement sur Google Play. Il existe cependant pour les analystes des services permettant d’analyser les applications Android pour d´etecter les ´echantillons de malware sans avoir `a les analyser avec une application dans un t´el´ephone. VirusTotal [14] est un exemple de ce type d’outil en ligne. Pour effectuer une analyse, les utilisateurs soumettent le fichier `a analyser via une page de soumission. Chaque fichier soumis est ensuite analys´e par diff´erents produits anti-virus afin de d´etecter si oui ou non il est malveillant. VirusTotal utilise `a ce jour 49 produits anti-virus. Le r´esultat des analyses de chaque anti-virus est ensuite retourn´ee `a l’utilisateur. AndroTotal [2] est un autre outil similaire `a VirusTotal. Comme son nom l’indique, AndroTotal est uniquement d´edi´e `a l’analyse d’application Android alors que VirusTotal n’impose aucune restriction sur le type de fichier `a analyser. Ce type d’outil peut s’av´erer utile pour identifier rapidement des ´echantillons de malware. Zhou et al. ont par exemple utilis´e VirusTotal afin de classifier les ´echantillons de malware qu’ils ont analys´e dans [113]. 2.8.2.3 Analyse dynamique d’application Analyser dynamiquement une application consiste `a l’ex´ecuter pour observer son comportement. L’ex´ecution se fait g´en´eralement `a l’int´erieur d’un environnement virtuel simulant un environnement d’ex´ecution tel qu’un syst`eme d’exploitation ou une machine. Ils existent plusieurs environnements d’analyse d’application Android. Certains d’entre eux sont disponibles via leur code source (ex : DroidBox) ou en tant que service en ligne (ex : Andrubis). Ils ont souvent une base commune d’informations surveill´ees : permissions utilis´ees, appels de fonction sensible de l’API Android, composants de l’application qui ont ´et´e ex´ecut´ees, acc`es aux syst`emes de fichier, communications r´eseaux, et ´emissions d’appel et SMS. Pour observer toutes ces informations, les auteurs de ces outils ont recours `a diff´erentes techniques : r´e´ecriture de code, suivi de flux d’information, observation des appels syst`eme, introspection de l’environnement virtuel d’ex´ecution et stimulation d’entr´ee.2.8. ANALYSE D’APPLICATIONS ANDROID 51 La r´e´ecriture de code consiste `a injecter le code n´ecessaire `a l’analyse dans l’application avant de l’ex´ecuter. Durant l’ex´ecution, le code inject´e renseignera sur les comportements d’int´erˆet. Les auteurs de DroidBox ont par exemple opt´e pour cette m´ethode afin d’observer les appels aux diff´erentes fonctions sensibles de l’API Android. Le suivi de flux d’information permet d’observer comment une information se propage dans un environnement donn´e. Un appareil Android contient un certain nombre d’informations sensibles (ex : liste de contact) dont l’usage par une application aurait une certaine utilit´e pour un analyste. Andrubis, AppsPlayground et DroidBox int`egrent ainsi TaintDroid afin de suivre les flux d’information dans les applications Android pour d´etecter toute fuite d’information. DroidScope a son propre moniteur de flux d’information Ces environnements d’analyse dynamique d’application peuvent ˆetre fournis sous deux formes. Soit leurs auteurs fournissent un acc`es en tant que service, l’analyse est effectu´ee en soumettant l’application `a analyser et l’utilisateur r´ecup`ere le r´esultat de l’analyse sous forme de page web ou de fichiers XML ou JSON, soit ils fournissent l’environnement en t´el´echargement afin que l’utilisateur l’ex´ecute sur sa proche machine. DroidBox [7] est un environnement d’analyse dynamique d’application Android `a t´el´echarger et ex´ecuter sur sa propre machine. Durant l’ex´ecution de l’application, l’outil enregistre les communications r´eseaux effectu´ees par l’application, les acc`es aux fichiers, les services lanc´es, les composants Broadcast Receiver, les classes charg´ees, les op´erations cryptographiques via l’API Android, les messages et les appels ´emis. Afin de suivre le rythme d’´evolution d’Android, DroidBox instrumente le code des applications pour intercepter l’appel des fonctions d’int´erˆet. DroidBox int`egre ´egalement une version de TaintDroid afin de d´etecter les ´eventuelles fuites d’information sensible. Son rapport int`egre ainsi les fuites d’information via le r´eseau et par SMS que l’application aurait pu faire. Le lancement de l’application est automatique mais il appartient `a l’utilisateur d’interagir avec l’application. Andrubis [100], version Android d’Anubis, est un service d’analyse d’application en ligne. Il fournit les mˆemes types d’information que DroidBox. Si DroidBox se limite aux fonctions de l’API Android, Andrubis lui consid`ere le fait que les applications puissent ´egalement utiliser du code natif. Ils enregistrent ainsi dans leur rapport l’usage des appels syst`eme utilis´es par l’application. Une autre diff´erence par rapport `a DroidBox est la g´en´eration d’´ev`enements afin de couvrir tout le code. DroidBox se contente de lancer l’application en ex´ecutant son Activity principal. Andrubis prend en compte le fait que chaque composant d’une application est un point d’entr´ee du programme et essaie de tous les lancer. D’apr`es l’´etude effectu´ee par Neuner et al. dans [77], DroidBox aurait ´et´e utilis´e comme base pour d’autres environnements d’analyse tels qu’ANANAS [44] et Mobile Sandbox [94]. Il existe ´egalement d’autres environnements ind´ependants de DroidBox tels que SmartDroid [111], CopperDroid [88], DroidScope [106] AASandbox [25] etc.52 CHAPITRE 2. ETAT DE L’ART ´ 1 .method public onClick(Landroid/view/View;)V .locals 5 2 .parameter "v" 3 .prologue const v4, 0x7f050004 4 const/4 v3, 0x4 5 const/4 v2, 0x0 6 .line 92 iget-object v0, p0, 7 Lcom/example/android/jetboy/JetBoy;->mJetBoyThread: 8 Lcom/example/android/jetboy/JetBoyView$JetBoyThread; 9 invoke-virtual {v0}, 10 Lcom/example/android/jetboy/JetBoyView$JetBoyThread; 11 ->getGameState()I 12 move-result v0 13 const/4 v1, -0x1 14 if-ne v0, v1, :cond_0 15 .line 93 iget-object v0, p0, 16 Lcom/example/android/jetboy/JetBoy;-> 17 mButton:Landroid/widget/Button; 18 const-string v1, "PLAY!" 19 invoke-virtual {v0, v1}, 20 Landroid/widget/Button;->setText(Ljava/lang/CharSequence;)V 21 .line 94 iget-object v0, p0, 22 Lcom/example/android/jetboy/JetBoy;->mTextView: 23 Landroid/widget/TextView; 24 invoke-virtual {v0, v2}, 25 Landroid/widget/TextView;->setVisibility(I)V 26 .line 96 iget-object v0, p0, 27 Lcom/example/android/jetboy/JetBoy;->mTextView: 28 Landroid/widget/TextView; 29 invoke-virtual {v0, v4}, 30 Landroid/widget/TextView;->setText(I)V 31 .line 97 iget-object v0, p0, 32 Lcom/example/android/jetboy/JetBoy;->mJetBoyThread: 33 Lcom/example/android/jetboy/JetBoyView$JetBoyThread; 34 invoke-virtual {v0, v2}, 35 Lcom/example/android/jetboy/JetBoyView$JetBoyThread;-> 36 setGameState(I)V Listing 2.5 – Extrait du code smali de l’application JetBoy2.8. ANALYSE D’APPLICATIONS ANDROID 53 1 public void onClick(android.view.View p6) 2 { 3 if(this.mJetBoyThread.getGameState() != 15) { 4 ... 5 } else { 6 this.mButton.setText("PLAY!"); 7 this.mTextView.setVisibility(0); 8 this.mTextView.setText(1.76787404569e+38); 9 this.mJetBoyThread.setGameState(0); 10 } 11 return; 12 } Listing 2.6 – Extrait du code r´esultant de la d´ecompilation de l’application JetBoy avec le d´ecompilateur par d´efaut d’Androguard54 CHAPITRE 2. ETAT DE L’ART ´ Nous avons pr´esent´e dans ce chapitre le syst`eme Android et introduit la base de connaissance n´ecessaire pour comprendre notre approche. Au lieu de d´etecter des sc´enarios d’attaque pr´ed´efinis, nous souhaitons en d´ecouvrir de nouvelles et les d´etecter. La premi`ere ´etape `a l’atteinte de cet objectif est d’analyser les flux d’information caus´es par les ´echantillons de malware Android. Pour observer ces flux, nous utilisons un moniteur de flux d’information Blare que nous avons port´e sous Android. Dans le chapitre suivant, nous pr´esentons ce moniteur et expliquons les ajouts effectu´es `a Blare lors du portage sous Android.Chapitre 3 Blare : un moniteur de flux d’information pour Linux et Android Pour suivre les flux d’information, nous utilisons Blare [37], un syst`eme de d´etection d’intrusion param`etr´e par une politique de flux d’information. La politique de flux d’information d´ecrit les flux autoris´es dans le syst`eme et l`eve une larte `a chaque violation de la politique. Blare est bas´e sur un mod`ele d´ecrit en section 3.1 et est impl´ement´e pour les syst`emes de type Linux comme d´ecrit en section 3.3. Android int´egrant des fonctionnalit´es qui lui sont propres, le premier apport de la th`ese a donc consist´e `a modifier Blare pour prendre en compte certaines fonctionnalit´es d’Android. La prise en compte de ces fonctionnalit´es donne une vue plus compl`ete des flux d’information sous Android. La section 3.4 d´ecrit les modifications apport´ees `a Blare. Le r´esultat de ce portage, AndroBlare, nous sert d’environnement d’analyse dynamique d’application afin d’apprendre le comportement des applications `a partir des flux d’information qu’elles causent dans le syst`eme. Dans la section 3.5, nous expliquons ainsi comment nous analysons les applications dans cet environnement. 3.1 Mod`ele th´eorique Le mod`ele th´eorique de Blare [55, 56] d´ecrit comment suivre et contrˆoler les flux d’information au niveau du syst`eme. Pour suivre les flux d’information, il utilise une m´ethode de marquage qui consiste `a marquer les objets selon la nature de leur contenu. Il existe ainsi une distinction importante entre les conteneurs d’information et leur contenu. 5556 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION Taille 8 16 32 64 Intervalle r´2 7 , 2 7 ´ 1s r´2 15 , 2 15 ´ 1s r´2 31 , 2 31 ´ 1s r´2 63 , 2 63 ´ 1s Table 3.1 – Intervalle de valeur du type int selon sa taille en bits 3.1.1 Conteneurs d’information Blare suit les flux d’information au niveau du syst`eme d’exploitation. Il a ainsi une vue des flux entre les objets du syst`eme. Le mod`ele de Blare d´efinit trois types de conteneur d’information : les conteneurs persistants, les conteneurs volatiles et les utilisateurs. Un conteneur persistant est un conteneur qui peut exister sur plusieurs cycles d’ex´ecution du syst`eme. Un fichier est l’exemple typique d’un conteneur persistant. Un conteneur volatile est conteneur qui n’existe que le temps d’un cycle d’ex´ecution du syst`eme. Il n’est cr´e´e qu’apr`es le d´emarrage du syst`eme et est d´etruit `a l’arrˆet. Les sockets sont des exemples de conteneurs volatiles. Les utilisateurs sont les utilisateurs du syst`eme. A chacun de ` ces conteneurs sera associ´e un ensemble de marques ou tags qui permettent de suivre et contrˆoler les flux d’information. Nous noterons par la suite C l’ensemble des conteneurs d’information, PC l’ensemble des conteneurs persistants, VC l’ensemble des conteneurs volatiles et U l’ensemble des utilisateurs. 3.1.2 Information et contenu courant d’un objet : itag Il existe deux types d’information dans le mod`ele de Blare. Le premier est l’information morte qui correspond `a toute donn´ee non ex´ecut´ee sur le syst`eme. Le contenu d’un fichier est l’exemple typique d’une information morte. Le deuxi`eme est l’information ex´ecut´ee qui correspond `a toute donn´ee ex´ecut´ee. Nous ne la retrouvons que dans les processus car seuls les processus peuvent ex´ecuter des donn´ees. A chaque donn´ee dont nous souhaitons contrˆoler la pro- ` pagation est associ´ee un entier unique l’identifiant. L’ensemble des identifiants d’information morte est not´ee I “ t1, 2, . . .u et correspond l’ensemble des entiers strictement positifs. L’ensemble des identifiants d’information ex´ecut´ee est not´ee X “ t´1, ´2...u et correspond `a l’ensemble des entier strictement n´egatifs. En th´eorie, il est possible de suivre autant d’information que souhait´e mais dans la pratique l’impl´ementation imposera toujours une valeur maximale et minimale des identifiants. Les identifiants sont repr´esent´es par des entiers sign´es de type int dans la version actuelle de Blare. La taille des types varie selon l’architecture du syst`eme (chapitre 11 de Linux Device Drivers [40]), ce qui rend impossible de d´efinir une intervalle de valeur fixe pour les identifiants. Le tableau 3.1 liste les intervalles de valeur pour un int selon le nombre de bits utilis´es pour le stocker. Il est `a noter que le type int d´esigne un entier sign´e et le dernier bit de sa repr´esentation en m´emoire est ainsi utilis´e pour coder son signe. Si I et X sont deux ensembles distincts, il existe cependant une relation entre leurs ´el´ements. Pour chaque ´el´ement n de I, ´n identifie la donn´e identifi´ee par n lorsqu’elle est ex´ecut´ee dans un processus. Par exemple, si nous supposons que3.1. MODELE TH ` EORIQUE ´ 57 le contenu du fichier /system/bin/cat 1 est identifi´e par 1 alors le processus qui ex´ecutera cat contiendra l’information identifi´ee par ´1. Itag Le mod`ele de Blare marque chaque conteneur d’information par tag appel´e itag pour caract´eriser son contenu. Sa valeur est un sous ensemble de I YX et pour tout conteneur c, itagpcq “ ti1, . . . inu signigie que le contenu de c contient les informations initialement identifi´ees par i1, . . . in. @c P C, itagpcq P PpI Y Xq 3.1.3 Politique de flux d’information : pxqptag Blare est param´etr´e par une politique de flux d’information. Cette politique d´efinit les flux autoris´es entre les conteneurs d’information et est repr´esent´ee par l’ensemble des ptags dans le syst`eme. A chaque conteneur d’information ` est ainsi associ´e un deuxi`eme tag : ptag. Le ptag d´efinit les diff´erents contenus maximaux autoris´es pour le conteneur. Sa valeur est une collection de sousensemble de I Y X et chacun de ses ´el´ements repr´esente un contenu maximal l´egal pour le conteneur. @c P C, ptagpcq P PpPpI Y Xqq Le contenu courant d’un conteneur c est l´egal si itagpcq est inclus dans au moins un des ´el´ements de ptagpcq. Le ptag d’un conteneur est nul par d´efaut. Le conteneur n’a donc pas le droit d’acc´eder `a une donn´ee `a laquelle un identifiant a ´et´e associ´e. Toute information n’ayant aucun identifiant associ´e est consid´er´e comme non sensible et a le droit de se propager dans n’importe quel conteneur. Le contenu de c est l´egal si De P ptagpcq tel que itagpcq Ď e Par exemple, si le ptag d’un conteneur vaut tt1, 2u, t2, 3uu cela signifie que l’ensemble des contenus l´egaux possibles pour ce conteneur sont H, t1u, t2u, t3u, t1, 2u et t2, 3u. Politique d’un programme, politique d’un processus : xptag Une distinction importante est faite entre programme et processus. Toute donn´ee pouvant ˆetre ex´ecut´ee dans le syst`eme est un programme tandis qu’un processus est une instance d’un programme ou plus pr´ecis´ement une entit´e ex´ecutant un programme. Le contenu d’un fichier com.android.browser.dex est un exemple de programme Android et le processus com.android.browser est une instance de ce programme. 1. cat est une application en ligne de commande qui concat`ene et affiche le contenu de fichiers58 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION USER PID PPID NAME root 1 0 /init drm 179 1 /system/bin/drmserver media 180 1 /system/bin/mediaserver install 181 1 /system/bin/installd keystore 183 1 /system/bin/keystore radio 186 1 /system/bin/netmgrd nobody 187 1 /system/bin/sensors.qcom root 190 1 /system/bin/thermal-engine-hh root 1678 1 /system/xbin/su Figure 3.1 – Extrait de la sortie de la commande ps sous Android 4.4 xptag La politique d’un programme est exprim´ee par un troisi`eme tag appel´e xptag qui est attach´e au conteneur stockant le programme. Tout comme le ptag, le xptag est ´egalement une collection de sous-ensemble de I Y X. Il n’est pas utilis´e pour v´erifier la l´egalit´e d’un contenu mais plutˆot `a calculer la valeur du ptag des processus. @c P C, xptagpcq P PpPpI Y Xqq Un processus est une instance d’un programme `a l’ex´ecution. Dans les syst`emes Unix/Linux, les processus peuvent ˆetre list´es avec la commande ps. La figure 3.1 pr´esente un extrait de la sortie de la commande ps sous Android. Les informations d’int´erˆet sont celles de la premi`ere, la deuxi`eme et la derni`ere colonnes. Chaque ligne liste des informations sur un processus. La premi`ere colonne identi- fie l’utilisateur ex´ecutant le processus. La deuxi`eme colonne liste les identifiants des processus. Enfin la derni`ere colonne liste les programmes ex´ecut´es par les processus. Ainsi, le programme /init est ex´ecut´ee par l’utilisateur root dans le processus identifi´e par 1. Un processus ´etant le r´esultat de l’ex´ecution d’un programme par un utilisateur, sa politique est calcul´ee `a partir de celle de l’utilisateur et celle du programme qu’il ex´ecute. Nous noterons execpc, uq le processus r´esultant de l’ex´ecution du programme c par l’utilisateur u par la suite. Plus pr´ecis´ement, la politique d’un processus r´esulte de l’intersection de la politique de l’utilisateur et de celle du programme qu’il souhaite ex´ecuter. Soient un programme c et un utilisateur u. La politique associ´ee au processus execpc, uq est l’intersection des ´el´ements de la politique de c avec ceux de la politique de u. @p P P rog et @u P U, ptagpexecpc, uqq “ tec X euu, ec P ptagpcq et eu P ptagpuqu Parmi les processus list´es par la commande ps dans la figure 3.1 se trouve un processus ex´ecut´e par l’utilisateur media et ex´ecutant le programme dans le fi-3.1. MODELE TH ` EORIQUE ´ 59 chier /system/bin/mediaserver. En supposant que la politique associ´ee respectivement au programme et `a l’utilisateur soit tt1, 2, 3u, t3, 4uu et tt2, 3, 5u, t5, 12uu, alors la politique associ´ee au processus serait tt2, 3uu. Cet unique ´el´ement de la politique r´esulte de l’intersection du premier ´el´ement de la politique du programme avec celui de l’utilisateur. Les autres intersections sont toutes vides. Cela signifie que le processus peut contenir tout au plus les informations identifi´ees par 2 et 3. 3.1.4 Suivi et contrˆole de flux d’information Le contenu courant d’un objet et sa politique de flux sont repr´esent´es respectivement par l’itag et le ptag attach´es `a l’objet. L’itag caract´erisant le contenu courant d’un objet, sa valeur ´evoluera en fonction de l’´evolution du contenu de l’objet auquel il est attach´e. Le ptag par contre lui n’´evoluera que si la politique de flux d’information n’´evolue. Le suivi et le contrˆole de flux d’information se fait en deux ´etapes. La premi`ere ´etape consiste `a la mise `a jour de l’itag de l’objet dont le contenu a ´et´e modifi´e suite au flux observ´e. La deuxi`eme ´etape consiste `a v´erifier la l´egalit´e du flux observ´e. Un flux est l´egal si le contenu des objets modifi´es par le flux est l´egal. La v´erification de la l´egalit´e se fait en comparant la nouvelle valeur de l’itag de l’objet modifi´e suite au flux avec la politique associ´ee `a l’objet, `a savoir son ptag. 3.1.4.1 Suivi de flux d’information Blare observe les ´ev`enements du syst`eme provoquant des flux d’information et `a chaque flux observ´e, il met `a jour l’itag des objets dont le contenu a ´et´e modifi´e par le flux. Ces flux peuvent ˆetre class´es dans diff´erents groupes comme list´e dans le tableau 3.2. Chaque ligne d´ecrit l’interaction entre deux objets du syst`eme causant un flux d’information et la mani`ere dont les tags sont mis `a jours quand Blare observe le flux. Non seulement l’itag de l’objet modifi´e est mis `a jour mais aussi son xptag, sauf dans le cas de l’ex´ecution d’un programme. Le xptag repr´esente la politique d’un programme. Or un programme est une donn´ee stock´ee dans un conteneur. Un programme peut ainsi ˆetre propag´e dans le syst`eme lors des flux d’information. Afin de s’assurer que la politique d’un programme reste associ´ee `a ce programme malgr´e le fait qu’il puisse ˆetre copi´e dans d’autres conteneurs, Blare propage le xptag des fichiers en mˆeme temps que l’itag du fichier. A chaque fois Blare observe un flux d’information, il effectue une suraproxi- ` mation du flux observ´e. Il consid`ere le pire des cas qui est que le contenu entier de la source du flux d’information s’est propag´e vers le conteneur destination. Nous expliquons ci-dessous ces mises `a jour effectu´ees par Blare list´ees dans le tableau 3.2. Lorsqu’un processus p lit le contenu d’un conteneur f, Readpp, fq, Blare consid`ere que le contenu de f s’est propag´e dans p. Le contenu du processus est modifi´e par le flux et son itag change de valeur. Le pire des cas ´etant que tout contenu de f se soit propag´e dans p, Blare consid`ere alors que le nouveau60 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION Type d’´ev`enement Description Mise `a jour des tags Readpp, fq Lecture de f par p itagppq Ð itagppq Y itagpfq xptagppq Ð xptagpfq X xptagppq W ritepp, fq Ecriture de ´ f par p itagpfq Ð itagppqzX xptagpfq Ð xptagppq W riteapppp, fq Ecriture de ´ f par p itagpfq Ð pitagppqzXq Y itagpfq xptagpfq Ð xptagpfq X xptagppq Execpp, fq Ex´ecution du contenu de f par p itagppq Ð t´nu, n P itagpfq ptagppq Ð xptagpfq Table 3.2 – Blare : m´ethode de suivi de flux contenu de p est un m´elange de son ancien contenu et du contenu de f. La nouvelle valeur de l’itag de p est donc l’union de son ancien itag avec celui de f. L’exemple typique de ce type de flux est la lecture d’un fichier par un processus. Les fichiers ne sont cependant pas les seuls conteneurs d’information du syst`eme `a partir duquel un processus peut lire des donn´ees. Un processus peut ´egalement lire des donn´ees `a partir d’un socket ou d’un message via les files de message [65]. Le conteneur f ne repr´esente donc pas uniquement un fichier mais tout autre conteneur `a partir duquel un processus peut lire des donn´ees. Lorsqu’un processus p ´ecrit dans un conteneur f, W ritepp, fq, Blare consid`ere que les informations dans p se propagent vers le conteneur f. Le contenu de f change et Blare met `a jour son itag. Le pire des cas ´etant que tout le contenu de p se propage dans f, le nouveau contenu de f est en cons´equent un m´elange de son ancien contenu avec le contenu de p `a l’exception des donn´ees ex´ecut´ees. Blare consid`ere qu’un processus ne propage pas le code qu’il ex´ecute. Les identi- fiants n´egatifs ne sont donc pas propag´es dans l’itag du destinataire. La nouvelle valeur de l’itag de f est ainsi l’union de son ancienne valeur avec l’ensemble des identifiants positifs dans l’itag de p. Comme expliqu´e en section 3.1.2, les donn´ees sensibles ex´ecut´ees dans un processus sont identifi´ees par un entier strictement n´egatif. Lorsqu’un processus ex´ecute un programme, Blare consid`ere que son contenu courant est remplac´e par le code provenant du fichier contenant le programme. Son itag devient ainsi l’ensemble des valeurs n´egatives des identifiants pr´esents dans l’itag du fichier. Les interactions entre les objets d’un syst`eme ne se limite `a la lecture, ´ecriture et l’ex´ecution. D’autres ´ev`enements tels que la cr´eation de conteneur ou l’envoi de signaux existent ´egalement. Ces ´ev`enements n’engendrent pas de flux d’information explicites entre les objets et sont ignor´es par Blare. Il est cependant techniquement possible de se servir de ces ´ev`enements pour faire fuir des informations et ainsi ´echapper au contrˆole effectu´e par Blare. 3.1.4.2 Contrˆole de flux d’information Un flux d’information est l´egal si le contenu de l’objet qui a ´et´e modifi´e par le flux est l´egal. Le contrˆole d’un flux d’information se fait en deux ´etapes.3.1. MODELE TH ` EORIQUE ´ 61 c1 c2 ptag = {{1, 2, 3}} ptag = {{1,2}, {2,3}} itag = {3} itag = {1} c1 c2 ptag = {{1,2}, {2,3}} itag = {3} itag = {1,3} c1 c2 ptag = {{1,2}, {2,3}} itag = {3} itag = {1,3} (a) (b) (c) ptag = {{1, 2, 3}} ptag = {{1, 2, 3}} Figure 3.2 – Exemple de contrˆole de flux d’information effectu´e par Blare 1. Mise `a jour de l’itag de l’objet dont le contenu a ´et´e chang´e. 2. Contrˆole de la l´egalit´e du nouveau contenu de l’objet modifi´e par le flux. Si le contenu est ill´egal alors, Blare consid`ere que le flux observ´e est ill´egal et l`eve une alerte. La figure 3.2 illustre un exemple de contrˆole de flux lorsque Blare observe la lecture d’un fichier c1 par un processus c2. (a) Les deux conteneurs sont marqu´es pr´ealablement avant la lecture. (b) Lors de la lecture du fichier, Blare consid`ere que le contenu de c1 se propage vers c2. Il met ainsi `a jour la valeur de itagpc2q comme d´ecrit dans le tableau 3.2 pour la lecture de fichier. La valeur de itagpc2q devient t2, 3u. (c) Apr`es la mise `a jour de l’itag, Blare contrˆole la l´egalit´e du nouveau contenu afin de d´eterminer si le flux observ´e est l´egal ou non. Il n’existe pas d’´el´ement de ptagpc2q qui inclut itagpc2q. Le nouveau contenu est ill´egal, ce qui signifie que le flux observ´e est ill´egal. Une alerte est donc lev´ee. Blare est outil de d´etection d’intrusion param´etr´e par une politique de flux d’information. Pour d´etecter une intrusion, il faut ainsi dans un premier temps d´efinir une politique de s´ecurit´e qui identifie les informations `a prot´eger et o`u ces informations ont le droit de se propager. Dans la section suivante, nous pr´esentons une mani`ere de d´efinir cette politique de flux sous Android.62 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION 3.2 D´efinition d’une politique de flux d’information Prot´eger un syst`eme avec un outil tel que Blare signifie qu’il faut dans un premier temps d´efinir une politique de s´ecurit´e. Dans le cas de Blare, cette politique est une politique de flux d’information. Elle identifie les informations `a prot´eger et comment les prot´eger, c’est-`a-dire la liste des conteneurs o`u elles ont le droit de se propager. D´efinir une politique de flux d’information pour Blare se r´esume en quatre ´etapes. 1. Identifier les informations sensibles `a prot´eger. 2. Associer `a chacune de ces informations un identifiant unique. 3. Identifier les conteneurs l´egaux pour ces informations. 4. D´efinir la valeur des ptags `a associer `a ces conteneurs. Il existe deux approches pour d´efinir la politique de s´ecurit´e. La premi`ere consiste `a la calculer `a partir d’une autre politique existante telle qu’une politique de contrˆole d’acc`es. Dans [56], Geller et al. ont propos´e un algorithme qui transforme une politique de contrˆole d’acc`es mandataire App Armor en une politique de flux d’information Blare. Les politiques App Armor d´efinissent des profils de programme limitant leur acc`es aux autres objets du syst`eme tels que les fichiers. L’algorithme propos´e prend en entr´ee un ensemble de profils App Armor et donne en sortie leur ´equivalent en terme de politique Blare. Cette approche a le m´erite d’ˆetre automatique et rapide mais elle ne permet pas d’exploiter toute l’expressivit´e d’une politique Blare. Un exemple de ce manque d’expressivit´e est la restriction sur les m´elanges d’information. Un conteneur a le droit d’acc´eder aux informations i et j mais n’a pas le droit de les m´elanger, c’est-`a-dire que le conteneur contient soit i soit j mais pas les deux en mˆeme temps. Le listing 3.1 pr´esente une politique App Armor pour le programme apache. Cette politique autorise le programme `a lire le contenu des fichiers apache2.conf et index.php. La politique de flux qui peut ˆetre d´eduite de cette politique est que les donn´ees dans les deux fichiers ont tout deux le droit de se propager vers le programme apache. Cependant, le propri´etaire du contenu de ces deux fichiers peut souhaiter que le contenu de ces fichiers ne se m´elangent pas. Cette contrainte ne peut-ˆetre exprim´ee avec une politique App Armor et une politique de flux exprimant une telle restriction ne peut donc ˆetre calcul´ee `a partir d’une politique App Armor. {/usr/bin/apache, {(/etc/apache2.conf, w), (/etc/apache2.conf, r), (/www/index.php,r), (/usr/bin/ftpd, px)} } Listing 3.1 – Exemple de politique App Armor3.2. DEFINITION D’UNE POLITIQUE DE FLUX D’INFORMATION ´ 63 La deuxi`eme approche consiste `a d´efinir manuellement la politique de flux d’information. Cette approche est plus longue car elle implique une analyse compl`ete du syst`eme mais permet d’exploiter toute l’expressivit´e d’une politique Blare. Construction manuelle d’une politique pour Android Dans [16], nous avons propos´e une politique de flux d’information pour le syst`eme Android. La politique a ´et´e construite `a la main en se basant sur une analyse manuelle du syst`eme. Le but ´etait de fournir une politique `a taille r´eelle pour un syst`eme entier. Comme ´ecrit pr´ec´edemment, la d´efinition d’une politique de flux se fait en quatre ´etapes. La premi`ere ´etape est l’identification des informations sensibles `a surveiller. Nous avons construit la liste des informations sensibles `a partir des donn´ees que nous avons jug´ees sensibles sur le syst`eme Android. Ces informations incluent les donn´ees li´ees `a l’utilisateur (ex : liste de contact et donn´ees de g´eolocalisation) mais aussi celles li´ees aux applications (ex : code et param`etres de configuration). Les donn´ees sensibles ont ´et´e identifi´ees en analysant manuellement le contenu des fichiers sur le syst`eme et en prenant en compte celles qui sont prot´eg´ees par le m´ecanisme de permission. Notre politique recense 150 informations sensibles m´elangeant donn´ees non ex´ecut´ees et code ex´ecut´e `a l’int´erieur des processus. Il existe encore plus d’information sur un syst`eme Android 2 mais nous avons jug´e cette quantit´e d’information `a surveiller suffisante pour construire une politique de flux d’information pour tout un syst`eme. La deuxi`eme ´etape consiste `a identifier les conteneurs d’information. La liste des fichiers et programmes install´ees sur un syst`eme Android est assez simple `a construire. Grˆace `a la commande find, nous pouvons lister tous les fichiers du syst`eme. Quant aux applications, les applications livr´ees sous forme d’apk sont connues grˆace `a la commande pm et les applications natives sont stock´ees dans /system/bin et /system/xbin. La liste des utilisateurs est elle par contre moins ´evidente `a construire car contrairement `a un syst`eme Linux standard, il n’existe pas de fichier /etc/passwd ni de fichier /etc/shadow. Android d´efinit en dur un ensemble restreint d’utilisateur n´ecessaire au fonctionnement de base du syst`eme tels que root, radio et system. Puis pour chaque application non native install´ee sur le syst`eme, il associe un utilisateur unique. Pour ´etablir la liste des utilisateurs associ´es aux applications, nous nous sommes bas´es sur le contenu des fichiers /data/system/packages.list ou /data/system/packages.xml. Ils recensent les informations li´ees aux applications install´ees sur le t´el´ephone dont l’utilisateur qui leur associ´e. Une fois les donn´ees sensibles et conteneur identifi´es, nous avons ensuite construit la politique de flux. La politique de chaque programme a ´et´e construite en analysant ses sources pour comprendre `a quelles informations il acc`ede. La politique de chaque utilisateur a ´et´e obtenue en faisant l’union des politiques des programmes qu’il peut ex´ecuter. Dans la plupart des cas, il n’y aura qu’un 2. Il existe plus des milliers de fichiers r´eguliers lors de l’ex´ecution du syst`eme.64 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION Identifiant des informations 11 -44 10 6 -55 -39 3 9 37 -37 Fichiers calendar.db ˆ contacts2.db ˆ ˆ mms.db ˆ telephony.db ˆ TelephonyProvider.apk ˆ Programmes com.android.calendar ˆ ˆ com.android.providers.contact ˆ ˆ ˆ com.android.providers.telephony ˆ ˆ ˆ Utilisateurs 10024 ˆ ˆ 10004 ˆ ˆ ˆ ˆ 1001 ˆ ˆ ˆ Table 3.3 – Un extrait de la politique de flux d’information seul programme car en dehors des utilisateurs syst`eme les autres utilisateurs n’ex´ecuteront que l’application `a laquelle ils ont ´et´e associ´es. La politique des fichiers a ´et´e construite `a partir des donn´ees qu’elles contiennent lors de l’analyse et de la politique des programmes qui y acc`edent. Si une donn´ee sensible a ´et´e trouv´ee dans un fichier, nous avons suppos´e que ce fichier avait le droit de contenir la donn´ee. A ces donn´ees s’ajoutent celles auxquelles les applications ` qui ont le droit d’´ecriture au fichier peuvent acc´eder. Nous avons suppos´e que toute application avait le droit de stocker les donn´ees contenues dans les fichiers auxquels l’application a un acc`es l´egal. G´en´eralement, il s’agit des fichiers dans le r´epertoire local de l’application. Pour les 150 informations identifi´ees lors de la premi`ere ´etape, nous avons identifi´e 186 conteneurs d’information pouvant acc´eder `a ces informations o`u les stocker. La politique contient donc 186 ptags. La politique finale a ´et´e repr´esent´ee sous la forme d’une matrice dont un extrait est pr´esent´ee dans le tableau 3.3. Le chemin complet des fichiers a ´et´e omis pour une meilleure lisibilit´e. Une croix `a l’intersection d’une ligne et d’une colonne signifie que le conteneur correspondant `a la ligne a le droit de stocker l’information correspondant `a la ligne. L’ensemble des croix sur une ligne l d´etermine ainsi le contenu maximal autoris´e pour le conteneur correspondant `a l. L’utilisateur 10004 (avant derni`ere ligne) a par exemple le droit d’acc´eder aux informations identifi´ees par 6, 10, ´39 et ´55. Autrement dit, son ptag vaut tt´55, ´39, 6, 10uu. Si la pertinence de la politique n’a pas ´et´e ´evalu´ee dans ce travail, le travail effectu´e a cependant permis de mettre en ´evidence deux points. Le premier est3.3. KBLARE : SUIVI ET CONTROLE DE FLUX VIA LSM ˆ 65 la difficult´e de la cr´eation de la politique `a la main car elle a n´ecessite une analyse compl`ete du syst`eme pour identifier les informations sensibles et leurs conteneurs l´egaux. Le deuxi`eme point est le nombre d’information sensible sur le syst`eme. Contrairement `a ce que les permissions Android pourraient laisser croire, il peut y avoir un nombre assez cons´equent d’information sensible sur le syst`eme. La politique que nous avons construite recense 150 informations mais il y a encore plus d’information que cela dans un syst`eme. 3.3 KBlare : suivi et contrˆole de flux via LSM Le cœur de Blare a ´et´e d´evelopp´ee en tant que module de s´ecurit´e Linux. Il r´eside dans le noyau et est appel´e KBlare. Dans le reste du document, nous d´esignons par KBlare l’impl´ementation de Blare dans le noyau et Blare tout l’environnement d’ex´ecution Blare (KBlare plus les outils en espace utilisateur li´e `a Blare). Les flux d’information au niveau du syst`eme se font via les interactions entre les objets du syst`eme et plus pr´ecis´ement via les appels syst`eme effectu´es par les processus. Pour contrˆoler les flux d’information, KBlare intercepte ainsi les appels syst`eme en utilisant les hooks LSM [103, 102]. LSM est un framework de s´ecurit´e dans le noyau utilis´e pour impl´ementer les modules de s´ecurit´e Linux. Les hooks sont des appels aux modules de s´ecurit´e du noyau. Ils sont plac´es dans le flux d’ex´ecution des appels syst`eme afin que les modules de s´ecurit´e puisse intercepter et contrˆoler ces appels. Pour intercepter un appel syst`eme, un module de s´ecurit´e enregistre une fonction `a associer au hook correspondant `a l’appel syst`eme. A chaque fois que ce ` hook est atteint, le noyau appelle la fonction enregistr´ee afin que le module de s´ecurit´e effectue le contrˆole souhait´e. La figure 3.3 illustre le fonctionnement g´en´eral de LSM. Lors d’un appel syst`eme, le noyau v´erifie si l’acc`es demand´e est autoris´e pour le processus effectuant l’appel. Il commence par v´erifier la conformit´e avec la politique DAC du syst`eme. Ensuite, il donne la main `a LSM qui lui demande au module de s´ecurit´e actif 3 s’il autorise ou non l’acc`es demand´e. Cette ´etape correspond au moment o`u un hook est atteint dans le flux de traitement de l’appel syst`eme. La fonction enregistr´ee au hook est ainsi appel´ee et statue si l’acc`es est autoris´e. Lorsqu’un processus fait un appel syst`eme, KBlare intercepte l’appel, calcule le flux correspondant, met `a jour les tags des objets modifi´es et contrˆole la l´egalit´e du flux observ´e. KBlare se contente cependant de d´etecter les intrusions mais ne les pr´evient pas. Mˆeme en cas de violation de la politique de flux d’information, il autorise le noyau `a continuer le traitement de l’appel syst`eme. Le tableau 3.4 liste les hooks utilis´es par KBlare dont l’op´eration correspondante peut engendrer des flux d’information. La premi`ere colonne liste les hooks, le deuxi`eme les op´erations intercept´ees via le hook et la derni`ere colonne les types de flux que KBlare peut observer. D’autres hooks sont utilis´es pour le fonctionnement interne de KBlare mais les op´erations correspondantes n’induisent aucun flux d’information. 3. En g´en´eral un seul module LSM est actif66 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION process Syscall #n Security module DAC LSM User space Kernel space exec syscall authorize? Figure 3.3 – Design de Linux Security Module3.3. KBLARE : SUIVI ET CONTROLE DE FLUX VIA LSM ˆ 67 Hook Op´eration Flux possible observ´e file permission Lecture/´ecriture `a un fi- chier ouvert Entre le processus et le fichier acc´ed´e file mmap Chargement en m´emoire du contenu d’un fichier Du fichier vers le processus inode permission Acc`es `a un i-node Entre un pipe et un processus bprm set creds Ex´ecution d’une application native Du fichier contenant l’application vers le processus socket sock rcv skb R´eception d’un paquet r´eseau De paquet re¸cu vers le processus socket sendmsg Envoi d’un message dans un socket r´eseau Du processus vers le socket et le paquet socket recvmsg R´eception d’un message via un socket Du socket vers le processus unix may send Envoi d’un message via un socket UNIX Du processus vers le socket UNIX msg queue msgrcv R´eception d’un message via une file de message Du processus vers le message envoy´e msg queue msgsnd Envoi d’un message dans une file de message Du message re¸cu vers le processus destinataire du message Table 3.4 – Liste des hooks LSM utilis´es par KBlare pouvant engendrer un flux d’information Stockage des tags KBlare repr´esente les tags des objets du syst`eme avec des structures contenant l’itag, le ptag et le xptag associ´es aux objets. En dehors des hooks, LSM a ´egalement modifi´e les structures repr´esentant les objets du syst`eme pour ajouter un champ appel´e security. Ce champ est un pointeur g´en´erique destin´e `a ˆetre utilis´e par les modules de s´ecurit´e. KBlare utilise ce champ pour stocker le pointeur vers la structure repr´esentant les tags. Les structures repr´esentant l’ensemble des tags existent uniquement en m´emoire et n’existent donc que le temps d’un cycle d’ex´ecution du syst`eme. Afin de stocker de mani`ere persistante les tags associ´es aux fichiers, KBlare stocke ´egalement leurs tags dans les attributs ´etendus des fichiers. Les attributs ´etendus sont des zone de m´emoire sur le disque qui sont utilis´ees par les syst`emes de fichier pour stocker des m´eta-donn´ees li´ees aux fichiers.68 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION KBlare contrˆole les flux d’information en interceptant les appels syst`eme et pour intercepter les appels syst`eme il utilise les hooks LSM. Ces appels permettent les interactions entre les objets du syst`eme : acc`es aux fichiers, ex´ecution de code natif et communication entre processus. Le noyau d’Android est bas´e sur celui de Linux mais contient des fonctionnalit´es en plus. Dans la section suivante, nous pr´esentons comment nous avons modifi´e KBlare afin de prendre en compte les fonctionnalit´es sp´ecifiques `a Android. 3.4 AndroBlare : Blare sous Android Le premier apport de cette th`ese est le portage de Blare sous Android. Nous avons montr´e pr´ec´edemment que Blare contrˆolait les flux d’information traduisant les acc`es aux fichiers, les ex´ecution de code et les communications entre processus. Ces contrˆoles sont bas´es uniquement sur les interactions possibles entre les objets du syst`eme sous Linux. Or, Android int`egre des fonctionnalit´es qui lui sont propres pouvant engendrer des flux d’information. Ces fonctionnalit´es sont l’ex´ecution des applications par les machines virtuelles Dalvik et les communications via le Binder. Le Binder est un m´ecanisme de communication impl´ement´e principalement dans le noyau Android. Il est la base des communications entre processus propos´es par le framework Android tels que les intents. Android n’utilise pas les m´ecanismes de communication offerts par Linux. Les communications entre applications ´etaient donc invisibles `a KBlare. Les applications que nous avons d´esign´ees par la couche Applications sur la figure 2.1 sont livr´ees sous la forme de dalvik bytecode et interpr´et´ees par la machine virtuelle Dalvik. Elles ne sont donc pas ex´ecut´ees de mani`ere native. A leur ` ex´ecution, le processus contenant la machine virtuelle qui va interpr´eter le code n’effectue pas d’appel syst`eme execve mais se contente de lire puis charger le code de l’application en m´emoire. Aucun appel syst`eme traduisant l’ex´ecution d’une application n’ayant lieu, KBlare ne voyait donc pas l’ex´ecution des applications. En cons´equent, aucune politique ne pouvait ˆetre appliqu´ee aux applications Android et aucun processus n’´etait marqu´e comme ex´ecutant une application lorsque le code de cette application ´etait associ´ee `a un identifiant. Limitations de Blare (1) Il n’y avait aucune visibilit´e sur les communications entre applications Android. (2) KBlare ne d´etectait pas l’ex´ecution des applications Android. Les tags des processus n’indiquaient jamais l’ex´ecution d’une application dont le code est sensible et aucune politique ne pouvait ˆetre appliqu´ee aux applications. Dans ce qui suit, nous pr´esentons comment nous avons modifi´e Blare pour combler ce manque de visibilit´e au niveau des flux d’information sous An-3.4. ANDROBLARE : BLARE SOUS ANDROID 69 droid. Nous pr´esentons le fonctionnement du Binder puis comment nous avons impl´ement´e le suivi des flux d’information via ce m´ecanisme. Ensuite, nous expliquons comment les applications Android sont ex´ecut´ees et comment nous avons ajout´e a prise en compte de leur ex´ecution dans Blare. 3.4.1 Communication entre processus : Binder 3.4.1.1 Fonctionnement Les applications Android tournent dans des processus distincts mais communiquent souvent entre elles grˆace `a divers m´ecanismes IPC tels que les intents et les Content Providers. Ces m´ecanismes sont fournis par le framework Java Android mais se basent tous `a un niveau plus bas sur le Binder. Le Binder est un m´ecanisme IPC qui permet `a une application d’appeler une m´ethode distante, c’est-`a-dire impl´ement´ee au sein d’une autre application tournant dans un autre processus. Le cœur de ce m´ecanisme est impl´ement´e dans le noyau sous forme de driver 4 dans le noyau. Par la suite nous adopterons les termes suivants. Le Binder fait r´ef´erence au code du Binder dans le noyau. Un service est une application dont les m´ethodes peuvent ˆetre appel´ees par d’autres applications. Un client est une application qui appelle une m´ethode d’un service. La figure 3.4 illustre le fonctionnement du binder lors de l’appel d’une m´ethode distante. Tout client doit avoir une r´ef´erence du service impl´ementant la m´ethode qu’il souhaite invoquer. Le client commence ainsi par demander la r´ef´erence du service cibl´e `a un autre service appel´e Context. Context, impl´ement´e sous Android par le Service Manager, est un service d’annuaire qui fait correspondre `a chaque nom de service une r´ef´erence unique. Chaque service doit s’enregistrer aupr`es du Service Manager afin que ses m´ethodes puissent ˆetre invoqu´ees par d’autres applications. Lorsqu’un client souhaite obtenir la r´ef´erence d’un service, il appelle ainsi la m´ethode getService du Service Manager en lui donnant en argument le nom du service. Une fois la r´ef´erence du service obtenu, le client appelle la m´ethode. L’invocation de la m´ethode n’est pas directe. Le client ne communique pas directement avec le serveur mais transmet l’appel au binder qui lui le transmet au serveur. Une fois l’appel re¸cu puis ex´ecut´e par le serveur, ce dernier renvoie le r´esultat au binder qui lui le transmet au client. 3.4.1.2 Impl´ementation du Binder dans le noyau Techniquement parlant, le Binder est impl´ement´e sous forme de driver dans le noyau. Cela signifie qu’il est pr´esent´e dans l’espace utilisateur en tant que fichier, /dev/binder, et que les seules interactions possibles sont des appels syst`eme sur ce fichier. Le listing 3.2 liste les op´erations sur les fichiers, voir le chapitre 3 de [40], support´es par Binder. Elles sont list´es dans une structure appel´ee file operations qui associe `a chaque op´eration support´ee la fonction correspondante. Par exemple, la valeur du champ open correspond `a la fonc- 4. /drivers/staging/android/binder.c70 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION Client App Context Binder Driver Service App get service service ref call func(param) relay call func(param) call return relay call return Figure 3.4 – Appel d’une m´ethode distante grˆace au Binder tion, ici binder open, qui sera appel´ee `a chaque fois qu’un processus ouvre /dev/binder. Celle qui a int´erˆet pour nous est la fonction binder ioctl (listing 3.3). Elle est appel´ee quand un processus effectue un appel syst`eme ioctl et prend les arguments de l’appel syst`eme. Le deuxi`eme argument de la fonction, cmd, correspond `a la commande `a ex´ecuter par le Binder. Binder reconnaˆıt 5 commandes. — BINDER WRITE READ est la commande la plus importante. Elle sert `a l’envoi et r´eception de donn´ees. — BINDER SET MAX THREADS d´efinit le nombre maximal de threads par processus pour traiter les messages re¸cus via le Binder. — BINDER SET CONTEXT MGR d´efinit le Context Manager. Une fois d´efini, il ne peut ˆetre modifi´e. — BINDER THREAD EXIT notifie l’arrˆet d’un thread utilis´e pour le traitement des messages re¸cus via le Binder. — BINDER VERSION retourne le num´ero de version du Binder. Lorsqu’un processus envoie la commande BINDER WRITE READ dans le but d’envoyer des donn´ees, il d´efinit une deuxi`eme commande pr´ecisant le type d’envoi. Il existe 14 commandes 5 li´ees `a l’envoi de donn´ees mais seules deux d’entre elles correspondent `a l’envoi des transactions : BINDER TRANSACTION et BINDER REPLY. BINDER TRANSACTION correspond `a l’´emission d’une transaction d’un processus client appelant une m´ethode distante. BINDER REPLY correspond `a l’envoi du r´esultat de l’appel par le processus ayant ex´ecut´e la fonction. L’envoi d’un message ayant un de ces deux types initie l’appel `a la fonction binder transaction qui impl´emente la troisi`eme et la cinqui`eme ´etapes de l’appel d’une m´ethode distante comme d´ecrit sur la figure 3.4 : call func(param) et call return. Toute action ex´ecut´ee par le noyau se fait dans le contexte 5. Voir la fonction binder thread write3.4. ANDROBLARE : BLARE SOUS ANDROID 71 d’un processus `a l’exception des interruptions 6 . Dans le cas des appels syst`eme, le contexte d’ex´ecution est celui du processus ayant fait l’appel ce qui signifie que l’envoi des transactions se fait dans le contexte de l’´emetteur. Lorsque le Binder transmet une transaction `a un processus, il l’ajoute `a une liste de tˆache `a traiter par ce processus. Les processus en attente de transaction consultent ainsi cette liste de tˆache pour traiter les transactions qui lui ont ´et´e transmises grˆace `a la commande BINDER WRITE READ. Chacune des tˆaches a un type d´efini. Il existe 6 types de tˆache en tout dont BINDER WORK TRANSACTION qui correspond au traitement d’une transaction en attente. A la r´eception ` d’une tˆache de ce type, les informations li´ees `a la transaction sont envoy´ees au processus en espace utilisateur afin qu’il puisse ex´ecuter l’appel. Le Binder est le cœur des IPC sous Android mais son usage n’´etait pas contrˆol´e par KBlare. Il y a deux raisons `a cela. La premi`ere est que son usage se fait via l’appel syst`eme ioctl or KBlare n’utilise pas le hook permettant d’intercepter cet appel. La deuxi`eme raison est que Binder est un m´ecanisme propre `a Android. Aucun travail ne s’est donc int´eress´e `a ´etendre LSM afin de pouvoir contrˆoler l’usage du Binder au moment o`u nous nous sommes int´eress´es au Binder durant la th`ese. A cause de ces raisons, KBlare ignorait les flux ` d’information via le Binder et ne pouvait observer les communications entre applications Android. Nous pr´esentons dans la section qui suit comment KBlare a ´et´e ´etendu pour suivre les flux d’information caus´es par son usage. 1 static const struct file_operations binder_fops = 2 { 3 .owner = THIS_MODULE, 4 .poll = binder_poll, 5 .unlocked_ioctl = binder_ioctl, 6 .mmap = binder_mmap, 7 .open = binder_open, 8 .flush = binder_flush, 9 .release = binder_release, 10 }; Listing 3.2 – Liste des op´erations sur les fichiers support´ees par Binder 1 static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg); Listing 3.3 – Signature de la fonction binder ioctl 6. Ce n’est jamais notre cas dans le Binder72 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION 3.4.2 Suivi de flux d’information dans le Binder Pour suivre les flux d’information li´ees aux transactions via le Binder, deux solutions ont ´et´e envisag´ees. La premi`ere solution est d’intercepter l’appel syst`eme ioctl grˆace au hook file ioctl. Cette solution est limit´ee car elle ne permettrait de voir que l’interaction entre les processus et /dev/binder. Or nous avons expliqu´e que le v´eritable flux s’op´erait entre processus et non entre un processus et /dev/binder. Cette limitation pourrait cependant ˆetre contourn´e en impl´ementant tout le m´ecanisme de traitement des commandes envoy´ees via ioctl au Binder mais cette approche est assez lourde. La deuxi`eme solution, celle que nous avons retenu, consiste `a ´etendre LSM afin de permettre aux modules de s´ecurit´e de contrˆoler l’envoi et la r´eception des transactions via le Binder. L’extension de LSM que nous avons apport´e consiste `a rajouter un champ security `a la structure repr´esentant les transactions et deux nouveaux hooks pour intercepter l’envoi et la r´eception de transaction. Tout comme les messages envoy´es dans les files de message, nous consid´erons que les transactions sont des conteneurs volatiles. Nous avons ainsi ajout´e un champ g´en´erique security `a la structure les repr´esentant. KBlare utilisera ensuite ce champ pour r´ef´erencer les tags associ´es `a la transaction. Les deux nouveaux hooks ont ´et´e rajout´es dans le code de Binder 7 . Quant aux hooks, nous les avons ajout´e dans le corps du Binder pour intercepter les ´echanges de transaction. Plus pr´ecis´ement, nous avons ajout´e un hook pour intercepter l’envoi d’une transaction et une autre pour la r´eception. Sous Android, KBlare utilise ces hooks pour suivre et contrˆoler les flux d’information 8 via le Binder. Interception de l’envoi d’une transaction binder transaction write Nous avons ins´er´e ce hook dans le corps de la fonction binder transaction. Cette fonction est utilis´ee par Binder pour transmettre les transactions ´emises par les processus. C’est dans cette fonction que la nouvelle tˆache correspondant `a la transaction est ajout´ee `a la liste de tˆache en attente du destinataire. Le hook est ins´er´e avant l’ajout de la nouvelle tˆache. Dans KBlare, nous avons d´eclar´e une fonction correspondant `a ce hook qui propage les tags du processus vers la transaction. La fonction cr´ee une instance de la structure contenant le tag des conteneurs d’information, l’associe `a la transaction et copie les tags du processus (itag et xptag) vers la structure contenant les tags de la transaction. Nous consid´erons que les transactions ont le droit de contenir n’importe quelle information. Aucun contrˆole n’est ainsi effectu´e. Interception de la r´eception d’une transaction binder thread read Le deuxi`eme hook est ins´er´e dans le corps de la fonction binder thread read. Cette fonction est utilis´ee pour r´ecup´erer et transmettre au processus destinataire en espace utilisateur les tˆaches dans la liste d’attente. La fonction 7. drivers/staging/android/binder 8. Fonctions correspondantes impl´ement´ees dans security/blare/binder ops.c3.4. ANDROBLARE : BLARE SOUS ANDROID 73 associ´ee `a ce hook propage les tags (itag et xptag) associ´es `a la transaction vers le processus destinataire. Un contrˆole de la l´egalit´e du flux est effectu´ee. Si le flux est ill´egal alors une alerte est lev´ee. Afin que l’alerte soit plus compr´ehensible, le flux correspondant `a l’alerte est d´ecrite comme un flux de processus ayant ´emis la transaction vers le processus destinataire. De plus, une transaction est un conteneur volatile impl´ement´e sous la forme d’une structure uniquement connue du noyau. Sa description dans une alerte n’apportera ainsi aucune information utile `a un analyste. Selon les transactions, les informations li´ees `a l’´emetteur ne sont pas ajout´ees dans la transaction. C’est le cas, par exemple des r´eponses retourn´ees par un appel distant. Nous avons modifi´e le Binder afin que cette information soit toujours comprise dans la transaction. Remarque sur le suivi de flux d’information dans le Binder Une autre mani`ere de propager les tags entre les processus aurait ´et´e de le faire directement `a l’envoi de la transaction par le processus ´emetteur. Cependant, nous avons opt´e pour un suivi de flux en deux temps. Les tags sont propag´es du processus ´emetteur vers la transaction puis de la transaction vers le processus destinataire. Chaque action effectu´ee par le noyau se fait toujours dans le contexte d’un processus. Pour les appels syst`eme, il s’agit du processus ayant effectu´e l’appel syst`eme. Lors de l’envoi de la transaction, le Binder s’ex´ecute ainsi dans le contexte du processus ´emetteur. Propager directement les tags `a l’envoi signifie modifier la structure associ´ee au processus destinataire tout en ´etant dans le contexte de l’´emetteur. Cette pratique n’est cependant pas conseill´ee dans la programmation noyau. Nous aurions ´egalement pu faire la propagation lors du traitement des tˆaches de la liste d’attente. Cela se fait dans le contexte du processus destinataire mais le risque est la possibilit´e de changement du contenu du processus ´emetteur entre l’envoi et la r´eception de la transaction. Cela pourrait par exemple permettre d’´echanger des donn´ees tout en faisant croire `a KBlare qu’aucune d’entre elles n’est sensible. En optant pour la propagation en deux temps des tags, nous ne modifions pas la structure d’un processus autre que celui qui sert de contexte d’ex´ecution et nous maintenons une coh´erence entre les identifiants des informations partant du processus ´emetteur et ceux des informations r´ecup´er´ees par le destinataire. Afin de prendre en compte les flux d’information s’op´erant via le Binder, nous avons ´etendu le framework LSM. Nous avons ajout´e deux nouveaux hooks permettant d’intercepter l’envoi et la transmission des transactions. Dans le code du Binder, les transactions repr´esentent les appels de m´ethodes distantes ainsi que le retour de ces appels. Nous avons ensuite ajout´e deux fonctions suppl´ementaires `a KBlare qui correspondent `a ces nouveaux hooks et effectuent la propagation des tags entre les applications qui communiquent via le Binder.74 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION 3.4.3 Ex´ecution des applications Android 3.4.3.1 Interpr´etation de code vs ex´ecution Dans Blare, la prise en compte de l’ex´ecution d’un code se fait en interceptant les appels syst`eme execve et mmap quand la page est marqu´ee comme ´etant ex´ecutable. Sous Android, `a l’exception des applications n´ecessaires au fonctionnement syst`eme, les applications tournent au sein d’instance de la machine virtuelle dalvik. Pour comprendre comment ces instances sont cr´e´ees, il est n´ecessaire de comprendre la s´equence de d´emarrage d’Android. La figure 3.5 illustre cette s´equence. Comme pour les syst`emes de type Linux, le premier processus lanc´e est init qui est en charge d’initialiser l’environnement Android. Les initialisations qu’il effectue sont d´efinies dans les fichiers init.*rc `a la racine du syst`eme de fichier. Il d´efinit par exemple les variables d’environnement et monte les partitions. Il lance ´egalement les diff´erents processus d´emons du syst`eme tels que servicemanager, surfaceflinger et Zygote. A son lancement, ce dernier ` lance une instance de la machine virtuelle dalvik, cr´ee un socket serveur, charge un ensemble de ressources et classes Java, se duplique pour cr´eer le processus system server et attend les connexions sur le socket cr´e´e. System server est le processus qui ex´ecute les diff´erents services du syst`eme (ex : Activity Manager). A sa cr´eation, il les lance donc et les enregistre aupr`es de ` servicemanager afin qu’ils puissent ˆetre appel´es par les diff´erentes applications du syst`eme. Zygote est un processus cl´e pour l’ex´ecution des diff´erentes applications Android car c’est `a partir de ce processus que les autres applications sont lanc´ees. Par exemple, lorsque l’utilisateur lance une nouvelle application via le menu principal du t´el´ephone, l’application Lancher appelle la fonction startActivity d´efinie dans Activity Manager. A l’ex´ecution de la m´ethode, ce dernier envoie ` une requˆete `a Zygote pour lancer l’application. A la r´eception de la requˆete, ce ` dernier se duplique 9 et lance dans le processus fils la nouvelle application. Au l’ex´ecution d’une nouvelle application, le processus l’ex´ecutant charge le code de l’application en m´emoire. Ce code est sous format dalvik et n’est pas ex´ecut´e, comprendre via l’appel syst`eme execve ou mmap et marqu´e ex´ecutable, mais charg´e comme une simple donn´ee en m´emoire. L’ex´ecution des applications se traduit par la lecture de leur code en m´emoire et son interpr´etation par la machine virtuelle dalvik. Comme aucun appel syst`eme synonyme d’ex´ecution de code pour Blare n’est effectu´e alors Blare, dans sa version avant nos modi- fications, ne d´etectait jamais l’ex´ecution des applications Android. Cela avait deux cons´equences directes. Premi`erement, l’ex´ecution des applications Android dont le code est marqu´e comme sensible ne causait pas le marquage des processus comme ex´ecutant du code sensible. L’itag des processus ex´ecutant les applications Android ne contenait jamais d’identifiant n´egatif. Ensuite, il ´etait impossible d’appliquer une politique par application car du point de vue de Blare ils ex´ecutent tous le mˆeme programme (app process). 9. appel syst`eme fork3.4. ANDROBLARE : BLARE SOUS ANDROID 75 Native daemons - servicemanager -netd -vold -mediaserver - app_process -X Init - Set up env variables - mount partitions - Zygote - etc start native daemons - etc Zygote - Start a dalvik virtual machine - Execute main function of zygote - Create a server socket - Preload resources and classes - Start system_server - Wait for application launch request system_server - Launch services (Activity Manager, Clipboard etc) - Register services App App App startActivity fork fork Figure 3.5 – S´equence de d´emarrage d’Android76 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION 3.4.3.2 Prise en compte de l’ex´ecution des applications Android Pour d´etecter l’ex´ecution des applications, nous avons introduit un syst`eme de coop´eration entre la machine virtuelle Dalvik et KBlare. Il permet `a la machine virtuelle de notifier KBlare quand elle va interpr´eter du code et donc permettre `a KBlare de voir quand une application est ex´ecut´ee. A la r´eception ` de la notification, KBlare met ainsi `a jour les tags convenablement et applique la politique de flux associ´ee `a l’application. L’ex´ecution d’une application se traduit par le chargement des ressources de l’application en m´emoire ainsi que de son code. Lorsqu’une application Android est install´ee, le syst`eme extrait `a partir de son apk une version optimis´ee du code. C’est cette version optimis´ee qui est charg´ee en m´emoire et interpr´et´ee par la machine virtuelle. Un bon point d’insertion pour la notification semble ainsi ˆetre le chargement de cette version optimis´ee. Aucune documentation technique n’existe sur le fonctionnement de Dalvik mais en analysant son code source, nous trouvons que le chargement est effectu´e par la fonction dvmDexFileOpenFromFd (listing 3.4). Cette fonction charge en m´emoire le code optimis´e d’une application et analyse syntaxiquement son contenu. Elle est appel´ee par deux autre fonctions 10 qui ouvrent un fichier jar ou dex, cr´ee la version optimis´ee du code `a partir du contenu du fichier ouvert et le charge en m´emoire. Cela correspond bien `a l’ex´ecution d’une application. Nous avons ainsi ajout´e la notification, fonction odex is mapped, au corps de la fonction dvmDexFileOpenFromFd. La figure 3.6 illustre les diff´erentes ´etapes de la prise en compte de l’ex´ecution de l’application. Les tags vert et bleu correspondent respectivement au contenu du fichier .dex et `a ce mˆeme contenu lorsqu’il est ex´ecut´e par un processus. Le tag marron correspond `a la politique de s´ecurit´e de l’application. Le syst`eme de notification est similaire `a une architecture client/serveur. Au d´emarrage du syst`eme, KBlare se met en ´ecoute des notifications provenant des machines virtuelles Dalvik. (a) Lorsqu’un processus initie l’ex´ecution d’une application (chargement du fichier .dex en m´emoire), elle charge le contenu du fichier .dex en m´emoire. KBlare voit ce chargement et marque le processus qui va ex´ecuter l’application comme contenant le contenu du fichier .dex. (b) La machine virtuelle notifie ensuite KBlare qu’elle va interpr´eter le contenu du fichier .dex, c’est- `a-dire l’ex´ecuter. (c) et (d) A la r´eception de la notification, KBlare consid`ere ` que le processus contenant la machine virtuelle ayant envoy´ee la notification va ex´ecuter l’application dont le code est stock´e dans le fichier .dex. KBlare met donc `a jour les tags du processus. Il indique que le processus contient la version ex´ecut´ee du contenu du fichier .dex et applique `a ce processus la politique de flux associ´ee au code que la machine virtuelle va interpr´eter. Impl´ementation de la notification de l’ex´ecution d’une application La notification est envoy´ee grˆace `a un canal de communication entre la machine virtuelle Dalvik et KBlare. Ce canal est impl´ement´e avec Generic Net- 10. dvmJarFileOpen et dvmRawDexFileOpen respectivement d´efinies dans dalvik/vm/JarFile.cpp et dalvik/vm/RawDexFile.cpp3.4. ANDROBLARE : BLARE SOUS ANDROID 77 VM init : - Load ressources - Load optimzed dex - Notify KBlare - ... KBlare : - Listen to notification - Upon notification: * Get tags associated to the odex file * Update tags associated to the process odex file (a) (b) (c) (d) Figure 3.6 – M´ecanisme de notification de l’ex´ecution d’une application Android link [52] qui lui utilise les sockets Netlink [63]. Netlink est un m´ecanisme de communication qui permet de faire communiquer entre eux des morceaux de code qui sont dans le noyau ou en espace utilisateur. La communication entre ces diff´erentes entit´es se font dans des bus Netlink, appel´es ´egalement protocoles. Il existe un nombre d´efini de bus dans les syst`emes Linux et leur nombre maximum est limit´e `a 32. Certains d’entre eux sont par exemple utilis´es par des outils de gestion du trafic r´eseau tels que iproute2 [53]. Generic Netlink est un m´ecanisme de communication bas´e sur Netlink et plus pr´ecis´ement un multiplexeur construit au dessus d’un bus Netlink [76]. Les canaux de communication sont appel´es familles et il est possible d’en d´efinir jusqu’`a 65520 pour un seul et mˆeme bus Netlink. Nous pr´esentons dans ce qui suit le syst`eme de coop´eration permettant de faire communiquer les machines virtuelles Dalvik et KBlare. Plus pr´ecis´ement, nous pr´esentons la d´eclaration de la famille servant de canal de communication, le comportement associ´e `a la r´eception d’une notification et la mise en attente. Comme ´ecrit pr´ec´edemment, le syst`eme de notification est une architecture client/serveur. KBlare est le serveur qui se met en attente des notifications d’ex´ecution d’application et les machines virtuelles Dalvik sont les clientes qui envoient les notifications au serveur. La cr´eation d’un serveur d’´ecoute avec Generic Netlink se fait en trois ´etapes : cr´eation d’une famille, d´efinition des commandes reconnues par le serveur et enregistrement de la famille. Afin que KBlare puisse recevoir les notifications, nous d´efinissons dans son code une famille servant de canal de communication. Le listing 3.5 montre la d´eclaration de la famille. Nous d´eclarons en premier les attributs possibles d’un message. Nous en d´eclarons deux : DOC EXMPL A MSG et DOC EXMPL A INT. Ensuite, nous d´efinissons le type associ´e aux attributs. Le premier attribut est une78 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION 1 int dvmDexFileOpenFromFd(int fd, DvmDex** ppDvmDex) 2 { 3 DvmDex* pDvmDex; 4 DexFile* pDexFile; 5 MemMapping memMap; 6 int parseFlags = kDexParseDefault; 7 int result = -1; 8 9 if (gDvm.verifyDexChecksum) 10 parseFlags |= kDexParseVerifyChecksum; 11 12 if (lseek(fd, 0, SEEK_SET) < 0) { 13 ALOGE("lseek rewind failed"); 14 goto bail; 15 } 16 17 if (sysMapFileInShmemWritableReadOnly(fd, &memMap) != 0) { 18 ALOGE("Unable to map file"); 19 goto bail; 20 } 21 22 // Nofify KBlare 23 odex_is_mapped(fd); 24 ... 25 } Listing 3.4 – Fonction de chargement en m´emoire du code d’une application chaˆıne de caract`ere et le second un entier non sign´e sur 32 bits. Enfin, nous d´eclarons la famille : variable doc exmpl gnl family. Chaque famille doit avoir un identifiant unique 11. Le champ id contient l’identifiant num´erique de la famille. En lui associant la valeur GENL ID GENERATE, nous laissons au syst`eme le choix de l’identifiant. Le champ hdrsize d´efinit la taille de l’en-tˆete des messages transitant par cette famille. Nous n’avons besoin d’aucune en-tˆete sp´ecifique. Nous le mettons ainsi `a 0. Le champ name d´efinit le nom de la famille. Chaque nom doit ˆetre unique et elle permet aux clients de r´ecup´erer l’identifiant de la chaine. Les champs restant d´efinissent le num´ero de version de la famille et le nombre d’attributs. Une fois la famille d´efinie, il faut ensuite d´eclarer les commandes qu’elle supporte ainsi que les fonctions qui leur sont associ´ees. Les commandes d´efinissent les op´erations support´ees par le serveur. Nous en d´efinissons un, DOC EXMPL EXEC DEX, dans le listing 3.6 qui correspond `a la notification de l’ex´ecution d’une application. A cette commande, nous associons la fonction ` doc exmpl exec dex. 11. champ id3.4. ANDROBLARE : BLARE SOUS ANDROID 79 1 // USE GENERIC NETLINK 2 /* Family declaration */ 3 /* attributes */ 4 enum { 5 DOC_EXMPL_A_UNSPEC, 6 DOC_EXMPL_A_MSG, 7 DOC_EXMPL_A_INT, 8 __DOC_EXMPL_A_MAX, 9 }; 10 #define DOC_EXMPL_A_MAX (__DOC_EXMPL_A_MAX - 1) 11 12 /* attribute policy */ 13 static struct nla_policy doc_exmpl_genl_policy[DOC_EXMPL_A_MAX + 1] = { 14 [DOC_EXMPL_A_MSG] = { .type = NLA_NUL_STRING }, 15 [DOC_EXMPL_A_INT] = { .type = NLA_U32 }, 16 }; 17 18 #define VERSION_NR 1 19 static struct genl_family doc_exmpl_gnl_family = { 20 .id = GENL_ID_GENERATE, 21 .hdrsize = 0, 22 .name = "BLARE_COOP", // family name 23 .version = VERSION_NR, //version number 24 .maxattr = DOC_EXMPL_A_MAX, 25 }; 26 /* End of family declaration */ Listing 3.5 – D´eclaration d’une famille Generic Netlink dans le noyau pour le m´ecanisme de coop´eration Cette fonction r´ecup`ere `a partir de la charge utile du message re¸cu par le serveur un entier repr´esentant le descripteur du fichier charg´e par la machine virtuelle (ligne 24 `a 26). A partir de ce descripteur, il r´ecup`ere la structure correspondant ` au fichier puis met `a jour les tags associ´es au processus (ligne 36 `a 38). Enfin, nous enregistrons la famille et les op´erations qu’elle supporte (listing 3.7). Ces enregistrements sont effectu´es dans la fonction netlink init qui est appel´ee pendant l’initialisation des modules de noyau (ligne 22). Du cˆot´e client, la communication avec KBlare est plus simple. Elle se traduit par l’envoi d’un message avec la commande DOC EXMPL EXEC DEX et le descripteur de fichier correspondant au code charg´e en m´emoire. La biblioth`eque libnl [11] offre une API les sockets Netlink et Generic Netlink. Cependant, dans la version actuelle du code, nous avons utilis´e les fonctions d´efinies dans l’exemple du client fourni par A. Keller dans [64]. Le listing 3.8 pr´esente une version ´epur´ee 12 du code servant `a la notification de l’ex´ecution des applications Android. La variable req est le message Netlink `a envoyer dans le noyau. 12. sans v´erification des codes d’erreur80 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION Il contient l’en-tˆete du message Netlink, celui de Generic Netlink et la charge utile du message. Rappelons que Generic Netlink n’est qu’un multiplexeur au dessus d’un bus Netlink. L’envoi d’une notification se fait en plusieurs ´etapes. 1. R´ecup´erer l’identifiant du canal de communication (lignes 13, 14). Il est n´ecessaire afin d’envoyer le message dans le bon canal de communication. 2. Initialiser les en-tˆetes Netlink et Generic Netlink. Dans le cas de Generic Netlink, il s’agit de d´efinir la commande `a envoyer, DOC EXMPL EXEC DEX. 3. Composer le message. Cela consiste `a d´efinir les attributs `a passer dans le message ainsi que la valeur qui leur est associ´ee. Nous d´efinissons ainsi comme attribut un entier et le descripteur du fichier dex comme valeur associ´ee (ligne 23 `a 28). 4. Envoyer le message. Generic Netlink est un multiplexeur au dessus d’un bus Netlink. Nous d´eclarons ainsi un socket Netlink et envoyons le message avec ce socket. Lorsqu’une machine virtuelle va interpr´eter le contenu d’un fichier .dex, il appelle la fonction odex is mapped (listing 3.4) en lui donnant en param`etre le descripteur du fichier .dex. Cette fonction envoie un message, via une famille de communication Generic Netlink, au noyau et plus pr´ecis´ement `a KBlare. Le message contient deux informations. La premi`ere est une commande qui permet au destinataire de choisir le traitement `a effectuer `a la r´eception du message. La deuxi`eme information est le descripteur du fichier .dex. Il permettra `a KBlare d’identifier le fichier dont le contenu va ˆetre interpr´et´e par la machine virtuelle et propager les tags de ce fichier vers le processus contenant la machine virtuelle. A la r´eception du message dans le noyau, ce dernier extrait du message la ` commande que le message contient. KBlare ayant associ´ee `a la commande, la fonction doc exmpl dex (listing 3.6), le noyau transfert le traitement du message `a cette fonction. La fonction r´ecup`ere `a partir du message le descripteur de fichier et `a partir de ce descripteur, il r´ecup`ere la structure repr´esentant le fichier contenant le code qui va ˆetre interpr´et´e. A partir de cette structure, KBlare ` r´ecup`ere les tags associ´es aux fichiers et les propage comme dans le cas d’une ex´ecution au processus ayant envoy´e la notification. A la r´eception du message, ` KBlare tourne dans le contexte du processus ayant envoy´e la notification. Ce sont donc les tags de ce processus qui sont mis `a jour.3.4. ANDROBLARE : BLARE SOUS ANDROID 81 1 /* commands: enumeration of all commands (functions), 2 * used by userspace application to identify command to be executed 3 */ 4 enum { 5 DOC_EXMPL_C_UNSPEC, 6 DOC_EXMPL_C_EXEC_DEX, 7 __DOC_EXMPL_C_MAX, 8 }; 9 10 #define DOC_EXMPL_C_MAX (__DOC_EXMPL_C_MAX - 1) 11 12 static int doc_exmpl_exec_dex(struct sk_buff *skb_2, struct genl_info *info) { 13 struct nlattr *na; 14 struct sk_buff *skb; 15 int rc; 16 void *msg_head; 17 int * mydata; 18 struct file * dexfile; 19 struct blare_file_struct *fstruct; 20 21 if (info == NULL) 22 goto out; 23 24 na = info->attrs[DOC_EXMPL_A_INT]; 25 if (na) { 26 mydata = (int *) nla_data(na); 27 if (!mydata) 28 printk(KERN_INFO "[BLARE_NETLINK] error while" 29 "receiving data\n"); 30 } else { 31 printk(KERN_INFO "[BLARE_NETLINK] no fd from userspace"); 32 goto out; 33 } 34 35 rcu_read_lock(); 36 dexfile = fcheck(*mydata); 37 if (dexfile) { 38 interp_exec(dexfile); 39 } else { 40 printk(KERN_INFO "[BLARE_NETLINK] could not find" 41 "struct file of %d\n", *mydata); 42 } 43 rcu_read_unlock(); 44 out: 45 return 0; 46 } 47 48 /* Map command and function */ 49 struct genl_ops doc_exmpl_gnl_ops_exec_dex = { 50 .cmd = DOC_EXMPL_C_EXEC_DEX, 51 .flags = 0, 52 .policy = doc_exmpl_genl_policy, 53 .doit = doc_exmpl_exec_dex, 54 .dumpit = NULL, 55 }; Listing 3.6 – D´efinition d’une commande Generic Netlink pour notifier l’ex´ecution d’une application82 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION 1 static int __init netlink_init() { 2 int rc; 3 printk(KERN_INFO "Blare init generic netlink"); 4 5 /* register new family */ 6 rc = genl_register_family(&doc_exmpl_gnl_family); 7 if (rc != 0) 8 goto failure; 9 10 /* register operations */ 11 genl_register_ops(&doc_exmpl_gnl_family, 12 &doc_exmpl_gnl_ops_exec_dex); 13 14 return 0; 15 16 failure: 17 printk(KERN_INFO "[BLARE_NETLINK] an error occured while" 18 "inserting the generic netlink example module\n"); 19 return -1; 20 } 21 22 __initcall(netlink_init); Listing 3.7 – Enregistrement de la famille servant `a la notification d’ex´ecution des applications3.4. ANDROBLARE : BLARE SOUS ANDROID 83 1 int odex_is_mapped(int fd) { 2 int nl_sd; // Netlink socket 3 int id; 4 int r; 5 struct { 6 struct nlmsghdr n; 7 struct genlmsghdr g; 8 char buf[256]; 9 } req; 10 struct nlattr *na; 11 12 /* Get the identifier of the family */ 13 nl_sd = create_nl_socket(NETLINK_GENERIC,0); 14 id = get_family_id(nl_sd); 15 16 /* Init netlink header */ 17 ... 18 19 /* Init generic netlink header */ 20 req.g.cmd = DOC_EXMPL_EXEC_DEX; 21 22 /* Compose message */ 23 na = (struct nlattr *) GENLMSG_DATA(&req); 24 na->nla_type = DOC_EXMPL_A_INT; 25 int mlength = sizeof(int); 26 na->nla_len = mlength + NLA_HDRLEN; 27 memcpy(NLA_DATA(na), &fd, mlength); 28 req.n.nlmsg_len += NLMSG_ALIGN(na->nla_len); 29 30 /* Send message */ 31 struct sockaddr_nl nladdr; 32 memset(&nladdr, 0, sizeof(nladdr)); 33 nladdr.nl_family = AF_NETLINK; 34 r = sendto(nl_sd, (char *)&req, req.n.nlmsg_len, 0, 35 (struct sockaddr *) &nladdr, sizeof(nladdr)); 36 close(nl_sd); 37 return 0; 38 } Listing 3.8 – Notification de l’ex´ecution d’une application par la machine virtuelle Dalvik84 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION 3.4.4 Description des flux observ´es KBlare d´ecrit les flux impliquant des donn´ees sensibles dans un format assez verbeux et sans fournir assez d’information parfois. La figure 3.7 est un exemple de description de flux ´emis par KBlare lorsqu’il d´etecte un flux d’un fichier vers un processus. Parmi les informations que nous aurions aim´e avoir ´etaient le chemin complet du fichier, son identifiant et les informations li´ees au processus. Avoir le chemin complet du fichier permet `a un analyste d’identifier avec pr´ecision le fichier impliqu´e dans le flux. L’identifiant du fichier, son inode, peut ´egalement s’av´erer utile si le nom du fichier est amen´e `a changer au cours de l’ex´ecution du syst`eme. Sous Android, nous avons ainsi mis les alertes sous la forme d´ecrite en fi- gure 3.8. Un message est d´ecoup´e en trois parties s´epar´ees par le caract`ere ’>’. Les deux premi`eres parties d´ecrivent le conteneur source et destination du flux. C TYPE repr´esente le type du conteneur (fichier, socket et processus). C NAME est le nom du conteneur. Dans le cas des sockets, il s’agit de l’adresse IP associ´ee `a la socket. Dans le cas des processus, nous donnons `a la fois le nom du thread courant et du processus. Les deux noms peuvent diff´erer. Par exemple, les services dans system server tournent dans des threads avec des noms diff´erents. Avoir le nom des deux peut ainsi aider `a comprendre quelle partie de l’application est `a l’origine du flux. 3.4.5 Outils en espace utilisateur Il existe sous Linux des outils en ligne de commande pour manipuler les tags Blare associ´es aux fichiers. Leur code est disponible dans la branche master du d´epˆot kblare-tools [38]. Ces outils ont ´et´e port´es sous Android, branche android version du mˆeme d´epˆot, et une version sous forme d’extension d’un navigateur de fichier Android a ´egalement ´et´e d´evelopp´ee lors d’un stage de 2 mois par Q. Dion. L’extension permet de manipuler via l’interface tactile d’un appareil Android les tags associ´es aux fichiers et ´evite ainsi d’avoir `a ouvrir une interface en ligne de commande. Dans le cadre d’un autre stage, T. Saliou a d´evelopp´e Blare Policy Manager (BPM). BPM impl´emente les fonctions de composition et de v´erification des politiques ´ecrites en BSPL et applique la politique r´esultant de la composition sur le syst`eme. Nous avons utilis´e BPM dans [20] pour composer et appliquer les politiques d’application tierce sur un t´el´ephone avec l’environnement AndroBlare. Process with pid 98 running cat made an illegal READ access to file toto.txt Figure 3.7 – Exemple de message lev´e par Blare sous Linux3.5. ANDROBLARE : ANALYSE D’APPLICATIONS ANDROID 85 C TYPE C NAME C ID > C TYPE C NAME C ID > ITAG Figure 3.8 – Format des flux observ´es par Blare sous Android 3.5 AndroBlare : environnement d’analyse d’applications Android Dans cette th`ese, nous avons utilis´e AndroBlare en tant que environnement d’analyse d’application Android. La figure 3.9 illustre l’environnement ainsi que l’usage que nous en aurons dans les chapitres suivants. Pour analyser les applications, nous utilisons un t´el´ephone Nexus S faisant tourner la version AOSP d’Android Ice Cream Sandwich. Nous avons ajout´e au t´el´ephone tout l’environnement AndroBlare : le module de s´ecurit´e dans le noyau, le syst`eme de notification d’ex´ecution d’application Android et les outils utilisateurs pour manipuler les tags. Nous avons ´egalement rajout´e les application Super User afin de recevoir une notification visuelle `a chaque fois qu’une application demande les acc`es root ainsi que busybox, un ´equivalent plus complet de toolbox. Dans cet environnement, nous ex´ecutons toute application dont nous souhaitons analyser le comportement. Ce comportement est la propagation des donn´ees de l’application dans le syst`eme et est obtenu grˆace au suivi de flux d’information effectu´e par AndroBlare. Pour chaque application `a analyser, nous r´ep´etons le processus suivant. Nous installons l’application sur le t´el´ephone puis marquons son fichier apk avec un identifiant unique. Nous consid´erons que le fichier apk est la source des donn´ees appartenant `a l’application car il contient `a la fois son code et les ressources qu’elle utilise telles que les images. Nous ex´ecutons ensuite l’application et observons avec AndroBlare comment les donn´ees de l’application se propagent dans le syst`eme. A partir des flux observ´es, nous pouvons effectuer ` deux types d’action : construire une repr´esentation compacte et humainement compr´ehensible des flux observ´es (chapitre 4) ou d´etecter l’ex´ecution d’instance de malware (chapitre 5). Nous laissons les tags des autres conteneurs d’information `a leur valeur par d´efaut, ensemble vide, sauf pour les fichiers servicemanager et surfaceflinger dans /system/bin. A l’exception de ces deux fichiers, les autre conteneurs ne ` contiennent donc aucune information sensible du point de vue d’AndroBlare et n’ont aucune politique de flux d’information. Quant aux deux fichiers, nous leur assignons l’itag t0u pour signifier que les processus les ex´ecutant sont `a ignorer pendant le suivi de flux d’information. L’identifiant 0 n’est pas utilit´e dans le mod`ele de Blare pour identifier une information `a surveiller. Dans l’impl´ementation, nous nous servons de cette valeur pour indiquer `a Blare quand ignorer des flux d’information. Le but est d’´eviter une trop grande surapproximation des flux observ´es par AndroBlare. Les applications servicemanager et surfaceflinger sont deux processus cl´es du syst`eme Android. Le premier est un service d’annuaire r´epertoriant tous les autres services du syst`eme. Les applications souhaitant utiliser ces services doivent demander au servicemanager leur r´ef´erence avant de pouvoir les utiliser. Le second est en charge de dessiner sur86 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION l’´ecran toute interface graphique. Les applications sont uniquement conscients de ce qu’ils veulent afficher `a l’´ecran. Elles le transmettent `a surfaceflinger qui lui composera les affichages des diff´erentes applications et affichera le rendu final sur l’´ecran de l’appareil.3.5. ANDROBLARE : ANALYSE D’APPLICATIONS ANDROID 87 Android Kernel User space BLARE Analyzed application Information container 1 ... Information container n Analysed application apk file Blare log Parser Malware detection Trusted containers surfaceflinger servicemanager Figure 3.9 – AndroBlare : environnement d’analyse d’application Android88 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION R´esum´e Dans ce chapitre, nous avons pr´esent´e Blare un syst`eme de d´etection d’intrusion param´etr´e par une politique de flux d’information, le mod`ele sur lequel il est bas´e et le processus de portage de Blare sous Android (AndroBlare). AndroBlare utilise le mˆeme mod`ele th´eorique que Blare mais diff`ere de ce dernier au niveau de l’impl´ementation. Lors du portage de Blare sous Android, nous avons ajout´e la prise en compte de deux types de flux d’information : flux d’information via le Binder et l’interpr´etation du code des applications Android par la machine virtuelle Dalvik. Les applications Android n’utilisent pas les m´ecanismes de communication fournis par le noyau Linux pour communiquer entre elles. A la place, elles utilisent diff´erents m´ecanismes fournis par le frame- ` work Java qui reposent tous sur le Binder. Afin de suivre les flux d’information entre les applications, nous avons pris en compte ce m´ecanisme de communication dans AndroBlare. Sa prise en compte a consist´e `a ajouter deux nouveaux hooks `a LSM et `a d´efinir dans le code de KBlare les fonctions correspondant `a ces hooks. Le deuxi`eme type de flux d’information pris en compte dans AndroBlare concerne l’ex´ecution des applications et plus pr´ecis´ement l’interpr´etation de leur code par la machine virtuelle Dalvik. Les applications Android ne sont pas des applications natives et leur ex´ecution ´etait donc invisible `a Blare. Lorsqu’une application est ex´ecut´ee, son code est en r´ealit´e interpr´et´ee par la machine virtuelle Dalvik. Le probl`eme pos´e par cette interpr´etation du code est que l’ex´ecution ´etait invisible et donc KBlare ne pouvait mettre `a jour correctement les tags des processus ex´ecutant du code sensible. Aucun processus n’´etait marqu´e comme ex´ecutant du code et aucune politique ne pouvait ˆetre appliqu´ee par application. Afin de permette `a KBlare d’observer l’ex´ecution d’une application Android, nous avons ainsi ajout´e un m´ecanisme de coop´eration entre la machine virtuelle Dalvik et KBlare. Cette coop´eration consiste `a notifier KBlare via les sockets Netlink de l’ex´ecution d’une application par la machine virtuelle. Lors de la pr´esentation du mod`ele de Blare, nous avons ´egalement expliqu´e comment nous avons d´efini manuellement une politique de flux d’information pour le syst`eme Android. La politique identifie 150 informations `a prot´eger et 186 conteneurs d’information pouvant acc´eder `a ces informations ou les stocker. Cette politique a fait l’objet d’une publication `a ICC 2012 [16].Chapitre 4 Graphes de flux syst`eme Pour chaque flux d’information observ´e qui implique une donn´ee sensible, Blare ajoute une entr´ee d´ecrivant le flux dans un journal. Au fur et `a mesure que le syst`eme s’ex´ecute, le taille du journal augmente et peut devenir rapidement difficile `a analyser pour un ˆetre humain. Quelques minutes d’ex´ecution du syst`eme peut suffire pour avoir des milliers d’entr´ees dans le journal de Blare. Nous proposons donc dans ce chapitre une structure appel´ee System Flow Graph pour repr´esenter les flux observ´es de mani`ere plus compacte et plus compr´ehensible. 4.1 Graphe de flux syst`eme Un graphe de flux syst`eme, que nous abr´egeons SFG (System Flow Graph) dans le reste du document, est un multigraphe orient´e G “ pV, Eq o`u les nœuds repr´esentent des conteneurs d’information et les arcs des flux d’information entre les conteneurs. Un nœud v P V a trois attributs v.type, v.name et v.id qui repr´esentent respectivement le type du conteneur (fichier, processus et socket) correspondant au nœud, son nom et son identifiant du conteneur dans le syst`eme. Selon le type du conteneur, le nom du nœud est soit le chemin complet du fichier, le nom du processus concat´en´e `a celui du thread ou l’adresse IP associ´ee `a la socket. L’identifiant est le num´ero d’i-node pour les fichiers et le PID pour les processus. Un arc e P E a deux attributs e.timestamp et e.flow qui correspondent respectivement `a la liste des moments auxquels le flux a ´et´e observ´e et les identifiants des informations impliqu´ees dans le flux. Un arc repr´esente un flux d’information unique du conteneur repr´esent´e par sa source vers le conteneur repr´esent´e par sa destination. Le flux peut ˆetre observ´e plusieurs fois et inclut `a chaque observation les mˆemes informations sensibles, i.e les identifiants des informations qui se propagent sont les mˆemes `a chaque observation. Un SFG est un multigraphe car il peut contenir des arcs parall`eles. Des arcs 8990 CHAPITRE 4. GRAPHES DE FLUX SYSTEME ` [1] file blob 18 > process cat 19 > {1, 2} [2] process woman 20 > file blob 18 {3} [3] process woman 20 > file blob 18 {3} [4] file blob 18 > process cat 19 > {1, 2, 3} Figure 4.1 – Exemple de flux d’information causant l’apparition d’arcs parall`eles dans les SFG �������� ������ ����������� ������������� �������� ����������� Figure 4.2 – Exemple de SFG avec des arcs parall`eles parall`eles sont des arcs reliant les mˆeme nœuds. Un SFG a deux arcs parall`eles lorsque Blare a observ´e deux flux d’information ayant la mˆeme source et la mˆeme destination mais n’impliquant pas les mˆemes informations sensibles. La figure 4.1 d´ecrit des flux d’information causant la cr´eation d’arcs parall`eles dans les SFG. La premi`ere et derni`ere entr´ees d´ecrivent des flux ayant la mˆeme source et la mˆeme destination : de blob `a cat. Cependant, le contenu de blob a ´et´e modifi´e par le deuxi`eme et troisi`eme flux observ´es par Blare et ainsi le dernier flux implique une information en plus par rapport `a la premi`ere. Ces deux flux ne peuvent donc ˆetre consid´er´es comme un flux unique et sont repr´esent´es avec deux arcs. Le deuxi`eme et le troisi`eme flux impliquent les mˆemes informations sensibles et repr´esentent donc un flux d’information unique. Ils sont repr´esent´es par un unique arc. Graphe de flux syst`eme vs. graphe de d´ependance Dans [66], Samuel T. King et Peter M. Chen utilisent un graphe de d´ependance pour analyser les intrusions dans un syst`eme. Un graphe de d´ependance d´ecrit sous la forme d’un graphe les flux d’information entre les objets du syst`eme. Les nœuds sont les objets du syst`eme et un arc entre deux nœuds signifie qu’il y a eu un flux d’information entre les objets repr´esent´es par les nœuds source et destination de l’arc. Lorsqu’une intrusion a ´et´e d´etect´ee sur un objet du syst`eme, ils construisent le graphe de d´ependance et l’analysent afin d’avoir un d´ebut de diagnostic de l’intrusion. Le graphe de d´ependance est construit `a partir des flux d’information qui ont eu lieu jusqu’`a la d´etection de l’intrusion et sa construction est similaire `a celle d’un SFG. Si un SFG et un graphe de d´ependance d´ecrivent tous les deux des flux4.1. GRAPHE DE FLUX SYSTEME ` 91 d’information entre les objets du syst`eme, le SFG apporte cependant plus de pr´ecision car il est plus centr´e sur les informations que ne l’est un graphe de d´ependance. Un graphe de d´ependance prend en compte tout flux d’information s’op´erant dans le syst`eme et ne fait aucune distinction entre les informations qui se propagent. Par contre, un SFG lui ne prendra en compte que les flux d’information impliquant les donn´ees `a surveiller dans le syst`eme ce qui permet de mieux filtrer les flux d’information `a analyser lors d’une intrusion et raccourcir la dur´ee de l’analyse. Nous d´emontrons ce gain en repr´esentant la suite d’´ev`enement suivante avec un SFG et un graphe de d´ependance pour analyser une intrusion. Soient un processus server ex´ecutant une application traitant des donn´ees `a la demande d’applications clientes et f ilex un fichier dont l’acc`es est limit´e `a server et dont l’int´egrit´e doit ˆetre pr´eserv´ee. Sur le mˆeme syst`eme tournent n processus b´enins ex´ecutant diff´erents clients de server. A chaque requˆete cliente ` que server re¸coit, server se duplique et attribue le traitement de la requˆete au processus fils r´esultant de la duplication. Un autre processus attacker ex´ecute ´egalement une application cliente de server sur le syst`eme mais contrairement aux autres clients, il s’agit d’un processus malveillant dont le but de corrompre le contenu de f ilex. Pour corrompre le contenu de f ilex, il envoie une requˆete malicieuse `a server qui lors de son traitement va forcer le processus fils de server `a corrompre f ilex. Nous supposons que la d´etection ait lieu au moment de la corruption et que l’attaque soit men´ee seulement apr`es que les n processus aient chacun envoy´e au moins une requˆete au serveur. Cette derni`ere supposition permet d’avoir le pire des cas dans lors de l’analyse car tous les clients sont d’´eventuels suspects. En supposant que ces ´ev`enements se soient pass´es dans l’environnement d’analyse utilis´ee dans [66], nous construisons le graphe de d´ependance illustr´e dans la figure 4.3.a. En analysant ce graphe, le seul diagnostic que nous d´eduisons est que l’un des processus clients a pu influencer le serveur `a modifier le contenu de f ilex. Tous les processus clients sont de potentiels suspects car ils ont tous envoy´es des donn´ees au serveur avant que l’attaque ne soit d´etect´ee. Si nous supposons cette fois que les mˆeme ´ev`enements se soient produits dans un environnement (Andro)Blare et que pour chaque client un identifiant unique est associ´e aux donn´ees qu’il envoie alors nous aurions un SFG illustr´e dans la figure 4.3.b. Nous supposons que l’identifiant x est associ´e aux donn´ees provenant de l’application malveillante. En analysant le SFG, nous d´eduisons que f ilex a ´et´e contamin´e avec des donn´ees identifi´ees par x. En filtrant le SFG pour ne garder que les arcs impliquant les donn´ees identifi´ees par x, nous obtenons la partie en gras du SFG qui indique clairement que le processus attacker est `a l’origine de l’attaque.92 CHAPITRE 4. GRAPHES DE FLUX SYSTEME ` proc 1 server ... proc n attacker child 1 ... child n child filex proc 1 server {1} ... proc n {n} attacker {x} child 1 {1} ... child n {n} child {x} filex {x} (a) (b) Figure 4.3 – Graphe de d´ependance et SFG repr´esentant les flux d’information ayant pr´ec´ed´e la corruption d’un fichier f ilex 4.2 Quelques op´erations utiles sur les SFG Dans les chapitres suivants, nous effectuerons certaines op´erations sur les SFG. Nous pr´esentons dans cette section ces op´erations qui nous serviront par la suite. 4.2.1 Intersection de deux SFG : g1 [ g2 L’intersection de deux SFG est le SFG dont les arcs sont l’ensemble des arcs en commun aux deux SFG. La notion d’arcs en commun de deux SFG d´esigne le fait qu’une partie des arcs des deux SFG sont les mˆemes. Nous consid´erons qu’un arc e1 P g1 est le mˆeme qu’un arc e2 P g2 si : — les deux arcs impliquent les mˆeme informations dans le flux d´ecrit par chacun des arcs ; — leurs nœuds de d´epart respectifs repr´esentent le mˆeme conteneur d’information ; — leurs nœuds d’arriv´ee respectifs repr´esentent le mˆeme conteneur d’information. Deux nœuds repr´esentant le mˆeme conteneur d’information doivent avoir le mˆeme type et le mˆeme nom. Nous ne prenons pas en compte l’identifiant syst`eme des conteneurs d’information car ils sont sp´ecifiques `a chaque syst`eme ou `a une ex´ecution. Un processus n’existe tout au plus que le temps d’ex´ecution du syst`eme. Son identifiant est donc li´e `a cette ex´ecution. L’identifiant d’un fichier est li´e au syst`eme o`u il se trouve. Il est g´en´er´e automatiquement `a la cr´eation du fichier. Un mˆeme fichier sur deux syst`emes diff´erents a donc deux identifiants diff´erents.4.3. CONSTRUCTION D’UN GRAPHE DE FLUX SYSTEME ` 93 4.2.2 Inclusion d’un SFG dans un autre : g1 Ď g2 Soient deux SFG g1 et g2. Nous consid´erons que g1 est inclus dans g2 si tous les arcs de g1 sont des arcs en commun avec g2. 4.2.3 Nœuds et arcs d’un SFG Nous d´efinissions ´egalement les fonctions node et edges comme ´etant les fonctions retournant respectivement l’ensemble des nœuds et des arcs d’un SFG. 4.3 Construction d’un graphe de flux syst`eme Pour obtenir la repr´esentation compacte du journal de Blare, nous avons d´evelopp´e un outil qui prend en entr´ee un journal de Blare et donne en sortie la repr´esentation sous forme de SFG. L’algorithme 1 d´ecrit la transformation du journal en SFG. Nous d´efinissons la fonction to edge comme ´etant une fonction qui calcule l’arc correspondant `a une entr´ee d’un journal de Blare et utilisons l’op´eration  pour exprimer le fait que deux arcs repr´esentent le mˆeme flux d’information unique. Deux arcs repr´esentent le mˆeme flux d’information unique si leurs nœuds sources repr´esentent le mˆeme conteneur d’information ainsi que leurs nœud de destination. Durant la construction d’un SFG, nous consid´erons que deux nœuds v1 et v2 repr´esentent le mˆeme conteneur d’information si l’un des cas suivants est vrai : — v1 et v2 sont des fichiers, v1.id est ´egal `a v2.id et les fichiers correspondant sont sur la mˆeme partition ; — v1 et v2 sont des processus et v1.id est ´egal `a v2.id ; — v1 et v2 sont des sockets qui sont li´ees `a la mˆeme adresse IP. Nous utilisons l’identifiant au lieu des noms dans le cas des processus et des fichiers car les noms peuvent changer durant l’ex´ecution du syst`eme. Les identifiants identifient de mani`ere unique chaque objet et ne changent pas durant l’ex´ecution du syst`eme. Utiliser le nom aurait ainsi cr´e´e une confusion pour l’analyste car il ne pourrait plus retracer correctement la propagation des flux dans le syst`eme. Par exemple, durant l’installation d’une application, un fichier avec un nom al´eatoire est cr´e´e dans /data/dalvik-cache. Ce fichier contient la version optimis´ee du code de l’application `a installer et est renomm´e en se basant sur le nom de l’application `a la fin de l’installation. Si le conteneur est impliqu´e dans un flux d’information avant et apr`es son renommage, nous aurions un seul et mˆeme nœud pour le repr´esenter avec les identifiants alors que nous aurions deux nœuds diff´erents en utilisant les noms. Pour chaque entr´ee du journal de Blare, nous v´erifions si il existe un arc e1 correspondant au flux d´ecrit par l’entr´ee. Si c’est le cas, alors nous ajoutons le timestamp de l’entr´ee courante `a la liste des timestamps de e1. Si ce n’est pas le cas, nous ajoutons l’arc correspondant `a l’entr´ee courante au SFG. L’ajout d’un nouvel arc implique ´egalement l’ajout de ses nœuds s’ils n’existaient pas dans le SFG ; c’est-`a-dire qu’aucun des nœuds du SFG n’´etait ´egal aux nœuds94 CHAPITRE 4. GRAPHES DE FLUX SYSTEME ` source et destination du nouvel arc. La construction s’arrˆete quand il n’y a plus d’entr´ee `a traiter et l’algorithme retourne le SFG. Algorithme 1 : Construction d’un SFG `a partir des entr´ees d’un journal de Blare Input : Journal de Blare Output : SFG correspondant aux flux d´ecrits dans le journal donn´e en entr´ee begin g Ð empty SFG; forall the entry ent in Blare log do e0 Ð to edgepentq; found Ð F alse; forall the e1 P g do if e0  e1 then e1.timestamp Ð e1.timestamp Y e0.timestamp; found Ð T rue; break; if found then Add e0 to g; return g; Compacit´e du SFG Nous avons avanc´e au d´ebut de ce chapitre que le premier atout du SFG ´etait de repr´esenter de mani`ere plus compacte les flux d’information observ´es par Blare. Cette compacit´e a pour cons´equence de faciliter l’analyse des flux observ´es afin de comprendre ce qui se passe dans le syst`eme. Durant la th`ese nous avons analys´e plus d’une centaine d’application dont certaines ´etaient malicieuses et d’autres non. L’analyse de chacune d’entre elles a dur´e entre 2 `a 5 minutes selon les applications et le journal de Blare obtenu `a la fin de l’analyse contenait quelques milliers d’entr´ee, c’est-`a-dire que Blare a observ´e des milliers de flux d’information et chacun des flux observ´es par une entr´ee dans le journal. A titre ` d’exemple, l’analyse de 65 applications provenant de Google Play a produit en moyenne plus de 130000 entr´ees dans le journal de Blare alors que les SFG produits `a partir de chaque journal ont en moyenne une centaine d’arcs. La raison de ce gain en compacit´e est que certains flux sont observ´es plusieurs fois durant l’ex´ecution du syst`eme. Les ´echanges entre une application et le processus system server sont par exemple r´ep´et´es plusieurs fois car ce processus h´eberge les applications services du syst`eme fournies aux autres applications. Un autre exemple de ces flux r´ep´et´es est la lecture ou l’´ecriture de donn´ees volumineuses dans un fichier.4.4. SFG : PROFIL COMPORTEMENTAL D’UNE APPLICATION 95 4.4 Graphe de flux syst`eme : profil comportemental d’une application Un SFG repr´esente de mani`ere compacte les flux d’information observ´es par (Andro)Blare. Dans cette th`ese, nous proposons d’utiliser le SFG en tant que profil d’une application. Plus pr´ecis´ement, nous proposons d’utiliser le SFG pour d´ecrire comment une information provenant d’une application se propage dans le syst`eme entier. Afin de construire le SFG, nous analysons avec AndroBlare comment l’information provenant d’une application sous surveillance se propage dans le syst`eme. Nous installons l’application, assignons un nouvel identifiant i `a ses donn´ees, marquons son apk avec un itag ´egal `a tiu, l’ex´ecutons et analysons avec Blare comment ses donn´ees se propagent dans le syst`eme. Nous assignons un nouvel identifiant aux donn´ees de l’application afin d’identifier les flux d’information impliquant les donn´ees de l’application. L’apk contient toutes les ressources d’une application. Nous le consid´erons donc comme l’origine des donn´ees d’une application et le marquons avec l’itag tiu. A chaque fois que ` Blare observe un flux d’information impliquant une donn´ee identifi´ee par i il rajoute une entr´ee d´ecrivant le flux observ´e. En utilisant l’algorithme 1, nous construisons ensuite le SFG correspondant aux flux observ´es. Le SFG r´esultant peut ensuite ˆetre analys´e afin de comprendre les actions d’une application. Dans ce qui suit, nous proposons d’analyser un ´echantillon d’un malware Android. 4.4.1 Analyse de DroidKungFu1 avec AndroBlare DroidKungFu1 [61] est un malware Android d´ecouvert en 2011 sur les plateformes de t´el´echargement alternatives `a Google Play. Il m`ene deux types d’attaque : le vol des donn´ees li´ees au t´el´ephone (IMEI, num´ero du t´el´ephone et version du syst`eme d’exploitation) et l’ajout d’application sur le t´el´ephone. Le vol des donn´ees est une attaque basique car l’application demande `a l’installation les permissions requises pour acc´eder aux donn´ees et communiquer sur le r´eseau. Une fois install´ee, l’application collecte les donn´ees sensibles et les envoie dans une requˆete HTTP vers un serveur distant. En revanche, l’ajout d’application est plus complexe et les permissions demand´ees ne laissent en rien pr´esager l’installation d’une nouvelle application. Pour installer d’autres applications, le malware ´el`eve ses privil`eges en exploitant une vuln´erabilit´e du syst`eme Android [31] ou en utilisant le binaire su 1 . L’´echantillon que nous utilisons 2 provient de la collection Contagio [82] et a ´et´e propos´e comme un client VoIP sur des plateformes alternatives `a Google Play. La figure 4.4 est une capture d’´ecran des permissions demand´ees `a l’utilisateur par l’´echantillon. Parmi les acc`es demand´es, nous remarquons l’acc`es `a l’identit´e du t´el´ephone (ex : IMEI et num´ero de t´el´ephone) et l’acc`es au r´eseau. Nous analysons l’´echantillon avec AndroBlare comme d´ecrit en section 3.5. Nous l’installons sur un t´el´ephone, marquons son apk, l’ex´ecutons et analysons avec 1. switch user 2. Empreinte MD5 : 39d140511c18ebf7384a36113d48463d96 CHAPITRE 4. GRAPHES DE FLUX SYSTEME ` Figure 4.4 – Permissions demand´ees par un ´echantillons de DroidKungFu AndroBlare comment ses informations se propagent dans le syst`eme. Le code malveillant dans l’application est automatiquement ex´ecut´e d`es que nous lan¸cons l’application. Super User notifie que l’application a obtenu les droits root et au bout de quelques secondes, nous remarquons une nouvelle application, Google SSearch, dans le menu principal du t´el´ephone (figure 4.5). Nous arrˆetons l’analyse et cr´eons `a partir du journal de Blare le SFG de l’application. Le nombre d’entr´ees cr´e´ees dans le journal est de 3563 et `a partir de ces entr´ees nous construisons le SFG que nous analysons dans la section suivante. 4.4.2 Analyse du SFG de DroidKungFu1 La figure 4.6 illustre un extrait du SFG de l’´echantillon 39d140511c18ebf7384a36113d48463d. Le SFG entier est plus grand (106 arcs et 76 nœuds) mais la figure montre la partie la plus importante du point de vue de l’attaque (partie en gras). Le SFG a deux types de nœuds. Les ellipses repr´esentent des processus tandis que les boˆıtes repr´esentent des fichiers. Les arcs repr´esentent toujours des labels mais pour des raisons esth´etiques, nous nous sommes limit´es `a afficher le nombre de fois que les flux correspondants aux arcs ont ´et´e observ´es4.4. SFG : PROFIL COMPORTEMENTAL D’UNE APPLICATION 97 Figure 4.5 – Liste des applications dans le menu du t´el´ephone apr`es l’installation d’une nouvelle application par un ´echantillon de DroidKungFu98 CHAPITRE 4. GRAPHES DE FLUX SYSTEME ` /data/app/com.aijiaoyou.android.sipphone-1.apk system_server 1 - 98081668 ndroid.sipphone 82 - 98349271 11 - 98341815 /data/system/packages.xml 1 - 313591933 .google.ssearch 7 - 319549869 82 - 98347483 /data/data/com.aijiaoyou.android.sipphone/gjsvro 2 - 100112038 /data/data/com.aijiaoyou.android.sipphone/legacy 1 - 312461265 1 - 100158896 gjsvro 3 - 121963546 /proc/sys/kernel/hotplug 1 - 121959054 /system/bin/gjsvr 2 - 121963729 /system/app/com.google.ssearch.apk 11 - 312503997 2 - 312993777 dexopt 1 - 313427486 2 - 319553901 cat 11 - 312938978 /data/dalvik-cache/system@app@com.google.ssearch.apk@classes.dex 2 - 313429554 1 - 313573503 1 - 319567573 7 - 319548445 12 - 312503806 12 - 312938674 Figure 4.6 – Extrait du SFG d’un ´echantillon de DroidKungFu4.4. SFG : PROFIL COMPORTEMENTAL D’UNE APPLICATION 99 ainsi que le timestamp de la premi`ere observation. L’application que nous avons analys´e est le processus ndroid.sipphone. En analysant le SFG, nous pouvons d´eduire que deux applications ont ´et´e install´ees sur le t´el´ephone. Lorsque l’´echantillon s’ex´ecute, il cr´ee deux fichiers /data/data/com.aijaoyou.sipphone/gjsvro et /data/data/com.aijaoyou.sipphone/legacy. A par- ` tir du contenu de ces fichiers, deux processus, gjsvro et cat, cr´eent deux nouveaux fichiers dans la partition system : /system/bin/gjsvro et /system/app/com.google.search.apk. Cela indique l’installation d’une application native, gjsvro, et d’une application Android, com.google.search.apk. Ces deux fichiers n’existent pas par d´efaut sous Android, ce qui laisse supposer qu’ils ont ´et´e cr´e´es par l’´echatillon du malware que nous analysons. Les flux qui suivent renforcent cette hypoth`ese car le contenu du fichier apk se propage vers le processus system server qui lui le propage dans le fichier packages.xml. Le processus system server ex´ecute divers services du syst`eme dont celui en charge de l’installation des nouvelles applications, Package Manager. Package Manager observe la cr´eation de nouveaux fichiers dans le r´epertoire /system/app qui stocke les applications syst`eme. Si un fichier est cr´e´e dans ce r´epertoire, il lance l’installation du fichier. Le fichier packages.xml contient la liste des applications install´ees sur le t´el´ephone. De plus, le contenu du fichier apk est ´egalement lu par le processus dexopt qui est en charge d’extraire la version optimis´ee du code d’une application `a partir de son apk. Un nouveau processus, google.search acc`ede ensuite `a cette version optimis´ee ainsi qu’`a l’apk cr´e´e par le malware ce qui indique l’ex´ecution d’une nouvelle application. Pour confirmer l’installation, nous analysons le fichier packages.xml. En calculant la diff´erence de son contenu avant et apr`es l’analyse de l’´echantillon, nous remarquons une entr´ee d´ecrivant une nouvelle application com.google.ssearch (listing 4.1). L’entr´ee indique que le code de l’application correspond au fichier com.google.ssearch.apk dans la partition system. Elle indique aussi l’UID associ´e `a l’application : 10059. A l’installation d’une application, le syst`eme lui ` associe un nouvel UID dont la valeur est le dernier UID associ´e `a une application incr´ement´e de 1. L’UID associ´e `a l’´echantillon que nous avons analys´e est 10058. Cela signifie donc que l’application com.google.ssearch a ´et´e install´ee apr`es l’´echantillon que nous avons analys´e. 481 484 485 486 487 488 Listing 4.1 – Entr´ee dans le fichier packages.xml ajout´ee suite `a l’installation d’une nouvelle application par un ´echantillon de DroidKungFu100 CHAPITRE 4. GRAPHES DE FLUX SYSTEME ` Avant de cr´eer les fichiers dans la partition system, le processus gjsvro ´ecrit dans un fichier hotplug. Ce fichier est une entr´ee du procfs, un syst`eme de fichier servant d’interface pour acc´eder `a des informations sur les processus et d’autres ´el´ements du syst`eme tels que le noyau. Si l’´ecriture de donn´ee dans le fichier hotplug ne signifie pas forc´ement une attaque, elle est cependant inhabituelle et correspond `a l’exploitation de la vuln´erabilit´e pour obtenir les droits root sur le syst`eme [31]. Un SFG est un multigraphe orient´e qui repr´esente de mani`ere compacte les flux d’information observ´es par AndroBlare. Comme nous l’avons montr´e `a la fin de la section 4.3, une centaine de milliers d’entr´ee dans le journal d’AndroBlare se r´eduit en un graphe avec un moyenne une centaine d’arcs. Grˆace `a sa compacit´e, cette structure facilite l’analyse des flux observ´es dans le syst`eme afin de comprendre le comportement d’une application. Dans le cas d’analyse de malware, cette fonctionnalit´e s’av`ere int´eressant pour ´etablir un d´ebut de diagnostic d’une attaque. Pour illustrer cela, nous avons analys´e avec AndroBlare un ´echantillon du malware DroidKungFu1 et construit le SFG correspondant aux flux observ´es durant l’analyse. Nous avons d´eduit `a partir du SFG que l’´echantillon analys´e installait deux applications dans le syst`eme : une native et une sous forme d’apk. Ces deux applications sont install´ees dans la partition system, ce qui rend leur pr´esence persistante sur le t´el´ephone. Un utilisateur normal ne peut d´esinstaller une application dans la partition system sans les droits root or ils ne sont pas disponibles par d´efaut sur les t´el´ephones. Le SFG a ´egalement mis en ´evidence l’exploitation de la vuln´erabilit´e pour avoir les droits root (´ecriture de donn´ees sensibles dans le fichier hotplug). Revenons sur le travail effectu´e dans [16] et pr´esent´e en section 3.2. Le but de ce travail ´etait de d´efinir manuellement une politique de flux d’information pour le syst`eme Android. Sa r´ealisation a cependant mis en ´evidence la difficult´e d’une telle approche. L’un des pr´e-requis `a cette d´emarche est une connaissance approfondie du syst`eme. Or ce n’est pas souvent le cas pour les d´eveloppeurs d’application et d´efinir une politique de flux pour des applications cens´ees tourner dans un environnement AndroBlare pourrait s’av`erer difficile. Avec T. Saliou, nous avons ainsi propos´e dans [20] une approche semi-automatique pour assister un d´eveloppeur dans la cr´eation de la politique d’une application. 4.5 Cr´eation d’une politique de flux d’information `a partir d’un System Flow Graph La difficult´e dans la d´efinition d’une politique est de connaˆıtre tous les conteneurs l´egaux des informations `a surveiller. Lors de la d´efinition de la politique d’une application, il s’agit donc d’identifier tous les conteneurs pouvant acc´eder ou stocker les donn´ees de cette application. Pour les identifier, nous proposons4.5. POLITIQUE DE FLUX D’INFORMATION A PARTIR D’UN SFG ` 101 d’analyser les applications pour construire leur profil sous forme de SFG. A par- ` tir du SFG, nous d´eduisons ensuite les conteneurs l´egaux des donn´ees surveill´ees car le SFG d´ecrit o`u les informations surveill´ees se propagent dans le syst`eme. La construction de la politique se fait en deux ´etapes. Dans un premier temps, le d´eveloppeur analyse son application dans un environnement AndroBlare et construit le profil de son application comme d´ecrit en section 4.4. Le but de cette ´etape est d’obtenir dans le SFG tous les flux d’information possibles que l’application peut causer. Le d´eveloppeur ´etant celui qui connaˆıt le mieux son application, il est le mieux plac´e pour stimuler son application et couvrir ainsi toutes les fonctionnalit´es offertes par l’application. Une fois le SFG obtenu, nous calculons la politique de flux de l’application. L’algorithme 2 d´ecrit le processus de calcul. Les fonctions cont, ptag, xptag, inedges et bin retournent respectivement le conteneur d’information associ´e `a un nœud, le ptag d’un conteneur, son xptag, les arcs entrants d’un nœud et le fichier contenant l’application ex´ecut´ee par un processus. Pour chaque nœud du SFG, nous consid´erons que le conteneur d’information qu’il repr´esente est un conteneur l´egal de toutes les information sensibles impliqu´ees dans les arcs entrants du nœud. Nous consid´erons que toutes ces informations peuvent se m´elanger dans le conteneur. Par exemple, si deux arcs e0 et e1 sont les arcs entrants d’un nœud n alors nous consid´erons que le conteneur repr´esent´e par n est un conteneur l´egal des informations impliqu´ees dans les flux d´ecrits par les deux arcs. Algorithme 2 : Calcul d’une politique de flux d’information Blare `a partir d’un SFG Input : Un SFG G Output : Une politique de flux d’information begin ptag (socket) Ð H; foreach n P nodes (G) do ids Ð H ; foreach e P inedges (n) do ids Ð ids Y e.flow ; switch type (n) do case file ptag (cont (n)) Ð tidsu; break; case process xptag (bin (cont (n))) Ð tidsu; break; case socket ptag (socket) Ð ptag (socket) Y tidsu; break;102 CHAPITRE 4. GRAPHES DE FLUX SYSTEME ` En utilisant cette approche, nous avons construit la politique de trois applications issues de Google Play : Angry Birds, Finger Scanner et Knife Game. La politique produite est ´ecrite en BSPL [57] et le listing 4.2 est un extrait de l’une des politiques BSPL produites. Ecrire la politique en BSPL permet de ´ la composer avec d’autres politiques, notamment celle du syst`eme sur lequel l’application est install´ee. La politique liste les conteneurs d’information pris en compte par la politique, les donn´ees sensibles `a surveiller et pour chaque donn´ee sensible la liste des conteneurs l´egaux ainsi que les informations avec lesquelles elles peuvent se m´elanger dans le conteneur. Evaluation des politiques produites ´ Nous avons men´e deux types d’exp´erience afin d’´evaluer les politiques de flux produites `a partir de notre approche. La premi`ere exp´erience consiste `a valider la prise en compte des flux que l’application engendre durant son ex´ecution par sa politique de flux. Nous nous assurons qu’aucune alerte n’est lev´ee par AndroBlare lorsque nous ex´ecutons l’application et appliquons sa politique. La deuxi`eme exp´erience consiste `a valider la capacit´e de d´etection de la politique en cas d’intrusion dans le syst`eme. Plus pr´ecis´ement, nous v´erifions que la politique de s´ecurit´e permet la d´etection des d´eviations par rapport au comportement d’origine de l’application. Nous consid´erons ici le cas des applications malveillantes qui sont `a l’origine des applications b´enignes mais auxquelles du code malveillant a ´et´e rajout´e. Ce mode d’infection est le plus utilis´ee par les auteurs de malware selon l’analyse dans [113]. Dans les deux types d’exp´eriences, nous appliquons la proc´edure suivante. Nous installons l’application, appliquons sa politique et l’utilisons comme un utilisateur normal l’utiliserait. En parall`ele, nous v´erifions avec AndroBlare si les flux caus´es par l’application violent la politique de flux du mise en œuvre. Lors de la premi`ere exp´erience, nous utilisons la version de l’application ayant servi lors de la cr´eation de la politique et v´erifions qu’aucune alerte n’est lev´ee lors de l’utilisation de l’application. Si aucune alerte n’est lev´ee, cela signifie que la politique couvre tous les flux que l’application cause durant son ex´ecution. Lors de la deuxi`eme exp´erience nous utilisons des versions infect´ees des applications utilis´ees dans l’exp´erience pr´ec´edente. Ces versions infect´ees sont des r´eels ´echantillons de malware provenant de la collection Contagio [82]. Les versions infect´ees d’Andry Birds, Finger Scanner et Knife Game sont respectivement des ´echantillons d’une variante de LeNa [104], DroidKungFu1 [61] et Bad News [91]. Chacun de ces malwares essaient d’installer des applications sur le t´el´ephone soit en usant des privil`eges demand´ees `a l’installation soit en exploitant des vuln´erabilit´es dans le syst`eme. Le but de la deuxi`eme exp´erience est donc de d´etecter ces comportements. Le tableau 4.1 liste le nombre d’alertes lev´ees lors de l’´evaluation des politiques des trois applications. Lors de la premi`ere exp´erience, AndroBlare n’a l´ev´e aucune alerte pour les 3 applications. Les politiques respectives des trois applications couvrent donc tous les flux qu’elles engendrent durant son ex´ecution. Lors de la deuxi`eme exp´erience, AndroBlare a lev´e des alertes pour chacune4.5. POLITIQUE DE FLUX D’INFORMATION A PARTIR D’UN SFG ` 103 des versions infect´ees des applications utilis´ees durant la premi`ere exp´erience. Les alertes lev´ees ´etant nombreuses, nous ne les mettrons pas dans le pr´esent document mais la figure 4.7 est un extrait de ces alertes. Elle liste les alertes lev´ees par AndroBlare lors de l’analyse de la version infect´ee de Finger Scanner. La version infect´ee d’Angry Birds est un ´echantillon de LeNa. Les analyses sur LeNa indiquent que le malware exploitent une vuln´erabilit´e du syst`eme afin d’obtenir les privil`eges root puis installer une nouvelle application. Lors de l’analyse de l’´echantillon, AndroBlare a lev´e des alertes indiquant l’acc`es en lecture et ´ecriture `a des fichiers dans le r´epertoire de l’application par d’autres applications : logo et logcat. Logo est une application binaire incluse par l’auteur du malware dans l’application. Logcat est une application qui permet de lire le contenu du journal du syst`eme. Ces deux applications lisent et ´ecrivent dans les fichiers logo, crashlog, flag, exec et .e1240987052d situ´es dans le r´epertoire de l’application analys´ee. Si ces acc`es n’indiquent pas forc´ement une intrusion dans le syst`eme, elles correspondent cependant `a la premi`ere ´etape de l’attaque men´ee par le malware, l’exploitation de la vuln´erabilit´e sur le syst`eme. L’analyse effectu´ee dans [95] indique que l’application installe ou remplace les binaires situ´ees dans /system/bin. AndroBlare n’a lev´e aucune alerte indiquant de tels comportements. Pour s’assurer qu’il ne s’agit pas de faux n´egatif, nous avons list´e le contenu du r´epertoire et v´erifi´e si de nouveaux binaires ont ´et´e cr´e´es ou si le contenu des fichiers pr´esents ont ´et´e chang´e pendant l’analyse de l’application. Notre analyse a montr´e qu’aucun fichier n’a ´et´e cr´e´e ni modifi´e. La version infect´ee de Finger Scanner est un ´echantillon de DroidKungFu 1. Tout comme LeNa, DroidKungFu1 exploite une vuln´erabilit´e dans le syst`eme Android afin d’´elever ses privil`eges et installer deux applications sur le t´el´ephone : une native et une application Android. Lors de l’analyse de l’´echantillon de DroidKungFu 1, AndroBlare a lev´e des alertes indiquant l’´ecriture de donn´ees sensibles dans une entr´ee de procfs 3 , deux fichiers dans la partition system et la propagation des donn´ees sensibles vers le fichier contenant la liste des applications du t´el´ephone, l’application en charge d’une partie de l’installation des nouvelles applications sur le t´el´ephone et un nouveau processus dont le nom est une partie du nom d’un des nouveaux fichiers cr´e´es dans la partition system. Ces alertes sont list´ees dans la figure 4.7. Ces alertes correspondent `a l’exploitation de la vuln´erabilit´e par DroidKungFu 1 ainsi que l’ajoute de nouvelles applications dans le syst`eme. La premi`ere alerte correspond `a l’exploitation de la vuln´erabilit´e par le malware. Les alertes qui restent d´ecrivent l’ajout des deux nouvelles applications system ainsi que l’ex´ecution de l’une d’entre elles (com.google.ssearch.apk). La version infect´ee de Savage Knife Game est un ´echantillon de BadNews. BadNews est un malware dont le comportement est dict´e par un serveur de commande. En analysant le code de l’´echantillon avec Androguard [97], nous avons d´ecouvert que le malware peut recevoir X types de commande : installer une application, afficher une notification `a l’utilisateur, changer l’adresse des serveurs de commande, t´el´echarger des fichiers et ajouter des raccourcis 3. Syst`eme de fichier servant d’interface `a des donn´ees du syst`eme, y compris le noyau104 CHAPITRE 4. GRAPHES DE FLUX SYSTEME ` [POLICY_VIOLATION] process gjsvro:gjsvro 984 > file /proc/sys/kernel/ hotplug 4827 > itag[-3] [POLICY_VIOLATION] process gjsvro:gjsvro 984 > file /system/bin/gjsvr 16738 > itag[-3 3] [POLICY_VIOLATION] process gjsvro:gjsvro 984 > file /system/app/ com.google.ssearch.apk 8330 > itag[-3 3] [POLICY_VIOLATION] process cat:cat 990 > file /system/app/com.google. ssearch.apk 8330 > itag[3] [POLICY_VIOLATION] process gjsvro:gjsvro 984 > socket (127.0.0.1) 0 > itag[-3 3] [POLICY_VIOLATION] file /system/app/com.google.ssearch.apk 8330 > process dexopt:dexopt 991 > itag[3] [POLICY_VIOLATION] process dexopt:dexopt 991 > file /data/dalvik-cache/ system@app@com.google.ssearch.apk@classes.dex 24632 > itag[3] [POLICY_VIOLATION] file /data/dalvik-cache/system@app@com.google.ssearch.apk @classes.dex 24632 > process dexopt:dexopt 991 > itag[3] [POLICY_VIOLATION] process droid.gallery3d:droid.gallery3d 995 > file /data/data/ com.android.gallery3d/shared\_prefs/com.android .gallery3d\_preferences.xml 57603 > itag[3] [POLICY_VIOLATION] file /system/app/com.google.ssearch.apk 8330 > process .google.ssearch:.google.ssearch 1059 > itag[3] [POLICY_VIOLATION] file /data/dalvik-cache/system@app@com.google.ssearch.apk @classes.dex 24632 > process .google.ssearch:.google.ssearch 1059 > itag[3] Figure 4.7 – Extrait des alertes lev´ees par l’´echantillon de DroidKungFu1 lors de l’´evaluation de la politique de Finger Scaner Version originale Version infect´ee Angry Birds 0 15 Finger scanner 0 11 Knife game 0 209 Table 4.1 – Nombre d’alertes lev´ees par Blare lors de l’ex´ecution des versions originales et infect´ees de trois applications en appliquant une politique BSPL soit vers des pages web soit vers des fichiers sur le t´el´ephone. Lors de l’analyse de l’´echantillon, AndroBlare a lev´e 209 alertes. Une partie d’entre elles correspondent au t´el´echargement de deux applications, leur installation et leur ex´ecution sur le t´el´ephone. L’une des applications est pr´esent´ee comme ´etant Adobe Flash mais est en r´ealit´e un jeu et l’autre application est une version infect´ee du jeu Doodle Jump. L’autre partie des alertes d´ecrivent l’´echange de donn´ees sensibles du navigateur avec d’autres objets du syst`eme. Ces alertes sont dues au fait que l’´echantillon analys´e utilise le navigateur pour initier le t´el´echargement des applications. Pour cela, il ´emet un intent pour ouvrir les adresses web pointant vers les applications `a t´el´echarger. A partir ce moment, le ` navigateur se trouve ainsi marqu´e comme contenant une donn´ee sensible et tout ´echange qu’il aura avec les autres ´el´ements du syst`eme est vu par AndroBlare comme impliquant une donn´ee sensible.4.5. POLITIQUE DE FLUX D’INFORMATION A PARTIR D’UN SFG ` 105 1 2 3 4 5 12 13 16 19 22 25 26 ... 27 ... 28 29 30 31 32 40 41 43 44 ... 45 ... 46 47 48 49 Listing 4.2 – Extrait de la politique BSPL de l’application Finger Scanner106 CHAPITRE 4. GRAPHES DE FLUX SYSTEME ` R´esum´e Nous avons pr´esent´e dans ce chapitre une structure de donn´ees, SFG, repr´esentant sous la forme de multigraphe orient´e les flux d’information qu’AndroBlare d´etecte durant l’ex´ecution du syst`eme. Cette structure est le deuxi`eme apport de la th`ese et la deuxi`eme ´etape vers l’accomplissement de notre objectif principal qui est de classifier et d´etecter les malware Android. Dans l’exemple propos´e en section 4.4, nous avons obtenu un SFG contenant moins de 100 arcs `a partir de plus de 3000 flux observ´es. Grˆace `a sa compacit´e, le SFG permet de comprendre rapidement les ´ev`enements qui se passent dans le syst`eme. L’analyse du graphe obtenu `a partir des flux engendr´es par un ´echantillon de DroidKungFu 1 nous a ainsi permis d’identifier l’installation de deux applications par le malware. En plus d’utiliser cette structure comme profil d’une application, nous avons ´egalement montr´e qu’il ´etait possible de s’en servir pour cr´eer la politique Blare d’une application. Nous avons test´e cette approche sur trois applications populaires de Google Play et montr´e que les politiques produites capturaient bien les flux caus´ees par les applications durant leur ex´ecution et permettaient de d´etecter les d´eviations de comportement dues `a tout code malveillant introduit dans les applications. Le contenu de ce chapitre a fait l’objet de deux publications. La premi`ere a ´et´e publi´ee `a WISG13 [18] et pr´esente la structure SFG ainsi que la mani`ere dont elle peut ˆetre utilis´ee pour comprendre le comportement d’une application. La deuxi`eme publication a ´et´e publi´ee `a IAS13 [20] et ´etendue dans un article du journal [19]. Elle pr´esente la m´ethode de cr´eation de politique BSPL `a partir d’un SFG ainsi que son ´evaluation.Chapitre 5 Caract´erisation et d´etection de malware Android Nous avons pr´esent´e dans le chapitre pr´ec´edent une structure de donn´ee qui d´ecrit de mani`ere compacte comment les informations surveill´ees par AndroBlare se propagent dans le syst`eme et propos´e d’utiliser cette structure pour d´ecrire comment une application propage ses donn´ees dans le syst`eme. En analysant le graphe d’un ´echantillon de DroidKungFu 1, nous avons montr´e qu’une partie du graphe correspondait `a l’attaque effectu´ee par le malware. Selon l’analyse effectu´ee dans [113], plus de 86% des ´echantillons de malware Android sont des applications existantes auxquelles du code malveillant a ´et´e ajout´e. Cela signifie donc que les ´echantillons d’un mˆeme malware ont un comportement partiellement commun dˆu au code malveillant qui leur a ´et´e inject´e. Un ´echantillon d’un malware est une application consid´er´ee comme ´etant une ´echantillon de ce malware. Une partie des flux qu’ils causent devraient ainsi ˆetre les mˆemes. En supposant que l’attaque observ´ee dans le graphe de l’´echantillon de DroidKungFu 1 soit dˆu `a un code qui a ´et´e inject´e dans l’application d’origine et d’autres applications, peut-on ainsi retrouver ce sous-graphe dans le graphe des autres ´echantillons ? Nous avons g´en´eralis´e ce probl`eme et r´epondons dans ce chapitre aux deux questions suivantes. 1. Existe-t-il des sous-graphes communs aux SFG des applications malveillantes telles que cette partie commune corresponde au comportement introduit par le code malveillant dans ces applications ? 2. Si un tel sous graphe existe, permet-il de d´etecter d’autres ´echantillons du malware ? Afin de r´epondre `a ces questions, nous pr´esentons et ´evaluons dans ce chapitre une m´ethode pour calculer ce sous-graphe en commun et une m´ethode de d´etection utilisant les flux d’information et les sous-graphes en commun pour d´etecter l’ex´ecution d’´echantillon de malware. 107108 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´ 5.1 Caract´erisation de malware Android : classi- fication d’applications malveillantes Android Nous proposons de caract´eriser un malware avec le(s) sous-graphe(s) en commun aux SFG de ses ´echantillons qui d´ecrit son comportement malveillant. Afin d’extraire cette partie commune, nous calculons les arcs en commun aux SFG des ´echantillons de malware comme d´ecrit par l’algorithme 3. Le calcul effectu´e peut ˆetre vu comme un processus de classification non supervis´ee o`u nous cherchons `a regrouper les SFG, implicitement les applications correspondantes, ayant des parties communes et parall`element `a calculer un profil pour chaque classe qui caract´erise ses ´el´ements. Id´ealement, les ´echantillons d’un mˆeme malware seraient regroup´ees au sein d’une mˆeme classe et donc caract´eris´es par un seul profil. Contrairement aux autres approches effectuant des classifications non supervis´ees sur les ´echantillons de malware ou des applications en g´en´eral [67, 89, 90, 22], nous n’utilisons aucune notion de distance entre chaque ´el´ement pour d´eterminer s’ils devraient faire partie d’une mˆeme classe. A la ` place, nous consid´erons que deux ´el´ements, ici des SFG, font partie d’une mˆeme classe s’ils ont une partie commune non nulle. Une classification consiste `a apprendre `a partir d’un jeu de donn´ees un mod`ele d´efinissant comment ces donn´ees sont ou peuvent ˆetre regroup´ees. Ici nous souhaitons calculer des classes de SFG et les profils caract´erisants les ´el´ements de chaque classe. Ce jeu de donn´ees est repr´esent´e par la premi`ere liste donn´ee en param`etre de l’algorithme 3. Une deuxi`eme liste est donn´ee en param`etre mais elle sert uniquement `a filtrer les arcs qui pourraient faire partie des profils que nous calculons. Ce filtrage est effectu´e par la fonction clean au d´ebut de la classification. Nous donnerons plus de d´etail sur cet aspect plus tard. Initialement, la classification associe une classe diff´erente `a chacun des SFG des applications. Le r´esultat renvoy´e par l’algorithme, c’est-`a-dire la classifi- cation finale, est obtenue en calculant un point fixe sur l’´evolution de cette classification. Le calcul du point fixe est repr´esent´e par la boucle while tandis que la mise `a jour de la classification est op´er´ee par la fonction one-step-classification (algorithme 4). Cette fonction prend en entr´ee une liste de classe en param`etre et fusionne les paires de classes dont les profils ont une partie commune. En supposant ainsi qu’il y ait n classes dans la classification donn´ee en param`etre, elle v´erifie pour toute combinaison de deux classes si leurs profils respectifs ont une partie commune non nulle. Cela se traduit par C 2 n calculs d’intersection de deux SFG. Si c’est le cas, elle fusionne les deux classes et associe comme profil `a la classe r´esultante cette partie commune non nulle. Aux ´el´ements des deux classes ayant ´et´e fusionn´ees s’ajoutent les ´el´ements des autres classes dont le profil contient l’intersection des profils des deux classes fusionn´ees. Si une classe n’a ´et´e fusionn´ee avec aucune autre classe, elle est ajout´ee telle quelle dans la nouvelle classification.5.1. CARACTERISATION DE MALWARE ANDROID ´ 109 Algorithme 3 : Calcul des parties communes de SFG d’application caract´erisant son comportement malveillant et regroupement de ces SFG Input : [g0,. . . ,gn] une liste de SFG white une liste blanche de SFG Output : [(s0,[g01 ,. . . ,g0i ]),. . . ,(sm,[gm1 ,. . . ,gmk ])] une liste de couple associant les sous-graphes communs aux graphes les contenant begin assoc Ð H; new assoc Ð [(clean (g0, white),[g0]),. . . ,(clean (gn, white),[gn])]; while passoc ‰ new assocq do assoc Ð new assoc; new assoc Ð one-step-classificationpassocq; return assoc; Algorithme 4 : One-step-classification function Input : assoc une liste de SFG Output : une liste d’association de SFG begin new assoc Ð rs ; tmp Ð H; forall the g1 P keyspassocq do forall the g2 P keyspassocqztg1u do if pg1, g2q P tmp or pg2, g1q P tmp then continue; tmp Ð tmp Ytpg1, g2qu; s Ð g1 [ g2 ; if s ­“ H then v Ð valuepassoc, g1q ` valuepassoc, g2q ; forall the g P keyspassocqztg1, g2u do if s Ď g then v Ð v + value (assoc, g) new assoc Ð addpnew assoc,ps, vqq; return new assoc;110 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´ Pr´e-traitement des ´el´ements `a classifier : filtrage des arcs des SFG Nous avons mentionn´e pr´ec´edemment que la deuxi`eme liste donn´ee en entr´ee de l’algorithme 3 ´etait utilis´ee par la fonction clean pour filtrer les arcs pouvant faire partie des profils que nous calculons. Filtrer les arcs pouvant faire partie des profils est une n´ecessit´e car une partie des SFG des applications Android est la mˆeme que ces applications soient b´enignes ou non. Nous filtrons ainsi les arcs `a prendre en compte dans les profils afin de ne pas calculer des profils g´en´eriques d´ecrivant toute application Android au lieu de profils de malwrare d´ecrivant leur comportement malveillant. Cette partie commune entre les SFG des applications Android est due `a la mani`ere dont les applications sont ´ecrites et `a la mani`ere dont l’environnement Android fonctionne. En effet, les composants des applications Android sont des composants qui ´etendent des classes pr´ed´efinies dans Android, `a savoir Activity, BroadcastReceiver, Service et ContentProvider. Les composants h´eritent ainsi des fonctionnalit´es de ces classes. Ainsi, ils ont tous par exemple la mˆeme r´ef´erence au ContextManager, classe servant `a demander les r´ef´erences des diff´erents services du syst`eme. Cette classe effectue la requˆete au processus servicemanager par d´efaut. De plus, l’interaction avec le reste du syst`eme se fait souvent avec des fonctions fournies par l’API Android ce qui peut causer des flux similaires aux applications. Pour cr´eer ou acc´eder aux pr´ef´erences de l’application, les applications utilisent souvent la fonction getSharedPreferences par exemple. L’usage des pr´ef´erences est conseill´e dans divers cas tels que la sauvegarde des donn´ees lorsqu’une applications est mise en pause par le syst`eme. Le fichier stockant les pr´ef´erences est localis´e dans le r´epertoire local de l’application par d´efaut et son acc`es via l’API d’Android est ainsi le mˆeme pour toutes les applications. A cause de ce caract`ere commun, des comportements communs sont par- ` tag´es entre les applications qu’elles soient b´enignes ou non. Ce qui implique qu’une partie des flux d’information qu’elles causent sont les mˆemes. En calculant simplement le sous-graphe commun aux graphes des ´echantillons de malware sans effectuer de filtrage, nous risquerions d’obtenir un graphe en commun caract´erisant n’importe quelle application Android et tout comportement malveillant sera ainsi absent de ce graphe. Pour palier `a ce probl`eme, il est ainsi n´ecessaire de filtrer les ´el´ements `a prendre en compte dans les sous-graphes en commun que nous calculons. Dans les exp´eriences men´ees en section 5.2, nous filtrons les arcs `a prendre en compte dans les profils de malware. Nous ignorons les arcs qui d´ecrivent un flux impliquant les processus system server, celui ex´ecutant l’application de galerie d’images et les fichiers dans /acct/uid 1 . A` ces flux s’ajoutent ceux d´ecrits par les ´el´ements de la deuxi`eme liste donn´ee en entr´ee de l’algorithme 3. Les ´el´ements de cette liste sont des SFG d’applications b´enignes que nous consid´erons comme repr´esentant les comportements communs que nous ne souhaitons pas ˆetre pris en compte durant le calcul des 1. Voir les pages manuel de acct sous Linux5.2. EVALUATION DE LA M ´ ETHODE DE CLASSIFICATION ´ 111 profils. Nous calculons dans la section 5.3 le r´esultat obtenu quand aucun filtrage n’est appliqu´e et montrons que les classes produites ainsi que les profils calcul´es sont trop g´en´eriques pour refl´eter un quelconque malware. Dans la section 5.3, nous montrons l’utilit´e de ce filtrage en r´ep´etant la classification effectu´ee en section 5.2. 5.2 Evaluation de la m´ethode de classification ´ 5.2.1 Jeu de donn´ee Afin d’´evaluer notre algorithme de calcul de sous-graphe, nous proposons de l’appliquer sur 19 ´echantillons de malware : 5 ´echantillons de BadNews [91], 7 de DroidKungFu1 [61], 3 de DroidKungFu2 [60] et 5 de jSMSHider [96]. En plus de ces 19 ´echantillons, nous utilisons ´egalement 7 applications provenant de Google Play dont les SFG constitueront la liste blanche. Ces applications sont compos´es de quatre jeux (Angry birds, Little Dentist, Finger Scanner et Crazy Jump), un navigateur web (Firefox), deux utilitaires (Android Term et Busybox Free) et une application de fond d’´ecran (Ironman 3 live). BadNews est un malware qui infecte les syst`emes Android sous la forme d’applications l´egitimes. En analysant manuellement les 5 ´echantillons avec Androguard, nous avons d´etermin´e que BadNews est un malware dont le comportement est dict´e par un serveur de commande et contrˆole (C&C). A l’ex´ecution ` du code malveillant, il contacte le serveur afin d’obtenir la prochaine commande `a ex´ecuter. D’apr`es l’analyse effectu´ee, il comprend plusieurs commandes : t´el´echarger et installer une application, afficher des informations sous forme de notification (page web `a visiter, mise `a jour d’une application etc), installer de nouveaux icˆones qui m`enent vers une page web ou une application Android qui aurait ´et´e pr´ealablement t´el´echarg´ee et changer l’adresse du serveur C&C. Durant les p´eriodes d’exp´erimentation que nous avons men´ees, le serveur ´etait toujours actif et envoyait les mˆemes commandes `a chaque fois : t´el´echarger deux applications et afficher des notifications de mises `a jour `a l’utilisateur qui une fois cliqu´ees causent l’installation des applications. Les deux applications sont une version infect´ee de Doodle Jump et un jeu en Russe qui est pr´esent´e comme ´etant une version d’Adobe Flash pour Android. DroidKungFu1 est un malware d´ecouvert en 2011 qui installe furtivement des applications sur le t´el´ephone en exploitant des vuln´erabilit´es du syst`eme ou grˆace `a la commande su. Les applications sont install´ees sur la partition system afin de rendre permanente leur pr´esence sur le t´el´ephone. Cette partition est par d´efaut mont´ee en lecture seule et par d´efaut un utilisateur ne peut en changer le contenu. Un acc`es root est n´ecessaire pour cela. DroidKungFu2 a un comportement similaire `a DroidKungFu1. Il exploite ´egalement une vuln´erabilit´e du syst`eme pour ´elever ses privil`eges et installer des applications sur le t´el´ephone. jSMSHider est un malware qui installe ´egalement d’autres applications sur le t´el´ephone de mani`ere furtive. Contrairement aux deux malwares pr´ec´edents,112 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´ il n’exploite aucune vuln´erabilit´e dans le syst`eme pour installer les applications. A la place, son d´eveloppeur a sign´e les ´echantillons du malware avec la cl´e ayant ` servie `a signer les applications syst`eme dans les images non officielles d’Android. Ces images sont cr´e´ees par des d´eveloppeurs de la communaut´e Android qui d´eveloppent des versions personnalis´ees du syst`eme. L’un des plus connus est Cyanogen Mod. Cette cl´e est celle qui est pr´esente dans les d´epˆots du code source d’Android et est ainsi accessible `a tous. Elle n’est cependant utilis´ee pour signer les applications dans les ROM officielles. En signant les ´echantillons avec cette cl´e, les ´echantillons obtiennent ainsi des droits r´eserv´es aux applications syst`eme telles que l’installation d’une application sur le t´el´ephone. 5.2.2 Exp´erimentation et r´esultat Analyse des applications Afin d’obtenir les SFG des ´echantillons, il faut dans un premier temps les analyser pour observer comment leurs donn´ees se propagent dans le syst`eme. Nous avons utilis´e l’environnement d’analyse d´ecrit en section 3.5 : un t´el´ephone Android faisant tourner la version 4.0 d’Android Ice Cream Sandwich auquel a ´et´e ajout´e l’environnement AndroBlare, c’est-`a-dire le noyau modifi´e ainsi que les applications en espace utilisateur. Pour chaque application, nous r´ep´etons le processus suivant. Nous l’installons sur le t´el´ephone, associons un identifiant unique `a ses donn´ees en marquant son apk avec cet identifiant et l’ex´ecutons. Nous utilisons chaque application comme un utilisateur lambda le ferait selon les fonctionnalit´es propos´ees par l’application. En addition `a cela, nous introduisons des ´ev`enements dans le syst`eme qui sont les ´el´ements d´eclencheurs des codes malveillants pr´esents dans les ´echantillons ´etudi´es. Ces ´ev`enements ont ´et´e d´ecouverts en analysant le code de quelques ´echantillons de ces malwares. Nous pr´esentons dans ce qui suit ces ´ev`enements d´eclencheurs mais invitons le lecteur `a lire l’annexe A pour l’analyse d´etaill´ee ayant men´e `a leur d´ecouverte. Afin d’´eviter ou de retarder toute d´etection, les d´eveloppeurs de malware ajoutent parfois des conditions `a l’ex´ecution de leur code. Le code malveillant dans BadNews ne s’ex´ecute par exemple que lorsque le composant MainService ne re¸coit un intent lui signifiant de s’ex´ecuter. Pour ´eviter que le composant ne soit lanc´e `a la r´eception de n’importe quel intent, le d´eveloppeur de BadNews ajoute une v´erification suppl´ementaire lors de la r´eception du message. Il v´erifie que l’intent re¸cu contienne un param`etre update et que la valeur associ´ee `a ce param`etre vaut true. Nous envoyons ainsi manuellement un intent avec un param`etre update dont la valeur associ´ee vaut true `a ce composant afin que le code malveillant s’ex´ecute et que nous puissions observer les flux d’information qu’il cause. Nous effectuons l’envoi grˆa ce `a la commande am, accessible `a partir du shell d’Android comme le montre la commande ci-dessous. $ am startservice APP_NAME/PACKAGE_NAME.AdvService \ --ez update 15.2. EVALUATION DE LA M ´ ETHODE DE CLASSIFICATION ´ 113 Dans le cas de DroidKungFu1 et DroidKungFu2, certains ´echantillons ont une dur´ee minimale d’attente avant d’ex´ecuter le code malveillant. Cette dur´ee est obtenue en soustrayant l’heure du syst`eme avec une date stock´ee dans un fichier sstimestamp.xml dans le r´epertoire local de l’application. Le listing 5.1 est le contenu du fichier avant toute modification pour un des ´echantillons de DroidKungFu1. En rempla¸cant la valeur stock´ee dans ce fichier par une valeur assez petite, par exemple 1, nous for¸cons l’ex´ecution du code malveillant. Nous changeons ici le contenu du fichier sstimestamp.xml lors de l’analyse des ´echantillons de DroidKungFu1 et DroidKungFu2 afin de s’assurer que le code malveillant soit ex´ecut´e. 1 2 Listing 5.1 – Contenu du fichier sstimestamp.xml d’un ´echantillon de DroidKungFu1 Quant aux ´echantillons de jSMSHider, il n’est pas n´ecessaire d’introduire un quelconque ´ev`enement car le code malveillant est ex´ecut´e d`es le lancement de l’application. Une fois les applications analys´ees, nous construisons les SFG correspondants et calculons les parties qui leur sont communes avec un outil impl´ementant l’algorithme 3. Nous pr´esentons dans ce qui suit les r´esultats obtenus. R´esultats A partir des SFG obtenus, nous avons calcul´e 4 profils, c’est-`a-dire 4 SFG. ` A chacun d’entre eux est associ´e un sous-ensemble des SFG donn´es en entr´ee. ` Le tableau 5.1 pr´esente les r´esultats du calcul. La premi`ere colonne liste les ´echantillons utilis´es. La deuxi`eme colonne indique la famille `a laquelle l’´echantillon appartient selon la classification effectu´ee par les auteurs de la collection d’o`u il provient. La troisi`eme colonne indique la collection d’o`u provient l’´echantillon. Les colonnes restantes repr´esentent chacune un profil qui a ´et´e calcul´e `a partir des SFG des ´echantillons. Pour chaque ´echantillon, une case non vide dans l’une de ces colonnes signifie que le SFG de l’´echantillon contient le SFG correspondant au profil. Par cons´equent, le profil caract´erise le comportement de l’´echantillon. Les profils calcul´es sont illustr´es par les figures 5.1, 5.2, 5.3 et 5.4. Le SFG de l’´echantillon live.photo.savanna.apk contient par exemple S0, le SFG illustr´e par la figure 5.1. Sur les 19 ´echantillons utilis´es, 17 d’entre eux sont regroup´es exactement selon leur classification dans leur base d’origine. Le profil S0, figure 5.1, caract´erise les ´echantillons de BadNews. Il d´ecrit l’envoi des donn´ees de l’application vers un deux serveurs distant, le t´el´echargement de deux applications et une partie de leur installation ainsi que de leur ex´ecution. L’envoi des donn´ees correspond aux flux partant du navigateur, android.brow-114 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´ Empreinte MD5 des ´echantillons Famille: Origine§ S0 S1 S2 S3 98cfa989d78eb85b86c497ae5ce8ca19 BN C ‘ e70964e51210f8201d0da3e55da78ca4 BN I ‘ 4ecf985980bcc9b238af1fdadd31de48 BN I ‘ ccab22538dd030a52d43209e25c1f07b BN I ‘ 3a648e6b7b3c5282da76590124a2add4 BN I ‘ 994af7172471a2170867b9aa711efb0d DKF1 G ‘ 39d140511c18ebf7384a36113d48463d DKF1 G ‘ 7f5fd7b139e23bed1de5e134dda3b1ca DKF1 A ‘ 107af5cf71f1a0e817e36b8deb683ac2 DKF1 A ‘ 6625f4a711e5afaee5f349c40ad1c4ab DKF1 G ‘ 6b7c313e93e3d136611656b8a978f90d DKF1 A ‘ 4f6be2d099b215e318181e1d56675d2c DKF2 G ‘ 72dc94b908b0c6b7e3cb293d9240393c DKF2 G ‘ f438ed38b59f772e03eb2cab97fc7685 DKF2 G ‘ ac2a5a483036eab1b363a7f3c2933b51 DKF1 A ‘ 0417b7a90bb5144ed0067e38f7a30ae0 JSH G ‘ a3c0aacb35c86b4468e85bfb9e226955 JSH G ‘ d25008db2e77aae53aa13d82b20d0b6a JSH A ‘ 24663299e69db8bfce2094c15dfd2325 JSH A ‘ : BN : BadNews, DKF1 : DroidKungFu1, DKF2 : DroidKunFu2, JSH : jSMSHider § C : Contagio, G : Genome Project, A : Androguard, I : Internet Table 5.1 – Classification des 19 ´echantillons de malware.5.2. EVALUATION DE LA M ´ ETHODE DE CLASSIFICATION ´ 115 57664 - files/player 24642 - /data/dalvik-cache/data@app@com.realarcade.DOJ-1.apk@classes.dex 1047 - dexopt * 1050 - .realarcade.DOJ * * 81 - mediaserver * * * 57667 - files/stats * 57663 - files/4200 * 57665 - files/4201 * 57666 - files/multi * * 32791 - /data/app/com.realarcade.DOJ-1.apk * * * 320 - ndroid.launcher * 57460 - downloads.db * 577 - iders.downloads 57361 - data_3 0 - (82.x.x.x) 762 - id.defcontainer 7958 - /mnt/asec/smdl2tmp1/pkg.apk * 1026 - ackageinstaller * 15 - /sdcard/download/adobe.flash.apk * 80 - drmserver * 14 - /sdcard/download/doodle.jump.apk * 275 - d.process.media * 57378 - downloads.db-journal * 973 - android.browser * * * * 8237 - /data/drm/fwdlock/kek.dat * * * 0 - (213.x.x.x) * * * * * * Figure 5.1 – S0 : sous-graphe en commun des ´echantillons de BadNews116 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´ ser, vers deux sockets r´eseaux. Sur la figure, nous avons intentionnellement masqu´e une partie des adresses IP. Apr`es v´erification, l’une des adresses, 213. x.x.x, est celle du serveur `a partir duquel les applications sont t´el´echarg´ees. Le t´el´echargement est d´ecrit par l’´ecriture de donn´ees sensibles dans deux fi- chiers apk par le processus iders.downloads. Ce dernier ex´ecute l’application par d´efaut en charge des t´el´echargements de fichier. L’acc`es `a ces deux fichiers par les processus id.defcontainer et packageinstaller indique leur installation et la premi`ere composante connexe du SFG en partant du haut d´ecrit l’ex´ecution d’une nouvelle application, une de celles qui ont ´et´e t´el´echarg´ees par le malware. Ici, il s’agit de la version infect´ee de Doodle Jump. L’ex´ecution de l’autre application n’est pas pr´esente dans le profil car il est install´e dans un r´epertoire chiffr´e qui ne supporte pas les attributs ´etendus. Il est ainsi impossible pour AndroBlare de suivre les flux d’information impliquant les fichiers dans ce type de r´epertoire. Le profil S1, figure 5.2, caract´erise les ´echantillons de DroidKungFu1 `a l’exception de deux d’entre elles que nous expliquerons dans le paragraphe suivant. S1 d´ecrit la copie de deux fichiers dans la partition system et l’ex´ecution de l’une d’entre elles par la suite. Leur destination indique qu’il s’agit d’une application native et d’une application Android. 8330 - /system/app/com.google.ssearch.apk 338 - ndroid.launcher * 1106 - dexopt * 57656 - /data/data/blare-anonym/gjsvro 1056 - gjsvro * * 0 - (127.0.0.1) * 16735 - /system/bin/gjsvr * 24640 - /data/dalvik-cache/system@app@com.google.ssearch.apk@classes.dex * 1105 - cat * * 57660 - /data/data/blare-anonym/legacy * * Figure 5.2 – S1 : sous-graphe en commun des ´echantillons de DroidKungFu 1 Le profil S2, figure 5.3, caract´erise les ´echantillons de DroidKunFu2 ainsi que deux ´echantillons de DroidKungFu1 qui ne sont pas caract´eris´es par S1. S2 indique l’acc`es du contenu de deux fichiers au contenu teint´es par les processus secbino et cat. Si ces flux n’indiquent rien de malveillant en soi, elles correspondent cependant au d´ebut de l’attaque effectu´ee par le malware. Ces processus servent en effet `a la copie d’applications malveillantes dans le syst`eme. Comme5.2. EVALUATION DE LA M ´ ETHODE DE CLASSIFICATION ´ 117 mentionn´e pr´ec´edemment, deux ´echantillons de DroidKungFu1 sont ´egalement caract´eris´es par S2. La raison est que ces ´echantillons partagent uniquement des comportements en commun avec les ´echantillons de DroidKunFu2 en terme de flux. Ainsi aucune fichier gjsvro ou com.google.search.apk, ni les processus correspondants n’ont ´et´e cr´e´es durant leur analyse. 1111 - cat 57651 - /data/data/blare-anonym/mycfg.ini 1113 - cat * 1073 - secbino * 971 - secbino 57656 - /data/data/blare-anonym/WebView.db * * 57652 - /data/data/blare-anonym/secbino * Figure 5.3 – S2 : sous-graphe en commun des ´echantillons de DroidKungFu 2 Le profil S3, figure 5.4, caract´erise les ´echantillons de jSMSHider et d´ecrit l’installation ainsi que le d´ebut de l’ex´ecution d’une nouvelle application. L’acc`es au fichier testnew.apk par le processus id.defcontainer indique l’installation d’une nouvelle application. La lecture du fichier jSMSHider.apk par le processus dexopt puis la cr´eation d’un fichier .dex par ce dernier indique l’ex´ecution d’une nouvelle application. En effet, le processus dexopt est celui en charge d’extraire le code des applications `a partir de l’apk et de cr´eer sa version optimis´ee. A partir des SFG d’´echantillons de 4 familles de malware, nous avons extrait ` 4 profils comportementaux sous la forme de SFG. Chacun de ces profils correspond `a une famille de malware et d´ecrit une partie des comportements connus de ces malwares. Le calcul de ces profils est rendu possible grˆace aux SFG de 7 applications b´enignes qui nous servent `a filtrer les ´el´ements faisant partie de ces profils. La liste d’application est compos´ee de 5 jeux (Angry Birds, Crazy Jump, Fingerprint scanner et Dentist), d’un navigateur internet (Firefox) et de deux utilitaires (un terminal et la boˆıte `a outil busybox). 883 - dexopt 24640 - /data/dalvik-cache/data@app@j.SMSHider-1.apk@classes.dex * * 32788 - /data/app/j.SMSHider-1.apk * 748 - id.defcontainer 57659 - /data/data/blare-anonym/files/testnew.apk * Figure 5.4 – S3 : Sous-graphe en commun des ´echantillons de jSMSHider118 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´ Filtrage Nombre de groupe cr´e´es Aucun filtrage 1 Sans la liste blanche 4 Filtre de base plus 7 SFG 4 20 applications de Google Play 4 Table 5.2 – Nombre de profils obtenus en variant le filtrage 5.3 De la n´ecessit´e du filtrage Nous appliquons un processus de filtrage dans l’´evaluation effectu´ee en section 5.2.2. Ce filtre est compos´e des arcs d´ecrivant des flux avec les processus system server et mediaserver ainsi que ceux des SFG de 7 applications. La raison de ce filtrage est d’´eviter de calculer des classes et profils trop g´en´eriques qui ne refl`etent aucun malware. Afin de montrer la n´ecessit´e de ce filtrage, nous r´ep´etons l’exp´erience mais en faisant varier le filtrage. Nous avons r´ealis´e l’exp´erience sans utiliser aucun filtre, c’est-`a-dire sans liste blanche ni les flux impliquant les conteneurs cit´es en section 5.1, sans la liste blanche puis en utilisant le filtrage de la section pr´ec´edente mais en ajoutant des SFG suppl´ementaires `a la liste blanche. Le tableau 5.2 pr´esente les r´esultats obtenus. Chaque ligne pr´esente le r´esultat obtenu selon le filtrage appliqu´e. La premi`ere colonne liste les diff´erents filtrages et la seconde le nombre de profils/groupes cr´e´e. Nous discutons dans ce qui suit de la pertinence des groupes cr´e´es. En utilisant aucun filtrage, l’algorithme extrait un seul sous-graphe qui est une partie commune aux SFG des 19 ´echantillons de malware utilis´es. La fi- gure 5.5 illustre ce sous-graphe. Les flux d´ecrits par le sous-graphe indique uniquement des ´echanges d’information entrele processus system server et diff´erents processus. Le profil calcul´e est trop g´en´erique et ne d´ecrit aucun comportement malveillant connu des malwares utilis´es. En filtrant sans la liste blanche, nous obtenons 4 profils associ´es `a 4 groupes diff´erents. Si le nombre de profils correspond au nombre de malwares utilis´es, ils ne d´ecrivent cependant aucune action malveillante et les ´echantillons dans chaque groupe sont des ´echantillons de malware diff´erent dont le comportement en terme de flux d’information ne devrait pas ˆetre le mˆeme. Les figures 5.6, 5.7, 5.8 et 5.9 illustrent les profils calcul´es et d´ecrivent des flux tout `a fait normaux dans le syst`eme. La premi`ere figure d´ecrit par exemple un simple ´echange d’information entre les applications syst`eme com.android.phone et com.android.systemui. En ´etendant la liste blanche utilis´ee en section 5.2.2 de 20 SFG suppl´ementaires, nous obtenons les mˆemes profils et les mˆemes groupes que ceux calcul´es dans la section 5.2.2. Augmenter le nombre d’´el´ements dans cette liste est inutile et les SFG des applications qui la composent repr´esentent de mani`ere satisfaisante les comportements g´en´eriques que nous souhaitions ignorer durant notre classification.5.3. DE LA NECESSIT ´ E DU FILTRAGE ´ 119 326 - ndroid.launcher 135 - system_server * 82 - mediaserver * 292 - m.android.phone * 903 - app_process * * * * 206 - ndroid.systemui * 673 - ufou.android.su * 310 - com.android.nfc * * 32783 - /data/app/blare-anonym-1.apk * Figure 5.5 – Profil calcul´e lorsqu’aucun filtrage n’est r´ealis´e120 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´ 308 - m.android.phone 221 - ndroid.systemui Figure 5.6 – Premier profil calcul´e en utilisant aucune liste blanche 202 - ndroid.systemui 32781 - /data/app/blare-anonym-1.apk Figure 5.7 – Second profil calcul´e en utilisant aucune liste blanche 276 - d.process.media 57526 - /data/data/com.android.providers.media/databases/external.db 57524 - /data/data/com.android.providers.media/databases/external.db-wal Figure 5.8 – Troisi`eme profil calcul´e en utilisant aucune liste blanche 1400 - m.android.email 1416 - ndroid.exchange 57472 - /data/data/com.android.email/databases/EmailProvider.db 57473 - /data/data/com.android.email/databases/EmailProvider.db-journal Figure 5.9 – Quatri`eme profil calcul´e en utilisant aucune liste blanche5.4. DETECTION D’EX ´ ECUTION DE MALWARE ANDROID ´ 121 L’algorithme 3 que nous avons propos´e dans cette section est algorithme de classification qui regroupe les SFG des applications ayant des parties communes non nulles et calcule `a la fois le profil correspondant `a chaque classe. Nous avons ´evalu´e cet algorithme avec un jeu de donn´ees de 19 ´echantillons provenant de 4 familles de malware diff´erentes. En appliquant l’algorithme sur les SFG des 19 ´echantillons, nous avons calcul´e 4 profils tels que chaque profil corresponde `a une famille de malware diff´erent et d´ecrit le comportement malveillant du malware auquel il correspond. Dans la section qui suit, nous proposons une m´ethode de d´etection d’´echantillon de malware en utilisant les profils calcul´es par notre algorithme. 5.4 D´etection d’ex´ecution de malware Android Les r´esultats pr´ec´edents, tableau 5.1, montrent que les ´echantillons de malware peuvent ˆetre caract´eris´es par un SFG qui d´ecrit une partie de comportement malveillant qu’ils ont. Dans cette section, nous proposons cette fois d’utiliser ces profils SFG pour d´etecter l’ex´ecution d’autres ´echantillons de malware. Plus pr´ecis´ement, nous proposons d’utiliser ces profils SFG en tant que profil de r´ef´erence afin de d´etecter si les donn´ees d’une application sous surveillance se propagent de la mˆeme mani`ere que celle d´ecrite par l’un des SFG. L’algorithme 5 d´ecrit le processus de d´etection pour une application/information donn´ee. Il prend en entr´ee les flux observ´es par AndroBlare ainsi qu’une liste de profil SFG avec lesquels il compare les flux observ´es pour d´etecter l’ex´ecution de malware. A l’initialisation du processus de d´etection, nous com- ` men¸cons par construire une liste d’association dans laquelle nous associons chaque arc des profils donn´es en entr´ee avec la liste des profils SFG(s) o`u il est pr´esent. Cette ´etape facilite la recherche d’une correspondance entre les flux observ´es et les arcs des profils SFG. Lors de la phase de d´etection, nous comparons ensuite chaque flux observ´e avec les arcs des diff´erents profils SFG afin de trouver une similarit´e entre eux. Si une similarit´e est trouv´ee, nous levons une alerte. Nous consid´erons qu’il y a une similarit´e entre un flux d’information et un arc si les conteneurs d’information de d´epart et d’arriv´ee du flux observ´e sont respectivement les mˆeme que ceux d´ecrits par les nœuds de d´epart et d’arriv´ee de l’arc et que les informations qui se propagent dans le flux observ´e et celui du flux d´ecrit par l’arc sont les mˆemes. Le conteneur d’information dans une entr´ee de Blare est le mˆeme que celui repr´esent´e par un nœud d’un SFG lorsqu’ils ont le mˆeme type et le mˆeme nom. Apr`es avoir lev´e l’alerte, nous enlevons l’arc de la liste d’association afin de ne pas lever la mˆeme alerte plusieurs fois.122 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´ Algorithme 5 : D´etection de l’ex´ecution de malware Android bas´e sur les flux d’information caus´e dans le syst`eme Input : L journal de Blare, sig l liste de profils SFG begin notseen Ð empty association list; forall the g P sig l do forall the e P edgespgq do if e R keyspnotseenq then Add pe, tguq to notseen; else old Ð valuepe, notseenq; Remove pe, oldq from notseen; Add the association pe, old Y tguq to notseen; forall the entry e P L do if to edgepeq Plight keyspnotseenq then l Ð valuepto edgepeq, notseenq; forall the g P l do Alert that a similarity with namepgq has been found; Remove pto edgepeq, lq from notseen; 5.5 Evaluation de la capacit´e de d´etection ´ Afin d’´evaluer la capacit´e de d´etection de l’approche pr´esent´ee pr´ec´edemment, nous proposons deux types d’exp´erience. Le premier consiste `a ´evaluer le taux de faux positif, c’est-`a-dire calculer le taux de fausses alertes lev´ees lorsque des applications b´enignes sont analys´ees. Le deuxi`eme consiste `a ´evaluer le taux de vrai positif, c’est-`a-dire calculer le taux d’alertes lev´ees lorsque des applications malicieuses sont ex´ecut´ees. Pour mener ces exp´eriences, nous proposons d’analyser des applications, b´enignes et malicieuses, dans l’environnement d’analyse pr´esent´e en section 3.5 et `a partir des flux observ´es d´etecter les ex´ecutions de malware. Jeu de donn´ees Nous utilisons 70 des applications les plus populaires 2 dans Google Play pour la premi`ere exp´erience et 39 ´echantillons de malware provenant des 4 familles de malware utilis´ees dans la section 5.2.2. Nous supposons que les 70 applications sont b´enignes car elles n’ont lev´e aucune alerte lorsque nous les avons soumises `a la plateforme d’analyse de VirusTotal [14]. 2. au mois de Juin 20135.5. EVALUATION DE LA CAPACIT ´ E DE D ´ ETECTION ´ 123 Analyse des applications et d´etection de l’ex´ecution de malware Le processus d’analyse de chaque applications est le mˆeme qu’en section 5.2.2. Il se traduit par son installation dans un environnement AndroBlare, le marquage de son apk et son ex´ecution. Nous utilisons chaque application comme un utilisateur normal le ferait et en parall`ele, nous introduisons les ´ev`enements d´eclenchant le code malveillant dans les ´echantillons de malware. Introduire ces ´ev`enements nous assure que le code malveillant se d´eclenche durant l’analyse afin de d´eterminer si oui ou non notre approche permet de d´etecter l’ex´ecution du code malveillant. Une fois les applications analys´ees, nous analysons les flux observ´es par AndroBlare pour d´etecter l’ex´ecution de malware. La d´etection est r´ealis´ee ult´erieurement `a l’analyse car nous souhaitions collecter les flux et ˆetre capables de les r´eutiliser plus tard. L’outil utilis´e est cependant capable de faire la d´etection en temps r´eel. R´esultat de la d´etection Lors de l’analyse des flux engendr´es par les diff´erentes applications, notre outil a lev´e des alertes pour chacun des ´echantillons de malware et aucune pour les applications b´enignes. Les tableaux 5.3 et 5.4 r´esument le r´esultat des exp´eriences men´ees respectivement sur les applications b´enignes provenant de Google Play et les ´echantillons de malware. Le premier tableau pr´esente les r´esultats avec les applications b´enignes provenant de Google Play. La premi`ere colonne liste les diff´erentes cat´egories d’application utilis´ee durant l’exp´erience. La deuxi`eme indique le nombre d’´echantillons utilis´es pour chaque cat´egorie. La troisi`eme indique les correspondances entre les flux observ´es et l’une des profils utilis´es. La derni`ere indique le total des flux observ´es lors de l’analyse des applications de chaque cat´egorie. Le deuxi`eme tableau pr´esente les r´esultats obtenus avec les ´echantillons de malware. La premi`ere colonne liste les ´echantillons. La deuxi`eme indique comment l’´echantillon a ´et´e cat´egoris´e dans sa collection d’origine. La troisi`eme indique la collection d’origine de l’´echantillon. La quatri`eme indique le nombre de flux observ´es par AndroBlare durant l’analyse. Les colonnes restantes indiquent le nombre de correspondance entre le profil SFG et les flux observ´es. Plus pr´ecis´ement, les valeurs dans ces colonnes indiquent le nombre d’arc du profil SFG qui correspondent `a au moins un des flux observ´es durant l’analyse de l’´echantillon. L’analyse des flux caus´es par les applications b´enignes montre que notre outil n’a d´etect´e aucun flux qui correspond `a l’un des arcs des profils utilis´es. Sur les 70 applications b´enignes analys´ees, aucune n’a ´et´e d´etect´ee comme ex´ecutant du code malveillant, ce qui nous donne un taux de faux positif nul. Chaque ´echantillon de malware a caus´e la lev´ee d’alerte par notre outil de d´etection. Plus pr´ecis´ement, chaque ´echantillon a ´et´e d´etect´e avec le profil SFG correspondant `a la famille d’origine `a laquelle il est suppos´e appartenir. Ainsi,124 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´ Cat´egorie Echantillons ´ Signature Journal match entries Jeux 48 0 7386736 Utilitaires 8 0 403427 R´eseaux sociaux 5 0 567605 Photo / Vid´eo 5 0 579883 Magazine 3 0 169622 Table 5.3 – R´esultat de d´etection sur les applications b´enignes provenant de Google Play. Taux de faux positif : 0% les ´echantillons de BadNews, DroidKungFu1, DroidKungFu2 et jSMSHider ont ´et´e d´etect´es respectivement grˆace au profil S0, S1, S2 et S3. La majorit´e des ´echantillons a caus´e autant d’alerte que de nombre d’arc que le profil pour lequel une correspondance a ´et´e trouv´e. L’´echantillon live.photo.drop.apk a par exemple caus´e 36 flux diff´erents qui correspondent aux 36 arcs du pro- fil SFG de BadNews. Cependant, quelques ´echantillons n’ont caus´e la lev´ee d’alerte que pour une partie des arcs du profil SFG de la famille de malware `a laquelle ils sont associ´es. Cela est dˆu au fait que durant leur analyse, une partie du comportement attendu ne s’est pas ex´ecut´e. L’´echantillon 41f7b03a94d38bc9b61f8397af95a204 n’a par exemple caus´e que 4 correspondances sur 11 entre les flux qu’il a engendr´es et les arcs de S1. Le profil S1 d´ecrit l’installation de deux applications, une native et une apk dans la partition system du t´el´ephone. L’´echantillon n’a cependant install´e que l’application native durant notre analyse car l’apk cens´e ˆetre install´e est un fichier vide et la proc´edure d’installation est ainsi avort´ee par le syst`eme.5.5. EVALUATION DE LA CAPACIT ´ E DE D ´ ETECTION ´ 125 Empreinte MD5 des ´echantillons Label: Origin§ Log size S0; S1; S2; S3; d25008db2e77aae53aa13d82b20d0b6a JSH A 79598 4{4 24663299e69db8bfce2094c15dfd2325 JSH A 179608 4{4 39d140511c18ebf7384a36113d48463d DKF1 A / G 3565 11{11 7f5fd7b139e23bed1de5e134dda3b1ca DKF1 A 5772 11{11 a81dc5210b3444b8e6f002605a97292d DKF1 A 3233 3{11 107af5cf71f1a0e817e36b8deb683ac2 DKF1 A 7257 11{11 ac2a5a483036eab1b363a7f3c2933b51 DKF1 A 3596 5{5 e741a9bc460793b9afdadc963d6e8c1d DKF1 A 3230 3{11 6b7c313e93e3d136611656b8a978f90d DKF1 A 7740 5{5 389b416fb0f505d661716b8da02f92a2 JSH G 179702 4{4 a3c0aacb35c86b4468e85bfb9e226955 JSH G 7527 4{4 0417b7a90bb5144ed0067e38f7a30ae0 JSH G 32145 4{4 d25008db2e77aae53aa13d82b20d0b6a JSH G 122951 4{4 f0fcef1c52631ae36f489351b1ba0238 JSH G 211823 4{4 06dea6a4b6f77167eaf7a42cb9861bbe DKF1 G 72706 6{11 994af7172471a2170867b9aa711efb0d DKF1 G 13959 11{11 107af5cf71f1a0e817e36b8deb683ac2 DKF1 G 187221 11{11 71fe80d5bf6d08890de3c76a3292fc09 DKF1 G 15709 11{11 ecc4aad77ab042a4fa1693fc77afb8ac DKF1 G 107910 11{11 b763bc07f641bb915a4e745f1deff315 DKF1 G 180984 8{11 6625f4a711e5afaee5f349c40ad1c4ab DKF1 G 4982 11{11 5c593a7ab5e61f76d2e0e61c870da986 DKF1 G 99363 11{11 41f7b03a94d38bc9b61f8397af95a204 DKF1 G 13474 4{11 f438ed38b59f772e03eb2cab97fc7685 DKF2 G 34906 5{5 4f6be2d099b215e318181e1d56675d2c DKF2 G 283990 5{5 805bbc6ff9ef376c4b5f2c1b1c1006d2 DKF2 G 49404 5{5 13a491126dd11f1ef51a4b067f10f368 DKF2 G 278425 5{5 72dc94b908b0c6b7e3cb293d9240393c DKF2 G 294163 5{5 e4d348e97db481507a0cea64232c8065 DKF2 G 64616 5{5 47ffc035dd1288bad27b3681535e68c8 BN I 298819 36{36 d8943ed5be382c22c9a206af0815ff0a BN I 363578 36{36 ccab22538dd030a52d43209e25c1f07b BN I 167837 36{36 3a648e6b7b3c5282da76590124a2add4 BN I 332519 36{36 4ecf985980bcc9b238af1fdadd31de48 BN I 125167 36{36 5b08c96794ad5f95f9b42989f5e767b5 BN C 132846 36{36 422d1290422ebfbf48ec34f0990fba21 BN I 634202 35{36 98cfa989d78eb85b86c497ae5ce8ca19 BN C 568920 36{36 e70964e51210f8201d0da3e55da78ca4 BN I 253320 36{36 8b9e8a2e93c3f3c18b8f5820f21e2458 BN I 149248 36{36 : BN : BadNews, DKF1 : DroidKungFu1, DKF2 : DroidKunFu2, JSH : jSMSHider § C : Contagio, G : Genome Project, A : Androguard, I : Internet Table 5.4 – R´esultats de la d´etection sur 39 ´echantillons de malware. Taux de Vrai Positif : 100%126 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´ Bilan et discussion Nous avons pr´esent´e et ´evalu´e dans ce chapitre une nouvelle m´ethode de classification et de d´etection des ´echantillons de malware bas´ee sur les flux d’information qu’ils causent dans le syst`eme d´ecrits par leur SFG. La m´ethode de classification propos´ee peut-ˆetre vue comme un apprentissage non supervis´e o`u nous cherchons `a construire des classes d’´echantillons de malware o`u les SFG des ´el´ements d’une mˆeme classe partagent tous une partie commune. Cette partie commune est cens´ee d´ecrire l’attaque men´ee par le(s) malware(s) et caract´eriser les ´echantillons de la classe qu’elle repr´esente en tant que profil comportemental. Nous avons ´evalu´e la m´ethode propos´ee en classifiant 19 ´echantillons de 4 malwares diff´erents. La classification de ces ´echantillons a donn´e en sortie 4 classes distinctes qui repr´esentent chacun un des 4 malwares et la partie commune des SFG des ´el´ements de chaque classe d´ecrit une partie de l’attaque men´ee par les mawares. A partir des profils caract´erisant chaque classe, nous avons propos´e de d´etecter ` des ´echantillons des 4 malawres utilis´es durant la classification. La m´ethode de d´etection consiste `a comparer les flux observ´es caus´es par les ´echantillons analys´es avec les arcs des profils comportementaux calcul´es. A chaque fois ` qu’une correspondance est trouv´ee, une alerte est lev´ee. Nous avons ´evalu´e cette m´ethode avec 36 ´echantillons de malware ainsi que 70 applications b´enignes provenant de Google Play et avons obtenu un taux de vrai positif de 100% ainsi qu’un taux de faux positif de 0%. Les ´echantillons de malware ont bien ´et´e d´etect´e et aucune alerte n’a ´et´e lev´ee dans le cas des applications b´enignes. De plus, chaque ´echantillon de malware a ´et´e d´etect´e grˆace au profil caract´erisant la classe associ´ee au malware obtenue durant la classification. La raison de la qualit´e des r´esultats obtenus aussi bien pour la classification que pour la d´etection est que le profil calcul´e ne se limite pas aux processus ex´ecutant les ´echantillons de malware. Il inclut ´egalement tout ´el´ement du syst`eme ayant acc`es aux informations provenant des ´echantillons de malware. Mˆeme si un malware change son aspect, le profil calcul´e ne sera que tr`es peu impact´e car le malware n’a pas de contrˆole ou alors tr`es peu sur tous les autres ´el´ements du syst`eme ayant acc`es `a ses informations au d´ebut de l’attaque. Si le cas contraire s’av´erait ˆetre vrai, c’est-`a-dire que le malware a un contrˆole total sur tous les autres ´el´ements du syst`eme, alors il pourrait propager ses informations de mani`ere diff´erente `a chaque ex´ecution et empˆecher notre algorithme de calculer un profil ou de d´etecter l’ex´ecution de l’un de ses ´echantillons. L’approche propos´ee se base sur une analyse dynamique des applications afin d’observer les flux d’information qu’elles causent dans le syst`eme. Comme toute approche dynamique, elle souffre ainsi de la mˆeme limitation qui est la couverture de code durant l’analyse et qui, pour le moment, limite la possibilit´e d’automatiser enti`erement tout le processus d’analyse et de classification des applications. En effet, durant l’analyse nous stimulons les applications en interagissant avec elles via leur interface graphique et introduisons des ´ev`enements dans le syst`eme afin de d´eclencher le code malveillant dans les ´echantillons de malware. Cette stimulation est r´ealis´ee manuellement. De plus, il nous a n´ecessit´e5.5. EVALUATION DE LA CAPACIT ´ E DE D ´ ETECTION ´ 127 d’analyser quelques ´echantillons de malware afin de d´eterminer les ´ev`enements d´eclenchant le code malicieux pr´esents dans leur code. Il serait ainsi int´eressant pour stimuler les applications et couvrir le maximum de code `a l’ex´ecution. La m´ethode de caract´erisation de malware Android propos´ee dans ce chapitre a fait l’objet d’une publication `a la conf´erence NSS 14 [17].128 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´Chapitre 6 Conclusion Dans cette th`ese nous avons propos´e et ´evalu´e une nouvelle m´ethode afin de caract´eriser / classifier et d´etecter les malwares Android. Afin d’y arriver, nous sommes pass´es par plusieurs ´etapes qui ont consist´e `a porter un moniteur de flux d’information sur Android, proposer une structure compacte et humainement compr´ehensible des flux d’information que le moniteur observe qui puisse aider un analyste `a comprendre le comportement d’une application et classifier ainsi que d´etecter les ´echantillons de malware `a partir de cette structure. La premi`ere ´etape de la th`ese a consist´e `a cr´eer AndroBlare, une version Android de Blare. Blare a ´et´e initialement d´evelopp´e pour les syst`emes Linux, et plus pr´ecis´ement pour les noyaux Linux. Si le syst`eme Android est proche des syst`emes Linux, le noyau Android ´etant bas´e sur le noyau Linux et suit la mˆeme num´erotation, il poss`ede cependant quelques fonctionnalit´es qui lui sont propres et qu’il a fallu prendre en compte lors du portage de Blare vers Android. Ces fonctionnalit´es sont l’ex´ecution des applications Android et le m´ecanisme de communication entre processus via le Binder. Nous avons ainsi introduit deux extensions dans AndroBlare pour prendre en compte ces deux fonctionnalit´es d’Android. Ces extensions ajoutent la prise en compte des flux d’information s’op´erant via le Binder et un m´ecanisme de coop´eration entre les instances de la machine virtuelle Dalvik et KBlare. Ces deux extensions sont importantes car elles permettent d’observer les flux d’information entre les applications Android ainsi que l’ex´ecution des applications. Diff´erents m´ecanismes sont utilis´es par les applications pour communiquer avec le reste des applications sur le syst`eme et tous ces m´ecanismes reposent sur le Binder. Ces communications n’´etaient cependant pas visibles avec la version Linux de Blare car Binder est sp´ecifique `a Android et n’est donc pas pris en compte. La premi`ere extension comble donc cette limitation de Blare en interceptant les ´emissions et r´eception de transaction et en effectuant les op´erations de propagation et de contrˆole des flux d’information correspondantes. Quant aux applications Android, leur ex´ecution est ´egalement invisible avec la version Linux de Blare. Le code de ces applications ´etant livr´e sous forme de dalvik bytecode, elles ne sont pas ex´ecut´ees directement mais interpr´et´ees par la machine virtuelle Dalvik. La deuxi`eme extension permet 129130 CHAPITRE 6. CONCLUSION donc, grˆace au m´ecanisme de coop´eration, de combler cette autre limitation de la version Linux de Blare. Grˆace `a ce m´ecanisme de coop´eration, les instances de la machine virtuelle Dalvik notifient KBlare dans le noyau `a chaque fois que le code d’une application est sur le point d’ˆetre interpr´et´e. A la r´eception d’une ` notification, KBlare met `a jour le label du processus ex´ecutant la machine virtuelle ayant ´emis la notification pour signifier le code qu’il ex´ecute et appliquer la politique de flux d’information de l’application au processus. La deuxi`eme ´etape a consist´e `a proposer une structure repr´esentant de mani`ere plus compacte et plus compr´ehensible les flux d’information observ´es par Blare que nous avons appell´e graphe de flux syst`eme ou SFG. Pour une information donn´ee, le SFG d´ecrit comment elle est propag´ee dans tout le syst`eme. Comme nous l’avons montr´e dans le chapitre 4, cette structure s’av`ere utile sur trois aspects. Premi`erement, sa repr´esentation est plus compacte et facilite l’analyse des flux d’information observ´es dans le syst`eme. A chaque fois qu’un ` flux d’information impliquant une donn´ee sensible, comprendre une donn´ee `a laquelle un identifiant a ´et´e associ´e, est observ´e, Blare ajoute une entr´ee d´ecrivant ce flux dans un journal. Or comme nous l’avons montr´e dans le chapitre 4, certains de ces flux sont r´ep´et´es plusieurs fois durant l’analyse de l’application ce qui au bout de quelques entraˆıne la cr´eation de milliers d’entr´ees dans le journal de Blare alors qu’en r´ealit´e seule une centaine de flux d’information uniques ont ´et´e observ´es. Ensuite, le SFG aide `a comprendre le comportement d’une application. Dans notre cas, nous nous sommes int´eress´es aux applications malveillantes. L’analyse d’un ´echantillon de DroidKungFu1 a montr´e qu’une partie de son SFG d´ecrivait l’attaque men´ee par le malware, `a savoir tentative d’´el´evation de privil`ege et installation de deux applications dans le syst`eme. La troisi`eme et derni`ere ´etape a consist´e consiste en la classfication et d´etection de malware. Dans cette ´etape, nous avons propos´e d’utiliser le profil sous forme de SFG des applications afin d’extraire le profil d’un malware. Dans l’´etape pr´ec´edente, nous avons montr´e que une partie du SFG de l’´echantillon de DroidKungFu1 correspondait au comportement malveillant du malware. D’apr`es les travaux de Zhou et al. dans [113], les d´eveloppeurs de malware ajoutent souvent leur code malveillant dans plusieurs applications existantes pour infecter les utilisateurs. Cela signifie donc que le mˆeme code malveillant peut ˆetre retrouv´e dans les ´echantillons d’un mˆeme malware ou qu’une similarit´e en mati`ere de comportement peut ˆetre retrouv´e dans le code malveillant de ces ´echantillons. Partant de ce constat, nous avons ´emis l’hypoth`ese que si une partie du SFG d’une application malveillante correspond au comportement malveillant et que si la m´ethode d’infection principale des d´eveloppeurs de malware ´etait d’injecter leur code malveillant dans des applications existantes alors une partie des SFG des ´echantillons d’un mˆeme malware devrait ˆetre le mˆeme. Direction pour des travaux futurs Le premier apport de la th`ese est AndroBlare, le r´esultat du portage de Blare sous Android. AndroBlare suit les flux d’information en consid´erant les131 objets du syst`eme comme des boˆıtes noires. Comme nous l’avons ´evoqu´e en section 2.6, une observation au niveau syst`eme offre une vue compl`ete des flux entre les diff´erents objets du syst`eme mais a une granularit´e moins fine qu’une observation au niveau applicatif. Par exemple, dans le cas d’AndroBlare, un flux d’un objet A vers un objet B signifie que toutes les informations dans A se propagent vers B (pire des cas). Cela n’est pas forc´ement le cas et il se peut qu’aucune information sensible ne se soit propag´ee. La granularit´e d’observation n’est donc pas assez fine. Un axe `a explorer serait ainsi de combiner les niveaux d’observation syst`eme et applicatif sous Android afin d’affiner la granularit´e des flux observ´es. L’apport d’une telle est non n´egligeable dans le cas de certains processus tels que system server car ce processus ex´ecute plusieurs services avec qui les applications interagissent tous, ce qui est une source de l’explosion des marques dans la version actuelle d’AndroBlare. Un autre apport de la th`ese, qui est le principal, est l’usage des SFG en tant que profil des malware. Pour calculer ce profil, nous calculons les intersections des SFG des ´echantillons de malware. Cette intersection n’autorise aucune d´eviation, mˆeme moindre, dans les flux observ´es. Par exemple, les flux d´ecrivant un processus P1 communiquant avec un processus P2 via un fichier et les flux d´ecrivant les mˆemes processus P1 et P2 communiquant cette fois de mani`ere directe sont consid´er´es comme des flux diff´erents. Cependant, dans la r´ealit´e, ils d´ecrivent la mˆeme action qui est la communication entre deux processus. Nous parlons dans ce cas de flux similaire. Il serait ainsi int´eressant d’explorer l’usage de la similarit´e `a la place d’une correspondance stricte entre les flux d’information observ´es. L’usage de la similarit´e pourrait par exemple r´ev´eler la ressemblance entre deux ou plusieurs malware. Il pourrait ´egalement am´eliorer la r´esistance de l’approche face `a des d´eviations de comportement dans les ´echantillons des malware. L’approche que nous proposons pour classifier et d´etecter les malware est une approche dynamique. Nous analysons dans un environnement AndroBlare les applications afin de capturer les flux d’information qu’ils causent dans le syst`eme. L’une des limites de cette approche est la couverture de code. Nous couvrons durant l’ex´ecution qu’une partie de tout le code de l’application que nous analysons. Dans le cas de l’analyse des ´echantillons de malware, nous avons par exemple du analys´e statiquement leur code afin de trouver les ´ev`enements d´eclenchant le code malveillant. Ces ´ev`enements ont ensuite ´et´e introduits durant l’analyse des ´echantillons avec AndroBlare afin de s’assurer que leur comportement malveillant soit captur´e. Quant aux applications b´enignes, nous les avons utilis´e comme un utilisateur normal pendant cinq minutes mais cela ne garantie pas une couverture optimale du code. Un axe `a explorer serait ainsi une m´ethode pour couvrir tout le code des applications durant leur analyse avec AndroBlare afin que tout leur comportement soit captur´e et d’automatiser tout le processus d’analyse des applications. Cela ouvrirait ´egalement la voie `a une exp´erimentation `a plus grande ´echelle des m´ethodes de classification et de d´etection que nous avons propos´e dans cette th`ese. Il est souvent plus difficile de finir que de commencer.132 CHAPITRE 6. CONCLUSIONAnnexe A Analyse d’´echantillons de malware : recherche des ´ev`enements d´eclenchant leur code malveillant Lors de la validation exp´erimentale des approches pour la caract´erisation et la d´etection de malware Android, nous avons utilis´e des ´echantillons de 4 malwares diff´erents : DroidKungFu1, DroidKungFu2, jSMSHider et BadNews. Le but des exp´eriences men´ees ´etait de montrer qu’il ´etait possible de caract´eriser sous forme de SFG le comportement malveillant des malware et d’utiliser ces SFG pour d´etecter l’ex´ecution d’autres instances des malware que nous supposions non-connues. Pour capturer et d´etecter ce comportement malveillant, ils nous a fallu introduire des ´ev`enements dans le syst`eme afin de d´eclencher le code malveillant. Nous pr´esentons dans ce qui suit l’analyse de quelques ´echantillons de malware afin de d´eterminer ces ´ev`enements. A.1 Outils Pour analyser les ´echantillons de malware, nous utilisons principalement les outils Androguard et apktool. Nous nous servons principalement d’Androguard afin de d´ecompiler `a la vol´ee le code des applications Android et d’apktool pour extraire le contenu des fichiers apk, d´ecoder en clair le contenu des fi- chiers AndroidManifest.xml ainsi que pour d´esassembler en smali le code des applications. 133134ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´ A.2 BadNews BadNews est un malware Android d´ecouvert en 2013 qui se r´epandait sousforme d’applications existantes infect´ees par un code malveillant. Le rapport d’analyse effectu´e dans [91] indique que le comportement de BadNews est dict´e par un serveur C&C. Lorsqu’un client se connecte, le serveur lui envoie une commande `a ex´ecuter et attend sa prochaine connexion pour lui indiquer la prochaine action `a effectuer. Trouver l’´ev`enement d´eclencheur du comportement malveillant des ´echantillons de BadNews revient ainsi `a trouver l’´ev`enement qui d´eclenche le connexion vers le serveur puis le traitement de la commande `a ex´ecuter. Pour identifier les ´ev`enements d´eclencheurs du code malveillants de BadNews, nous avons analys´e l’un de ses ´echantillons 1 provenant de la collection Contagio. L’approche que nous avons adopt´e est de partir des diff´erents points d’entr´ee de l’application afin d’identifier le code impl´ementant le comportement de BadNews, puis d´eterminer l’´ev`enement attendu par l’application pour d´eclencher l’ex´ecution du code. Les composants sont les points d’entr´ee d’une application Android. A quelques exceptions pr`es, ils doivent tous ˆetre list´es dans ` le fichier AndroidManifest.xml. Le listing A.1 pr´esente le contenu de ce fichier pour l’´echantillon analys´e. Il indique que l’application poss`ede cinq composants : deux de type Activity, un Service et deux de type Receiver. L’analyse du code des deux composants Receiver indique qu’ils ex´ecutent tous deux la mˆeme action `a la r´eception d’un intent, listing A.2, `a savoir le lancement du composant AdvService. L’analyse du code de AdvService s’av`ere fructueuse car parmi les m´ethodes de ce composant se trouve une m´ethode sendRequest, listing A.3, qui impl´emente le comportement attendu de BadNews : envoi d’une requˆete vers un serveur distant et ex´ecution de diff´erentes actions selon la r´eponse re¸cue : installation d’application, ajout de raccourci sur le t´el´ephone, affichage de notification etc. Le code ayant ´et´e identifi´e, il reste `a d´eterminer comment il est appel´e et sous quelles conditions. L’une des fonctionnalit´es d’Androguard est de construire le graphe d’appel des fonctions d’une application et de l’exporter sous un format de graphe reconnu par des outils de visualisation et manipulation de graphe tels que Gephi. Grˆace `a la commande androgexf dans Androguard, nous cr´eons ainsi un graphe sous le format gexf d´ecrivant les appels de fonction dans l’´echantillon analys´e et que nous pouvons ouvrir avec Gephi. La figure A.1 est un extrait du graphe d’appel produit quand nous le visualisons sous Gephi. Chaque nœud repr´esente une m´ethode dont le label comporte le nom de la classe o`u la m´ethode est d´eclar´ee, son nom et sa signature. Quant aux arcs, ils repr´esentent les appels de fonction entre les m´ethodes. Un arc de A vers B signifie que la m´ethode A appelle la m´ethode B. Ainsi la m´ethode sendRequest est directement appel´ee par getUpdate. En analysant la premi`ere composante connexe du graphe `a partir du bas de la figure, nous remarquons que sendRequest est uniquement appel´e durant l’ex´ecution d’un Thread impl´ement´e par la classe AdvService$1 2 . La com- 1. SHA sum : f1b351d1280422c5d1e3d2b1b04cb96a5d195f62 2. m´ethode runA.2. BADNEWS 135 19 21 26 27 28 29 30 31 34 36 38 39 40 41 42 44 45 46 47 48 49 51 Listing A.1 – Fichier AndroidManifest.xml d’un ´echantillon de BadNews posante connexe en haut de la figure nous r´ev`ele ´egalement que le thread n’est instanci´e que lors de l’ex´ecution de la m´ethode onStartCommand de AdvService, c’est-`a-dire lorsqu’AdvService re¸coit un intent lui demandant de s’ex´ecuter. L’analyse du code de onStartCommand, listing A.4 nous le confirme et nous indique mˆeme la condition pour que le thread soit lanc´e. En effet pour qu’il soit ex´ecut´e, il faut que l’intent re¸cu par AdvService contienne un param`etre update dont la valeur doit ˆetre diff´erente de 0 3 . Ainsi pour lancer l’ex´ecution du code malveillant de BadNews, il faut envoyer un intent avec un param`etre update dont la valeur est `a true au composant AdvService. Dans le cas de certains ´echantillons, le composant AdvService est nomm´e diff´eremment. Il suffit dans ce cas d’envoyer l’intent `a ce composant. La commande am permet l’envoi de l’intent `a partir de la ligne de commande sous Android comme illustr´e ci-dessous. Il est n´ecessaire de pr´eciser `a la fois le 3. Les bool´eens sont consid´er´es comme des entiers sous Dalvik136ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´ nom complet de l’application ainsi que celui du composant afin que le syst`eme puisse d´eterminer le destinataire exact du message. $ am startservice APP_NAME/PACKAGE_NAME.AdvService \ --ez update 1 1 public void onReceive(android.content.Context p4, android.content.Intent p5) { 2 v0 = new android.content.Intent(); 3 v0.setAction("com.mobidisplay.advertsv1.AdvService"); 4 v0.putExtra("update", 1); 5 p4.startService(v0); 6 return; 7 } Listing A.2 – Code appel´e `a la r´eception d’un Intent par les composants de type Receiver d’un ´echantillon de BadNewsA.2. BADNEWS 137 Figure A.1 – Extrait du graphe d’appel de fonction d’un ´echantillon de BadNews138ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´ 1 private void sendRequest(String p24) { 2 v12 = android.net.Proxy.getDefaultHost(); 3 v13 = android.net.Proxy.getDefaultPort(); 4 v4 = new java.net.URL(p24); 5 if(v13 <= 0) { 6 v5 = v4.openConnection(); 7 } else { 8 v5 = v4.openConnection(new java.net.Proxy(java.net.Proxy$Type.HTTP, 9 new java.net.InetSocketAddress(v12, v13))); 10 } 11 v5.setDoInput(1); 12 v5.setDoOutput(1); 13 v5.setRequestMethod("POST"); 14 v5.setConnectTimeout(10000); 15 this.tmett = (System.currentTimeMillis() / 1000.0); 16 v18 = new java.io.DataOutputStream(v5.getOutputStream()); 17 v18.writeBytes(new StringBuilder("kurok=").append(this.ii) 18 .append("&taket=").append(this.pacNme).append("&phone=") 19 .append(this.phoNum).append("&vesn=").append(this.vesn) 20 .append("&sysname=").append(this.syNm).append("&operator=") 21 .append(this.opNm).append("&sdk=") 22 .append(android.os.Build$VERSION.SDK).append("&tmett=") 23 .append(this.tmett, 1000.0).append("&model=").append(this.phMl) 24 .append("&lg=").append(this.lg).append("&io=").append(this.io) 25 .append("&qyNm=").append(this.qyNm).append("&devicesid=") 26 .append(android.provider.Settings$Secure.getString(this 27 .getBaseContext().getContentResolver(), "android_id")) 28 .toString()); 29 v18.flush(); v18.close(); v5.connect(); 30 v6 = v5.getInputStream(); 31 if(v6 != 0) { 32 this.increaseQueryNum(); 33 v19 = new java.io.InputStreamReader; 34 v19(v6, "UTF-8"); 35 v14 = new java.io.BufferedReader(v19); 36 v3 = new StringBuilder(); 37 while(true) { 38 v8 = v14.readLine(); 39 if(v8 == 0) break; 40 v3.append(v8).append("\x0a"); 41 } 42 v16 = new org.json.JSONTokener; 43 v16(v3.toString()); 44 v7 = new org.json.JSONObject(v16); 45 v15 = v7.getString("status"); 46 if(v15.equalsIgnoreCase("news") != 0) { 47 this.parseNews(v7); 48 } 49 if(v15.equalsIgnoreCase("install") != 0) { 50 this.parseInstall(v7); 51 } 52 ... Listing A.3 – Extrait du code de la m´ethode sendRequest d’un ´echantillon de BadNewsA.2. BADNEWS 139 1 public int onStartCommand(android.content.Intent p3, int p4, int p5) { 2 this.log("AdvService Started"); 3 if(p3 == 0) { 4 this.startUpdater(); 5 } else { 6 if(p3.getExtras() == 0) { 7 this.startUpdater(); 8 } else { 9 if(p3.getExtras().getBoolean("update") != 0) { 10 this.startUpdateThread(); 11 } 12 } 13 } 14 return 1; 15 } 16 17 private void startUpdateThread() { 18 new Thread(new com.mobidisplay.advertsv1.AdvService$1(this)).start(); 19 return; 20 } Listing A.4 – Code appel´e `a l’ex´ecution du composant AdvService d’un ´echantillon de BadNews140ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´ A.3 DroidKungFu1 DroidKungFu1 [61] est un malware d´ecouvert en 2011. Certains de ses ´echantillons n’ex´ecutent pas automatiquement le code malveillant d`es le lancement de l’application dans laquelle ils se trouvent. Nous avons ainsi analys´e l’un des ´echantillons de ce malware 4 afin de trouver l’´ev`enement d´eclenchant le code malveillant. Selon l’analyse qui en a ´et´e r´ealis´ee par X. Jiang dans [61], le code malveillant du malware est stock´e dans un service qui est ajout´e `a des applications existantes pour infecter les utilisateurs. Les captures effectu´ees dans le rapport montrent que le service en question s’appellerait com.google.searchservice et que l’envoi de donn´ees sensibles vers l’ext´erieur et l’installation de nouvelles applications se font respectivement grˆace aux fonctions doSearchReport et cpLegacyRes. L’analyse du fichier AndroidManifest.xml, listing A.5, confirme qu’un tel service existe dans l’application et une analyse rapide du code de ce composant indique la pr´esence de ces deux m´ethodes. Il reste ainsi `a d´eterminer comment ces m´ethodes sont appel´ees. Comme dans le cas de BadNews, nous construisons le graphe d’appel de fonction de l’application pour identifier comment ces m´ethodes sont appel´ees. La figure A.2 est un extrait du graphe d’appel et indique que les deux m´ethodes sont appel´ees durant la cr´eation du composant SearchService, plus pr´ecis´ement par la m´ethode onCreate de ce composant. L’analyse du code de cette m´ethode, listing A.6, indique que l’ex´ecution de l’attaque ne se fait qu’apr`es un laps de temps. A la cr´eation du composant, l’application r´ecup`ere la valeur du pa- ` ram`etre start dans ses pr´ef´erences et la compare avec le temps du syst`eme. Si la diff´erence est inf´erieure `a 14400000.0ms alors l’attaque n’est pas lanc´ee et la valeur de start est initialis´ee au temps du syst`eme. Dans le cas contraire, l’attaque est lanc´ee. La condition pour que l’attaque soit ex´ecut´ee est ainsi qu’au moins 14400000.0ms se soit ´ecoul´e depuis le changement de la valeur du param`etre start. Ce param`etre est stock´e dans le fichier sstimestamp.xml, voir listing A.7, situ´e dans un sous-r´epertoire du r´epertoire local de l’application. En modifiant sa valeur, nous pouvons ainsi faire croire `a l’application que plus de 14400000.0ms s’est ´ecoul´e et forcer l’ex´ecution du code malveillant. 4. MD5 : 7f5fd7b139e23bed1de5e134dda3b1caA.3. DROIDKUNGFU1 141 Figure A.2 – Extrait du graphe d’appel de fonction d’un ´echantillon de DroidKungFu142ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´ 1 2 4 5 6 7 8 9 10 13 14 15 16 17 18 19 20 21 Listing A.5 – Extrait du contenu du fichier AndroidManifest.xml d’un ´echantillon de DroidKungFu1 1 public void onCreate() { 2 super.onCreate(); 3 v5 = this.getSharedPreferences("sstimestamp", 0); 4 v3 = v5.getLong("start", 0.0, v8); 5 v0 = System.currentTimeMillis(); 6 if(v3 != 0.0) { 7 if((v0 - v3) >= 14400000.0) { 8 this.mPreferences = this.getSharedPreferences("permission", 0); 9 if(com.google.ssearch.Utils.isConnected(this) != 0) { 10 this.doSearchReport(); 11 } 12 this.getPermission(); 13 this.provideService(); 14 } else { 15 this.stopSelf(); 16 } 17 } else { 18 v2 = v5.edit(); 19 v2.putLong("start", v0, v1); 20 v2.commit(); 21 this.stopSelf(); 22 } 23 return; 24 } Listing A.6 – M´ethode onCreate du composant SearchService d’un ´echantillon de DroidKungFu1A.3. DROIDKUNGFU1 143 1 2 Listing A.7 – Contenu du fichier sstimestamp.xml d’un ´echantillon de DroidKungFu1144ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´ A.4 DroidKungFu2 DroidKungFu2 [60] est un malware d´ecouvert en 2011 et consid´er´e comme ayant ´et´e ´ecrit par le mˆeme groupe de d´eveloppeurs que DroidKungFu1. Le rapport sur son analyse indique qu’ils ont d’ailleurs un comportement similaire car ils exploitent tous deux des vuln´erabilit´es dans le syst`eme pour ´elever leur privil`eges et installer de nouvelles applciations sur le t´el´ephone. La diff´erence entre les attaques sont les applications qu’ils installent sur le t´el´ephone. En analysant un des ´echantillons de DroidKungFu2 5 , nous remarquons rapidement que leur mode d’ex´ecution est le mˆeme. Voir listing A.8. Dans DroidKungFu2, le code malveillant est ´ex´ecut´e lors de la cr´eation d’un service et sous la condition qu’un certain temps se soit ´ecoul´e. Nous pouvons aussi d’ailleurs remarquer que le nom de certaines m´ethodes appel´ees sont exactement les mˆemes (ex : getPermission). Il suffit de modifier la valeur du param`etre start dans sstimestamp.xml pour faire ainsi croire `a l’application que plus de 1800000.0ms se sont ´ecoul´ees et forcer l’ex´ecution du code malveillant. 1 public void onCreate() { 2 super.onCreate(); 3 v5 = this.getSharedPreferences("sstimestamp", 0); 4 v3 = v5.getLong("start", 0.0, v8); 5 v0 = System.currentTimeMillis(); 6 if(v3 != 0.0) { 7 if((v0 - v3) >= 1800000.0) { 8 this.mPreferences = this.getSharedPreferences("permission", 0); 9 this.updateInfo(); 10 this.getPermission(); 11 this.provideService(); 12 } else { 13 this.stopSelf(); 14 } 15 } else { 16 v2 = v5.edit(); 17 v2.putLong("start", v0, v1); 18 v2.commit(); 19 this.stopSelf(); 20 } 21 return; 22 } Listing A.8 – M´ethode onCreate d’un composant service d’un ´echantillon de DroidKungFu2 5. MD5 : f438ed38b59f772e03eb2cab97fc7685A.5. JSMSHIDER 145 A.5 jSMSHider Les ´echantillons de jSMSHider ex´ecutent tous leur code malveillant d`es le lancement de l’application. Il n’y a ainsi nul besoin d’introduire manuellement des ´ev`enements dans le syst`eme.146ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´Publications V Viet Triem Tong, R Andriatsimandefitra, S Geller, S Boche, F Tronel, C Hauser. Mise en œuvre de politiques de protection des flux d’information dans l’environnement Android. Computer & Electronics Security Applications Rendezvous, 2011. Rennes, France. Radoniaina Andriatsimandefitra, St´ephane Geller, Val´erie Viet Triem Tong. Designing information flow policies for android’s operating system. IEEE International Conference on Communications, 2012 (ICC 2012). Ottawa, Canada R Andriatsimandefitra, V. Viet Triem Tong, L M´e. Diagnosing intrusions in Android operating system using system flow graph. Workshop Interdisciplinaire sur la S´ecurit´e Globale, 2013 (WISG 2013). Troyes, France. M Jaume, R Andriatsimandefitra, V. Viet Triem Tong, L M´e. Secure States versus Secure Executions. 9th International Conference on Information Systems Security, 2013 (ICISS 2013). Kolkata, India. R Andriatsimandefitra, V Viet Triem Tong, T Saliou. Information Flow Policies vs Malware. International Conference on Information Assurance and Security, 2013 (IAS 2013). Yassmine Hammamet, Tunisia. R Andriatsimandefitra and V Viet Triem Tong. Capturing Android Malware Behaviour using System Flow Graph. The 8th International Conference on Network and System Security, 2014 (NSS 2014). Xi’an, China R Andriatsimandefitra, V Viet Triem Tong, T Saliou. Information Flow Policies vs Malware – Final Battle - . Journal of Information Assurance and Security, Dynamic Publishers Inc., USA, 2014, 9 (2), pp.72-82. R Andriatsimandefitra, V Viet Triem Tong. Poster Abstract : Highlighting Easily How Malicious Applications Corrupt Android Devices. Research in Attacks, Intrusions and Defenses, 2014 (RAID 2014). Gothenburgh, Sweden. 147148 PUBLICATIONSBibliographie [1] Android-root 2009-08-16 source. http://www.zenthought.org/ content/file/android-root-2009-08-16-source. [2] Andrototal. http://andrototal.org. [3] Bionic (software). http://en.wikipedia.org/wiki/Bionic_ %28software%29. [4] Cve-2009-2692. http://web.nvd.nist.gov/view/vuln/detail? vulnId=CVE-2009-2692. [5] Cve-2013-6282. http://cve.mitre.org/cgi-bin/cvename.cgi?name= CVE-2013-6282. [6] dedexer. http://dedexer.sourceforge.net/. [7] droidbox. android application sandbox. https://code.google.com/p/ android-apktool/. [8] F1 score. https://en.wikipedia.org/wiki/F-score. [9] Ida pro. https://www.hex-rays.com/products/ida/. [10] Java decompiler. http://jd.benow.ca/. [11] Netlink protocol library suite (libnl). http://www.carisma.slowglass. com/~tgr/libnl. [12] Programmation java/r´eflexion. http://fr.wikibooks.org/wiki/ Programmation_Java/R%C3%A9flexion. [13] smali, an assembler/disassembler for android’s dex format. https:// code.google.com/p/smali/. [14] Virustotal. https://www.virustotal.com/. [15] dm-crypt. http://git.kernel.org/cgit/linux/kernel/git/ torvalds/linux.git/tree/Documentation/device-mapper/ dm-crypt.txt, 2014. [16] Radoniaina Andriatsimandefitra, St´ephane Geller, and Val´erie Viet Triem Tong. Designing information flow policies for android’s operating system. In IEEE International Conference on Communications, 2012. [17] Radoniaina Andriatsimandefitra and Val´erie Viet Triem Tong. Capturing Android Malware Behaviour using System Flow Graph. In NSS 2014 - The 8th International Conference on Network and System Security, Xi’an, China, October 2014. 149150 BIBLIOGRAPHIE [18] Radoniaina Andriatsimandefitra, Val´erie Viet Triem Tong, and Ludovic M´e. Diagnosing intrusions in android operating system using system flow graph. In Workshop Interdisciplinaire sur la S´ecurit´e Globale, 2013. [19] Radoniaina Andriatsimandefitra, Val´erie Viet Triem Tong, and Thomas Saliou. Information flow policies vs malware–final battle–. Journal of Information Assurance and Security, 9(2) :72–82, 2014. [20] Radoniaina Andriatsimandefitra, Val´erie Viet Viet Triem Tong, and Thomas Saliou. Information flow policies vs malware. In Information assurance and security - 2013, 2013. [21] Andrew W. Appel. Deobfuscation is in np, aug 2002. [22] Daniel Arp, Michael Spreitzenbarth, Malte H¨ubner, Hugo Gascon, Konrad Rieck, and CERT Siemens. Drebin : Effective and explainable detection of android malware in your pocket. In NDSS 2014, 2014. [23] Arini Balakrishnan and Chloe Schulze. Code obfuscation literature survey. Technical report, Computer Sciences Department - University of Wisconsin, Madison, 2005. CS701 Construction of Compilers, Instructor : Charles Fischer. [24] Alastair R. Beresford, Andrew Rice, Nicholas Skehin, and Ripduman Sohan. Mockdroid : trading privacy for application functionality on smartphones. In Proceedings of the 12th Workshop on Mobile Computing Systems and Applications, 2011. [25] Thomas Blasing, Leonid Batyuk, A-D Schmidt, Seyit Ahmet Camtepe, and Sahin Albayrak. An android application sandbox system for suspicious software detection. In Malicious and unwanted software (MALWARE), 2010 5th international conference on, pages 55–62. IEEE, 2010. [26] Ohad Bobrov. Chinese government targets hong kong protesters with android mrat spyware. https://www.lacoon.com/ chinese-government-targets-hong-kong-protesters-android-mrat-spyware/, 2014. [27] Dan Boneh and Matt Franklin. Identity-based encryption from the weil pairing. In Advances in Cryptology—CRYPTO 2001, pages 213–229. Springer, 2001. [28] Joany Boutet and Tom Leclerc. Grand theft android : Phishing with permission. http://sagsblog.telinduslab.lu/index.php/ post/201309%5CS-Team-at-Hacklu-2013%3A-GRAND-THEFT-ANDROID% 3A-PHISHING-WITH-PERMISSION, 2013. [29] Sven Bugiel, Lucas Davi, Alexandra Dmitrienko, Thomas Fischer, and Ahmad-Reza Sadeghi. Xmandroid : A new android evolution to mitigate privilege escalation attacks. Technical report, Technische Universitat Darmstadt, Center for Advanced Security Research Darmstadt, 2011. [30] Sven Bugiel, Stephan Heuser, and Ahmad-Reza Sadeghi. mytunes : Semantically linked and user-centric fine-grained privacy control on android. Technical report, CASED, 2012.151 [31] C-Skills. Android trickery. http://c-skills.blogspot.fr/2010/07/ android-trickery.html, 2010. [32] C-skills. Yummy yummy, gingerbreak ! http://c-skills.blogspot.fr/ 2011/04/yummy-yummy-gingerbreak.html, 2011. [33] Victor Chebyshev and Roman Unuchek. Mobile malware evolution : 2013, 02 2014. [34] Erika Chin, Adrienne Porter Fell, Kate Greenwood, and David Wagner. Analyzing inter-application communication in android. In MobiSys’11, 2011. [35] Mihai Christodorescu and Somesh Jha. Static analysis of executables to detect malicious patterns. In Proceedings of the 12th conference on USENIX Security Symposium - Volume 12, SSYM’03, pages 12–12, Berkeley, CA, USA, 2003. USENIX Association. [36] Fred Chung. Custom class loading in dalvik, July 2011. [37] CIDRE. Blare ids. www.blare-ids.org. [38] CIDRE. Git repositories of blare. https://git.blare-ids.org. [39] Christian Collberg, Clark Thomborson, and Douglas Low. A taxonomy of obfuscating transformations. Technical report, University of Auckland, 1997. [40] Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Linux Device Drivers. O’Reilly Media, third edition edition, 2005. [41] Nello Cristianini and John Shawe-Taylor. An Introduction to Support Vector Machines : And Other Kernel-based Learning Methods. Cambridge University Press, New York, NY, USA, 2000. [42] Anthony Desnos and Geoffroy Gueguen. Android : From reversing to decompilation. Technical report, Black Hat Abu Dhabi 2011, 2011. [43] dex2jar team. dex2jar tools to work with android .dex and java .class files. https://code.google.com/p/dex2jar/. [44] Thomas Eder, Michael Rodler, Dieter Vymazal, and Markus Zeilinger. Ananas-a framework for analyzing android applications. In Availability, Reliability and Security (ARES), 2013 Eighth International Conference on, pages 711–719. IEEE, 2013. [45] Petros Efstathopoulos, Maxwell Krohn, Steve VanDeBogart, Cliff Frey, David Ziegler, Eddie Kohler, David Mazieres, Frans Kaashoek, and Robert Morris. Labels and event processes in the asbestos operating system. In ACM SIGOPS Operating Systems Review, 2005. [46] William Enck, Peter Gilbert, Byung gon Chun, Landon P. Cox, Jaeyeon Jung, Patrick McDaniel, and Anmol N. Sheth. Taintdroid : An information-flow tracking system for realtime privacy monitoring on smartphones. In In Proc. of the USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2010.152 BIBLIOGRAPHIE [47] William Enck, Machigar Ongtang, and Patrick Mcdaniel. Mitigating android software misuse before it happens. Technical report, The Pennsylvania State University, 2008. [48] Rong-En Fan, Kai-Wei Chang, Cho-Jui Hsieh, Xiang-Rui Wang, and ChihJen Lin. Liblinear : A library for large linear classification. The Journal of Machine Learning Research, 9 :1871–1874, 2008. [49] Adrienne Porter Felt, Helen J. Wang, Alexander Moshchuk, Steven Hanna, and Erika Chin. Permission re-delegation : Attacks and defenses. In Proceedings of the 20th USENIX Conference on Security, SEC’11. USENIX Association, 2011. [50] Eric Filiol. Metamorphism, formal grammars and undecidable code mutation. J. Comp. Sci, pages 70–75, 2007. [51] Jeff Forristal. Android : One root to own them all, 2013. [52] Linux Foundation. Generic netlink howto. http://www. linuxfoundation.org/collaborate/workgroups/networking/ generic_netlink_howto, 2009. [53] Linux Foundation. iproute2. http://www.linuxfoundation.org/ collaborate/workgroups/networking/iproute2, 2009. [54] Debin Gao, Michael K. Reiter, and Dawn Song. Gray-box extraction of execution graphs for anomaly detection. In Proceedings of the 11th ACM conference on Computer and communications security, pages 318– 329, 2004. [55] St´ephane Geller. Information flow and execution policy for a model of detection without false negatives. Network and Information Systems Security (SAR-SSI), 2011 Conference on, 2011. [56] St´ephane Geller, Christophe Hauser, Fr´ed´eric Tronel, and Val´erie Viet Triem Tong. Information flow control for intrusion detection derived from mac policy. In IEEE International Conference on Communications, 2011. [57] St´ephane Geller, Val´erie Viet Triem Tong, and Ludovic M´e. Bspl : A language to specify and compose fine-grained information flow policies. In SECURWARE 2013, The Seventh International Conference on Emerging Security Information, Systems and Technologies, 2013. [58] Kent Griffin, Scott Schneider, Xib Hu, and Tzi cker Chiueh. Automatic generation of string signatures for malware detection. In Proceedings of the 12th International Symposium on Recent Advances in Intrusion Detection (RAID 2009), 2009. [59] Peter Hornyack, Seungyeop Han, Jaeyeon Jung, Stuart Schechter, and David Wetherall. “these aren’t the droids you’re looking for” : Retrofitting android to protect data from imperious applications. In CCS’11, 2011. [60] Xuxian Jiang. Security alert : New droidkungfu variants found in alternative chinese android markets. http://www.csc.ncsu.edu/faculty/ jiang/DroidKungFu2/.153 [61] Xuxian Jiang. Security alert : New sophisticated android malware droidkungfu found in alternative chinese app markets. http://www.csc.ncsu. edu/faculty/jiang/DroidKungFu.html. [62] Xuxian Jiang. Questionable android apps – sndapps – found and removed from official android market. http://www.csc.ncsu.edu/faculty/ jiang/SndApps/, 2011. [63] Kevin Kaichuan He. Kernel korner - why and how to use netlink socket. http://www.linuxjournal.com/article/7356, 2005. [64] Ariane Keller. Kernel space - user space interfaces. http://people.ee. ethz.ch/~arkeller/linux/kernel_user_space_howto.html. [65] Michael Kerris. The linux programming interfaces - posix message queues. http://man7.org/tlpi/download/TLPI-52-POSIX_Message_ Queues.pdf. [66] Samuel T. King and Peter M. Chen. Backtracking intrusions. In Proceedings of the nineteenth ACM symposium on Operating systems principles, pages 223–236, Bolton Landing, NY, October 2003. ACM Press. [67] Christopher Kruegel, Engin Kirda, Paolo Milani Comparetti, Ulrich Bayer, and Clemens Hlauschek. Scalable, behavior-based malware clustering. In Proceedings of the 16th Annual Network and Distributed System Security Symposium (NDSS 2009), 1 2009. [68] Mohit Kumar. Dynamic analysis tools for android fail to detect malware with heuristic evasion techniques. http://thehackernews.com/2014/05/ dynamic-analysis-tools-for-android-fail.html, 2014. [69] International Secure Systems Lab. Anubis - malware analysis for unknown binaries. http://anubis.iseclab.org/. [70] Cullen Linn and Saumya Debray. Obfuscation of executable code to improve resistance to static disassembly. In CCS ’03 : Proceedings of the 10th ACM conference on Computer and communications security, pages 290–299, New York, NY, USA, 2003. ACM. [71] Radmon Llamas, Melissa Chau, and Michael Shirer. Worldwide smartphone market grows 28.6% year over year in the first quarter of 2014, according to idc. http://www.idc.com/getdoc.jsp?containerId= prUS24823414, 2014. [72] Lisa Mahapatra. Android vs. ios : What’s the most popular mobile operating system in your country ? http://www.ibtimes.com/ android-vs-ios-whats-most-popular-mobile-operating-system-your-country-1464892, 2013. [73] Andrew C. Myers and Barabara Liskov. Complete, safe information flow with decentralized labels. In IEEE Symposium on Security and Privacy, 1998. [74] Andrew C. Myers and Barbara Liskov. A decentralized model for information flow control. SIGOPS Oper. Syst. Rev., 31(5) :129–142, 1997.154 BIBLIOGRAPHIE [75] Andrew C. Myers and Barbara Liskov. Protecting privacy using the decentralized label model. ACM Trans. Softw. Eng. Methodol., 9(4) :410–442, 2000. [76] Pablo Neira-Ayuso, Rafael M Gasca, and Laurent Lefevre. Communicating between the kernel and user-space in linux using netlink sockets. Software : Practice and Experience, 40, 2010. [77] Sebastian Neuner, Victor van der Veen, Martina Lindorfer, Markus Huber, Georg Merzdovnik, Martin Mulazzani, and Edgar Weippl. Enter sandbox : Android sandbox comparison. Proceedings of the IEEE. [78] Jon Oberheide and Charlie Miller. Dissecting the android bouncer, 2012. Summercon. [79] Machigar Ongtang, Stephen McLaughlin, William Enck, and Patrick McDaniel. Semantically rich application-centric security in android. In Annual Computer Security Applications Conference, volume 0, pages 340– 349, Los Alamitos, CA, USA, 2009. IEEE Computer Society. [80] Xinming Ou, Wayne F Boyer, and Miles A McQueen. A scalable approach to attack graph generation. In Proceedings of the 13th ACM conference on Computer and communications security, pages 336–345. ACM, 2006. [81] PalmSource. Openbinder. http://www.angryredplanet.com/~hackbod/ openbinder/docs/html/index.html. [82] Mila Parkour. Contagio mobile. contagiominidump.blogspot.com. [83] Android Open Source Project. Device administration. https:// developer.android.com/guide/topics/admin/device-admin.html. [84] Android Open Source Project. Intent. http://developer.android.com/ reference/android/content/Intent.html#setFlags%28int%29. [85] Android Open Source Project. Introducing art. http://source.android. com/devices/tech/dalvik/art.html. [86] Android Open Source Project. Jni tips. http://developer.android. com/training/articles/perf-jni.html. [87] Android Open Source Project. Pro guard. http://developer.android. com/tools/help/proguard.html. [88] Alessandro Reina, Aristide Fattori, and Lorenzo Cavallaro. A system callcentric analysis and stimulation technique to automatically reconstruct android malware behaviors. EuroSec, April, 2013. [89] Konrad Rieck, Thorsten Holz, Carsten Willems, Patrick D¨ussel, and Pavel Laskov. Learning and classification of malware behavior. In Proceedings of the 5th international conference on Detection of Intrusions and Malware, and Vulnerability Assessment, DIMVA ’08, pages 108–125, Berlin, Heidelberg, 2008. Springer-Verlag. [90] Konrad Rieck, Philipp Trinius, Carsten Willems, and Thorsten Holz. Automatic analysis of malware behavior using machine learning. J. Comput. Secur., December 2011.155 [91] Marc Rogers. The bearer of badnews. https://blog.lookout.com/ blog/2013/04/19/the-bearer-of-badnews-malware-google-play/, 2013. [92] Sebastian. Droid2. http://c-skills.blogspot.fr/2010/08/droid2. html, 2010. [93] Sebastian. Zimperlich sources. http://c-skills.blogspot.fr/2011/ 02/zimperlich-sources.html, 2011. [94] Michael Spreitzenbarth, Felix Freiling, Florian Echtler, Thomas Schreck, and Johannes Hoffmann. Mobile-sandbox : having a deeper look into android applications. In Proceedings of the 28th Annual ACM Symposium on Applied Computing, pages 1808–1815. ACM, 2013. [95] Tim Starzzere. Security alert : Legacy makes another appearance, meet legacy native (lena). https://blog.lookout.com/blog/2011/10/20/, 2011. [96] Tim Strazzere. June 15, 2011 security alert : Malware found targeting custom roms (jsmshider). https://blog.lookout.com/ blog/2011/06/15/security-alert-malware-found-targeting\ discretionary{-}{}{}custom-roms-jsmshider/. [97] Androguard team. Reverse engineering, malware and goodware analysis of android applications ... and more (ninja !). https://code.google.com/ p/androguard/. [98] Roman Unuchek. The most sophisticated android trojan. https: //www.securelist.com/en/blog/8106/The_most_sophisticated_ Android_Trojan, June 2013. [99] Marko Vitas. Art vs dalvik - introducing the new android runtime in kitkat. http://www.infinum.co/the-capsized-eight/articles/ art-vs-dalvik-introducing-the-new-android-runtime-in-kit-kat. [100] Lukas Weichselbaum, Matthias Neugschwandtner, Martina Lindorfer, Yanick Fratantonio, Victor van der Veen, and Christian Platzer. Andrubis : Android malware under the magnifying glass. Technical report, Vienna University of Technology, 2014. [101] Carsten Willems, Thorsten Holz, and Felix Freiling. Toward automated dynamic malware analysis using cwsandbox. IEEE Security and Privacy, 5(2) :32–39, mar 2007. [102] Chris Wright, Crispin Cowan, and James Morris. Linux security modules : General security support for the linux kernel, 2002. [103] Chris Wright, Crispin Cowan, Stephen Smalley, James Morris, and Greg Kroah-Hartman. Linux security module framework. In OLS2002 Proceedings, 2002. [104] Tim Wyatt. Security alert : New variants of legacy native (lena) identified. http://blog.lookout.com/blog/2012/04/03/ security-alert-new-variants-of-legacy-native-lena-identified/, 2013.156 BIBLIOGRAPHIE [105] Rubin Xu, Hassen Saidi, and Ross Anderson. Aurasium : Practical policy enforcement for android applications. In USENIX Security ’12, 2012. [106] Lok-Kwong Yan and Heng Yin. Droidscope seamlessly reconstructing os and dalvik semantic views for dynamic android malware analysis. In Proceedings of the 21st USENIX Security Symposium, August 2012. [107] Jay Yarow. This chart shows google’s incredible domination of the world’s computing platforms. http://www.businessinsider.com/ androids-share-of-the-computing-market-2014-3, 2014. [108] Heng Yin, Dawn Song, Manuel Egele, Christopher Kruegel, and Engin Kirda. Panorama : capturing system-wide information flow for malware detection and analysis. In CCS ’07 : Proceedings of the 14th ACM conference on Computer and communications security, pages 116–127, New York, NY, USA, 2007. ACM. [109] Nickolai Zeldovich, Silas Boyd-Wickizer, Eddie Kohler, and David Mazi`eres. Making information flow explicit in histar. In OSDI ’06 : Proceedings of the 7th symposium on Operating systems design and implementation, pages 263–278, Berkeley, CA, USA, 2006. USENIX Association. [110] Nickolai Zeldovich, Silas Boyd-Wickizer, and David Mazi`eres. Securing distributed systems with information flow control. In NSDI’08 : Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation, pages 293–308. USENIX Association, 2008. [111] Cong Zheng, Shixiong Zhu, Shuaifu Dai, Guofei Gu, Xiaorui Gong, Xinhui Han, and Wei Zou. Smartdroid : an automatic system for revealing uibased trigger conditions in android applications. In Proceedings of the second ACM workshop on Security and privacy in smartphones and mobile devices, pages 93–104. ACM, 2012. [112] Yajin Zhou and Xuxian Jiang. An analysis of the anserverbot trojan. Technical report, NQ Mobile Security Research Center, 2011. [113] Yajin Zhou and Xuxian Jiang. Dissecting android malware : Characterization and evolution. In Proceedings of the 2012 IEEE Symposium on Security and Privacy, SP ’12, pages 95–109, Washington, DC, USA, 2012. IEEE Computer Society. Interaction entre alg`ebre lin´eaire et analyse en formalisation des math´ematiques Guillaume Cano To cite this version: Guillaume Cano. Interaction entre alg`ebre lin´eaire et analyse en formalisation des math´ematiques. Other. Universit´e Nice Sophia Antipolis, 2014. French. . HAL Id: tel-00986283 https://tel.archives-ouvertes.fr/tel-00986283 Submitted on 2 May 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.UNIVERSITÉ DE NICE - SOPHIA ANTIPOLIS ÉCOLE DOCTORALE STIC SCIENCES ET TECHNOLOGIES DE L’INFORMATION ET DE LA COMMUNICATION THÈSE pour l’obtention du grade de Docteur en Sciences de l’Université de Nice - Sophia Antipolis Mention : Informatique Présentée et soutenue par Guillaume CANO Interaction entre algèbre linéaire et analyse en formalisation des mathématiques Thèse dirigée par Yves BERTOT soutenue le 4 avril 2014 Jury : Micaela MAYERO - Maître de conférence, LIPN (Rapporteur) Julio RUBIO - Professeur, Université de la Rioja (Rapporteur) Yves BERTOT - Directeur de recherche, INRIA (Directeur) Stephen Watt - Professeur, Université Ontario Ouest (Examinateur) Christine PAULIN-MOHRING - Professeur, Université Paris Sud (Examinateur) Douglas HOWE - Professeur, Université Carlton (Examinateur)Abstract In this thesis we present the formalization of three principal results that are the Jordan normal form of a matrices, the Bolzano-Weierstraß theorem, and the Perron-Frobenius theorem. To formalize the Jordan normal form, we introduce many concepts of linear algebra like block diagonal matrices, companion matrices, invariant factors, ... The formalization of Bolzano-Weierstraß theorem needs to develop some theory about topological space and metric space. The Perron-Frobenius theorem is not completly formalized. The proof of this theorem uses both algebraic and topological results. We will show how we reuse the previous results. Résumé Dans cette thèse nous présentons la formalisation de trois résultats principaux que sont la forme normale de Jordan d’une matrice, le théorème de Bolzano-Weierstraß et le théorème de Perron-Frobenius. Pour la formalisation de la forme normale de Jordan nous introduisons différents concepts d’algèbre linéaire tel que les matrices diagonales par blocs, les matrices compagnes, les facteurs invariants, ... Ensuite nous définissons et développons une théorie sur les espaces topologiques et métriques pour la formalisation du théorème de BolzanoWeierstraß. La formalisation du théorème de Perron-Frobenius n’est pas terminé. La preuve de ce théorème utilise des résultat d’algèbre linéaire, mais aussi de topologie. Nous montrerons comment les précédents résultats seront réutilisés.Remerciements Je voudrais dans un premier temps remercier Micaela Mayero et Julio Rubio pour avoir acceptés d’endurer l’épreuve d’être les rapporteurs de cette thèse. Je remercie mon directeur de thèse Yves Bertot pour m’avoir permis de faire cette thèse, mais aussi pour les moments patisserie. Je tiens à remercier aussi toute l’équipe Marelle pour son soutient. Je remercie Nathalie Bellesso qui est une secrétaire merveilleuse, qui m’a aidée dans mes tâches administratives et qui en plus écrit de bons livres. Je remercie José Grimm pour ces conseils TEXniques, Laurent Théry pour son soutient, ses conseils et ses casse-têtes. Et surtout un grand merci à Laurence Rideau qui a passé beaucoup de temps à m’apprendre SSReflect, à relire mes écrits, à corriger mes fautes réccurentes, qui a aussi eu la patience de me supporter, et aussi qui m’a encouragé, grondé et motivé tout au long de ma thèse. Je remercie également ceux qui ont passés du temps à la relecture de ma thèse, et que j’ai déjà cités. Merci également à Ioana Paşca qi m’a beaucoup appris, en particulier une chose absolument fondamentale : le chocolat, au bureau, c’est important ! Merci à Tom Hutchinson dont j’ai apprécié la compagnie et les conversations. Merci aussi à Cyril Cohen, Maxime Dénès, Érik Martin-Dorel, Anders Mörtberg. Merci à ceux que j’ai oubliés. Je remercie aussi ma famille pour son soutient à toute épreuve. Et je voudrais rendre hommage à Pierre Damphousse, sans qui je n’aurais jamais fait cette thèse.Table des matières Introduction 1 1 Preuve formelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Assistants de preuve . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Brève présentation de Coq . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Les Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Motivations générales . . . . . . . . . . . . . . . . . . . . . 5 4.2 Motivations de la thèse . . . . . . . . . . . . . . . . . . . . 6 5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1 Contexte 9 1.1 Les types de base . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1.1 Le type produit . . . . . . . . . . . . . . . . . . . . . . . . 10 1.1.2 Les types propositionnels . . . . . . . . . . . . . . . . . . . 10 1.1.3 Le type booléen . . . . . . . . . . . . . . . . . . . . . . . . 10 1.1.4 Les entiers naturels . . . . . . . . . . . . . . . . . . . . . . 11 1.1.5 Les séquences . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 La bibliothèque SSReflect . . . . . . . . . . . . . . . . . . . . . 12 1.2.1 La réflexion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.2 Le système de vue . . . . . . . . . . . . . . . . . . . . . . 14 1.2.3 Les types avec une égalité décidable . . . . . . . . . . . . . 15 1.2.4 Les types finis . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2.5 Les opérateurs de familles . . . . . . . . . . . . . . . . . . 16 1.2.6 Les structures algébriques . . . . . . . . . . . . . . . . . . 18 1.2.7 Les polynômes . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2.8 Les matrices . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2.9 Matrices et polynômes . . . . . . . . . . . . . . . . . . . . 22 1.2.10 Les structures ordonnées . . . . . . . . . . . . . . . . . . . 23 1.2.11 Les nombres complexes . . . . . . . . . . . . . . . . . . . . 24 1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2 Forme de Jordan d’une matrice 25 2.1 Matrices diagonales par blocs . . . . . . . . . . . . . . . . . . . . 25 2.1.1 Définition idéale . . . . . . . . . . . . . . . . . . . . . . . . 26vi Table des matières 2.1.2 Problèmes en dimension nulle . . . . . . . . . . . . . . . . 29 2.1.3 Définition finale . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2 Matrices semblables et équivalentes . . . . . . . . . . . . . . . . . 31 2.2.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.2.2 Théorème fondamental . . . . . . . . . . . . . . . . . . . . 32 2.3 Forme normale de Smith . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.1 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.3.2 Unicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.3.3 Facteurs invariants . . . . . . . . . . . . . . . . . . . . . . 39 2.4 Forme normale de Frobenius . . . . . . . . . . . . . . . . . . . . . 40 2.4.1 Matrices compagnes . . . . . . . . . . . . . . . . . . . . . 40 2.4.2 De Smith à Frobenius . . . . . . . . . . . . . . . . . . . . 42 2.5 Forme normale de Jordan . . . . . . . . . . . . . . . . . . . . . . 44 2.5.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.5.2 De Frobenius à Jordan . . . . . . . . . . . . . . . . . . . . 45 2.5.3 Diagonalisation . . . . . . . . . . . . . . . . . . . . . . . . 48 2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.7 Travaux reliés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3 Topologie 51 3.1 Théorie des ensembles . . . . . . . . . . . . . . . . . . . . . . . . 51 3.1.1 Réécriture . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.1.2 Les familles d’ensembles . . . . . . . . . . . . . . . . . . . 53 3.2 Structures Topologiques . . . . . . . . . . . . . . . . . . . . . . . 55 3.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.2.2 Approche naïve . . . . . . . . . . . . . . . . . . . . . . . . 57 3.2.3 Approche SSReflect . . . . . . . . . . . . . . . . . . . . 59 3.3 Bolzano-Weierstraß . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.3.1 Topologie générale . . . . . . . . . . . . . . . . . . . . . . 62 3.3.2 Les suites . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.3.3 Le théorème . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.5 Travaux reliés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4 Perron-Frobenius 69 4.1 Rappels et définitions . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.1.1 Minimum et maximum . . . . . . . . . . . . . . . . . . . . 70 4.1.2 Éléments d’algèbre linéaire . . . . . . . . . . . . . . . . . . 71 4.2 Matrices strictement positives . . . . . . . . . . . . . . . . . . . . 73 4.2.1 Preuve du théorème principal . . . . . . . . . . . . . . . . 73 4.2.2 Instance des structures topologiques . . . . . . . . . . . . . 75 4.2.3 Preuve de l’axiome . . . . . . . . . . . . . . . . . . . . . . 77 4.3 Matrices à coefficients positifs ou nuls . . . . . . . . . . . . . . . . 80 4.3.1 La preuve . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Table des matières vii 4.3.2 Convergence des rayons spectraux . . . . . . . . . . . . . . 81 4.3.3 Compacité de la boule unité . . . . . . . . . . . . . . . . . 83 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.5 Travaux reliés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Conclusion 85 Bibliographie 87Introduction 1 Preuve formelle Formaliser un théorème, c’est difficile à définir formellement. Dans le mot “formelle” on a le mot “forme”. Une preuve formelle, serait donc une preuve qui manipule seulement des formes, des symboles, en faisant abstraction du sens que peuvent avoir ces symboles. Le mieux serait d’essayer de comprendre sur un exemple. Essayons de formaliser le résultat suivant : “Si nous avons un ensemble, avec une loi associative sur cet ensemble qui possède un élément neutre, et si un élément de l’ensemble possède un inverse à droite et un inverse à gauche, alors l’inverse à droite et l’inverse à gauche sont égaux”. Nous commencons d’abord par mettre en forme l’énoncé, c’est-à-dire l’exprimer à l’aide de symboles. Nous pouvons utiliser la lettre “E” pour désigner l’ensemble, le symbole “∗” pour la loi, et “e” pour son élément neutre. Nous pouvons formaliser le fait que la loi est associative et que e et un élément neutre par les hypothèses suivantes : hA : ∀xyz ∈ E,(x ∗ y) ∗ z = x ∗ (y ∗ z). n1 : ∀x ∈ E, x ∗ e = x. n2 : ∀x ∈ E, e ∗ x = x. Ensuite nous pouvons utiliser par exemple la lettre “a” pour désigner un élé- ment de E qui a un inverse à gauche et à droite que nous appellerons a1 et a2. Formellement, nous avons les deux hypothèses suivantes : ha1 : a ∗ a1 = e ha2 : a2 ∗ a = e et donc nous voulons prouver que a1 = a2. Nous avons pour l’instant décrit formellement les hypothèses de l’énoncé, ainsi que le but que nous voulons prouver. Nous pouvons maintenant prouver formellement que a1 = a2 en utilisant uniquement les hypothèses que nous avons formalisées.2 Introduction Nous avons donc a1 = e ∗ a1 = (a2 ∗ a) ∗ a1 = a2 ∗ (a ∗ a1) = a2 ∗ e = a2, en utilisant respectivement les hypothèses n2, ha2, hA, ha1, n1. Pour vérifier cette preuve, nous n’avons pas besoin de connaitre le sens des symboles. La première hypothèse utilisée est l’hypothèse n2. Si on regarde cette hypothèse, on s’aperçoit qu’il y a un signe “=” qui indique que la forme qu’il y a d’un coté de ce signe est équivalente à la forme qu’il y a de l’autre coté du signe, ainsi dans une expression nous pouvons remplacer l’une par l’autre. Donc l’hypothèse n2 dit que le dessin “a1” a la même forme que le dessin “e ∗ a1”. On n’a pas besoin de savoir à quoi correspond ∗ ou e, on a seulement besoin de savoir que l’on peut remplacer une expression par une autre, et donc on peut vérifier la preuve juste en comparant des dessins1 . C’est ce qu’on appelle une preuve formelle. Cette abstraction du sens des symboles que l’on manipule fait qu’une preuve formelle est généralement plus longue et détaillée qu’une preuve normale. En effet, dans une preuve mathématique, certaines choses sont considérées comme évidentes. Mais si l’on exprime ces choses à l’aide de symboles, et que l’on oublie le sens de ces symboles, alors en gros la seule trivialité qui reste est x = x. D’un autre côté, le fait de pouvoir faire des preuves en manipulant des symboles sans se préoccuper du sens fait que certaines choses peuvent se faire de manière automatique, et donc être faites par une machine. 2 Assistants de preuve Un assistant de preuve est un logiciel permettant de faire des preuves formelles. Il en existe de deux sortes : • Les assistants de preuve automatiques : ce sont des logiciels qui prouvent automatiquement les théorèmes. L’exemple utilisé ci-dessus serait très rapidement prouvé par un prouveur automatique. Pour prouver les théorèmes, le logiciel regarde parmi la liste des théorèmes qu’il a à sa disposition, lesquels il peut appliquer. Il essaye ensuite les lemmes qu’il peut appliquer. Pour chaque théorème appliqué, les conditions du théorème deviennent de nouveaux buts à prouver, il génère ainsi une sorte d’arbre de preuve. Si une branche de cet arbre termine, alors il annonce que le théorème est valide, sinon nous n’avons aucune information sur la validité du résultat que nous voulions prouver. Si l’on donne un théorème à un prouveur automatique, il répondra soit “c’est vrai” soit “je ne sais pas”, mais il n’indiquera pas comment il a prouvé le théorème. On peut cependant demander une trace de ce qu’il a fait, mais c’est rarement exploitable, on se sert géneralement de la trace pour voir quels théorèmes intermédiaires manquent à l’assistant de preuve pour valider la preuve. 1Enfin pas tout à fait. Dans cet exemple, il faut au moins connaître les symboles ∀, ∈, et =. Pour avoir une preuve formelle complète, il aurait fallu donner aussi les règles d’utilisation de ces symboles.3 Brève présentation de Coq 3 Ceci est une présentation assez grossière des assistants de preuve automatiques, on pourra trouver dans [6] ou dans [24] plus de détails sur les mécanismes utilisés. Les principaux prouveurs automatiques1 sont ACL2 [28, 29], Alt-Ergo [5], E-prover [44], Gappa [31], Z3 [11], ... • Les assistants de preuve semi-automatiques : contrairement aux assistants de preuve automatiques, les preuves sont faites par un utilisateur humain. L’utilisateur dit quel théorème il veut utiliser, et la machine indique si oui ou non le théorème peut être appliqué ou pas. Donc ici l’humain fait la preuve, et la machine la vérifie. Parmi les principaux assistants de preuve semiautomatique, on trouve HOL [35], HOL-Light [25], Isabelle [50], Coq [13], Mizar [33], Matita [1], PVS [45], Nuprl [10] ... Dans cette thèse nous utiliserons l’assistant de preuve Coq. 3 Brève présentation de Coq Le logiciel Coq est un assistant de preuve semi-automatique qui permet de faire des preuves, mais aussi des programmes (et des preuves sur ces programmes !). La construction de preuves se fait à l’aide d’un langage de tactiques. Une tactique c’est ce qui permet de dire au système quel règle logique utiliser pour construire les preuves. La formalisation des théorèmes en Coq se fait de manière interactive avec la machine. En général nous avons un environnement de preuve qui se présente comme suit : H =================== B où H est la partie où sont nos hypothèses, et B est la partie où il y a le(s) but(s) que nous voulons prouver. Supposons par exemple que nous ayons l’environnement de preuve suivant : ... Hn0 : n = 0 H : m = n -> P =================== P Nous pouvons écrire dans le script de preuve que l’on veut appliquer l’hypothèse H en écrivant : apply: H. Nous pouvons ensuite exécuter la commande que l’on vient d’écrire pour voir comment notre environnement de preuve évolue. Ici il y a deux possibilités, soit 1On peut trouver une liste plus complète dans http://why3.lri.fr/.4 Introduction le système Coq ne peut pas appliquer l’hypothèse et dans ce cas il renvoie un message d’erreur, soit comme c’est le cas ici, le système Coq peut appliquer l’hypothèse et dans ce cas il va alors demander de prouver les conditions de l’hypothèse. Nous aurons donc le nouvel environnement de preuve suivant : ... Hn0 : n = 0 =================== m = n Là, nous savons que n = 0, nous pouvons donc remplacer n par 0 dans notre but. Pour cela, nous pouvons écrire dans le script de preuve la ligne suivante : rewrite Hn0. Après l’exécution de cette ligne, nous aurons l’environnement de preuve suivant : ... Hn0 : n = 0 =================== m = 0 Dans cet exemple, apply et rewrite sont ce qu’on appelle des tactiques. Au départ nous voulions prouver la proposition P, et en utilisant les deux tactiques cidessus, nous nous somme ramenés à prouver m = 0. C’est en utilisant les tactiques et nos hypothèses que nous allons construire progressivement la preuve formelle. Le langage que nous utiliserons pour la formalisation des théorèmes s’appelle SSReflect [20]. C’est une extension de Coq créée par Georges Gonthier pour prouver le théorème des quatre couleurs [18]. Le langage de tactique est défini différemment mais le noyau qui vérifie les preuves reste le même. Cette bibliothèque possède déjà les outils de base pour faire de l’algèbre linéaire. 3.1 Les Types Coq est un langage fortement typé. Un type définit un ensemble d’objets de même nature. Par exemple dans Coq tous les entiers naturels sont de type nat, on écrit : 3 : nat et ça se lit “trois est de type nat”. Le type Prop est le type des propositions, par exemple : (forall n : nat, n + 0 = n) : Prop Maintenant dire que le type de H est la proposition forall n : nat, n + 0 = n, c’est dire que H est une preuve de cette proposition. Si on reprend l’exemple ci-dessus, on a dans nos hypothèses la ligne suivante : Hn0 : n = 04 Motivations 5 Cela signifie que parmi nos hypothèses on a une preuve (ici appelé Hn0) que n = 0. Toutes les preuves d’une proposition ont le même type. Le type d’une fonction est indiqué par une flèche. Le type nat -> nat, par exemple, est le type d’une fonction qui prend en argument un entier et qui retourne comme résultat un entier. On utilise la même flèche pour l’implication. En effet, si P et Q sont des propositions, P -> Q est le type d’une fonction qui prend en argument une preuve de P et qui retourne comme résultat une preuve de Q, c’est bien une preuve de P implique Q. Cette correspondance entre les types et les preuves s’appelle la correspondance de Curry-Howard. Elle fait le lien entre une preuve d’une proposition P, et le type d’un terme de λ-calcul. Donc vérifier une preuve revient à vérifier le type d’un λ-terme. Et la vérification de type est quelque chose qui peut se faire de manière automatique par un ordinateur. Coq est un assistant de preuve qui utilise cette correspondance. Coq permet également de travailler avec des types dépendants. Un type dé- pendant est un type qui dépend de un ou plusieurs paramètres. Par exemple, le type d’une matrice est un type qui dépend du nombre de lignes et de colonnes de la matrice. 4 Motivations 4.1 Motivations générales Il y a deux principales raisons pour lesquelles on voudrait faire des preuves formelles. La première est pour vérifier des programmes. Par exemple, les programmes utilisés dans les métros automatiques qui n’ont pas de conducteur, ou les programmes utilisés dans des avions, etc. C’est le genre de programmes dont on voudrait être sûr qu’ils ne feront pas d’erreurs. La seconde, est que certaines preuves mathématiques nécessitent de longs calculs par ordinateur. C’est le cas par exemple du théorème des quatre couleurs ou dernièrement de la conjecture de Kepler qui est en train d’être formalisée avec l’assistant de preuve HOL Light [21, 22]. Donc prouver formellement que les calculs faits par l’ordinateur sont corrects permet d’avoir une meilleure certitude sur ces preuves. Il y a aussi le fait que les preuves mathématiques deviennent plus difficiles. Il existe des théorèmes dont la preuve n’est compréhensible que seulement par une poignée de mathématiciens. Ce sont des théorème difficiles à vérifier et prouver formellement ces théorèmes permettrait de pouvoir vérifier ces preuves de manières automatiques. C’est le cas par exemple du théorème de Feit-Thompson [19] dont la preuve fait plusieurs centaines de pages et qui a été formalisé avec l’assistant de preuve Coq.6 Introduction 4.2 Motivations de la thèse Les démonstrations de certains théorèmes mathématiques parfois font intervenir des résultats de différentes branches des mathématiques. C’est le cas par exemple du théorème de Perron-Frobenius qui parle des propriétés du rayon spectral des matrices à coefficients positifs. La preuve de ce théorème utilise des résultats d’algèbre linéaire, comme la réduction de Jordan d’une matrice, mais aussi des résultats d’analyse comme le théorème de Bolzano-Weierstraß en topologie générale, ou des résultats de convergence sur les matrices. Le but de cette thèse a été d’essayer de fournir des outils d’algèbre linéaire et d’analyse assez généraux pour qu’ils puissent être réutilisés. Nous présenterons dans cette thèse d’abord les travaux sur la forme normale de Jordan, ensuite ceux sur la topologie générale. Ces deux parties ont été formalisées indépendamment l’une de l’autre. Nous verrons une réutilisation de ces résultats dans le dernier chapitre avec le théorème de Perron-Frobenius. Ce qui a amené en premier lieu à s’intéresser au théorème de Perron-Frobenius est un problème de robotique qui a demandé à étudier des matrices dont les coefficients sont des intervalles [32]. Le fait que l’on ait besoin du théorème de Perron-Frobenius a été mis en évidence par Ioana Paşca en étudiant la régularité de ces matrices [42]. 5 Contributions La preuve du théorème de Perron-Frobenius qui a été formalisée en partie dans cette thèse utilise deux résultats fondamentaux en mathématiques qui sont le théorème de Bolzano-Weierstraß en topologie générale et la forme normale de Jordan d’une matrice en algèbre linéaire. Jusqu’à présent les notions de topologie telles que la continuité de fonction, ou la convergence de suite, par exemple, sont formalisées dans un cadre restreint, c’est-à-dire la plupart du temps celui des nombres réels. Pour la formalisation du théorème de Perron-Frobenius, nous avons besoin d’utiliser des propriétés de topologie sur des matrices. C’est pourquoi cette thèse propose une formalisation de résultats de topologie générale qui pourront être utilisés pour n’importe quel type, du moment que l’on aura instancié une topologie sur ce type. Un des résultats important de cette formalisation est le théorème de Bolzano-Weierstraß. La formalisation de la forme normale de Jordan a, entre autre, apporté une formalisation des matrices diagonales par blocs, d’une théorie sur les matrice semblables et équivalentes, de la théorie des facteurs invariants, des matrices compagnes, en formalisant au passage la forme normale de Frobenius. En collaboration avec Maxime Dénès, nous avons pu, en utilisant les outils fournis par les bibliothèques CoqEAL1 et SSReflect, faire une formalisation complète (sans 1http://www.maximedenes.fr/content/coqeal-coq-effective-algebra-library5 Contributions 7 axiomes) de ces résultats. Pour la preuve du théorème de Perron-Frobenius, nous avons formalisé des théorèmes généraux sur la convergence des suites sur des structures ordonnées et archimédiennes, mais aussi sur la convergence des suites de matrices. En particulier nous établissons formellement quelles sont les conditions nécessaires et suffisantes pour que la suite des puissances d’une matrice converge vers zéro. Nous donnons également une définition formelle du rayon spectral d’une matrice. Pour résumer, les contributions originales de cette thèse sont : • Une théorie générale sur la topologie. – dont le théorème de Bolzano-Weierstraß. • Les matrices diagonales par blocs. • Une théorie des facteurs invariants. • Les matrices compagnes. • Les formes normales de Frobenius et de Jordan d’une matrice. • Des théorèmes généraux sur la convergence des suites – sur les structures ordonnées. – sur les structures archimédiennes. – sur les matrices. • Une définition du rayon spectral d’une matrice. • Une preuve partielle du théorème de Perron-Frobenius.Chapitre 1 Contexte L’outil utilisé pour la formalisation de tous les résultats présentés dans cette thèse est l’assistant de preuve Coq avec la bibliothèque SSReflect. La bibliothèque SSReflect contient déjà des théories assez développées sur les principaux concepts que nous utiliserons tels que les polynômes ou les matrices par exemple. Nous présenterons donc ici comment les principaux outils que nous utiliserons par la suite sont formalisés dans la bibliothèque SSReflect, afin de familiariser le lecteur avec les notations et les énoncés formels qu’il rencontrera. 1.1 Les types de base Les notions abordées dans cette section sont expliquées plus en détail dans [3]. La plupart des types en Coq sont des types inductifs. Les types inductifs sont en général définis comme suit : Inductive TI := C1 : e1 | C2 : e2 | ... | Ck : ek. Ici les ei sont des expressions dans lesquelles le type TI peut apparaître. Les Ci sont les constructeurs du type TI. C’est ce qui permet de construire des éléments de type TI. Tous les éléments de type TI sont forcément construits à partir des constructeurs. Nous pouvons définir des fonctions du type inductif TI vers un type T en faisant un traitement par cas sur toutes les formes possibles de l’élément de type TI passé en argument de la fonction : Definition f (x : TI) : T := match x with |C1 ... => E1 |C2 ... => E2 ... |Ck ... => Ek end.10 Contexte où les points de suspensions horizontaux sont de possibles arguments des constructeurs du type TI. L’expression f (Ci ...) est convertible avec l’expression Ei, c’est-à-dire que l’expression f (Ci ...) se réduit en Ei par des règles de calculs. On peut considérer deux expressions convertibles comme étant identiques. Nous allons voir dans la suite les types inductifs de base dans Coq. 1.1.1 Le type produit Le type produit de deux types A et B est défini comme suit : Inductive prod (A B : Type) := pair : A -> B -> prod A B. Ce type correspond au produit cartésien de A et de B. La notation définie dans la bibliothèque standard de Coq pour prod A B est A * B, et celle pour pair x y est (x,y). Donc si nous avons x : A et y : B alors nous avons (x,y) : A * B. Si nous avons un élément p : A * B alors on peut définir les projections qui permettent de récupérer le premier et le second élément de la paire p : Definition fst (A B : Type) (p : A * B) := match p with (x,y) => x end. La fonction snd qui renvoie le second élément de p est définie de la même manière. Dans la bibliothèque SSReflect, la notation p.1 désigne fst p et p.2 désigne snd p. Donc (x,y).1 = x et (x,y).2 = y. 1.1.2 Les types propositionnels Soit A et B deux propositions, alors les propositions « A et B » et « A ou B » sont exprimées formellement à l’aide de types inductifs. Elles sont notées respectivement A /\ B et A \/ B. Pour la conjonction de plusieurs propositions par exemple, on peut rencontrer dans la bibliothèque SSReflect, la notation suivante : [/\ A , B & C] Pour la disjonction le /\ est remplacé par \/ et le & par |. On peut utiliser cette notation jusqu’à cinq propositions pour la conjonction, et quatre pour la disjonction. 1.1.3 Le type booléen Les booléens sont définis simplement dans Coq de la manière suivante : Inductive bool := true : bool | false : bool. Les opérateurs booléens « et » et « ou » sont notés respectivement a && b et a || b pour deux booléens a et b quelconques.1.1 Les types de base 11 1.1.4 Les entiers naturels Les entiers naturels sont définis selon la construction de Peano : Inductive nat := O : nat | S : nat -> nat. Le constructeur S correspond à la fonction successeur. Dans la bibliothèque SSReflect, S n est noté n.+1, n.+2 est une notation pour S n.+1, cela va jusqu’à n.+4. La fonction prédécesseur d’un entier est définie dans la bibliohèque standard de Coq : Definition pred n := match n with 0 => 0 | S n’ => n’ end. La bibliothèque SSReflect fourni pour pred n une notation similaire à la pré- cedente qui est n.-1, de même nous avons aussi la notation n.-2. 1.1.5 Les séquences Une séquence permet d’énumérer un nombre fini d’éléments de même type. On utilise plus couramment le mot « liste », d’ailleurs dans la bibliothèque standard de Coq ce type s’appelle list. Pour certaines raisons historiques dans la bibliothèque SSReflect on utilise la notation seq pour list, donc bien que la définition des séquences soit définie dans la bibliothèque standard de Coq, je vais la présenter ici avec la notation SSReflect car c’est celle que nous utiliserons par la suite : Inductive seq (T : Type) := nil : seq T | cons : T -> seq T -> seq T. Les notations et les quelques définitions que nous allons voir maintenant sont celles de la bibliothèque SSReflect. Le constructeur nil, noté [::], correspond à la séquence vide. Le constructeur cons permet d’ajouter un élément en tête d’une séquence. Par exemple si s est la séquence qui contient (dans cet ordre) les éléments 2 et 3 alors cons 1 s est la séquence qui contient (dans cet ordre) les éléments 1, 2 et 3. On note cons a s par a :: s, par exemple la séquence ci-dessus est notée 1 :: (2 :: (3 :: nil)). Une autre façon de noter cette séquence est la suivante [:: 1 ; 2 ; 3 ]. Voici plusieurs fonctions élémentaires sur les séquences : • La fonction size retourne le nombre d’éléments d’une séquence. • La fonction nth permet de retourner le n-ième élément d’une séquence. Cette fonction prend un élément par défaut comme argument. Par exemple nth x0 s i retourne x0 si la séquence s est vide ou si l’entier i est plus grand que size s et retourne le i-ème élément de la séquence sinon. Si le12 Contexte type des éléments d’une séquence s a une structure de groupe additif avec comme élément neutre 0, alors la notation s‘_i désigne nth 0 s i. • la fonction last retourne le dernier élément d’une séquence. Par exemple, last x0 s retourne le dernier élément de la séquence s et x0 si la séquence s est vide. • La fonction cat permet de concaténer deux séquences. cat s1 s2 se note s1 ++ s2. • La fonction map permet à partir d’une séquence s et d’une fonction f d’obtenir une nouvelle séquence en appliquant f à chaque élément de s. Par exemple map f [:: 1 ; 2 ; 3] est la séquence [:: f 1 ; f 2 ; f 3]. La notation [seq f x | x <- s] est une notation dite par compréhension pour map f s. On peut lire cette notation comme « La séquence des f x tels que x appartient à s »(le signe <- symbolise ∈). • La fonction filter permet à partir d’un prédicat booléen P et d’une sé- quence s d’obtenir une séquence qui ne contient que les éléments de la séquence s qui vérifient le prédicat P. La notation par compréhension de filter P s est [seq x <- s | P x]. 1.2 La bibliothèque SSReflect Dans cette section, nous allons expliquer dans un premier temps quelques mécanismes utilisés dans la bibliothèque SSReflect. Nous présenterons ensuite les principaux outils de SSReflect utilisés pour la formalisation. 1.2.1 La réflexion La réflexion est une manière d’utiliser le calcul pour prouver un résultat. Imaginez un miroir. D’un côté du miroir il y a le monde des propositions, et de l’autre côté il y a le monde des booléens. Si certaines propositions (pas toutes) se regardent dans le miroir, elle pourront voir une expression booléenne qui reflète leur comportement. C’est-à-dire que l’expression booléenne aura la valeur true si la proposition est vraie et la valeur false sinon. Prouver une proposition P par réflexion, c’est passer de l’autre côté du miroir, pour calculer la valeur de l’expression booléenne et ainsi en déduire la valeur de vérité de la proposition. Dans la bibliothèque SSReflect, les lemmes qui permettent de passer d’un côté ou de l’autre du miroir sont appelés des lemmes de réflexion. Ces lemmes s’expriment à l’aide du type inductif suivant : Inductive reflect (P : Prop) : bool -> Set := ReflectT (_ : P) : reflect P true | ReflectF (_ : ~P) : reflect P false.1.2 La bibliothèque SSReflect 13 Le type reflect a deux constructeurs de type légèrement différent. Le premier constructeur prend une preuve de la proposition P en argument (cette preuve n’étant pas utilisée dans le type du constructeur, il est inutile de lui donner un nom, d’où le _:), et son type est reflect P true. Alors que le deuxième constructeur prend en argument une preuve de ~P et a comme type reflect P false. Nous avons donc une correspondance entre une preuve de P avec la valeur true, et une preuve de ~P avec la valeur false. Si H est de type reflect P b alors nous avons deux cas. Soit H = ReflectT H’, et dans ce cas nous avons d’une part b = true (car le type de ReflectT H’ est reflect P true), et d’autre part la proposition P est vraie (car H’ est une preuve de P). Soit H = ReflectF H’ et alors dans ce cas b = false et H’ est une preuve de ~P. Ainsi H : reflect P b exprime bien le fait qu’il y a une réflexion entre la valeur de b et la proposition P. Un lemme de réflexion sur la proposition P permet de faire un raisonnement classique sur cette proposition. Si nous avons l’environnement de preuve suivant : ... H : reflect P b. ========================== G(b) alors nous pouvons faire un traitement par cas sur l’hypothèse H : case: H. Cette tactique va essayer de déstructurer l’hypothèse H. Comme le type de H est inductif et possède deux constructeurs, cela va générer deux sous-buts (un pour chaque constructeur). Chacun des constructeurs ayant besoin d’un argument, chaque sous-but va être quantifié sur ces arguments ; dans le premier cas l’argument est une preuve de P, et dans le deuxième cas c’est une preuve de ~P. Nous allons donc avoir les deux sous-buts suivants : subgoal 1 : ... ============================== P -> G(true) subgoal 2 is : ~P -> G(false) Mis à part le remplacement du booléen b par sa valeur dans chacun des cas, nous obtenons le même résultat que si l’on avait utilisé la tactique case: HP, où HP est une hypothèse de type P \/ ~P. Avec des lemmes de réflexion il est possible de passer facilement du monde des propositions au monde booléen (et vice versa) grâce au mécanisme de « vue » que nous allons présenter dans la section suivante.14 Contexte 1.2.2 Le système de vue Dans la bibliothèque SSReflect, il existe un mécanisme de « vue ». Il est nommé ainsi car il permet de faire, dans un certain sens, des changements de point de vue. Pour utiliser le système de vue on utilise la syntaxe suivante : tactic/H. où tactic peut être une tactique quelconque1 , et H une hypothèse ayant une des trois formes suivantes : 1. P -> Q 2. P <-> Q 3. reflect P b où P, Q sont des propositions et b un booléen. Dans chaque cas, il y a deux exemples d’utilisation des vues. Regardons d’abord les cas 1) et 2) : • Le premier exemple d’utilisation est quand le but que l’on veut prouver est Q. Alors dans ce cas là la tactique apply/H transforme le but en P. • Le deuxième exemple d’utilisation est quand le but que l’on veut prouver est de la forme P -> G alors la tactique move/H transforme le but en Q -> G. La différence entre le cas 1) et le cas 2) est que dans le cas 2) les rôles des propositions P et Q peuvent être inversés. Nous allons expliquer maintenant le cas 3). Dans la bibliothèque SSReflect, il y a une coercition du type des booléens vers le type des propositions : Coercion is_true (b : bool) := b = true. Cette coercition permet d’utiliser les booléens comme des propositions. Donc dans le cas où H est de la forme reflect P b, le système de vues se comporte comme si l’on avait H : P <-> b (i.e P <-> b = true). Expliquons le principe sur un exemple. Imaginons que l’on veuille prouver qu’un booléen b soit égal à true, et que l’on ait une hypothèse H : reflect P b. Nous avons donc l’environnement de preuve suivant : ... H : reflect P b ======================= b Si l’on exécute la tactique apply/H nous obtiendrons : 1Enfin presque, disons plutôt à quelque exceptions près. Par exemple on ne peut pas utiliser de vue avec la tactique rewrite.1.2 La bibliothèque SSReflect 15 ... H : reflect P b ======================= P Pour voir ce qui s’est passé, nous pouvons exécuter la commande Show Proof, le système affichera un terme de preuve dans lequel on verra apparaître : . . . [eta introTF H] . . . Donc lorsque nous avons voulu appliquer une vue avec l’hypothèse H, le système a fait appel à un lemme appelé introTF. Le lemme introTF est défini dans la bibliothèque SSReflect comme suit : Lemma introTF (P : Prop) (b c : bool) : reflect P b -> (if c then P else ~P) -> b = c. Le but que l’on veut démontrer est b = true, donc si nous appliquons le lemme introTF il va être instancié avec c = true, et le système va nous demander de prouver if true then P else ~P ( c’est-à-dire P) et reflect P b, mais cette dernière hypothèse est donnée par H. Donc finalement le nouveau but sera transformé en P. Le théorème introTF a été ajouté dans une base de données, que nous appelerons la base des lemmes de vues, à l’aide de la commande Hint View. Donc lorsque nous avons exécuté la tactique apply/H, le système a cherché s’il y a un lemme dans la base des lemmes de vues qui pourrait être utilisé avec l’hypothèse H. Dans notre cas il a trouvé le lemme introTF, s’il n’avait pas trouvé de lemme qu’il aurait pu utiliser, il aurait essayé d’appliquer directement l’hypothèse H (c’est ce qu’il fait dans le cas où H : P -> Q par exemple). 1.2.3 Les types avec une égalité décidable L’égalité utilisée dans le système Coq est l’égalité de Leibniz. Prouver l’égalité entre deux éléments n’est pas toujours décidable. La théorie développée dans la bibliothèque SSReflect distingue le cadre où l’on peut décider de l’égalité. La structure d’égalité décidable est l’une des premières structures de base définies dans la bibliothèque SSReflect. On peut décider de l’égalité de deux éléments de type T si on a un algorithme qui prend en argument ces deux éléments et qui retourne le booléen true si ces éléments sont égaux, et le booléen false sinon. La structure est donc définie ainsi1 : Structure eqType := EqMixin { sort : Type ; eq_op : sort -> sort -> bool ; _ : forall x y, reflect (x = y) (eq_op x y) } 1Enfin presque, pour des raisons de clarté j’ai donné une définition plus simple.16 Contexte La notation utilisée pour eq_op x y est (x == y). L’expression (x == y) repré- sente donc une égalité booléenne. Bien sûr, l’algorithme caché derrière la notation == dépend du type de x et de y, s’ils sont de type nat, alors le == représente l’algorithme qui teste l’égalité de deux éléments de type nat, mais s’ils sont de type bool, alors le == représente le test d’égalité de deux booléens. Le sytème Coq retrouve les bonnes instances de la notation grâce à un système de structures canoniques. Cependant dans certains cas on peut demander au système de choisir une interprétation particulière du signe == avec la notation (x == y :> T), ici on demande au système de voir les éléments x et y comme des éléments de type T 1 , et donc l’algorithme de comparaison utilisé sera celui instancié sur le type T. 1.2.4 Les types finis Les types finis sont définis dans la bibliothèque SSReflect comme les types dont tous les éléments peuvent être énumérés dans une séquence. Ils sont définis dans une structure appelée finType. Ici nous allons présenter dans un premier temps le type fini appelé ordinal, car nous l’utiliserons couramment dans la suite. Nous verrons ensuite quelques notations à propos des fonctions sur un type fini. Les ordinaux Si n est un entier, alors le type ordinal n contient tous les entiers strictement plus petit que n. Il est défini dans la bibliothèque SSReflect comme suit : Inductive ordinal (n : nat) := Ordinal m (_ : m < n). Le type ordinal n est noté ’I_n. Ainsi, un élément x de type ’I_n est un entier muni d’une preuve qu’il est plus petit que n. Il y a donc une coercition naturelle du type ’I_n dans le type nat, cette coercition s’appelle nat_of_ord. Les fonctions sur les types finis Si nous avons une fonction f de type aT -> rT avec aT : finType et rT un type quelconque, alors cette fonction a un nombre fini d’images, donc l’image de f peut être représentée par une séquence. La théorie de ces fonctions est développée dans le fichier finfun.v de la bibliothèque SSReflect. Le type de ces fonctions est noté {ffun aT -> rT}. Pour définir une fonction qui a ce type, on peut utiliser la notation [ffun x => expr] où expr est le corps de la fonction. 1.2.5 Les opérateurs de familles Les opérateurs de familles sont les opérateurs que l’on utilise dans des expressions comme : 1 Il faut donc soit que le type de x et de y soit convertible au type T, soit qu’il existe une coercition du type de x et de y vers le type T.1.2 La bibliothèque SSReflect 17 X p i=n xi Y i∈S ai [ i∈S Ai Le fichier bigop.v de la bibliothèque SSReflect contient des définitions et des lemmes qui permettent d’exprimer formellement, et de manipuler ce genre d’expression. C’est ce que nous allons présenter brièvement ici. Supposons que nous avons un opérateur op avec la notation suivante : Variables (T : Type) (op : T -> T -> T). Notation "x * y" := (op x y). Les opérateurs de familles sont un moyen d’exprimer de manière concise une expression comme : x1 * x2 * ... * xk Autrement dit, on s’en sert pour appliquer, dans un certain sens, un opérateur à une famille d’éléments en itérant plusieurs fois l’opération. Il existe une fonction foldr définie dans la bibliothèque SSReflect, qui permet de faire cela sur les éléments d’une séquence. La fonction foldr est définie comme suit : Fixpoint foldr f x0 s := if s is x :: s’ then f x (foldr s’ f) else x0. Donc dans notre exemple, nous aurons : • foldr op x0 [::] = x0 • foldr op x0 [:: x1] = x1 * x0 Et de manière plus générale : • foldr op x0 [:: x1, x2, ..., xk] = x1 * (x2 * . . . * xk * x0) L’argument x0 de la fonction foldr est l’élément par défaut retourné quand la fonction est appelé sur la séquence vide. C’est pour cela que ci-dessus l’argument x0 apparaît à la fin de chaque expression. Donc pour que la fonction foldr ait le comportement attendu, il suffit que x0 soit un élément neutre à droite pour l’opérateur op. Dans ce qui est fait dans le fichier bigop.v, la fonction foldr n’est pas utilisée directement sur la séquence [:: x1, ..., xk] mais sur la séquence des indices (i.e la séquence [:: 1, 2, ... k] ; et donc au lieu d’utiliser directement la fonction op comme premier argument, on applique d’abord la fonction fun (i : nat) => xi avant de faire appel à l’opérateur op. Tout ce mécanisme est caché principalement derrière la notation suivante : \big[op/id]_(i <- s) F i où op est l’opérateur qui est itéré, id est (en général) l’élément neutre pour l’opérateur op, s la séquence des indices, et F i l’expression des termes auquels on applique l’opérateur op. Par exemple, si addn est l’addition sur les entiers, et U_ est une fonction sur les entiers alors :18 Contexte \big[addn/0]_(i <- [:: 2 ; 5 ; 7]) U_ i = U_ 2 + U_ 5 + U_ 7. Il existe plusieurs variantes de cette notation qui sont présentées dans le tableau suivant : Contexte Notation générale Exemple avec l’opérateur somme i) \big[op/id]_(m <= i < n) F i nX−1 i=m Fi ii) \big[op/id]_(i < n) F i X i seq R; _ : last 1 polyseq != 0}. Le symbole :> permet de déclarer polyseq comme une coercition du type des polynômes vers le type des séquences. La séquence vide représentant le polynôme nul doit vérifier la définition ci-dessus. Or lorsque la fonction last est appliquée à la séquence vide, elle retourne un élément par défaut. Cet élément par défaut doit être différent de 0, et le seul autre élément de l’anneau R dont on connait l’existence est 1. Donc pour que cette définition de polynôme soit valide, il faut que 1 != 0. C’est principalement pour cette raison que l’axiome 1 != 0 a été rajouté comme axiome dans la structure ringType. Nous allons voir d’abord quelques généralités sur les polynômes, ensuite nous parlerons de la divisibilité sur les polynômes. Généralité Le type des polynômes est noté {poly R}, ainsi si p : {poly R} alors p est un polynôme à coefficients dans l’anneau R. Voici un tableau qui résume les principales notations sur les polynômes : Notation SSReflect Description c%:P Le polynôme constant c (avec c : R) ’X Le polynôme X (où X est l’indéterminée) lead_coef p Le coefficient dominant du polynôme p p \is monic Le polynôme p est unitaire p.[a] La valeur du polynôme p évalué en a (i.e p(a)) Il n’y a pas vraiment de définition pour le degré d’un polynôme. On parle plutôt de la taille de la séquence des coefficients. Comme il existe une coercition des polynômes vers les séquences, on peut directement écrire size p. Donc pour un polynôme p non nul, (size p).-1 est égal au degré de p.1.2 La bibliothèque SSReflect 21 Divisibilité et racines Les notations liés à la divisibilité et aux racines d’un polynôme sont présentées dans le tableau suivant : Notation SSReflect Description p %/ q p divisé par q p %% q p modulo q p %| q p divise q p %= q p %| q et q %| p gcdp p q pgcd(p, q) root p x x est une racine de p \mu_x p multiplicité de x dans p La relation %= est une relation d’équivalence. Si p %= q alors cela veut dire que l’on peut passer de l’un à l’autre en multipliant par un scalaire inversible. En mode mathématique, nous noterons cette relation p ∼ q. 1.2.8 Les matrices Dans la bibliothèque SSReflect, les matrices sont définies comme suit : Inductive matrix := Matrix (_ : {ffun ’I_m * ’I_n -> R}). Ce type inductif a un constructeur Matrix qui prend en argument une fonction dont toutes les valeurs correspondent aux coefficients de la matrice. Cette fonction peut être récupérée par la fonction mx_val définie comme suit : Definition mx_val m n (A : matrix m n) := match A with Matrix g => g end. On peut ainsi définir la coercition suivante : Definition fun_of_matrix m n A (i : ’I_m) (j : ’I_n) := mx_val A (i,j). Coercion fun_of_matrix : matrix -> Funclass. Cette coercition permet de voir les matrices comme des fonctions. Ainsi, si nous avons une matrice A, alors on peut écrire A i j le coefficient de la ligne i et de la colonne j de A. Le type des matrices est noté de manière générale ’M[R]_(m,n) où R est le type des coefficients de la matrice et m et n ses dimensions. Si il n’y a pas d’ambiguïté sur le type des coefficients, alors on peut écrire ’M_(m,n). Dans le cas des matrices carrées on notera ’M[R]_n ou ’M_n. Si l’on connait l’expression générale des coefficients d’une matrice, alors on peut la définir avec la notation suivante : \matrix_(i < m , j < n) E i j22 Contexte où E est l’expression générale des coefficients. Le type de la matrice ainsi définie est ’M_(m,n). Dans le cas des matrices carrées, pour la taille de la matrice, on peut juste préciser (i, j < n) ; et si il n’y a pas d’ambiguïté sur la taille de la matrice alors on précisera simplement (i,j). Par exemple la matrice définie comme suit : \matrix_(i, j < 3) 2 *+ (i == j) + (i.+1 == j) correspond à la matrice :   2 1 0 0 2 1 0 0 2   Comme il y a une coercition du type bool vers le type nat, l’expression (i == j) sera interprétée comme 0 ou 1, et elle ne vaudra 1 que dans le cas où i et j sont égaux ; c’est la raison pour laquelle les 2 apparaissent sur la diagonale. En fait (i == j) est une façon d’écrire δij , le symbole de Kronecker, et a *+ (i == j) est une façon d’écrire a.δij . Ici nous avons montré l’exemple d’une matrice carrée où i et j ont le même type. Mais dans le cas d’une matrice rectangulaire, i et j ont des types différents, et donc l’expression (i == j) est mal typée. Par exemple, si nous avions écrit : \matrix_(i < 2, j < 3) 2 *+ (i == j) + (i.+1 == j) Nous aurions i : ’I_2 et j : ’I_3. Pour que la définition soit correcte il faut préciser au système Coq que l’on veut que la comparaison entre i et j se fasse sur les entiers. La définition correcte est donc : \matrix_(i < 2, j < 3) 2 *+ (i == j :> nat) + (i.+1 == j) Pour finir voici les notations usuelles sur les matrices : Notation SSReflect Description A i j Le coefficient Aij de la matrice A a%:M La matrice qui ne contient que des a sur la diagonale (par exemple 1%:M est la matrice identité) A *m B A ∗ B \det A Le déterminant de A A \in unitmx A est inversible 1.2.9 Matrices et polynômes Dans cette thèse nous serons amenés à évoquer les notions de polynôme caractéristique d’une matrice et de polynôme minimal. Ces notions sont formalisées dans la bibliothèque SSReflect dans le fichier mxpoly.v. Soit A un anneau, p ∈ A[X] et A ∈ Mn(A). Alors p(A) est la matrice qui correspond à l’évaluation du polynôme p en la matrice A. Par exemple, si nous1.2 La bibliothèque SSReflect 23 avons p = 2X2 − 3X + 4 alors p(A) = 2A2 − 3A + 4I. Si p est tel que p(A) = 0 alors on dit que p est un polynôme annulateur de la matrice A. La matrice XI − A est la matrice caractéristique de A. Le déterminant de cette matrice est un polynôme appelé polynôme caractéristique de la matrice A. Ce polynôme est un polynôme annulateur de la matrice. Le polynôme unitaire et annulateur de la matrice A de plus petit degré est appelé polynôme minimal de la matrice A. Une propriété caractéristique du polynôme minimal est que c’est un polynôme annulateur qui divise tout les autres polynômes annulateurs de la matrice. Le tableau ci-dessous donne le nom des fonctions définies dans la bibliothèque SSReflect qui correspondent à ce que l’on a décrit ci-dessus : Notation SSReflect Description horner_mx A p p(A) char_poly_mx A XI − A char_poly A polynôme caractéristique de A mxminpoly A polynôme minimal de A 1.2.10 Les structures ordonnées Les structures telles que les corps réels clos, ou les corps archimédiens sont dé- finis dans le fichier ssrnum.v de la bibliothèque SSReflect. La structure ordonnée la plus générale est basée sur la structure d’anneau commutatif intègre (idomainType), et contient en plus une comparaison booléenne large notée <=, une comparaison booléenne stricte notée <, et une fonction valeur absolue ou module notée ‘|.|. Cette structure est appelée numDomainType. Sur cette structure, les fonctions maxr et minr désignent respectivement les fonctions maximum et minimum. Voici les structures qui sont implémentées dans le fichier ssrnum.v : Nom de la structure Description numDomainType c’est la structure décrite plus haut numFieldType numDomainType, mais basé sur un corps numClosedFieldType numDomainType basé sur un corps algébriquement clos realDomainType numDomainType avec un ordre total realFieldType Corps réel archiFieldType Corps archimédien rcfType Corps réel clos Ces structures (ainsi que la construction de nombres complexes ci-dessous) sont expliquées plus en détails dans la thèse de Cyril Cohen [8].24 Contexte 1.2.11 Les nombres complexes Les nombres complexes sont définis comme étant une paire de nombres : Inductive complex (R : Type) : Type := Complex {Re : R; Im : R}. On utilisera en général la notation suivante : Local Notation C := (complex R). La notation x%:C représente un réel plongé dans les complexes, c’est une notation pour Complex x 0. On peut munir le type complex R des structures ordonnées numDomainType et numFieldType si R est de type rcfType (i.e. c’est un corps réel clos). En effet, pour définir le module d’un nombre complexe, il faut définir la fonction « racine carrée ». Or la racine carrée d’un nombre a est définie comme une racine du polynôme X2 − a, donc pour que cette fonction soit bien définie, il faut1 que R soit un corps réel clos. L’ordre partiel défini sur les complexes est le suivant : Definition lec x y := (Im x == Im y) && (Re x <= Re y). Definition ltc x y := (Im x == Im y) && (Re x < Re y). La structure de numDomainType est instanciée sur le type complex avec les deux définitions ci-dessus pour l’ordre large et l’ordre strict, et avec la fonction “module” suivante : Definition normc x := (Num.sqrt ((Re x)^+2 + (Im x)^+2))%:C. Pour pouvoir déclarer les nombres complexes comme étant une instance de la structure numDomainType, on doit plonger le module d’un nombre complexe dans C. Car si T est le type principal sur lequel est défini la structure numDomainType, alors le type de la fonction ‘|.| est T -> T. Or, dans notre cas, T est instancié par C, donc la fonction module doit être de type C -> C. Ceci a pour inconvénient que le module d’un nombre complexe est un nombre complexe. 1.3 Conclusion Ce chapitre explique les principaux outils utilisés dans le travail de formalisation. Il présente aussi les notations usuelles qui seront utilisées dans la suite de cette thèse. 1Enfin pas tout à fait. Disons que la structure rcfType est la plus petite structure implé- mentée dans la bibliothèque SSReflect telle que la fonction « racine carrée »soit bien définie.Chapitre 2 Forme de Jordan d’une matrice Un résultat important en algèbre linéaire est le fait qu’une matrice soit semblable à sa forme normale de Jordan. La formalisation de ce résultat passe d’abord par la formalisation de nombreux concepts comme les matrices diagonales par blocs, les matrices compagnes, les facteurs invariants, et les matrices semblables ou équivalentes. Ce résultat utilise également d’autres formes normales de matrices comme la forme normale de Smith et la forme normale de Frobenius d’une matrice. Les travaux présentés dans ce chapitre ont été menés en commun avec Maxime Dénès (voir [7]), et ont été inspirés de la thèse de Patrick Ozello [37] et de celle de Isabelle Gil [16]. Nous verrons dans une première section comment les matrices diagonales par blocs ont été formalisées. Dans la section suivante, nous parlerons de la similitude et de l’équivalence entre deux matrices. Ensuite nous discuterons sur la forme normale de Smith, sur ses propriétés, et montrerons quelques lemmes importants qui seront utiles par la suite. Dans une quatrième section, nous donnerons les définitions formelles de matrices compagnes et des facteurs invariants ; nous pourrons ainsi définir la forme normale de Frobenius d’une matrice. Enfin nous montrerons comment nous obtenons la forme normale de Jordan d’une matrice. 2.1 Matrices diagonales par blocs Une matrice diagonale par blocs est une matrice de la forme :   A1 0 . . . 0 0 A2 . . . . . . . . . . . . . . . 0 0 . . . 0 Ak   où les Ai sont des matrices carrées quelconques. Ces matrices seront utilisées pour exprimer les formes normales de Frobenius et de Jordan d’une matrice.26 Forme de Jordan d’une matrice Ce qui est intéressant dans les matrices diagonales par blocs est qu’en général si l’on veut faire des opérations (ou montrer des propriétés), on peut se ramener à les faire (ou les montrer) sur chaque bloc ; ce qui permet dans certains cas de se ramener à un problème plus simple. Certains choix de formalisation dans la bibliothèque SSReflect font que la définition formelle de matrice diagonale par blocs n’est pas aussi simple qu’on le voudrait. Nous expliquerons donc dans un premier temps quelle définition de matrice diagonale par blocs nous voudrions avoir, et ensuite nous verrons quels problèmes nous avons rencontrés avec cette définition, et comment ils ont été résolus. 2.1.1 Définition idéale Dans la bibliothèque SSReflect, il existe une fonction qui s’appelle block_mx. Cette fonction permet de construire une matrice à partir de blocs matriciels. Par exemple, si A, B, C et D sont des matrices (avec des dimensions adéquates) alors block_mx A B C D est la matrice A B C D! Si B et C sont des matrices nulles, et si A et D sont des matrices carrées, alors block_mx A 0 0 D est une matrice diagonale par blocs avec comme blocs diagonaux les matrices A et D. L’idée de base pour construire les matrices diagonales par blocs est d’appeler récursivement la fonction block_mx. À chaque appel de la fonction block_mx, il faudra lui donner en arguments successivement les blocs diagonaux de la matrice que l’on veut construire. Ces blocs peuvent être de tailles différentes, et donc de types différents. Une première difficulté va être d’exprimer l’ensemble de ces blocs diagonaux. Une solution pourrait être d’utiliser le type des paires dépendantes de Coq. Dans la bibiliothèque standard de Coq, il y a un type sigT défini comme suit : Inductive sigT (A : Type) (P : A -> Type) : Type := existT : forall x : A, P x -> sigT P. Notation "{ x : A & P }" := (sigT (fun x : A => P)) Dans notre cas, si A est le type nat et P est la fonction fun n => ’M_n, alors {n : nat & ’M_n} est le type des paires composées d’un entier et d’une matrice. Ces paires sont dépendantes dans le sens où le type de la matrice dépend de l’entier. De plus, pour tout k : nat et pour toute matrice M : ’M_k l’expression existT k M est de type {n : nat & ’M_n}. Ainsi une sequence s dont le type est seq {n : nat & ’M_n} peut contenir des matrices de types différents (comme deuxième élément d’une paire), nous pouvons donc nous en servir pour parler des blocs diagonaux. Ce qui nous donnerait comme première définition :2.1 Matrices diagonales par blocs 27 Fixpoint diag_block_mx (s : seq {n : nat & ’M[R]_n}) := match s return ’M[R]_(size_sum s) with | [::]=> 0 | (existT k A) :: s’=> block_mx A 0 0 (diag_block_mx s’) end. où size_sum s est la fonction qui donne la taille de la matrice diagonale par blocs, elle consiste simplement à faire la somme des tailles de chaque bloc. Cette définition est suffisante pour prouver qu’une matrice est semblable à sa forme de Jordan, car la seule chose que l’on fait avec les matrices diagonales par blocs est de prouver leur similitude ou leur équivalence avec d’autres matrices. Par contre, il est difficile de définir les opérateurs usuels sur ces matrices. Nous allons rencontrer un premier problème lorsque nous voudrons exprimer la somme de deux matrices diagonales par blocs. La matrice diag_block_mx s1 et la matrice diag_block_mx s2, pour des séquences s1 et s2 différentes, ont respectivement comme taille size_sum s1 et size_sum s2 ; autrement dit elles ont des types différents (même si l’on peut prouver que size_sum s1 = size_sum s2). En particulier on ne pourra même pas écrire l’expression suivante : diag_block_mx s1 + diag_block_mx s2. Il est possible de contourner ce problème en utilisant la fonction castmx de la bibliothèque SSReflect. Si nous avons deux matrices A et B, respectivement de type ’M_(m1,n1) et ’M_(m2,n2), et deux preuves d’égalités eqm : m1 = m2 et eqn : n1 = n2 alors la matrice cast_mx (eqm,eqn) B a le même type que la matrice A (i.e ’M_(m1,n1)). Donc si eq_size est une preuve d’égalité entre size_sum s1 et size_sum s2 alors nous pouvons écrire l’addition de deux matrices diagonales par bloc comme suit : diag_block_mx s1 + castmx (eq_size,eq_size) diag_block_mx s2 Malgré l’utilisation de la fonction castmx, nous nous heurterons à un deuxième problème pour exprimer qu’additionner deux matrices diagonales par blocs revient à les additionner bloc à bloc. Pour cela, il faudrait montrer que chacun des blocs des séquences s1 et s2 sont deux à deux de la même taille, et à partir de cette preuve obtenir les preuves d’égalité qui permetteront à l’aide de la fonction castmx d’écrire les sommes des blocs deux à deux. Cette définition de matrice diagonale par blocs n’est donc pas adaptée pour exprimer ce genre de propriété. Si nous voulons additionner deux matrices diagonales par blocs, c’est qu’elles ont, en général, le même découpage en blocs, car cela permet de faire l’addition bloc à bloc. Si elles n’ont pas le même découpage en blocs, alors l’information que les matrices sont diagonales par blocs n’apporte rien, et l’on doit faire l’addition comme sur deux matrices quelconques. Il est donc intéressant que deux matrices diagonales par blocs, ayant le même découpage en blocs, aient le même type. Dans la description précédente, nous avons vu que la dimension d’une matrice diagonale par blocs est donné par la fonction size_sum. Cette fonction prend en argument une liste de paires dépendantes tailles/matrices, en extrait les dimen-28 Forme de Jordan d’une matrice sions des matrices et en fait la somme. Dans la nouvelle définition de matrice diagonale par blocs, nous allons plutôt donner comme premier argument directement une séquence d’entiers qui correspondra à la séquence des tailles des blocs ; autrement dit cette séquence donnera le découpage en blocs de la matrice. Maintenant, pour exprimer les blocs de la matrice, nous ne pouvons plus utiliser une séquence de paires dépendantes. Car sinon il faudrait s’assurer que les tailles données comme premier élément de chaque paire soient les mêmes que ceux de la séquence de découpage des blocs, ce que l’on veut éviter. Pour exprimer les blocs, nous allons donc utiliser une fonction. Cette fonction doit retourner comme valeur des matrices de différentes tailles, et donc de types différents. C’est pourquoi le premier argument de la fonction sera la taille de la matrice qu’elle va retourner ; pour le deuxième argument nous prendrons simplement le numéro du bloc dans la matrice diagonale par blocs. Le type de cette fonction est donc forall n : nat, nat -> ’M_n. Notre nouvelle définition de matrices diagonales par blocs se présente donc ainsi : Fixpoint diag_block_mx s (F : forall n : nat, nat -> ’M_n) := match s return ’M_(sumn s) with | [::] => 0 | n :: s’ => block_mx (F n 0) 0 0 (diag_block_mx s’ (fun n i => F n i.+1)) end. où sumn prend en argument une séquence d’entiers et retourne la somme de ces entiers. Voyons comment cela fonctionne sur un exemple :   1 1 0 0 0 0 2 4 0 0 0 0 0 0 4 0 0 0 0 0 0 4 5 1 0 0 0 9 6 6 0 0 0 0 4 2   Le découpage en blocs de la matrice ci-dessus correspond à la séquence de découpage [:: 2 ; 1 ; 3]1 . Le bloc numéro 0 est de taille 2, il correspond donc au bloc F 2 0 où F est la fonction qui retourne les blocs diagonaux de la matrice ci-dessus, c’est-à-dire n’importe quelle fonction qui vérifie les trois conditions suivantes : F 2 0 = 1 1 2 4! ; F 1 1 =  4  ; F 3 2 =   4 5 1 9 6 6 0 4 2   1 Il y a quatre façon de découper cette matrice en blocs qui correspondent aux séquences suivantes : [:: 6], [:: 2 ; 4], [:: 3 ; 3], [:: 2 ; 1 ; 3].2.1 Matrices diagonales par blocs 29 Comme les autres valeurs de la fonction F ne sont pas appelées par la fonction diag_block_mx, elles n’ont pas d’importance. Avec cette définition nous pouvons exprimer facilement que la somme de deux matrices diagonales par blocs est la matrice diagonale par blocs où chaque bloc est la somme des blocs des deux premières matrices : Lemma add_diag_block s F1 F2 : diag_block_mx s F1 + diag_block_mx s F2 = diag_block_mx s (fun n i => F1 n i + F2 n i). Cette deuxième définition est assez proche de la définition idéale que l’on voudrait pour les matrices diagonales par blocs, car elle est proche de l’intuition que l’on s’en fait (appel récursif de la fonction block_mx), et permet de manipuler les matrices diagonales par blocs assez simplement. Cependant, à cause de certains choix de formalisation dans la bibliothèque SSReflect, nous allons rencontrer d’autres problèmes qui font que nous allons devoir modifier cette définition. C’est ce que nous allons voir dans la sous-section suivante. 2.1.2 Problèmes en dimension nulle La définition de structure d’anneaux dans la bibliothèque SSReflect demande une preuve que 1 (l’élément neutre de la loi multiplicative) soit différent de 0 (l’élément neutre de la loi additive). Ceci a pour conséquence que l’ensemble des matrices carrées d’une taille fixée forme un anneau (dans le sens de SSReflect) seulement si ces matrices sont non vides, c’est-à-dire de taille non nulle (car toutes les matrices vides sont égales). Autrement dit, l’instance canonique de la structure d’anneau sur les matrices est implémentée seulement sur celles ayant un type de la forme ’M_n.+1. Ainsi, sur les matrices n’ayant pas un type de cette forme, on ne peut pas utiliser les fonctions définies à partir des opérations génériques d’anneaux (par exempe les fonctions qui calculent la puissance, le polynôme minimal où la valeur d’un polynôme en une matrice). Or le type des matrices diagonales par blocs définies plus haut est de la forme ’M_(sumn s). Nous ne pourrons donc pas utiliser sur ces matrices certaines des fonctions citées ci-dessus. En effet, si l’on essayait d’appliquer une de ces fonctions, le système Coq attendrait comme argument une structure d’anneau sur les matrices, comme cette structure est déclarée pour les matrices dont le type est de la forme ’M_n.+1, le système va essayer de résoudre le problème d’unification ?n.+1 = sumn s et il va échouer. Nous allons donc voir ici comment la définition de matrice diagonale par blocs a été modifiée pour que le type de ces matrices soit de la bonne forme. 2.1.3 Définition finale Une propriété intéressante des matrices diagonales par blocs est que faire certaines opérations sur une matrice diagonale par blocs revient à faire ces opérations sur chaque bloc. Si ces opérations utilisent des opérations génériques d’anneaux,30 Forme de Jordan d’une matrice il faut alors que chacun des blocs ait un type de la forme ’M_n.+1. Le type de la fonction F de la définition de matrice diagonale par blocs devient donc forall n, nat -> ’M_n.+1. Maintenant nous voulons trouver une fonction, appelons-la size_sum, telle que le type d’une matrice diagonale par blocs soit ’M_(size_sum s).+1. Nous remarquons d’abord que si la séquence donnée en premier argument de la fonction diag_block_mx est vide, alors la matrice diagonale par blocs retournée est vide, et donc sa taille ne peut pas être de la forme n.+1. Il va donc falloir modifier la définition de diag_block_mx pour qu’elle ne renvoie jamais une matrice vide. Pour cela nous allons définir une première fonction pour laquelle nous allons séparer la séquence de découpage des blocs en deux ; c’est-à-dire qu’elle va prendre en argument un entier qui va représenter la taille du premier bloc, et une séquence qui contiendra la taille des autres blocs (à un près à cause du décalage dû au n.+1) : Fixpoint diag_block_mx_rec k s (F : forall n, nat -> ’M_n.+1) := match s return ’M_((size_sum_rec k s).+1) with | [::] => F k 0 | n :: s’ => block_mx (F k 0) 0 0 (diag_block_mx_rec n s’ (fun n i => F n i.+1)) end. où size_sum_rec est défini de telle façon que le type de diag_block_mx_rec ait la bonne forme : Fixpoint size_sum_rec k s := match s with | [::] => k | n :: s’ => k + (size_sum_rec n s’).+1 end. donc si s est vide alors (size_sum_rec k s).+1 = k.+1 ce qui est bien le type de F k 0, et si s = n :: s’ alors : (size_sum_rec k s).+1 = (k + (size_sum_rec n s’).+1).+1 et la dimension de la matrice dans la deuxième branche de la définition de diag_block_mx_rec est k.+1 + (size_sum_rec n s’).+1, et comme l’addition est définie récursivement par rapport à la première variable, les deux expressions sont convertibles. Mais pour utiliser cette définition, il faut donner en argument un entier et une séquence d’entiers, ce qui peut souvent amener à “couper” en deux une séquence pour donner les deux arguments. Pour éviter cela nous définissons la fonction diag_block_mx de façon à ce qu’elle prenne en argument seulement une séquence : Definition size_sum s := match s with | [::] => 0 | n :: s’ => size_sum_rec n s’ end.2.2 Matrices semblables et équivalentes 31 Definition diag_block_mx s (F : forall n, nat -> ’M_n.+1) := match s return ’M_((size_sum s).+1) with | [::] => 0 (* de type ’M_1 *) | n :: s’ => diag_block_mx_rec n s’ F end. Cette définition retourne une matrice de taille un si la séquence donnée en argument est vide. Dans la pratique cela ne devrait pas trop poser de problèmes car lorsque l’on parle d’une matrice diagonale par blocs, c’est rarement à propos d’une matrice vide. Ceci a pour conséquences que dans les énoncés des théorèmes, il faut dans certains cas rajouter l’hypothèse que la séquence des tailles des blocs soit non vide ; et dans les preuves, il faut en général faire un traitement par cas sur cette séquence pour éliminer le cas où elle est vide. Dans le cas où la séquence n’est pas vide, la fonction diag_block_mx a le comportement attendu. Pour conclure cette section, cette dernière définition de matrice diagonale par blocs a l’inconvénient mineur de ne pas avoir le bon comportement dans le cas où la séquence des tailles des blocs est vide. Mais maintenant le type d’une matrice retournée par la fonction diag_block_mx est de la bonne forme pour que l’on puisse utiliser les opérations génériques d’anneaux dessus, ainsi que sur chacun des blocs de la matrice. 2.2 Matrices semblables et équivalentes Rappelons que nous voulons montrer que la forme normale de Jordan d’une matrice est semblable à celle-ci. Pour cela nous utiliserons en plus de la notion de matrices semblables, celle de matrices équivalentes. Nous présenterons donc, dans cette section, la formalisation de ces deux notions, et nous verrons comment elles sont liées. 2.2.1 Définitions Deux matrices A et B sont équivalentes s’il existe deux matrices inversibles M et N telles que MAN = B, et elles sont semblables s’il existe une matrice inversible P telle que P AP −1 = B. Pour la définition de matrices semblables, nous préfèrerons la version avec P A = BP, car dans la bibiliothèque SSReflect, la notation x^-1 est définie sur la structure appelée unitRingType1 , or cette structure est audessus de la structure d’anneaux de SSReflect, et donc comme nous l’avons vu dans la section précédente, nous pourrons utiliser cette notation uniquement sur les matrices dont le type est de la forme ’M_n.+1. Une première définition formelle que l’on pourrait donner pour la similitude est la suivante2 : 1voir section 1.2.6 2voir 1.2.8 pour les notations.32 Forme de Jordan d’une matrice Definition similar n (A B : ’M[R]_n) := (exists P : ’M_m , P \in unitmx /\ P *m A = B *m P). Mais cette définition n’est pas assez souple pour être utilisée facilement. En effet, pour pouvoir écrire l’expression similar A B, il faut absolument que les matrices A et B aient le même type. Or nous avons signalé plus haut que la forme normale de Jordan sera exprimée comme une matrice diagonale par blocs. Donc si A : ’M_n alors sa forme normale de Jordan sera de type ’M_(size_sum s).+1 pour une certaine séquence s. En particulier, nous ne pouvons pas écrire l’énoncé qui nous intéresse, à savoir qu’une matrice est semblable à sa forme normale de Jordan ; sauf si nous décidons d’utiliser la fonction castmx, mais cela alourdirait les énoncés et compliquerait les preuves. Pour éviter ces problèmes, nous définissons le prédicat similar pour deux matrices quelconques (pas forcément de même type). Cela implique que le prédicat doit vérifier l’égalité des tailles des matrices : Definition similar m n (A : ’M[R]_m) (B : ’M[R]_n) := m = n /\ (exists P : ’M_m , P \in unitmx /\ P *m A = (conform_mx P B) *m P). Nous voyons aussi apparaître dans la définition la fonction conform_mx. Cette apparition est due au fait que, comme les matrices P et B n’ont pas le même type, l’expression B *m P est mal typée. La fonction conform_mx est définie dans la bibliothèque SSReflect. Si M et N sont deux matrices alors conform_mx M N a le même type que la matrice M. Si l’on peut prouver que les matrices M et N ont des tailles différentes, alors conform_mx M N = M. Si les matrices M et N ont le même type alors nous avons conform_mx M N = N. Nous avons donc utilisé cette fonction pour remplacer l’expression B *m P, qui est mal typée, par l’expression (conform_mx P B) *m P qui elle est bien typée. Ainsi si les matrices A et B ont la même dimension alors (conform_mx P B) représentera la matrice que l’on attend, sinon les matrices A et B n’ont aucune chance d’être semblables, et donc la matrice retournée par (conform_mx P B) importe peu, puisque l’égalité des tailles est vérifiée par ailleurs. Pour les mêmes raisons, nous définissons de manière analogue l’équivalence entre deux matrices : Variables m1 n1 m2 n2 : nat. Definition equivalent (A : ’M[R]_(m1,n1)) (B : ’M[R]_(m2,n2)) := [/\ m1 = m2, n1 = n2 & exists M, exists N, [/\ M \in unitmx , N \in unitmx & M *m A *m N = conform_mx A B]]. 2.2.2 Théorème fondamental Le lien entre ces deux notions d’équivalence et de similitude est donné par le théorème fondamental de similitude sur un corps :2.3 Forme normale de Smith 33 Théorème. Soit K un corps, soit A et B deux matrices de Mn(K) alors : A et B sont semblables ⇔ (XI − A) et (XI − B) sont équivalentes Les matrices (XI − A) et (XI − B) sont les matrices caractéristiques de A et de B. Ce sont des matrices à coefficients dans l’anneau principal K[X]. Or sur les anneaux principaux, chaque matrice a une forme normale équivalente appelée forme normale de Smith. Le théorème fondamental permet de donner une procédure simple pour tester si deux matrices sont semblables. Il suffit de prendre les matrices caractéristiques de ces matrices, de calculer leur forme normale de Smith, et de comparer les résultats. A =⇒ (XI − A) =⇒ B =⇒ (XI − B) =⇒ Mn(K) Mn(K[X]) Smith −→ SA = −→ SB = Forme normale de Smith de (XI − A) Forme normale de Smith de (XI − B) A semblable à B ⇔ SA = SB Ce théorème sera souvent utilisé dans la suite de cette formalisation, il permet de montrer que deux matrices sont semblables sans avoir à donner la matrice de passage entre ces deux matrices. L’algorithme qui donne la forme normale de Smith d’une matrice et le théorème fondamental ont été respectivement implémenté et prouvé formellement par Maxime Dénès [12, 9]. Ce travail sur la forme normale de Smith a permis d’avoir une formalisation complète (sans axiomes) des formes normales de Frobenius et de Jordan d’une matrice. Dans les sections suivantes nous allons d’abord présenter ce qu’est la forme normale de Smith d’une matrice et ensuite nous verrons le cheminement pour passer de la forme normale de Smith à celle de Jordan. 2.3 Forme normale de Smith Nous expliquons dans cette section ce qu’est la forme normale de Smith d’une matrice. Nous voyons ensuite comment l’algorithme qui donne cette forme normale est spécifié formellement, et montrons quelques propriétés importantes.34 Forme de Jordan d’une matrice 2.3.1 Spécification La forme normale de Smith d’une matrice A est une matrice équivalente à A qui se présente de la manière suivante :   d1 0 . . . . . . . . . 0 0 d2 . . . . . . . . . . . . . . . . . . . . . 0 . . . 0 dk 0 . . . 0   avec la particularité que ∀i, 1 ≤ i < k, di | di+1. Avoir un pgcd est suffisant pour que la forme normale de Smith existe. Ce qui est le cas pour les polynômes à coefficients dans un corps, qui est le contexte dans lequel nous utiliserons la forme normale de Smith. Pour exprimer cette matrice, nous définissons la fonction diag_mx_seq qui prend en argument une séquence et qui retourne une matrice diagonale dont les éléments diagonaux sont les éléments de la séquence1 : Variable R : ringType. Definition diag_mx_seq m n (s : seq R) : ’M[R]_(m,n) := \matrix_(i < m, j < n) s’_i *+ (i == j :> nat). Les dimensions de la matrice retournée par la fonction diag_mx_seq sont ses deux premiers arguments. Ceci permet une utilisation très souple de cette fonction. En effet, si nous avons besoin dans une expression que la matrice retournée par diag_mx_seq soit d’un type particulier, il suffit de donner les premiers arguments adéquats. Mais cette souplesse implique qu’il faut ajouter certaines contraintes dans les énoncés des propriétés de la fonction diag_mx_seq, pour établir un lien entre les dimensions de la matrice retournée par la fonction et la séquence donnée en argument. Par exemple, pour la sequence s = [:: 1 ; 2 ; 3] nous avons : diag_mx_seq 4 2 s = diag_mx_seq 5 4 s = diag_mx_seq 3 3 s =   1 0 0 2 0 0 0 0   ;   1 0 0 0 0 2 0 0 0 0 3 0 0 0 0 0 0 0 0 0   ;   1 0 0 0 2 0 0 0 3   Nous voyons ici que selon les valeurs de m et de n la matrice diag_mx_seq m n s n’est pas toujours la matrice à laquelle on pense. En fait, pour que la matrice diag_mx_seq m n s soit une matrice telle que sur sa diagonale on puisse lire toute la séquence s, et seulement la séquence s, il faut que la taille de la séquence soit égale au minimum de m et de n. 1voir 1.2.8 pour les notations.2.3 Forme normale de Smith 35 Une fonction Smith nous est fournie par [9] pour calculer la forme normale de Smith d’une matrice A : ’M_(m,n). Cette fonction retourne un triplet (M,d,N), où M et N sont des matrices et d une séquence qui vérifient les trois spécifications suivantes : • M *m A *m N = diag_mx_seq m n d • sorted %| d (La séquence d est triée pour la relation de division sur l’anneau R) • M \in unitmx & N \in unitmx (Les matrices M et N sont inversible) Nous pouvons fusionner le premier et le dernier point pour avoir les deux spécifications suivantes : • equivalent A (diag_mx_seq m n d) • sorted %| d Nous allons montrer dans la section suivante qu’une séquence vérifiant les spécifications ci-dessus est unique modulo une relation que nous définirons. 2.3.2 Unicité Le calcul de la forme normale de Smith utilise des calculs de pgcd sur les coef- ficients de la matrice. Le pgcd de deux éléments est unique modulo la relation d’équivalence ∼ définie de la manière suivante : a ∼ b ⇔ a|b et b|a La forme normale de Smith est donc unique modulo cette relation d’équivalence sur les coefficients. Nous allons montrer ici un résultat important sur la forme normale de Smith d’une matrice qui permet d’en déduire l’unicité, mais qui sera aussi très utile dans la suite de la formalisation. Théorème 1. Soit A une matrice à coefficients dans un anneau principal. Soit d une séquence vérifiant les spécifications suivantes : – La séquence d est triée pour la relation de division. – La matrice diagonale dont les éléments diagonaux sont les éléments de d est équivalente à la matrice A. Si l’on note ∧ le pgcd, si di désigne le ième élément de la séquence d et si |A| k désigne l’ensemble des mineurs d’ordre k de la matrice A, alors nous avons l’identité suivante : Y k i=1 di ∼ ^ x∈|A|k x36 Forme de Jordan d’une matrice Un mineur d’une matrice A est le déterminant d’une sous-matrice de A. Avant de montrer ce résultat, nous allons voir sur un exemple comment on utilise ce théorème pour déterminer de façon “unique” la forme normale de Smith d’une matrice. Exemple 1. Prenons la matrice dans M3(Z[X]) suivante : M =   5 2X X + 3 −X + 6 X + 1 4 X + 9 4X 3X + 5   Le théorème pour k = 1 dit que d1 est égal au pgcd de tous les mineurs d’ordre 1 de la matrice M. Les mineurs d’ordre 1 de la matrice M sont les déterminants des sous-matrices de tailles 1 de M, i.e ce sont les coefficients de la matrice M. Ici on voit que les polynômes M11 et M23 sont premiers entre eux, donc le pgcd des coefficients de la matrice est est 1. Nous avons donc d1 = 1. Remarque 1. En fait nous avons plus exactement d1 ∼ 1, donc d1 peut être -1 ou 1. Si les coefficients de la matrice M avaient été dans Q[X] au lieu de Z[X] alors d1 aurait pu être n’importe quel rationnel non nul. Quelque soit le choix de d1, la matrice diagonale obtenue à la fin respecte les spécifications de l’algorithme de la forme normale de Smith. Cette remarque est valable pour tous les di. Pour k = 2, nous avons d1 ∗d2 qui est égal au pgcd de tous les mineurs d’ordre 2 de la matrice M. Dans la suite nous noterons |M|IJ le déterminant de la sous matrice de M définie par les lignes qui sont dans I et par les colonnes qui sont dans J. Par exemple nous avons : |M|{1,2}{1,2} =      5 2X −X + 6 X + 1      = 2X 2 − 7X + 5 = (X − 1)(2X − 5) De même on a : |M|{1,3}{1,3} =      5 3 + X X + 9 3X + 5      = −X 2 + 3X − 2 = (X − 1)(−X + 2) |M|{1,2}{2,3} =      2X 3 + X X + 1 4      = −X 2 + 4X − 3 = (X − 1)(−X + 3) . . . Si on continue, on s’aperçoit que (X − 1) est le seul facteur commun à tous les mineurs d’ordre 2 de M, donc d1 ∗ d2 = d2 = (X − 1). Enfin pour k = 3, nous avons d1 ∗ d2 ∗ d3 qui est égal au pgcd des mineurs d’ordre 3 de la matrice M. Or la seule sous-matrice de M d’ordre 3 est la matrice2.3 Forme normale de Smith 37 M elle même. Donc d1 ∗ d2 ∗ d3 = det M ce qui donne après calcul (X − 1) ∗ d3 = (X − 1)2 (X − 2) soit d3 = (X − 1)(X − 2). Ainsi la forme normale de Smith de M est la matrice :   1 0 0 0 (X − 1) 0 0 0 (X − 1)(X − 2)   Nous avons vu comment utiliser le théorème précédent pour déterminer de manière unique (modulo la relation ∼) la forme normale de Smtih d’une matrice. Maintenant nous allons voir comment il a été formalisé. Le théorème peut s’exprimer formellement ainsi1 : Lemma Smith_gcdr_spec m n (A : ’M_(m,n)) (d : seq R) k : \prod_(i < k) d‘_i %= \big[gcdr/0]_f \big[gcdr/0]_g minor k f g A . où le premier argument de la fonction minor est l’ordre du mineur. Les fonctions f et g jouent le rôle des ensembles d’indices I et J dans la notation |A|IJ , plus précisément I correspond à l’image de f et J à l’image de g. Soit donc R un anneau principal, une matrice A : ’M[R]_(m,n), et une sé- quence d telle que d soit triée par la relation de division et que la matrice diag_mxseq m n d soit équivalente à A. Le résultat se montre en deux étapes. Dans une première étape nous prouvons le théorème pour la matrice diag_mx_seq m n d (au lieu de A). Comme c’est une matrice diagonale, les seuls mineurs d’ordre k non nuls sont les mineurs principaux, c’est à dire les déterminants de sous-matrices dont la diagonale principale coïncide avec la diagonale de la matrice. Dans notre cas particulier, les mineurs principaux sont égaux au produit de k éléments de la séquence d. Comme chaque élément de la séquence divise le suivant, le pgcd des mineurs d’ordre k est donc le produit des k premiers éléments de la séquence. Nous pouvons ensuite remplacer dans l’énoncé du théorème le membre de gauche \prod_(i < k) d‘_i par l’expression suivante : \big[gcdr/0]_f \big[gcdr/0]_g minor k f g (diag_mx_seq m n d) Dans la seconde étape, il nous reste donc à prouver ceci : \big[gcdr/0]_f \big[gcdr/0]_g minor k f g (diag_mx_seq m n d) %= \big[gcdr/0]_f \big[gcdr/0]_g minor k f g A Cela se prouve par double divisibilité, comme les deux preuves se font de la même manière, nous montrons ici seulement le résultat suivant : \big[gcdr/0]_f \big[gcdr/0]_g minor k f g A %| \big[gcdr/0]_f \big[gcdr/0]_g minor k f g (diag_mx_seq m n d) D’après les propriétés du pgcd, il suffit de montrer que pour tout f’ et g’ nous avons : 1voir 1.2.5, et 1.2.7 pour les notations.38 Forme de Jordan d’une matrice \big[gcdr/0]_f \big[gcdr/0]_g minor k f g A %| minor k f’ g’ (diag_mx_seq m n d) Or nous savons que les matrices A et diag_mx_seq m n d sont équivalentes, il existe donc deux matrices M et N telles que M *m A *m N = diag_mx_seq m n d. En réécrivant cette égalité, il nous reste à prouver : \big[gcdr/0]_f \big[gcdr/0]_g minor k f g A %| minor k f’ g’ (M *m A *m N) Nous avons fait apparaître ici le mineur d’un produit de matrices, nous allons le transformer en une somme de produits de mineurs en utilisant la formule de Binet-Cauchy. Cette formule s’énonce comme suit : det(AB) = X I∈P({1,...,l}) #|I|=k det(AI ) det(BI ) où A est une matrice de taille k × l et B une matrice de taille l × k. Ici det AI = |A|{1,...,k}I et det BI = |B|I{1,...,k}. Ce résultat a été prouvé formellement par Vincent Siles [46]. On peut facilement ramener la formule de Binet-Cauchy à la formule suivante : |AB|IJ = X K |A|IK|B|KJ La formule ci-dessus s’écrirait formellement : minor k f g (A *m B) = \sum_h (minor k f h A) * (minor k h g B) Grâce à ce lemme nous pouvons remplacer minor k f’ g’ (M *m A *m N) par \sum_h \sum_j (minor k f’ h M) * (minor k h j A) * (minor k j g’ N) Or d’après les propriétés du pgcd, pour tout h et j nous avons : \big[gcdr/0]_f \big[gcdr/0]_g minor k f g A %| minor k h j A Donc le pgcd des mineurs d’ordre k de la matrice A divise tous les termes de la somme ci-dessus, ce que nous voulions démontrer. Nous avons vu que les coefficients de la forme normale de Smith peuvent être choisis modulo la relation d’équivalence ∼. Cela implique en particulier, que, pour les matrices carrées, nous pouvons choisir un représentant de la forme normale de Smith d’une matrice A qui a le même déterminant. En effet, soit D la forme normale de Smith d’une matrice A. Nous savons que D est équivalent à la matrice A, il existe donc des matrices L et R inversibles telles que D = LAR. Le fait que L et R soient inversibles signifie que leur déterminant est également inversible. Donc si nous appelons D′ la matrice D dans laquelle nous avons multiplié la première ligne par (detL ∗ det R) −1 alors : • Les éléments diagonaux de D′ sont triés pour la relation de division (car multiplier certains éléments par un inversible ne change pas les classes d’équivalences).2.3 Forme normale de Smith 39 • La matrice D′ est équivalente à la matrice A (car multiplier une ligne par un élément inversible est une opération réversible et donc conserve l’équivalence). Formellement nous avons : Definition Smith_seq m n (M : ’M[E]_(m,n)) := let: (L,d,R) := (Smith _ M) in if d is a :: d’ then (\det L)^-1 * (\det R)^-1 * a :: d’ else nil. Definition Smith_form m n (A : ’M[R]_(m,n)) := diag_mx_seq m n (Smith_seq A). Lemma det_Smith n (A : ’M[R]_n) : \det (Smith_form A) = \det A. Le théorème d’unicité de la forme normale de Smith d’une matrice s’énonce formellement comme suit : Lemma Smith_unicity m n (A : ’M[R]_(m,n)) (s : seq R) : sorted %| s -> equivalent A (diag_mx_seq m n s) -> forall i, i < minn m n -> s‘_i %= (Smith_seq A)‘_i. 2.3.3 Facteurs invariants Dans la section 2.2.2, nous avons vu que nous pouvons déterminer si deux matrices carrées A et B à coefficients dans un corps sont semblables en comparant les formes normales de Smith de leur matrice caractéristique. Ensuite nous avons montré dans la section précédente un théorème qui permet de montrer l’unicité de la forme normale de Smith, mais dont nous nous servirons plus tard pour déterminer les éléments diagonaux de la forme normale de Smith d’une matrice par des calculs de pgcd. Nous allons présenter maintenant les facteurs invariants. La forme normale de Smith de la matrice XI − A est une matrice diagonale à coefficients polynômiaux. Les polynômes non-constants qui apparaissent sur la diagonale sont les facteurs invariants de la matrice A. Le théorème fondamental et le résultat d’unicité nous disent que les facteurs invariants sont des invariants de similitude, c’est-à-dire que deux matrices sont semblables si et seulement si elles ont les mêmes facteurs invariants. Nous allons voir ici comment les facteurs invariants d’une matrice ont été définis formellement. Rappelons que la forme normale de Smith d’une matrice à coefficients dans un anneau principal est unique modulo la relation d’équivalence ∼. Or dans notre contexte, l’anneau principal sur lequel nous travaillons est l’anneau des polynômes à coefficients dans un corps. Dans ce cas-ci, si p est un polynôme non nul alors il existe un unique représentant unitaire de la classe d’équivalence de p qui est p divisé par son coefficient dominant.40 Forme de Jordan d’une matrice Nous pouvons donc définir une nouvelle séquence qui vérifie les mêmes spé- cifications que la séquence Smith_seq mais qui ne contient que des polynômes unitaires1 : Definition Frobenius_seq n (A : ’M_n) := [seq (lead_coef p)^-1 *: p | p <- (Smith_seq (char_poly_mx A))]. Les facteurs invariants sont les polynômes non constants de cette séquence : Definition invariant_factors n (A : ’M_n) := [seq p : {poly R} <- (Frobenius_seq A) | 1 < size p]. 2.4 Forme normale de Frobenius La forme normale de Frobenius d’une matrice M est la matrice diagonale par blocs dont les blocs diagonaux sont les matrices compagnes des facteurs invariants de M. Nous avons déjà vu comment sont définies formellement les matrices diagonales par blocs. Nous avons vu ensuite ce qu’était la forme normale de Smith, ce qui nous a permis de définir les facteurs invariants d’une matrice. Il nous reste donc à donner une définition formelle des matrices compagnes pour pouvoir dé- finir la forme normale de Frobenius. Nous prouverons ensuite que toute matrice carrée à coefficients dans un corps est semblable à sa forme normale de Frobenius. 2.4.1 Matrices compagnes La matrice compagne d’un polynôme unitaire p = Xn+an−1Xn−1+. . .+a1X +a0 est la matrice suivante : Cp =   0 . . . . . . 0 −a0 1 . . . . . . −a1 0 . . . . . . . . . . . . . . . . . . . . . 0 . . . 0 . . . 0 1 −an−1   Cette matrice est intéressante car p est à la fois son polynôme caractéristique et son polynôme minimal. Formellement, si p est un polynôme, la taille de la matrice compagne de p est (size p).-1. Mais ici encore, si nous voulons utiliser des opérations génériques d’anneaux sur des matrices compagnes, il faut que leur taille soit de la forme n.+1. Pour cela nous définissons les matrices compagnes de sorte que leur type soit (size p).-2.+1 : 1voir 1.1.5, 1.2.6 et 1.2.9 pour les notations.2.4 Forme normale de Frobenius 41 Definition companion_mx (p : {poly R}) := \matrix_(i,j < (size p).-2.+1) ((i == j.+1 :> nat)%:R + p‘_i *+ ((size p).-2 == j)). Nous avons (size p).-2.+1 = (size p).-1 si et seulement si 1 < (size p), c’est-à-dire si p est un polynôme non constant. La définition de matrice compagne n’est donc valide que pour les polynômes non constants. En pratique ceci ne devrait pas être trop contraignant car les matrices compagnes de polynômes constants sont des matrices vides et sont donc inintéressantes dans un certain sens. Malheureusement, avec cette définition de matrices compagnes, nous ne pouvons pas définir de matrice diagonale par blocs dont les blocs sont des matrices compagnes. En effet, le type de la fonction qui retourne les blocs diagonaux de la matrice est forall n, nat -> ’M_n.+1 ; c’est donc une fonction qui prend un entier n, un entier et qui retourne une matrice de type ’M_n.+1, mais si la matrice retournée est une matrice compagne d’un polynôme p, alors son type sera ’M_(size p).-2.+1 et non ’M_n.+1. Pour résoudre ce problème, nous définissons les matrices compagnes en deux étapes. Nous définissons d’abord une fonction companion_mxn qui prend en argument un entier n et un polynôme p, et qui retourne une matrice de type ’M_n telle que si n = (size p).-2.+1 alors la matrice retournée correspond à la matrice compagne du polynôme p. Nous pouvons donc ensuite définir la matrice compagne d’un polynôme p comme étant la matrice retournée par la fonction companion_mxn appliquée aux arguments (size p).-2.+1 et p : Definition companion_mxn n (p : {poly R}) := \matrix_(i,j < n) ((i == j.+1 :>nat)%:R + p‘_i *+ ((size p).-2 == j)). Definition companion_mx (p : {poly R}) := companion_mxn (size p).-2.+1 p. Ainsi pour faire une matrice diagonale par blocs, nous pouvons utiliser la fonction companion_mxn, car companion_mxn n.+1 a le type ’M_n.+1 qui est bien de la bonne forme. Les lemmes sur les matrices compagnes seront exprimés, eux, sur companion_mx. Nous pouvons maintenant donner une définition formelle de la forme normale de Frobenius d’une matrice. Elle se présente de la manière suivante :   Cp1 Cp2 0 0 . . . Cpk   où les polynômes pi sont les facteurs invariants de la matrice. Formellement, nous la définissons comme suit :42 Forme de Jordan d’une matrice Definition Frobenius_form n (A : ’M_n) := let sizes := [seq (size p).-2 | p <- (invariant_factors A)] in let blocks n i := companion_mxn n.+1 (invariant_factors A)‘_i in diag_block_mx sizes blocks. 2.4.2 De Smith à Frobenius Maintenant que nous avons défini la forme normale de Frobenius d’une matrice, nous allons montrer ici que toute matrice sur un corps F est semblable à sa forme normale de Frobenius : Lemma Frobenius n (A : ’M[F]_n.+1) : similar A (Frobenius_form A). Comme nous l’avons annoncé, pour prouver ce résultat nous utilisons le théorème fondamental. Il nous faut donc montrer que pour toute matrice A, les matrices caractéristiques de A et Frobenius_form A sont équivalentes. Soit une matrice A, nous allons partir de la matrice XI − A et arriver à la matrice caractéristique de Frobenius_form A par transitivité de l’équivalence. Nous avons vu que la séquence Frobenius_seq A respecte les spécifications de l’algorithme de Smith. Donc la matrice XI − A est équivalente à la matrice diag_mx_seq n.+1 n.+1 (Frobenius_seq A), qui se présente de la façon suivante :   1 . . . 0 1 p1 0 . . . pn   où les pi sont les facteurs invariants de la matrice A. Ici nous allons utiliser le résultat suivant pour justifier le fait que nous pouvons permuter les éléments diagonaux : Lemma similar_diag_mx_seq m n s1 s2 : m = n -> size s1 = m -> perm_eq s1 s2 -> similar (diag_mx_seq m m s1) (diag_mx_seq n n s2). où perm_eq s1 s2 exprime le fait que les séquence s1 et s2 ont les mêmes éléments mais permutés. En effet, si deux matrices diagonales ont leurs éléments diagonaux permutés, alors la matrice de passage de l’une à l’autre est une matrice de permutation qui est inversible ; donc les deux matrices sont semblables, et donc à fortiori équivalentes. Nous pouvons ainsi permuter les éléments diagonaux de la matrice2.4 Forme normale de Frobenius 43 précédente :   1 . . . 1 p1 0 . . . 0 1 . . . 1 pn   Si pi représente le polynôme pi , alors (size pi).-2 représente le nombre de 1 avant chaque pi . Cette matrice peut être vue comme la matrice diagonale par blocs suivante :   1 . . . 1 p1 0 0 . . . 1 . . . 1 pn   Nous voulons maintenant montrer que cette matrice est équivalente à la matrice caractéristique de la forme normale de Frobenius de A. Nous utilisons d’abord le fait que la matrice caractéristique d’une matrice diagonale par blocs est la matrice diagonale par blocs des blocs caractéristiques : Lemma char_diag_block_mx s (F : forall n, nat -> ’M[R]_n.+1) : s != [::] -> char_poly_mx (diag_block_mx s F) = diag_block_mx s (fun n i => char_poly_mx (F n i)). Il ne nous reste donc plus qu’à montrer que la matrice précédente est équivalente à :   XI − Cp1 . . . 0 0 . . . XI − Cpn   Nous voulons donc montrer que deux matrices diagonales par blocs sont équivalentes. Pour cela, il nous suffit de prouver que les matrices sont équivalentes bloc44 Forme de Jordan d’une matrice à bloc. C’est-à-dire que pour chaque indice i, la matrice XI − Cpi est équivalente à :   1 . . . 1 pi   Pour montrer ce dernier résultat, nous utilisons le lemme Smith_gcdr_spec vu plus haut. En effet, pour tout k tel que k < (size pi).-2, on peut trouver une sous-matrice de la matrice XI − Cpi ci-dessous n’ayant que des −1 sur la diagonale : XI − Cpi =   X . . . 0 0 a0 −1 . . . . . . . . . a1 0 . . . X . . . . . . . . . . . . −1 X . . . 0 . . . 0 −1 X + an−1   Donc si nous calculons la forme normale de Smith de la matrice ci-dessus comme nous l’avons fait dans l’exemple 1, nous remarquons que pour tout k strictement plus petit que (size pi).-2, il existe un mineur d’ordre k associé à 1 (car (−1)k ∼ 1), et donc le pgcd de ces mineurs est lui-même associé à 1. Ainsi tous les éléments diagonaux de la forme normale de Smith de la matrice XI − Cpi sont égaux à 1, sauf le dernier qui lui est égal au déterminant de la matrice XI − Cpi , c’est-à-dire à pi . Le fait qu’une matrice est équivalente à sa forme normale de Smith termine la démonstration. 2.5 Forme normale de Jordan La forme normale de Jordan d’une matrice A est une matrice triangulaire supé- rieure dont les éléments diagonaux sont les racines du polynôme caractéristique de la matrice A (c’est-à-dire les valeurs propres de A). Pour que cette forme existe, il suffit que le polynôme caractéristique soit scindé à racines simples. Afin d’assurer cette condition, nous choisissons de travailler sur un corps algébriquement clos F. Nous avons montré dans la section précédente qu’une matrice était semblable à sa forme normale de Frobenius. Nous allons ici dans un premier temps donner une définition formelle de la forme normale de Jordan. Nous montrerons ensuite que la forme normale de Frobenius d’une matrice est semblable à la forme normale de Jordan de celle-ci. Par transitivité de la similitude nous aurons donc qu’une matrice est semblable à sa forme normale de Jordan.2.5 Forme normale de Jordan 45 2.5.1 Définitions On appelle bloc de Jordan la matrice de dimension n suivante : J(λ, n) =   λ 1 0 . . . 0 0 . . . . . . . . . . . . . . . . . . . . . . . . 0 . . . . . . . . . 1 0 . . . . . . 0 λ   Formellement, cela se définit simplement de la manière suivante : Definition Jordan_block lam n : ’M[F]_n := \matrix_(i,j) (lam *+ (i == j) + (i.+1 == j)%:R). La forme normale de Jordan est une matrice diagonale par blocs composée de blocs de Jordan1 : Definition Jordan_form n (A : ’M[R]_n.+1) := let sp := root_seq_poly (invariant_factors A) in let sizes := [seq x.1 | x <- sp] in let blocks n i := Jordan_block (nth (0,0) sp i).2 n.+1 in diag_block_mx sizes blocks. où la fonction root_seq_poly prend en argument une séquence de polynômes et retourne la concaténation des séquences des paires multiplicité/racine de chaque polynôme de la séquence. Par exemple si on a la séquence de polynômes suivante : [:: (’X - (sqrt 2))^+ 4, (’X - (sqrt 2))^+ 4, (’X - 1)^+3 *(’X - 2)] alors la séquence retournée par root_seq_poly sera : [:: (4,(sqrt 2))] ++ [:: (4,(sqrt 2))] ++ [:: (3,1), (1,2)] = [:: (4,sqrt2), (4,sqrt2), (3,1), (1,2)] Dans la suite nous expliquons le passage de la forme normale de Frobenius à celle de Jordan. Cela permettra de mieux comprendre la définition donnée cidessus. 2.5.2 De Frobenius à Jordan Soit A une matrice à coefficients dans un corps clos F. Nous avons déjà prouvé que la matrice A est semblable à sa forme normale de Frobenius. Nous allons maintenant montrer que la forme normale de Frobenius de A est semblable à sa forme normale de Jordan. Ce qui nous permettra de montrer le lemme suivant : Lemma Jordan n (A : ’M[F]_n.+1) : similar A (Jordan_form A). La preuve de ce lemme utilise deux résultats intermédiaires. Le premier résultat intermédiaire est le lemme suivant : 1voir 1.1.1 et 1.1.5 pour les notations.46 Forme de Jordan d’une matrice Lemme 2. Soit q un polynôme, soit (qi)1≤i≤m une famille de polynômes unitaires premiers entre eux deux à deux telle que q = q1 . . . qm, alors la matrice Cq est semblable à la matrice :   Cq1 . . . 0 0 . . . Cqm   Montrons d’abord ce lemme pour m = 2. Soit donc deux polynômes unitaires q1 et q2 premiers entre eux, et soit q = q1q2. Nous voulons montrer que la matrice Cq est semblable à la matrice : Cq1 0 0 Cq2 ! Là encore nous utilisons le théorème fondamental, pour se ramener à montrer l’équivalence entre XI − Cq et la matrice : XI − Cq1 0 0 XI − Cq2 ! D’après ce que nous avons déjà vu cela revient à montrer que la matrice   1 . . . 1 q   est équivalente à la matrice   1 . . . 1 q1 0 0 1 . . . 1 q2   Autrement dit, il faut montrer que le seul facteur invariant de la matrice cidessus est le polynôme q. Pour cela nous allons utiliser une fois de plus le lemme Smith_gcdr_spec. En effet, pour tous les ordres k strictement plus petit que la taille de la matrice ci-dessus, on peut trouver un mineur principal égal à q1, et un autre égal à q2, et comme q1 et q2 sont premiers entre eux, le pgcd des mineurs d’ordre k est égal à 1. Donc les éléments diagonaux de la forme normale de Smith2.5 Forme normale de Jordan 47 de la matrice ci-dessus sont donc tous égaux à 1, sauf le dernier qui correspond au déterminant de la matrice ci-dessus qui est q1q2 = q. Le lemme général en découle directement par récurrence. Le deuxième résultat intermédiaire est celui-ci : Lemme 3. Soit K un corps. Soit λ ∈ K et n ∈ N. alors la matrice C(X−λ)n est semblable à la matrice J(λ, n). Ici nous pouvons directement donner la matrice de passage P définie comme suit : Pij = j − 1 n − i ! λ (i+j)−(n+1) Mais la vérification formelle est assez longue. Sinon nous pouvons utiliser une nouvelle fois le théorème fondamental, et montrer que XI−C(X−λ)n est équivalente à la matrice XI − J(λ, n). D’après ce que nous savons déjà sur les matrices compagnes, nous voulons montrer que la matrice :   1 . . . 1 (X − λ) n   est équivalente à la matrice :   X − λ −1 0 . . . 0 0 . . . . . . . . . . . . . . . . . . . . . . . . 0 . . . . . . . . . −1 0 . . . . . . 0 X − λ   Ici encore, nous allons utiliser le lemme Smith_gcdr_spec. En effet, pour tout k < n, nous pouvons trouver dans la matrice ci-dessus un mineur d’ordre k égal à (−1)k , et donc associé à 1. Donc par les mêmes raisonnement que précédemment, le seul facteur invariant de la matrice ci-dessus est (X − λ) n . Maintenant nous pouvons passer à la preuve de la similitude entre les formes normales de Frobenius et de Jordan d’une matrice. Comme nous sommes sur un corps clos, alors chaque facteur invariant pi de la matrice A peut se décomposer comme suit : pi = Ymi j=1 (X − λij ) µij où les λij sont les racines de pi et les µij leur multiplicité.48 Forme de Jordan d’une matrice Donc d’après le lemme 2 montré ci-dessus, chaque bloc Cpi de la forme normale de Frobenius est semblable à la matrice :   C(X−λi1) µi1 . . . 0 0 . . . C(X−λimi ) µimi   et d’après le lemme 3, chacun des blocs C(X−λij ) µij de la matrice ci-dessus est semblable au bloc de Jordan J(λij , µij ). Les paires (λij , µij ) sont les paires qui se trouvent dans la séquence retournée par la fonction root_seq_poly appliquée à la séquence des facteurs invariants. Cela explique la définition de la forme normale de Jordan donnée plus haut, et démontre aussi que la forme normale de Frobenius de A est semblable à la forme normale de Jordan de A. 2.5.3 Diagonalisation En plus de la forme normale de Jordan, la théorie des facteurs invariants permet de donner également un théorème de diagonalisation. Une matrice est diagonalisable, c’est-à-dire semblable à une matrice diagonale, si son polynôme minimal est scindé et à racines simples. Nous allons voir ici comment nous prouvons ce résultat. Commençons par montrer le théorème suivant : Théorème 4. Soit A une matrice à coefficients dans un corps. Si les polynômes p1 . . . pk sont les facteurs invariants de la matrice A tels que p1 | p2 | . . . | pk, alors le polynôme pk est le polynôme minimal de la matrice A. Soit donc A une matrice à coefficients dans un corps. Comme la matrice A et la forme normale de Frobenius de A sont semblables, ces deux matrices ont le même polynôme minimal. Donc montrer que pk est le polynôme minimal de A revient à montrer que pk est le polynôme minimal de la forme normale de Frobenius de A. Pour cela, nous allons montrer d’une part que pk est un polynôme annulateur de la forme normale de Frobenius de A, et d’autre part que pk divise n’importe quel polynôme annulateur de la forme normale de Frobenius de A. Un polynôme p est annulateur de la matrice A si p(A) = 0. Cela peut s’exprimer formellement grâce à la fonction horner_mx de la bibliothèque SSReflect comme suit : horner_mx A p = 0 Dans cette preuve, nous utiliserons le fait qu’appliquer un polynôme à une matrice diagonale par blocs revient à appliquer le polynôme à chacun des blocs. Ce qui s’exprime formellement de la façon suivante.2.6 Conclusion 49 Lemma horner_mx_diag_block (p : {poly R}) s F : s != [::] -> horner_mx (diag_block_mx s F) p = diag_block_mx s (fun n i => horner_mx (F n i) p). Donc pour montrer que le polynôme pk annule la forme normale de Frobenius de A, il faut et il suffit que pk annule chaque matrice compagne des facteurs invariants. Soit donc pi un facteur invarant de la matrice A. D’après les propriétés des matrices compagnes, nous savons que pi est le polynôme minimal de la matrice Cpi . De plus comme les facteurs invariants se divisent successivement, nous savons également que pi | pk. Donc pk est un polynôme annulateur de Cpi . Maintenant il reste à montrer que pk divise tous les polynômes annulateurs de la forme normale de Frobenius de A. Soit donc Q un polynôme annulateur de la forme normale de Frobenius de A. Alors nous savons que Q est un polynôme annulateur de chacun des blocs de la forme normale de Frobenius de A. En particulier Q annule Cpk , or nous savons également que pk est le polynôme minimal de la matrice Cpk . Donc pk | Q. Le polynôme pk étant un polynôme annulateur de la forme normale de Frobenius de A qui divise tous les autres polynômes annulateurs est donc le polynôme minimal de la forme de Frobenius de A et donc de A. Ainsi nous avons d’une part que le polynôme pk est le polynôme minimal de la matrice A, et d’autre part que tous les facteurs invariants divisent pk. Autrement dit tous les facteurs invariants de la matrice A divisent son polynôme minimal. Donc si le polynôme minimal de A est scindé à racines simples, alors c’est aussi le cas des facteurs invariants. Or la taille des blocs de la forme normale de Jordan de A sont les multiplicités des racines des facteurs invariants. Donc dans le cas où le polynôme minimal de A est scindé à racines simples, tous les blocs de la forme normale de Jordan de la matrice A sont de taille 1, c’est donc une matrice diagonale. Ce qui nous donne le théorème suivant : Lemma ex_diagonalization n (A : ’M[R]_n.+1) : uniq (root_seq (mxminpoly A)) -> {s | similar A (diag_mx_seq n.+1 n.+1 s)}. où root_seq est la fonction qui retourne la séquence des racines d’un polynôme et uniq est un prédicat booléen qui prend la valeur true si la séquence passée en argument n’a pas de doublons. 2.6 Conclusion Nous avons utilisé ici les matrices de la bibliothèque SSReflect. Le type de ces matrices dépend de leurs dimensions, et cela a posé quelques problèmes. Cependant nous avons vu qu’il y avait des outils (comme conform_mx) qui ont permis de résoudre certains de ces problèmes.50 Forme de Jordan d’une matrice Au départ, pour prouver certains lemmes de similitude, nous donnions directement les matrices de passages, et nous avions de longues preuves faites de traitements par cas exhaustifs. L’idée d’utiliser de manière assez systématique le théorème fondamental et le lemme Smith_gcdr_spec à grandement simplifié les preuves. Ce travail, en plus de la formalisation de la forme normale de Jordan d’une matrice, a apporté une bibliothèque sur les matrices diagonales par blocs, sur les matrices compagnes, et sur les propriétés de similitude et d’équivalence de matrices. Ce sont des concepts importants de l’algèbre linéaire utilisés dans d’autres contextes mathématiques que celui de ce chapitre. Nous avons aussi montré la formalisation de la forme normale de Frobenius d’une matrice. L’avantage de cette forme normale est que ses coefficients sont dans le même corps que les coefficients de la matrice de départ. Contrairement à la forme de Jordan, où l’on peut avoir des coefficients dans la clôture algébrique. 2.7 Travaux reliés Le développement de la forme normale de Smith que nous avons utilisé dans ce chapitre fait parti d’un projet qui s’appelle CoqEAL(Coq Efficient Algebra Library)1 . Le but de ce projet est de faire des algorithmes effectifs d’algèbre linéaire en utilisant l’extension SSReflect de Coq. Dans les autres assistants de preuve, il existe d’autres travaux qui ont été faits sur les matrices. En HOL, les matrices sont vues comme des vecteurs de vecteurs [23]. En ACL2 elles sont représentées soit par des listes de vecteurs de même dimensions [49] soit par des tableaux [17]. En Isabelle, ce sont des fonctions telles que l’ensemble des images non nulles de ces fonctions soit fini [36]. À ma connaissance, seul l’assistant de preuve Mizar possède des travaux sur les matrices diagonales par blocs et sur la forme de Jordan d’une matrice [41]. Mizar est un assistant de preuve basé sur la théorie des ensembles contrairement à Coq qui est basé sur la théorie des types. En Mizar, une séquence finie est une fonction dont le domaine de définition est l’ensemble des entiers de 1 à n pour un certain n ∈ N. Une matrice M à m lignes et n colonnes est une séquence finie de séquences finies de longueur m tel que toute séquence finie de l’image de M soit de longueur n [27]. Une matrice diagonale par blocs est construite à partir d’une séquence finie de matrices carrées. Elle est définie comme étant la matrice dont l’élément (i, j) est 02 si l’on se trouve en dehors des blocs et l’éléments f(i), g(j) d’une matrice de la séquence sinon (pour certaines fonctions f et g) [39]. 1http://www.maximedenes.fr/content/coqeal-coq-effective-algebra-library 2En fait, la définition de Mizar de matrice diagonale par block permet de remplir la matrice hors des blocs diagonaux par un élément d que l’on peut passer en paramètre.Chapitre 3 Topologie Dans ce chapitre, nous allons présenter un résultat important de topologie géné- rale qui est le théorème de Bolzano-Weierstraß. Ce théorème porte sur les valeurs d’adhérence des suites dont les valeurs sont dans un ensemble compact. Tous le travail sur la topologie et sur la théorie des ensembles est formalisé dans un cadre fortement classique, c’est-à-dire avec l’axiome du tiers exclu et l’axiome du choix. Nous avons besoin de ces axiomes pour prouver le théorème de Bolzano-Weierstraß. Il existe dans la bibliothèque standard de Coq un fichier Rtopology.v1 qui contient déjà certaines notions que nous allons présenter dans ce chapitre. Mais ces notions ne sont définies que pour les réels de Coq. Nous présentons ici un travail plus général. Nous commencerons par voir quelques points de la théorie des ensembles dont nous aurons besoin pour la formalisation de la topologie générale. Nous verrons ensuite comment sont définies les structures d’espaces métriques et topologiques, et nous terminerons par une présentation du théorème. 3.1 Théorie des ensembles Pour parler d’ensembles ouverts, fermés ou compacts, il faut d’abord définir ce qu’est un ensemble. La notion d’ensemble utilisée dans cette formalisation est celle que l’on peut trouver dans la bibliothèque Sets de la bibliothèque standard de Coq2 , à savoir qu’un ensemble d’éléments de type T est identifié à un prédicat de type T -> Prop. Cependant nous n’utiliserons pas la théorie des ensembles ainsi développée dans Coq, car par exemple les définitions d’union, d’intersection, ou de complémentaire sur les ensembles sont intoduites explicitement à l’aide de types inductifs, alors que ces notions peuvent être définies comme une réinterprétation des opérateurs ”et”, ”ou”, ”non” de la logique propositionnelle. L’égalité utilisée entre les ensembles est l’égalité par inclusion mutuelle, mais 1http://coq.inria.fr/distrib/current/stdlib/Coq.Reals.Rtopology.html 2http://coq.inria.fr/distrib/current/stdlib/52 Topologie nous avons tout de même besoin de la propriété d’extensionnalité. Plutôt que d’ajouter cette propriété comme axiome, nous allons voir comment faire en sorte d’utiliser l’égalité ensembliste comme l’égalité de Leibniz. Nous nous attarderons ensuite sur la définition de famille d’ensembles car nous en aurons besoin pour définir ce qu’est un ensemble compact. 3.1.1 Réécriture La tactique rewrite en Coq permet à partir d’une hypothèse de type x = y (où = représente l’égalité de Leibniz) de changer des occurences de x par des occurences de y et vice versa. Si on remplace l’égalité de Leibniz par une relation d’équivalence, on peut aussi utiliser la tactique rewrite si x et y apparaissent dans une fonction dont on a montré qu’elle était compatible avec la relation d’équivalence, c’est-à-dire que sa valeur ne dépend pas du représentant choisi dans la classe d’équivalence. C’est ce que nous allons voir ici avec comme relation d’équivalence l’égalité entre ensembles. L’égalité entre ensembles est définie comme suit : Variable T : Type. Definition eqset (A B : T -> Prop) := forall x, x ’in A <-> x ’in B. Notation "A =s B" := (eqset A B). où x ’in A est une notation pour A x. C’est une relation d’équivalence. Pour que le système Coq puisse la reconnaître comme telle, il faut la déclarer de la manière suivante : Add Relation _ eqset reflexivity proved by eqset_refl symmetry proved by eqset_sym transitivity proved by eqset_trans as eqset_rel. où eqset_refl,eqset_sym, et eqset_trans sont respectivement les lemmes de re- flexivité, symétrie et de transitivité de la relation eqset. Puis il faut indiquer à Coq quelles sont les fonctions sous lesquelles on peut réécrire avec la relation eqset, c’est-à-dire les fonctions qui sont compatibles avec la relation eqset. Pour cela on utilise les mots clefs Add Morphism. Prenons comme exemple l’inclusion. L’inclusion est définie comme suit : Definition include (A B : T -> Prop) := forall x, x ’in A -> x ’in B. Notation "A eqset ==> iff as include_mor. Proof. ... Qed. Une manière de lire la signature est que si deux ensembles vérifient la relation eqset, et que deux autres ensembles vérifient également la relation eqset, alors nous avons deux propositions d’inclusions qui vérifient la relation iff, autrement dit qui sont équivalentes. Le système nous demande donc de prouver l’énoncé suivant : forall x y : T -> Prop, x =s y -> forall x0 y0 : T -> Prop, x0 =s y0 -> (x y Prop; F :> Ti -> T -> Prop }. Dans cette définition, il n’y a pas de dépendance entre la fonction F et l’ensemble d’indices ind. Donc dans certaines définitions et certains lemmes, il faudra préciser que l’on ne s’intéresse qu’aux indices appartenant à l’ensemble d’indices54 Topologie de la famille. En effet, si nous avons un indice i : Ti qui n’appartient pas à l’ensemble ind, alors F i est un ensemble qui n’appartient pas à la famille, et donc on ne voudrait pas que cet ensemble soit pris en compte dans certaines preuves ou définitions. Les autres définitions dont nous aurons besoin pour la définition d’ensemble compact sont celles de sous-famille, de famille finie et de recouvrement d’un ensemble par une famille. Une sous-famille est définie comme un prédicat qui prend deux familles, et qui vérifie que l’ensemble d’indices de l’une est bien un sous-ensemble de l’ensemble d’indices de l’autre, et que sur ce sous-ensemble d’indices commun, les ensembles des deux familles sont les mêmes : Definition sub_family f g := ind g f i =s g i. Pour les familles finies, nous avons le choix entre définir un prédicat comme pour les sous-familles, ou définir un type “famille finie”. Dans le premier cas, à chaque usage d’une définition sur les familles finies, nous devrons fournir une preuve que la famille passée en argument est finie. Alors que dans le second cas, l’information qu’une famille est finie est donnée par le typage. Cette dernière option permet d’avoir des définitions qui ne dépendent pas d’un terme de preuve. Une famille est finie si son ensemble d’indices est un ensemble fini : Definition finite_set (T1 : eqType) (A : T1 -> Prop) := exists s : seq T1, A =s (fun x => x \in s). Structure finite_family := Ff { fam :> family; _ : finite_set (ind fam) }. Une fois que nous avons défini les familles, nous pouvons appliquer des opé- rations dessus, comme l’union ou l’intersection des éléments d’une famille. Nous donnons ici uniquement l’opération qui nous intéresse pour la définition de recouvrement : Definition union_fam (f : family) (x : T) := exists i, i ’in (ind f) /\ x ’in (f i). Definition cover (A : T -> Prop) (f : family) := A Prop) -> Prop. L’union de tous les ensembles d’un ensemble d’ensembles est définie comme suit : Definition union_s (E : (T -> Prop) -> Prop) (f : (T-> Prop) -> (T -> Prop)) (x : T) := exists A, A ’in E /\ x ’in (f A). Par exemple, si E est un ensemble d’ensembles et f une fonction sur les ensembles, alors union_s E f représente l’ensemble suivant : [ A∈E f(A) Donc pour faire l’union des ensembles de E nous utiliserons la fonction identité pour f. On peut maintenant définir la structure d’espace topologique simplement comme suit :56 Topologie Structure Topologicalspace : Type := mkTS { T_Space : Type; open : (T_Space -> Prop) -> Prop; _ : open {ø : T_Space}; _ : open {full : T_Space}; _ : forall (E : (T_Space -> Prop) -> Prop), E open (union_s E id); _ : forall A B, open A -> open B -> open (inter A B); _ : forall A B, A =s B -> (open A <-> open B) }. Le dernier champ de la structure est la propriété d’extensionnalité pour les ouverts. Les ouverts étant définis axiomatiquement, cette propriété utile ne peut être démontrée, et a donc dû être ajoutée à la définition d’espace topologique. Espace Métrique Un espace métrique est un ensemble de points muni d’une distance. Il existe déjà une définition de cette structure dans le fichier Rlimit.v de la bibliothèque standard de Coq1 . Dans cette définition le type de retour de la fonction distance est le type des réels de Coq. Ici on s’autorise à ce que ce soit une structure ordonnée plus générale : Structure Metricspace (Rn : numDomainType) := mkMS { T_metric : Type. dist : T_metric -> T_metric -> Rn; _ : forall x y, 0 <= dist x y ; _ : forall x y, dist x y = dist y x; _ : forall x y, reflect (x = y) (dist x y == 0); _ : forall x y z, dist x y <= dist x z + dist z y }. L’espace métrique prend en paramètre le type de retour de la distance dist. Ce type de retour doit être une structure ordonnée. Au début ce paramètre n’existait pas. Le type de retour de la fonction distance était directement le type des réels de Coq. Le problème était que l’on ne pouvait pas déclarer la structure numDomainType par exemple comme une instance de la structure d’espace mé- trique. Car la fontion de distance que l’on définit pour cela utilise la fonction ‘|.| dont le type de retour est une instance abstraite de la structure numDomainType et non le type concret des réels de Coq. Mettre le type de retour de la fonction distance en paramètre de la structure d’espace métrique permet d’implémenter la structure d’espace métrique sur des types plus abstraits comme le type des corps réels clos, des corps archimédiens, ou des complexes. Pour un ensemble E de type Metricspace, on utilisera la notation suivante : Notation d := (dist E). 1http://coq.inria.fr/distrib/current/stdlib/Coq.Reals.Rlimit.html3.2 Structures Topologiques 57 La principale notion utilisée pour étudier les propriétés métriques et topologiques d’un espace métrique est la notion de boule. Une boule est un ensemble défini à partir d’un élément de l’espace métrique qui sera appelé centre, et d’un rayon représenté par un nombre strictement positif. Pour éviter d’avoir dans la définition de boule une preuve que le rayon est strictement positif, on peut définir un type des nombres strictement positifs comme suit : Structure posDomain (T: numDomainType) := PosD { sort :> T ; _ : 0 < sort }. Notation "{ ’posD’ T }" := (posDomain T). Ceci permet de définir les boules comme suit : Variable Rn : numDomainType. Variable E : (MetricSpace Rn). Definition open_ball (x: E) (r : {posD Rn}) (y : E) := d x y < r. Notation "’’B’ ( x , r )" := (open_ball x r). Nous allons voir maintenant comment inférer les instances de structures canoniques avec les définitions ci-dessus. Les structures que nous définirons ensuite contiendrons les mêmes axiomes. Ce qui changera sera seulement la façon d’implémenter les structures. 3.2.2 Approche naïve Pour déclarer dans le système Coq qu’un espace métrique possède canoniquement une structure d’espace topologique il faut d’abord définir ce qu’est un ensemble ouvert dans un espace métrique : Variable Rn : numDomainType. Variable E : (Metricspace Rn). Definition open_met (A : E -> Prop) := forall x, x ’in A -> exists r, ’B(x,r) Prop) -> Prop; _ : open . . . _ : . . . ... }. Cette structure ne suffit pas, car comme le type de base n’est plus un champ de la structure, lors de la déclaration de structure canonique, la projection vers le type de base n’existera pas. Les projections enregistrées correspondent seulement aux champs de la structure qui sont nommés. Nous allons donc définir une deuxième structure qui va correspondre à notre type final d’espace topologique (ou métrique) : Notation class_of := mixin_of Structure type := Pack {sort : Type; _ : class_of sort}. Coercion sort : type >-> Sortclass. La structure class_of est habituellement utilisée pour assurer l’héridité dans les structures héréditaires. Comme ici nous n’avons pas d’hérédité, class_of est seulement une notation utilisée pour des raisons d’uniformité des définitions. Ces structures sont définies dans un module, par exemple ici dans le module Topology. Ce qui fait qu’en dehors du module les noms des structures seront de la forme Topology.type ce qui permet d’avoir des noms uniformes. Chacune de ces nouvelles définitions sera utilisée avec les notations suivantes : Notation topologyType := type. Notation TopologyMixin := Mixin. Notation TopologyType T m := (@Pack T m). Nous avons donc séparé le type de base et les axiomes de la structure que nous avons mis dans une boîte que nous avons appelée mixin_of. Cette boîte a été mise dans une deuxième structure appelée type qui contient comme premier champ le type sur lequel nous voulons déclarer l’instance, et comme deuxième champ la boîte qui contient toutes les propriétés que doit vérifier le type en question. Pour revenir au problème qui nous intéresse, avec ces nouvelles structures nous allons déclarer l’instance canonique d’espace topologique à partir d’un espace métrique :3.3 Bolzano-Weierstraß 61 Variable Rn : numDomainType. Variable E : (espMetType Rn). Definition EspMet_TopMixin := Eval hnf in TopologyMixin empty_in_open_met full_in_open_met . . . Definition EspMet_TopType := Eval hnf in TopologyType E EspMet_TopMixin. Canonical EspMet_TopMixin. Canonical EspMet_TopType. Nous déclarons ensuite de la même manière que l’ensemble des nombres réels de Coq (représenté par R) a une structure d’espace métrique : Definition EspMet_RMixin := EspMetMixin R_dist_pos . . . Definition EspMet_R := Eval hnf in EspMetType R R EspMet_RMixin. ... Et maintenant pour dire que le type R des réels de Coq a une structure d’espace topologique, nous allons utiliser la fonction TopologyType. Comme nous voulons que la projection se fasse directement sur R, nous allons donner comme premier argument R. Le deuxième argument doit être la structure mixin_of, la notation EspMet_TopMixin permet justement de construire cette structure. Nous pouvons donc déclarer la structure d’espace topologique sur R directement comme ceci : Definition EspTop_R := TopologyType R (EspMet_TopMixin EspMet_R). Canonical EspTop_R. Bien que dans cette sous-section nous mentionnons les espaces normés et euclidiens (avec un produit scalaire), seules les structures d’espaces métriques et topologiques sont implémentées. La formalisation des espaces normés et euclidiens pourra faire l’objet de travaux futurs. Nous allons maintenant nous intéresser à la formalisation de certains concepts de topologie générale qui ont permis d’énoncer et de prouver formellement le théorème de Bolzano-Weierstraß. 3.3 Bolzano-Weierstraß Le théorème de Bolzano-Weierstraß est un résultat de topologie générale dont la forme la plus utilisée est la suivante : Bolzano-Weierstraß (dans un espace métrique). Toute suite à valeurs dans un compact admet une sous-suite convergente. La version du théorème formalisée est sa forme plus générale qui est vraie pour un espace topologique quelconque : Bolzano-Weierstraß (dans un espace topologique). Toute suite à valeurs dans un compact admet une valeur d’adhérence.62 Topologie En effet, dans un espace métrique les valeurs d’adhérence sont les limites de sous-suites. Nous donnons dans un premier temps quelques définitions de topologie gé- nérale, principalement celles dont nous aurons besoin (comme la compacité par exemple). Nous verrons ensuite quelques notions sur les suites, et enfin nous parlerons de la formalisation du théorème. 3.3.1 Topologie générale Nous faisons ici quelques rappels des notions utilisées par la suite. Une première notion que nous utiliserons est celle de voisinage. Soit x un point d’un espace topologique T , alors un ensemble V est un voisinage du point x si V contient un ouvert qui contient x, autrement dit s’il existe un ensemble ouvert qui contient x et qui est inclus dans V : Definition neighbourhood (V : T -> Prop) (x : T) := exists A, [/\ x ’in A, open A & A y -> exists V1, exists V2, [/\ neighbourhood V1 x, neighbourhood V2 y & (inter V1 V2) Prop) := forall Ti (f : family T Ti), open_family f -> cover K f -> exists g : finite_family T Ti, sub_family f g /\ cover K g. Definition compact (K : T -> Prop) := separated /\ quasi_compact K. Nous allons maintenant définir les suites. 3.3.2 Les suites Nous parlerons ici de sous-suites et nous rappellerons en donnant les définitions formelles ce qu’est une valeur d’adhérence et la convergence d’une suite. Une suite d’éléments de type T est représentée par un élément dont le type est nat -> T. Soit u = (un)n∈N une suite, alors toutes les sous-suites de u peuvent3.3 Bolzano-Weierstraß 63 s’exprimer sous la forme (uϕ(n))n∈N où ϕ est une fonction strictement croissante de N → N. Donc une sous-suite est principalement la donnée d’une fonction ϕ qui vérifie les bonnes propriétés : Structure sub_seq : Type := mkss { phi :> nat -> nat; grow : forall m n, (m < n)%N -> (phi m < phi n)%N }. Formellement, étant donné g : sub_seq et une suite Un : nat -> T, alors Un \o g (où \o est la composition) désigne une sous-suite de Un. La formalisation des définitions de convergence et de valeur d’adhérence est une retranscription directe des définitions mathématiques. Une suite (un)n∈N converge vers une limite l si pour tout voisinage V de l on peut trouver un rang à partir duquel tous les éléments de la suite sont dans V . Et l est une valeur d’adhérence si pour tout voisinage V de l, pour chaque rang N on peut trouver un élément de la suite dans V au-delà du rang N : Definition Un_cvg (Un : nat -> T) (l : T) := forall V, neighbourhood V l -> exists N : nat, forall n, N <= n -> (Un n) ’in V. Notation "Un >->> l" := (Un_cvg Un l). Definition cluster_point (Un : nat -> T) (l : T) := forall V, neighbourhood V l -> forall N : nat, exists n, N <= n /\ (Un n) ’in V. À ce point, nous avons toutes les définitions utiles à l’énoncé et à la preuve du théorème de Bolzano-Weierstraß, dont nous décrivons la formalisation dans la section suivante. 3.3.3 Le théorème Le théorème de Bolzano-Weierstraß s’énonce formellement sur un espace topologique quelconque de la manière suivante : Lemma Bolzano_Weierstrass : forall (Un : nat -> T) K, compact K -> (forall n, (Un n) ’in K) -> exists l, l ’in (cluster_point Un). Nous allons dans un premier temps voir les grandes lignes de la preuve de ce théorème. Pour utiliser le théorème sous sa forme plus usuelle dans un espace métrique, nous montrerons ensuite que dans un espace métrique, les valeurs d’adhérence d’une suite sont des limites de ses sous-suites. Preuve dans un espace topologique La preuve formelle du théorème suit les mêmes étapes que la démonstration mathématique, et sa formalisation n’a pas posé de problème majeur. Les grands64 Topologie points de la démonstration du théorème sont les suivants : Soit K un ensemble compact et u = (un)n∈N une suite dont tous les termes sont dans l’ensemble K. Supposons par l’absurde que la suite u n’ait aucune valeur d’adhérence. Cela signifie que pour n’importe quel point x ∈ K on peut trouver un voisinage (ouvert) Vx de x qui à partir d’un certain rang nx ne contient aucun élément de la suite. La famille (Vx)x∈K recouvre l’ensemble K, comme K est compact, alors on peut extraire une sous-famille finie (Wi)i∈{0...k} avec Wi = Vxi qui recouvre K. Pour chaque Wi on a un rang nxi au-delà duquel la suite u n’a aucun terme qui appartient à l’ensemble Wi . Donc si l’on note N le maximum de tous les nxi , uN n’appartient à aucun ensemble de la famille W. Ce qui est absurde car uN est dans l’ensemble K et que la famille W forme un recouvrement de K. Preuve dans un espace métrique Pour montrer la version métrique du théorème de Bolzano-Weierstraß, nous montrons que dans les epaces métriques, les valeurs d’adhérence d’une suite sont les limites de ses sous-suites. Dans un espace métrique, nous avons une distance, et cela nous permet de définir pour un point x et un réel positif r donnés, la boule de centre x et de rayon r, notée généralement B(x, r), dont nous rappelons la définition formelle : Definition open_ball (x : E) (r : {posD Rn}) (y : E) := d x y < r. Notation "’’B’ ( x , r )" := (open_ball x r). où d est la distance de l’espace métrique. Ainsi, pour la plupart des définitions comme la convergence ou les valeurs d’adhérence d’une suite, on peut remplacer de manière équivalente les voisinages par des boules. Comme nous l’avons vu précédemment, les définitions formelles sont principalement de simples retranscriptions des définitions mathématiques. Donc dans la suite, nous utiliserons pour plus de lisibilité les notations mathématiques. Soit donc u = (un)n∈N une suite, et l une valeur d’adhérence de u. Le fait d’enlever le premier terme d’une suite ne change pas les valeurs d’adhérence, donc l est aussi une valeur d’adhérence de la suite (un+1)n∈N, autrement dit : ∀V ∈ Vois(l), ∀N, ∃n, N ≤ n et un+1 ∈ V où Vois(l) désigne l’ensemble des voisinages de l. Comme nous l’avons dit plus haut, ceci est équivalent à : ∀k ∈ N ∗ , ∀N, ∃n, N ≤ n et un+1 ∈ B(l, 1 k ) (1) Nous voulons maintenant montrer que la suite u a une sous-suite qui converge vers l, autrement dit nous voulons trouver une fonction ϕ : N → N strictement croissante telle que la suite (uϕ(n))n∈N converge vers l. Nous allons donc dans un premier temps “construire” la fonction ϕ.3.3 Bolzano-Weierstraß 65 Pour construire la fonction, nous allons utiliser le lemme functional_choice que l’on trouve dans la bibliothèque standard de Coq1 . Ce lemme s’énonce ainsi : (∀x ∈ A, ∃y ∈ B, P(x, y)) ⇔ (∃f : A → B, ∀x ∈ A, P(x, f(x))) Si nous appliquons ce lemme une première fois dans l’expression (1) nous obtenons : ∀k ∈ N ∗ , ∃f, ∀N, N ≤ f(N) et uf(N)+1 ∈ B(l, 1 k ) Nous pouvons utiliser le lemme functional_choice une seconde fois pour obtenir : ∃G, ∀k ∈ N ∗ , ∀N ∈ N, N ≤ Gk(N) et uGk(N)+1 ∈ B(l, 1 k ) où Gk(N) est une notation pour (G(k))(N). Nous avons donc une fonction G du type nat->nat->nat qui vérifie : ∀k ∈ N ∗ , ∀N ∈ N, N ≤ Gk(N) et uGk(N)+1 ∈ B(l, 1 k ) ou de manière équivalente : ∀k ∈ N ∗ , ∀N ∈ N, N < Gk(N) + 1 et uGk(N)+1 ∈ B(l, 1 k ) (2) Ici nous avons fait apparaître deux choses. La première est l’inégalité N < Gk(N) + 1 et la deuxième est uGk(N)+1 qui est un bon candidat pour définir une sous-suite. Le problème c’est que l’expression Gk(N) + 1 dépend de deux entiers k et N. Mais l’expression (2) est vraie quelque soit N, donc en particulier elle est vraie pour tous les N de la forme ϕ(k) pour une certaine fonction ϕ. Ainsi en remplaçant dans l’inégalité les occurences de N par ϕ(k), où ϕ est une fonction que l’on cherche à définir, nous obtenons d’une part : ∀k, ϕ(k) < Gk(ϕ(k)) + 1 Donc en définissant récursivement la fonction ϕ de manière à ce que ϕ(k + 1) = Gk(ϕ(k)) + 1, nous avons ∀k, ϕ(k) < ϕ(k + 1) et donc ϕ est une fonction strictement croissante. Et d’autre part, d’après (2) la fonction ϕ vérifie : ∀k ∈ N ∗ , uϕ(k+1) ∈ B(l, 1 k ) (3) On peut définir la fonction ϕ formellement comme suit : Fixpoint phi (m : nat) : nat := match m with | 0 => G 0 0 | m’.+1 => (G m’ (phi m’)).+1 end. 1http://coq.inria.fr/distrib/current/stdlib/Coq.Logic.IndefiniteDescription.html66 Topologie Nous avons donc construit une fonction ϕ strictement croissante. Maintenant, il ne nous reste plus qu’à prouver que la suite uϕ(n) converge vers l, ainsi nous aurons montré que l est une limite d’une sous-suite de u. Comme nous l’avons déjà dit précédemment, on peut remplacer les voisinages par des boules de manière équivalente dans la définition de convergence dans un espace métrique. Nous voulons donc montrer que : ∀t ∈ N ∗ , ∃N ∈ N, ∀n, N ≤ n ⇒ uϕ(n) ∈ B(l, 1 t ) Soit t ∈ N ∗ , alors montrons que N = t + 1 convient. Soit n ∈ N tel que t + 1 ≤ n, il nous reste à montrer que uϕ(n) ∈ B(l, 1 t ). Comme t+1 ≤ n et que t ∈ N ∗ alors n−1 ∈ N ∗ , donc d’après (3) nous avons : uϕ(n) ∈ B(l, 1 n−1 ) Comme t + 1 ≤ n alors t ≤ n − 1, ce qui implique que 1 n−1 ≤ 1 t , et donc B(l, 1 n−1 ) ⊂ B(l, 1 t ), autrement dit : uϕ(n) ∈ B(l, 1 t ) Nous avons donc montré que dans un espace métrique, les valeurs d’adhérences d’une suite sont les limites de ses sous-suites. La preuve du résultat précédent permet d’utiliser la version de Bolzano-Weierstraß dans un espace métrique. En fait, dans un cadre plus général, pour montrer ce résultat il suffit d’avoir pour chaque point l de l’espace topologique une base dénombrable de voisinages (dans les espaces métriques ce sont les boules de centre l et de rayon 1 k ). 3.4 Conclusion La topologie générale se formalise plutôt bien. Comme nous l’avons vu, la plupart des définitions sont naïves, et les preuves suivent le même schéma que les preuves mathématiques. La logique utilisée est la logique classique. D’une part cela permet d’avoir une théorie des ensembles avec les bonnes propriétés (comme le fait qu’un ensemble soit égal au complémentaire de son complémentaire par exemple), d’autre part le théorème de Bolzano-Weierstraß est un résultat de logique classique. La formalisation de la topologie a permis de prouver le théorème de BolzanoWeierstraß, mais aussi de munir les structures ordonnées de la bibliothèque SSReflect d’une topologie, et de montrer des résultats dessus dont nous aurons également besoin par la suite. Il existe déjà un théorème de Bolzano-Weierstraß dans la bibliothèque standard de Coq, mais prouvé uniquement sur les nombres réels. Puisque nous l’avons prouvé dans un cadre plus général, cela fait que l’on pourra l’utiliser sur n’importe quel type que l’on aura muni d’une topologie. En particulier, par la suite, nous aurons besoins de l’utiliser sur l’espace des matrices.3.5 Travaux reliés 67 Cependant, pour utiliser ce théorème il faut d’abord montrer qu’un certain ensemble est compact. L’argument souvent utilisé pour prouver la compacité d’un ensemble est de montrer qu’il est fermé et borné. Mais pour prouver ce résultat il faut être dans un espace vectoriel normé de dimension finie ou dans un espace euclidien. Comme nous l’avons vu, pour l’instant seules les structures d’espaces métriques et topologiques sont implémentées, il serait donc intéressant par la suite d’implémenter également les structures d’espaces normés et euclidiens. 3.5 Travaux reliés Les travaux de formalisation de topologie générale sont nombreux et ont été faits dans de nombreux assistants de preuve comme Mizar [38], Isabelle [26], PVS [30], etc. Plus particulièrmeent dans l’assistant de preuve HOL Light on trouve une preuve du théorème de Bolzano-Weierstraß dans le cas particulier des espaces métriques [23]. Il existe également un début de formalisation de topologie générale en Coq, dans un projet qui s’appelle Coqtail1 . Il existe aussi des travaux de formalisation qui ont une approche constructive de la topologie. Cela la s’appelle la topologie formelle, ou la topologie sans points. On pourra par exemple cité les travaux de Giovanni Sambin [43] dont une partie des travaux a été formalisée avec l’assistant de preuve Matita [2]. 1http://coqtail.sourceforge.netChapitre 4 Perron-Frobenius Le théorème de Perron-Frobenius est un théorème d’algèbre linéaire à propos du rayon spectral d’une matrice réelle dont les coefficients sont positifs. Les principales applications de ce théorème sont en théorie des graphes, ou en probabilité avec les chaînes de Markov. Le théorème est utilisé sur les matrices d’adjacence d’un graphe ou sur des matrices stochastiques, ce sont des matrices à coefficients positifs [48]. On utilise également le théorème de Perron-Frobenius dans l’étude des matrices dont les coefficients sont des intervalles [32, 42]. La partie du théorème de Perron-Frobenius à laquelle on s’intéresse est celle qui dit que le rayon spectral d’une matrice à coefficients positifs est une valeur propre de la matrice, et que cette valeur propre a un vecteur propre associé dont les coefficients sont positifs. Cette preuve se fait en deux étapes. Dans une première étape on démontre le théorème pour les matrices à coefficients strictement positifs. Dans une deuxième étape on utilise un argument de densité pour prouver le résultat sur les matrices à coefficients positifs ou nuls. Pour prouver ce théorème nous devrons utiliser les notions de topologie, et la forme normale de Jordan d’une matrice vues dans les deux chapitres précédents. Dans un premier temps, nous allons voir dans ce chapitre la formalisation de la première étape de la preuve. Nous verrons d’abord les définitions de base dont nous aurons besoin par la suite. Ensuite nous présenterons une preuve du théorème pour le cas des matrices strictements positives pour mettre en évidence les résultats intermédiaires dont nous aurons besoin et dont nous montrerons la formalisation ensuite. Dans un second temps, nous expliquerons le chemin qu’il reste à faire pour la formalisation de la deuxième partie de la preuve.70 Perron-Frobenius 4.1 Rappels et définitions 4.1.1 Minimum et maximum Nous aurons besoin de définir le maximum d’une famille d’éléments pour la définition du rayon spectral d’une matrice et du minimum pour la preuve du théorème. C’est pourquoi nous commençons par définir ces deux notions dans cette section. Minimum Pour exprimer le minimum d’une famille d’éléments, on pourrait essayer d’utiliser les opérateurs de familles de la façon suivante1 : \big[minr/id]_(i <- s) F i Le problème avec cette façon de faire c’est que id doit être un élément neutre pour le minimum. En effet, nous avons vu que, par exemple, pour une séquence [:: a, b, c] l’expression ci-dessus est équivalente à : minr a (minr b (minr c id)) et donc si a, b et c sont tous plus grand que l’élément id alors la valeur retournée sera id et non le plus petit des trois éléments a, b et c. C’est la raison pour laquelle id doit être un élément neutre, or dans notre cas la fonction minimum n’a pas d’élément neutre. Pour les besoins de la preuve, nous avons seulement besoin d’une fonction qui retourne un élément de la famille qui soit plus petit que tous les autres. Le minimum est donc simplement défini comme suit : Fixpoint min_seq s := match s with | [::] => 0 | [:: x] => x | x :: s’ => minr x (min_seq s’) end. On traite à part le cas où la séquence ne contient qu’un seul élément pour que l’appel récursif de la fonction ne se fasse jamais sur une séquence vide. À partir de cette définition, nous pouvons définir une fonction minimum plus proche de ce qui est fait dans la bibliothèque SSReflect sur les opérateurs de familles : Definition min_fT (I : finType) (F : I -> R) := min_seq [seq F i | i <- index_enum I]. Cette définition respecte les deux propriétés dont nous avons besoin, à savoir : Lemma min_fT_le (I : finType) F (i : I) : min_fT F <= F i. Lemma ex_min_fT (I : finType) F (_ : I) : {k | min_fT F = F k}. 1voir 1.2.5 et 1.2.10 pour les notations.4.1 Rappels et définitions 71 Maximum Pour définir le maximum d’une famille d’éléments, nous pouvons contourner le problème de l’élément neutre du fait que dans notre contexte, nous prenons toujours le maximum d’une famille d’éléments positifs. Nous pouvons donc choisir zéro comme élément neutre et utiliser les opérateurs de familles : \big[(@maxr R)/0%R]_i F i L’expression ci-dessus sera cachée derrière la notation : \maxr_i F i 4.1.2 Éléments d’algèbre linéaire Soit A une matrice carrée de dimension n à coefficients dans un corps. Le noyau de la matrice A, noté ker A, est l’ensemble des vecteurs tels que Ax = 0 c’est-à-dire : x ∈ ker A ⇔ Ax = 0 Le noyau d’une matrice est fourni par une fonction de la bibliothèque SSReflect, noté kermx A. Si x est un vecteur non nul qui appartient au noyau de la matrice A, alors A n’est pas inversible. En effet, si A était inversible nous aurions : x = I ∗ x = (A −1 ∗ A)x = A −1 (Ax) = A −1 ∗ 0 = 0 ce qui contredit le fait que x soit non nul. La matrice A n’étant pas inversible, comme nous sommes sur des matrices à coefficients dans un corps, nous avons det A = 0. Soit maintenant x et λ respectivement un vecteur colonne non nul et un scalaire tels que l’on ait la relation : Ax = λx Alors on dit que λ est une valeur propre de la matrice A et que x est un vecteur propre associé à la valeur propre λ. La relation ci-dessus peut être réécrite comme suit : (A − λI)x = 0 (1) Donc si λ est une valeur propre de la matrice A alors x est un vecteur non nul appartenant au noyau de la matrice (A−λI). C’est ainsi qu’est définie le prédicat booléen qui caractérise les valeurs propres dans la biblothèque SSReflect : Variables (T : fieldType) (n : nat) (A : ’M[T]_n). Definition eigenvalue lam := kermx (A - lam%:M) != 0.72 Perron-Frobenius Remarque 2. Le prédicat eigenvalue ne représente que l’ensemble des valeurs propres qui sont de type T. Donc par exemple si T est le corps des réels, alors les seules valeurs qui vérifieront le prédicat seront les valeurs propres réelles de la matrice A, et si lam est une valeur propre complexe de la matrice A alors eigenvalue A lam sera mal typé. L’égalité (1) indique également que si λ est une valeur propre de la matrice A alors det(A − λI) = 0 d’après ce que l’on a vu juste avant. C’est-à-dire que λ est une racine du polynôme caractéristique de la matrice A. Nous pouvons donc, dans un corps algébriquement clos, définir la séquence des valeurs propres d’une matrice : Variable F : closedFieldType. Definition eigen_seq n (A : ’M[F]_n) := root_seq (char_poly A). où la fonction root_seq retourne la séquence des racines d’un polynôme. Par exemple, si p est le polynôme (’X-1)^+2 * (’X-2) alors root_seq p sera la sé- quence [:: 1, 1, 2] (ou une de ses permutations). Le lemme suivant montre que, sur un corps algébriquement clos, les deux définitions ci-dessus expriment bien la même chose : Lemma eigenE n (A : ’M[F]_n) lam : (lam \in (eigenvalue A)) = (lam \in (eigen_seq A)). Le rayon spectral d’une matrice est le plus grand des modules des valeurs propres d’une matrice. Donc pour définir le rayon spectral, il faut une fonction module. Comme la séquence des valeurs propres est définie pour les matrices à coefficients dans un corps clos, alors le rayon spectral est défini pour les matrices à coefficients complexes1 : Variable R : rcfType. Notation C := (complex R). Definition spectral_radius n (A : ’M[C]_n) := \maxr_(lam <- eigen_seq A) Re ‘|lam|. Notation "\rho A" := (spectral_radius A). où Re désigne la fonction partie réelle, car bien que le module d’un nombre complexe ait une partie imaginaire nulle, son type est le type des nombres complexes, donc la fonction partie réelle est utilisée ici pour que le résultat obtenu soit réel. Donc pour parler du rayon spectral d’une matrice à coefficients réels, il faudra d’abord plonger la matrice dans l’espace des matrices à coefficients complexes. Dans la suite, nous parlerons également de comparaison entre matrices. Si A et B sont deux matrices de même dimensions, alors on dira que A ≤ B (resp. A < B) si tous les coefficients de B sont supérieurs ou égaux (resp. strictement supérieurs) aux coefficients de A. Dans le code formel, nous utiliserons les définitions et les notations suivantes : 1voir 1.2.10 et 1.2.11 pour les notations.4.2 Matrices strictement positives 73 Definition Mle A B := forall i j, A i j <= B i j. Definition Mlt A B := forall i j, A i j < B i j. Notation "A <=m: B" := (Mle A B). Notation "A exists x, 0 <=m: x /\ A *m x = (\rho A^%:C) *: x. La notation A^%:C signifie que chaque coefficient réel de la matrice A est plongé dans le corps des nombres complexes 4.2 Matrices strictement positives Nous allons voir maintenant dans une première partie la formalisation de la preuve du théorème de Perron-Frobenius pour les matrices strictement positives. Dans une seconde partie, nous verrons la formalisation d’un résultat important dont nous aurons besoin pour la première partie. 4.2.1 Preuve du théorème principal Le théorème que nous allons montrer ici est le suivant : Perron-Frobenius[cas strictement positif] Soit A ∈ Mn(R) telle que 0 < A, alors ρ(A) est une valeur propre de la matrice A et possède un vecteur propre associé dont tous les coefficients sont strictement positifs. La preuve du théorème repose sur l’axiome suivant : Axiome. Soit A ∈ Mn(R). La suite définit par (Ak )k∈N converge vers 0 si et seulement si ρ(A) < 1. Nous utiliserons également dans la preuve le résultat suivant : Resultat 1. Soit A ∈ Mn(R) telle que 0 < A, soit x un vecteur non nul tel que 0 ≤ x, alors 0 < Ax.74 Perron-Frobenius En effet, le i-ème coefficient du vecteur Ax est P k aikxi et comme x est nonnul alors il existe un terme de la somme qui est non-nul, donc tous les coefficients du vecteur Ax sont strictement positifs. Pour la preuve du théorème de Perron-Frobeniuspour les matrices strictement positives nous avons besoins du lemme suivant : Lemme 5. Soit A ∈ Mn(R) telle que 0 < A. Soit λ une valeur propre de A telle que |λ| = ρ(A), et soit x un vecteur non nul tel que Ax = λx. Alors nous avons A|x| = ρ(A)|x|, 0 < ρ(A) et 0 < |x|. Pour montrer ce lemme, on fait un traitement par cas sur l’égalité A|x| = ρ(A)|x| : Posons z = A|x|, alors d’après le résultat 1 nous avons 0 < z. • Supposons que A|x| = ρ(A)|x|, dans ce cas il ne reste plus qu’à montrer que 0 < ρ(A) et 0 < |x|. On sait que 0 ≤ ρ(A), si ρ(A) = 0 alors on aurait A|x| = 0 ∗ |x| = 0, autrement dit on aurait z = 0 ce qui contredit le fait que 0 < z, donc 0 < ρ(A). De plus, comme 0 < z et que z = ρ(A)|x|, on a 0 < ρ(A)|x| et donc 0 < |x|. • Maintenant supposons que A|x| 6= ρ(A)|x|. Nous allons montrer que cette hypothèse est absurde. Posons y = A|x| − ρ(A)|x|, alors d’après l’inégalité précédente nous avons y 6= 0, de plus 0 ≤ y en effet, nous avons : ρ(A)|x| = |λ||x| = |λx| = |Ax| ≤ |A||x| = A|x| et donc ρ(A)|x| ≤ A|x| ⇔ 0 ≤ A|x| − ρ(A)|x| = y Donc d’après le résultat 1 nous avons 0 < Ay = Az − ρ(A)z. Comme 0 < z et 0 < Az − ρ(A)z alors il existe un ε > 0 tel que l’on ait Az − ρ(A)z > εz. Autrement dit, nous avons : Az > (ρ(A) + ε)z ⇔ A ρ(A) + ε z > z Donc en posant B = A/(ρ(A) + ε) nous avons Bz > z, et par récurrence nous obtenons que ∀k, Bk z > z. De plus ρ(B) = ρ(A)/(ρ(A) + ε) < 1 donc d’après l’axiome, la suite des Bk converge vers 0 ce qui donne que 0 ≥ z > 0 ce qui est absurde. Le théorème découle directement du lemme 5 et des deux lemmes ci-dessous : Lemma ex_eigen_rho n (A : ’M[C]_n.+1) : {lam | eigenvalue A lam & ‘|lam| = \rho(A)%:C}. Lemma eigenvalueP a : reflect (exists2 v : ’rV_n, v *m g = a *: v & v != 0) (eigenvalue a).4.2 Matrices strictement positives 75 Le premier est une conséquence du fait que le maximum d’un nombre fini de valeurs est atteint et le deuxième est un résultat donné par la bibliothèque SSReflect. Dans la preuve du lemme 5, nous avons utilisé quatre résultats qui ne sont pas seulement des manipulations algébriques : • Le premier dit que si u et v sont des vecteurs strictement positifs, alors il existe ε > 0 tel que εv < u. Pour montrer ce résultat, on peut prendre ε = min i ui 2vi . L’énoncé prouvé formellement est celui-ci : Lemma Mle_eps m (u v : ’cV[R]_m.+1) : let F i := ((u i 0) / 2%:R)/ (v i 0) in let eps := min_fT F in 0 0 eps *: v B, et si la suite des Ak converge vers C alors on a C ≥ B. Son énoncé formel est le suivant : Lemma ltmx_cvg_lemx m n (A B :’M[R]_(m,n)) (U : nat -> ’M_(m,n)) : (forall k, A (U >->> B) -> A <=m: B. Nous remarquons que certaines propriétés utilisent la notion de convergence d’une suite de matrices. Donc pour pouvoir les exprimer, il faut d’abord munir le type des matrices d’une topologie. Nous allons donc voir maintenant comment est implémentée la structure d’espace topologique sur les matrices, mais aussi sur les structures ordonnées car nous en aurons besoin par la suite. 4.2.2 Instance des structures topologiques Nous avons déjà vu au chapitre 3 comment sont implémentées les structures d’espace métrique et topologique. Nous avons aussi vu sur l’exemple des réels de Coq comment instancier ces structures. Aussi nous indiquerons ici seulement la métrique qui sera utilisée pour ces instanciations.76 Perron-Frobenius Les structures ordonnées Toutes la hiérarchie des structures ordonnées est basée sur la structure appelée numDomainType. Nous avons vu que cette structure possède une fonction valeur absolue, ou module notée ‘|.|. La métrique utilisée sur les structures ordonnées est donc la suivante : Definition dist_real x y := ‘|x - y|. Les nombres complexes Nous avons vu aussi que dans la définition d’espace métrique le type de retour de la fonction distance était en paramètre. Ainsi si nous avons E : metricType R alors plus R sera “haut” dans la hiérarchie des structures ordonnées, plus nous pourrons démontrer de propriétés sur les espaces métriques. Les nombres complexes sont une instance de la structure numFieldType. Or nous aurons besoin dans le développement formel que le type de retour de la fonction distance sur les nombres complexes soit au moins de type realDomainType. C’est pourquoi nous utilisons la fontion partie réelle dans la définition de la distance sur les nombres complexes : Definition dist_C x y := Re ‘|x - y|. Les matrices Avant de définir une distance sur les matrices, nous définissons d’abord un type pour les normes de matrices : Section normDef. Variable R : numDomainType. Structure can_norm : Type := MNorm { anorm : forall p q, ’M[R]_(p,q) -> R; pos_norm : forall p q (A : ’M_(p, q)), 0 <= anorm A; hom_pos_norm : forall p q (A : ’M_(p, q)) (r : R), anorm (r *: A) = ‘|r| * anorm A; trin_ineq_norm : forall p q (A B : ’M_(p, q)), anorm (A + B) <= anorm A + anorm B; prod_ineq_norm : forall p q r (A : ’M_(p, q)) (B : matrix _ q r), anorm (A *m B) <= anorm A * anorm B; canonical_norm : forall p q (A : ’M_(p, q) ) i j, ‘|A i j| <= anorm A; canonical_norm2 : forall p q (A B: ’M_(p, q)), (forall i j, ‘|A i j| <= ‘|B i j|) -> anorm A <= anorm B }. End normDef.4.2 Matrices strictement positives 77 Notation "|| A : N |" := (anorm N A). Ici nous avons simplement repris la définition de norme formalisée par Ioana Paşca dans [42]. La définition a été actualisée avec les nouvelles définitions et notations de SSReflect. La norme que nous utiliserons par la suite est la norme infini définie commme suit1 : Definition norm8 (m n : nat) (A : ’M[R]_(m,n)) := \maxr_i \sum_j ‘|A i j|. Cette norme vérifie tous les axiomes de la structure can_norm définie ci-dessus. Donc après avoir démontré ces propriétés, nous pouvons déclarer la norme infini comme une instance de la structure : Canonical Structure can_norm8 := MNorm norm8_pos norm8_hom ... La distance sur les matrices est définie à partir de cette norme : Variable R : numDomainType. Let N8 := can_norm8 R. Definition dist_mat m n (A B : ’M[R]_(m,n)) := ||(A - B) : N8 |. 4.2.3 Preuve de l’axiome Nous allons montrer ici le théorème que nous avons posé en axiome dans la première partie de la preuve du théorème de Perron-Frobenius : Théorème 6. Soit A ∈ Mn(K) (K étant R ou C). La suite définit par (Ak )k∈N converge vers 0 si et seulement si ρ(A) < 1. Nous verrons également quelques points de la formalisation de cette preuve. La Preuve Commençons d’abord par montrer le sens facile : Si la suite (Ak )k∈N converge vers 0 alors ρ(A) < 1. Soit λ une valeur propre de la matrice A et x un vecteur propre associé à λ. Comme Ax = λx alors Akx = λ kx. Supposons que (Ak )k∈N converge vers 0, alors la suite (λ kx)k∈N = (Akx)k∈N converge vers 0 et comme x est non nul cela signifie que la suite (λ k )k∈N converge vers 0 et donc que |λ| < 1. Nous avons donc montré que pour toute valeur propre λ de la matrice A nous avons |λ| < 1 et donc en particulier nous avons ρ(A) < 1. Maintenant supposons que ρ(A) < 1 et montrons que la suite (Ak )k∈N converge vers 0. Notons J (A) la forme normale de Jordan de la matrice A. D’après ce que 1Le “8” représente un infini debout.78 Perron-Frobenius nous avons vu dans le chapitre 2, la matrice A est semblable à J (A). C’est-à-dire qu’il existe une matrice inversible P telle que A = P −1J (A)P, autrement dit telle que Ak = P −1J (A) kP. Donc prouver que la suite (Ak )k∈N converge vers 0 revient à prouver que la suite (J (A) k )k∈N converge vers 0. Nous savons que la forme normale de Jordan de A est une matrice diagonale par blocs dont chaque bloc est un bloc de Jordan J(λ, n) où λ est une valeur propre de A. Donc la matrice J (A) k est une matrice diagonale par blocs dont chaque bloc est de la forme J(λ, n) k . Ainsi pour montrer que la suite (J (A) k )k∈N converge vers 0, il suffit de montrer que pour chaque bloc la suite des (J(λ, n) k )k∈N converge vers 0. Voyons donc quelle est la forme générale de la matrice J(λ, n) k . Sur la figure ci-dessous on peut voir ce qui se passe sur un exemple pour les quatre premières puissances avec n = 4 : J(λ, 4) =   λ 1 0 0 0 λ 1 0 0 0 λ 1 0 0 0 λ   J(λ, 4)2 =   λ 2 2λ 1 0 0 λ 2 2λ 1 0 0 λ 2 2λ 0 0 0 λ 2   J(λ, 4)3 =   λ 3 3λ 2 3λ 1 0 λ 3 3λ 2 3λ 0 0 λ 3 3λ 2 0 0 0 λ 3   J(λ, 4)4 =   λ 4 4λ 3 6λ 2 4λ 0 λ 4 4λ 3 6λ 2 0 0 λ 4 4λ 3 0 0 0 λ 4   On remarque que sur chaque ligne les puissances de λ décroissent et que des coefficients binomiaux apparaissent. De manière générale nous avons : (J(λ, n) k )ij = k j − i ! λ k−(j−i) avec la convention que  k j−i  = 0 si j − i > k ou si i > j. Rappelons que nous avons ρ(A) < 1 et donc pour toute valeur propre λ de A nous avons |λ| < 1. Nous allons montrer que si |λ| < 1 alors la suite (J(λ, n) k )k∈N converge vers 0, pour cela nous allons montrer que les coefficients de la matrice J(λ, n) k convergent vers 0 quand k tend vers l’infini. Nous avons pour tout l : k l ! = k! (k − l)! l! = (k − (l − 1)) ∗ · · · ∗ k l! ≤ k ∗ · · · ∗ k l! = k l l! avec comme convention que a − b = 0 si a < b. Cela signifie que pour un l fixé,  k l  est borné par le polynôme k l/l! et donc dans l’expression suivante : k j − i ! λ k−(j−i)4.2 Matrices strictement positives 79 comme |λ| < 1 nous avons le terme λ k−(j−i) qui converge vers 0 de façon exponentielle alors que le terme  k j−i  croit vers l’infini de façon polynômiale. Donc finalement chaque coefficient du bloc J(λ, n) k converge vers 0. Ceci fini de montrer le théorème. Quelques points de formalisation Matrice et convergence Nous allons d’abord parler de lemmes généraux sur la convergence des suites de matrices. Un premier lemme important que nous avons utilisé est celui qui fait le lien entre la convergence des matrices et la convergence coefficient par coefficient. Ce lemme s’énonce formellement ainsi : Variable R : numFieldType. Lemma mx_cvgP m n (U : nat -> ’M_(m,n)) (A :’M[R]_(m,n)) : U >->> A <-> (forall i j, (fun n => (U n) i j) >->> (A i j)). Nous nous en sommes servi pour montrer que la suite des puissances des blocs de Jordan convergeait vers 0. Le second résultat sur la convergence des matrices que nous allons voir est celui qui fait le lien entre la convergence des matrices diagonales par blocs et la convergence bloc à bloc. Rappelons qu’une matrice diagonale par blocs est définie formellement à l’aide d’une fonction F : forall n, nat -> ’M_n.+1 qui donne les blocs diagonaux (voir 2.1), et d’une séquence qui correspond à peu de choses près à la taille des blocs. Une suite U1, U2, . . . de matrices diagonales par blocs correspondra formellement à une suite : diag_block_mx s (UF 1), diag_block_mx s (UF 2), ... où UF est la suite des fonctions qui donnent les blocs diagonaux. Nous avons donc UF qui est de type nat -> forall n, nat -> ’M_n.+1. Le lemme s’énonce ainsi : Lemma diag_block_mx_cvg s (UF : nat -> forall n, nat -> ’M[R]_n.+1) (F : forall n, nat -> ’M[R]_n.+1) : (forall i, (i < size s)%N -> (fun k => UF k (nth 0%N s i) i) >->> (F (nth 0%N s i) i)) -> (fun k => diag_block_mx s (UF k)) >->> (diag_block_mx s F). Nous l’utilisons pour montrer que la forme normale de Jordan de la matrice A converge vers 0. Convergence sur les nombres réels ou complexes Nous avons également utilisé le fait qu’il y a équivalence entre |λ| < 1 et la convergence de la suite (λ k )k∈N vers zéro. La preuve de ce résultat utilise la propriété archimédienne des nombres réels. Or dans notre cas nous utilisons ces lemmes sur les nombres complexes qui n’est pas archimédien. La structure archifieldType de la bibliothèque SSReflect est une structure realFieldType qui vérifie l’axiome suivant :80 Perron-Frobenius Definition archimedean_axiom (R : numDomainType) := forall (x : R), exists ub : nat, ‘|x| < ub%:R. La preuve de ce résultat n’utilise pas le fait que la structure de base est de type realFieldType, mais seulement le fait que l’axiome ci-dessus est vérifié. Or il se trouve que l’ensemble des nombres complexes vérifie cet axiome (car le module d’un nombre complexe est réel). Pour éviter d’avoir à dupliquer les lemmes sur les nombres réels et sur les nombres complexes, nous allons définir une nouvelle structure plus faible que la structure archiFieldType dont le type de base sera la structure numFieldType : Structure class_of (R : Type) := Class { base : NumField.class_of R; _ : archimedean_axiom (@NumDomain.Pack R base) }. Coercion base : class_of >-> NumField.class_of. Structure type := Pack {sort; _ : class_of sort}. Coercion sort : type >-> Sortclass. Notation archiDomainType := type. Nous avons déjà rencontré ce genre de définition dans le chapitre 3 sur la présentation des structures topologiques. La structure class_of est la structure d’hérédité. Elle contient un champ base qui correspond à la structure d’hérédité du type de base, et un preuve que ce type de base vérifie les propriétés supplé- mentaires qui se trouve dans la structure mixin_of qui ici est seulement réduite à l’axiome archimedean_axiom. Ce genre de structure est expliquée plus en détail dans [15, 14]. Cette structure étant basée sur la structure numFieldType hérite des propriétés de cette dernière, et aussi de la topologie (et de la métrique) que nous avons instanciée pour la structure numDomainType. L’ensemble des nombres réels et l’ensemble des nombres complexes étant tous les deux des instances de la structure ci-dessus, nous pouvons utiliser dans les deux cas les deux lemmes suivants qui nous intéressent : Variable R : archiDomainType. Lemma cvg_lt1 (x : R) : reflect ((fun k => x ^+ k) >->> 0) (‘|x| < 1). Lemma polyM_exp_cvg0 i (a : R) : ‘|a| < 1 -> (fun k => k%:R ^+ i * a ^+ k) >->> 0. 4.3 Matrices à coefficients positifs ou nuls Nous avons montré que pour toute matrice A ∈ Mn(R) telle que 0 < A, il existe un vecteur propre x de A tel que 0 < x et que Ax = ρ(A)x. Nous allons voir4.3 Matrices à coefficients positifs ou nuls 81 maintenant comment l’on généralise ce résultat pour le cas où 0 ≤ A. Ce que nous allons voir dans cette section n’est pas formalisé. Nous discuterons ici du travail qu’il reste à faire. 4.3.1 La preuve Le théorème que nous allons étudier maintenant est donc le suivant : Perron-Frobenius Soit A ∈ Mn(R) telle que 0 ≤ A, alors ρ(A) est une valeur propre de la matrice A et possède un vecteur propre associé dont tous les coefficients sont positifs. Prenons donc une matrice A telle que 0 ≤ A. Posons Ak = (aij + 1 k )1≤i,j≤n. Les matrices Ak sont des matrices strictement positives. Donc d’après le théorème que nous venons de montrer dans la section 4.2.1, nous avons ρ(Ak) qui est une valeur propre de Ak et qui possède un vecteur propre associé xk strictement positif. Quitte à normaliser, nous pouvons choisir le vecteur xk de norme 1. Comme la suite des matrices Ak converge vers A, alors la suite des ρ(Ak) converge vers ρ(A). De plus, comme les vecteurs de la suite xk sont dans un ensemble compact, alors d’après le théorème de Bolzano-Weierstraß (chapitre 3) il existe une sous-suite xϕ(k) qui converge vers un vecteur x positif. Pour tout entier k nous avons donc Aϕ(k)xϕ(k) = ρ(Aϕ(k))xϕ(k) , donc d’après ce qui précède, en passant à la limite nous obtenons Ax = ρ(A)x. Ainsi ρ(A) est une valeur propre de A et possède un vecteur propre associé à coefficients positifs ou nuls. Les deux principaux résultats de cette preuve qui demanderont le plus de travail de formalisation sont : • Si (An)n∈N est une suite de matrice qui converge vers A alors la suite des ρ(An) converge vers ρ(A). • L’ensemble des vecteurs de norme 1 est un ensemble compact. 4.3.2 Convergence des rayons spectraux Nous avons deux façons de montrer que la suite (ρ(Ak))k∈N∗ décrite plus haut converge vers ρ(A). La première utilise un argument de convergence des suites réelles décroissantes et minorées, et la deuxième utilise un argument de continuité. Argument de convergence Pour montrer que la suite des rayons spectraux est décroissante, nous utilisons le lemme suivant : Lemme 7. Si A, B ∈ Mn(K) (avec K = R ou C) sont des matrices telles que |A| ≤ B alors ρ(A) ≤ ρ(B).82 Perron-Frobenius Démonstration. Soit ε > 0. Définissons les matrices suivantes : Aε = A ρ(B) + ε et Bε = B ρ(B) + ε Comme |A| ≤ B, nous avons |Aε| ≤ Bε et donc |Aε| k ≤ Bk ε . D’une part ρ(Bε) = ρ(B)/(ρ(B) + ε) < 1. D’après ce que nous avons vu dans la section 4.2.3, cela signifie que la suite (Bk ε )k∈N converge vers 0. D’autre part pour tout entier k nous avons |Ak ε | ≤ |Aε| k ≤ Bk ε . D’après ce qui précède, cela signifie que la suite (Ak ε )k∈N converge aussi vers 0, et donc cela implique que ρ(Aε) < 1. Donc finalement : ρ(Aε) = ρ(A) ρ(B) + ε < 1 ⇔ ρ(A) < ρ(B) + ε et ce pour tout ε > 0 donc ρ(A) ≤ ρ(B). Grâce à ce lemme nous pouvons montrer que la suite (ρ(Ak))k∈N∗ est une suite décroissante et minorée par ρ(A) donc cette suite converge vers un réel ρ tel que ρ ≥ ρ(A). De plus nous avons vu que en passant à la limite, nous avons l’égalité Ax = ρx. Cela nous donne que ρ ≤ ρ(A) et donc par double inégalité ρ = ρ(A). Le développement sur la topologie est assez développé pour faire ce genre de preuve. Argument de continuité Une autre façon de faire est de montrer que la fonction A → ρ(A) est continue. Ainsi comme la suite (Ak)k∈N converge vers A alors la suite (ρ(Ak))k∈N∗ converge vers ρ(A). L’argument le plus souvent utilisé pour montrer la continuité du rayon spectral est le suivant : • Les coefficients du polynôme caractéristique d’une matrice varient continuement en fonction des coefficients de la matrice. • Les racines d’un polynôme varient continuement en fonction des coefficients du polynôme. • Le rayon spectral est continu en tant que composée d’applications continues. Le polynôme caractéristique d’une matrice est le déterminant de sa matrice caractéristique. Donc une manière de prouver le premier point est d’instancier une métrique sur l’ensemble des polynômes et de prouver que l’application déterminant est continue.4.4 Conclusion 83 On peut trouver une preuve du second point dans [34]. C’est une preuve qui demanderait encore du travail de formalisation, mais qui je pense reste abordable avec les outils que nous avons déjà formalisés. Le troisème point est un résultat général sur la continuité qui est déjà formalisé dans le développement sur la topologie. 4.3.3 Compacité de la boule unité Pour pouvoir utiliser le théorème de Bolzano-Weierstraß que nous avons vu au chapitre 3, il nous faut montrer que l’ensemble des vecteurs de norme 1 est un ensemble compact. Pour montrer ce résultat, on montre d’abord que les intervalles fermés sur R sont compacts. Ensuite on montre que la boule unité est incluse dans un pavé qui est le produit cartésien d’intervalles de R. Comme le produit cartésien fini d’ensembles compacts est compact, nous avons la boule unité qui est un ensemble fermé inclus dans un compact et est donc compact. Une première étape serait de définir le produit cartésien de deux ensembles. Nous avons vu qu’il existe déjà dans Coq un type produit pour le produit carté- sien de deux types (voir 1.1.1). Nous pourrions réutiliser ce produit cartésien sur les types pour avoir une définition du produit cartésien sur les ensembles : Variables (T1 T2 : Type). Definition cartesian_product (A : T1 -> Prop) (B : T2 -> Prop) := fun x : (T1 * T2) => (x.1 ’in A) /\ (x.2 ’in B). Mais je n’ai aucune idée si cette définition est praticable. Un second problème va apparaître lorsque nous voudrons utiliser ce résultat sur l’ensemble des nombres complexes. Ici l’argument est que l’on peut voir l’ensemble C comme le produit cartésien R × R. Il faudrait alors expliquer que la topologie obtenue à partir de la topologie produit sur R × R est équivalente à la topologie que nous avons instanciée sur l’ensemble des nombres complexes. Pour l’instant, telle qu’est définie la structure d’espace topologique, c’est quelque chose de difficile à exprimer. Le fait qu’un ensemble fermé inclus dans un compact est compact est déjà formalisé dans le développement sur la topologie générale. 4.4 Conclusion Le théorème de Perron-Frobenius est un exemple de théorème d’algèbre linéaire qui fait intervenir des arguments d’analyse et de topologie. Bien que la formalisation de ce théorème ait motivé la formalisation de la forme normale de Jordan et des espaces topologiques et métriques, ces développements ont été fait de manière indépendantes. La premère partie du théorème a permis de montrer que ces développements étaient réutilisables. Nous avons pu ainsi avoir une formalisation complète du84 Perron-Frobenius théorème de Perron-Frobeniuspour les matrices strictements positives. Toutefois pour montrer le théorème dans le cas générale, il reste encore à prouver des résultats comme la continuité du rayon spectrale ou la compacité de l’ensemble des vecteurs de norme 1. 4.5 Travaux reliés A ma connaissance, il n’existe pas de travaux de formalisation à propos du théorème du théorème de Perron-Frobenius. Un des rares papiers que j’ai trouvé sur la formalisation de sujet semblable est celui de Karol Pąk où le concept de valeur propre est formalisé en Mizar [40].Conclusion La formalisation du théorème de Perron-Frobenius a permis de formaliser des résultats plus généraux d’algèbre linéaire, mais aussi de topologie générale. C’est ce théorème qui a principalement motivé cette thèse. La bibliothèque SSReflect contient déjà une formalisation assez avancée sur les matrices, les polynômes et les propriétés algébriques. Ceci nous a fourni une bonne base pour développer les travaux de cette thèse. La formalisation des formes normales de Frobenius et de Jordan vue au chapitre 2, outre le fait d’avoir une preuve formelle de ces résultats, a occasionné le développement de théories sur les matrices diagonales par blocs, et sur les matrices semblales ou équivalentes. Ce sont des théories qui sont utilisées dans d’autres contextes mathématiques et donc nous espérons que ces outils pourront être réutilisés pour la formalisation d’autres résultats mathématiques. Dans le chapitre 3 nous avons formalisé les structures d’espace métrique et topologique. Il existe déjà une topologie dans la bibliothèque standard de Coq sur les nombre réels. Ici nous avons défini une structure générale de topologie pour avoir des résultats qui puissent être utilisés aussi bien sur des réels que sur des matrices ou sur des nombres complexes. Le résultat important de ce développement sur la topologie est le théorème de Bolzano-Weierstraß. Pour l’utilisation de ce théorème, il serait intéressant par la suite d’implémenter les structures d’espace normé et euclidien, ainsi que les propriétés de compacité des produits cartésiens d’ensembles. Cela permettrait d’avoir des théorèmes généraux supplémentaires pour montrer la compacité d’un ensemble. Les développements sur les formes normales de matrices et sur la topologie ont été formalisés de manière indépendante et dans le but de pouvoir être réutilisés. Le théorème de Perron-Frobenius est une première application de l’utilisation de ces développements formels. En effet, nous avons réussi à instancier une métrique et une topologie sur les matrices et les nombres réels ou complexes. Ensuite nous avons pu prouver des résultats sur la convergence de certaines suites. Et la forme normale de Jordan a permis de montrer un résultat important sur la convergence des suites des puissances de matrices. Cependant la partie du théorème de Perron-Frobenius utilisant le théorème de Bolzano-Weierstraß n’a pu être encore formalisée. Pour finir cette partie de la preuve, il reste à montrer quelques résultats comme la continuité du rayon spectral, et d’autres résultats de topologie pour pouvoir montrer la compacité d’un ensemble, et utiliser Bolzano-Weierstraß.Bibliographie [1] Andrea Asperti, Claudio Sacerdoti Coen, Ferruccio Guidi, Enrico Tassi et Stefano Zacchiroli : Matita v0.99.1 : User manual, 2006. http://matita.cs.unibo.it/. 3 [2] Andrea Asperti, Maria Emilia Maietti, Claudio Sacerdoti Coen, Giovanni Sambin et Silvio Valentini : Formalization of formal topology by means of the interactive theorem prover matita. In Proceedings of the 18th Calculemus and 10th International Conference on Intelligent Computer Mathematics, MKM’11, pages 278–280, Berlin, Heidelberg, 2011. SpringerVerlag. 67 [3] Yves Bertot et Pierre Castéran : Interactive Theorem Proving and Program Development – Coq’Art : The Calculus of Inductive Constructions. Texts in Theoretical Computer Science. An EATCS Series. Springer Verlag, 2004. 9 [4] Yves Bertot, Georges Gonthier, Sidi Ould Biha et Ioana Paşca : Canonical big operators. In Theorem Proving in Higher Order Logics, 21st International Conference, TPHOLs 2008, Montreal, Canada, volume 5170 de Lecture Notes in Computer Science, pages 86–101. Springer, 2008. 18 [5] François Bobot, Sylvain Conchon, Évelyne Contejean, Mohamed Iguernelala, Stéphane Lescuyer et Alain Mebsout : The Alt-Ergo automated theorem prover, 2008. http://alt-ergo.lri.fr/. 3 [6] Robert Stephen Boyer et J Strother Moore : A Computational Logic Handbook. Academic Press, Inc, 1988. 3 [7] Guillaume Cano et Maxime Dénès : Matrices à blocs et en forme canonique. In JFLA - Journées francophones des langages applicatifs, Aussois, France, 2013. 25 [8] Cyril Cohen : Formalized algebraic numbers : construction and first-order theory. Thèse de doctorat, École Polytechnique, 2012. 23 [9] Cyril Cohen, Maxime Dénès, Anders Mörtberg et Vincent Siles : Smith Normal form and executable rank for matrices, 2012.88 Bibliographie http://wiki.portal.chalmers.se/cse/pmwiki.php/ForMath/ProofExamples. 33, 35 [10] Robert L. Constable, Stuart F. Allen, H. M. Bromley, W. R. Cleaveland, J. F. Cremer, R. W. Harper, Douglas J. Howe, T. B. Knoblock, N. P. Mendler, P. Panangaden, James T. Sasaki et Scott F. Smith : Implementing mathematics with the nuprl proof development system, 1986. 3 [11] Leonardo de Moura et Nikolaj Bjørner : Z3 : An efficient SMT solver. In Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS), Budapest, Hungary, 2008. http://z3.codeplex.com/. 3 [12] Maxime Dénès : Étude formelle d’algorithmes efficaces en algèbre linéaire. Thèse de doctorat, Université de Nice - Sophia Antipolis, 2013. 33 [13] The Coq development team : The Coq proof assistant : Reference manual, 2013. http://coq.inria.fr/. 3 [14] François Garillot : Outils génériques de preuve et théorie des groupes finis. These, Ecole Polytechnique X, décembre 2011. 59, 80 [15] François Garillot, Georges Gonthier, Assia Mahboubi et Laurence Rideau : Packaging Mathematical Structures. In Tobias Nipkow et Christian Urban, éditeurs : Theorem Proving in Higher Order Logics, volume 5674 de Lecture Notes in Computer Science, Munich, Germany, 2009. Springer. 80 [16] Isabelle Gil : Contribution à l’algèbre linéaire formelle. Thèse de doctorat, Institut Nationale Polytechnique de Grenoble, 1993. 25 [17] Ruben Gomboa, John Cowles et Jeff Van Baalen : Using ACL2 arrays to formalize matrix algebra. ACL2 Workshop 2003, Boulder, 2003. 50 [18] Georges Gonthier : The four colour theorem : Engineering of a formal proof. In Computer Mathematics, 8th Asian Symposium, ASCM 2007, volume 5081 de Lecture Notes in Computer Science, page 333. Springer, 2007. 4 [19] Georges Gonthier, Andrea Asperti, Jeremy Avigad, Yves Bertot, Cyril Cohen, François Garillot, Stéphane Le Roux, Assia Mahboubi, Russell O’Connor, Sidi Ould Biha, Ioana Paşca, Laurence Rideau, Alexey Solovyev, Enrico Tassi et Laurent Théry : A machine-checked proof of the odd order theorem. In Interactive Theorem Proving - 4th International Conference, ITP 2013, Rennes, France. Proceedings, volume 7998 de Lecture Notes in Computer Science, pages 163–179. Springer, 2013. 5Bibliographie 89 [20] Georges Gonthier et Assia Mahboubi : A Small Scale Reflection Extension for the Coq system. Research Report RR-6455, INRIA, 2008. 4 [21] Thomas Callister Hales : Introduction to the flyspeck project. In Mathematics, Algorithms, Proofs, volume 05021 de Dagstuhl Seminar Proceedings. Internationales Begegnungs- und Forschungszentrum für Informatik (IBFI), Schloss Dagstuhl, Germany, 2005. 5 [22] Thomas Callister Hales, John Harrison, Sean McLaughlin, Tobias Nipkow, Steven Obua et Roland Zumkeller : A revision of the proof of the kepler conjecture. Discrete & Computational Geometry, 44(1):1–34, 2010. 5 [23] John Harrison : A HOL theory of Euclidean space. In Joe Hurd et Tom Melham, éditeurs : Theorem Proving in Higher Order Logics, 18th International Conference, TPHOLs 2005, volume 3603 de Lecture Notes in Computer Science, Oxford, UK, 2005. Springer-Verlag. 50, 67 [24] John Harrison : Handbook of Practical Logic and Automated Reasoning. Cambridge University Press, New York, NY, USA, 1st édition, 2009. 3 [25] John Harrison : The HOL-Light system reference. University of Cambridge, 2013. http://www.cl.cam.ac.uk/~jrh13/hol-light/. 3 [26] Johannes Hölzl, Fabian Immler et Brian Huffman : Type classes and filters for mathematical analysis in Isabelle/HOL. In Proceedings of the 4th International Conference on Interactive Theorem Proving, ITP’13, pages 279–294, Berlin, Heidelberg, 2013. Springer-Verlag. 67 [27] Katarzyna Jankowska : Matrices. Abelian group of matrices. Formalized Mathematics, 2(4):475–480, 1991. 50 [28] Matt Kaufmann et J Strother Moore : ACL2, 2013. http://www.cs.utexas.edu/~moore/acl2/. 3 [29] Matt Kaufmann, J. Strother Moore et Panagiotis Manolios : ComputerAided Reasoning : An Approach. Kluwer Academic Publishers, Norwell, MA, USA, 2000. 3 [30] David R. Lester : Topology in PVS : Continuous mathematics with applications. In Proceedings of the Second Workshop on Automated Formal Methods, AFM ’07, pages 11–20, New York, NY, USA, 2007. ACM. 67 [31] Guillaume Melquiond : User’s guide for gappa, 2013. http://gappa.gforge.inria.fr/. 3 [32] Jean-Pierre Merlet : Interval Analysis and Reliability in Robotics, mars 2006. 6, 6990 Bibliographie [33] Michał Muzalewski : An outline of PC Mizar. Fondation Philippe le Hodey, 1993. http://mizar.uwb.edu.pl/. 3 [34] Raúl Naulin et Carlos Pabst : The roots of a polynomial depend continuously on its coefficients. Revista Colombiana de Matemáticas, 28(1):35–37, 1994. 83 [35] Michael Norrish, Konrad Slind et al. : The HOL system reference. Automated Reasoning Group, University of Cambridge, Computer Laboratory, 2013. http://hol.sourceforge.net/. 3 [36] Steven Obua : Proving bounds for real linear programs in Isabelle/HOL. In Joe Hurd et Thomas F. Melham, éditeurs : TPHOLs, volume 3603 de Lecture Notes in Computer Science, pages 227–244. Springer, 2005. 50 [37] Patrick Ozello : Calcul exact des formes de Jordan et de Frobenius d’une matrice. Thèse de doctorat, Université Scientifique Technologique et Médicale de Grenoble, 1987. 25 [38] Beata Padlewska et Agata Darmochwał : Topological spaces and continuous functions. Formalized Mathematics, 1(1):223–230, 1990. 67 [39] Karol Pąk : Block diagonal matrices. Formalized Mathematics, 16(3):259– 267, 2008. 50 [40] Karol Pąk : Eigenvalues of a linear transformation. Formalized Mathematics, 16(4):289–295, 2008. 84 [41] Karol Pąk : Jordan matrix decomposition. Formalized Mathematics, 16(4): 297–303, 2008. 50 [42] Ioana Paşca : Vérification formelle pour les méthodes numériques. Thèse de doctorat, Université Nice-Sophia Antipolis, 2010. 6, 69, 73, 77 [43] Giovanni Sambin : The basic picture, a structure for topology (the basic picture, i). Rapport technique, 2001. 67 [44] Stephan Schulz : E 1.8 : User manual, 2013. http://www4.informatik.tu-muenchen.de/~schulz/E/. 3 [45] Natarajan Shankar, Sam Owre, John M. Rushby et David William John Stringer-Calvert : PVS prover guide, 2001. http://pvs.csl.sri.com/. 3 [46] Vincent Siles : A formal proof of the Cauchy-Binet formula, 2012. http://wiki.portal.chalmers.se/cse/pmwiki.php/ForMath/ProofExamples. 38Bibliographie 91 [47] Matthieu Sozeau et Nicolas Oury : First-Class Type Classes. In Otmame Aït-Mohamed, César Muñoz et Sofiène Tahar, éditeurs : 21th International Conference on Theorem Proving in Higher Order Logics, volume 5170 de Lecture Notes in Computer Science. Springer, août 2008. 53 [48] Shlomo Sternberg : Dynamical Systems. Dover Publications, 2010. Chapitre 9. 69 [49] Joe Hendrix University et Joe Hendrix : Matrices in ACL2, 2003. 50 [50] Makarius Wenzel et al. : The Isabelle/Isar reference manual, 2013. http://www.cl.cam.ac.uk/research/hvg/Isabelle/. 3 M´ethodes num´eriques pour la spatialisation sonore, de la simulation `a la synth`ese binaurale Matthieu Aussal To cite this version: Matthieu Aussal. M´ethodes num´eriques pour la spatialisation sonore, de la simulation `a la synth`ese binaurale. Mathematics. Ecole Polytechnique X, 2014. French. HAL Id: tel-01095801 https://pastel.archives-ouvertes.fr/tel-01095801 Submitted on 16 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Thèse pour l’obtention du titre de Docteur de l’École Polytechnique Spécialité : Mathématiques appliquées par Matthieu Aussal Méthodes numériques pour la spatialisation sonore, de la simulation à la synthèse binaurale. Soutenue le 02 octobre 2014 Rapporteurs et membres du jury Directeur de thèse : François Alouges (École Polytechnique) Rapporteurs : Leslie Greengard (New York University) Jean-Marc Jot (DTS inc.) Séraphin Mefire (Université de Lorraine) Examinateurs : Toufic Abboud (École Polytechnique) Joël Bensoam (IRCAM) Marc Bonnet (ENSTA) Directeurs Industriels : Vincent Mouret (Digital Media Solutions) Hervé Roux (Digital Media Solutions)Remerciements Mes premiers remerciements vont tout naturellement à Hervé Roux, initiateur de ces recherches à travers la société Digital Media Solutions et Vincent Mouret, qui a repris le flambeau avec la même ferveur. Merci de m’avoir fait confiance, et ce dès le début, en me laissant toute la liberté d’agir sans autre contrainte que celle d’imaginer l’avenir. En m’impliquant doucement mais sûrement dans les rouages de la société, vous m’avez transmis le goût de l’entrepreneuriat. Je remercie mes rapporteurs, MM. Leslie Greengard, Jean-Marc Jot et Séraphin Mefire d’avoir accepté de consacrer une partie de leurs vacances à relire mon manuscrit. J’ai été très honoré qu’ils acceptent cette charge et particulièrement touché par les compliments de leurs rapports respectifs. Je tiens aussi à remercier MM. Toufic Abboud, Joël Bensoam et Marc Bonnet d’avoir accepté de faire partie de mon jury. Merci à Toufic de nous avoir proposé son aide lorsque nous en avions besoin. Merci à Joël de m’avoir donné le goût des équations intégrales pour l’acoustique. Merci à Marc pour les nombreux échanges passés et à venir. Par ailleurs, je remercie les doctorants et personnels du Centre de Mathématiques Appliquées de l’École Polytechnique qui se sont prêtés de nombreuses fois à des expériences sonores diverses et variées, et toujours avec le sourire. Un grand merci aussi à l’École Polytechnique, et plus spécifiquement au CMAP et Antonin Chambolle, pour m’avoir accueilli pendant ce doctorat, et pour m’accueillir encore pendant quelques temps. Une pensée toute particulière accompagne l’équipe Audio 3D de DMS, qui a réussie à supporter mon encadrement sans (trop) broncher ! ;-) Encore Bravo à Mathieu Coïc pour la quantité/qualité colossale de travail abattu et merci pour cette ambiance si chaleureuse. Merci à Alexandre Dazzoni pour ses conseils et sa grande disponibilité. Je souhaiterais aussi féliciter et remercier les nombreux stagiaires que j’ai eu le plaisir d’encadrer : Ivan Alouges, Louis Anglionin, Martin Averseng, Pierre Bézard, Timothée Chevalier, Marie-Julie Dhaou, Louis Faucon (et merci à l’ADO !), Valentin Labourette, Hanna Ma-tahri, Lasse Munk, François Salmon, Adel Chelghoum et Augustin Deprez. J’en profite pour remercier tout le personel de DMS et tout particulièrement Nathalie, Alix, Mika, Walid, Ludo, Pascal C., Eric, Matthieu D., PatrickGilles, Guillaume E., Lucas et Alberto. En vrac, encore merci à Sylvie Tonda-Goldstein pour son aide précieuse en démêlage de sac de nœuds, à Hervé Le Meur pour ses nombreux coups de pouce, à Timothée Chevalier pour ses maillages de tête à trous, à Sylvain Faure et Pascal Frey pour leurs maillages de tête sans trou, à Jean-Christophe Messonnier pour les nombreuses conversations, à Hervé Déjardin pour ses riches conseils, aux membres du consortium BiLi, à Sophie-Anaïs pour son expertise, à Isabelle et Jean pour la transmission de savoirs, à Manou et So pour leurs coups de main, à Grany, à The Mathworks d’avoir inventé Matlab, au bâtiment 334, aux d’Yvette d’en face pour leurs superbes voix et à Vincent, l’ami éternel. Enfin, il faudrait bien plus qu’un merci à ma famille, ma belle-famille et mes amis pour leur soutien sans faille. Et puisqu’il est coutume de garder le meilleur pour la fin, je tiens à adresser mes plus sincères et chaleureux remerciements à François Alouges. Au-delà d’un encadrement scientifique d’une rare qualité, tu as été d’une extrême bienveillance pendant ces trois années qui, grâce à toi, furent d’une richesse inouïe. Je te dois cette thèse, alors vraiment, merci.à Caroline et à nos enfants Crédits : Bob de Groot et Turk, Léonard est un génie, ed. Le Lombard, 1977.Résumé Les recherches effectuées lors de ce doctorat ont été initiées par un besoin industriel identifié par la société Digital Media Solutions, à savoir la réalisation d’un outil de spatialisation sonore au casque destiné aux nonvoyants. Malgré les nombreux dispositifs déjà existants, les techniques de synthèse binaurale butent, depuis leur apparition, sur un obstacle majeur, qui empêche la réalisation de produits de haute qualité. En effet, pour rendre l’illusion d’un espace sonore perceptible, les déformations temporelles et spectrales issues de la propagation d’une onde sonore jusqu’aux tympans doivent être restituées le plus fidèlement possible. En plus des difficultés classiques rencontrées en traitement du signal audio, ceci entraîne, de facto, la nécessité d’individualiser les fonctions de transfert HRTF, traduisant pour chacun l’empreinte spatiale d’une source sonore. Pour réaliser cette personnalisation, une première approche consiste à mesurer en laboratoire les HRTF de chaque individu. Bien qu’offrant des résultats convaincants, cette technique n’est pas encore applicable au grand public, car le processus est long, pé- nible et relativement coûteux. C’est pourquoi la modélisation mathématique a été envisagée. Sous réserve d’un maillage représentatif de la morphologie de l’auditeur, la résolution numérique des équations de propagation des ondes pourrait avantageusement remplacer la mesure. Aujourd’hui, des outils grand public (e.g. Kinect de Microsoft) permettent la réalisation de maillages satisfaisants, qui peuvent être perfectionnés, voire couplés, à des formes élé- mentaires analytiques (Sphères, Ellipses, Cônes, etc.). La thèse se concentre alors sur deux axes principaux et complémentaires. D’une part, nous avons développé (conjointement avec F. Alouges) un nouveau moteur de calcul intégral par éléments finis de frontières (MyBEM), réalisé sous Matlab. Ce dernier est appliqué à la résolution des équations de l’acoustique. Pour pouvoir calculer les fonctions de transfert HRTF sur l’ensemble des fréquences audibles, une nouvelle méthode rapide de convolution a été conçue, implémentée, puis validée analytiquement. À partir d’une quadrature monodimensionnelle performante d’un noyau de Green quelconque (Laplace, Helmholtz, Stokes, Maxwell, etc), une séparation des variables permet 1le calcul rapide d’un produit de convolution dans l’espace. Dénommée "Dé- composition Creuse en Sinus Cardinal" (SCSD), cette méthode est confrontée à la "Méthode Multipolaire Rapide" (FMM), référence reconnue en la matière. D’autre part, une fois les HRTF mesurées ou calculées sur une grille sphé- rique discrète, une résolution de quelques degrés angulaires est indispensable pour pouvoir effectuer un rendu spatial de grande qualité. Il faut donc procéder à des interpolations de filtres, qui nuisent à la qualité du rendu audio et à l’impression d’externalisation. Cependant, une nouvelle compréhension des HRTF initiée avant la thèse a permis un sous-échantillonnage spatial des bases de données, sans produire d’artefacts audibles, mais aussi une personnalisation par filtrage inverse. Mise en œuvre au sein d’un moteur de rendu audio spatialisé sous Matlab (PifPaf3D), cette technique appelée "Décomposition par Modèle Morphologique" a montré des qualités reconnues par validations subjectives. Par ailleurs, de nombreux outils connexes ont été intégrés à ce moteur, pour améliorer encore le rendu spatial, comme des acoustiques de salles ou la compensation du casque audio. Ces deux étapes, abouties et maîtrisées, doivent désormais être couplées en vue de réaliser une chaîne complète de synthèse binaurale numérique. 2Abstract Research conducted during this PhD were initiated by an industrial need identified by Digital Media Solutions, namely the creation of a tool for spatial sound rendering through headphones for blind people. Despite the many existing devices, techniques for binaural synthesis face, since their appearance, a major obstacle that prevents to realize high quality products. Indeed, to make the illusion of a perceptible sound space, temporal and spectral distortions resulting from the propagation of a sound wave to the ears must be reproduced as accurately as possible. In addition to traditional difficulties in audio signal processing, this enlightens the need to individualize the Head Related Transfer Functions (HRTF), that encode the spatial impression of a sound source. To achieve this individualization, a first approach consists in measuring in the laboratory the HRTF of each individual. Although offering convincing results, this technique is not yet applicable to the general public, because the process is long, painful, and relatively expensive. This is why mathematical modeling has been considered. Subject to a mesh representing the morphology of the listener, the numerical solution of the wave propagation equations could advantageously replace the measure. Today, large public tools (e.g. Microsoft Kinect) allow the construction of satisfactory meshes, which can be refined, when coupled with analytical basic shapes (spheres, Ellipse, cones, etc..). The thesis then focuses on two main and complementary axes. On the one hand, we have developed (jointly with F. Alouges) a new boundary element method software (MyBEM). Realized in Matlab, we apply it to solve the equations of acoustics. For the calculation of the HRTF across all audible frequencies, a new fast convolution method has been designed, implemented and validated analytically. From the efficient one dimensional quadrature of any Green kernel (Laplace, Helmholtz, Stokes, Maxwell, etc.), a separation of variables allows a fast convolution in space calculation. Called "Sparse Cardinal Sine Decomposition" (SCSD), this method is confronted with the Fast Multipole Method (FMM) renowned as the state-of-the-art in the domain. 3Moreover, once the HRTF are measured or calculated on a discrete spherical grid, a resolution of a few angular degrees is essential to perform a high quality spatial rendering. It is therefore necessary to interpolate the filters, and that affects the quality of the audio rendering. However, a new understanding initiated before the PhD allows an undersampling of the databases, without producing audible artifacts, and providing with a possibility of individualization by inverse filtering. Implemented in a spatial audio rendering engine (PifPaf3D), this technique called "Morphological Model Decomposition" has been validated by subjective tests. Moreover, many related tools have been integrated into the engine, to further improve the spatial rendering, such as acoustic rooms or headphones compensation. These two stages, accomplished and mastered must now be coupled in order to achieve a complete chain of digital binaural synthesis. 4Table des matières Résumé/Abstract 1 1 Synthèse binaurale et HRTF 7 1.1 Introduction à l’écoute spatialisée . . . . . . . . . . . . . . . . 7 1.1.1 Espace sonore . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.2 Théorie du Duplex . . . . . . . . . . . . . . . . . . . . 9 1.1.3 Head-Related Transfer Function . . . . . . . . . . . . . 11 1.2 Exemples de systèmes de spatialisation sonore . . . . . . . . . 14 1.2.1 Panning d’Amplitude, de la stéréo au VBAP . . . . . . 14 1.2.2 High Order Ambisonics, captation et restitution . . . . 17 1.2.3 Technologies binaurales, enregistrement et synthèse . . 21 1.3 Head-Related Transfer Function, what else ? . . . . . . . . . . 24 1.3.1 Modèle de HRTF, la sphère rigide . . . . . . . . . . . . 25 1.3.2 Mesures de HRTF, Acoustics Research Institute . . . . 31 1.3.3 Interpolation linéaire . . . . . . . . . . . . . . . . . . . 34 1.3.4 Interpolation par harmoniques sphériques . . . . . . . . 43 1.4 Décomposition par Modèle Morphologique . . . . . . . . . . . 48 1.4.1 Principe et résultats . . . . . . . . . . . . . . . . . . . 48 1.4.2 Interpolation optimisée . . . . . . . . . . . . . . . . . . 54 1.4.3 Variations de position . . . . . . . . . . . . . . . . . . 57 1.4.4 Déraffinement spatial d’une base de données . . . . . . 59 1.4.5 Vers une méthode d’individualisation . . . . . . . . . . 62 2 Moteur binaural PifPaf3D 67 2.1 Introduction et configuration . . . . . . . . . . . . . . . . . . . 67 2.2 Transport et contrôle . . . . . . . . . . . . . . . . . . . . . . . 70 2.3 Traitement Binaural . . . . . . . . . . . . . . . . . . . . . . . 72 2.4 Acoustique de salle et Ambisonics . . . . . . . . . . . . . . . . 77 2.5 Compensation du casque et égalisation . . . . . . . . . . . . . 81 2.6 SpherAudio Headphones . . . . . . . . . . . . . . . . . . . . . 83 53 Formulations intégrales rapides pour l’acoustique 89 3.1 Représentation et équations intégrales . . . . . . . . . . . . . . 91 3.1.1 Diffraction dans l’espace libre . . . . . . . . . . . . . . 91 3.1.2 Diffraction en présence d’un obstacle . . . . . . . . . . 93 3.1.3 Équations intégrales . . . . . . . . . . . . . . . . . . . 96 3.1.4 Formulations discrètes . . . . . . . . . . . . . . . . . . 99 3.2 Introduction aux méthodes multipolaires rapides . . . . . . . . 101 3.3 Nouvelle méthode rapide - SCSD . . . . . . . . . . . . . . . . 104 3.3.1 Vers un problème mono-dimensionnel . . . . . . . . . . 105 3.3.2 Résolution du problème . . . . . . . . . . . . . . . . . 106 3.3.3 Formalisme final pour l’équation de Helmholtz . . . . . 116 3.3.4 Extension vers Laplace (et plus si affinités...) . . . . . . 120 3.4 Comparaisons et performances . . . . . . . . . . . . . . . . . . 123 3.4.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . 123 3.4.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . 124 4 Moteur intégral MyBEM 131 4.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 4.2 Validations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 4.3 Applications au calcul de HRTF . . . . . . . . . . . . . . . . . 142 Conclusion 153 Bibliographie 155 Articles 163 6Chapitre 1 Synthèse binaurale et HRTF Ce premier chapitre a pour but de poser le cadre théorique des recherches en spatialisation sonore effectuées avant, puis pendant la thèse, notamment en synthèse binaurale. En effet, il est important de préciser que les travaux de recherche exposés ici s’inscrivent dans la continuité de travaux effectués au préalable et par le même auteur au sein de la société Digital Media Solutions. Ces travaux ont donné naissance à un spatialisateur innovant, appelé PifPaf3D, écrit exclusivement en langage Matlab, dont le développement s’est poursuivi au cours de ces trois années de thèse. Aussi, certains aspects pré- sentés dans ce chapitre sortent du sujet de thèse initial, mais ont néanmoins motivé des axes de développement non négligeables. 1.1 Introduction à l’écoute spatialisée De par sa grande complexité et ses multiples domaines d’étude (physiologie, neurologie, psycho-acoustique, physique ondulatoire, etc.), seuls les principes généraux de la perception spatiale liée au système auditif humain sont présentés ici, en guise d’introduction ou de rappel. Le lecteur curieux est invité à se documenter sur les ouvrages de références [10], [15] et [68], ou encore les manuscrits de thèse [20] et [70]. Pour une courte introduction, [14] et [17] présentent un excellent résumé, avec une bibliographie détaillée. 1.1.1 Espace sonore La perception sonore de l’espace, bien que souvent négligée au profit de la perception visuelle, n’en est pas moins fondamentale puisqu’elle est l’unique indicateur environnemental qui ne souffre d’aucune restriction spatiale. À titre comparatif, le système visuel (vision fovéale + périphérique) 7Figure 1.1 – Vue subjective du célèbre jeu de tir à la première personne Counter Strike. ne délivre d’informations que sur une faible portion de l’espace, alors que le système auditif est effectif pour toutes les directions, avec une précision angulaire (Just Noticeable Difference) de l’ordre de quelques degrés. De plus, le système auditif effectue une analyse permanente et souvent inconsciente de l’environnement, tandis que le système visuel est de plus en plus requis pour effectuer des tâches quotidiennes, nécessitant une attention particulière. La capture d’écran présentée en figure 1.1 est un exemple issu du monde des jeux vidéos. Cette vision subjective du célèbre jeu de tir à la première personne (FPS) Counter Strike présente un certain nombre d’objets, comme les mains du joueur, des caisses, une terrasse, des murs, etc. Bref, aucun danger n’est visuellement apparent. Si le joueur ne dispose pas d’un système de rendu sonore, il n’aura aucune information relative à son environnement autre que celles fournies par la vision, ce qui est restrictif. Si, au contraire, le joueur dispose d’un rendu stéréo classique, il aura accès à d’autres données non visibles. Cependant, privé d’une perception sonore en rendu spatialisé, le joueur devra balayer visuellement l’ensemble de la scène à la moindre alerte auditive, pour identifier la position de la source sonore (tirs, bruits de pas, explosion, etc.). Ce temps perdu peut lui être dommageable. Aussi, pour que le joueur puisse pleinement et rapidement appréhender tout danger non visible à l’écran, un rendu spatial de la scène sonore serait souhaitable. Les mêmes principes s’appliquent au quotidien, à savoir que le système auditif fournit l’ensemble des informations nécessaires à une perception spatiale de l’environnent, dynamique et analytique. La spatialisation sonore est une branche de l’Acoustique dont on peut défi- 8Figure 1.2 – Système auditif humain. (source www.alynsimardaudio.com) nir l’objectif général comme étant "la (re)création d’un espace sonore subjectif au niveau de l’auditeur" [20]. D’un point de vue physiologique, l’étude de la spatialisation sonore part d’une hypothèse fondatrice, à savoir que l’oreille interne et l’oreille moyenne n’interviennent pas dans la création des indices de localisation tridimensionnels. La figure 1.2 fournit un embryon d’explication par une représentation en coupe du système auditif humain. Lorsqu’une onde sonore (une variation de pression dans l’air) atteint le tympan, celle-ci est ensuite transmise mécaniquement par les osselets vers la cochlée. Cette dernière encode alors le signal sonore en impulsions électriques, acheminées au cerveau par le nerf auditif. Dans ce schéma simpliste, une fois que l’onde sonore a fait vibrer le tympan, ce dernier transmet un signal qui se propage de l’oreille moyenne jusqu’au cerveau, sans aucun ajout possible d’informations spatiales. Aussi, la compression des informations de localisation encodées dans ce signal ne peut être faite qu’avant. 1.1.2 Théorie du Duplex Des indices dits de localisation sont inhérents à l’analyse discriminatoire de l’espace sonore, effectuée par notre système cognitif. Dans ce sens, deux contributions principales ont été mises en évidence par Lord Rayleigh en 1907, formant ainsi la théorie du Duplex [74]. Cette dernière fut ainsi nommée car elle met en lumière l’analyse des indices acoustiques interauraux, c’est-à-dire issus des signaux perçus conjointement par les deux oreilles. Sur le schéma 9Figure 1.3 – Représentation graphique de l’ITD et de l’ILD. (source www.kfs.oeaw.ac.at) de la figure 1.3, l’onde sonore incidente est supposée provenir de l’infini. De ce fait, les isovaleurs de pression acoustique sont orthogonales au sens de propagation. Ainsi, de par l’orientation de l’onde dans le plan horizontal, l’oreille gauche percevra l’information plus tôt et plus fort que l’oreille droite. Ces écarts de temps et d’intensité sont caractérisés respectivement par l’ITD et l’ILD : – Interaural Time Difference, ITD : La différence interaurale de temps est la différence de temps d’arrivée d’une onde sonore entre les deux oreilles. Cet indice de localisation joue un rôle fondamental pour la localisation dans le plan horizontal, notamment en basse fréquence ; – Interaural Level/Intensity Difference, ILD ou IID : La différence interaurale de niveau est la différence d’intensité de l’onde sonore entre les deux oreilles. Cet indice de localisation joue de même un rôle fondamental pour la localisation azimutale, notamment en moyenne et haute fréquence. En revanche, cette théorie est incomplète pour les sources sonores qui seraient, par exemple, dans le plan médian. En effet, l’ITD et l’ILD sont grossièrement identiques pour une source sonore devant, dessus ou encore derrière un auditeur. Pourtant, l’être humain est capable de discriminer ces directions, avec une précision exemplaire. Le fait est que la théorie du Duplex ne tient pas compte des dissymétries de la tête et du pavillon. 10Figure 1.4 – Cônes de confusion, représentant les isovaleurs de l’ITD et de l’ILD pour une approximation de tête sphérique sans pavillon. (source www.humansystems.arc.nasa.gov) 1.1.3 Head-Related Transfer Function Avec l’approximation de tête sphérique [85], l’ILD et l’ITD de la théorie du Duplex n’apportent pas d’informations discriminatoires dans le plan median, ni dans des cônes communément appelés "cônes de confusion" (fig. 1.4). Il manque donc un indice de localisation pour compléter cette théorie. Ce dernier indice est principalement lié à la morphologie de l’auditeur, notamment la géométrie du pavillon et du conduit auditif de l’oreille externe (fig. 1.2) qui modifient singulièrement l’onde sonore incidente. En effet, des ondes ré- fléchies peuvent être engendrées selon l’incidence, ainsi que des déformations spectrales liées à des modes de résonance (fig. 1.5). Le timbre du signal émis par la source sonore est alors modifié et ce, en fonction de sa position dans l’espace. Il en résulte des filtres spatio-fréquentiels relativement complexes, encore appelés Direction-Dependent Filters (fig. 1.6). Ces trois indices (ITD, ILD et DDF) sont inclus dans un modèle plus général de filtres fréquentiels communément appelés Head-Related Transfert Functions (HRTF). Par Transformée de Fourier, ces filtres s’expriment aussi bien en domaine fréquentiel qu’en domaine temporel, sous forme de HeadRelated Impulse Responses (HRIR), et peuvent être définis comme suit : HRTF : R 3 × R + → C (r, θ, φ) × f → HRT F HRIR : R 3 × R + → R (r, θ, φ) × t → HRIR 11Figure 1.5 – Modes de résonance de l’oreille externe. (source www.dtmblabber.blogspot.fr, d’après [78]) Figure 1.6 – Représentation directionelle des Directions Depending Filters de l’oreille gauche du sujet 003 de la base CIPIC. Visualisation de l’amplitude spectrale (dB) pour des sources sonores situées sur la sphère unité (croix noire), à fréquence fixe, dans le repère de la figure 1.4. De gauche à droite, la fréquence vaut respectivement 2 kHz, 8 kHz et 15 kHz. 12Figure 1.7 – Amplitude spectrale (dB) des HRTF de l’oreille gauche du sujet 003 de la base CIPIC, dans le plan médian. L’amplitude spectrale (dB) pour quelques positions de ces filtres est représentée sur la figure 1.7. L’azimut est fixé à 0˚, pour une élévation croissante de 0˚ à 80˚ (plan median). Comme le montre cette figure, il existe une forte variabilité entre chacun de ces filtres, induisant une grande complexité dans leur étude. Ces fonctions de transfert HRTF établissent donc une cartographie spatiale minutieuse du système auditif humain et sont, de par leur nature même, propres à chaque individu. Enfin, il est intéressant de souligner que ces filtres peuvent être : – Mesurés par réponse impulsionnelle sous forme de HRIR (e.g. [3], [62], [6]) ; – Modélisés de manière analytique (e.g. [85], [57], [25]) ou par simulation numérique (e.g. [50], [51], [39]) ; – Échangés sous forme de bases de données (e.g. [65], [9]) ; – Individualisés, par divers et nommbreux procédés. La compréhension et l’exploitation de ces HRTF représente un enjeu majeur pour la recherche en spatialisation sonore, mais aussi pour les industriels soucieux d’innovations technologiques. En effet, la perception d’un espace sonore réaliste devient possible dès lors que les trois indices formant les HRTF sont correctement restitués, ou dans une moindre mesure au moins l’un des trois. Aussi, tout système de restitution sonore en exploite certaines proprié- tés, directement sur casque audio ou indirectement sur enceintes. 13Figure 1.8 – Principe de la stéréophonie et notion de "Sweet Spot". 1.2 Exemples de systèmes de spatialisation sonore Il existe de nombreux systèmes de spatialisation sonore, chacun exploitant de savants mélanges au sein des dimensions perceptives et physiques. Dans cette section, trois de ces techniques sont détaillées, à savoir le panning d’amplitude et sa généralisation au Vector Base Amplitude Panning (VBAP), l’approche Ambisonics et son extension en High Order Ambisonics et pour terminer la synthèse binaurale. Ce choix est principalement motivé par le fait qu’elles ont toutes trois été intégrées dans le spatialisateur PifPaf3D, moteur de rendu audio 3D Matlab détaillé dans le chapitre suivant. 1.2.1 Panning d’Amplitude, de la stéréo au VBAP Le panning d’amplitude est apparu avec les premiers supports utilisant plus d’un canal de diffusion et fait partie des plus anciennes techniques de spatialisation sonore [83]. Le principe théorique est relativement simple, à savoir la création d’une image sonore virtuelle dite "Fantôme", en jouant sur la différence d’intensité de sources sonores réelles ( haut-parleurs). Tout l’art de l’ingénieur du son consiste en l’obtention d’une image sonore robuste et réaliste, répartissant judicieusement l’ensemble des objets virtuels sur des segments reliant les sources réelles. La restitution stéréophonique, encore très largement dominante aujourd’hui, est fondée sur ce principe. En disposant l’auditeur et deux haut-parleurs (gauche et droit) sur les sommets d’un triangle équilatéral, ce système permet une restitution spatialisée sur une dimension d’espace. Il est important de noter qu’une contrainte forte af- 14Figure 1.9 – Disposition fixée de haut-parleurs en 5.1 (en traits pleins), 9.1 (en tirets) et 22.2 (en pointillés). (source Wikipedia) fecte l’ensemble des systèmes de spatialisation sonore sur enceintes, à savoir le positionnement des sources sonores par rapport à l’auditeur (notion de Sweet Spot). Celle-ci est déjà présente sur un système à deux canaux, tel que le montre la figure 1.8. Dans la lignée de la stéréophonie, plusieurs systèmes de restitution en audio spatialisé sont progressivement apparus, comme la quadriphonie, le 5.1, le 7.1, le 9.1, ou plus récemment le 22.2 de la NHK (fig. 1.9, [42]). Tous utilisent des maillages de haut-parleurs répartis sur des positions préalablement fixées dans l’espace autour de l’auditeur. Ces systèmes permettent d’étendre les principes fondateurs de la stéréophonie sur des maillages plus denses de haut-parleurs, sur un cercle entourant l’auditeur (1D), voire sur une sphère (2D). En appliquant des lois de panning prédéfinies, des sources sonores fantômes peuvent ainsi être créées. Il est intéressant de remarquer qu’aucun de ces systèmes n’est réellement 3D en terme de répartition de haut-parleurs. Ceci est notamment lié à la faible précision de la localisation en distance, qui est préférentiellement rendue dans sa dimension perceptive plutôt que physique [48]. Enfin, de récents travaux ont donné naissance aux techniques de Vector 15Figure 1.10 – Principe du Vector Base Amplitude Panning : la source virtuelle, symbolisée par sa pression acoustique p, est générée par panning d’intensité de coefficients Ij appliqués aux trois sources sonores adjacentes j. (source www.ausim3d.com/products/Vectsonic) Base Amplitude Panning (VBAP), autorisant une répartition quelconque des haut-parleurs sur une sphère entourant l’auditeur [73]. Cette approche est une extension de la stéréo vers un système à multiples sources sonores réelles, ce qui permet de définir un support quelconque pour les sources fantômes (triangle, quadrangle, etc.). Une loi d’interpolation est alors appliquée aux canaux pour déterminer leurs gains, en utilisant notamment les cordonnées barycentriques de la source virtuelle dans la base formée par les sources réelles (fig. 1.10). Un maillage quelconque de haut-parleurs peut être envisagé, ce qui permet de s’affranchir des contraintes liées aux systèmes fixes précédents. Cette méthode a été implémentée dans le spatialisateur PifPaf3D, en marge des travaux de thèse, et testée sur un maillage de 16 haut-parleurs répartis dans une pièce de type bureau. Le script réalisé permet notamment de générer le maillage triangulaire selon la position absolue des haut-parleurs, et de naviguer en temps réel dans ses éléments pour créer les sources fantômes. Les résultats de cette étude feront éventuellement l’objet d’une publication ultérieure. Face au développement de ces nouveaux systèmes de restitution, toujours plus complexes et précis, la notion d’objet sonore ponctuel devient dès lors incontournable pour que les techniques de spatialisation soient humaine- 16Figure 1.11 – (Gauche) Schéma du microphone Soundfield tel que breveté [19]. Quatre capsules cardioïdes sont placées sur les faces d’un tétraèdre régulier, dont les signaux (RF,LF,RB,LB) constituent le A-Format, ou format ambisonique brut. (Droite) Les composantes directionnelles du B-Format (W,X,Y,Z) ou format encodé. (source [20]). ment réalisables. En effet, le mixage stéréo ne nécessite qu’un potentiomètre pour répartir l’intensité sonore de la source virtuelle entre les deux canaux de diffusion. Dans le cas d’un maillage triangulaire dense, il est nécessaire de manipuler des objets sur des surfaces, ce qui complique singulièrement l’interface homme-machine. C’est pourquoi l’ensemble de la chaîne de traitement audio, de la captation à la restitution en passant par le mixage, subit aujourd’hui de grands bouleversements. 1.2.2 High Order Ambisonics, captation et restitution Parmi les nombreuses techniques émergentes de spatialisation sonore, l’approche Ambisonics et son extension High Order Ambisonics (HOA) fournissent une gamme d’outils complète sur l’ensemble de la chaîne de production (e.g. [19], [20], [21], [33]). Originellement, elles sont issues des techniques de prise de son par couple MS. Le principe général est de capter simultanément et ponctuellement un champ sonore à l’aide d’un micro bidirectif et d’un micro omnidirectionnel. Des informations directionnelles de la scène sonore sont alors nativement incluses dans les signaux de sortie des microphones, qui peuvent-être stockés ou échangés comme tels. Pour que l’image sonore soit directement rendue, dans une dimension d’espace, il suffit ensuite de restituer ce champ sur un système stéréophonique, par une sommation 17des signaux sur un haut-parleur et une opposition de phase sur l’autre. Cette technique de prise de son fut généralisée aux trois dimensions d’espace par Gerzon et donna naissance au fameux encodage B-Format du microphone Soundfield (fig. 1.11). À la restitution, le B- Format est décodé pour s’adapter au système de haut-parleurs, par exemple disposés sur les sommets d’un cube. Ce processus d’encodage-décodage d’une scène sonore spatialisée est une caractéristique propre des méthodes Ambisonics. Cependant, cette approche souffre d’une faible précision spatiale de par la nature même de la captation, à savoir cardioïde. Aussi, de nombreux travaux, notamment ceux de J. Daniel [20], ont permis de créer un cadre robuste pour étendre Ambisonics vers une précision supérieure, appelée High order Ambisonics (HOA). Cette extension peut s’introduire de façon théorique en considérant le problème de propagation des ondes dans un espace Ω homogène et isotrope, dénué de sources, en régime harmonique. Sous ces hypothèses, l’équation de Helmholtz formalise mathématiquement ce type de problème et s’écrit comme suit : −(∆ + k 2 )u = 0 avec u ∈ Ω. (1.1) Cette équation peut être résolue en introduisant les harmoniques sphériques (Y m l ), qui sont des fonctions propres de l’opérateur Laplace Beltrami sur la sphère S 2 , associées aux valeurs propres l(l + 1) (e.g. [69], [82] et fig. 1.12). Elles forment une base orthonormée pour le produit scalaire L 2 (S 2 ) et sont définies comme la trace sur la sphère unité S 2 des polynômes homogènes harmoniques de degré l (i.e. à Laplacien nul sur R 3 ). Cette base orthonormée (Y m l ) peut être considérée comme un équivalent pour la sphère dans R 3 de la base (e inθ) pour le cercle dans le plan R 2 . D’un point de vue plus formel, les fonctions de Legendre : P m l (x) = (−1)m(1 − x 2 ) m/2 d m dxm Pl(x) avec m ≥ 0, définies pour tout l dans N, −l ≤ m ≤ l et −1 < x < 1, construisent la famille (Y m l ), définie par : Y m l (θ, φ) = vuut 2l + 1 4π (l − m)! (l + m)!P m l (cos(φ))e imθ . (1.2) En fixant Ω comme l’intérieur ou l’extérieur de la sphère unité S 2 , toute fonction u solution de l’équation de Helmholtz (1.1) peut se décomposer en harmoniques sphériques comme suit : u(k, r, θ, φ) = X l,m α m l (k)Ul(kr)Y m l (θ, φ). (1.3) 18Figure 1.12 – Représentation spatiale des cinq premières harmoniques sphé- rique Y m l , telles que r = |Y m l (θ, φ)|. En pratique, selon les conditions aux limites du problème considéré (Dirichlet, Neumann, Fourier, etc.), la fonction radiale Ul(kr) est construite par des combinaisons linéaires dans C de fonctions de Bessel sphériques, Hankel sphériques et de leurs dérivées. D’un point de vue strictement mathématique, le formalisme HOA est pleinement contenu dans l’équation (1.3) et la propriété d’orthonormalité des harmoniques sphériques pour le produit L 2 (S 2 ) [20]. En effet, la captation puis l’encodage HOA consiste en la création des signaux de projection α m l sur les harmoniques sphériques. Ces signaux peuvent être stockés, échangés et utilisés en l’état pour effectuer des opérations simples, comme des zooms ou des rotations spatiales. Par exemple, le B-Format est l’équivalent du signal α m l pour l ≤ 1. Enfin, s’ensuit l’étape de décodage pour la restitution sur un système de haut-parleurs en calculant cette fois les canaux u correspondants aux signaux α m l . Le protocole suivant, non exhaustif, résume les grandes étapes d’un encodage-décodage HOA dans le cas d’une captation-restitution d’une scène sonore spatialisée. Encodage : 1. Suite à la captation d’une scène sonore par une sphère de microphones, le problème aux limites correspondant est formalisé en domaine de Fou- 19rier pour expliciter les fonctions Ul(kr) sous forme de filtres fréquentiels ; 2. En considérant les valeurs du champ u aux positions des microphones par rapport au centre de la sphère, la série en (1.3) peut alors être tronquée ; 3. En projetant la série (1.3) tronquée sur la base orthonormée des harmoniques sphériques par intégration sur S 2 , un système linéaire est formé ; 4. Puis, ce système est résolu, fréquence par fréquence, pour déterminer les coefficients α m l (k) de la décomposition. Cette étape d’encodage HOA permet de créer les signaux fréquentiels α m l (k), ou encore temporels α m l (t) par transformée de Fourier inverse. Ces derniers définissent un format d’échange évolutif et modulable (rotation, zoom, etc.), indépendant de la sphère de microphones utilisée pour la captation. Le BFormat Ambisonics est la version à l’ordre l = 1 du format HOA et le couple MS en est la version d’ordre l = 1 avec m = 0 uniquement. Décodage : 1. Un nouveau problème aux limites est formalisé pour la diffusion en champ libre par une sphère de haut-parleurs, explicitant notamment un nouveau filtre fréquentiel et une nouvelle matrice de décodage liés aux positions des haut-parleurs dans l’espace centré sur l’auditeur ; 2. Par intégration sur S 2 , un nouveau système linéaire est formé ayant pour inconnues les signaux ui discrets ; 3. Ce système est cette fois inversé, délivrant ainsi le signal à diffuser par les haut-parleurs pour recréer un champ sonore identique à la captation. Une version améliorée de ce protocole a été implémentée durant la thèse dans le moteur PifPaf3D, notamment pour effectuer un rendu binaural d’une captation par microphone Soundfield en A-Format (fig. 1.11). De nombreux dé- tails soulèvent de grandes difficultés, non présentées dans ce manuscrit, mais bien connues de l’homme de l’art. Peuvent être citées en exemple la troncature de la série harmonique dans l’équation (1.3), les phénomènes d’aliasing fréquentiel liés aux diverses discrétisations, la pseudo inversion de la matrice rectangulaire des harmoniques sphériques, ou encore la régularisation des filtres fréquentiels faisant appels aux fonctions de Bessel et Hankel sphé- riques. Néanmoins, le module Matlab d’encodage-décodage HOA a donné des résultats encourageants pour des captations par microphone Soundfield. Il fera sans doute l’objet de recherches ultérieures, par exemple sur le rendu 20de microphones d’ordres plus élevés, ou non sphériques, ou encore pour de la localisation spatiale de sources sonores. Pour conclure, comme toute technique audio, HOA présente des avantages et des inconvénients, à la fois sur les plans perceptif, physique et technique. Ce manuscrit n’ayant pas pour vocation d’en faire une étude détaillée, mais plutôt d’en expliciter les grandes lignes pour comprendre et exploiter l’outil, le lecteur curieux pourra se documenter sur une littérature abondante (e.g. [11], [20], [21], [59], [71]). 1.2.3 Technologies binaurales, enregistrement et synthèse Binaural, binaurale, binauraux (adj. du latin bini/paire et auris/oreille) se dit des perceptions auditives engendrées par une stimulation simultanée des deux oreilles. (Larousse 2013 ) Cette définition introductive a pour but de fixer le vocabulaire employé dans ce manuscrit. En effet, le terme binaural tend à se démocratiser ces dernières années, en devenant un nom commun synonyme d’une écoute spatialisée sur casque audio. En accord avec la définition précédente, il doit en réalité être employé comme adjectif caractérisant une stimulation simultanée des deux oreilles, ce qui induit une certaine prudence d’utilisation 1 ... Ceci étant, les technologies binaurales peuvent être introduites en distinguant deux grandes techniques, ayant comme point commun leur mode de restitution essentiellement sur casque audio, voire sur haut-parleur par Cross-Talk Cancellation. Tout d’abord, l’enregistrement binaural (fig. 1.13) consiste à effectuer une prise de son par l’intermédiaire de deux microphones placés au niveau des tympans d’un être humain, ou d’un objet reprenant tout ou partie des caractéristiques de l’oreille externe (mannequin Gras Kemar, tête artificielle Neumann KU100, oreilles Otokinoko, sphère The Audio BS3D, etc.). Cette technique contient nativement des informations perceptives relatives à la scène sonore originale, ce qui lui confère (en général) un rendu plutôt réaliste, à la fois en direction et en distance. Cependant, elle souffre des contraintes suivantes, liées à la "compression" des informations spatiales dans un signal stéréo : 1. En effet, la quasi-totalité du monde de l’audio est basé sur une stimulation simultanée des deux oreilles... Au même titre, les HRTF sont bien souvent associées au "binaural", alors que tout système de restitution audio exploite de manière directe ou indirecte tout ou partie des informations de localisation contenues dans ces filtres. 21Figure 1.13 – (Gauche) Enregistrement binaural par microphones DPA, situés à l’embouchure du conduit auditif d’un joueur de violoncelle. (Droite) Tête artificielle Neumann KU100, avec microphones intégrés au creux de chaque "oreille". (source www.neumann.com) 1. Les divers objets de la scène sonore forment un tout difficilement dissociable ; 2. Il est difficile de construire manuellement une scène sonore ; 3. Les retouches par égaliseurs, compresseurs, limiteurs, réverbérateurs et autres effets risquent d’altérer fortement la spatialisation, native à la captation ; 4. A posteriori, les filtres HRTF liés à la prise de son ne peuvent pas être individualisés à la morphologie de l’auditeur. Aussi, même si cette approche est connue depuis la fin des années 60, ces difficultés ont sans doute fait obstacle à sa popularisation, à la fois chez les professionnels et les particuliers. La seconde technique, appelée synthèse binaurale (fig. 1.14), réside en l’application d’algorithmes de traitement du signal audio pour recréer artifi- ciellement la perception spatialisée d’une scène sonore. Le principe de base consiste à mesurer par réponse impulsionnelle les filtres HRIR gauches et droits d’un auditeur, pour une position donnée dans l’espace. Puis, après convolution d’une source audio mono par ces deux filtres, le fichier stéréo issu de cette manipulation peut être écouté sur n’importe quel casque audio (de facture honorable !). Dès lors, la source mono sera perçue dans la direction de la position mesurée. En pratique, les HRIR sont mesurées en plusieurs positions de l’espace et une interpolation spatiale de ces filtres est effectuée pour convoluer n’importe quelle source audio dans n’importe quelle 22Figure 1.14 – (Gauche) Principe de base de la synthèse binaurale : x˜(t) correspond au signal mono xA(t), perçu à la position (r, θ, φ) et délivré par les signaux binauraux xL(t) et xR(t). Pour ce faire, xA(t) est convolué par les filtres HRIR gauches h˜ L(t) et droit h˜ R(t) de la position (r, θ, φ), généralement obtenus par interpolation sur une base de données de HRIR. (source Wikipedia) (Droite) Système de mesure de HRTF de l’ARI. (source www.kfs.oeaw.ac.at) 23direction. Sous réserve d’un workflow draconien, la synthèse binaurale peut s’affranchir des contraintes précédentes liées à l’enregistrement binaural, à savoir : 1. Les sources sonores peuvent être des objets dissociés, issus de prises de son séparées ou non ; 2. Une scène sonore se construit manuellement, par positionnement des sources dans l’espace ; 3. Toutes les retouches nécessaires peuvent être faites avant le rendu par synthèse binaurale, préférentiellement effectué en dernier dans la chaîne de production sonore ; 4. Les bases de données HRIR utilisées pour les convolutions peuvent être différentes selon l’utilisateur, voire même individualisées. Ce sont toutes ces possibilités offertes par la synthèse binaurale qui ont motivé l’ensemble de ce travail de recherche appliquée, en particulier le dernier point sur l’individualisation des filtres HRIR/HRTF par des méthodes numériques non intrusives. Aussi, même si cette technique est beaucoup plus difficile à mettre en œuvre, les progrès matériels et logiciels de ces dix dernières années appliqués au traitement du signal offrent aujourd’hui de nouvelles perspectives. Le contexte CIFRE de cette thèse n’est d’ailleurs pas sans rappeler que de nombreux industriels suivent de très (très) près les récentes avancées faites en synthèse binaurale, toujours plus prometteuses. 1.3 Head-Related Transfer Function, what else ? Pour mieux saisir les difficultés liées à l’utilisation des filtres HRTF en synthèse binaurale, une analyse systémique de ces filtres est présentée dans cette section. Cette analyse est effectuée dans la dimension physique des fonctions de transfert, sans se soucier des questions perceptives. La méthodologie est discutable au regard de la psycho-acoustique, mais facilite l’appréhension des résultats de mesures, ainsi que leur couplage avec des résultats issus de modélisations analytiques ou de simulations numériques. Par ailleurs, cette approche rigoureuse a donné naissance à une décomposition fonctionnelle des HRTF en éléments modélisables et résiduels, détaillée dans la section suivante. Aussi, dans toute la suite, les HRTF seront avant tout considérées comme des solutions de radiation sphérique d’un problème de diffraction des ondes sonores par un objet essentiellement rigide, à savoir l’être humain. 24Figure 1.15 – Repère en coordonnées sphériques, convention en rayonlongitude-latitude correspondant respectivement à la distance (ρ), l’azimut (θ) et l’élévation (φ). (source Wikipedia) 1.3.1 Modèle de HRTF, la sphère rigide Avant de s’intéresser aux HRTF réelles issues de mesures en laboratoire, certaines bases méritent d’être posées en étudiant un modèle simplifié, comme les HRTF d’une sphère rigide sans pavillon. Ceci permet notamment d’introduire différents modes de représentations, ainsi que des résultats utiles pour la suite. Pour ce faire, il existe deux principaux modèles associés au problème de diffraction d’une onde sonore par un objet sphérique. Le premier modèle fournit une solution dans le domaine temporel, à savoir une évaluation analytique du retard interaural (ITD) pour une sphère rigide (e.g. [57], [85]). Ce retard correspond à la différence de temps de propagation d’une onde sonore à l’infini entre deux points diamétralement opposés sur la sphère. En considérant que la direction d’une source sonore à l’infini est caractérisée par un angle d’azimut θ et d’élévation φ dans un repère sphérique (fig. 1.15), le retard interaural τ s’exprime par : τ = a c × (arcsin(cos φ sin θ) + cos φ sin θ), (1.4) avec a le rayon de la tête sphérique considérée et c la célérité des ondes sonores dans l’air. La figure (fig. 1.16) donne une représentation du retard τ calculé par le modèle d’ITD (1.4), en fonction de l’azimut θ, pour trois élévations φ significatives. Le rayon de tête choisi pour les calculs correspond au rayon de tête sphérique moyen (a = 8.74 cm [58]) et la vitesse du son dans l’air est 25Figure 1.16 – Représentation de l’ITD τ calculé par le modèle de Larcher (1.4), en fonction de l’azimut θ, pour trois élévations φ significatives. prise à 15˚C (c = 340 m/s). En pratique, ce modèle peut simplement être mis en œuvre en approchant les HRTF comme une combinaison de déformations spectrales en amplitude et d’un retard pur : HRT F(θ, φ) = |HRT F(θ, φ)|e iτ(θ,φ) . Cette décomposition est surtout valable en basse fréquence, lorsque l’approximation de tête sphérique est légitime. Cette technique a été implémentée dès la toute première version du logiciel PifPaf3D, notamment pour faciliter les interpolations de filtres et autoriser une personnalisation de la synthèse binaurale au diamètre de la tête de l’auditeur. Cependant, malgré des résultats perceptifs encourageants, cette approche est trop grossière en haute fréquence pour être raisonnablement suffisante. Le second modèle sphérique a été introduit par Duda [25] et exploite les solutions analytiques du problème de diffraction d’onde par une sphère rigide de rayon a, en régime harmonique de nombre d’onde k. La source sonore est cette fois ponctuelle et localisée dans l’espace. Comme ce problème possède une symétrie de révolution, la position de cette source sera entièrement dé- terminée par sa distance r et son angle d’incidence θ. La fonction de transfert HS issue de cette modélisation est analytique et donnée par : HS(k, a, r, θ) = − r ka2 e −ikr X∞ m=0 (2m + 1)Pm(cos θ) hm(kr) h 0 m(ka) , r > a, (1.5) où Pm est le polynôme de Legendre de degré m et hm la fonction de Hankel sphérique de degré m. De plus, Duda propose un algorithme récursif pour évaluer les fonctions de Hankel et leurs dérivées, ce qui permet un calcul rapide et facilite l’étude. Les deux premières représentations graphiques 26Figure 1.17 – Représentations des HRTF du modèle sphérique de Duda, dans le plan azimutal. (Haut) Amplitude spectrale. (Milieu) Portrait de phase. (Bas) Amplitude signal HRIR. 27de la figure 1.17 montrent l’amplitude spectrale et le portrait de phase des HRTF sphériques de Duda, évalués à partir de l’équation (1.5). Dans le repère sphérique de la figure 1.15, ces deux grandeurs sont données pour "l’oreille gauche", située en (0, a, 0). La discrétisation angulaire du plan d’incidence (azimutal) est de l’ordre du degré et la discrétisation fréquentielle compte 129 échantillons répartis régulièrement entre 0 et 24 kHz. Les valeurs d’amplitude spectrale sont données en dB sur un intervalle audible fixe ([−60, 0] dB) et la phase est exprimée en radian ([−π, π] rad). Sur la figure 1.17, les amplitudes spectrales des sources ipsilatérales sont relativement monotones, alors qu’apparaissent des interférences constructives et destructives pour les sources contralatérales. De plus, pour les sources diamétralement opposées au point de mesure sur la sphère (θ = 270˚), les interférences constructives amènent un gain jusque 20 dB supérieur aux sources juxtaposées. Enfin, le portrait de phase est relativement uniforme, avec des isovaleurs caractéristiques d’un problème à géométrie sphérique, excepté pour ces mêmes sources diamétralement opposées, qui présentent un saut de phase. La dernière repré- sentation graphique de la figure 1.17 montre la transformée de Fourier inverse des HRTF sphériques, soit les HRIR du modèle sphérique de Duda dans le plan d’incidence. La discrétisation temporelle compte 256 échantillons sur un intervalle de l’ordre de quelques millisecondes. Les valeurs d’amplitude du signal sont données en dB sur un intervalle audible fixe ([−60, 0] dB). Le modèle d’ITD de Larcher (1.4) en élévation nulle (fig. 1.16) est clairement visible sur la représentation temporelle des HRIR sphériques. Il est néanmoins intéressant de noter un lissage pour l’azimut θ = 90˚, correspondant à une source ipsilatérale. Ceci peut s’expliquer par l’approximation d’onde incidente à l’infini dans le modèle de Larcher, qui diffère de l’approximation en sources ponctuelles dans le modèle de Duda. Par ailleurs, un second front d’ondes d’amplitude non négligeable apparaît pour les sources contralaté- rales, retardé par rapport au front d’onde caractérisant l’ITD. Ce résidu est généré par les ondes contournant la sphère par le chemin diamétralement opposé au plus court trajet, dans le plan d’incidence. La figure 1.17 donne une première forme de représentation graphique des HRTF sphériques, à la fois en fréquence, en temps et en espace. Cependant, autant où les représentations strictement azimutales s’avèrent consistantes pour les HRTF sphériques, autant où elles sont incomplètes pour les HRTF réelles. En effet, ces dernières sont des données directionnelles n’ayant a priori pas de symétries particulières. Or, l’ajout d’une dimension pour l’élévation complique grandement l’analyse, qui nécessite des supports clairs et intuitifs pour être rigoureuse et efficace. Aussi, en fixant la fréquence, une représentation aplatie en azimut θ et élévation φ de l’amplitude spectrale (fig. 1.18) et du portrait de phase (fig. 1.19), est un bon complément des représentations 28Figure 1.18 – Amplitude spectrale (dB) des HRTF gauches du modèle sphérique de Duda (eq. 1.5). Représentation en azimut θ et élévation φ, à fréquence fixe f. 29Figure 1.19 – Portrait de phase (radian) des HRTF gauches du modèle sphérique de Duda (eq. 1.5). Représentation en azimut θ et élévation φ, à fréquence fixe f. 30Figure 1.20 – Répartition spatiale des positions de mesures pour la base de données ARI. (source [6]) exclusivement fréquence-azimut précédentes. Sur ces figures, les discrétisations en azimut θ et élévation φ pour le modèle analytique de Duda sont de l’ordre du degré dans chaque dimension. Cette nouvelle représentation offre l’avantage d’afficher toutes les données spatiales sans idées reçues et de mesurer pleinement la nature ondulatoire des HRTF. En effet, l’amplitude spectrale et la phase des HRTF sphériques de Duda (fig. 1.18 et 1.19) ne sont pas sans rappeler les figures d’interférences classiques des problèmes de diffraction d’onde. Enfin, la symétrie axiale d’axe de rotation interaural Oy est parfaitement visible. Tous les outils de représentation graphique étant désormais établis avec un modèle analytique, le problème réel des HRTF mesurées peut maintenant être abordé. 1.3.2 Mesures de HRTF, Acoustics Research Institute La base de données récemment mesurée à l’Acoustics Research Institute de l’Austrian Academy of Science a été utilisée dans cette section à des fins de recherche, sous licence Creative Commons (cc). Ces mesures présentent l’avantage de compter 1550 positions, quasi-uniformément espacées sur plus d’une demi-sphère (fig. 1.20), avec un écart angulaire de 2.5˚ frontalement et de 5˚ sinon. Au vu des schémas de diffraction précédents pour le modèle sphérique analytique (fig. 1.18 et 1.19), ce faible écart angulaire semble 31indispensable pour représenter le plus fidèlement possible les variations en hautes fréquences. Pour réaliser ces mesures, le dispositif expérimental mis en place consiste en une batterie de haut-parleurs disposés en arc de cercle autour d’une chaise rotative où s’assoit le sujet, dans une chambre semianechoïque (fig. 1.14). Les HRIR sont mesurées par sweep multiples [64] de 50 Hz à 20 kHz, puis post-traitées par filtrage inverse en minimum de phase de l’amplitude spectrale de la Common Transfer Function (CTF), afin de compenser l’impact de l’équipement sur la mesure. Pour finir, elles ont été filtrées par coupe-haut à 18 kHz (ce qui rend les données non valables au-delà de cette limite), puis fenêtrées en temps sur 256 échantillons (Tukey asymé- trique). Pour plus d’informations sur le protocole expérimental, un extrait est disponible sur le site de l’ARI [6]. Enfin, il n’est pas inutile de préciser que cette base de données est disponible au format Matlab, ce qui en facilite grandement l’usage. La figure 1.21 donne les représentations de l’amplitude spectrale, de la phase et de l’amplitude signal des HRTF du sujet NH5 de la base ARI, en azimut-fréquence. La discrétisation azimutale θ est semi-régulière, avec un pas de 2.5˚ autour de θ = 0˚ et un pas de 5˚ sinon. Les valeurs d’amplitude spectrale ont été normalisées et sont données en dB sur l’intervalle audible fixe [−60, 0] dB, pour faciliter les comparaisons avec le modèle sphérique de Duda (fig. 1.17). La discrétisation fréquentielle compte 129 échantillons répartis régulièrement entre 0 et 24 kHz et l’équivalent temporel présente 256 échantillons sur un intervalle de l’ordre de quelques millisecondes. D’une part, sur la représentation temporelle, le modèle d’ITD de Larcher (fig. 1.16) est parfaitement visible, avec le même décrochement à θ = 90˚ que pour la modélisation analytique de Duda (fig. 1.17). De plus, un certain nombre de réflexions supplémentaires, engendrées par le pavillon de l’oreille, mais aussi les épaules et le torse, se dessinent en suivant les mêmes courbes d’ITD. Ces réflexions sont à l’origine des importantes déformations spectrales en amplitude et en phase, caractéristiques des HRTF. D’autre part, certaines remarques peuvent se dégager de l’analyse comparative des représentations fréquentielles des HRTF modélisées (fig. 1.17) et mesurées (fig. 1.21) : – Les HRTF des sources contralatérales (θ proche de 270˚) sont beaucoup plus complexes que celles ipsilatérales (θ proche de 90˚) ; – L’amplitude spectrale des HRTF mesurées est relativement lisse, dans le sens où ses variations présentent peu de sauts critiques, excepté en faible amplitude ; – Le portrait de phase présente quant à lui de fortes variations et de nombreux sauts ; – Le modèle de Duda est visible sur l’amplitude spectrale, notamment en basse fréquence pour l’oreille contralatérale et se retrouve aussi sur 32Figure 1.21 – Représentations des HRTF du sujet NH5 de la base de données ARI, dans le plan azimutal. (Haut) Amplitude spectrale, avec filtrage coupehaut d’origine. (Milieu) Portrait de phase. (Bas) Amplitude signal HRIR. 33toute la bande fréquentielle du portrait de phase. Ce dernier point, parfaitement empirique, est fondamental puisqu’il a donné naissance au principe de Décomposition par Modèle Morphologique des HRTF, présenté dans la suite de ce manuscrit. En complément des représentations azimutales précédentes, les figures 1.22 et 1.23 donnent les représentations en azimut-élévation à fréquence fixe des HRTF mesurées du sujet NH5 de la base ARI. La discrétisation spatiale de cette base oscillant entre 2.5˚ et 5˚, ces figures présentent une discrétisation tous les degrés d’espace en considérant la valeur du plus proche voisin mesuré, ce qui correspond aux diagrammes de Voronoï. Ceci permet d’afficher les résultats de mesures bruts, sans interpolations graphiques éventuellement préjudiciables à l’analyse des données. Les positions spatiales des données mesurées sont représentées par des points noirs. Les propriétés précédemment observées se retrouvent dans la représentation spatiale des HRTF. En effet, l’amplitude spectrale (fig. 1.22) est relativement lisse, y compris en haute fréquence. Certains décrochements sont néanmoins visibles pour les sources contralatérales (en bleu foncé). Mais ces valeurs sont relativisées par leur faible amplitude en échelle logarithmique. Cette représentation laisse penser que la discrétisation spatiale de la base ARI semble surdéterminée, au regard des faibles variations entre chaque point de mesure. Une interpolation, linéaire ou d’ordre supérieur, pourrait donc être envisagée. En revanche, le portrait de phase est quant à lui bien plus oscillant (fig. 1.23). La discrétisation spatiale est suffisante pour une représentation à 0.5 kHz, mais commence à pêcher pour les sources contralatérales à 8 kHz et devient manifestement insuffisante pour ces mêmes positions à 16 kHz. Une interpolation de ces données en l’état est donc relativement difficile à haute fréquence, mais reste envisageable (cf. section suivante). Il est néanmoins intéressant de remarquer une certaine symétrie axiale par rotation autour de l’axe interaural, qui n’est pas sans rappeler le portrait de phase sphérique du modèle de Duda (fig. 1.19). Toutes les représentations brutes des HRTF et des HRIR équivalentes étant établies, celles-ci vont désormais servir de référence dans toute la suite de ce chapitre. 1.3.3 Interpolation linéaire Les représentations précédentes des diagrammes de Voronoï en azimut- élévation (fig. 1.22 et 1.23) amènent naturellement la question de l’interpolation spatiale des filtres HRTF, à savoir : Comment construire des données pertinentes entre les positions discrètes des mesures ? 34Figure 1.22 – Amplitude spectrale (dB) des HRTF gauches du sujet NH5 de la base de données ARI. Représentation en azimut θ et élévation φ, à fréquence fixe. Les positions des mesures sont données par les points noirs. 35Figure 1.23 – Portrait de phase (radian) des HRTF gauches du sujet NH5 de la base de données ARI. Représentation en azimut θ et élévation φ, à fréquence fixe. Les positions des mesures sont données par les points noirs. 36Cette question est fondamentale pour la compréhension de ces fonctions de transfert, ainsi que pour leur exploitation industrielle (e.g. [17], [45], [57]). Par exemple, une interpolation spatiale de haute qualité permet notamment : – Un rendu dynamique de la spatialisation sonore en minimisant les artefacts audibles ; – L’ajout d’un head-tracking transparent ; – Une minimisation de la densité spatiale des mesures, ce qui diminue leur durée, simplifie les appareillages nécessaires et décroit la taille des bases de données de façon quadratique. Pour ce faire, une interpolation linéaire par triangularisation sphérique de la sphère de mesures a été préférentiellement choisie. Tant que la discrétisation des fonctions à interpoler est suffisante pour appliquer une hypothèse de linéarité locale, ce type d’interpolation est un bon compromis entre précision et coûts de calcul. L’algorithme exploité pour produire les représentations ci-après peut se résumer comme suit : 1. Considérer le nuage de points de mesures en coordonnées sphériques ; 2. Subdiviser la surface sphérique en triangles plans, ayant pour sommets les points des mesures ; 3. Construire une grille régulière plus fine, par exemple, tous les degrés en azimut θ et élévation φ ; 4. Interpoler linéairement triangle par triangle les données aux nœuds sur cette nouvelle grille. Au vu des variations des HRTF brutes (fig. 1.22 et 1.23), le module et la phase des HRTF ont été traités séparément. Les figures (fig. 1.24 et 1.25) représentent respectivement en azimut-élévation les interpolations linéaires de l’amplitude spectrale et de la phase des HRTF mesurées du sujet NH5 de la base ARI. L’interpolation linéaire de l’amplitude spectrale (fig. 1.24) donne d’excellents résultats puisque, comparativement aux mesures originales (fig. 1.22), les variations semblent entièrement décrites avec la discrétisation spatiale de la base ARI et ce, quelle que soit la fréquence. Autour de l’oreille contralatérale, seuls quelques "trous" de faible amplitude mériteraient une étude plus approfondie, mais leur importance est moindre au regard de la faible amplitude de la zone avoisinante. D’autre part, à 8 kHz, des stries horizontales apparaissent pour l’oreille ipsilatérale et semblent fonctions de l’élévation. Selon le protocole expérimental, à savoir une rangée de hautparleurs distincts en élévation, il est possible que l’égalisation du dispositif impacte la mesure. Cette problématique limite les mesures d’erreurs possibles et peut justifier qu’une interprétation purement graphique des résultats soit suffisante en première approche. En revanche, l’interpolation linéaire de la 37Figure 1.24 – Interpolation linéaire de l’amplitude spectrale (dB) des HRTF gauches du sujet NH5 de la base de données ARI. Représentation en azimut θ et élévation φ, à fréquence f fixe. Les positions des mesures sont données par les points noirs. 38Figure 1.25 – Interpolation linéaire du portrait de phase (radian) des HRTF gauches du sujet NH5 de la base de données ARI. Représentation en azimut θ et élévation φ, à fréquence f fixe. Les positions des mesures sont données par les points noirs. 39phase (fig. 1.25), peut quant à elle être considérée comme un échec. En effet, même si le portrait de phase original (fig. 1.25) est relativement consistant pour les fréquences 1 kHz, voire 8 kHz, la discrétisation spatiale de la base ARI est clairement insuffisante pour ce type d’interpolation à 15 kHz. En effet, étant donné que les données spatiales brutes présentent de nombreux sauts de π vers −π, une interpolation linéaire entre ces sauts génère des artefacts visibles et audibles. À titre comparatif, le portrait de phase théorique des HRTF sphériques de Duda (fig. 1.19) peut être mis en regard du portrait de phase interpolé (fig. 1.25). Comme les oscillations observées résultent en grande partie de la repré- sentation modulo 2π, une approche classique consiste à "dérouler" la phase pour retirer les sauts de π vers −π, obtenant ainsi une phase continue sur un intervalle élargi [10]. Mais, comme le montrent les mesures brutes (fig. 1.23), la question de la direction du déroulement est loin d’être triviale. En effet, celui-ci doit respecter la causalité, qui est difficile à évaluer directement pour des fonctions de transfert définies sur deux dimensions d’espace (azimut et élévation). Des travaux de recherches ont précédemment été entrepris pour tenter de résoudre cette problématique, donnant lieu à des méthodes comme : – Soustraire la portion de phase linéaire liée au retard de propagation ; – Soustraire la portion de phase minimale déduite du spectre d’amplitude et représenter l’excès de phase déroulé ("unwrapped"). La seconde approche est considérée notamment dans la thèse de Véronique Larcher et propose de mesurer le retard de propagation par une approximation linéaire de l’excès de phase (e.g. [57]). Une autre méthode, utilisée ici, consiste à interpoler directement les HRTF dans le domaine complexe, en séparant la partie imaginaire et la partie réelle. Étant donné que la transformée de Fourier et la méthode d’interpolation sont toutes deux linéaires, cela revient à effectuer une interpolation linéaire en domaine temporel, soit directement sur les HRIR [45]. L’amplitude spectrale (dB) et la phase (rad) peuvent alors être extraites du résultat et représentées en azimut-élévation à fréquence fixe. Suivant cette technique, le portrait de phase (fig. 1.27) semble cette fois plus cohérent que précédemment (fig. 1.25), notamment à 1 kHz, voire 8 kHz. Cependant, les variations à 16 kHz étant toujours trop fortes pour être interpolées correctement, de nouveaux artefacts apparaissent, comme des phases spatialement constantes (visibles aussi à 8 kHz pour les sources contralatérales). D’autre part, l’amplitude spectrale de cette méthode (fig. 1.27) est quant à elle plutôt médiocre à 8 kHz et 16 kHz, car un aliasing spectral perturbe la reconstruction. Même si la répartition générale est respectée (fig. 1.22), ces oscillations locales de l’amplitude spectrale sont du domaine de l’audible. Ceci modifie de manière conséquente le timbre de la source sonore restituée et peut affecter la localisation spa- 40Figure 1.26 – Amplitude spectrale (dB) de l’interpolation linéaire complexe des HRTF gauches du sujet NH5 de la base de données ARI (équivalent de l’interpolation des HRIR). Représentation en azimut θ et élévation φ, à fréquence fixe. 41Figure 1.27 – Phase (radian) de l’interpolation linéaire complexe des HRTF gauches du sujet NH5 de la base de données ARI (équivalent de l’interpolation des HRIR). Représentation en azimut θ et élévation φ, à fréquence fixe. 42tiale. Cet aliasing est majoritairement dû à la sous-discrétisation spatiale de la phase, qui vient perturber l’interpolation linéaire en domaine temporel. En effet, l’interpolation linéaire des HRTF fait appel à des combinaisons de filtres, qui peuvent générer des erreurs lorsque les interpolants présentent une trop grande variabilité, ou un mauvais alignement temporel. À partir de ces résultats, une première intuition pour interpoler les HRTF serait de combiner une interpolation linéaire de l’amplitude spectrale (fig. 1.24) avec la phase d’une interpolation temporelle (fig. 1.27). Mais cette phase étant reliée à une amplitude spectrale avec fort aliasing (fig. 1.26), rien ne garantit la validité du résultat. Une nouvelle méthode, dite de "Décomposition par Modèle Morphologique", a été mise au point pour répondre à cette problématique. 1.3.4 Interpolation par harmoniques sphériques En complément de l’interpolation linéaire précédente, un autre type d’interpolation a été étudié, issu des travaux de R. Duraiswami et N. Gumerov (e.g. [27], [28], [53]). Le principe général de la méthode consiste à projeter sur les harmoniques sphériques Y m l (eq. 1.2, fig. 1.12) des fonctions u défi- nies sur la sphère S 2 , afin de les interpoler en n’importe quel point. Comme les harmoniques sphériques forment une base orthonormée de L 2 (S 2 ), toute fonction u ∈ L 2 (S 2 ) peut se décomposer selon la série (1.3), indépendamment de r : u(θ, φ) = X∞ l=0 X +l m=−l α m l Y m l (θ, φ), (1.6) avec α m l les coefficients de cette décomposition. Cette écriture autorise la formation de systèmes matriciels, qui peuvent être résolus ou inversés selon le changement de base souhaité. Pour ce faire, la série précédente doit être tronquée à une valeur fixe l ≤ L, ce qui donne (L + 1)2 termes. Puis, en considérant N données discrètes ui évaluées aux points (θi , φi) sur la sphère S 2 , la série (1.6) peut être réécrite sous la forme matricielle : U = Aα, (1.7) avec A une matrice rectangulaire formée par les harmoniques sphériques tronquées, évaluées aux points de mesures (θi , φi). Cette matrice peut être mal conditionnée, notamment par une répartition parfois incomplète des N mesures sur la sphère. Aussi, lorsque les coefficients α m l sont obtenus par inversion du système linéaire (1.7), une régularisation de type Tikhonov peut-être mise en place [27] : A TU = (A TA + D)α. (1.8) 43Dans l’équation (1.8), D = diag(1 + l(l + 1)) est une matrice diagonale favorisant les harmoniques sphériques d’ordre peu élevé, pour minimiser les perturbations générées par des "trous" spatiaux présents dans les données originales. D’autre part,  est introduit comme constante de pondération de cette régularisation. Après de nombreux essais, un algorithme empirique, relativement simpliste, a été conçu pour calculer automatiquement . En effet, les grandes valeurs de  favorisent le lissage, dont l’excès engendre une perte de précision importante dans les informations spatiales. Par ailleurs, les petites valeurs de  peuvent rendre la régularisation parfaitement inopérante. Par conséquent, ce paramètre doit être judicieusement choisi pour obtenir de bons résultats, notamment selon le conditionnement du système à résoudre (M = ATA + D). Pour cela, un estimateur normalisé du conditionnement est calculé par le produit ||M||2 × ||M−1 ||2, avec une donnée initiale 0 fixée à 10−6 . Tant que la valeur de l’estimateur est plus grande que 104 , ce qui correspond traditionnellement à un système mal conditionné,  est multiplié par 10 et l’estimateur est recalculé. Cette régularisation semble relativement efficace pour pallier les nombreuses erreurs numériques engendrées par les troncatures, ou les répartitions de données incomplètes. Pour résumer, une interpolation par harmoniques sphériques d’une fonction u ∈ L 2 (S 2 ) peut être effectuée par l’algorithme suivant : 1. Considérer N valeurs connues de la fonction u sur la sphère, pour former le vecteur second membre U de l’équation régularisée (1.8) ; 2. Tronquer la série (1.6) à un ordre L en fonction de la précision de l’interpolation voulue, pour construire la matrice A aux N positions connues de la fonction u ; 3. Appliquer la régularisation de Tikhonov, ce qui permet a priori de prendre L relativement quelconque ; 4. Résoudre l’équation (1.8) par inversion matricielle pour calculer le vecteur α des coefficients de décomposition α m l ; 5. Construire une nouvelle matrice B d’harmoniques sphériques, évaluées aux M positions (θ, φ) à interpoler ; 6. Calculer le produit matrice-vecteur Bα pour obtenir le vecteur des valeurs de la fonction u aux positions interpolées. Cet algorithme, parfaitement générique, peut être appliqué à toute fonction u ∈ L 2 (S 2 ), à valeurs dans R ou C. Or, en décomposant les HRTF fréquence par fréquence, les données ré- sultantes sont typiquement des fonctions de L 2 (S 2 ) à valeurs dans C. Par ailleurs, leurs module, phase et transformée de Fourier (HRIR) sont aussi des 44fonctions de L 2 (S 2 ), à valeurs dans R. L’interpolation par harmoniques sphé- riques peut donc être appliquée à tous ces objets, pour estimer des données spatiales non mesurées. Ce type d’interpolation présente l’avantage d’être global, contrairement à l’interpolation linéaire qui est un algorithme local. De plus, la régularisation de Tikhonov induit un certain lissage, qui peut avantageusement compenser les erreurs ponctuelles inhérentes aux mesures. Enfin, les coefficients α m l ne sont rien d’autres que les signaux utilisés par les technologies HOA présentées dans la section précédente. Aussi, cet algorithme peut-être utilisé pour assurer la conversion des mesures discrètes aux signaux ambisonics. Néanmoins, la répartition non uniforme des données issues de systèmes de mesures mécaniques peut générer des erreurs difficilement maîtrisables, notamment à haute fréquence pour des bases de HRTF non suffisamment denses. Pour limiter le nombre de figures, cet algorithme a uniquement été appliqué à l’amplitude spectrale des HRTF du sujet NH5 de la base ARI (fig. 1.28 et 1.29). Ces données sont donc à valeurs dans R, avec N = 1550 mesures sur une calotte sphérique d’élévation comprise entre −30˚< φ < 80˚ (points noirs). Dans un premier temps, la troncature a été arbitrairement fixée à L = b √ Nc = 39 (fig. 1.28) et la constante de régularisation calculée vaut  = 1, significative d’un système assez mal conditionné. Au vu des données manquantes pour compléter la sphère, cette valeur n’est pas vraiment surprenante. La comparaison de ces résultats aux mesures brutes (fig. 1.22), ainsi qu’à l’interpolation linéaire (fig. 1.24), semble montrer que ce type d’algorithme est bien adapté à l’interpolation de ces HRTF, et ce, quelque soit la fréquence. Ceci est principalement dû à la grande densité spatiale des mesures originales, autorisant un ordre élevé d’harmoniques sphériques. Cette approche avec L grand conduit à une interpolation fidèle des données, qui ressemble finalement beaucoup à une interpolation linéaire (fig. 1.24). En effet, un des intérêts de cet algorithme réside dans sa considération globale de l’information spatiale, ce qui est assez peu visible sur la figure (fig. 1.28) tant l’ordre de troncature est élevé. Aussi, un ordre de troncature arbitraire a été fixé à L = 15, tout en conservant les autres paramètres à l’identique. Le coefficient  calculé vaut cette fois 0.1, la matrice étant mieux conditionnée. Un système extrêmement surdéterminé est donc résolu, engendrant un moyennage spatial de l’ensemble des données disponibles. Les résultats de cette approximation sont représentés sur la figure 1.29. Quelle que soit la fréquence, un lissage est clairement visible, tout en conservant les principales variations des HRTF originales (fig. 1.22). Ceci a pour conséquence d’égaliser sphériquement les mesures entre elles, pour en dégager l’essentiel. En faisant l’hypothèse (raisonnable) que le système auditif est limité en précision, donc en ordre de troncature d’harmoniques sphériques, cette méthode permet de 45Figure 1.28 – Interpolation par harmoniques sphériques (L = 39) de l’Amplitude spectrale (dB) des HRTF gauches du sujet NH5 de la base de données ARI. Représentation en azimut θ et élévation φ, à fréquence fixe. 46Figure 1.29 – Interpolation par harmoniques sphériques (L = 15) de l’Amplitude spectrale (dB) des HRTF gauches du sujet NH5 de la base de donnée ARI. Représentation en azimut θ et élévation φ, à fréquence fixe. 47générer des bases de données HRTF particulièrement adaptées à la synthèse binaurale. Il reste néanmoins à trouver par des tests subjectifs l’ordre de troncature optimal minimisant les erreurs de localisation. Que ce soit pour la conversion des HRTF en format HOA, pour l’égalisation sphérique de l’information, ou encore pour l’interpolation globale et automatique des mesures, une attention particulière a été portée à cette méthode durant cette recherche doctorale. Ces études ont conduit à la publication de deux articles de conférence [8] et [9]. Le premier de ces articles concerne l’interpolation harmonique de l’ITD, qui est une fonction de L 2 (S 2 ) dans R. Le second propose une analyse approfondie de la précision de cet algorithme, en mesurant l’erreur d’une interpolation des HRTF sur une grille de mesure dense déraffinée. 1.4 Décomposition par Modèle Morphologique La Décomposition par Modèle Morphologique est issue du constat classique que les modèles sphériques de Larcher [57] et Duda [25] (fig. 1.16 et 1.17) se retrouvent nettement dans les représentations temporelles des HRIR mesurées (fig. 1.21). Aussi, de nombreuses recherches ont été faites et sont actuellement en cours, pour affiner ces modélisations en construisant analytiquement et/ou numériquement des HRTF s’approchant de mesures réelles, en phase comme en amplitude spectrale (e.g. [4], [26], [37], [52], [72], [81]). Toutes ces méthodes ont comme point commun de s’inscrire dans une logique de "construction" de modèles de HRTF, se voulant de plus en plus proches de mesures expérimentales. La simulation numérique par Boundary Element Method accélérés en Fast Multipole sur des maillages de tête individuels haute-résolution en est un aboutissement des plus complexes (e.g. [30], [39], [56]). La Décomposition par Modèle Morphologique suit une démarche inverse, qui consiste cette fois à "retirer" des mesures originales les solutions exactes ou approchées issues de modélisations élémentaires. Les HRTF deviennent dès lors le résultat d’un couplage astucieux entre modèle(s) et mesures, ayant vocation à exploiter les avantages de chacun. Cette distinction de cheminement est le point fondamental de cette nouvelle approche, dont le formalisme, ainsi que trois applications, sont détaillés dans la suite de ce chapitre. 1.4.1 Principe et résultats La Décomposition par Modèle Morphologique s’effectue en trois étapes, dans un contexte de traitement du signal en régime harmonique. Tout d’abord, 48des fonctions de transfert HRTF originales H(Xi), mesurées en N points de l’espace Xi = (ri , θi , φi), sont décomposées en une série de filtres élémentaires paramétriques Hm(p m, Xi). Ces filtres sont des solutions analytiques ou numériques de modèle m, paramétrées par un jeu de données p m en lien avec la morphologie. La fonction de transfert résiduelle issue de cette décomposition sera notée Hr (Xi) et est, a priori, parfaitement inconnue. La Décomposition par Modèle Morphologique s’écrit alors : H(Xi) = H r (Xi) · Y m H m(p m, Xi), ∀i ∈ [1, N]. (1.9) Cette décomposition est équivalente a une décomposition additive de l’amplitude en dB et de la phase en radians. La seconde étape consiste en la réécriture de cette décomposition (1.9) par filtrage inverse, afin d’en expliciter le résidu : H r (Xi) = H(Xi) Q m Hm(pm, Xi) , ∀i ∈ [1, N]. (1.10) Ce filtre résiduel Hr (Xi) peut alors être étudié pour valider, invalider, ou affiner la décomposition. En effet, le résidu est directement équivalent a des erreurs de modélisation, calculées par soustraction. Par exemple, dans le cas idéal où le modèle coïnciderait exactement avec les données mesurées, le résidu serait uniformément nul pour l’amplitude spectrale et la phase, et égal en temps à une impulsion de Dirac. En pratique, si le module ou la phase du résidu présente une plus grande régularité (des variations plus petites) que la fonction de transfert originale H(Xi), alors la décomposition peut être jugée satisfaisante. Dans le cas contraire, il faudra retravailler la modélisation d’un ou plusieurs éléments, séparément ou non. Enfin, la dernière étape réside en la recomposition des HRTF, en exploitant notamment les solutions issues des modèles et connues en tous points de l’espace. Des propriétés propres aux modèles, ainsi que les paramètres p m peuvent aussi être exploités pendant cette étape, en fonction du but recherché. À titre d’exemple d’utilisation de cette méthode, trois applications sont détaillées dans la suite de cette section, à savoir l’interpolation optimisée des HRTF, la sous-discrétisation spatiale et l’individualisation. Pour ce faire, la Décomposition par Modèle Morphologique (1.9) a été appliquée au modèle sphérique de Duda [25], dont la fonction de transfert (1.5) sera notée Hsp(a, Xi). Ce choix est guidé par un confort d’utilisation, puisque ce modèle est un modèle analytique abouti, aisément calculable. Les solutions sont donc connues en tous points de l’espace, avec en outre un rayon de tête paramétrique a. Cette décomposition s’écrit alors : H(Xi) = H r (Xi) · H sp(a, Xi). (1.11) 49Figure 1.30 – Représentations fréquentielles et temporelle dans le plan azimutal du résidu Hr de la décomposition sphérique des HRTF gauches du sujet NH5 de la base ARI. (Haut) Amplitude spectrale. (Milieu) Portrait de phase. (Bas) Amplitude signal HRIR.50La figure 1.30 donne les représentations azimut-fréquence de l’amplitude spectrale et de la phase du résidu Hr (Xi), aux points de mesures Xi . Ces valeurs sont calculées par filtrage inverse de Hsp(a, Xi) (eq. 1.10), avec un rayon de tête sphérique a = 8.74 cm, correspondant au rayon de tête moyen [58]. Il en ressort de prime abord que le portrait de phase de ce résidu est beaucoup plus droit que celui des HRTF originales (fig. 1.21) et présente, dans l’ensemble, moins de variations, en fréquence comme en azimut. Cependant, les sources contralatérales ont toujours des irrégularités locales assez fortes. Une des conséquences de ce résultat réside dans l’alignement temporel des HRIR résiduelles, clairement visible sur la représentation en temps azimut-fréquence du résidu (fig. 1.30). Par ailleurs, en comparaison avec les HRTF originales (fig. 1.21), l’amplitude spectrale du résidu semble avoir été globalement égalisée, notamment certains creux en amplitude de l’oreille contralatérale. En revanche, des stries apparaissent, similaires au portrait d’amplitude des HRTF sphériques (fig. 1.17). Ces stries sont la conséquence d’une modélisation trop grossière, ou mal adaptée, qui vient surcompenser les HRTF originales. Ceci montre les limitations d’un modèle de HRTF sphé- rique, notamment pour l’oreille contralatérale. Il faudrait donc l’affiner, en conservant certaines propriétés visiblement bénéfiques pour la phase. Les figures 1.31 et 1.32 viennent compléter les représentations azimutales précédentes, en donnant l’amplitude spectrale (dB) et le portrait de phase (radian) en azimut-élévation du résidu Hr de la décomposition sphérique de rayon a = 8.74 cm, pour les HRTF gauches du sujet NH5 (base ARI). Au même titre que pour les représentations azimut-fréquence (fig. 1.30), l’amplitude spectrale et la phase sont globalement lissées et ce, quelle que soit la fréquence. D’une part, le portrait de phase présente particulièrement peu de variations, comparé à l’original avant décomposition (fig. 1.23), d’autre part l’amplitude spectrale semble avoir été partiellement "rebouchée", notamment dans la zone contralatérale. Cependant, cette même zone présente encore des irrégularités importantes, en amplitude et en phase. De plus, des sauts de phase verticaux sont à noter en haute fréquence, caractérisés par des stries horizontales à 8 et 16 kHz (fig. 1.32). Celles-ci peuvent être causées par le dispositif expérimental, qui compte un haut-parleur différent par élévation et dont les variations résiduelles sont faibles au regard de la fréquence élevée. Pour conclure, il semblerait que la décomposition de HRTF par un modèle sphérique de Duda soit plutôt pertinente, surtout pour la phase. L’analyse du résidu Hr montre une bonne concordance du modèle, surtout en basse fréquence. De plus, même si par construction Hr n’a pas de sens physique véritable, les résultats de la décomposition précédente donnent l’impression que ce résidu pourrait caractériser des HRTF "privées" d’une tête sphérique. Mais cette hypothèse reste encore à démontrer... En revanche, cette modé- 51Figure 1.31 – Amplitude spectrale (dB) du résidu Hr de la décomposition sphérique des HRTF gauches du sujet NH5 de la base ARI. Représentation en azimut θ et élévation φ, à fréquence fixe. Les positions des mesures sont données par les points noirs. 52Figure 1.32 – Portrait de phase (rad) du résidu Hr de la décomposition sphérique des HRTF gauches du sujet NH5 de la base ARI. Représentation en azimut θ et élévation φ, à fréquence fixe. Les positions des mesures sont données par les points noirs. 53lisation montre des limites importantes pour les sources contralatérales qui semblent assez mal prises en compte, surtout en haute fréquence. Ceci peut s’expliquer par la sphéricité du modèle qui tend à exagérer la reconstruction des ondes contralatérales par des oreilles diamétralement opposées, induisant une mise en phase contraire à la réalité. Une première amélioration de cette décomposition consisterait par exemple en une modélisation ovoïdale de la tête, avec des oreilles non diamétralement opposées [26]. Mais il n’existe pas de solutions analytiques simples à ce problème, qui nécessite dès lors des outils de simulation numérique. Aussi, malgré ce défaut, trois applications de la décomposition sphérique sont présentées. 1.4.2 Interpolation optimisée Comme expliqué précedemment, la question de l’interpolation des HRTF n’est pas triviale de par la grande variabilité de ces filtres, en temps comme en espace [45]. Une première application de la Décomposition par Modèle Morphologique consiste à optimiser l’interpolation spatiale en tenant compte de solutions modélisées, connues en tous points de l’espace. Plus exactement, les figures 1.31 et 1.32 montrent que le résidu Hr (Xi), issu du filtrage inverse d’une HRTF mesurée H(Xi) par sa décomposition sphérique Hsp(a, Xi), est plus régulier que la fonction de transfert originale (fig. 1.22 et 1.23), notamment en phase. En complément, la représentation temporelle de ce résidu (fig. 1.30) montre un alignement azimutal des filtres. Fort de ces deux constats, une idée naturelle consiste à interpoler linéairement en espace le résidu Hr (Xi) sous sa forme temporelle, ce qui revient par transformée de Fourier à une interpolation du résidu sous sa forme complexe. Ceci fait, des HRTF peuvent être recomposées, calculées avec les valeurs des HRTF sphériques de Duda aux points interpolés. Une grille quelconque peut alors être générée, en tout point de l’espace. Par ailleurs, si les modèles de décomposition et de recomposition sont identiques et que l’interpolation n’est pas régularisante, alors les HRTF aux points de mesure originaux reste inchangées par cette opération. Les figures 1.33 et 1.34 représentent respectivement l’amplitude spectrale et le portrait de phase des HRTF gauches du sujet NH5 de la base ARI, après interpolation optimisée par décomposition morphologique. La nouvelle grille possède un pas constant de 1˚ en azimut et élévation, au même titre que les représentations précédentes (fig. 1.22 à 1.27). La symétrie sphérique du portrait de phase semble cette fois plutôt bien reconstituée, y compris à 16 kHz. Le résultat est lisse sans aberrations flagrantes, avec une causalité respectée, même pour les sources contralatérales. En revanche, même si l’interpolation de l’amplitude spectrale semble réussie à 1 et 8 kHz, un aliasing spectral est toujours visible à 16 kHz (fig. 1.33). 54Figure 1.33 – Amplitude spectrale (dB) de l’interpolation linéaire par dé- composition sphérique, des HRTF gauches du sujet NH5 de la base ARI. Représentation en azimut θ et élévation φ, à fréquence fixe. 55Figure 1.34 – Portrait de phase (radian) de l’interpolation linéaire après décomposition par modèle sphérique, HRTF gauches du sujet NH5 de la base ARI. Représentation en azimut θ et élévation φ, à fréquence fixe. 56Bien que plus faible qu’en interpolation linéaire directe (fig. 1.26), cette erreur montre néanmoins les limites du modèle, qui mériterait donc d’être affiné. Pour conclure, cette interpolation par décomposition morphologique est suffisamment robuste pour être mise en pratique et les résultats de test d’écoute à la volée sont plutôt satisfaisants. Il reste cependant des artefacts d’interpolation audibles pour les sources situées proches de l’axe interaural, dues aux erreurs visibles dans les représentations du résidu Hr (Xi) (fig. 1.31 et 1.32). Enfin, d’autres méthodes d’interpolation (quadratiques, cubiques, harmoniques sphériques, etc.) peuvent être appliquées sur le résidu Hr (Xi) et ce, indépendamment de la décomposition morphologique choisie. 1.4.3 Variations de position Une des principales applications de l’interpolation optimisée des HRTF concerne le Head-Tracking, qui consiste à corriger en temps réel la direction spatiale (θ, φ) des sources sonores, en fonction des rotations de la tête. L’utilisation d’un tel dispositif augmente singulièrement la qualité d’expérience binaurale, grâce à un rendu dynamique de l’espace, contrôlé consciemment (ou inconsciemment) par l’utilisateur (e.g. [10], [12]). Par exemple, l’image sonore est plus stable, la localisation des directions spatiales des sources sonores est facilitée et l’externalisation est, elle aussi, bien meilleure. Pour ce faire, l’ensemble des directions de l’espace doit être synthétisable par rendu binaural, ce qui implique une définition continue des HRTF. Comme les mesures sont discrètes par nature, il est nécessaire de recourir à des algorithmes d’interpolations à la fois rapides et transparents. Cependant, l’accès à un Head-Tracker n’était pas possible lors de la réalisation du spatialisateur PifPaf3D, c’est pourquoi une méthode de rendu dynamique sans Head-Tracking a été imaginée. La démarche consiste à rendre mobiles les sources sonores pour profiter d’indices de localisation dynamiques (e.g. [47], [84]), sans pour autant détériorer le rendu binaural par un détimbrage permanent. Des trajectoires spatiales autour des positions fixes ont donc été mises en place, d’amplitude angulaire de l’ordre de la Just Noticeable Difference (1˚ à 4˚ selon l’azimut θ), afin de s’adresser à la partie inconsciente de la localisation spatiale. Une trajectoire de micro-variations est représentée par des ronds noirs sur la figure 1.35, en azimut-élévation. Elle est tout d’abord superposée aux HRTF brutes du sujet NH5 de la base ARI, à 16 kHz, autour de la position θ = 180˚ et φ = 0˚ (en haut). Comme la JND est de l’ordre du degré, l’amplitude maximale du mouvement doit être du même ordre, arbitrairement fixé à 2˚. Il apparaît clairement que sans interpolation spatiale des HRTF, les micro-variations sont proprement inutiles, puisque le même filtre HRTF 57Figure 1.35 – Représentation en azimut θ et élévation φ à 16 kHz des HRTF gauches du sujet NH5 de la base ARI, centrées sur la position θ = 180˚ et φ = 0˚. Les positions successives des micros-variations sont représentées par les ronds noirs. (Haut) Amplitude spectrale (dB) des mesures brutes. (Milieu) Amplitude spectrale (dB) après interpolation optimisée par décomposition sphérique. (Bas) Phase (rad) après interpolation optimisée par décomposition sphérique. 58est toujours utilisé, quelle que soit la position de la source sonore dans l’espace. Les deux représentations suivantes montrent en revanche l’intérêt d’une interpolation optimisée des HRTF, ici par décomposition sphérique. Sur la trajectoire du milieu, des variations en amplitude spectrale sont cette fois bien présentes, principalement en élévation (entre −12 et −2 dB). Sur la trajectoire du bas, les isovaleurs de phase (agissant notamment sur l’ITD) sont plutôt verticales, ce qui conduit à des variations principalement azimutales. Ces deux constats peuvent s’expliquer par la géométrie de la tête et du pavillon. En effet, il est coutumier de dire que les variations d’ITD sont principalement azimutales, car reliées à la forme plutôt sphérique de la tête. D’autre part, les fortes variations spectrales sont surtout causées par la géométrie du pavillon, qui génère de plus grandes variations dans les HRTF en élévation qu’en azimut (e.g. [15], [12]). Fort de ces deux remarques, la trajectoire des micro-variations représentée sur la figure 1.35 a donc été choisie de manière à exciter à la fois la phase et l’amplitude spectrale, sans a priori. Par ailleurs, ces résultats se retrouvent bien entendu pour des fréquences plus basses que 16 kHz, mais avec des variations moins intenses. Un stage a été encadré durant cette thèse pour évaluer subjectivement l’impact des micro-variations, mais ces travaux n’ont pas abouti à une conclusion probante. De plus, de nouvelles recherches pourraient être menées sur ce thème, notamment pour générer des trajectoires optimales, trouver des amplitudes et des périodes d’oscillations adaptées, ou encore comparer des trajectoires continues contre des apparitions stochastiques localisées. Enfin, le traitement du signal audio se faisant par blocs de données, la question du nombre de blocs nécessaires pour construire proprement une trajectoire est encore à déterminer. 1.4.4 Déraffinement spatial d’une base de données Les résultats de l’interpolation par décomposition morphologique ouvrent une perspective intéressante sur la discrétisation spatiale des HRTF. En effet, une interpolation de haute fidélité permet notamment de réduire le nombre d’interpolants nécessaires à la reconstruction spatiale des données. Or, la représentation en azimut-élévation à fréquence fixe de l’amplitude spectrale de la HRTF brute du sujet NH5 de la base ARI (fig. 1.22) laisse supposer une sur-discrétisation du problème. En effet, moyennant une égalisation visible des haut-parleurs entre eux (stries horizontales), les variations en module semblent plutôt faibles au regard de l’échantillonnage spatial des mesures, compris entre 2.5˚et 5˚en azimut et élévation. Aussi, un déraffinement arbitraire a été envisagé, de l’ordre de 15˚ en moyenne en azimut et élévation. De plus, une grille uniforme est préférentiel- 59Figure 1.36 – Représentation en azimut θ et élévation φ à 8 kHz de l’amplitude spectrale (dB) des HRTF gauches du sujet NH5 de la base ARI. Les positions des mesures sont données par les points noirs. (Haut) Mesures brutes uniformément déraffinées tous les 15˚. (Milieu) Interpolation par décomposition sphérique sur la grille déraffinée. (Bas) Mesures brutes originales. 60Figure 1.37 – Représentation en azimut θ et élévation φ à 8 kHz du portrait de phase (rad) des HRTF gauches du sujet NH5 de la base ARI. Les positions des mesures sont données par les points noirs. (Haut) Mesures brutes uniformément déraffinées tous les 15˚. (Milieu) Interpolation par décomposition sphérique sur la grille déraffinée. (Bas) Mesures brutes originales. 61lement extraite de la grille originale, notamment pour limiter les redondances locales. Ce faisant, le nombre de mesures utiles passe de 1550 positions à environ 220, puisque diviser par 3 le nombre de mesures sur chaque dimension revient à diviser par 8 le nombre de mesures total sur la sphère. Cette division est résolument excessive, l’idée étant simplement de montrer une application de la Décomposition par Modèle Morphologique, qui mériterait d’être approfondie par la recherche de grilles optimales en fonction du modèle choisi. La figure 1.36 (haut) donne une représentation en azimut-élévation de l’amplitude spectrale brute de la HRTF du sujet NH5 de la base ARI, sur la grille déraffinée. La fréquence a été fixée à 8 kHz, puisqu’un aliasing spectral apparaissait déjà à 16 kHz, lorsque l’ensemble des mesures était pris en compte (fig. 1.33). Après interpolation par décomposition sphérique (fig. 1.36, milieu), l’amplitude spectrale résultante semble consistante avec l’originale (fig. 1.36, bas), excepté pour l’oreille contralatérale. Apparaît dans cette zone la diffraction de la sphère par surcompensation, ce qui démontre que le modèle n’est pas suffisamment fin pour être directement exploité. En revanche, le portrait de phase semble plutôt convaincant, comme le montre la figure 1.37, et ce, malgré le peu de mesures originales exploitées. En effet, il n’y a pas d’artefacts visibles, la causalité est respectée et la phase semble se dérouler correctement. Au vu de ces représentations, la Décomposition par Modèle Morphologique semble une technique tout à fait prometteuse pour le déraffinement spatial des HRTF. Malgré la simplicité apparente du modèle utilisé, les ré- sultats pour la phase sont plutôt bons et ceux pour l’amplitude spectrale ne sont pas dénués d’intérêt. Par ailleurs, il n’est pas inutile de rappeler que la fréquence choisie est assez élevée et le déraffinement plutôt fort. Aussi, comme spécifié plus haut, une piste pour améliorer cet algorithme sans changer de modèle serait de chercher une répartition optimale des données sur la sphère, minimisant les erreurs d’interpolation spectrale sur l’amplitude. Enfin, pour définitivement valider cette approche, des tests subjectifs complémentaires sont encore à réaliser. 1.4.5 Vers une méthode d’individualisation Selon l’équation (1.9), la Décomposition par Modèle Morphologique fait intervenir des paramètres propres aux modèles, notés p m. Ces paramètres peuvent être purement abstraits, ou en lien avec des éléments de la morphologie individuelle, à l’origine des HRTF. Auquel cas, les deux applications précédentes pourraient voir leurs performances améliorées, en individualisant les étapes de décompositions et recompositions par un modèle correctement ajusté aux HRTF considérées. En outre, les étapes de décomposition et de 62recomposition étant indépendantes, il serait même envisageable de décomposer des HRTF par un modèle adapté, puis de les recomposer en utilisant cette fois une nouvelle paramétrisation dudit modèle, propre à l’auditeur. Sous réserve que le résidu obtenu par décomposition soit bien indépendant des paramètres utilisés, cette approche autoriserait une réelle individualisation des fonctions de transfert HRTF. Par exemple, des mesures de haute qualité, dont les paramètres morphologiques seraient connus, pourraient être couplées à des modèles analytiques ou numériques en vue d’une individualisation sur un ou plusieurs critères morphologiques. Afin d’estimer la faisabilité d’une telle approche, une paramétrisation individualisée a été appliquée à une décomposition par modèle sphérique de Duda (eq. 1.11, [25]). Comme la représentation temporelle du résidu (fig. 1.30) issue de cette décomposition laisse penser que les HRTF décomposées par une sphère ne possède plus d’ITD, ce dernier a préférentiellement été choisi pour valider le concept. De plus, le rayon de la sphère peut être choisi en lien avec le périmètre crânien de l’auditeur, ce qui offre un premier pas vers l’individualisation des HRTF. Pour ce faire, la première étape consiste à mesurer sur le plan azimutal l’ITD de HRIR originales, ici celles du sujet NH5 de la base ARI (fig. 1.38, haut). Cet ITD a été mesuré en recherchant pour chaque azimut les premiers échantillons temporels où le niveau de l’amplitude signal franchit un certain seuil. Aussi, pour compenser la perte de niveau en distance imputable au décentrage de l’oreille, les HRIR ont préalablement été multipliées par un facteur (t × c) 2 , où t correspond au temps de propagation (en seconde) et c correspond à la célérité des ondes dans l’air à 15˚ (soit 340 m/s). Enfin, afin de limiter les erreurs dues aux imperfections de mesures, chaque échantillon temporel compensé en niveau a été moyenné par un fenêtrage de Hann sur ses plus proches voisins. Le résultat de ces deux traitements, après normalisation, est représenté sur la figure (fig. 1.38, milieu). En accord avec cette représentation, le seuil de recherche a été fixé à −15 dB. L’ITD ainsi mesuré est représenté par un liserai marron sur les HRIR originales (fig. 1.38, haut) et semble suffisamment satisfaisant pour continuer. La seconde étape consiste en l’ajustement du rayon a d’un modèle de tête sphérique, pour coller par essai-erreur un ITD sphérique analytique sur l’ITD mesuré précedemment. Cet ITD sphérique est calculé pour chaque azimut en considérant le maximum des HRIR sphériques analytiques. Ces deux ITD sont représentés en bleu sur la figure (fig. 1.39). Les deux courbes coïncident plutôt bien pour les azimuts situés à l’arrière, voire sur les côtés, mais plus difficilement sur le plan frontal. Ce résultat est probablement causé par la géométrie de la tête, qui tend vers une sphère à l’arrière, mais qui s’en éloigne assez fortement vers l’avant. C’est la raison pour laquelle le "zéro" de l’ITD a été placé à θ = 180˚, sans tenir compte de θ = 0˚. Le rayon de la sphère 63Figure 1.38 – (Haut) Représentation temporelle dans le plan azimutal des HRIR du sujet NH5 de la base de données ARI, amplitude signal avant décomposition sphérique (ITD en marron). (Milieu) Représentation temporelle de ces mêmes HRIR compensées en distance et lissées par fenêtrage afin de mesurer l’ITD par seuil de l’amplitude signal, fixé à −15 dB. (Bas) Représentation temporelle de ces mêmes HRIR après individualisation par décomposition sphérique de rayon inférieur (ITD en marron). 64Figure 1.39 – Représentation de l’ITD (ms) en fonction de l’azimut θ (˚), pour les HRTF originales, sphériques et individualisées avec Décomposition par Modèle Morphologique. des HRTF azimutales du sujet NH5 a ainsi été estimé à a = 9.7 cm. Une fois ce paramètre de la décomposition sphérique établi, l’étape suivante consiste à établir un nouveau jeu de paramètres pour le modèle considéré. Dans cette étude, un rayon b = 8.0 cm a été choisi arbitrairement, afin de générer une tête sphérique de circonférence inférieure à celle du sujet NH5. Dès lors, les HRTF originales peuvent être décomposées par le modèle sphé- rique de paramètre correspondant a, avant d’être recomposées par le même modèle reparamétré par b. Si l’hypothèse d’indépendance est bien vérifiée, les HRTF ainsi générées deviennent individualisées. La dernière étape permettant de valider le concept consiste alors à mesurer l’ITD des HRTF recomposées par le même protocole de mesures que pour les HRTF originales. Le résultat ainsi obtenu est représenté par un liseré marron et superposé aux HRIR individualisées (fig. 1.38, bas). Une bonne coïncidence entre l’ITD mesuré et le front d’onde est de nouveau obtenu par cette méthode. De plus, la HRIR individualisée ne semble pas présenter d’aberration flagrante faisant suite au traitement subi, ce qui donne du cré- dit au résultat obtenu pour l’ITD. Aussi, ce dernier a été tracé en rouge sur la figure 1.39, au même titre que la mesure de l’ITD du modèle sphérique équivalent. Comme le montrent ces deux dernières courbes, l’ITD individualisé semble coller à son modèle et ce dernier est bien représentatif d’une tête 65sphérique singulièrement plus petite que l’originale (en bleu). Donc, mises à part les aberrations frontales déjà présentes pour le modèle sphérique original, il semble bien que l’ITD soit indépendant du résidu de la décomposition sphérique, ce qui en autorise la personnalisation. Pour poursuivre cette étude, il faudrait désormais valider l’individualisation de la phase et de l’amplitude spectrale. Cette étape, bien plus complexe, n’a pas été abordée durant cette thèse et fera très probablement l’objet de recherches ultérieures. Par ailleurs, des modèles numériques peuvent désormais être utilisés pour affiner l’individualisation, comme des têtes ellipsoïdes, des "snowman model", ou encore des maillages de têtes. 66Chapitre 2 Moteur binaural PifPaf3D Une grande partie des travaux de thèse a porté sur la conception et la réalisation d’un moteur de synthèse binaurale innovant, nommé PifPaf3D (fig. 2.1). Ce moteur intègre de nombreuses fonctionnalités pour chaque étape de la chaîne de production sonore, de la captation à la restitution. Il a été entièrement programmé et optimisé en langage Matlab, bénéficiant ainsi d’une grande souplesse de programmation pour en faire un outil de prototypage efficace (≈ 2000 lignes de code). De plus, aucune librairie externe n’a été utilisée, ceci afin d’assurer un contrôle total sur l’ensemble des traitements effectués. Aussi, l’essentiel des recherches effectuées en spatialisation sonore, présentées ou non dans ce manuscrit, ont été implémentées dans ce moteur, testées et validées de manière analytique et/ou subjective. Par ailleurs, ce spatialisateur ayant été développé dans le contexte industriel de la thèse CIFRE, pour des raisons évidentes de protection de la propriété industrielle, seule une revue générale des différents modules est présentée dans ce chapitre. Les détails de conception et de programmation de ce moteur ne seront donc pas explicités. 2.1 Introduction et configuration Le spatialisateur PifPaf3D est un logiciel exclusivement écrit en langage Matlab, interfacé avec une interface graphique (GUI) faisant appel aux différentes parties de la librairie, selon le traitement audio souhaité (fig. 2.1). Il se décompose en différents modules, indépendants et autonomes, ce qui permet de réaliser n’importe quel traitement audio dans un ordre déterminé par l’utilisateur. Les passerelles pour assurer la communication entre chaque module ont été implémentées sous forme de pipe-line et tous les traitements ont été programmés sous forme de fonctions callback. Cette logique de pro- 67Figure 2.1 – PifPaf3D, prototype Matlab pour la spatialisation sonore en temps réel. 68Figure 2.2 – PifPaf3D - Module de Configuration. grammation rend ce code suffisamment flexible pour s’adapter au traitement audio temps réel. À titre informatif, sur un ordinateur portable standard dont le processeur est cadencé à 1.6Ghz, il est possible de spatialiser et contrôler en temps réel au moins seize sources sonores dynamiques simultanément. En mode offline, un nombre illimité de sources peut être joué puisque le temps de calcul est simplement proportionnel au nombre de canaux traités. Au démarrage de PifPaf3D, la première étape consiste à configurer le moteur avec l’interface graphique (fig. 2.2), qui permet d’accéder aux principaux paramètres. Tout d’abord, l’utilisateur fait le choix dans une liste de fichiers audio multicanaux, présents dans un dossier ’wav/input/’ à la racine du script de lancement du logiciel. Ces fichiers doivent être au format .wav, préférentiellement échantillonnés à 44.1 kHz et de nombre de canaux fixe (mono, stéréo, 5.1, 7.1, n.m, etc.). Ensuite, l’utilisateur peut choisir son routing dans une batterie de fichiers .txt, disponibles par défaut dans un dossier ’data/speakers’. Ces fichiers contiennent à la fois des positions statiques de sources audio et des trajectoires pré-établies en fonction du temps et de l’espace. L’utilisateur peut ainsi utiliser les routing présents, ou créer son propre fichier. Voici, par exemple, un script pour effectuer une trajectoire dynamique sur deux canaux. Ici, le premier canal se déplace pendant 30 secondes derrière l’auditeur, tandis que le second passe au-dessus sur la même durée : % Source 1 sources.azimuth{1} = [90,270]; % Azimut (deg) sources.elevation{1} = [0,0]; % Elevation (deg) sources.range{1} = [2,2]; % Distance à l’auditeur (m) sources.time{1} = [0,30]; % Durée entre les 2 positions (s) % Source 2 sources.azimuth{2} = [270,270]; sources.elevation{2} = [0,180]; 69sources.range{2} = [2,2]; sources.time{2} = [0,30]; Cette étape effectuée, l’intervalle de lecture du fichier audio est défini, avec pour unité la seconde. Enfin, la latence du rendu temps réel peut être modi- fiée, ainsi que la taille des blocs de traitement du signal. Ces deux paramètres agissent essentiellement sur la fluidité de la lecture en rendu temps réel, qui est fonction de la puissance de calcul disponible sur la machine. Une fois tous ces choix établis, le spatialisateur peut être lancé en cliquant sur le bouton "GO !", ce qui affichera l’interface complète (fig. 2.1) et bloquera définitivement le module de configuration (fig. 2.2). PifPaf3D devra donc être relancé pour tout changement ultérieur dans ces données. Pour les utilisateurs plus avancés, il est possible de choisir d’autres paramètres directement dans le code source. À titre d’exemple, peuvent être cités la forme des fenêtres de traitement audio (Hann, Porte, Sine, Linear, etc.), le répertoire de sortie des fichiers audio après traitement (par défaut ’wav/output/’) ou la taille des filtres utilisés. 2.2 Transport et contrôle Le module de transport (fig. 2.3) se décompose en deux parties. La première partie (onglet "Play") propose les principales fonctionnalités de lecture et de navigation dans un fichier audio, à savoir un curseur de lecture, un curseur de volume pour le monitoring, un bouton play/pause, ainsi qu’un bouton de répétition. Par ailleurs, il est possible de désactiver la lecture temps réel pour traiter des fichiers audio plus rapidement en mode offline. Tous les algorithmes de traitement du signal sont routés sur ce module, qui réalise une transformée de Fourier en overlap-add [7] sur des blocs fenêtrés, typiquement par des fenêtres de Hann. Ce fenêtrage est nécessaire pour limiter l’impact d’éventuels changements brutaux dans des fonctions de transfert utilisées lors d’un filtrage, qui peuvent introduire des claquements audibles perturbant l’écoute. Par exemple, des sauts de filtres interviennent en continu lors du traitement binaural de sources en mouvement. Aussi, cette combinaison entre overlap-add et fenêtrage a été optimisée pour le cas particulier du filtrage binaural, dont les fonctions de transfert HRTF ont des caractéristiques propres. Cette optimisation a conduit au développement d’un algorithme type overlap performant, qui fera l’objet d’une publication ultérieure. La seconde partie de ce module (onglet "Sources", fig. 2.3) permet de visualiser séparément des informations relatives aux canaux audio, préalablement définis dans le routing, dans un esprit de mixage objet. C’est pourquoi 70Figure 2.3 – PifPaf3D - Module de transport. chaque tranche donne la couleur et les coordonnées sphériques de la source associée, représentée dans le module de contrôle détaillé ci-après (fig. 2.4). De plus, il est possible d’activer ou de désactiver une source sonore par des boutons "Mute/Solo" interconnectés, ainsi que de modifier le gain d’entrée de chaque tranche de +/- 3 dB. Au même titre que le module de transport, le module de contrôle (fig. 2.4) se décompose en deux parties. La première partie (fig. 2.4, gauche) donne une représentation de l’espace péri-personnel, avec un auditeur représenté en trois dimensions entouré de sources sonores ponctuelles. Pour faciliter la visualisation, les axes cartésiens ont été rajoutés, ainsi que trois cercles de positionnement inclus dans une sphère de rayon unité, le tout complété par un plan sur lequel repose l’auditeur. De plus, des rotations de la camera et de l’éclairage sont autorisées, notamment pour lever d’éventuelles indéterminations de positionnement en naviguant au sein de la scène sonore. Enfin, un onglet situé en haut à gauche de l’interface graphique permet de choisir le mode de déplacement des sources sonores pour les contrôler en temps réel. Les sources à mouvoir sont sélectionnées dans le module de transport (fig. 2.3) par un clic sur le bouton donnant les coordonnées sphériques de leur position, puis déplacées par le pavé numérique du clavier, la souris, ou encore une manette de type Microsoft XBox 360. Le clavier et la manette 71Figure 2.4 – PifPaf3D - Module de contrôle. font bouger les sources relativement à leurs positions respectives, tandis que la souris fixe une position absolue. Dans ce dernier cas, la position de la croix rouge sur la grille du module de contrôle (fig. 2.4, droite) détermine les coordonnées azimutales des sources sonores sélectionnées, tandis qu’un curseur sur le côté permet d’en modifier l’élévation. Toutes ces fonctionnalités faisant appel à un rafraîchissement graphique récurent (plutôt gourmand en CPU), le ratio entre la charge de calcul disponible et le coût de la mise à jour est vérifié en permanence, notamment pour que ces dernières ne soient pas faites au détriment des traitements audio. Il est important de souligner que ces outils ont avant tout été conçus pour naviguer et contrôler des sources sonores en temps réel sous Matlab, afin de tester et valider les différents traitements audio. Ils n’ont donc pas vocation à former une véritable plate-forme de mixage professionnel. 2.3 Traitement Binaural Le module de traitement binaural (fig. 2.5) s’appuie essentiellement sur les recherches présentées dans le premier chapitre de ce manuscrit. Tout d’abord, les bases de données de fonctions HRTF utilisées pour le filtrage (onglet "HRIR" de la figure 2.5) sont issues des bases publiques suivantes : – CIPIC, Université de Californie [3] ; – ARI, Institut de Recherche en Acoustique de l’Académie des sciences d’Autriche [6] ; – LISTEN, Institut de Recherche et Coordination en Acoustique et Musique [62]. 72Figure 2.5 – PifPaf3D - Module de traitement binaural. Ces bases ont comme points communs d’être disponibles au format Matlab et d’être livrées avec des filtres sous forme HRIR, des coordonnées des points de mesures, ainsi que des données morphologiques associées à chaque sujet. Ces trois informations sont nécessaires et suffisantes pour le bon fonctionnement du filtrage binaural dispensé par PifPaf3D. En effet, la convolution en domaine de Fourier entre un signal monophonique et les filtres gauches et droits d’une HRTF à une position donnée est réalisée par interpolation linéaire locale quadrangle sur des grilles régularisées de filtres. Pour ce type de support, la recherche des filtres voisins à la position souhaitée est instantanée : les parties entières de l’azimut et de l’élévation donnent directement les indices des filtres à interpoler, tandis que les parties décimales fournissent les coefficients de pondération de la sommation. Il n’y a donc pas de parcours d’arbre, ce qui diminue d’autant les charges de calcul pour chaque position à évaluer. Aussi, une attention particulière a été portée sur l’interpolation globale des HRTF brutes, notamment pour minimiser les erreurs générées au cours de la formation des grilles régulières, à l’origine d’artefacts audibles. Les recherches sur cette problématique ont conduit à la Décomposition par Modèle Morphologique (1.9), présentée dans le chapitre précédent. Ainsi, dans un premier temps, des bases de données fidèles aux mesures brutes ont été créées en vue de pratiquer une interpolation locale inaudible (fig. 1.33 et 1.34). Le modèle sphérique de Duda [25] a été utilisé et paramétré par le rayon de la tête dont sont issues les HRTF mesurées. Lorsque celui-ci n’est pas disponible, le rayon de tête moyen (8.74 cm) sert de référence [58]. Pour effectuer des comparaisons subjectives, trois raffinements sont prévus dans l’onglet "Database" de la figure 2.5, à savoir "Low", "Medium" et "High density", correspondant respectivement à 15, 10 et 5 degrés de discrétisation en azimut et élévation. D’autre part, il est important de souligner que les bases de données [3], [6] et [62] ne sont pas les seules exploitables par PifPaf3D, puisque l’algorithme d’interpolation globale est applicable dès lors que les 73filtres et les positions des mesures sont fournis. Par la suite, il est apparu après quelques optimisations que la Décomposition par Modèle Morphologique était peu coûteuse en calcul, ce qui rendait le processus adapté pour du traitement en temps réel. Aussi fut-elle inté- grée directement dans PifPaf3D pour pratiquer les interpolations locales sur des grilles de filtres régulières et déraffinées (exemple fig. 1.36 et 1.37), plus rapides d’accès puisque plus légères en mémoire. De plus, le peu d’espace nécessaire au stockage de ces données favorise le traitement embarqué sur processeurs dédiés de type DSP, qui disposent de plus de ressources de calcul que de mémoire vive. En pratique, PifPaf3D exploite désormais les grilles échantillonnées tous les 15 degrés par défaut, sans artefact d’interpolation audible. Le choix de la densité des grilles est toujours proposé à titre comparatif, mais inusité en pratique. Enfin, l’espace mémoire requis pour de telles grilles est d’environ 2 Mo, ce qui constitue un format d’échange exploitable. Par ailleurs, un bouton "on/off " est disponible sur l’interface graphique (fig. 2.5) pour comparer en temps réel l’activation du binaural contre un downmix stéréo du contenu multicanal original. Afin d’estimer le gain à fournir aux canaux gauches et droits, le downmix utilise la norme Root Mean Square (moyenne quadratique) normalisée des filtres HRTF aux positions des sources sonores. Ainsi, le downmix est bien rendu en stéréophonie, il tient compte de la position des sources sonores et conserve la norme RMS du signal "downmixé" constante par rapport au traitement binaural. Ce faisant, les écoutes comparées permettent d’apprécier à sa juste valeur la spatialisation, sans autres biais que le Loudness. Pour les utilisateurs avertis, PifPaf3D propose quatre paramètres avancés disponibles dans l’onglet "Advanced" de la figure 2.5 : 1. Le premier de ces paramètres ("D") offre une première étape d’individualisation. Le principe est fondé sur la Décomposition par Modèle Morphologique pour l’individualisation, telle que présentée dans le chapitre précédent. L’utilisateur rentre le diamètre de sa tête en cm, qui sera utilisé pendant l’étape de recomposition par modèle sphérique. Les réponses fréquentielles présentes dans les HRTF finales se trouve dès lors plus proches de celles de l’utilisateur que de celles des HRTF originales, notamment pour l’ITD (fig. 1.39). 2. Les deux paramètres suivants ("A","T") règlent respectivement l’amplitude (degré) et la période (seconde) des oscillations des micro-variations de sources, détaillées dans le chapitre précédent (fig. 1.35). Par défaut, ces paramètres sont fixés en deçà du seuil de perception. Des recherches par tests perceptifs ont été effectuées par un stagiaire pour analyser l’impact de ces paramètres sur la localisation. Ces travaux n’ayant pas 74Figure 2.6 – Schématisation des premières réflexions intervenant lors de la propagation d’une onde sonore dans un espace clos. (source www.audacity.sourceforge.net) donné de résultats significatifs, des études restent encore à mener pour évaluer les micro-variations et trouver des paramètres rigoureux. 3. La dernière option permet d’activer ou de désactiver un modèle dynamique de premières réflexions (early reflexions, fig 2.6), fruit d’une discussion avec J.-C. Messonnier du Conservatoire National Supérieur de Musique et de Danse de Paris [66]. Ce modèle est fondé sur une méthode source-image temps réel [2], indépendante pour chaque source sonore, ayant vocation à simuler la présence de panneaux réflecteurs autour de la source pour favoriser la création d’énergie précoce [63]. Pour ce faire, deux HRTF sont superposées à l’originale, choisies symétriquement de part et d’autre et de la source. Chacune est retardée manuellement, relativement à la distance entre l’auditeur et la source fantôme ainsi créée. Cet outil offre des perspectives intéressantes, en rajoutant des indices de localisation pour lever l’indétermination de positionnement des sources sonores. Une analyse plus approfondie, ainsi qu’une validation subjective fera l’objet de travaux ultérieurs. Pour terminer, plusieurs effets de distance ont été rajoutés, afin d’imiter artificiellement l’éloignement entre la source sonore et l’auditeur (fig. 2.5). Le premier effet, simple et efficace, consiste à jouer sur le volume de la source sonore en fonction de son éloignement. Une loi en 1 rα a été employée, avec α contrôlé par l’utilisateur pour adapter le gain en fonction du contenu audio. 75Figure 2.7 – Cross-ear selection pour la correction des HRTF gauches et droites, en champ proche [75]. Sur ce schéma, la sphère verte représente une tête, le maillage quadrangle appartient à la sphère de mesure des HRTF, la flèche bleu indique l’avant (axe Ox), la flèche verte indique la gauche (axe Oy) et la flèche rouge le dessus (axe Oz). Pour une source proche de l’auditeur (trait plein noir), le filtre HRTF sans traitement spécifique est celui donné par la direction en pointillés, invariant selon la distance. Après cross-ear selection, les filtres gauches et droits sont donnés par les directions en tirets. Le deuxième effet intervient lors de la Décomposition par Modèle Morphologique, en recomposant le résidu sphérique par les HRTF sphériques évaluées cette fois à la distance souhaitée. Le troisième effet consiste à filtrer le signal d’entrée par un coupe-haut modélisant l’absorption de l’air selon la distance parcourue par l’onde sonore. Cet effet intervient principalement pour les sources en champ lointain. Pour le champ proche, un quatrième et dernier effet nommé cross-ear selection vient compléter cette panoplie [53] [75]. Les HRTF utilisées pour le traitement binaural sont sélectionnées sur la sphère de mesure originale, en calculant géométriquement les coordonnées des HRTF réellement mises en jeu lorsqu’une source se rapproche de l’auditeur (fig. 2.7). Mathématiquement, cela revient à résoudre une équation du second degré pour chaque oreille, puisque la position cherchée est solution de l’intersection entre une droite et une sphère. Pour l’ensemble de ces effets, il est important de préciser que, faute de base de données de HRTF en distance aisément disponible, aucun procédé n’a été validé analytiquement. Seule une évaluation perceptive a été pratiquée, donnant des résultats encourageants. Une analyse approfondie de ces effets doit désormais être faite pour s’assurer que les HRTF ainsi modifiées respectent bien la physique du problème. 76Figure 2.8 – Microphone Soundfield SPS200 et enceinte KH pour la mesure impulsionelle en B-Format du studio de répétition de l’École Polytechnique. (Atelier des Ondes, www.atelierdesondes.net) 2.4 Acoustique de salle et Ambisonics Comme les HRTF sont classiquement mesurées en chambre anéchoïque, le traitement binaural issu de la convolution avec de tels filtres souffre bien souvent d’un manque d’espace, minimisant la sensation d’externalisation. C’est pourquoi, un module d’acoustique de salle vient avantageusement compléter le module binaural précédent, en apportant l’illusion de la diffusion au sein d’une pièce. Le principe consiste en l’ajout d’une réverbération directionnelle pour chaque source sonore, captée en trois dimensions en High Order Ambisonics (HOA) et restituée en binaural par un système de haut-parleurs virtuels fixes. La thèse de J. Daniel [20] en explicite toute la théorie, qui ne sera donc pas reprise ici, mais survolée d’un point de vue pratique en accord avec la courte introduction du premier chapitre. La première étape pour réaliser ce traitement consiste à construire une base de données de réponse impulsionnelle d’une salle (Room Impulse Responses) en format HOA. Pour ce faire, il existe principalement deux mé- thodes : – Virtuellement en simulant numériquement la mesure avec des logiciels adaptés, tels que Catt-Acoustique 1 . Cette approche permet d’obtenir un ordre HOA flexible, de considérer n’importe quelle pièce et de disposer les points de mesures à n’importe quelle position de l’espace. En 1. Un résultat de simulation numérique d’un studio de type LEDE, effectuée au LIMSI/CNRS, a été utilisé dans cette étude. 77Figure 2.9 – Projection sur les harmoniques sphériques de la norme RMS des quatre signaux du B-Format, représentation spatiale d’une mesure par microphone SoundField. revanche, certaines simulations peuvent générer des artefacts audibles, notamment en haute fréquence, qui nuisent au rendu. – Réellement en mesurant des réponses impulsionnelles avec une sphère de microphones. Cette technique demande à la fois du matériel de haute qualité (microphones HOA, carte son, haut-parleurs, salle mesurable, etc.), ainsi que des logiciels de traitement du type encodeur/décodeur HOA. Cette technique est plus difficile à mettre en œuvre, mais offre souvent des résultats plus convaincants à l’écoute. Ces deux approches ont été testées durant la thèse et les résultats intégrés dans PifPaf3D. Ainsi, un outil Matlab a été spécifiquement programmé pour réaliser des mesures de réponses impulsionnelles par microphone HOA. Cependant, comme le seul microphone 3D à disposition pendant la thèse était un Soundfield SPS200 (à gauche sur la figure 2.8), toutes les prises de son ont été faites à l’ordre 1 (équivalent du B-Format). Ce logiciel doit donc encore être éprouvé pour les ordres supérieurs. Cela étant, trois pièces ont été mesurées, à savoir la salle à manger de la société Digital Media Solutions, le bureau de l’équipe Audio 3D de DMS et le studio de répétition des étudiants de l’École Polytechnique (fig. 2.8). Dans le cas du studio, un haut-parleur a été placé tous les 30 degrés en azimut, à élévation nulle, pour générer une base de données sur douze positions. Le signal de mesure utilisé est une combinaison entre codes de Golay [32], bruit blanc et sweep-sine fréquentiel [80]. À titre d’exemple issu d’une de ces mesures, la projection sur les har- 78Figure 2.10 – Méthode des haut-parleurs virtuels pour le rendu ambisonique en binaural. (source [20]) moniques sphériques de la norme RMS des quatre signaux du B-Format est représentée dans l’espace sur la figure 2.9. Cette enveloppe prend la forme d’un champignon, dont le maximum est symbolisé par l’étoile noire, tandis que le cercle noir donne la position théorique du haut- parleur comme réfé- rence. La mesure est validée dès lors que ces deux objets sont suffisamment proches, preuve que l’onde directe est captée à la bonne incidence. Avec ce type de représentation, cet outil peut aussi servir à la localisation de sources sonores. En complément de ces données, les RIR effectuées par A. Farina en B-format dans une salle de classe, une bibliothèque et une salle de concert (www.isophonics.net, [29]) ont aussi été intégrées dans PifPaf3D. La deuxième étape consiste à filtrer les sources sonores ponctuelles par les fonctions de transfert tridimensionnelles de la pièce, obtenues pendant l’étape précédente. Tout d’abord, chaque position est associée à la plus proche RIR mesurée et le contenu audio de la source est filtré en domaine ambisonique pour obtenir la projection du signal original sur les harmoniques sphériques. Suivant cette étape d’encodage, un filtrage supplémentaire peut éventuellement être ajouté pour corriger la proximité des haut-parleurs, ou encore la sphéricité du microphone dans le cas d’une mesure réelle. Une fois toutes les sources audio traitées par leurs réponses respectives, celles-ci sont sommées, toujours en domaine ambisonique. Un décodage associe alors le signal à diffuser sur chaque haut-parleur virtuel, qui sont in fine rendus par filtrage binaural comme résumé figure 2.10. En pratique, le module d’acoustique de salle de PifPaf3D (gauche, fig. 2.11) est capable de traiter jusqu’à huit sources sonores en temps réel avec un dé- codage HOA d’ordre 3, diffusé sur un système à vingt canaux disposés aux 79Figure 2.11 – PifPaf3D - (Gauche) Module de traitement acoustique de salle. (Droite) Module de traitement High Order Ambisonics. sommets d’un dodécaèdre. Pour ce faire, l’algorithme d’overlap-add optimisé pour le traitement binaural a été adapté à l’ajout d’acoustique de salle par convolution, ce qui diminue considérablement les coûts de calculs effectués par Matlab. De plus, l’interface graphique offre la possibilité de comparer l’ajout d’acoustique de salle au signal original par un bouton "on/off ", qui active/désactive l’effet en temps réel. Pour respecter les niveaux lors d’écoutes comparées, un contrôle des gains à la volée a été ajouté pour que la norme RMS du signal de sortie soit proche de celle du signal d’entrée. Cette option est disponible par simple clic sur le bouton "Volume" de l’interface. Par ailleurs, comme expliqué précédemment, plusieurs salles sont présentes par défaut, comme le studio de l’école Polytechnique, et l’utilisateur averti peut aisément rentrer ses propres mesures dans le code source. Un ordre ambisonique variable est proposé, entre 0 (réverbération classique) et 3 (réverbération directionelle), scalable au besoin selon la théorie HOA. Un curseur permet en outre de jouer sur le rapport "Dry-Wet", couramment utilisé par les ingénieurs du son utilisant ce type d’effet. Pour finir, un filtre additionnel permet de compenser la proximité des haut-parleurs (bouton "Near LS") et l’utilisateur peut activer une interpolation linéaire des RIR, à la place d’une recherche de la RIR la plus proche (bouton "Interp"). Suite aux développements effectués pour les mesures réelles de réponses impulsionelles de salle en High Order Ambisonics, un module autonome de traitement HOA a été ajouté à PifPaf3D (droite, fig. 2.11). Ce dernier pratique un encodage/décodage des signaux bruts issus de microphones sphé- riques, couplé à des filtres correctifs. En pratique, seul le Soundfield SPS200 a été éprouvé, faute de microphones d’ordre plus élevé disponibles. Les signaux de sortie sont donc directement projetés sur les harmoniques sphé- riques, relativement aux positions des capsules, avant d’être filtrés en domaine ambisonique pour compenser notamment la répartition sphérique et la directivité des capsules. Enfin, le décodage HOA est effectué sur le sys- 80Figure 2.12 – Représentation fréquentielle du module des filtres associés au casque Sennheiser HD25. tème de haut-parleurs choisi lors de la première étape de configuration de PifPaf3D. Comme le montre l’interface graphique, un choix de microphones est néanmoins possible et les filtres spatiaux associés sont activables (bouton "Spatial filter"). De plus, il est possible de visualiser en trois dimensions le microphone utilisé en cliquant sur le bouton "Visu Mic", notamment pour s’assurer du routing entre les canaux de sortie du microphone et les entrées fixées dans ce module. Enfin, le contenu encodé en HOA peut être sauvé pour une éventuelle utilisation extérieure des signaux bruts encodés en domaine ambisonique (bouton "Save Content"). 2.5 Compensation du casque et égalisation Le dernier module présenté dans ce chapitre concerne la compensation du casque et l’égalisation tri-bande du signal de sortie. La compensation du casque consiste en la suppression de la fonction de transfert issue à la fois des transducteurs utilisés, de la forme et des matériaux de la structure du casque, ainsi que de la cavité formée par le système {Oreille Externe ; Casque} dans le cas d’une écoute fermée. Pour ce faire, plusieurs séries de mesures ont été pratiquées en plaçant différents casques sur la tête artifi- cielle Neumann KU100, isolée phoniquement par des panneaux absorbants. Le signal utilisé pour l’obtention des fonctions de transfert est une combinaison entre code de Golay, bruit blanc et sweep-sine, au même titre que pour les mesures de réponses impulsionnelles de salle. Entre chaque excitation, le casque est retiré puis remis, ceci afin de moyenner intrinsèquement les différents positionnements possibles sur les oreilles. Un code Matlab a été 81Figure 2.13 – PifPaf3D - Module de compensation de casque et d’égalisation tri-bandes. spécifiquement développé pour traiter les données ainsi obtenues et livrer un filtre brut utilisable par PifPaf3D. Un exemple de module fréquentiel d’une fonction de transfert mesurée avec un casque type Sennheiser HD25 est représenté en bleu sur la figure 2.12. Sur cette même figure, apparaissent les différents étapes de traitement avec, en premier lieu, le filtre brut tronqué (en rouge) par un gabarit (en noir), dont la bande fréquentielle est définie par l’utilisateur. Étant donné que la mesure par tête artificielle nécessite l’utilisation d’un filtre coupe-bas pour limiter le bruit, la valeur minimale du gabarit a été fixée à 400 Hz. La valeur maximale est déterminée par une estimation empirique de la zone de linéarité des transducteurs au delà de laquelle les mesures ne sont plus considérées comme tangibles (ici 4000 Hz). Le module de la fonction de transfert ainsi obtenue est alors inversé pour servir de réfé- rence à la création d’un filtre à minimum de phase par modélisation du type Yulewalk (en vert sur la figure 2.12). Ce filtre compensatoire est alors utilisé par convolution en domaine de Fourier sur les signaux gauches et droits. L’interface graphique associée au module de compensation du casque (fig. 2.13) propose ainsi un ensemble de corrections de casques, mesurés au sein de la société DMS et obtenu d’après le protocole précédent. Le module du filtre fréquentiel associé est affiché en noir sur cette figure et le résultat du filtrage des canaux gauche et droit est donné en temps réel par les courbes bleu (canal gauche) et rouge (canal droit). Un bouton "on/off " permet d’activer ou désactiver le traitement en temps réel, notamment pour les écoutes comparées. Par ailleurs, en utilisant cette fonctionnalité, un bruit blanc a été compensé par PifPaf3D pour chaque casque mesuré. Le fichier audio obtenu a été diffusé et enregistré sur le même dispositif que celui utilisé pour les mesures, à savoir le casque positionné sur la tête artificielle Neumann KU100. Ce résultat a été comparé en domaine fréquentiel à la diffusion du bruit blanc de référence, où la fonction de transfert est non compensée. Ainsi, pour la 82plupart des casques, le module fréquentiel obtenu après compensation est bien plus aplati, ce qui valide expérimentalement le procédé et les résultats. Enfin, en complément de cet outil, un égaliseur tri-bande du second ordre est proposé, notamment pour compenser d’éventuelles détériorations fréquentielles du signal original traité par les différents modules composant PifPaf3D. Ce dernier est accessible en temps réel par trois curseurs modifiant les gains par bande de fréquence ("Low", "Medium" et "High", fig. 2.12). Un bouton "Reset" a été ajouté pour remettre rapidement l’ensemble de ces gains à leur valeur par défaut. 2.6 SpherAudio Headphones Dès ses premières versions, PifPaf3D a démontré des performances étonnantes d’un point de vue qualitatif, validées par de nombreux ingénieurs du son, ainsi que d’importants industriels du monde de l’audio. La société DMS a donc rapidement monté une équipe de développement pour créer une librairie C/C++ industrialisable, dont l’équivalence au code Matlab est certifiée par une batterie de tests de non régression. Afin d’assurer une retranscription inaudible sur l’ensemble des traitements effectués, ces tests adoptent tous une précision relative fixée à 10−6 sur les signaux de sortie. PifPaf3D reste donc l’unique référence, limitant les conflits éventuels entre les différents codes. Par ailleurs, la librairie C/C+ a été popularisée sous la marque SpherAudio Headphones (fig. 2.14 et 2.15), et interfacée avec : – un plug’in VST sous Reaper (SpherAudioVST) ; – un processeur dédié (BP84 ) ; – une tablette Samsung Galaxy Tab (SpherAudioDroid) ; – une web audio API en HTML5 (SpherAudioAPI) ; – un serveur audio (SpherAudio@Home). Mis à part le BP84, tous ces développements ont été réalisés par M. Mathieu Coïc, que j’ai eu le plaisir d’encadrer en parallèle des travaux de recherche doctorale présentés dans ce manuscrit. Par ailleurs, de nombreux stagiaires ont contribué à la réalisation de ces outils. Dès lors, il est agréable de préciser que le plug’in VST et le processeur dédié ont été utilisés par de nombreux organismes, publics ou privés (CNSMDP, Radio France, France Télévision, INA, Technicolor, etc.). De plus, Radio France a mis en ligne un site internet pour diffuser des contenus spatialisés, utilisant la gamme SpherAudio pour l’encodage binaural (fig. 2.16). Je profites donc de ce court aparté pour renouveler à tous et à toutes mes sincères félicitations et remerciements. 83Figure 2.14 – Outils et logiciels dérivés de PifPaf3D, développés en parallèle de la thèse par la société Digital Media Solutions. (Haut, gauche) Spatialisateur SpherAudioAPI pour les plate-formes web compatibles HTML5, comme Google Chrome. (Haut, droite) Spatialisateur SpherAudioDroid pour les tablettes Androïd du type Samsung Galaxy et les terminaux mobiles compatibles. (Bas, gauche) Plug’in VST SpherAudioVST pour le logiciel de Musique Assisté par Ordinateur Reaper. (Bas, droite) Processeur Binaural BP84 pour le traitement professionnel sur système embarqué, proposant huit entrées mono et quatre sorties binaurales. 84Figure 2.15 – Outils et logiciels dérivés de PifPaf3D, développés en parallèle de la thèse par les ingénieurs de la société Digital Media Solutions. (Gauche) Interface "télécommande" pour serveur d’Audio spatialisé sous tablette Androïd. (Droite) Interface "télécommande" pour serveur d’Audio-description spatialisée sous tablette Androïd, en vue d’améliorer l’accessibilité au cinéma des personnes non-voyantes. 85Figure 2.16 – Visuels extraits de nouvoson.radiofrance.fr, plate-forme de contenus multicanaux mis en ligne par Radio France, utilisant les outils dé- rivés de PifPaf3D pour l’encodage binaural (BP84 et SpherAudioVST). 868788Chapitre 3 Formulations intégrales rapides pour l’acoustique Une fois que le spatialisateur PifPaf3D eut atteint un stade de développement suffisant pour être exploité dans la suite des recherches, la seconde partie de la thèse porta sur la génération numérique des fonctions de transfert HRTF, notamment pour leurs individualisations. En effet, comme expliqué dans les chapitres précédents, une des difficultés majeures que rencontrent aujourd’hui les technologies binaurales concerne la personnalisation de ces filtres, propres à chacun. De nombreuses études ont démontré qu’un filtrage générique est insuffisant pour un rendu de l’espace réellement convaincant (e.g. [12], [67], [86]). C’est pourquoi le but original de l’ensemble du projet de thèse consiste en l’obtention et l’exploitation de HRTF individualisées pour le grand public, obtenues par une reproduction numérique des mesures physiques (e.g. [39], [49], [50], [51], [52]). Le protocole alors envisagé (fig. 3.1) est découpé en trois grandes étapes : 1. Création et adaptation de maillages de tête/corps individuels, obtenus par traitement d’images et fusionnés ou non avec des maillages paramétriques de formes élémentaires (sphères, ovoïdes, cônes, etc.). Cette étape, détaillée dans le chapitre suivant, a notamment été réalisée en Matlab à partir de données issues d’une Kinect Microsoft. 2. Réalisation d’un moteur de calcul intégral pour résoudre rapidement les équations de propagation des ondes sur lesdits maillages. Cette étape a donné naissance à la librairie MyBEM, entièrement programmée en Matlab et optimisée par vectorisation. De plus, une nouvelle méthode rapide intitulée "Décomposition Creuse en Sinus Cardinal" ("Sparse Cardinal Sine Decomposition") a été implémentée en lieu et place des classiques méthodes multipolaires FMM (e.g. [31], [34], [35], [38], [82]). 89Figure 3.1 – Résumé de la méthodologie envisagée pour la création de HRTF numériques individualisées. Diagramme issu du projet de thèse initial, entre mathématiques appliquées et acoustique. 903. Validation par tests perceptifs des HRTF issues des simulations numériques sur les maillages individuels, en utilisant le moteur binaural PifPaf3D pour le rendu audio. Cette étape n’a pas été réalisée pendant la thèse et fera l’objet de recherches ultérieures. 1 Une revue théorique des équations intégrales fait donc l’objet de la première partie de ce chapitre, adjointe à l’introduction de la méthode multipolaire rapide (Fast Multipole Method). Dans une seconde partie, la nouvelle méthode rapide SCSD est présentée, non pas de façon théorique, mais en suivant les différentes étapes du raisonnement qui ont menées vers le formalisme final. Une présentation moins empirique, établie en parallèle de la rédaction de ce manuscrit, est disponible dans l’article [5] joint en annexe. La réalisation pratique au sein de la librairie MyBEM, développée conjointement avec F. Alouges, est quant à elle présentée dans le chapitre suivant. 3.1 Représentation et équations intégrales Il existe différentes méthodes pour la modélisation numérique des phé- nomènes de propagation d’ondes, classés parmi les problèmes hyperboliques linéaires. En effet, la linéarité permet un traitement de la variable temps par transformée de Fourier, ce qui autorise une formulation en temps comme en fréquence. Dans le cas de l’acoustique fréquentielle, le problème de diffraction résultant peut être écrit sous une forme intégrale, puis discrétisé par éléments finis de frontière. Cette section introduit donc quelques rappels classiques des équations intégrales sous forme variationnelle. Pour plus de précisions, le lecteur curieux peut se documenter sur les ouvrages suivants : [13], [16], [55], [69] et [82]. 3.1.1 Diffraction dans l’espace libre Les équations de l’acoustique s’obtiennent par linéarisation des équations d’Euler, caractérisant les fluides : – Conservation de la masse ; – Conservation de la quantité de mouvement ; – Conservation de l’entropie pour les fluides parfaits. 1. En complément, des itérations sur l’ensemble de ce processus sont envisagées pour obtenir une personnalisation optimale. En effet, il doit être possible d’exploiter les données issues des tests perceptifs pour guider la création des maillages de calcul, ainsi que pour définir les conditions aux limites du problème à résoudre. Cette piste fera très probablement l’objet de travaux futurs. 91En fixant c la vitesse du son dans un fluide au repos, la pression acoustique p vérifie l’équation des ondes scalaire : 1 c 2 ∂ 2 t p − ∆p = 0. (3.1) Pour que ce modèle conduise à un problème bien posé, il est nécessaire d’ajouter des conditions initiales à t = 0. Par ailleurs, comme l’équation des ondes scalaire (3.1) est linéaire, la transformée de Fourier en convention temporelle e iωt conduit à l’équation de Helmholtz scalaire : −∆u − ω 2 c 2 u = −∆u − k 2u = 0, (3.2) où k représente le nombre d’onde (rad.m−1 ) et u(ω) = p(ω), ω étant la pulsation (rad.s−1 ). Il existe certaines solutions non triviales à cette équation, mentionnées à toutes fins utiles : – Les ondes planes, dont le vecteur d’onde k, de module k, fixe la direction de propagation : u(x) = u0e −ik·x ∀x ∈ Ω, (3.3) – Les ondes sphériques : u(x) = u0 e ±ik|x| |x| ∀x ∈ Ω ∗ . (3.4) Enfin, pour que le problème fréquentiel (3.2) équivalent à la formulation temporelle (3.1) soit bien posé, il faut rajouter des conditions aux limites pour fixer le sens du temps et fermer le système. La condition de radiation de Sommerfeld (3.5), introduite à partir de considérations énergétiques, joue ce rôle en assurant l’unicité d’une solution : r (∂ru + iku) → 0 quand r = |x| → +∞. (3.5) Il est d’ores et déjà possible de constater que certaines solutions de l’équation de Helmholtz (3.2) ne respectent pas cette condition, à l’instar des ondes planes (3.3), dites non causales (ou non physiques). Pour résumer, un problème bien posé de diffraction dans l’espace libre s’écrit dans le cas général :    −∆u − k 2u = f, r (∂ru + iku) → 0 quand r → +∞. 92Figure 3.2 – Notations associées à la modélisation des phénomènes de propagation d’ondes. (source [82]) Pour f ≡ δy, ce système possède une solution élémentaire E ∈ D0 (R 3 ), au sens des distributions. Dans le cas tridimensionnel, le noyau (ou fonction) de Green G(x, y) est introduit à partir de E : G(x, y) = E(x − y) = e −ik|x−y| 4π|x − y| ∀(x, y) ∈ R 3 , (3.6) et permet d’établir l’expression de la solution générale u du problème, issue du produit de convolution ? suivant : u(x) = (E ? f)(x) = Z R3 G(x, y)f(y)dy = Z R3 e −ik|x−y| 4π|x − y| f(y)dy. (3.7) Pour que cette expression ait un sens, des restrictions sur f doivent être imposées avec, par exemple, f ∈ L 2 (R 3 ). 3.1.2 Diffraction en présence d’un obstacle Une surface fermée régulière et orientable Γ découpe désormais l’espace Ω en un ouvert borné Ω i et un ouvert non borné Ω e (fig. 3.2). La présence d’une telle frontière permet de définir deux distributions surfaciques, utilisées pour établir les résultats fondamentaux de ce chapitre : – Pour toute fonction λ régulière définie sur une surface Γ, la distribution de simple couche de densité λ sur Γ correspond à la mesure de Radon s(λ) = λ(x)dΓx telle que : hs(λ), φi = Z Γ λ(x)φ(x)dΓx ∀φ ∈ D(R 3 ). (3.8) 93– La distribution de double couche de densité µ, notée d(µ), est quant à elle définie par : hd(µ), φi = Z Γ µ(x)∂nφ(x)dΓx ∀φ ∈ D(R 3 ). (3.9) Ainsi, dans le cas particulier du rayonnement de sources réparties sur la surface Γ, le potentiel de simple couche Sλ peut être établi comme la solution u du problème de diffraction dans l’espace libre pour une distribution de simple couche s(λ) (3.8) :    −∆u − k 2u = s(λ), r (∂ru + iku) → 0 quand r → +∞. D’après la formulation générale des solutions de ce problème (3.7), Sλ s’écrit donc comme le produit de convolution : Sλ(x) = (E ? s(λ))(x) = Z Γ G(x, y)λ(y)dΓy ∀x ∈ R 3 , (3.10) et possède les propriétés suivantes : – Continuité dans R 3 ; – C ∞ en dehors de Γ ; – Solution de l’équation de Helmholtz homogène (3.2) en dehors de Γ ; – Vérifie la condition de radiation à l’infini de Sommerfeld. L’opérateur S associé est appelé "opérateur de simple couche" et sa restriction à la frontière Γ sera notée S. Au même titre, un opérateur dit de "double couche" D peut être appliqué à toute fonction régulière µ, définie sur Γ, pour former le potentiel de double couche suivant : Dµ(x) = (E ? d(µ))(x) = Z Γ ∂nyG(x, y)µ(y)dΓy ∀x ∈ R 3 , (3.11) où d(µ) est la distribution de double couche (3.9). Le potentiel de double couche Dµ possède les mêmes propriétés que celui de simple couche Sλ, mais présente une discontinuité sur R 3 par un saut de −µ à la traversée de Γ. La restriction de l’opérateur double couche D à la frontière Γ sera notée D. Les solutions u tot du problème de diffraction en présence d’un obstacle peuvent désormais être explicitées à partir de ces potentiels de rayonnement. En posant le champ diffracté u = u tot − u in comme la différence entre le champ total u tot et le champ incident u in , u est solution de l’équation de Helmholtz homogène (3.2), pour laquelle le théorème de représentation inté- grale s’applique. 94Théorème 1 (de représentation intégrale) Soit u une fonction régulière dé- finie de part et d’autre d’une frontière Γ régulière orientée. La restriction de u à Ω i est notée u i et la restriction à Ω e est notée u e . Les sauts de u et de sa dérivée normale ∂nu sont notés µ et λ : µ = [u] = u i − u e et λ = [∂nu] = ∂nu i − ∂nu e sur Γ. D’après la formule des sauts appliquée à la distribution {u}, définie par u en dehors de Γ : ∆{u} = {∆u} − s([∂nu]) + d([u]), si les hypothèses suivantes sont satisfaites :    −(∆u i + k 2u i ) = 0 dans D0 (Ωi ), −(∆u e + k 2u e ) = 0 dans D0 (Ωe ), r (∂ru e + ikue ) → 0 quand r → +∞, alors la fonction u vérifie : −(∆ + k 2 )u = s(λ) − d(µ) dans D 0 (R 3 ), ainsi que la condition de radiation à l’infini. u est donc la somme d’un potentiel de simple couche et d’un potentiel de double couche : u = E ? s(λ) − E ? d(µ), u = Sλ − Dµ dans D 0 (R 3 ). Plus précisément, les formulations de représentation intégrale suivantes peuvent être explicitées : u(x) = Sλ(x) − Dµ(x) ∀x ∈ Ω i ∪ Ω e , 1 2 (u i (x) + u e (x)) = Sλ(x) − Dµ(x) ∀x ∈ Γ, 1 2 (∂nu i (x) + ∂nu e (x)) = D ∗λ(x) − Hµ(x) ∀x ∈ Γ, où les opérateurs S, D, S et D sont tels qu’introduits dans (3.10) et (3.11). Les opérateurs D∗ et H (hypersingulier), sont respectivement obtenus par dérivation normale des opérateurs de simple et double couches S et D. Par ailleurs, dans le cas de singularités géométriques présentes sur une surface Γ lipschitzienne, les facteurs 1 2 doivent être remplacés par les rapports à 4π des limites des angles solides intérieurs et extérieurs. 953.1.3 Équations intégrales Le théorème de représentation intégrale 1 est la pierre angulaire des mé- thodes intégrales. Il peut élégamment s’écrire sous la forme d’opérateurs matriciels, appelés projecteurs de Calderón intérieur Ci et extérieur Ce. Théorème 2 (Projecteurs de Calderón) Soient λ et µ deux fonctions régulières quelconques définies sur Γ, alors la fonction u définie par u = Sλ−Dµ dans D0 (R 3 ) est solution de l’équation de Helmholtz dans Ω i ∪ Ω e et vérifie la condition de radiation à l’infini. De plus, les traces intérieures et extérieures de u et de sa dérivée normale sur Γ sont données par :   u i ∂nu i   = (Id 2 + C)   µ λ   = Ci   µ λ   ,   u e ∂nu e   = (− Id 2 + C)   µ λ   = Ce   µ λ   , où C est l’opérateur   −D S −H D∗   . De plus, les projecteurs Ce et Ci satisfont les relations suivantes : C 2 i = Ci , C2 e = Ce, Ci − Ce = Id, qui peuvent se réécrire à partir des opérateurs surfaciques usuels : DS = SD∗ , HD = D ∗H, D2 − SH = D ∗2 − HS = Id 4 . (3.12) Ces projecteurs confirment que les potentiels de simple et double couches sont définis partout et vérifient l’équation de Helmholtz en dehors de Γ, ainsi que la condition de radiation de Sommerfeld à l’infini. Cependant, afin de calculer explicitement la solution du problème de diffraction en présence d’un obstacle, il reste encore à déterminer les sauts µ et λ. Pour cela, des prolongements sur les traces intérieures et extérieures de u permettent d’établir des équations intégrales, définies sur la frontière Γ. Pour former un système bien posé, ces équations sont alors couplées à des conditions de bord, fixées par la modélisation physique de la structure diffractante. Trois types de condition de bord sont utilisés en pratique : 96– La condition de Dirichlet, pour les obstacles dits mous (ou soft) : u = uD régulière sur Γ; (3.13) – La condition de Neumann, pour les obstacles dits rigides (ou hard) : ∂nu = grad(u) · n = uN régulière sur Γ; (3.14) – La condition de Robin (ou Fourier), pour les obstacles d’impédance β : ∂nu − ikβu = uR régulière sur Γ. (3.15) Selon la modélisation physique souhaitée, il existe de nombreuses équations intégrales liées aux conditions de bord et au choix du prolongement des traces intérieures ou extérieures. Aussi, pour ne pas surcharger le manuscrit par de nombreuses formules, seuls les problèmes extérieurs de Dirichlet et Neumann sont détaillés. Dans le cas d’un problème de Dirichlet extérieur (3.13), la formulation bien posée est la suivante :    −(∆u e + k 2u e ) = 0 dans Ω e , u e = uD régulière sur Γ, r (∂ru e + ikue ) → 0 quand r → +∞, et selon le prolongement choisi pour la trace intérieure, cinq équations inté- grales peuvent être formulées en saut : Prolongement µ λ Dirichlet 0 Sλ = uD Neumann −(0.5Id + D)µ = uD 0 Zéro −uD Sλ = (0.5Id − D)uD Zéro (∂n) −uD (0.5Id + D∗ )λ = −HuD Robin, β ∈ C (ikβS − (0.5Id + D))µ = uD ikβµ Pour les quatre premières équations, le prolongement n’est pas unique si k 2 est une valeur propre du problème de Dirichlet intérieur relatif à l’opérateur −∆. L’opérateur associé à l’équation intégrale ne sera donc pas inversible pour ces fréquences propres. 97Dans le cas d’un problème de Neumann extérieur (3.14), la formulation bien posée s’écrit cette fois :    −(∆u e + k 2u e ) = 0 dans Ω e , ∂nu e = uN régulière sur Γ, r (∂ru e + ikue ) → 0 quand r → +∞, avec les équations intégrales associées : Prolongement µ λ Dirichlet 0 (−0.5Id + D∗ )λ = uN Neumann −Hµ = uN 0 Zéro −Hµ = (0.5Id + D∗ )uN −uN Zéro (trace) (0.5Id − D)µ = SuN −uN Robin, β ∈ C −(H + ikβ(0.5Id − D∗ ))µ = uN ikβµ Au même titre que pour le problème de Dirichlet, seule la dernière équation assure l’existence et l’unicité d’une solution pour toutes les fréquences. Une fois ces équations établies, il ne reste plus qu’à les résoudre numé- riquement pour obtenir les sauts µ et λ. En accord avec le théorème de représentation intégrale, la solution générale u pourra dès lors être calculée en tous points de l’espace, par rayonnement des potentiels de simple et double couches Sλ et Dµ. Pour mémoire, les opérateurs intégraux mis en jeu s’écrivent dans l’espace tridimensionnel : Sλ(x) = Z Γ G(x, y)λ(y)dΓy pour x ∈ R 3 \ Γ, (3.16) Dµ(x) = Z Γ ∂nyG(x, y)µ(y)dΓy pour x ∈ R 3 \ Γ, (3.17) Sλ(x) = Z Γ G(x, y)λ(y)dΓy pour x ∈ Γ, (3.18) Dµ(x) = Z Γ ∂nyG(x, y)µ(y)dΓy pour x ∈ Γ, (3.19) D ∗λ(x) = Z Γ ∂nxG(x, y)λ(y)dΓy pour x ∈ Γ, (3.20) Hµ(x) = Z Γ ∂ 2 nxyG(x, y)µ(y)dΓy pour x ∈ Γ, (3.21) où G(x, y) est le noyau de Green introduit en (3.6). De plus, en posant x = |x|ν = rν dans R 3 , à ces relations s’ajoutent les potentiels de champ 98lointain, obtenus par développement limité du noyau de Green pour |x|  |y| : Sλ(x) = e −ikr 4πr S ∞λ(ν) + O( 1 r 2 ) avec S ∞λ(ν) = Z Γ e ikν·yλ(y)dΓy, (3.22) et Dµ(x) = e −ikr 4πr D ∞µ(ν) + O( 1 r 2 ) avec D ∞µ(ν) = ik Z Γ (ny · ν)e ikν·yµ(y)dΓy. (3.23) Les opérateurs S ∞ et D∞ sont appelés "opérateurs de rayonnement à l’infini" et sont couramment utilisés pour représenter la radiation en champ lointain, sans tenir compte de la décroissance 1 r . 3.1.4 Formulations discrètes Le problème de Dirichlet extérieur prolongé par un problème de Dirichlet intérieur a été choisi pour établir une formulation discrète des équations inté- grales. À partir de cet exemple, la méthodologie peut aisément être reproduite pour obtenir les formulations d’autres problèmes. Aussi, pour toute fonction régulière f, l’équation intégrale à résoudre s’écrit : Sλ = f, Sλ(x) = Z Γ G(x, y)λ(y)dΓy = f(x) pour x ∈ Γ. Ce problème peut alors être formulé sous la forme variationnelle :    trouver λ ∈ V = H− 1 2 (Γ) tel que hSλ, λt i = hf, λt i ∀λ t ∈ V. Les méthodes par éléments finis de frontière consistent, en premier lieu, à approcher la surface Γ par un maillage élémentaire Th de taille h, composé par exemples de triangles Ti formant une discrétisation Γh de Γ. Ce maillage doit vérifier les propriétés classiques sur l’intersection de deux éléments, la qualité des éléments, etc. Dès lors, l’espace variationnel V peut être approché par un espace : Vh = {λh = λi sur le triangle Ti , Ti ∈ Th}, et la formulation variationnelle devient :    trouver λh ∈ Vh tel que hSλh, λt h i = hf, λt h i ∀λ t h ∈ Vh. 99Cette approximation, dite P 0 , est conforme et permet d’approcher λ par λh, constante par morceau. De plus, Vh est de dimension N égale au nombre de triangles de Th et sa base {φi , i = 1, · · · , N} s’exprime relativement simplement par : φi(x) =    1 sur le triangle Ti , 0 ailleurs. Une fois ce cadre formel établi, en posant Λ h les coordonnées de λh ∈ Vh dans la base {φi , i = 1, .., N} telles que : λh(x) = X N i=1 Λ h i φi(x), le problème discret équivalent à la formulation variationnelle approchée consiste en la résolution du système linéaire S hΛ h = F h . Chaque coefficient de la matrice S h est défini par : S h i,j = Z Ti Z Tj G(x, y)dTj (y)dTi(x) pour (i, j) ∈ {1, · · · , N} 2 , et le vecteur F h a pour coordonnées : F h i = Z Ti f(x)dTi(x). En supposant, d’une part, que k 2 n’est pas une valeur propre du problème de Dirichlet intérieur pour −∆, d’autre part, que le maillage est suffisamment fin pour que la base choisie puisse représenter correctement le problème, le système linéaire ainsi formé admet une unique solution Λ h . Dès lors, le champ approché uh de la solution du problème de diffraction u peut être calculé dans tout l’espace, par représentation intégrale des potentiels de simple et double couches approchés S hλh et Dhµh. Dans le cas d’un problème de Dirichlet extérieur prolongé par Dirichlet intérieur, µ = 0 et la représentation discrète s’écrit : uh(x) = Z Γh G(x, y)λh(y)dΓh(y) = X N j=1 Λ h j Z Tj G(x, y)dTj (y). Heuristiquement, pour obtenir des résultats raisonnables en approximation P 0 , il faut que la taille h des éléments soit au minimum inférieure au dixième de la longueur d’onde (donnée empirique). Un espace variationnel 100discret P 1 permet d’estimer λh par des fonctions de bases plus précises, linéaires par morceaux (fonctions chapeaux). Auquel cas, au prix d’une inté- gration locale plus fine, la taille h des éléments peut être seulement inférieure au sixième, voire au quart de la longueur d’onde. In fine, quelle que soit la dimension de l’espace d’approximation variationnelle, l’assemblage du système linéaire à résoudre est principalement fonction des interactions élémentaires dans Th, estimées numériquement par intégration de Gauss. En omettant les problèmes liés aux singularités des intégrales, ceci revient donc à calculer l’ensemble des interactions au sein d’un nuage de points, évaluées avec une complexité quadratique. C’est pourquoi le calcul rapide de ces interactions est un enjeu majeur pour la compétitivité des méthodes intégrales. 3.2 Introduction aux méthodes multipolaires rapides La méthode des multipoles rapides (Fast Multipole Method) a été introduite par L. Greengard et V. Rokhlin à la fin du XXe siècle [34], pour ramener la complexité des méthodes intégrales de quadratique (N2 ) à quasi-linéaire (N log N). Cet algorithme a littéralement bousculé les ordres de grandeurs des problèmes jusqu’alors résolus, et, pour cela, a été classé parmi les dix algorithmes majeurs du siècle dernier (source Wikipedia). Pour réaliser cette compression, le principe de base consiste à calculer des produits matricesvecteurs de manière économique, à la fois en mémoire vive et en charge de calcul. Seule une brève introduction est présentée dans ce manuscrit, essentiellement pour illustrer les concepts principaux mis en jeu. Pour de plus amples détails, de nombreux ouvrages de référence expliquent les fondements théoriques et pratiques de cette méthode (e.g. [35], [38], [82]). En méthodes intégrales, quelle que soit la formulation variationnelle et l’équation intégrale considérée, le produit matrice vecteur calculé dans la résolution d’un problème de diffraction se ramène toujours à la forme : Z Γh Z Γh G(x, y)f(x)g(y)dΓh(x)dΓh(y), avec f et g des fonctions scalaires. Hors singularités, les quadratures utilisées pour l’évaluation numérique des intégrales font généralement appel à des points de Gauss xg et yg, répartis sur la surface Γh. La formulation précédente peut donc être approchée par la discrétisation : X xg∈Γh X yg∈Γh G(xg, yg)f(xg)g(yg), (3.24) 101Figure 3.3 – Configuration type d’une répartition spatiale pour l’application du théorème d’addition de Gegenbauer. (source [82]) où les fonctions f et g incluent aussi les poids d’intégration des quadratures. L’idée générale de la FMM consiste à séparer les variables spatiales xg et yg, pour calculer indépendamment, donc rapidement, les deux sommes de la formulation (3.24) : X xg∈Γh   X yg∈Γh G(xg, yg)g(yg)   f(xg). (3.25) Pour cela, le noyau de Green est décomposé à l’aide du théorème suivant : Théorème 3 (d’addition de Gegenbauer) Soient x, y, M1 et M2 quatre points de l’espace, avec x "proche" de M1 et y "proche" de M2 (fig. 3.3). s est un point de la sphère unité S 2 dans R 3 , Pl le polynôme de Legendre de rang l et hl la fonction de Hankel sphérique du premier type de rang l. En posant le vecteur xy = xM1 + M1M2 + M2y, le noyau de Green G(x, y) peut se décomposer en : G(x, y) = ik 16π 2 lim L→+∞ Z s∈S2 e iks·xM1T L M1M2 (s)e iks·M2y ds, (3.26) avec T L M1M2 (s) = X L l=0 (2l + 1)i lhl(k|M1M2|)Pl(cos(s,M1M2)). Dans (3.26), les variables x et y sont bien séparées et les trois termes de l’intégrale sphérique peuvent s’interpréter comme suit : – e iks·xM1 transporte l’information du point source x au centre M1 ; – T L M1M2 (s) transfère l’information du centre M1 au centre M2 ; – e iks·M2y envoie l’information du centre M2 au point de destination y. 102Figure 3.4 – (Gauche) Traitement des interactions sans regroupement multipolaire. (Droite) Traitement des interactions en FMM. (source [82]) Ainsi, de par la centralisation des informations sur M1 et M2 due au théorème d’addition de Gegenbauer (3.26), le nombre d’interactions à calculer entre le nuage de points en x et celui en y diminue grandement entre la méthode classique et la méthode multipolaire (fig. 3.4). Il reste néanmoins à choisir une valeur de troncature pour L, ainsi qu’une quadrature sur la sphère unité S 2 , en fonction de la précision souhaitée pour l’évaluation des interactions ponctuelles entre les deux groupes de points. Cette étape, particulièrement délicate, est grandement liée à la "proximité" des objets mis en jeu dans la configuration type (fig. 3.3). Le domaine de calcul original Ω doit donc être découpé en sous-domaines, où la séparation des variables est valable lorsque les deux sous-domaines en interaction ne sont pas voisins. Si tel est le cas, le calcul de la double somme (3.24) sera traité classiquement, sans regroupement multipolaire. Dans l’exemple de gauche de la figure 3.5, les interactions entre C et C 0 peuvent être calculées par séparation des variables, centrées respectivement sur M et M0 . Ce découpage conduit à la formulation FMM mono-niveau du produit matrice-vecteur discret (3.24), entre C et C 0 : ik 16π 2 X xg∈C0 Z s∈S2     X yg∈C e iks·ygMf(yg)   T L MM0(s)e iks·M0xgds   g(xg). En considérant l’ensemble des interactions entre chaque sous-domaines, la complexité finale de l’algorithme mono-niveau est de l’ordre de N3/2 . Pour atteindre la limite N log N, les interactions multipolaires doivent être effectuées suivant un algorithme du type Divide and Conquer. Pour ce faire, des sous-domaines hiérarchiques sont construits à l’aide d’un octree (fig. 3.5 à droite), en vue de former par bloc le produit matrice vecteur associé au problème. Les interactions très lointaines seront, dès lors, traitées différemment des interactions lointaines, banlieues, proches, etc. Cette méthode, bien que robuste et bien maîtrisée, est relativement complexe, notamment dans sa programmation, et de nombreux détails soulèvent toujours de grandes diffi- cultés. Par ailleurs, bien que la complexité théorique de l’algorithme FMM 103Figure 3.5 – (Gauche) Découpage mono-niveau du domaine original Ω et de la frontière Γ en sous-domaines de calcul. (Droite) Découpage multi-niveaux. (source [82]) multi-niveaux ait pour limite N log N, la constante de cette complexité peut être assez lourde si l’algorithme n’est pas correctement réglé pour le problème à résoudre. Ces deux raisons ont poussé les recherches effectuées lors de cette thèse vers une solution alternative, la Décomposition Creuse en Sinus Cardinal (SCSD). 3.3 Nouvelle méthode rapide - SCSD La séparation des variables d’espace (3.25) conduit au calcul rapide des produits matrices-vecteurs (3.24), issus des équations intégrales. Dans le cas de l’acoustique tridimensionnelle, cet assemblage se résume à évaluer le produit de convolution (Gf )(xp), défini pour toute fonction régulière f par : (Gf )(xp) = X Ny q=1 G(xp, yq)f(yq) = X Ny q=1 e −ik|xp−yq| 4π|xp − yq| f(yq). (3.27) Ce résultat n’est pas sans rappeler la forme des solutions générales d’un problème de diffraction (3.7), construites par le produit de convolution ?. 1043.3.1 Vers un problème mono-dimensionnel Le fondement de la Décomposition Creuse en Sinus Cardinal (SCSD) réside dans la représentation intégrale de la fonction sinus cardinal [69] et [82]. Pour tout z dans R 3 : sin(k|z|) |z| = k 4π Z S2 e iks·z ds, (3.28) avec S 2 est la sphère unité de R 3 et k le nombre d’onde (positif). En posant |z| = |x − y|, la partie imaginaire du noyau de Green (3.6) peut s’écrire en variables séparées : sin(k|x − y|) 4π|x − y| = k (4π) 2 Z S2 e iks·(x−y) ds (3.29) = k (4π) 2 Z S2 e iks·x e −iks·y ds. Sous réserve d’une quadrature efficace pour la sphère unité S 2 , cette séparation des variables peut se substituer au théorème d’addition de Gegenbauer (3.26), dont dérivent la FMM. Par ailleurs, une intégration sur S 2 apparaît aussi dans (3.26), mais le couplage avec les fonctions de transfert T L M1M2 (s) complexifie grandement la tâche. Dans (3.29), ces fonctions de transfert ont disparu. Une transformée de Fourier en espace F[.] est appliquée sur l’équation élémentaire de Helmholtz, pour obtenir une représentation intégrale de la partie réelle du noyau de Green (3.6) : F h (−∆ − k 2 )G(x, y) i = F[δy]. En posant y = 0 dans l’égalité précédente, celle-ci devient : (|ξ| 2 − k 2 ) F[G(x, 0)] = 1, ce qui permet d’écrire la transformée de Fourier du cosinus cardinal : F " cos(k|x|) |x| # = 4π |ξ| 2 − k 2 . Une représentation intégrale de la partie réelle du noyau de Green est alors obtenue par transformée de Fourier inverse sur l’équation précédente : cos(k|x − y|) 4π|x − y| = 1 (2π) 3 Z R3 1 |ξ| 2 − k 2 e iξ·(x−y) dξ, 105amenant de nouveau la séparation des variables d’espace : cos(k|x − y|) 4π|x − y| = 1 (2π) 3 Z R3 1 |ξ| 2 − k 2 e iξ·x e −iξ·y dξ. (3.30) La singularité du cosinus cardinal présente en 0 lui confère une forte irré- gularité. Celle-ci est traduite en domaine de Fourier par une représentation intégrale sur tout l’espace R 3 , alors que la partie sinus s’intègre sur uniquement sur S 2 (eq. 3.29). À cela s’ajoute une singularité en |ξ| = k, ce qui peut sembler rédhibitoire. Néanmoins, après réécriture de l’équation (3.30) en coordonnées sphé- riques, la représentation intégrale du sinus cardinal (3.28) permet d’établir l’égalité suivante : cos(k|x − y|) 4π|x − y| = 1 (2π) 3 Z +∞ ρ=0 ρ 2 ρ 2 − k 2 Z S2 e iρs·(x−y) ds  dρ, = 2 π Z +∞ ρ=0 ρ ρ 2 − k 2 sin(ρ|x − y|) 4π|x − y| dρ. (3.31) Si l’intégrale sur ρ converge bien dans (3.31), alors une séparation des variables de la partie réelle pourrait découler de celle obtenue pour la partie imaginaire (3.29). De plus, pour éviter de retomber sur les difficultés de programmation de la FMM, il est nécessaire qu’une même quadrature, la plus précise possible, puisse être utilisée pour R dans un grand intervalle [Rmin, Rmax]. Pour étudier ce problème, l’intégrale (3.31) est réécrite sous la forme : cos(R) = 2 π Z +∞ ρ=0 ρ ρ 2 − 1 sin(ρR)dρ, (3.32) avec R = k|x − y|. 3.3.2 Résolution du problème Le problème d’intégration mono-dimensionnel à résoudre est le suivant : Existe-il une quadrature vérifiant l’égalité (3.32) pour tout R dans un intervalle [Rmin, Rmax] le plus grand possible, avec peu de points d’intégration ρ dans un intervalle [0, A] petit ? En première approche, des méthodes classiques de quadrature du type Trapèze, Simpson, ou encore Fourier ont été appliquées sur une formulation 106Figure 3.6 – Calcul du cosinus par intégration de Simpson, pour R dans [0, 15]. 71 points d’intégrations en ρ, espacés régulièrement sur [0, 7], ont été utilisés pour approcher l’intégrale (3.33). L’erreur relative est inférieure au seuil de 5% pour R > 3. tronquée en A et régularisée avec une solution analytique : cos(R) ≈ 2 π Z A ρ=0 ρ ρ 2 − 1 (sin(ρR) − sin(R))dρ! + 2 sin(R) π Z A ρ=0 ρ ρ 2 − 1 dρ. (3.33) Dans cette approximation, le membre de gauche est bien régulier pour ρ autour de 1 et le membre de droite s’intègre exactement au sens des valeurs principales. Les résultats présentés sur la figure 3.6 sont peu satisfaisants et dépendent beaucoup de l’intervalle dans lequel évolue R. Pour R petit, A est grand avec des points d’intégration relativement espacés, tandis que pour R grand, A est petit mais il faut de nombreuses valeurs pour discrétiser l’intervalle [0, A]. Ces résultats sont, bien entendu, liés à la singularité du cosinus, quand R tend vers 0. Une quadrature classique pour l’évaluation de cos(R) sur un intervalle [Rmin, Rmax] grand n’est donc pas raisonnable. Une quadrature entièrement numérique pour la résolution de ce problème a donc été envisagée. Pour ce faire, l’équation (3.32) est réécrite sous la formulation discrète suivante, tronquée en N ∈ N : cos(R) ≈ X N n=0 αn sin(ρnR). (3.34) Le problème d’intégration approchée à résoudre devient : 107Figure 3.7 – Calcul du cosinus par quadrature numérique issue d’une minimisation sous contrainte (3.35), pour R dans [0, 15]. 5 points d’intégrations en ρ, espacés régulièrement sur [0, 1.2], ont été trouvés pour évaluer l’approximation (3.34). L’erreur relative est inférieure au seuil de 5% pour R > 3. Pour N le plus petit possible, existe-il un vecteur (ρn)n∈[0,N] de petites valeurs, associées à un vecteur (αn)n∈[0,N], tels que la relation (3.34) soit vérifiée pour tout R dans un intervalle [Rmin, Rmax] le plus grand possible ? Comme il n’est pas évident de résoudre analytiquement cette question, une minimisation sous contrainte a d’abord été programmée pour tenter d’obtenir des éléments de réponses. Une discrétisation (Ri)i∈[0,M] de R dans [Rmin, Rmax] est utilisée pour former un système matriciel, dont chaque ligne i est définie par : (cos(Ri))i∈[0,M] = X N n=0 αn sin(ρnRi) ! i∈[0,M] . (3.35) Dans ce système linéaire, (αn)n∈[0,N] est le vecteur inconnu, recherché au sens des moindres carrés. Les contraintes sont fixées sur le calcul de (ρn)n∈[0,N] , discrétisé par pas régulier sur [0, A], avec A exigé le plus petit possible. De plus, à chaque itération de la minimisation, le rang du système linéaire est estimé avec une précision  donnée. Si ce rang n’est pas plein, l’ordre de troncature N est diminué pour assurer un nombre de termes minimal dans la quadrature. Ce procédé permet de tenir compte du défaut de rang constaté dans les opérateurs intégraux issus du noyau de Green (3.6) et exploité dans d’autres méthodes de compression comme H-matrix [43], GGQ [18], Skeletonization, ACA, etc. Cet algorithme a été développé en langage Matlab 108et la structure "optimset" a été utilisée pour établir la minimisation sous contraintes du système matriciel. La figure 3.7 donne un résultat issu de cette approche empirique, avec une configuration identique à l’intégration de Simpson précédente (fig. 3.6). Après convergence, 5 points en ρ ont été trouvés, compris entre 0 et 1.2. Ces valeurs apportent cette fois une solution tangible au problème mono- dimensionnel et le calcul d’un produit matricevecteur rapide peut être envisagé, pour toutes les interactions entre x et y telles que Rmin < k|x − y| < Rmax. Cependant, malgré une certaine robustesse éprouvée à l’usage, l’algorithme de minimisation sous contrainte ne permet pas de comprendre les mécanismes mis en jeu, ce qui a poussé les recherches vers une quadrature analytique. Celle-ci peut être introduite à partir de la quadrature de l’unité suivante : 1 ≈ X N n=0 βn sin(ρnR). (3.36) En effet, il existe une formule exacte similaire à l’approximation (3.36), définie pour tout t dans (0, π) : X∞ n=0 4 π(2n + 1) sin((2n + 1)t) = 1. Cette série, couramment utilisée en traitement du signal pour définir la fonction créneau, est issue de la décomposition en série de Fourier de la fonction 2π-périodique égale à −1 sur (−π, 0) et 1 sur (0, π). En posant le changement de variable t = R b π pour tout R dans (0, b), l’égalité précédente devient : X∞ n=0 4 π(2n + 1) sin  π b (2n + 1)R  = 1. La convergence de cette série est assez lente et dépend fortement des valeurs de R. Aussi, une troncature avec N petit conduit à de fortes oscillations aux extrémités de l’intervalle de R, dues à la discontinuité en zéro de la fonction créneau (phénomène de Gibbs). Cet artefact est classiquement lissé par l’introduction d’un facteur correctif de Lanczos, encore appelé σ-approximation (e.g. [1], [44]), qui consiste à pondérer la série précédente par une puissance de sinus cardinal : N X−1 n=0 4 π(2n + 1)  sinc  2n + 1 2N π q sin  π b (2n + 1)R  ≈ 1, avec q entier (typiquement q = 1 ou 2). En fixant dans (3.36) : βn = 4 π(2n + 1)  sinc  2n + 1 2N π q et ρn = π b (2n + 1), (3.37) 109Figure 3.8 – Calcul du cosinus par quadrature analytique issue des coeffi- cients exacts (3.37) de la quadrature de l’unité (3.36), avec q = 1 pour R dans [0, 15]. 6 points d’intégration en ρ, espacés régulièrement sur [0, 1.4], sont nécessaires pour une erreur relative inférieure à 5%. une quadrature analytique de l’unité avec une bonne convergence est ainsi établie. Une quadrature analytique du cosinus (3.34) peut être déduite en multipliant (3.36) par cos(R), puis en appliquant la formule trigonométrique sin(A) cos(B) = 0.5(sin(A + B) + sin(A − B)) : cos(R) ≈ X N n=0 0.5βn (sin((1 + ρn)R) − sin((1 − ρn)R)), (3.38) où les ρn sont donnés par (3.37). Enfin, lorsque b = 2πL avec L ∈ N ∗ , la variante (3.38) se décompose sous la forme : cos(R) ≈ X N n=0 0.5βn (sin((1 + ρn)R)) − L X−1 n=0 0.5βn (sin((1 − ρn)R)) + X N n=L−1 0.5βn (sin((ρn − 1)R)), où tous les facteurs devant R appartiennent à la même discrétisation de ρ dans l’intervalle [ρ0; 1 + ρN ]. Ainsi, après réagencement et unification des termes de cette nouvelle série, la quadrature analytique du cosinus (3.34) peut être obtenue à partir de celle de l’unité (3.36). En pratique, pour tout R dans [Rmin, Rmax] ⊂ [Rmin, b], il suffit de rechercher N tel que l’erreur relative  de cette quadrature soit inférieure à une précision fixée. Par ailleurs, pour 110limiter l’impact du phénomène de Gibbs et minimiser N, il est avantageux de symétriser l’erreur commise en posant b ≥ (Rmax+Rmin), multiple de 2π. La figure 3.8 offre une comparaison de la quadrature analytique avec les deux quadratures précédentes (fig. 3.6 et 3.7). Même si ce résultat est du même ordre de grandeur que celui de la figure 3.7, les valeurs de ρn et N sont légèrement supérieures à celles obtenues par l’algorithme de minimisation sous contraintes. Cette remarque est d’autant plus vraie pour b plus grand, non représenté ici. Aussi, une quadrature hybride a été développée à partir des deux quadratures précédentes. Comme les valeurs analytiques de ρn sont connues pour tout n ≤ N (eq. 3.37), celles-ci peuvent directement être utilisées dans la quadrature du cosinus (3.34) pour former le système matriciel (3.35), utilisé par l’algorithme de minimisation sous contrainte. Après résolution, les valeurs calculées de αn lissent au sens des moindres carrés l’erreur relative , pour tout R sur l’intervalle de quadrature [Rmin, Rmax]. En itérant ce processus sur N pour atteindre une précision donnée, cette approche permet d’estimer αn pour que l’erreur commise soit plus uniforme. Par ailleurs, suivant le même principe, il est possible d’estimer βn par une quadrature hybride de l’unité et d’obtenir une nouvelle quadrature du cosinus en utilisant la formule de passage (3.38). Trois méthodes peuvent donc être confrontées (fig. 3.9) : 1. Quadrature analytique du cosinus, d’après une quadrature analytique de l’unité lissée par σ-approximation avec q = 2 ("Analytique", courbe bleue) ; 2. Quadrature analytique du cosinus, d’après une quadrature hybride de l’unité lissée au sens des moindres carrés ("Hybride Un", ronds verts) ; 3. Quadrature numérique du cosinus lissée au sens des moindres carrés. ("Hybride Cos", croix rouges). cos(R) Rmin Rmax N ρN erreur L 2 erreur L ∞ 1. Analytique 3 15 14 4.5 2.26e −4 7.83e −4 2. Hybride Un 3 15 14 4.5 1.83e −6 5.27e −6 3. Hybride Cos 3 15 14 4.5 7.91e −8 1.91e −7 Pour R dans [Rmin, Rmax] et ρ dans [ρ0, ρN ] avec N fixé, il apparaît très nettement sur ces valeurs numériques et sur la figure 3.9 que l’évaluation de αn par ces trois méthodes fournit des erreurs relatives et uniformes singulièrement différentes. En effet, plus d’un facteur 1000 sépare la quadrature analytique de la quadrature hybride en cosinus. Aussi, en fixant un seuil d’erreur relative ∞ à 10−3 (norme L ∞) pour R ∈ [Rmin, Rmax], puis en minimisant le 111Figure 3.9 – Quadratures de l’unité et du cosinus pour R dans [3, 15], avec respectivement 11 et 14 points d’intégrations fixés, inclus dans [0, 3.5] et [0, 4.5]. L’erreur relative (∞ en norme L ∞) en fonction de R est donnée en échelle logarithmique pour une meilleure lisibilité. 112Figure 3.10 – Quadratures de l’unité et du cosinus pour R dans [3, 15], avec un seuil d’erreur relative ∞ fixée à 1e−3. Le nombre de points d’intégration N varie en fonction de la quadrature. 113nombre N de points d’intégrations nécessaires pour atteindre cette précision, les résultats suivants sont obtenus (fig. 3.10) : cos(R) Rmin Rmax N ρN erreur L 2 erreur L ∞ 1. Analytique 3 15 14 4.5 2.26e −4 7.83e −4 2. Hybride Un 3 15 10 3.17 1.95e −4 5.62e −4 3. Hybride Cos 3 15 8 2.5 1.40e −4 3.47e −4 Pour une précision fixée, les valeurs de N et ρN sont fortement liées à la quadrature considérée, ce qui est particulièrement intéressant dans le contexte de cette étude. Par exemple, la quadrature hybride en cosinus semble tout à fait adaptée pour répondre au problème mono-dimensionnel posé dans cette section. Au vu de ces résultats, l’intervalle [Rmin, Rmax] et la précision relative en norme L ∞ ont donc été modifiés, pour éprouver la robustesse des quadratures (fig. 3.11) : Cosinus Rmin Rmax N ρN erreur L 2 erreur L ∞ 1. Analytique 3 150 115 4.58 7.05e −5 9.65e −4 2. Hybride Un 3 150 80 3.18 1.11e −4 9.41e −4 3. Hybride Cos 3 150 61 2.42 1.13e −4 9.98e −4 1. Analytique 3 1000 734 4.58 2.81e −5 9.97e −4 2. Hybride Un 3 1000 510 3.18 4.68e −5 9.97e −4 3. Hybride Cos 3 1000 392 2.45 5.02e −5 9.95e −4 1. Analytique 0.5 150 436 4.58 5.92e −5 8.85e −4 2. Hybride Un 0.5 150 281 3.18 6.06e −5 6.89e −4 3. Hybride Cos 0.5 150 259 2.45 9.09e −5 9.93e −4 1. Analytique 3 150 - - - - 2. Hybride Un 3 150 213 8.5 1.16e −13 7.96e −13 3. Hybride Cos 3 150 189 4.4 1.62e −13 9.21e −13 Pour les quadratures hybrides de l’unité et du cosinus, la linéarité apparente 114Figure 3.11 – Représentation du nombre N de termes nécessaires à chaque quadrature. (Haut) Rmin dans [1, 3] et Rmax = 150, pour une précision relative fixée à 10−3 . (Milieu) Rmin = 3 et Rmax dans [10, 1000], pour une précision relative fixée à 10−3 . (Bas) [Rmin, Rmax] = [3, 150], pour une précision relative dans [10−13 , 10−2 ]. 115de l’ensemble des courbes de la figure 3.11 permet de conjecturer la relation : N ∝ Rmax + Rmin Rmin | log()|. (3.39) Une dépendance logarithmique en erreur relative est donc empiriquement établie, ainsi qu’une dépendance linéaire pour l’intervalle de R. Ce résultat est fondamental pour les applications visées. Il ne reste plus qu’à savoir si la linéarité de la conjecture (3.39) sur N va permettre d’atteindre une complexité finale raisonnable pour le calcul rapide du noyau de Green. Pour terminer, non seulement il apparaît que l’efficacité d’une quadrature ne dépende que de αn, mais aussi N diminue lorsque le rapport entre l’erreur L 2 et l’erreur L ∞ tend vers 1. Les trois méthodes proposées ne seraient donc peut-être pas les seules et de nouveaux algorithmes pourraient être recherchés en vue de diminuer N, ce qui aurait un impact très fort sur l’efficacité globale de la méthode SCSD. 3.3.3 Formalisme final pour l’équation de Helmholtz Pour une précision  donnée, la section précédente a mis numériquement en lumière qu’il existe deux suites (αn)n∈[0,N] et (ρn)n∈[0,N] telles que, pour tout R dans [Rmin, Rmax] : cos(R) ≈ X N n=0 αnsin(ρnR) avec N ∝ Rmax + Rmin Rmin | log()|. Le retour vers le problème tri-dimensionnel original s’effectue simplement à travers la définition de R, à savoir R = k|x − y| pour tous points x et y de l’espace R 3 . En divisant la relation précédente par 4π|x − y|, la partie réelle du noyau de Green (3.6) peut être approchée par la quadrature suivante : cos(k|x − y|) 4π|x − y| ≈ X N n=0 αn sin(ρnk|x − y|) 4π|x − y| , équivalent discret de (3.31). En ajoutant à cette relation la partie imaginaire du noyau de Green, la quadrature complète du noyau peut être établie, sous la forme d’une somme pondérée de sinus cardinaux : G(x, y) ≈ N X +1 n=0 αn sin(ρnk|x − y|) 4π|x − y| , où αN+1 = −i et ρN+1 = 1. En appliquant la représentation intégrale du sinus cardinal (3.28) sur ce résultat fondamental, la séparation des variables 116de la SCSD peut être formulée comme une somme pondérée d’intégrales surfaciques sur N + 2 sphères unités : G(x, y) ≈ k (4π) 2 N X +1 n=0 αnρn Z S2 e ikρns·x e −ikρns·y ds, (3.40) ou encore sur des sphères emboîtées de rayon kρn : G(x, y) ≈ 1 (4π) 2 N X +1 n=0 αn Z kρnS2 e is·x e −is·y ds. Pour obtenir une version totalement discrète de la séparation des variables du noyau de Green (3.40), il reste à choisir une dernière quadrature pour l’intégration sphérique. De nombreux travaux traitent de ce sujet récurrent et certaines solutions sont couramment utilisées dans divers domaines des mathématiques appliquées [46]. Pour la SCSD, les quadratures de GaussLegendre ont été préférées aux grilles de Fibonacci [41], ou encore aux sphères de Lebedev [60]. Quadrature de Gauss-Legendre sur la sphère unité S 2 : Pour un entier Na donné, les angles azimutaux (θi)i∈[1,2Na] sont choisis dans {0, π Na , ..., 2π − π Na }, tandis que les angles d’élévations (φj )j∈[1,Na] sont tels que cos(φj ) appartient aux zéros du Nième a polynôme de Legendre PNa . Une grille sphérique (si,j )i×j∈[1,Ns] de dimension Ns = 2N2 a peut alors être générée en (θ, φ), associée aux poids d’intégrations ωs. Cette quadrature intègre exactement toutes les harmoniques sphériques Y m l (1.2) de degré inférieur ou égal à 2Na − 1, mais discrétise la sphère par pas régulier en azimut, ce qui créé une concentration de points élevée aux pôles. En pratique, la quadrature de Gauss-Legendre dans l’approximation (3.40) est telle que Na doit être au moins proportionnel à la plus grande distance évaluée sous l’intégrale, c’est-à-dire : Na ∝ kρn max(|x − y|) ⇒ Ns ∝ (ρnRmax) 2 . (3.41) L’approximation (3.40) conduit alors à : G(x, y) ≈ k (4π) 2 N X +1 n=0 αnρn X Ns s ωse ikρns·x e −ikρns·y . Puis, pour tout l dans [1, Nξ] tel que Nξ = PN+1 n=0 Ns, en posant : ξl = kρns dans R 3 et ωl = kαnρnωs (4π) 2 dans R, (3.42) 117Figure 3.12 – Représentation du nombre total de points Nξ d’une quadrature SCSD, pour le noyau de Helmholtz (3.43). (Haut) Rmin dans [2, 3] et Rmax = 150, pour une précision relative fixée à 10−3 . (Milieu) Rmin = 3 et Rmax dans [10, 250], pour une précision relative fixée à 10−3 . (Bas) [Rmin, Rmax] = [3, 50] pour une précision relative dans [10−12 , 10−2 ]. 118la version discrète de la séparation des variables SCSD peut être établie : G(x, y) ≈ X Nξ l=1 ωle iξl ·x e −iξl ·y . (3.43) De plus, d’après les relations (3.37) et (3.41) : Ns ∝  Rmax Rmin + Rmax (2n + 1)2 . Dès lors, à partir de la conjecture (3.39) sur N, Nξ peut être estimé par une majoration de la somme des carrés impairs pour Rmax  Rmin : Nξ = N X +1 n=0 Ns ∝ Rmax Rmin | log()| 3 . (3.44) La figure 3.12 vient confirmer ce résultat, par l’apparente linéarité des fonctions représentées. La séparation des variables de la SCSD est donc logarithmique en erreur et le nombre de points total est simplement fonction du rapport des extremums Rmax sur Rmin, élevé au cube. Pour terminer, la quadrature en ξ (3.43) est directement injectée dans le produit de convolution initial (3.27) : Gf (xp) ≈ X Ny q=1 f(yq)   X Nξ l=1 ωle iξl ·xp e −iξl ·yq   , pour aboutir au calcul rapide par SCSD : Gf (xp) ≈ X Nξ l=1 e iξl ·xp   X Ny q=1 e −iξl ·yq f(yq)   ωl . (3.45) Ce résultat, fondateur de la méthode de Décomposition Creuse en Sinus Cardinal, est le pendant discret du théorème d’addition de Gegenbauer (3.26), qui conduit à la séparation des variables en FMM. En comparaison, cette formulation est bien moins complexe et le calcul des sommes du type : Xn q=0 e ±iap·bq h(bq) avec (ap, bq) ∈ R 3 , peut être réalisé par transformée de Fourier 3D rapide, non uniforme en espace/fréquence. Cet algorithme, plus connu sous le nom de Type-III Non Uniform Fast Fourier Transform (NUFFT), est notamment utilisé en traitement d’image et propose une complexité quasi-linéaire N log N (e.g. [24], [36], [61]). Un calcul de produit matrice-vecteur en SCSD (3.45) se résume donc à : 1191. Passer du domaine spatial (en y) vers le domaine de Fourier (en ξ), par NUFFT directe de type-III ; 2. Multiplier le résultat obtenu par les poids ωl , liés aux quadratures de la SCSD ; 3. Retourner dans l’espace (en x) par NUFFT inverse de type-III. In fine, comme le produit matrice-vecteur (3.27) est issu d’une convolution spatiale entre le noyau de Green G(x, y) et la fonction régulière f(y) (eq. 3.7), la SCSD reflète simplement l’idée qu’une telle convolution se traduit en domaine de Fourier par un produit. Toute l’originalité de la méthode ré- side finalement dans l’efficacité et la robustesse de la quadrature monodimensionnelle (3.34). 3.3.4 Extension vers Laplace (et plus si affinités...) Avant de poursuivre vers des résultats applicatifs, une légère digression mérite d’être faite pour les problèmes de Laplace, qui interviennent dans de nombreux domaines de la physique (Électrostatique, Magnétostatique, Gravitation, etc.). Introduite par l’équation : −∆u = f, avec f régulière sur R 3 , la solution générale d’un problème de Laplace est formée par interactions Coulombiennes : u(x) = ELap ? f(x) = Z R3 f(y) 4π|x − y| dy, dont la version discrète s’écrit : u(xp) = X Ny q=1 1 4π|xp − yq| f(yq). (3.46) Sensiblement proche des interactions helmholtziennes (3.27), seules les oscillations liées à l’exponentielle complexe n’apparaissent plus dans ce nouveau noyau de Green. Or, le problème mono-dimensionnel a été résolu à la fois pour la quadrature du cosinus (3.34) et pour celle de l’unité (3.36). En effet, les résultats précédents montrent bien que l’unité peut être approchée comme une somme pondérée de sinus, pour une précision donnée sur un intervalle [Rmin, Rmax]. Par conséquent, suivant le même raisonnement, les grandes étapes de la Dé- composition Creuse en Sinus Cardinal du noyau de Laplace sont données 120Figure 3.13 – Représentation du nombre total de points N0 ξ d’une quadrature CSD, pour le noyau de Laplace (3.48). (Haut) Rmin dans [2, 3] et Rmax = 150, pour une précision relative fixée à 10−3 . (Milieu) Rmin = 3 et Rmax dans [10, 250], pour une précision relative fixée à 10−3 . (Bas) [Rmin, Rmax] = [3, 50] pour une précision relative dans [10−12 , 10−2 ]. 121par : 1 4π|xp − yq| ≈ X N n=0 βn sin(ρn|xp − yq|) 4π|xp − yq| , ≈ 1 (4π) 2 X N n=0 βnρn Z S2 e iρns·xp e −iρns·yq ds, ≈ 1 (4π) 2 Nξ X0 l=1 ω 0 l e iξ0 l ·xp e −iξ0 l ·yq , avec ξ 0 l et ω 0 l similaires à ξl et ωl dans (3.42) : ξ 0 l = ρns dans R 3 et ω 0 l = βnρnωs (4π) 2 dans R. (3.47) Ce résultat offre donc une séparation des variables identique à l’équation (3.45) : u(xp) ≈ N0 X ξ l=1 e iξ0 l ·xp   X Ny q=1 e −iξ0 l ·yq f(yq)   ω 0 l , (3.48) où chaque somme peut être calculée rapidement par NUFFT de type III. L’étude détaillée des quadratures du noyau de Laplace n’est pas présentée ici, mais la figure 3.13 montre bien que la loi sur Nξ, établie pour Helmholtz (eq. 3.44), semble toujours vérifiée pour Laplace. De plus, l’article [5] disponible en annexe propose une revue théorique de la SCSD pour Laplace, étendue ensuite sur Helmholtz. Cet article fait donc office de référence en la matière et n’est donc pas repris dans ce manuscrit. Il est donc fondamental de remarquer qu’une même méthode générique peut-être appliquée à deux noyaux distincts, en vue de calculer rapidement des interactions ponctuelles, oscillantes ou non. Cette constatation s’étend aux noyaux de Stokes ou Maxwell, respectivement dérivés des noyaux de Laplace et d’Helmholtz, ou plus largement encore à tous noyaux de Green exprimés en domaine de Fourier. Par conséquent, la SCSD est intrinsèquement multi-physique, contrairement à la FMM, qui nécessite des développements propres à chaque noyau. À elle seule, cette remarque peut justifier l’intérêt des recherches effectuées sur cette nouvelle méthode. 1223.4 Comparaisons et performances Comme les produits de convolution par les noyaux de Green pour Helmholtz (3.27) et Laplace (3.46) sont tous deux définis par : Gp = X N q=1 G(xp, xq)fq ∀p ∈ [1, N], (3.49) un nuage de N points x est défini dans R 3 , associé à un vecteur (fq)q∈[1,N] de valeurs aléatoires complexes. Une routine Matlab a été programmée pour comparer l’évaluation du produit Gp (3.49) par différentes méthodes, dont la SCSD. Ce code n’est pas un solveur d’équations intégrales, mais un outil de validation analytique. La machine utilisée pour l’ensemble des tests de cette section est un PC portable disposant de 8 GO de mémoire vive et d’un processeur à 8 cœurs cadencés à 1.6 GHz. 3.4.1 Méthodologie En premier lieu, le nuage de N points x dans R 3 est créé suivant trois répartitions : – Aléatoire dans une boule ; – Aléatoire dans un cube ; – Uniforme sur une sphère. Chacune de ces répartitions est centrée en zéro, de sorte à maximiser par symétrie l’efficacité de la méthode SCSD. Pour assurer un régime fréquentiel adapté aux méthodes approchées, une normalisation sur la position des points x est effectuée : la plus grande distance au sein du nuage est imposée telle que Rmax = √3 N et le nombre d’onde k, intervenant dans le noyau de Green de Helmholtz (3.6), est fixé à 1. Une fois le domaine de calcul établi, la SCSD a été programmée en neuf grandes étapes, tirées des formulations du produit de convolution (3.49) pour Helmholtz (3.45) et Laplace (3.48) : 1. Quadrature hybride de l’unité ou du cosinus pour les interactions lointaines dans [Rmin, Rmax] ; 2. Quadrature des sphères d’intégrations et construction du domaine de Fourier en (ξl)l∈[1,Nξ] associé aux poids (ωl)l∈[1,Nξ] ; 3. NUFFT type-III directe de l’espace (xq)q∈[1,N] vers les fréquences (ξl)l∈[1,Nξ] , appliquée sur (fq)q∈[1,N] ; 4. Pondération du résultat précédent par les poids de quadrature (ωl)l∈[1,Nξ] ; 1235. NUFFT type-III inverse des fréquences (ξl)l∈[1,Nξ] vers l’espace (xp)p∈[1,N] , appliquée sur le résultat pondéré ; 6. Recherche des interactions proches, définies par |xp − xq| ≤ Rmin ; 7. Calcul du noyau de Green pour les interactions proches ; 8. Calcul de la partie réelle de la quadrature SCSD pour les interactions proches, inexacte, mais régulière sur [0, Rmin] ; 9. Addition des résultats issus des interactions proches et lointaines, puis soustraction des évaluations inexactes SCSD. Cet algorithme permet une implémentation vectorielle relativement simple. Aussi, toutes les routines ont été écrites nativement en Matlab, à l’exception de la NUFFT qui dispose de nombreuses versions .mex en accès libre sur internet (e.g. [93], [94], [95], [96], etc.). Après quelques tests comparatifs, celle proposée par L. Greengard [95] a été choisie, notamment pour sa rapidité, sa précision et sa simplicité d’utilisation. Pour valider les résultats issus de la SCSD, deux autres méthodes ont servi de référence au calcul du produit de convolution (3.49) : – La méthode directe, notée DM (exacte, complexité quadratique) ; – La méthode multipolaire rapide FMM (approchée, complexité quasilinéaire). Les deux routines utilisées sont issues d’une autre librairie Fortran écrite par L. Greengard, toujours interfacée Matlab, mais dédiée cette fois au calcul intégral [88]. Étant donné que L. Greengard est un pionnier de la FMM, les comparaisons avec cette librairie ont semblé toutes naturelles. Pour s’assurer du bon réglage de ces outils, la précision machine a été vérifiée sur des petits cas (N < 10000), en comparant les méthodes directe et rapide proposées par L. Greengard, avec un produit de convolution écrit nativement en Matlab. Afin d’être le plus objectif possible, le multi-threading a été désactivé pour les exécutions Matlab (options ’-singleCompThread’ au démarrage) et pour les bibliothèques externes (re-compilées sans OpenMP). Seul le parallélisme du calcul direct de la méthode exacte en Fortran a été conservé, afin de minimiser l’impact de la complexité quadratique sur les temps de calcul. 3.4.2 Résultats La figure 3.14 compare les temps de calcul de la convolution avec le noyau de Laplace, en fonction du nombre N de points dans l’espace. La précision des méthodes relatives est fixée à 10−3 et Rmin est fixé à 1. Tout d’abord, il apparaît que la méthode directe présente bien des temps de calcul supérieurs, ce qui est attendu. Ensuite, les temps d’assemblage FMM et SCSD sont 124Figure 3.14 – Temps totaux comparatifs pour la convolution (3.49) du noyau de Laplace, en fonction du nombre N de points x en interactions dans R 3 . La précision relative des méthodes approchées est fixée à 10−3 et Rmin = 1 pour la SCSD. 125comparables sur une boule, alors que la FMM est légèrement plus rapide pour le cube et bien plus rapide pour la sphère. Ceci peut s’expliquer par les fondements même de chaque méthode : – La SCSD est optimale pour les répartitions volumiques dans une boule. En effet, sa complexité est fonction de la quadrature en domaine de Fourier, dont le nombre de points Nξ est, dans ce cas, très proche de N (eq. 3.44 avec Rmin = 1 et Rmax = √3 N) ; – La FMM est plus adaptée aux répartitions volumiques dans un cube, de par le découpage de l’espace en octree. De plus, quelle que soit la répartition spatiale, sa complexité reste N log N. C’est pourquoi le cas sphérique n’est pas plus difficile en FMM. Par ailleurs, toutes les erreurs relatives finales obtenues entre méthode directe, FMM et SCSD sont de l’ordre de grandeur de la précision souhaitée (dans ce cas ≈ 10−3 ). Enfin, autant la pente de la méthode directe montre bien une complexité plus grande que les méthodes approchées, autant la SCSD et la FMM présentent la même linéarité, malgré quelques accrocs numériques inexpliqués. Ceci laisse penser que la complexité empirique de la SCSD pourrait être du même ordre que celle de la FMM, de mille à un million de points en interactions (soit mille milliards d’interactions calculées). De plus, en pré-calculant les interactions proches lors de calculs itératifs, le produit matrice-vecteur résultant (SCSD - MV, fig. 3.14) est quant à lui tout à fait compétitif avec la FMM. La figure 3.15 présente les mêmes courbes que la figure 3.14, mais pour une convolution avec le noyau oscillant de Helmholtz. La précision des méthodes relatives est toujours fixée à 10−3 , et Rmin à 1. Quelle que soit la répartition spatiale de x dans R 3 , il apparaît cette fois que la méthode SCSD est la plus rapide. De plus, les pentes des courbes des méthodes approchées montrent toujours une complexité empirique équivalente. Enfin, le pré-calcul des parties proches lors de résolutions itératives offre un produit matrice-vecteur particulièrement rapide. Pour terminer, la figure 3.16 donne les temps de calculs pour les convolutions de Laplace et Helmholtz sur une sphère, avec une précision fixée à 10−6 . Pour réaliser des calculs SCSD en accord avec la loi (3.44), Rmin a été augmenté et fixé arbitrairement à 3. Il apparaît de nouveau une grande similitude pour les divers temps de résolution, malgré une précision relative mille fois supérieure. Par conséquent, la SCSD montre en outre une certaine robustesse à la précision, comparable à celle de la FMM. En conclusion, la SCSD semble tout à fait comparable à la FMM, tant en terme de complexité que de précision. La plupart des résultats présentés a d’ailleurs été démontrée dans un article rédigé en parallèle de ce manuscrit, ce qui a permis de valider et maîtriser pleinement cette approche [5]. De plus, 126Figure 3.15 – Temps totaux comparatifs pour la convolution (3.49) du noyau de Helmholtz, en fonction du nombre N de points x en interactions dans R 3 . La précision relative des méthodes approchées est fixée à 10−3 et Rmin = 1 pour la SCSD. 127Figure 3.16 – Temps totaux comparatifs pour la convolution (3.49) des noyaux de Laplace (Haut) et Helmholtz (Bas), en fonction du nombre N de points x en interactions dans R 3 . La précision relative des méthodes approchées est fixée à 10−6 et Rmin = 3 pour la SCSD. 128de nombreuses optimisations mathématiques et algorithmiques sont encore envisageables (et envisagées) pour chacune des étapes de cette méthode (pré- calculs, parallélismes, amélioration des quadratures, etc.), ouvrant un large pan de recherche pour de futurs travaux. Par ailleurs, comme le même code Matlab a été utilisé pour calculer les produits de convolution (3.49) pour Laplace (3.48) et Helmholtz (3.45), ces optimisations impacteront directement toutes les physiques compatibles (gravitation, acoustique, électromagnétisme, mécanique des fluides, etc). C’est pourquoi cette méthode a d’ores et déjà été implémentée avec succès dans un moteur de calcul d’équations intégrales pour l’acoustique, présenté dans le dernier chapitre de ce manuscrit. 129130Chapitre 4 Moteur intégral MyBEM Une fois la SCSD validée pour le calcul des interactions au sein d’un nuage de points, elle fut aussitôt implémentée dans une nouvelle routine Matlab, qui assemble par collocation les opérateurs sphériques de simple couche (3.18) et de double couche (3.19). En estimant les interactions lointaines par le produit matrice-vecteur (3.45), des solutions tirées d’une résolution itérative sont obtenues, pour des problèmes de diffraction de 1 000 à 50 000 inconnues. Ces résultats furent alors confrontés aux solutions analytiques du rayonnement sphérique, avec succès. Ce principe montra de bonnes performances, mais il n’était pas possible d’aller plus loin sans une approximation de Galerkin bien établie. Il fut donc décidé d’implémenter la SCSD dans un vrai moteur de calcul intégral en éléments finis P 1 (MyBEM), dont le prototype est présenté dans ce dernier chapitre. Ce moteur a été développé en collaboration avec François Alouges à partir d’une librairie Matlab dont il est l’auteur, initialement conçue pour l’enseignement des éléments finis 2D. Ce co-développement a permis d’en étendre rapidement et très significativement la portée. 4.1 Présentation MyBEM est une librairie de calcul intégral par éléments finis de frontières, appliquée à l’acoustique tri-dimensionnelle et nativement écrite en langage Matlab. De nombreux services connexes y ont été associés, comme la gestion de maillage, le pré/post-traitement de données et la visualisation de résultats. De prime abord, le choix d’une implémentation Matlab peut surprendre au regard des performances exigibles en calcul numérique, mais cette plateforme fut initialement adoptée pour assurer un prototypage rapide et efficace. Au final, il aura fallu moins d’une année pour aboutir à la version présentée dans ce manuscrit. Par ailleurs, une vectorisation drastique de 131Figure 4.1 – MyUI, interface graphique de MyBEM, prototype Matlab pour le calcul intégral en acoustique tridimensionelle. 132l’ensemble des opérations a été effectuée, ceci afin d’assurer des performances comparables à celles obtenues par des langages de plus bas niveau. Enfin, la Parallel Computing Toolbox proposée par Mathwork a définitivement scellé ce choix, puisque les calculs les plus gourmands ont pu bénéficier d’un multithreading efficace, au prix d’un effort de développement réellement modique (remplacer les boucles "for" par "parfor"). En pratique, les temps de calcul sont en moyenne divisés par cinq sur une machine comptant huit cœurs. MyBEM est programmé dans une logique objet et les fonctions membres comme les attributs sont accessibles par appels directs, ou par interface graphique dédiée à l’utilisateur (MyUI, fig. 4.1). L’ensemble des données et des traitements est inclu dans six objets distincts, relatifs aux différentes étapes intervenant dans la résolution d’une formulation intégrale : 1. Mesh : Contient l’ensemble des données sur maillages, ainsi que les routines de lecture de fichiers .vtk, .ply, .mat, .mesh, etc. Toutes les données utiles (arêtes, normales, tangentes, surfaces, etc.) sont calculées par MyBEM, à partir des nœuds et des éléments. 2. Mef : Contient l’ensemble des données relatives à l’espace d’éléments finis des méthodes de Galerkin (degrés de liberté, fonctions de bases, formules d’intégrations, matrices d’intégrations de Gauss, etc.). Ces données sont automatiquement générées à partir des maillages et ne nécessitent, a priori, aucune intervention de la part de l’utilisateur. Dans sa version actuelle, MyBEM se limite aux formulations P 1 , avec les inconnues aux nœuds de mailles triangulaires. Des travaux sont en cours pour ajouter d’autres éléments finis. 3. Opr : Contient l’ensemble des données relatives aux opérateurs inté- graux usuels (eq. 3.16 à 3.23), ainsi que les différentes méthodes pour les assembler. En effet, MyBEM propose non seulement une construction matricielle classique par évaluation exacte des noyaux de Green, mais aussi des assemblages FMM et SCSD de produits matrices-vecteurs approchés (3.27). Dans tous les cas, les opérateurs sont construits à partir des interactions entre les points de Gauss des éléments finis, puis intégrés pour former le système final aux degrés de liberté. Par ailleurs, pour limiter les erreurs dues aux singularités, les intégrations proches sont régularisées analytiquement [77]. 4. Sol : Contient l’ensemble des données relatives à la modélisation mathé- matique du problème de diffraction, ainsi qu’à sa résolution. Les fonctions membres permettent à l’utilisateur de définir les sources [ondes planes (3.3) ou ondes sphériques (3.4)], les conditions de bord [Dirichlet (3.13) ou Neumann (3.14)] et le prolongement de la trace. Le système linéaire correspondant est ensuite établi, puis résolu de ma- 133nière directe ou itérative selon la méthode d’assemblage choisie pour former les opérateurs. De plus, pour accélérer les résolutions itératives, des préconditionneurs issus des identités de Calderón (3.12) sont couplés à la décomposition LU des interactions proches (e.g. [54], [79]). Les solutions alors obtenues sont rendues en saut, pour conserver le cadre généraliste des formulations indirectes. 5. Rad : Contient l’ensemble des services de post-traitement des résultats, notamment de rayonnement dans l’espace. Par exemple, des solutions peuvent être calculées sur le maillage surfacique initial, mais aussi sur un maillage volumique quelconque fourni par l’utilisateur, ainsi que dans toutes les directions d’un rayonnement infinitésimal. 6. Draw : Contient l’ensemble des outils de visualisation graphique, en domaine fréquentiel et temporel. Parmi l’ensemble des traitements proposés par MyBEM, trois librairies externes interfacées avec Matlab ont été utilisées : – FMM : Librairie Fortran de L. Greengard [88], pour le calcul de produits matrices-vecteurs approchés. La routine d’interaction ponctuelle hfmm3dpart de L. Greengard est couplée aux matrices d’intégrations de Galerkin calculées par MyBEM pour obtenir une formulation éléments finis P 1 . Cette librairie est utilisable pour les maillages conséquents, lorsque l’assemblage matriciel des opérateurs n’est plus envisageable. Elle est nativement parallèle. – NUFFT : Librairie Fortran de L. Greengard [95], pour le calcul de transformées de Fourier non uniformes, de une à trois dimensions. La routine nufft3d3 intervient dans la SCSD. Bien que déjà très performante, elle est néanmoins non parallèle, ce qui impacte les temps de calcul lors des résolutions itératives. De plus, de nombreux pré- calculs pourrait être réalisés, toujours en vue de minimiser les temps de chaque itération. C’est pourquoi le développement d’une nouvelle librairie NUFFT est actuellement envisagé. – OpenTSTOOL : Librairie C++ de C. Merkwirth [98], pour le calcul rapide de distances au sein d’un nuage de points. La routine range_ search est utilisée par la SCSD pour rechercher et calculer les interactions ponctuelles dont la distance est inférieure au rayon Rmin. Cette librairie n’est pas parallèle, mais son usage est très localisé donc peu impactant. Par ailleurs, la fonction rangeSearch est aussi proposée par MathWorks dans la Statistics Toolbox, mais celle-ci n’était pas à disposition lors de la création de MyBEM. 134Avant de clore cette brève présentation, il n’est pas inutile de préciser que l’interface graphique MyUI (fig. 4.1) interagit par callback avec chacune de ces structures. C’est pourquoi, les différentes étapes de résolution liées à ces objets ont été identifiées par couleurs : en bleu la gestion de maillage, en jaune la création des opérateurs, en rouge la résolution du problème et en vert le post-traitement. Seuls les éléments finis ne sont pas visibles, puisque leur paramétrisation n’est pas nécessaire et requiert une certaine expertise. 4.2 Validations Un protocole de validation analytique de la librairie MyBEM a été mis en place dès l’obtention des premiers résultats numériques. Celui-ci permet d’assurer le bien-fondé des solutions obtenues, ainsi qu’une assurance de nonrégression lors des fréquentes mises à jour. Lors de ces tests, les divers temps de calcul sont aussi comparés, ce qui permet l’élaboration d’algorithmes toujours plus rapides, avec une précision maîtrisée. Par ailleurs, des résultats similaires sont discutés dans [22] et peuvent être confrontés à ceux présentés ici. Enfin, tous les résultats de cette section ont été calculés sur une machine disposant de 8 cœurs cadencés à 3.3 Ghz, de 128 Go de mémoire vive et de la version R2013a de Matlab. Lorsqu’une onde plane (3.3) est diffractée par une sphère, des solutions explicites peuvent être calculées analytiquement à l’aide d’une décomposition en harmoniques sphériques [23]. En effet, pour des conditions de Dirichlet au bord de la sphère (3.13), le système :    −(∆u + k 2u) = 0 dans Ω e , u = uD = −e −ik·x sur S 2 , r (∂ru + iku) → 0 quand r → +∞, possède des solutions analytiques, données en coordonnées sphériques par : uref (r, θ, φ) = X∞ n=0 i n (2n + 1)κnh (2) n (kr)Pn(cos(γ)). (4.1) γ représente l’angle d’incidence avec la direction k de l’onde plane et la constante κn est définie par : κn = − jn(k) h (2) n (k) , (4.2) 135Figure 4.2 – Champ total issu de la diffraction d’une onde plane par une sphère unité, à la fréquence f = 300 Hz. Représentation en décibel (20 log |u|). (Haut) Solutions analytiques. (Bas) Solutions numériques calculées par MyBEM, pour une sphère à 1000 inconnues. (Gauche) Problème de Dirichlet. (Droite) Problème de Neumann. 136avec jn la fonction de Bessel sphérique et h (2) n la fonction de Hankel sphérique de seconde espèce. Cette solution décrit exactement l’évolution du champ diffracté pour tout r ≥ 1 et la série converge suffisamment rapidement pour être estimée avec une bonne précision. Par ailleurs, pour un problème de Neumann, le système :    −(∆u + k 2u) = 0 dans Ω e , ∂nu = uN = −∂ne −ik·x sur S 2 , r (∂ru + iku) → 0 quand r → +∞, a pour solution (4.1), avec une nouvelle constante κn : κn = − j 0 n (k) h (2)0 n (k) . (4.3) À titre d’exemple, des solutions analytiques de problèmes de diffraction sphé- riques de Dirichlet et Neumann ont été représentées en haut de la figure 4.2 (respectivement à gauche et à droite). Des solutions numériques issues de MyBEM, sur un maillage de sphère à 1000 inconnues, sont quant à elles visibles en bas de cette même figure. Toutes ces représentations sont données en décibel (20 log |u|). Même si les résultats concordent à première vue, la décroissance du rayonnement en 1 r complique l’utilisation d’une mesure objective de l’erreur commise dans l’espace. C’est pourquoi la solution en champ lointain, indépendante de la distance r, a été préférentiellement choisie : u ∞ ref (θ, φ) = i k X∞ n=0 (−1)n (2n + 1)κnPn(cos(γ)). (4.4) Comme cette solution est symétrique par rapport à l’incidence k, l’évaluation pour γ dans [0, 2π] est suffisante, voire préférable pour la lisibilité des résultats. Par ailleurs, l’équivalent numérique de (4.4), noté u ∞, est donné par le rayonnement des potentiels de champ lointain (3.22) et (3.23). Ce rayonnement a donc été ajouté dans les fonctionnalités proposées par MyBEM, avec une évaluation rapide par NUFFT type-III. L’analyse des résultats est réalisée à la fois par superposition graphique des deux solutions et par l’intermédiaire des normes quadratiques et infinies du rapport signal sur bruit 137(Signal/ Noise Ratio), définies par : SNR2 = vuuut 1 Nγ X γi∈[1,Nγ] 20 log 10      u∞(γi) u∞ ref (γi)      !2 , (4.5) SNR∞ = max γi∈[1,Nγ]      20 log 10      u ∞(γi) u∞ ref (γi)      !     . (4.6) Les résultats de validation présentés dans les différents tableaux de la figure 4.3 ont été obtenus en utilisant les formulations Brackage-Warner des problèmes de Dirichlet et Neumann préconditionnés. Ce choix découle essentiellement de la forme bien posée issue du prolongement de Robin, qui assure l’existence et l’unicité de la solution quelque soit la fréquence. Les différentes méthodes d’assemblage proposées dans MyBEM sont comparées (BEM, FMM et SCSD), en précision (SNR2 et SNR∞), mais aussi en temps d’assemblage des parties proches (tpsP ) et temps de résolution (tpsR). Le nombre d’itérations des résolutions approchées est précisé (Niter), ce qui donne une estimation du temps passé dans un produit matrice-vecteur. Pour tous les problèmes étudiés, les sphères unités sont maillées à l’aide de grilles uniformes de Fibonacci, de 103 à 106 points. Étant donné que MyBEM est programmé en formulation variationnelle approchée par éléments finis de frontière P 1 , les N inconnues correspondent exactement aux sommets du maillage. Par ailleurs, comme 3 points de Gauss ont été utilisés par élé- ments, le calcul des interactions ponctuelles pour l’assemblage des différents opérateurs a donc lieu entre les 6N points de gauss. De plus, pour qu’une longueur d’onde soit représentée au minimum par 6 inconnues, la fréquence f a été ajustée pour chaque grille, en fonction de la taille de la plus grande arête amax (kamax ≈ 1). Enfin, la précision des méthodes approchées a été fixée à 10−3 , au même titre que celle du solveur GMRES [76] utilisé pour les résolutions itératives de la FMM et de la SCSD. En complément de ces données, les figure 4.4 et 4.5 offrent une représentation graphique des rayonnements analytiques u ∞ ref , superposés aux solutions numériques u ∞ obtenues par SCSD. Il apparaît d’une part que les rapports signal sur bruit (SNR) sont stables, et montrent une grande précision pour tous les résultats. En effet, l’écart entre les solutions numériques et analytiques sont de l’ordre de 10−2 dB en norme quadratique et 10−1 dB en norme infinie. Ces performances se retrouvent dans les représentations graphiques des figures 4.4 et 4.5, puisque les solutions numériques et analytiques sont trait sur trait, en échelle logarithmique (dB). Les temps de calcul totaux, somme des temps d’assemblage des parties proches tpsP et des temps de résolution tpsR, sont 138DIRICHLET BEM FMM SCSD N f (Hz) krmax SNR2 SNR∞ SNR2 SNR∞ SNR2 SNR∞ 103 300 5 0.017 0.032 0.033 0.067 0.016 0.032 104 1000 19 0.002 0.008 0.017 0.060 0.009 0.024 105 3200 118 - - 0.011 0.039 0.019 0.073 106 10000 368 - - 0.021 0.120 0.014 0.090 NEUMANN BEM FMM SCSD N f (Hz) krmax SNR2 SNR∞ SNR2 SNR∞ SNR2 SNR∞ 103 300 5 0.050 0.161 0.052 0.159 0.047 0.158 104 1000 19 0.021 0.134 0.026 0.201 0.019 0.179 105 3200 118 - - 0.015 0.093 0.017 0.110 106 10000 368 - - 0.025 0.214 0.013 0.061 DIRICHLET BEM FMM SCSD N f (Hz) krmax tpsP tpsR tpsP tpsR Niter tpsP tpsR Niter 103 300 5 1.78 0.13 0.74 1.02 5 0.96 0.71 5 104 1000 19 140 22.4 3.21 12.5 7 4.49 3.58 7 105 3200 118 - - 23.4 174 9 56.7 39.1 9 106 10000 368 - - 235 2460 12 782 618 12 NEUMANN BEM FMM SCSD N f (Hz) krmax tpsP tpsR tpsP tpsR Niter tpsP tpsR Niter 103 300 5 1.78 0.13 0.74 2.83 5 0.96 0.84 5 104 1000 19 140 24.2 3.21 34.8 6 4.49 4.59 6 105 3200 118 - - 23.4 479 7 56.7 47.0 7 106 10000 368 - - 235 6324 9 782 740 9 Figure 4.3 – Tableaux comparatifs de la précision et des temps de calculs de MyBEM pour un problème de diffraction sphérique de 103 à 106 inconnues. Tous les temps sont donnés en secondes et les SNR sont données en décibel (20 log |u|). 139Figure 4.4 – Représentations en décibel des diagrammes de rayonnement en champs lointains des solutions analytiques (u ∞ ref ) et numériques, obtenues par MyBEM en SCSD (u ∞ SCSD). (Gauche) Problèmes de Dirichlet. (Droite) Problèmes de Neumann. 140Figure 4.5 – Représentations en décibel des diagrammes de rayonnement en champs lointains des solutions analytiques (u ∞ ref ) et numériques, obtenues par MyBEM en SCSD (u ∞ SCSD). (Haut) Problèmes de Dirichlet. (Bas) Problèmes de Neumann. 141favorables à la méthode SCSD. En effet, bien qu’assez performante dans son assemblage, la BEM ne peut pas résoudre des problèmes d’une taille supérieure à 25 000 inconnues, puisque le stockage mémoire des opérateurs explose de façon quadratique. D’autre part, la FMM est globalement moins rapide que la SCSD, à précision équivalente. Néanmoins, ces résultats sont à nuancer par les nombreuses différences intrinsèques aux deux algorithmes (niveau de langage, parallélisme de la FMM mais pas des NUFFT, accessibilité aux différentes étapes de construction, etc.), qui rendent hasardeuse toute conclusion objective. De nouvelles études sont donc à prévoir, ainsi que divers benchmark, mais il apparaît déjà que MyBEM, l’interface FMM de L. Greengard et la nouvelle méthode rapide SCSD semblent prometteurs pour réaliser du calcul intégral haute performance sous Matlab. 4.3 Applications au calcul de HRTF La validité des calculs de la librairie intégrale MyBEM étant désormais établie, des exemples d’applications plus concrètes sont présentés dans cette dernière section. Pour ne pas s’écarter du but initial, des simulations sur des maillages de têtes et d’oreilles ont été effectués. Néanmoins, par manque de temps, la construction d’une HRTF complète n’a pas encore été réalisée et fera l’objet de travaux futurs, en vue d’une confrontation finale aux mesures réelles. Dans un premier temps, des maillages de calcul ont été générés en trois étapes (fig. 4.6). Tout d’abord, un maillage initial d’une tête artificielle Neumann KU100 [91] a été réalisé par balayage optique, à l’aide de la Kinect [90] et du kit de développement Microsoft. Ce maillage n’étant pas utilisable en l’état (trous, intersections d’éléments, abérations géométriques, etc.), l’oreille gauche en a été extraite. Ensuite, un maillage paramétrique de "tête" a été créé sous Matlab, à partir d’une grille sphérique de Fibonacci, déformée en ovoïde. Pour finir, les deux maillages ont été fusionnés sous Matlab, puis corrigés et rééchantillonnés à l’aide d’outils comme MeshLab [92], Remesh [97], VTK [99], etc. Trois maillages de tête ont ainsi été générés, comptant respectivement 4 000, 15 000 et 50 000 sommets, pour des fréquences optimales de 5 000, 10 000 et 20 000 Hz. En complément, l’oreille tirée du maillage initial a été fermée par un demi-ovoïde, pour disposer d’un maillage d’étude de petite taille, fonctionnel sur toute la bande de fréquence audible. Ce dernier maillage ne comte que 6 000 sommets, ce qui autorise l’assemblage BEM exact avec résolution directe. À partir de ces maillages, une première application de MyBEM a consisté à calculer des modes de résonance du pavillon auditif, notamment pour tes- 142Figure 4.6 – Balayage de la tête artificielle Neumann KU100 par mesures optiques Kinect, et création de maillages de calcul. (Haut) Système de mesure de la tête Neumann et tête de Timothée. (Bas, gauche) Maillage obtenu avec le kit de développement Microsoft. (Bas, droite) Maillage final par fusion de l’oreille gauche sur un ovoïde. 143Figure 4.7 – (Gauche) Excitation par onde plane de l’oreille fermée. (Droite) Modes de résonances du pavillon obtenus par BEM. (Haut) 5 000 Hz. (Milieu) 10 000 Hz. (Bas) 20 000 Hz. 144Figure 4.8 – (Gauche) Modes de résonances du pavillon obtenus par FMM. (Droite) Modes obtenus par SCSD. (Haut) 5 000 Hz. (Milieu) 10 000 Hz. (Bas) 20 000 Hz. 145Figure 4.9 – Modes de résonance du pavillon avec diffraction par une tête ovoïdale. (Gauche) Assemblage BEM et FMM en bas. (Droite) Assemblage SCSD uniquement. (Haut) 5 000 Hz. (Milieu) 10 000 Hz. (Bas) 20 000 Hz. 146ter les trois méthodes d’assemblage (BEM, FMM et SCSD) sur un cas concret difficile. Pour chaque fréquence (5 000, 10 000 et 20 000 Hz), le problème de Neumann homogène a été résolu, modélisant mathématiquement la rigidité de la peau [50]. Les formulations en Brackage-Werner ont été choisies pour assurer l’existence et l’unicité de la solution, préconditionnées par identités de Calderón et décomposition LU, et toutes les précisions ont été fixée à 10−3 . Les solutions sont représentées sur les figures 4.7, 4.8 et 4.9, en décibel (20 log |u|), avec les temps suivants : OREILLE BEM FMM SCSD f (Hz) tpsP tpsR tpsP tpsR Niter tpsP tpsR Niter 5 000 58.0 7.10 2.34 41.6 14 5.75 5.80 14 10 000 56.5 7.26 2.42 44.7 15 5.95 5.55 15 20 000 57.2 7.07 2.36 52.4 17 5.73 6.17 17 TÊTE BEM FMM SCSD f (Hz) tpsP tpsR tpsP tpsR Niter tpsP tpsR Niter 5 000 19.6 2.45 1.84 17.5 8 5.00 2.49 8 10 000 454 77.8 5.28 101 12 15.4 10.9 12 20 000 - - 14.8 434 18 46.8 50.2 18 D’une part, pour un cas non trivial (résonances dans plusieurs cavités de tailles diverses), la concordance entre toutes ces figures montre bien que l’ensemble des méthodes d’assemblage implémentées dans MyBEM donnent des résultats tout à fait comparables. En considérant la BEM comme la référence (assemblage et résolution exacte), les méthodes approchées semblent donc relativement robustes. D’autre part, la SCSD montre des temps totaux plus rapides que les deux autres méthodes, pour un nombre d’itérations identique aux FMM. Pour terminer, un embryon de calcul HRTF a été pratiqué sur un maillage de tête réelle (fig. 4.10). Fourni par P. Frey [89], ce maillage présente 15 000 sommets et autorise les calculs jusqu’à 5 000 Hz. La méthode consiste à placer une source ponctuelle au creux du pavillon auditif (étoile cyan, fig. 4.10), puis résoudre le problème de Neumann homogène associé avant de faire rayonner les solutions obtenues sur la sphère unité (e.g. [49], [50], [39]). D’après le principe de réciprocité, les déformations spectrales causées par la morphologie sont alors bien prises en compte [87]. Pour valider la démarche, ce 147Figure 4.10 – Maillage de tête à 15 000 sommets, réalisé par P. Frey. (Gauche) Vue de face. (Droite) Vue de profil, avec une étoile bleue au creux de l’oreille droite, correspondant à la source ponctuelle pour le calcul de HRTF par réciprocité. problème a aussi été résolu sur un maillage sphérique de rayon a = 8.74 cm [58], avec une source ponctuelle placée à la surface en lieu et place de l’oreille droite. Comme il existe une solution analytique (eq. 1.5, [25]), les résultats numériques peuvent s’y référer. Pour ces derniers calculs, la formulation Brackage-Werner préconditionnée a de nouveau été utilisée et la précision fixée à 10−3 . Les figures 4.11 et 4.12 représentent en décibel les solutions obtenues par BEM, FMM et SCSD, à 1 mètre de distance et 5 000 Hz. Les temps de calcul sont résumés dans le tableau suivant : SPHÈRE TÊTE Méthode tpsP tpsR Niter tpsP tpsR Niter BEM 29.9 4.38 - 805 70.1 - FMM 1.28 18.4 6 8.24 85.6 11 SCSD 2.18 2.52 6 22.1 9.85 11 Tout d’abord, il apparaît que les rayonnements de la méthode exacte et des méthodes approchées sont bien concordants dans le cas sphérique, et ces résultats semblent coïncider avec le modèle de Duda (fig. 1.18). Néanmoins, il existe quelques écarts entre les méthodes approchées et la méthode exacte, visibles sur la tête réelle pour les gains relativement faibles (variations des échelles de couleurs). Ceci peut s’expliquer par la finesse de ce problème, à 148Figure 4.11 – HRTF sphérique du modèle de Duda de rayon 8.74 cm, calculée par MyBEM à 5 000 Hz, représentation en décibel sur la sphère unité. (Haut) Assemblage BEM. (Bas, gauche) Assemblage FMM. (Bas, droite) Assemblage SCSD. 149Figure 4.12 – HRTF du maillage de P. Frey calculée par MyBEM à 5 000 Hz, représentation en décibel sur la sphère unité. (Haut) Assemblage BEM. (Bas, gauche) Assemblage FMM. (Bas, droite) Assemblage SCSD. 150savoir le rayonnement en champ proche d’une source ponctuelle dans une cavité, où des différences minimes peuvent générer des perturbations consé- quentes. Mais vu l’ordre de grandeur relatif de ces écarts, il est possible qu’ils soient inaudibles. Aussi, ces calculs montrent que MyBEM est prêt pour la génération numérique de HRTF par méthodes intégrales, que ce soit en BEM, FMM ou SCSD. Pour générer une HRTF complète, il ne reste désormais plus qu’à boucler sur les fréquences, en raffinant éventuellement le maillage de calcul. 151DÉFI IDIOT MAIS RÉUSSI : " Salut tout le monde ! Je suis désormais en pleine phase de rédaction du manuscrit de thèse, c’est donc le moment de m’envoyer votre liste de mots à caser (en français). Le principe de ce jeu est le suivant, pour chaque mot soumis présent dans le manuscrit final, vous me payez une bière de votre choix. Si le mot est jugé de façon impartiale mal adapté au contexte, c’est moi qui régale... A vos plumes !" – ADRIEN : platokaolinophile. – ALAIN : zygomatique, xérodermie et yttrialite. – ANTOINE : lama. – BENJAMIN : courgette, pornographique. – CAROLINE A. : érythème, eczéma, petit-jama, cromalin. – CAROLINE F. : Tchoupi. – CLAIRE A. : coelioscopie. – CLAIRE Ette : formication et kyphonisme – EMILIE : on ne vit pas dans le monde de oui-oui ! ! – FRANCOIS : procrastination, turlututu, François Fromont. – FREDERIQUE : prurit. – GUILLAUME : canal de Nidus, rage quit, GG. – JULIE : priapisme. – SOPHIE : ratatouille, sapristouille. – STEPHANE : phugoïde. – STEVEN : swag, "c’est aussi rébarbatif que de placer une béchamel dans un micro-ondes soviétique pour la rendre déliquescente". – THIBAULT : 1=0 ; – TIMOTHÉE : censuré. – VICTOR : immixtion, cristallisation, Canaan, prophète, Hypokhâgne, Zoé, Django Reinhart, pronosthud. – VINCENT : soviétique, rébarbatif, déliquescent, micro-ondes, béchamel. – XAVIER : pachydermique. ATTENTION : L’auteur de ce manuscrit n’est en rien responsable du contenu de cette page et décline toute responsabilité quand au vocabulaire employé ici. 152Conclusion Pour conclure, l’ensemble des travaux présenté dans ce manuscrit offre des perspectives réellement prometteuses. D’une part, la Décomposition par Modèle Morphologique propose une nouvelle voie pour étudier les HRTF. Au lieu de construire des filtres basés sur des considérations arbitraires, des mesures réelles sont déconvoluées par des fonctions de transferts issues de modèles morphologiques paramétriques, obtenus analytiquement ou par simulation. Le résidu de cette décomposition peut alors être analysé, pour valider la bonne correspondance au modèle considéré. Cette démarche a prouvé son efficacité et de nombreuses applications industrielles en ont découlé (interpolation haute qualité, micro-variations de sources, déraffinement spatial de bases de données, individualisation des HRTF, etc.). D’autre part, la Décomposition Creuse en Sinus Cardinal permet la convolution rapide par un noyau de Green. Initiée par une démarche essentiellement expérimentale, une nouvelle théorie a vu le jour et les premiers tests de performances ont démontré l’efficacité de cette approche. Des développements logiciels ont toujours accompagné les problèmes rencontrés, pour mieux cerner les idées visibles, comme les subtilités cachées. Cette méthode de travail a engendré la création de prototypes innovants et fonctionnels, directement exploitables par le milieu industriel. Deux librairies indépendantes regroupent l’essentiel de ces codes. D’une part, PifPaf3D propose de nombreuses technologies pour la spatialisation sonore en temps réel, comme la synthèse binaurale, la captation-restitution en High Order Ambisonics, ou encore la réverbération de salles en trois dimensions. De multiples logiciels créés par la société Digital Media Solutions, à l’initiative de cette thèse CIFRE, en sont issus. D’autre part, MyBEM résout les équations intégrales de l’acoustique par éléments finis de frontières, incluant diverses méthodes d’assemblage et de résolution (BEM, FMM et SCSD). Ce code est aujourd’hui capable de traiter des problèmes de l’ordre du million d’inconnues relativement rapidement, avec une très bonne précision. Ainsi, tous les outils dédiés à l’individualisation numérique de la spatialisation sonore sont réalisés et fonctionnels. Il ne reste désormais plus qu’à 153générer des HRTF par équations intégrales pour "écouter" des mathématiques appliquées par synthèse binaurale. En effet, le formalisme de la Décomposition par Modèle Morphologique est particulièrement adapté au couplage entre les mesures réelles et les résultats de simulation numérique. Par ailleurs, d’autres applications, qui dépassent largement le cadre de cette thèse, sont aussi envisageables pour l’acoustique, comme la simulation numérique architecturale ou la détection sonar. Enfin, d’un point de vue mathématique, nous sommes persuadés que la SCSD a un potentiel qu’il faudra exploiter dans les années à venir. Par exemple, il est fortement envisagé de l’utiliser pour résoudre des problèmes de très grandes tailles par équations intégrales, dans des domaines aussi variés que l’acoustique, la gravitation, l’élasticité linéaire, l’électromagnétisme, la mécanique des fluides, etc. 154Bibliographie [1] Acton, F. S. (1990). Numerical methods that usually work. Washington, DC : Mathematical Association of America. [2] Allen, J. B., & Berkley, D. A. (1979). Image method for efficiently simulating small-room acoustics. The Journal of the Acoustical Society of America, 65(4), 943-950. [3] Algazi, V. R., Duda, R. O., Thompson, D. M., & Avendano, C. (2001). The cipic hrtf database. In Applications of Signal Processing to Audio and Acoustics, 2001 IEEE Workshop on the (pp. 99-102). [4] Algazi, V. R., Duda, R. O., Duraiswami, R., Gumerov, N. A., & Tang, Z. (2002). Approximating the head-related transfer function using simple geometric models of the head and torso. The Journal of the Acoustical Society of America, 112(5), 2053-2064. [5] Alouges, F., Aussal, M. (2014) The Sparse Cardinal Sine Decomposotion and its application for fast numerical convolution. [6] HRTF database from Acoustic Research Institute, www.kfs.oeaw.ac.at [7] Armelloni, E., Giottoli, C., & Farina, A. (2003, October). Implementation of real-time partitioned convolution on a DSP board. In Applications of Signal Processing to Audio and Acoustics, 2003 IEEE Workshop on. (pp. 71-74). [8] Aussal, M., Alouges, F., & Katz, B. F. (2012, March). ITD interpolation and personalization for binaural synthesis using spherical harmonics. In Audio engineering society UK conference. New York, UK (p. 04). [9] Aussal, M., Alouges, F., & Katz, B. (2013, June). A study of spherical harmonics interpolation for HRTF exchange. In Proceedings of Meetings on Acoustics (Vol. 19, No. 1, p. 050010). Acoustical Society of America. [10] Begault, D. R. (1994). 3-D sound for virtual reality and multimedia (Vol. 955). Boston etc : AP professional. [11] Bertet, S., Daniel, J., & Moreau, S. (2006, May). 3d sound field recording with higher order ambisonics-objective measurements and validation 155of spherical microphone. In Audio Engineering Society Convention 120. Audio Engineering Society. [12] Begault, D. R., Wenzel, E. M., & Anderson, M. R. (2001). Direct comparison of the impact of head tracking, reverberation, and individualized head-related transfer functions on the spatial perception of a virtual speech source. Journal of the Audio Engineering Society, 49(10), 904-916. [13] Bensoam, J. (2003). Représentation intégrale appliquée à la synthèse sonore par modélisation physique (Doctoral dissertation, PhD thesis, Université du Maine). [14] Blauert, J. (1994). La technologie binaurale : bases scientifiques et domaines d’application génériques. Le Journal de Physique IV, 4 (C5-11). [15] Blauert, J. (1997). Spatial hearing. [16] Bonnet, M. (1999). Boundary integral equation methods for solids and fluids. Meccanica, 34(4), 301-302. [17] Cheng, C. I., & Wakefield, G. H. (1999, September). Introduction to head-related transfer functions (HRTFs) : Representations of HRTFs in time, frequency, and space. In Audio Engineering Society Convention 107. Audio Engineering Society. [18] Chaillat, S., & Bonnet, M. (2014). A new Fast Multipole formulation for the elastodynamic half-space Green’s tensor. Journal of Computational Physics, 258, 787-808. [19] Craven, P. G., & Gerzon, M. A. (1977). U.S. Patent No. 4,042,779. Washington, DC : U.S. Patent and Trademark Office. [20] Daniel, J. (2000). Représentation de champs acoustiques, application à la transmission et à la reproduction de scènes sonores complexes dans un contexte multimédia (Doctoral dissertation, Ph. D. Thesis, University of Paris VI, France). [21] Daniel, J., Moreau, S., & Nicol, R. (2003, March). Further investigations of high-order ambisonics and wavefield synthesis for holophonic sound imaging. In Audio Engineering Society Convention 114. Audio Engineering Society. [22] Darbas, M., Darrigrand, E., & Lafranche, Y. (2013). Combining analytic preconditioner and fast multipole method for the 3-D Helmholtz equation. Journal of Computational Physics, 236, 289-316. [23] Durufle, M. (2006). Intégration numérique et éléments finis d’ordre élevé appliqués aux équations de Maxwell en régime harmonique (Doctoral dissertation, ENSTA ParisTech). 156[24] Dutt, A., & Rokhlin, V. (1993). Fast Fourier transforms for nonequispaced data. SIAM Journal on Scientific computing, 14(6), 1368-1393. [25] Duda, R. O., & Martens, W. L. (1998). Range dependence of the response of a spherical head model. The Journal of the Acoustical Society of America, 104(5), 3048-3058. [26] Duda, R. O., Avendano, C., & Algazi, V. R. (1999, March). An adaptable ellipsoidal head model for the interaural time difference. In Acoustics, Speech, and Signal Processing, 1999. Proceedings., 1999 IEEE International Conference on (Vol. 2, pp. 965-968). [27] Duraiswaini, R., Zotkin, D. N., & Gumerov, N. A. (2004, May). Interpolation and range extrapolation of HRTFs [head related transfer functions]. In Acoustics, Speech, and Signal Processing, 2004. Proceedings. (ICASSP’04). IEEE International Conference on (Vol. 4, pp. iv-45). [28] Evans, M. J., Angus, J. A., & Tew, A. I. (1998). Analyzing head-related transfer function measurements using surface spherical harmonics. The Journal of the Acoustical Society of America, 104(4), 2400-2411. [29] Farina, A. (2000, February). Simultaneous measurement of impulse response and distortion with a swept-sine technique. In Audio Engineering Society Convention 108. Audio Engineering Society. [30] Fiala, P., Huijssen, J., Pluymers, B., Hallez, R., & Desmet, W. (2010, September). Fast Multipole BEM modeling of head related transfer functions of a dummy head and torso. In ISMA 2010 Conference, Leuven, Belgium. [31] Fischer, M., Gauger, U., & Gaul, L. (2004). A multipole Galerkin boundary element method for acoustics. Engineering analysis with boundary elements, 28(2), 155-162. [32] Foster, S. (1986, April). Impulse response measurement using Golay codes. In Acoustics, Speech, and Signal Processing, IEEE International Conference on ICASSP’86. (Vol. 11, pp. 929-932). [33] Gerzon, M. A. (1985). Ambisonics in multichannel broadcasting and video. Journal of the Audio Engineering Society, 33(11), 859-871. [34] Greengard, L., & Rokhlin, V. (1987). A fast algorithm for particle simulations. Journal of computational physics, 73(2), 325-348. [35] Greengard, L. (1988). The rapid evaluation of potential fields in particle systems. MIT press. [36] Greengard, L., & Lee, J. Y. (2004). Accelerating the nonuniform fast Fourier transform. SIAM review, 46(3), 443-454. 157[37] Gumerov, N. A., Duraiswami, R., & Tang, Z. (2002, May). Numerical study of the influence of the torso on the HRTF. In Acoustics, Speech, and Signal Processing (ICASSP), 2002 IEEE International Conference on (Vol. 2, pp. II-1965). [38] Gumerov, N. A., & Duraiswami, R. (2005). Fast multipole methods for the Helmholtz equation in three dimensions. Elsevier. [39] Gumerov, N. A., O’Donovan, A. E., Duraiswami, R., & Zotkin, D. N. (2010). Computation of the head-related transfer function via the fast multipole accelerated boundary element method and its spherical harmonic representation. The Journal of the Acoustical Society of America, 127(1), 370-386. [40] M.A. Hamdi, An integral equation variational formulation for the resolution of the Helmholtz equation including mixed boundary conditions. Comptes Rendus de l’Académie des Sciences. Paris. 192 (1981) 17–20 [41] Hannay, J. H., & Nye, J. F. (2004). Fibonacci numerical integration on a sphere. Journal of Physics A : Mathematical and General, 37 (48), 11591. [42] Hamasaki, K., Hiyama, K., & Okumura, R. (2005, May). The 22.2 multichannel sound system and its application. In Audio Engineering Society Convention 118. Audio Engineering Society. [43] Hackbusch, W. (2009). Hierarchische matrizen. Algorithmen und AnalysisSpringer-Verlag, Berlin. [44] Hamming, R. (2012). Numerical methods for scientists and engineers. Courier Dover Publications. [45] Hartung, K., Braasch, J., & Sterbing, S. J. (1999, March). Comparison of different methods for the interpolation of head-related transfer functions. In Audio Engineering Society Conference : 16th International Conference : Spatial Sound Reproduction. Audio Engineering Society. [46] Hesse, K., Sloan, I. H., & Womersley, R. S. (2010). Numerical integration on the sphere. In Handbook of Geomathematics (pp. 1185-1219). Springer Berlin Heidelberg. [47] Hill, P. A., Nelson, P. A., Kirkeby, O., & Hamada, H. (2000). Resolution of front–back confusion in virtual acoustic imaging systems. The Journal of the Acoustical Society of America, 108(6), 2901-2910. [48] Jot, J. M. (1997, September). Efficient models for reverberation and distance rendering in computer music and virtual audio reality. In Proc. 1997 International Computer Music Conference. [49] Kahana, Y. (2000). Numerical modelling of the head-related transfer function (Doctoral dissertation, University of Southampton). 158[50] Katz, B. F. (2001). Boundary element method calculation of individual head-related transfer function. I. Rigid model calculation. The Journal of the Acoustical Society of America, 110(5), 2440-2448. [51] Kahana, Y., & Nelson, P. A. (2006). Numerical modelling of the spatial acoustic response of the human pinna. Journal of Sound and Vibration, 292 (1), 148-178. [52] Kahana, Y., & Nelson, P. A. (2007). Boundary element simulations of the transfer function of human heads and baffled pinnae using accurate geometric models. Journal of sound and vibration, 300(3), 552-579. [53] K-V. Nguyen, T. Carpentier, M. Noisternig, O. Warusfel, Calculation of the head related transfer function in the proximity region using spherical harmonics decomposition : comparison with measurements and evaluation. Proc. of the 2nd International Symposium on Ambisonics and Spherical Acoustics - Paris, 2010. [54] Kechroud, R., Soulaimani, A., Saad, Y., & Gowda, S. (2004). Preconditioning techniques for the solution of the Helmholtz equation by the finite element method. Mathematics and Computers in Simulation, 65(4), 303- 321. [55] Kirkup, S. (1998). The boundary element method in acoustics (Vol. 129). Heptonstall : Integrated sound software. [56] Kreuzer, W., Majdak, P., & Chen, Z. (2009). Fast multipole boundary element method to calculate head-related transfer functions for a wide frequency range. The Journal of the Acoustical Society of America, 126(3), 1280-1290. [57] Larcher, V., & Jot, J. M. (1997, April). Techniques d’interpolation de filtres audio-numériques, Application a la reproduction spatiale des sons sur écouteurs. In Proc. CFA : Congres Français d’Acoustique. [58] Larcher, V. (2001). Techniques de spatialisation des sons pour la réalité virtuelle (Doctoral dissertation). [59] Laborie, A., Bruno, R., & Montoya, S. (2003, March). A new comprehensive approach of surround sound recording. In Audio Engineering Society Convention 114. Audio Engineering Society. [60] Lebedev, V. I., & Laikov, D. N. (1999). A quadrature formula for the sphere of the 131st algebraic order of accuracy. In Doklady. Mathematics(Vol. 59, No. 3, pp. 477-481). MAIK Nauka/Interperiodica. [61] Lee, J. Y., & Greengard, L. (2005). The type 3 nonuniform FFT and its applications. Journal of Computational Physics, 206(1), 1-5. 159[62] HRTF database from listen project, www.recherche.ircam.fr/ equipes/salles/listen [63] Lokki, T., & Pätynen, J. (2011). Lateral reflections are favorable in concert halls due to binaural loudness. The Journal of the Acoustical Society of America, 130(5), EL345-EL351. [64] Majdak, P., Balazs, P., & Laback, B. (2007). Multiple exponential sweep method for fast measurement of head-related transfer functions. Journal of the Audio Engineering Society, 55(7/8), 623-637. [65] Majdak, P., Iwaya, Y., Carpentier, T., Nicol, R., Parmentier, M., Roginska, A., ... & Noisternig, M. (2013, May). Spatially Oriented Format for Acoustics : A Data Exchange Format Representing Head-Related Transfer Functions. In Audio Engineering Society Convention 134. Audio Engineering Society. [66] Messonnier, J. C., & Moraud, A. (2011, May). Auditory Distance Perception : Criteria and Listening Room. In Audio Engineering Society Convention 130. Audio Engineering Society. [67] Middlebrooks, J. C. (1999). Individual differences in external-ear transfer functions reduced by scaling in frequency. The Journal of the Acoustical Society of America, 106(3), 1480-1492. [68] Møller, H. (1992). Fundamentals of binaural technology. Applied acoustics, 36(3), 171-218. [69] J.C Nédélec, Acoustics ans Electromagnetic equations. Integral representations for harmonic problems. Applied Mathematics Science, 144, Springer Verlag, New-York (2001). [70] Nicol, R. (1999). Restitution sonore spatialisée sur une zone étendue : application à la téléprésence. PhD these, Université Du Maine, France. [71] Nicol, R., & Emerit, M. (1999, March). 3D-sound reproduction over an extensive listening area : A hybrid method derived from holophony and ambisonic. In Audio Engineering Society Conference : 16th International Conference : Spatial Sound Reproduction. Audio Engineering Society. [72] Otani, M., & Ise, S. (2003). A fast calculation method of the head-related transfer functions for multiple source points based on the boundary element method. Acoustical Science and Technology, 24(5), 259-266. [73] Pulkki, V. (1997). Virtual sound source positioning using vector base amplitude panning. Journal of the Audio Engineering Society, 45(6), 456- 466. [74] Rayleigh, L. (1907). XII. On our perception of sound direction. The London, Edinburgh, and Dublin Philosophical Magazine and Journal of Science, 13(74), 214-232. 160[75] Romblom, D., & Cook, B. (2008, October). Near-field compensation for HRTF processing. In Audio Engineering Society Convention 125. Audio Engineering Society. [76] Saad, Y., & Schultz, M. H. (1986). GMRES : A generalized minimal residual algorithm for solving nonsymmetric linear systems. SIAM Journal on scientific and statistical computing, 7(3), 856-869. [77] Salles, N. (2013). Calcul des singularités dans les méthodes d’équations intégrales variationnelles (Doctoral dissertation, Université Paris SudParis XI). [78] Shaw, E. A. G., & Teranishi, R. (1968). Sound Pressure Generated in an External-Ear Replica and Real Human Ears by a Nearby Point Source. The Journal of the Acoustical Society of America, 44(1), 240-249. [79] Steinbach, O., & Wendland, W. L. (1998). The construction of some efficient preconditioners in the boundary element method. Advances in Computational Mathematics, 9(1-2), 191-216. [80] Stan, G. B., Embrechts, J. J., & Archambeau, D. (2002). Comparison of different impulse response measurement techniques. Journal of the Audio Engineering Society, 50(4), 249-262. [81] Takemoto, H., Mokhtari, P., Kato, H., Nishimura, R., & Iida, K. (2010). A simple pinna model for generating head-related transfer functions in the median plane. Proc. 20th Int. Congr. Acoust.(ICA’10). [82] Terrasse, I., & Abboud, T. (2007). Modélisation des phénomenes de propagation d’ondes. (Modeling of wave propagation phenomena), Ecole Polytechnique. [83] Mercier, D. (2002). Le livre des techniques du son-Tome 1-3. Dunod. [84] Wightman, F. L., & Kistler, D. J. (1999). Resolution of front-back ambiguity in spatial hearing by listener and source movement. The Journal of the Acoustical Society of America, 105(5), 2841-2853. [85] Woodworth, R. S., & Schlosberg, H. (1962). Experimental psychology. Holt, Rinehart and Winston. [86] Zotkin, D. N., Hwang, J., Duraiswaini, R., & Davis, L. S. (2003, October). HRTF personalization using anthropometric measurements. In Applications of Signal Processing to Audio and Acoustics, 2003 IEEE Workshop on. (pp. 157-160). [87] Zotkin, D. N., Duraiswami, R., Grassi, E., & Gumerov, N. A. (2006). Fast head-related transfer function measurement via reciprocity. The Journal of the Acoustical Society of America, 120(4), 2202-2215. 161[88] Voir http ://www.cims.nyu.edu/cmcl/fmm3dlib/fmm3dlib.html [89] Voir https ://www.ljll.math.upmc.fr/frey [90] Voir http ://www.xbox.com/fr-FR/Kinect [91] Voir http ://www.neumann.com [92] Voir http ://meshlab.sourceforge.net [93] Voir http ://www.mathworks.com/matlabcentral/ fileexchange/25135- nufft–nfft–usfft [94] Voir http ://web.eecs.umich.edu/ fessler/code/index.html [95] Voir http ://www.cims.nyu.edu/cmcl/nufft/nufft.html [96] Voir http ://www-user.tu-chemnitz.de/ potts/nfft [97] Voir http ://remesh.sourceforge.net [98] Voir http ://www.physik3.gwdg.de/tstool [99] Voir http ://www.vtk.org 162Noname manuscript No. (will be inserted by the editor) The Sparse Cardinal Sine Decomposition and its application for fast numerical convolution Fran¸cois Alouges · Matthieu Aussal Received: date / Accepted: date Abstract Fast convolution algorithms on unstructured grids have become a well established subject. Algorithms such as Fast Miltipole Method (FMM), adaptive cross approximation (ACA) or H-matrices for instance are, by now, classical and reduce the complexity of the matrix-vector product from O(N2 ) to O(N log N) with a broad range of applications in e.g. electrostatics, magnetostatics, acoustics or electromagnetics. In this paper we describe a new algorithm of which we would like to explore the potential. Based on the Non Uniform FFT algorithm, it is at the same time simple, efficient and versatile. Keywords Quadrature · Non Uniform FFT · Fast convolution · Fast Multipole Method Mathematics Subject Classification (2000) 65T50 · 65Z05 1 Introduction In many areas of computational physics appears the problem of solving a PDE via the convolution of a distribution with an explicit Green kernel. This is for instance the case in electrostatics, magnetostatics or gravitation where a Coulombian interaction is used. In order to fix the ideas we set the problem as computing for N given punctual masses (fk){1≤k≤N} located at the points F. Alouges CMAP - Ecole Polytechnique, Route de Saclay, 91128, Palaiseau Cedex, France. Tel.: +33-1-69334631 Fax: +33-1-69334646 E-mail: francois.alouges@polytechnique.edu M. Aussal CMAP - Ecole Polytechnique, Route de Saclay, 91128, Palaiseau Cedex, France and Digital Media Solutions, 45 Grande All´ee du 12 F´evrier 1934, 77186 Noisiel, France. E-mail: matthieu.aussal@gmail.com2 Fran¸cois Alouges, Matthieu Aussal (xk){1≤k≤N} in ❘3 , the Coulombian potential at the same points defined by ∀k ∈ {1, · · · , N}, gk = X N l=1 fl 4π|xk − xl | . (1) The previous problem is easily solved with the O(N2 ) algorithm by computing straightforwardly the potential generated by each source at each target. However for big values of N (e.g. a million or a billion), the above formula is too slow to be used. Techniques already exist to speed up this computation, the most famous of which being certainly the FMM (for Fast Multipole Method) developed by Greengard and coauthors (see the seminal book [9] for instance). We hereafter would like to present a different method that is based on a sparse Fourier representation. 2 Principle of the method Introducing the N × N matrix A whose entries are Akl = 1 4π|xk−xl| , we recast the problem as storing A and computing the matrix-vector product G = AF , where G = (g1, · · · , gN ) t and F = (f1, · · · , fN ) t . A fast algorithm is at hand if we are able to write A as a sum of a small number of rank one matrices1 A = X n CnRn , where Cn and Rn are respectively column and row vectors of size N. Indeed, the matrix vector product is computed in this case as AF = X n CnRnF = X n Cn(R t n · F), (2) and each term in the sum is computed in O(N) operations. Notice that such a decomposition is formally given by writing the Fourier transform of the kernel 1 4π|x| in ❘3 F  1 4π|x|  = 1 |ξ| 2 . Indeed, this enables us to write 1 4π|x − y| = 1 (2π) 3 Z ❘3 e i(x−y)·ξ |ξ| 2 dξ , 1 This is by the way the basis of the principle of H−matrices, see [11].Title Suppressed Due to Excessive Length 3 while coming back to the problem (1), we deduce X N l=1 1 4π|xk − xl | fl = 1 (2π) 3 X N l=1 Z ❘3 e i(xk−xl)·ξ |ξ| 2 dξ fl = 1 (2π) 3 Z ❘3 e ixk·ξ   X N j=1 e −ixl·ξ |ξ| 2 fl   dξ. (3) This latter formula is exactly under the desired form (2) with Cξ = 1 (2π) 3 (e ix1·ξ , · · · , eixN ·ξ ) t and Rξ = (e −ix1·ξ , · · · , e−ixN ·ξ ) t |ξ| 2 , except that the finite sum indexed by n is now replaced by an integral over ξ ∈ ❘3 . We can thus produce a formula of the desired form if we can derive a quadrature formula that approximates the integral. For efficiency reasons, it is also desirable to have the smallest possible number of terms in this quadrature formula2 . In order to proceed, we pass in spherical coordinates, and further transform (3) into gk = X N l=1 1 4π|xk − xl | fl = 1 (2π) 3 Z +∞ 0 Z ❙2 e iλxk·ξ X N l=1 e −iλxl·ξ λ2 fl ! λ 2 dξ! dλ = 1 (2π) 3 Z +∞ 0 Z ❙2 e iλxk·ξ X N l=1 e −iλxl·ξ fl ! dξ! dλ. (4) The basis of our method thus consists in finding numerical quadratures for the integrals in λ and ξ. This would eventually permit us to approximate the above formula by X N l=1 1 4π|xk − xl | fl ∼ X S s=1 ωse iλsxk·ξs X N l=1 e −iλsxl·ξs fl ! = X S s=1 ωse ixk·ζs X N l=1 e −ixl·ζs fl ! , having set ζs = λsξs ∈ λs❙ 2 . Afterwards, the convolution can be done in two passes : • Compute ηs = PN l=1 e −ixl·ζs fl from the (fl)1≤l≤N for all 1 ≤ s ≤ S ; • Compute gk = PS s=1 e ixk·ζs (ωsηs) knowing the previously computed (ηs)1≤s≤S . 2 Notice that similar ideas are already used in [2] and [8], though in a different context.4 Fran¸cois Alouges, Matthieu Aussal Both steps can be realized using a (direct and inverse) type-3 Non Uniform FFT (NUFFT) algorithm [4, 15, 16]. We will be more explicit on this point later. Afterall, the method is not surprising and simply relies on the fact that a convolution is a product in Fourier space. The difficulty however stands in the fact that one needs, to make the method of practical use, a good quadrature which is both precise and efficient (i.e. that possesses a small number of points). It turns out that this is feasible to a very reasonable cost, and at the end gives a quite powerful numerical method that we have called Sparse Cardinal Sine Decomposition (SCSD). Maybe the originality of the present approach lies in the fact that, having written the integral in spherical coordinates permits us furthermore to decouple the approximation problem (in λ and ξ), and treat them separately. The aim of the paper is to give such a method and estimate its complexity through the following Proposition. Proposition 1 Assume that the original points are uniformly distributed in a ball then the SCSD algorithm has a global complexity which scales as O(N log N). If instead, the points are spread uniformly on a regular surface in ❘3 , then the complexity is O(N6/5 log N). The paper is divided as follows. Section 3 addresses the problem of finding a good quadrature in λ, by introducing a so-called sparse cardinal sine decomposition. Section 4 explain the spherical quadrature. Actually, a classical Gauss-Legendre quadrature is used whose parameters are thoroughly studied (see [10] for instance). Eventually Section 5 explains how to take into account the close interactions, while Section 6 details how to choose the parameters of the method. Other kernels are treated in Section 7 and numerical results are provided the last Section. In particular, we compare the timings obtained to compute the convolution using either a FMM routine provided by Leslie Greengard on CMCL website [18] or the abovementionned quadrature and NUFFT approach where the (type-3) NUFFT routine is also taken from the same website [17]. (Another implementation, which in particular uses the FFTW package, is also available in the NFFT project of D. Potts [19] but the type 3 NFFT does not yet have a Matlab interface.). 3 The Sparse Cardinal Sine Decomposition In order to decouple the problem in spherical coordinates we notice that the formula (4) can be rewritten under the form X N l=1 1 4π|xk − xl | fl = 1 (2π) 3 Z +∞ 0 X N l=1 Z ❙2 e iλxk·ξ (e