Royal Military Academy Brussels, BELGIUM Secure Information Storage in the Cloud

Transcription

1 Royal Military Academy Brussels, BELGIUM Secure Information Storage in the Cloud Thibault-Alexandre SWENNEN 2014

2 Préface Dans le cadre de la réalisation du mémoire de fin d'étude, parmi plusieurs sujets qui ont été proposés, celui au nom évocateur "Secure information storage in the cloud" a particulièrement attiré mon attention pour la raison suivante : Ce sujet rassemble plusieurs facettes qui, selon moi, prennent de plus en plus d'importance dans l'ère actuelle. La première facette a trait à l'utilisation de l'informatique dans l'administration de manière généralisée. Cette évolution me semble une étape non seulement utile mais indispensable pour continuer à garantir une efficacité minimum dans notre monde où tout va de plus en plus vite. Le développement de ce point de passage obligé est déjà bien présent de nos jours et se développera bien d avantage dans un avenir proche. La deuxième facette du sujet concerne la sécurité informatique. Cet aspect de l informatique fait de plus en plus parler de lui dans notre monde où tout est de plus en plus interconnecté au travers d internet qui reste accessible à tout un chacun. L'importance même de la sécurité informatique ne cesse donc de croître et plus particulièrement la sécurité liée à la confidentialité. Pour la réalisation de ce travail, j'ai pu compter sur l'aide inestimable de mon promoteur, le Capitaine d'aviation Thibault DEBATTY que je remercie beaucoup pour son aide et son appui. Je tiens également à remercier tous ceux qui ont, de près ou de loin, contribué à la réalisation de ce travail: mes parents, mes frères et sœurs ainsi que mes camarades de promotion. i

3 Table des matières Préface... i Table des matières...ii Liste des figures...iv Liste des abréviations... v Introduction Le Chiffrement Introduction Choix des méthodes de chiffrement des données Symétrie de chiffrement Chiffrement symétrique Chiffrement asymétrique Limitations de ces systèmes de chiffrement Le chiffrement homomorphique Introduction Sur le plan technique Conclusion intermédiaire Les recherches (queries) Déterminisme Chiffrement homomorphique Conclusion partielle Le projet THEP Introduction Aperçu général Création des clés Clé privée Clé publique Chiffrement Opérations mathématiques Déchiffrement Conclusion partielle Porticor Introduction Système de chiffrement utilisé Démonstration Conclusion partielle ii

4 4 Conclusion Recommandations Références Annexes Annexe1 :EncryptedInteger.class Annexe2 :PrivateKey.class Annexe 3: PublicKey Annexe 4: THEP.java Annexe 5: Mail de Porticor iii

5 Liste des figures Figure1: SubBytes ( 6 Figure 2: ShiftRows ( 6 Figure 3: MixColumns ( 7 Figure 4: AddRoundKey ( 7 Figure 5: clé privée et clé publique ( 8 Figure 6: Chiffrement asymétrique ( 9 Figure 7: Signature ( 10 Figure 8: Chiffrement non-déterministe ( 26 Figure 9: privkey Figure 10: PrivateKey Figure 11: Clé publique Figure 12: PublicKey Figure 13: Chiffrement Figure 14: Chiffrage de a et de b Figure 15: EncryptedInteger Figure 16: findrngcons Figure 17: findbicons Figure 18: set Figure 19: L'addition Figure 20: add Figure 21: La multiplication Figure 22: multiply Figure 23: Résultat du logiciel Figure 24: decrypt Figure 25: Porticor Virtual Key Management Service ( 45 Figure 26: La solution Porticor ( 47 Figure 27: Image OVA Figure 29: Ajout des disques durs Figure 28: Début avec VMWare Player Figure 30: Adresse IP du serveur web Figure 31: Login Figure 32: Informations supplémentaires Figure 33: Début du projet Porticor Figure 34: Master Key Figure 35: Porticor Project Setup Figure 36: Disques durs Figure 37: Type de stockage Figure 38: Titre Figure 39: Adresse du Cloud Figure 40: Premier dossier sur le Cloud iv

6 Liste des abréviations COTS AES XOR RSA PGCD FHE PPCM THEP FIPS SSL OSI AWS IP NFS iscsi Commercial of the Shelf Advanced Encryption Standard exclusive OR (ou exclusif) Ronald Rivest, Adi Shamir et Leonard Adleman Plus Grand Commun Dénominateur Fully Homomorphic Encryption Plus Petit Commun Multiple The Homomorphic Encryption Project Federal Information Processing Standards Secure Socket Layer Open Systems Interconnection Amazon Web Services Internet Protocol Network File System Internet Small Computer System Interface v

7 Introduction De nos jours, la Défense brasse une quantité énorme d informations. En effet, grâce aux nouvelles technologies telles que le "Link16" 1 déjà présent dans nos F-16 et qui permet l'échange de données tactiques, le soldat actuel a accès en tous lieux et en temps réel à des masses d informations dont celles indispensables à la réalisation de son métier. D un autre côté, la gestion administrative de l'armée se réalise en majeure partie de façon électronique avec, entre autre, les logiciels ILIAS et Harmony, ce qui a pour conséquence de générer également un flux gigantesque de données. Le stockage d informations, d informations sécurisées, est donc crucial pour une armée développée telle que la Défense belge. Le coût engendré par ce stockage est non-négligeable. En effet, il requiert une équipe de spécialistes pour mettre en place le système, l'entretenir, veiller à son bon fonctionnement, en faire des sauvegardes régulières, etc. Pour diminuer ce coût, de plus en plus d entreprises civiles se tournent vers le Cloud Computing pour le stockage de leurs données (certains exemples commerciaux sont, par ailleurs, déjà bien connus: DropBox, icloud, etc.). Le Cloud Computing consiste à stocker des informations et à utiliser les capacités de serveurs informatiques d'une firme civile au travers d'internet. A l'heure actuelle, la baisse des coûts informatiques liés à cette technologie pourrait bientôt atteindre 30 à 40 %[2]. La Défense a donc tout intérêt à évaluer le potentiel de cette technologie comme solution à long terme pour réduire ses frais de stockage. Mais l'utilisation de nouvelles technologies va de pair avec de nouveaux défis. Dans notre cas bien précis du Cloud Computing, le problème majeur reste celui de la sécurité de l information car, à l'heure actuelle, le Net est parcouru par une quantité indénombrable de pirates (de hackers) en tout genre: les ennemis avérés de la Défense Belge, ses ennemis potentiels tels que les Etats voyous (les fameux "rogue nations"[3]), ceux qui piratent par défis, etc. La liste des attaquants potentiels est très longue; il est donc nécessaire de mettre en place une protection complète et sûre pour ne pas laisser la porte ouverte aux dérives en tout genre. De plus, pour le cas précis de la Défense, le propriétaire du Cloud est également une personne contre laquelle il faut se protéger car, comme les autres citoyens ordinaires, elle ne doit pas avoir accès aux informations sensibles. 1 Le "Link16" est un standard de liaison de données tactiques de l'otan pour l'échange d'informations tactiques entre des unités militaires [1] 1

8 Ce travail a l ambition d'exposer au lecteur une petite facette de la sécurité de l information dans le domaine du Cloud Computing au travers d'un aspect théorique qui reprend les différentes méthodes de chiffrement actuelles ainsi que de nouvelles découvertes dans le domaine de la cryptographie (le chiffrement homomorphique) mais aussi au travers d'un aspect pratique avec l'implémentation concrète d'une solution discutée dans la première partie (ce fameux chiffrement homomorphique) et finalement à l'aide d'un exemple Commercial of the Shelf (COTS), c'est-à-dire grâce à une solution civile de Cloud chiffré. Le fil rouge de ces différents chapitres se situe dans la manière de protéger des données stockées dans un Cloud: le chiffrement. 2

9 1 Le Chiffrement 1.1 Introduction Pour contrer la menace que représentent les pirates du net, qu ils le fassent par jeu ou pour des raisons commerciales, politiques ou terroristes, une solution évidente apparaît : le chiffrement des données. En effet, rendre les données ou textes illisibles pour des tiers en les remplaçant par d autres caractères au moyen d un ou d une série de moyens techniques contrôlés par l auteur et mis à disposition du lecteur semble le moyen idéal de se protéger face à ces pirates. Lorsque les informations restent en local, c'est-à-dire qu'elles restent uniquement sur une seule machine (et ne voyagent donc pas sur le réseau), le chiffrement peut sembler superflu en raison des protections multiples habituelles des accès au système local mais lorsque les données sortent sur la toile même temporairement, le chiffrement prend tout son sens. La qualité du chiffrement qui se traduit par la difficulté de décoder son contenu est primordiale. L objet de ce présent chapitre est, dans une première partie, de présenter des solutions de chiffrement efficaces et plus particulièrement dans le cas de transfert d'instructions à un Cloud qui est un lieu virtuel de stockage de données sur le Net. Ces instructions sont typiquement des requêtes (GET, POST, etc.) vers les bases de données chiffrées contenues dans le Cloud ainsi que le rapatriement des réponses. Dans une deuxième partie, le problème des recherches d'information à l'intérieur des bases de données cryptées sera abordé. 3

10 1.2 Choix des méthodes de chiffrement des données Lorsque l'on place des données dans un Cloud, elles doivent pouvoir être manipulées. Pour cela, il faut que l'utilisateur émette des requêtes. La logique de requête traditionnelle à un Cloud nécessite plusieurs étapes: 1. Envoyer la requête au serveur Cloud pour qu'il l'exécute: a. Chiffrer la requête sur l'ordinateur du client (l'émetteur de la requête). b. Ensuite l'envoyer au serveur qui contient la base de données (le Cloud) au travers du réseau. c. Faire exécuter la requête par le serveur entre les étapes de déchiffrage de la requête et rechiffrage du résultat. 2. Récupérer les données chiffrées a. Le serveur envoie les données chiffrées correspondantes à la requête. b. Les données chiffrées sont déchiffrées sur la machine du client pour permettre leurs utilisations. Le problème majeur qui se pose est de trouver le/les moyens pour chiffrer la requête en local et faire en sorte qu'elle soit utilisable par le serveur. De plus, il apparaît déjà que l'exécution, dans le cas d'un système de chiffrement traditionnel, se fait sans protection dans le Cloud lui-même car la requête est en effet déchiffrée puis exécutée en clair donc sans codage. Ce qui représente évidemment un danger en terme de protection face au propriétaire physique du Cloud ou toute autre personne ayant réussit à en prendre le contrôle de manière licite ou illicite. Il existe, à ce jour, plusieurs solutions très différentes. Afin de les juger à leur juste valeur, certaines classifications seront faites. Dans un premier temps, la distinction entre un chiffrement symétrique et asymétrique pour des solutions traditionnelles sera abordée. Puis, dans un deuxièmes temps, le chiffrement homomorphique sera développé en tant que tel. 4

11 1.3 Symétrie de chiffrement Chiffrement symétrique Le chiffrement symétrique est une méthode de chiffrement "très ancienne" (1977 pour l'algorithme RSA [4] [5] [6]) qui consiste à chiffrer un message grâce à une clé, appelons la "A", de telle manière que ce message ne pourra être déchiffré que grâce à cette même clé "A" 2. Le concept de la clé est donc très important et ne s utilise qu avec un mécanisme qui, dans le chiffrage de données, est un algorithme. Plus précisément, une clé est donc une donnée qui, une fois insérée dans l'algorithme de chiffrage, permet de coder et de décoder un message. Cette fameuse clé est le point crucial du système symétrique car pour que le système soit sûr, il faut que l'algorithme soit disponible (publié ouvertement) et que la clé "résiste" à une attaque de "brute forcing", c'est-à-dire à un essai par approche systématique et exhaustive de toutes les clés possibles, de manière à ce que le temps de décodage soit trop long pour être efficace. C'est ce que l'on appelle la sécurité calculatoire. Malheureusement, cette sécurité calculatoire s'est affaiblie avec le développement constant des technologies et performances informatiques. Mais les techniques de chiffrement actuelles sont encore suffisamment sûres pour assurer une relative sécurité. Prenons l'exemple du chiffrement AES (Advanced Encryption Standard) [7], créé par deux concepteurs belges Joan Daemen et Vincent Rijmen, qui utilise des clés de 128 bits c'est à dire (2 ) é = (3, ) é Cet algorithme est considéré aujourd'hui comme relativement sûr: il existe certaines attaques possibles [8] mais elles restent complexes à mettre en place et demande énormément de temps L'algorithme AES Pour être plus précis, l'algorithme AES [9] consiste à exécuter un nombre n de fois le même processus composé des mêmes étapes. Dans le cas de l'algorithme AES, le nombre minimum d'itérations est de 10 (ce nombre d'itérations peut atteindre 14 moyennant une clé de base de 256 bits). 2 Dans certains cas, la clé peut ne pas être réellement présente: en effet, l'algorithme de chiffrement peut être la clé elle-même (tel que dans le ROT13). Ce cas simple ne sera pas traité dans ce travail. 5

12 La première itération démarre avec un bloc de données de 16 octets (c'est-à-dire de 128 bits), ce bloc sera nommé State, et une clé de 16 octets également. Les 16 octets du bloc de départ sont placés dans une matrice de 4x4 transformée à chaque itération conformément aux quatre étapes. éléments qui sera Etape 1 Dans un premier temps, les 16 octets vont être permutés grâce à une table définie au préalable (c'est l'étape dite "SubBytes" en anglais). Figure1: SubBytes ( Etape 2 Les lignes de cette matrice subissent dans un deuxième temps un décalage vers la gauche (l'incrément varie selon le numéro de la ligne), c'est l'étape "ShiftRows". Figure 2: ShiftRows ( 6

13 Etape 3 La troisième étape consiste en une transformation linéaire de la matrice. Pratiquement, une multiplication binaire va être effectuée entre la matrice de départ et une matrice auxiliaire (c(x)) selon certaines règles spéciales dites "des corps finis". C'est l'étape du "MixColumns". Figure 3: MixColumns ( Etape 4 La quatrième et dernière étape est une opération XOR (l'opération "ou exclusif") entre la dernière matrice obtenue et une sous-clé (étape "AddRoundKey). Cette sous-clé (la roundkey) est obtenue en effectuant l'opération XOR bit par bit entre la clé principale et le State. Figure 4: AddRoundKey ( 7

14 Avantages et inconvénients La plus grande faiblesse du chiffrement symétrique est sa clé. En effet, si un utilisateur A veut transmettre un message codé à l'utilisateur B, il doit forcément lui transmettre l'algorithme utilisé ainsi que la clé utilisée. Comme décrit précédemment, les algorithmes actuels sont suffisamment résistants pour affronter les attaques dites de "brute forcing". Ils ne sont donc pas la vraie source de la faiblesse de ce genre de chiffrement. Par contre, la transmission de la clé reste un problème récurrent. En effet, la clé doit absolument être transmise "en clair", c'est-à-dire que la clé doit être transmise de manière non chiffrée. Elle est donc fort vulnérable lors de ce type de transfert! De plus, pour augmenter la sécurité, la clé doit être changée régulièrement pour diminuer le risque de piratage ou pour limiter les effets d'un éventuel piratage réussit. Le principe du transfert d'une clé en "clair" au travers du Net implique qu'elle doit voyager sans protection ou protégée par d'autres moyens que le cryptage, ce qui augmente sensiblement la précarité de ce système de chiffrage symétrique. Heureusement ce défaut principal a été en grande partie corrigé grâce au chiffrement asymétrique Chiffrement asymétrique Le chiffrement asymétrique [10] [11], aussi appelé le chiffrement à clé publique, est une méthode de décodage qui se base sur l'utilisation de deux clés différentes: une clé publique et une clé privée. Le principe consiste en l'obligation, pour décoder un message chiffré grâce à la clé publique, d'utiliser la clé privée correspondante et vice-versa. Figure 5: clé privée et clé publique ( 8

15 Les clés publiques doivent être diffusées sur tout le réseau pour que tout le monde y ait accès tandis que les clés privées doivent être conservées uniquement en local. En effet, si les clés privées sont aussi diffusées (ne sont plus uniquement en local) ), le chiffrement ne sert à rien car les pirates ont accès aux deux clés et peuvent déchiffrer les messages. Ce principe élimine le plus grand inconvénient du chiffrement symétrique: le besoin de donner via le réseau la clé unique de chiffrement "en clair". Tandis que, dans le cas d'un chiffrement asymétrique, seule la clé publique transite sur le réseau (et y est accessiblee à tous) alors que la clé privée reste locale et ne voyage donc pas du tout sur le réseau. Ceci permet de garantir nettement plus de sécurité. Illustrons ce principe à l'aide d'un exemple [10] : Figure 6: Chiffrement asymétrique ( Soit un utilisateur A, Alice, souhaitant recevoir un message secret d'un utilisateur B, Bob, sur un canal susceptiblee d'être écouté par un utilisateur C, Caro. Alice va, dans un premier temps, générer deux clés: sa clé publique APublique et sa clé privée APrivée. Ensuite, elle va publier sa clé publique APublique sur le réseau de manière à ce que Bob ait accès à cette clé. Ce faisant, Caro aura aussi accès à cette clé publique. Dans un deuxième temps, Bob, récupère la clé publique d'alice APublique via le réseau, ensuite chiffre son message grâce à cette clé (APublique) puis le transmet sur le réseau. 9

16 La troisième et dernière étape consiste, pour Alice, à déchiffrer le message grâce à sa clé privée (APrivée) qu'elle seule possède. Figure 7: Signature ( L'utilisateur C, Caro, est donc incapable de déchiffrer le message codé par Bob même si elle parvient à l'intercepter. Il y a différentes applications possibles de ce genre de système de chiffrement. Un exemple des plus connus est sans nuls doutes celui de la signature. La problématique de ces communications de données sensibles se situe dans le fait que, lors du transfert d'informations, l'identité de l'expéditeur d'un message (un par exemple) peut être usurpée. Mais, grâce au chiffrement asymétrique, ceci peut être évité. En effet, dans la continuité de l'exemple précédent, imaginons qu'alice désire envoyer un message chiffré à Bob et ce dernier désirerait être certain qu'alice soit bien l'émettrice de ce message. Il suffit alors à Alice de chiffrer sa signature avec sa clé privée APrivée et, ensuite, de chiffrer tout le message avec la clé publique de Bob BPublique. Ainsi, à la réception, Bob pourra déchiffrer le message en utilisant sa clé privée BPrivée et il pourra également déchiffrer la signature d'alice grâce à la clé publique d'alice APublique. Or, comme un message chiffré par la clé privée d'alice peut être déchiffré uniquement avec la clé publique d'alice, Bob peut être sûr qu'il s'agit bien d'alice et non d'un usurpateur. Ce système est, entre autres, utilisé pour les signatures de payements bancaires au travers du Net. 10

17 Une troisième application de cette méthode de chiffrement est la non-répudiation d'un message: lorsque Bob reçoit un message signé d'alice, il est certain que ce message provient d'alice et que elle seule peut l'avoir envoyé. Alice ne peut donc pas nier être l'auteur de ce message, c'est la non-répudiation L'algorithme RSA L'algorithme de chiffrement RSA [4] [5] [6] (appelé d'après les noms de ses développeurs: Ronald Rivest, Adi Shamir et Leonard Adleman) est un algorithme très utilisé à l'heure actuelle pour la protection des données sur internet. C'est un chiffrement asymétrique dont les clés sont constituées uniquement de nombres premiers. Il s'appuie d'une part sur la congruence des nombres entiers (l'opération "modulo n") et d'autre part sur le petit théorème de Fermat qui peut s'énoncer comme suit: "Si p est un nombre premier et si a est un entier non divisible par p, alors (a p-1-1) est un multiple de p". En d'autres termes, si p est un nombre premier et a un entier non divisible par p, alors on a 1 = 0 ( ) Ce qui revient à dire que si p est un nombre premier et que a est un nombre quelconque, alors (a p-1-1) est un multiple de p. Une autre notion importante utilisée dans cet algorithme est la fonction mathématique appelée "indicatrice d'euler". Cette fonction mathématique couramment notée (!) associe à n le nombre d'entiers strictement positifs inférieurs ou égaux à n et premiers à n. De manière plus formelle, on peut écrire: N N! & ' (( ) N!, ',,' à!) La dernière notion mathématique utile à la compréhension de ce chiffrement est l'algorithme d'euclide étendu qui permet à partir de deux entiers a et b, de calculer non seulement leur plus grand commun diviseur (PGCD), mais aussi un de leurs couples de coefficients de Bézout (deux entiers x et y tels que a.x + b.y = PGCD(a, b)). Quand a et b sont premiers entre eux, x est alors l'inverse pour la multiplication de a modulo b (et y est de la même façon l'inverse modulaire de b, modulo a) [12]. 11

18 Pratiquement, l'utilisation de l'algorithme RSA passe par trois phases distinctes: La création des clés; Le chiffrement; Le décodage Création des clés La création de clés se fait en cinq étapes: 1. La première étape consiste à choisir deux nombres premiers distincts p et q. 2. Ensuite, il faut calculer n tel que:! = 0 3. Le troisième temps consiste à calculer l'indicatrice d'euler en n: (!) = ( 1). (0 1) 4. La quatrième et avant dernière étape consiste à choisir l'exposant de chiffrement. Ce nombre est un entier naturel e qui doit être premier avec (!) et strictement inférieur à (!). 5. La dernière étape est le calcul de d, l'exposant de déchiffrement. Ce d est l'inverse de (, (!)) et est strictement inférieur à (!). Ce nombre peut être calculé grâce à l'algorithme d'euclide étendu. Les clés peuvent enfin être exprimées: 2 & é 0, = (,,!) 2 & é ' 3é, = (,!) Illustrons ceci avec un exemple [13]: Prenons 2 nombres premiers au hasard: p = 29, q = 37 Alors, n = pq = 29 * 37 = 1073 Il faut choisir e au hasard tel que e n'ai aucun facteur en commun avec (p-1)(q-1): (p-1)(q-1) = (29-1)(37-1) =

19 Prenons, par exemple, e = 71 d est alors tel que (71 ) 1008 = 1 d = 1079 Les clés sont donc: La clé publique est (e,n) = (71,1073) La clé privée est (d,n) = (1079,1073) (=clé d'encryptage) (=clé de décryptage) Chiffrement Soit M un entier naturel strictement inférieur à n représentant un message, alors le message chiffré C sera: Déchiffrement (!) Pour déchiffrer C, on utilise d, l'inverse de e modulo (p-1)(q-1), et on retrouve le message clair M par (!) La démonstration repose sur le petit théorème de Fermat, à savoir que comme p et q sont deux nombres premiers, si M n'est pas un multiple de p, on a la première égalité, et la seconde s'il n'est pas un multiple de q : 7 1 ( ), 7 : 1 ( 0) 13

20 En effet 5 9 ( 7 8 ) (!) Or,. 1 ( ( 1). (0 1)) Ce qui signifie que pour un entier k,. = 1 + <. ( 1). (0 1) Donc, si M n'est pas multiple de p d'après le petit théorème de Fermat =>( )(: ) 7. (7 ) >(: ) 7 ( ) et de même, si M n'est pas multiple de q, on peut tenir le même raisonnement et avoir ( 0) Les deux égalités sont en fait réalisées pour n'importe quel entier M, car si M est un multiple de p, M et toutes ses puissances non-nulles sont congrues à 0 modulo p (de même pour q). L'entier?7 89 donc un multiple de p et de q, qui sont premiers distincts, donc également de leur produit pq = n. Il est dès lors possible de retrouver le message clair M depuis le message codé C grâce à l'opération (!) 14

21 1.4 Limitations de ces systèmes de chiffrement Comme nous l'avons vu dans les exemples de ces deux types différents de codage, le chiffrement symétrique et asymétrique, la seule possibilité qui s'offre à nous est celle d'encoder un message et de le décoder entièrement soit avec la même clé (chiffrement symétrique) soit avec deux clés différentes (chiffrement asymétrique). Dans les cas où la quantité de données reste limitée, ces méthodes peuvent être suffisantes car les opérations de rapatriement et de décodage seront limitées dans le temps. Mais si l'on applique ces méthodes à de grandes bases de données comme celles de la Défense où des centaines de gigas de données sont en jeux, il est clair que la puissance du réseau et des ordinateurs ne suffira pas pour assurer une efficacité maximum. Or, dans le cas de l entreposage de données chiffrées stockées dans un Cloud, nous avons besoin de pouvoir exécuter, au sein même du Cloud, une recherche sur les données sans devoir, à chaque fois, tout déchiffrer et tout re-chiffrer. En effet, la méthode "primitive" serait d'encoder d'abord en local nos données à stocker et de les envoyer ensuite une fois chiffrées vers le Cloud. Alors, pour toutes modifications, il faudra télécharger l'ensemble des données et les déchiffrer. Ce qui résulte en une perte considérable de puissance de calcul et de temps. On en déduit qu'un simple algorithme de chiffrement brut symétrique ou asymétrique n'est pas efficace dans le cas du Cloud Computing. Cependant, ces principes sont essentiels pour arriver, à terme, à une méthode de chiffrement adaptée à notre situation. Récemment, une solution théorique s'est développée: le chiffrement homomorphique. 15

22 1.5 Le chiffrement homomorphique Introduction "An encryption is homomorphic, if: from Enc(a) and Enc(b) it is possible to compute Enc(f(a, b)), where f can be: +,, and without using the private key"[14]. Librement traduit cela donne: "Un chiffrement est homomorphique si: depuis Enc(a) et Enc(b) il est possible de calculer Enc(f(a, b)), où f peut être: +,, et ce, sans utiliser la clé privée". Le cryptage homomorphique est une forme de cryptage qui permet d'effectuer certains types de calculs sur un texte chiffré et de générer un résultat chiffré qui, une fois déchiffré, correspond au résultat d'opérations effectuées sur le texte en clair [15]. Par exemple, un chiffrement capable de faire: Dec [ Enc(1) + Enc(2) ] = 3 Appliquée au stockage des données chiffrées placées sur le Cloud, la définition de cette méthode de cryptage semble être une bonne solution permettant de traiter, au sein même du Cloud, la requête sans devoir décrypter les données au niveau du serveur. Pour exprimer ce type de chiffrement à travers une analogie concrète, prenons l'exemple d'un gérant d'une bijouterie [16]. Ce gérant aimerait que ses employés assemblent des pierres et des matériaux précieux pour en faire des bijoux finis mais il est très inquiet par rapport aux vols. Il résout le problème en construisant des boîtes pourvues de gants, boîtes dans lesquelles il stocke les pierres et matériaux précieux et dont il est le seul à posséder la clé. En utilisant les gants, un employé peut manipuler les pierres ou matériaux à l'intérieur des boîtes. L'employé peut aussi introduire de nouveaux matériaux sans que rien ne puisse en sortir. Une fois le travail terminé, le gérant peut venir récupérer le travail terminé en utilisant sa clé. Bien sûr, cette analogie n'est pas entièrement correcte car dans le cas d'un chiffrement totalement homomorphique, seul le produit final importe. Plusieurs vieux systèmes de chiffrement connus tels que RSA (1977 [5]), Benaloh (1994 [17] ou Paillier (1999 [18] [19]) sont partiellement homomorphiques. En effet, ils permettent le calcul homomorphique d'une seule opération (l'addition ou la multiplication) sur des textes en clair. Un système de cryptographie qui supporte à la fois l'addition et la multiplication est appelé "cryptage entièrement homomorphique" (ou Fully Homomorphic Encryption en anglais, abrévié: FHE) et est beaucoup plus puissant. En outre, l'utilisation d'un tel système permet à un processus ou à un algorithme d'être "homomorphisé". 16

23 C'est-à-dire que l'utilisation d'un cryptage homomorphique permettrait au système d'utiliser des données brutes cryptées homomorphiquement sans devoir les déchiffrer et, de ce fait, produire un résultat qui lui aussi sera chiffré homomorphiquement sans devoir implémenter un quelconque système de cryptage propre. De plus, comme un tel programme ne décrypte pas les données entrantes, il peut être exécuté par un tiers n'ayant pas accès aux algorithmes / clés de décodage (tiers "non approuvé") et, de cette manière, être exécuté sans révéler ses secrets. L'utilité du cryptage entièrement homomorphique est reconnu depuis longtemps. La question de la mise en place d'un tel système a été posée à la suite du développement du crypto-système RSA car celui-ci étant partiellement homomorphique, la recherche s'est orientée vers une solution l'étant totalement. Trouver une solution s'est avérée plus difficile que prévu. En effet, pendant plus de 30 ans, il a été difficile de savoir si le cryptage entièrement homomorphique était réellement possible. Pendant cette période, la meilleure solution a été le système de chiffrement Boneh - Goh - Nissim [20] qui permettait l'utilisation d'un nombre illimité d'opérations d'addition, mais avec un maximum d'une seule multiplication. C'est en 2009 que Craig Gentry a montré le premier schéma de chiffrement totalement homomorphique [16]. Son élaboration commence à partir d'un schéma de chiffrement peu (partiellement) homomorphique qui évolue ensuite selon un schéma le rendant "bootstrappable". Dans ce cas-ci, l'adjectif "bootstrappable" fait référence aux petits programmes d'amorçage qui permettent d'en lancer de plus gros, c'est-à-dire qu'une petite partie partiellement homomorphique du schéma de Craig Gentry sert à démarrer une plus grosse partie qui, elle, sera totalement homomorphique. Il démontre enfin que tout système de chiffrement homomorphique bootstrappable peut être converti en un chiffrement totalement homomorphique avec peu de manipulation. En ce qui concerne les performances, évaluées grâce au schéma de Gentry, elles restent encore faibles dans la mesure où le temps de compilation ne dépend pas du tout de la complexité de la fonction qui est appliquée sur les données chiffrées: le temps de calcul est lié linéairement au nombre d'opérations effectuées. Cependant, ce schéma n'est pas pratique pour de nombreuses applications, car la taille du texte à chiffrer et le temps de calcul augmentent fortement lorsque l'on désire augmenter le niveau de sécurité. Pour obtenir une sécurité suffisante contre les attaques connues, le temps de calcul et la taille du texte chiffré sont encore trop longs, bien qu'une amélioration ait déjà été apportée par Stehle et Steinfeld [13]. Ce phénomène est un des plus grands freins à l'utilisation de cette technologie pourtant très prometteuse. En 2009, Marten van Dijk, Craig Gentry, Shai Halevi et Vinod Vaikuntanathan [21] ont présenté un deuxième plan de cryptage entièrement homomorphique [15] qui utilise de nombreux outils de la construction de Gentry. 17

24 Cette nouvelle approche est conceptuellement plus simple que le système originel de Gentry, mais possède des propriétés similaires en ce qui concerne les opérations et l'efficacité homomorphique ainsi que le temps de compilation Sur le plan technique L'exigence minimale pour un schéma de cryptage homomorphique est d'être déchiffrable. En effet, pour tout schéma B d'encryption homomorphique, il doit être possible de décrypter un texte encrypté en étant munis des clés publiques/privées nécessaires. Le but final est de construire un schéma d'encryption B qui soit totalement homomorphique. Pour l'exprimer autrement, l'essence même de l'encryption homomorphique est simple: soit un texte original et sa version chiffrée C, C, C,, C E B (C, C, C,, C E ) un chiffrement homomorphique de ce texte sera tout chiffrement qui permet à n'importe qui (pas seulement le détenteur des clés de cryptage) de produire un texte chiffré qui encode F(C, C, C,, C E ) pour toute fonction f. C'est-à-dire que n'importe qui sera capable d'effectuer, à partir de B (C, C, C,, C E ), B[ F (C, C, C,, C E )] Aucune information à propos de (C, C, C,, C E ) ou de n'importe quel produit intermédiaire n'est "lisible" car l'input, l'output et les produits intermédiaires sont toujours cryptés. Pour satisfaire à cette définition, un cryptage entièrement homomorphique doit être homomorphique multiplicatif et homomorphique additif. En effet, sans ces deux propriétés essentielles, il serait impossible de pouvoir appliquer une fonction quelconque f à C, C, C,, C E, ce qui est le but final de l'encryptage homomorphique. 18

25 Homomorphique additif Un cryptage homomorphique additif est un cryptage homomorphique qui respecte la propriété d'additivité. Cette propriété stipule qu'il est possible, connaissant la clé publique de p et de q et la méthode de chiffrement, de calculer le chiffrement de (p+q) [14]. Donc, un cryptage est additif si: I!& (J L) = I!& (J) M I!&(L) ou, plus généralement, Q Q I!& (N O ) = P I!& ( O ) OR OR C'est-à-dire que le chiffrement de la somme des blocs est égal à la multiplication des blocs chiffrés. Pour illustrer ceci, prenons comme exemple le crypto-système de Paillier (1999 [18]). Ce système, tout comme RSA, demande deux inputs: p et q, deux nombres premiers. Dans un premier temps, il faut calculer n et λ tel que:! = 0 Ensuite, il faut choisir g tel que: S = TT57 3 ( 1, 0 1) U Z X Y TZ5[ \2?U = 1 3,& 2 _ = ( 1)! Les clés sont alors 5 é 0, = (!, U) 5 é ' 3é, = (, 0) 3 PPCM = Plus Petit Commun Multiple 19

26 Pour chiffrer un message m avec la clé publique, il faut d'abord choisir r tel que ' Z X Ensuite, on peut calculer c, le message m chiffré avec ce système de Paillier: & = U` ' X!² Pour déchiffrer ce message c, en un message clair m, il faut procéder comme suit: = 2 ( &]! ) 2 ( U ]! )! Or, supposons deux textes chiffrés comme décris ci-dessus C1 et C2 tels que: 5 = U`b. ' X.! 5 = U`Y. ' X.! On peut ensuite réaliser la multiplication de ces deux messages: 5. 5 = U`b. ' X. U. ' X! = U`b=`Y. ('. ' ) X! On peut dès lors remarquer que si l'on déchiffre ce message, le résultat sera égal à coxdq = + Prenons un exemple pour clarifier les choses: Soit = 7, 0 = 11 Alors! = 7 11 = 77, U = 5652 (g a été calculée grâce à Mathlab selon la formule cidessus). Et donc la clé privée vaut (7,11) tandis que la clé publique vaudra (77,5652). Soit un message = 42 avec ' = 23 et un message = 56 avec ' = 29 20

27 Alors on a & = [(5652) h (23) ii ] 5929 & = [(5652) jk (29) ii ] 5929 Or si l'on multiplie c1 et c2, on obtient: & & = [(5652) h (5652) jk (23) ii (29) ii ] 5929 = [(5652) h =jk (23 29) ii ] 5929 Et si l'on déchiffre c1.c2, on a coxdq = = 98 Ce qui est bien l'addition de nos deux messages d'origines m1 et m2. On peut donc conclure que le système de Paillier réalise cette propriété d'additivité homomorphique. Une application concrète d'un cryptage homomorphique additif est le vote électronique: chaque vote est encrypté et seule la "somme" est décryptée Homomorphique multiplicatif Un cryptage homomorphique multiplicatif est un cryptage homomorphique qui respecte la propriété de multiplication. Cette propriété stipule qu'il est possible, connaissant la clé publique de p et de q et la méthode de chiffrement, de calculer le chiffrement de (p.q) [14]. Comme précédemment cité, la notion de cryptage entièrement homomorphique a été introduite peu après le développement de la solution de cryptage RSA (Rivest, Shamir et Adleman) car cette solution RSA est en fait un schéma de cryptage homomorphique multiplicatif. Reprenons ce système RSA pour expliquer cette propriété de multiplication homomorphique. Soit une clé publique RSA < = (,,!) 21

28 et le texte chiffré par ce système (ciphertext en anglais): alors, on peut effectivement calculer: 5 O O 8 (!) P 5 O = (P m m ) 8! O O Ce qui est un texte chiffré résultant du produit des textes chiffrés mais qui est aussi le chiffrement du produit des textes originaux. C'est en fait une propriété "accidentelle" du crypto-système RSA. Outre le fait que cette propriété soit présente, il existe un problème de sécurité. En effet, supposons deux textes chiffrés C1 et C2 provenant des messages m1 et m2 tels que: 5 = 8! 5 = 8! Alors 5 5 = ( 8 8 )! = ( ) 8! Or, si le client envoie la paire (C1,C2) au serveur, celui-ci va effectuer l'opération demandée par le client et renvoyer le résultat (C1 x C2) au client. Si un pirate intercepte les deux textes C1 et C2, encrypté avec la même clé, il sera capable de décrypter tous les messages échangés entre le serveur et le client moyennant des techniques mathématiques complexes. Prenons un exemple concret: Soit p = 3, q = 11, e =7 et d = 3 et soit une taille de bloc de 1 (pour plus de facilité, nous utiliserons également des messages de un bloc de longueur). Les deux messages m1 et m2 et leur messages chiffrés respectifs C1 et C2 obtenus en utilisant le cryptage RSA: m1 = 9 et C1 = 15 m2 = 3 et C2 = 9 22

29 Appliquons maintenant la multiplication: 5 5 = 15 9 = 135 Maintenant, si nous décryptons le texte chiffré (C1 x C2) avec la clé privée, nous obtenons: = (5 5 ) 9! = = 27 Ce qui est exactement la multiplication des deux messages originaux: m1 = 9 m2 = 3 m1 x m2 = 27 Il est donc montré que le crypto-système RSA respecte bien la propriété de multiplicité homomorphique, propriété qu'il est essentiel de posséder dans le cadre d'un chiffrement totalement homomorphique Conclusion intermédiaire Il a été démontré que certains systèmes de chiffrement possèdent, individuellement, des propriétés d'homomorphisme (additif ou multiplicatif) et qu'une solution rassemblant ces deux propriétés a été trouvée. Ces systèmes de chiffrement ne présentant qu'une seule des deux propriétés sont appelés "chiffrements partiellement homomorphiques" tandis que la solution qui joint les deux propriétés est appelée "totalement homomorphique". Cette solution totalement homomorphique permet, comme il a été démontré, d'effectuer des additions et des multiplications sur les données chiffrées sans devoir les déchiffrer, ce qui représentait une des grandes failles de sécurité dans les chiffrements classiques. Cette méthode de chiffrement est donc une bonne alternative mais elle présente un désavantage: sa complexité. Cet inconvénient mène a une certaine lenteur dans l'exécution de ce chiffrement, ce qui en fait son défaut principal. 23

30 1.6 Les recherches (queries) La recherche (ou query en anglais) peut représenter un problème complexe dans le contexte des bases de données chiffrées. Ce problème est en fait plus large qu'il n'y paraît. En effet, la recherche d'une information chiffrée dans une base de données elles-mêmes chiffrées n'est qu'une facette du problème qui consiste à effectuer une opération donnée dans cette base de données. Pour le dire plus clairement, l'informatique n'a pas révolutionné les mathématiques: les opérations de bases sur lesquelles toute autre opération est basée restent l'addition, la soustraction, la multiplication et la division. Certains vont même plus loin en assimilant la soustraction à un cas particulier d'addition et la division à un cas particulier de multiplication. Une recherche dans une base de données sera donc, au final, une série d'instructions exécutées par le processeur. Dès lors, que la finalité de cette série d'instructions soit une recherche ou une addition ne change presque rien à notre problème: comment effectuer une opération dans une base de données chiffrées? Déterminisme La première partie de la solution est de classifier le type de chiffrement utilisé. En effet, il peut être déterministe ou non-déterministe. Cette section a donc pour fonction d'expliquer la différence qui existe entre un chiffrement déterministe et un chiffrement non-déterministe au travers d'exemples concrets Déterministe Un système de chiffrement déterministe est un schéma de chiffrement qui produira toujours le même texte chiffré pour un texte clair donné et pour une certaine clé [22]. Dès lors, il devient plus aisé d'effectuer des opérations sur les parties chiffrées. En effet, prenons le cas très simple d'un schéma de chiffrement tel que pour chaque bloc, le chiffrement consiste à additionner la valeur de la clé (il s'agit donc d'un chiffrement symétrique car pour le déchiffrer, il suffit de soustraire la clé). On a donc, si la clé vaut un, n & opoccqé = n & oqdoq + 1 Supposons également que les données ne soient constituées que d'une matrice contenant des chiffres et qu'un bloc corresponde à un seul chiffre. Le système de chiffrement s'applique sur chaque élément individuellement (les éléments vont donc garder leur place initiale) avec une clé valant un. 24

31 ID élève Points ID* élève Points* Matrice non-chiffrée Matrice chiffrée Il est donc clair que la recherche dans ce genre de schéma de chiffrement est relativement aisée. Effectivement, il suffit de chiffrer la recherche de la même manière que les données ont été chiffrées pour que la recherche puisse s'exécuter sur les données chiffrées. Prenons un exemple simple, Select * From Nom_de_ma_Table where ID élève = 2 Select * From Nom_de_la_Table where ID* élève = 3 Notons au passage que ce genre de chiffrement ne respecte pas l'additivité ni la multiplicité homomorphique. En effet, on a = De plus, on a également 1 x 2 = 1 2 x 3 2 Ce système de chiffrement n'est donc visiblement pas homomorphique en addition et en multiplication. Le point fort de ce système est qu'il est aisé d'y effectuer une opération dans les données cryptées mais il souffre d'un point faible de taille: la sécurité! Il est indéniable qu'un pirate informatique doué pourrait, par recoupements, réussir à déterminer l'emplacement de certaines informations etc. Il est donc clair que ce genre de système n'est pas adapté à pour l'utilisation d'un Cloud contenant des données sensibles car il n'offre pas assez de sécurité. 25

32 Non-déterministe Un système de chiffrement non-déterministe, également appelé probabiliste, est un schéma de chiffrement qui utilise au moins un élément aléatoire de sorte que si le même message est codé plusieurs fois, les messages chiffrés résultants seront généralement différents (d'où l'idée de probabilité) [23]. Ce genre de mécanisme se rencontre essentiellement dans des schémas de chiffrements asymétriques mais certains schémas symétriques l'utilisent également. Un exemple concret de ce genre de chiffrement peut être élaboré à partir du système AES décrit plus haut. Le principe est de démarrer notre système de chiffrement par un vecteur initial de valeur aléatoire auquel on ajoute le premier bloc de notre message à coder. Ensuite, le résultat de cette opération est chiffré grâce à l'algorithme AES et une certaine clé (symétrique). Pour chiffrer le second bloc, on utilisera le résultat de ce chiffrement pour l'ajouter au bloc et ce n'est qu'après cette opération que l'on pourra utiliser AES pour chiffrer et ainsi de suite pour les autres blocs. Il apparaît donc que le résultat d'un tel schéma est non-déterministe car le vecteur initial aléatoire implique une possible variation du résultat final liée à la probabilité d'utiliser le même vecteur initial aléatoire. Figure 8: Chiffrement non-déterministe ( 26

33 Dans ce genre de schéma, la recherche et les autres opérations sur les données déjà chiffrées sont, si pas impossibles, très complexes. En effet, comme une même information peut être chiffrée différemment, il est donc presque impossible de l'identifier dans une base où chaque donnée peut prendre une valeur particulière parmi un panel de valeurs. Certaines solutions approchent quand même la réalisation d'une recherche dans des données chiffrées grâce à un algorithme pseudo-non-déterministe telle que celle proposée par Porticor (voir ci-après). Mais aucune n'y arrive lorsque l'algorithme est réellement non-déterministe Chiffrement homomorphique De par sa nature complexe, le chiffrement homomorphique permet de réaliser des additions et des multiplications: ce qui revient à dire qu'il permet d'effectuer des recherches sur les données codées. Mais ce système de codage est-il déterministe ou non-déterministe? Le choix est crucial car il a été démontré plus haut que le danger inhérent aux systèmes de chiffrement déterministe est le fait de pouvoir déterminer où se situent les différentes informations. Il est donc important de pouvoir utiliser un système de codage homomorphique nondéterministe. Le système de chiffrement homomorphique échappe quelque peu à cette classification car, tout comme le système AES, il peut être utilisé de plusieurs façons le rendant tantôt déterministe et tantôt non-déterministe [16]. 27

34 1.7 Conclusion partielle Ce chapitre met en lumière les faiblesses des méthodes de chiffrement classiques. En effet, elles comportent des vulnérabilités inhérentes à leurs modes de fonctionnement; vulnérabilités beaucoup trop importantes pour pouvoir être utilisées pour le stockage d'informations sensibles comme pourrait le faire la Défense. De plus, il est maintenant clair que toutes les méthodes de chiffrement ne sont pas utilisables dans la perspective d'un Cloud. Il est indéniable que pour une telle utilisation, la fonction de recherche est primordiale et tous les systèmes de codage n'offrent pas cette possibilité. Le choix est donc réduit. Le chiffrement homomorphique répond, en partie, à ces besoins de sécurité et de fonctionnalités mais n'est pas non plus la solution idéale. Il comporte, lui aussi, un point faible: le temps de calcul qui est très important. Or, dans l'optique de l'utilisation d'un Cloud pour sa gestion administrative, la Défense a besoin de manipuler ses informations très régulièrement et souvent sans délai. Le temps de calcul a donc une influence très significative et le temps de calcul du chiffrement homomorphique peut constituer un frein significatif dans l'utilisation quotidienne de ses données. En définitive, il n'existe pas de solution miracle. La seule alternative envisageable est de trouver un bon compromis de l'utilisation de ces différentes techniques pour arriver à un système combinant sécurité et vitesse. 28

35 2 Le projet THEP 2.1 Introduction Dans le cadre du développement informatique du chiffrement homomorphique, un projet dit "libre" (libre d'accès au code source et à la manipulation) est disponible sur Google Code dont le but est d'implémenter dans le langage informatique Java ce genre de chiffrement. Les parties les plus intéressantes du code sources de ce projet sont disponibles dans les annexes 1 à 4. Ce projet porte le nom de THEP (The Homomorphic Encryption Project) et est au stade de la réalisation expérimentale. Cela signifie que le projet n'est pas finalisé et qu'il n'est disponible que sous forme de fichiers informatiques comme des librairies diverses ou des conteneurs java (fichier avec l'extension ".jar"). Ce projet se base essentiellement sur la thèse Craig Gentry: " A FULLY HOMOMORPHIC ENCRYPTION SCHEME" [16] consacrée au chiffrement homomorphique. Sa mise à disposition sur le Net indique qu'il y a une réelle volonté d'ouvrir la recherche à l'implémentation. Dans un premier temps, le projet a été étudié et une ébauche de "programme" fonctionnel a été développée. En effet, le projet en lui même ne consiste qu'en une collection de classes implémentant le chiffrement homomorphique, il a donc fallut créer une nouvelle classe permettant de mettre en application cette implémentation. Les explications du fonctionnement du chiffrement homomorphique se baseront sur la classe développée par nos soins. 29

36 2.2 Aperçu général Dans cette partie, le fonctionnement très global de la librairie sera abordé par le biais de l'articulation logique en quatre phases du logiciel développé: 1. Création des clés; 2. Chiffrement; 3. Opérations mathématiques (addition et multiplication); 4. Déchiffrement; Pour être le plus didactique possible, le programme montre séparément l'addition et la multiplication. Bien sûr, ces opérations peuvent être combinées à l'infini pour créer des opérations des plus complexes. Dès lors, les recherches (ou queries) dans des bases de données cryptées sont possibles comme vu précédemment. La classe Java que nous avons développé pourrait donc être utilisée pour le chiffrement de bases de données au prix de modifications ou améliorations relativement complexes et fastidieuses. 30

37 2.3 Création des clés L'étape de la création des clés est une des plus essentielles. En effet, c'est elle qui va définir la taille et la complexité des clés et donc du chiffrement. Mais d'un autre côté, la connaissance du mécanisme de création de cette clé importe peut tant que le programme est capable de la reconnaître et de l'utiliser. Pour simplifier quelque peu le projet THEP, il a été décidé que ces clés seraient aléatoires, ce qui est beaucoup plus facile pour l'encodage. Dans l'exemple développé, nous nous remettons entièrement aux classes Java intitulées "PrivateKey" et "PublicKey" contenues dans le projet THEP Clé privée Pour la création des clés aléatoires, le programme fait appel à la fonction PrivateKey avec un paramètre de longueur arbitrairement choisit de 128 bits. Cette clé privée sera appelée sans surprise "privkey". Figure 9: privkey La seconde ligne (ligne 22) ne sert qu'à afficher la clé privée lors de l'exécution du logiciel. Cette étape n'est pas du tout indispensable lors du développement d'un logiciel plus complexe et plus opérationnel. Elle n'est présente dans notre cas que pour assurer une bonne compréhension du mécanisme de chiffrement. Pour clarifier le mécanisme de création de la clé privée aléatoire, il suffit de développer (ouvrir) la classe java PrivateKey. En effet, dans cette classe, tous les détails liés à sa création sont visibles: Figure 10: PrivateKey 31

38 Il paraît donc que le seul argument à fournir à cette fonction est bien sa longueur sous la forme d'un entier (integer en anglais, représenté par "int"). Dans l'exemple développé, la longueur est de 128 bits. Lors de la création de cette clé, la première étape consiste à utiliser un générateur de nombres sécurisés. Il s'agit d'un nombre issu de la classe SecureRandom [24]. Cette classe fournit un générateur de nombre "fort" en terme de cryptographie. Ces nombres "forts" se plient aux exigences de la norme FIPS section [25] qui spécifie: "A cryptographic module shall perform the following power-up tests: cryptographic algorithm test, software/firmware integrity test, and critical functions test". De plus, le nombre fournit par cette classe est non déterministe (au sens vu ci-dessus), il ne peut donc pas être "deviné" à l'avance: il est imprévisible. Les étapes suivantes consistent à créer deux nombres (i.e. p et q) qui sont "probablement" premiers. On reconnaît par ailleurs les nombres p et q de l'algorithme RSA (le chiffrement homomorphique en est proche). En effet, la classe BigInteger permet de construire un nombre positif qui est "probablement" premier, avec une représentation en binaire de longueur du premier argument. La "probabilité" que l'entier soit premier dépasse: T' é rq8`o8q = s _tOè`8 dqv_`8xew Il est évident que cette probabilité doit être la plus élevée possible pour le bon déroulement de la suite de la création de la clé. En effet, il est impératif que ces nombres soient premiers comme il a été démontré dans la section à propos des clés de chiffrement dans un système asymétrique. Malheureusement, le temps de création de cette clé dépend du degré de certitude que l'on veut atteindre. Il est donc important de trouver un juste milieu entre complexité (qui augmente la sécurité) et vitesse d'exécution. Dans notre exemple, les deux nombres p et q sont créés avec une représentation en binaire de longueur de 64 bits (car la longueur de la clé vaut 128 bits, ces deux nombres sont donc de longueur 128 / 2 = 64 bits). Toujours avec ce même exemple, la probabilité que l'entier soit premier dépasse: T' é rq8`o8q = s1 1 2 xw = 99,902 % La probabilité que la création de cette clé aboutisse à un nombre premier est donc supérieure à 99,9%; ce qui semble tout à fait acceptable. 32

39 La suite de la création de la clé suit, essentiellement, le même système que la création des clés dans le chiffrement RSA développé précédemment. En effet, l'étape suivante consiste à multiplier p et q pour obtenir n. Ensuite, l'indicatrice d'euler est calculée (lambda) et l'exposant de chiffrement mu est déterminé pour arriver, finalement, à la création de la clé privée Clé publique Pour la création de la clé publique, le logiciel suit exactement le même cheminement que pour la clé privée: il se repose sur la classe PublicKey. Figure 11: Clé publique De la même manière que pour la clé privée, la seconde ligne (ligne 27, figure 11) représente la clé publique. Notons que cette étape du code est totalement dénuée de sens dans un logiciel qui ne se veut pas didactique. La création de cette clé se fait grâce à la variable privkey. En effet, lors de la création de la clé privée, la clé publique est directement créée (ligne 28 de PrivateKey, figure 10) grâce à la classe PublicKey. Il est logique, en effet, que la clé publique soit formée à l'aide de sa clé privée correspondante. Pour être précis, la méthode de création de la clé publique est la suivante: Figure 12: PublicKey Il est visible que la clé publique sera, elle aussi, longue de 128 bits dans notre exemple. 33

40 2.3.3 Chiffrement Dans cette section, l'implémentation de la méthode de chiffrement sera discutée en ellemême. Pour l'aspect de démonstration du logiciel, il est demandé à l'utilisateur de rentrer deux nombres qui seront, par la suite, transformés en BigInterger [26] pour de futures manipulations (ce format Java permet de manipuler des grands nombres). Figure 13: Chiffrement Sur la figure 13, il est clairement visible que grâce au scanner saisieutilisateur, les nombres entier1 et entier2 sont récupérés (lignes 31 à 36). Ils sont ensuite transformés respectivement en BigInteger a1 et b1 (lignes 43 et 44). L'avantage de transformer ces nombres en BigInteger réside dans le fait que cette classe permet de représenter des entiers ou des nombres flottants sans limitations de taille des types primitifs (int, float, etc.). Le cœur même de cette étape de chiffrement réside dans l'utilisation des lignes 52 et 53: Figure 14: Chiffrage de a et de b En effet, c'est grâce à ces deux simples lignes de code que a1 et b1 sont chiffrés homomorphiquement! Bien évidemment, pour plus de clarté, il faut développer la classe EncryptedInteger présente dans le projet THEP. Pour plus de lisibilité, seule la fonction EncryptedInteger accompagnée de deux arguments sera expliquée en détails. 34

41 Figure 15: EncryptedInteger Il apparaît que, pour fonctionner normalement, la fonction EncryptInteger a besoin de trois arguments: le nombre à chiffrer, la clé publique et une classe c. Dans notre cas, si cette classe c n'est pas fournie, la fonction va lui fournir d'office la classe BigInteger comme décrit à la ligne 16. Une fois en possession de ces trois arguments, la fonction va créer un nouveau nombre aléatoire de la classe SecureRandom ainsi que deux variables rngcons et bicons issues de deux méthodes, respectivement findrngcons et findbicons, décrites ci-après, qui renvoient des constructeurs. Un constructeur dans le langage Java est une fonction particulière qui permet d'instancier, c est-à-dire créer un objet en mémoire vive [27]. Pour l'exprimer plus vulgairement, c'est une fonction qui va créer une nouvelle sorte de variable. La première méthode findrngcons n'a besoin que d'un seul argument, une classe, pour renvoyer son constructeur. 35

42 Figure 16: findrngcons Cette méthode permet de vérifier que dans la classe c, il existe bien un constructeur acceptant deux variables: un entier (integer) et un nombre aléatoire (random). Le second constructeur findbicons, comme le précédent ne requiert qu'un argument: une classe. Figure 17: findbicons Cette méthode sert à vérifier que dans cette classe c, il existe un constructeur acceptant un entier (integer). Ces deux vérifications sont mises en place pour vérifier que la classe c ressemble suffisamment à un BigInteger. En effet, pour être plus souple, ce logiciel propose d'utiliser autre chose qu'un BigInteger comme variable pour la fonction EncryptedInteger. 36

43 Malheureusement, il ne peut pas accepter non plus n'importe quelle classe trop éloignée d'un BigInteger. Il est donc important de vérifier que la classe, dérivée d'un BigInteger, ressemble suffisamment à cette dernière. Mais l'instruction la plus importante dans cette partie est "set (plainval)". En effet, c'est elle qui est la vraie responsable de l'encodage du message. Sans surprise, il faut se rendre à la fonction set pour y retrouver le cœur des opérations. Figure 18: set Le premier point marquant est que cette fonction accepte comme argument un BigInteger. Heureusement, les deux constructeurs précédents nous ont permis de vérifier que l'élément plainval était bien issu d'une classe ressemblante. Ensuite, après avoir initialisé r (ligne 73), un BigInteger supérieur à n (le produit de p et q), et g (ligne 82), le même g que dans la classe PublicKey (où g = n + 1), la première étape est de calculer 5 h,'3 = U rqdoxdq (! ) La seconde étape consiste à initialiser x tel que J = ' X (! ) Après cela, le logiciel va multiplier la valeur de Cipherval par celle de x et stocker cette valeur dans la variable Cipherval. Ensuite cette valeur subira un modulo n². Ce dernier résultat est alors la valeur finale de Cipherval. En résumant ce code en une seule ligne, on peut écrire: 5 h,'3 = \U rqdoxdq (! )^ J!² 37

44 On a donc notre texte chiffré Cipherval à partir du texte original Plainval et la clé publique Pub, comme il a été démontré dans la théorie au chapitre I. Après ce long développement de chiffrage, a1 et b1 sont enfin cryptés de manière homomorphique. Ce qui permet donc de passer à l'étape suivante qui est l'application, à ces deux nombres chiffrés, d'opérations mathématiques de bases Opérations mathématiques Dans cette section, une série d'opérations élémentaires sont appliquées aux nombres chiffrés pour vérifier si l'implémentation s'est effectuée correctement. En effet, le plus gros avantage du chiffrement totalement homomorphique réside dans le fait qu'on peut appliquer toute une série d'opérations élémentaires sans avoir recours à un déchiffrement des données. Dans un premier temps, une addition est effectuée entre les deux nombres chiffrés. Figure 19: L'addition Cette opération add est décrite dans la bibliothèque EncryptedInteger. Figure 20: add Pour permettre une addition, cette fonction commence par initialiser g (tout comme dans la fonction set, c'est-à-dire g = n + 1) et tmp_int un EncryptedInteger. Ce tmp_int a donc une valeur Cipherval. 38

45 Ensuite, la fonction va stocker dans la valeur tmp la valeur de la multiplication de la première valeur chiffrée et de g exposant la valeur chiffrée modulo n². Par après, cette valeur obtenue subit un modulo n² une fois de plus. Pour clarifier ce petit développement, exprimons le en langage mathématique: = \5 h,'3 (U ~O p8qdq Y! )^!² Cette valeur de tmp est ensuite stockée dans la valeur Cipherval de tmp_int. C'est finalement l'encryptedinteger tmp_int qui est renvoyé par la fonction (car il contient dans sa valeur Cipherval le résultat de l'addition des deux EncryptedIntegers). Il apparaît que la méthode utilisée ne déchiffre pas du tout les données mais transforme la requête d'addition traditionnelle en un processus plus complexe pour permettre au logiciel d'additionner ces deux BigIntegers de manière homomorphique. Dans un deuxième temps, la multiplication est effectuée avec enc_a, la version chiffrée du premier nombre entré par l'utilisateur, et b1, la version BigInteger du deuxième nombre entré par l'utilisateur. Figure 21: La multiplication L'opération multiply utilisée ici est également décrite dans la bibliothèque EncryptedInteger. Figure 22: multiply 39

46 De la même manière que pour l'addition, la première étape est l'initialisation de tmp_int, un EncryptedInteger, ainsi que celle de c, la valeur Cipherval du premier terme de la multiplication. & = 5 h,'3 Ensuite, le BigIntegertmp de valeur égale à c exposant la valeur du deuxième terme de la multiplication modulo n² est créé: = \(& Ov XE8v8q Y! )^ Cette valeur est, tout comme pour l'addition, stockée dans la valeur Cipherval du BigInteger int_tmp et renvoyée comme le résultat de la multiplication. De nouveau, il apparaît que l'opération multiply ne déchiffre pas du tout les données mais multiplie de manière homomorphique ces deux nombres. De manière plus pragmatique, l'image suivante représente le programme après un essai avec 163 et 149. Leur addition vaut et leur multiplication = = Lorsqu'on lance le logiciel en entrant ces deux nombres, on obtient: Figure 23: Résultat du logiciel 40

47 On peut observer que lorsque les opérations sont effectuées sur les nombres chiffrés et que les résultats sont déchiffrés, ils sont exactes! Même si ce test n'est pas une preuve formelle en soit, il a l'avantage de corroborer le développement théorique ci-dessus et de montrer, de manière didactique, que la pratique rejoint la théorie. D'un autre côté, il est intéressant de noter la longueur des nombres chiffrés. Il est dès lors tout à fait compréhensible que des opérations sur ces nombres requièrent beaucoup de ressources et de temps Déchiffrement Une fois de plus, notre approche dans le logiciel pris comme exemple consiste à utiliser la fonction toute faite decrypt présente dans la classe java IncryptedInteger aux lignes 171 à 194. Figure 24: decrypt Il y est clairement exprimé que l'argument à donner dans ce cas-ci est la clé privée. En effet, lors du chiffrement, la clé publique a été utilisée, il est donc logique d'utiliser la clé privée pour le déchiffrement du message encodé. 41

48 En essence, la procédure de déchiffrement est la suivante: 1. On soustrait 1 au message encodé: & 1 2. On divise ce résultat par n: (& 1)! 3. On multiplie ce résultat par Mu (l'indicatrice d'euler de la clé privée): (& 1)!. (!) 4. On applique l'opération modulo n à ce résultat: (& 1). (!)!! 42

49 2.4 Conclusion partielle Ce chapitre montre de manière didactique, à travers le projet THEP, la manière dont il est possible d'implémenter pratiquement le concept théorique du chiffrement homomorphique vu dans le premier chapitre. Cette solution particulière n'est évidemment pas exploitable sans quelques modifications qui peuvent être significatives mais elle a l'avantage d'être un exemple bien réel du chiffrement homomorphique. Il apparaît également, suite à ce chapitre, que l'implémentation de ce système de codage est relativement longue et complexe. En effet, un bon nombre de raccourcis ont été utilisés: les clés sont aléatoires, le texte non-chiffré doit être exclusivement composé de nombre (BigInteger), etc. pourtant ce petit programme, sans interface graphique, "pèse" plus de 64 ko. Il n'est donc pas aisé de construire des logiciels utilisant ce genre de technologies. 43

50 3 Porticor 3.1 Introduction Il existe de nombreuses solutions commerciales proposant un chiffrement ressemblant, de près ou de loin, à un chiffrement homomorphique. Le projet libre THEP décrit cidessus, et disponible sur Google Code, est certes une ébauche de programme mais certainement pas un logiciel complet prêt à être utilisé. Il est, cependant, impossible de décrire toutes les solutions commerciales existantes dans ce travail; c'est pourquoi celui-ci se limite à en tester une seule: Porticor Cloud Security [28]. Cette solution de Cloud Computing sécurisée est une alternative parmi d'autres également très connues comme: CipherCloud, Bionimbus, etc. Mais Porticor est une des seules sociétés qui se vante ouvertement d'utiliser le chiffrement homomorphique. Cette solution, disponible en ligne, reste relativement onéreuse puisqu'elle demande plus ou moins 599$ par machine où un Cloud est installé ainsi que 99$ par mois pour les services en ligne offerts (quelque soit le nombre de machines différentes utilisées). Heureusement pour ce travail, une version d'essai est disponible durant 30 jours pour permettre aux futurs clients de se familiariser avec cette solution. C'est cette solution qui a été testée. 44

51 3.2 Système de chiffrement utilisé Tout d'abord, il est très important de noter que selon Porticor Cloud Security, la tâche la plus importante de la solution proposée est de protéger la clé de chiffrement. En effet, comme l'a affirmé Ariel Dan, l'un des co-fondateurs de Porticor, contacté par nos soins via (voir annexe 5): " In cloud computing, we believe that protecting the encryption keys is the most important task. By implementing Homomorphic key management, we can provide the assurance that your encryption key is never revealed in the cloud, even while in use. We're the only encryption vendor that can claim such claim, therefore we are proud to deliver the strongest cloud encryption technology (keep in mind that we also deploy our split-key technology in addition to homomorphic key management)". Par ce mail, on ne peut que confirmer ce que les explications de la société laisse sousentendre, à savoir que le chiffrement homomorphique n'est pas réellement utilisé sur les données mêmes stockées dans le Cloud mais bien sur la clé qui sert à utiliser ces données. En effet, la solution offerte par Porticor Cloud Security est un stockage de données sécurisées avec un algorithme AES-256, c'est-à-dire un algorithme AES (symétrique) dont la clé a une longueur de 256 bits. Mais la spécificité de cette solution réside dans sa clé. En effet, cette clé de 256 bits est composée de deux parties différentes: la Master key, en possession du client, et une autre partie de la clé, en possession du Porticor Virtual Key Management. Figure 25: Porticor Virtual Key Management Service ( 45

52 C'est dans cette clé que réside la partie homomorphique du système. Effectivement, lorsque l'application veut accéder aux données chiffrées stockées dans la partie Cloud, elle doit utiliser les deux parties de la clé de manière dynamique pour chiffrer et déchiffrer les données encodées. Or, comme cette utilisation de la clé se veut dynamique, Porticor a décidé de chiffrer cette clé finale de manière homomorphique. L'avantage indéniable de ce système est que la clé voyage donc de manière chiffrée (homomorphiquement) entre le système de gestion des clés de Porticor et le serveur où se trouve le Cloud. Elle ne peut donc pas être volée ou piratée. Mais il faut également noter que la partie de la clé que le client possède doit voyager sans protection entre son ordinateur et le système de gestion des clés de Porticor. Ce voyage de la Master key est indéniablement le point faible de cette solution. Car si un pirate arrive à intercepter cette clé lors du voyage initial, il est à même de se faire passer pour le client et d'accéder au contenu de son Cloud. Bien évidemment, Porticor a essayé de protéger au maximum ce transfert initial. C'est pourquoi la connexion se fait via le protocole https, c'est-à-dire via une connexion sécurisée par Secure Socket Layer (SSL). Ce type de protection relativement vieux (2001) se situe entre la couche application et la couche transport dans le modèle OSI [29]. Il repose sur l'utilisation combinée d'un chiffrement asymétrique pour l'authentification et d'un chiffrement symétrique (plus rapide) pour assurer la transmission des informations [30] [31]. Malheureusement, ce type de protection pour l'envoi de la clé au système de gestion des clés de Porticor est relativement dépassé. En effet, plusieurs failles ont déjà été découvertes dans le système et dans son implémentation. Pour ne citer que la plus récente, la faille Heartbleed, rendue publique le 7 avril 2014, se situait au niveau de l'implémentation d une mise à jour du certificat SSL. Cette vulnérabilité a touché plus d'un demi-million de serveurs dont Twitter, Dropbox, Yahoo, Facebook... [32] [33] [34]. Il apparaît donc que si Porticor offre une bonne solution d'utilisation du chiffrement homomorphique, elle comporte malheureusement des points faibles. Dans le cas de la Défense, ces points faibles restent inacceptables car ils sont une brèche par laquelle des pirates informatiques sont susceptibles d'entrer. 46

53 3.3 Démonstration Cette partie sera consacrée au test proprement dit de la solution depuis son téléchargement jusqu'à la manipulation de données dans un espace protégé. Figure 26: La solution Porticor ( La première étape consiste à télécharger la solution Porticor. D entrée de jeu, deux solutions s'offrent au client: un choix entre deux images virtuelles 4 d'une machine Porticor. La première image est destinée aux services AWS (Amazon Web Services) qui est une plateforme de collection de services informatiques distants fournis via internet par le groupe américain de commerce électronique Amazon.com [35] [36]. La seconde image est destinée à VMWare qui est un logiciel connu de virtualisation. C'est cette dernière solution qui a été retenue pour les tests. Bien évidemment, pour l'utilisation de chacune de ces images, les logiciels de virtualisation utilisés doivent avoir été installés au préalable, dans notre cas, VMware Player version L'image à télécharger sur le site de Porticor (Porticor-VPD-v2.35) se présente donc sous la forme d'une image pour VMWare (.ova) de 1,3 Go environ. Figure 27: Image OVA Cette image s'ouvre très facilement grâce à l'onglet "Open a virtual machine" de VMWare Player. 4 Une image virtuelle est, dans notre cas bien précis, la copie conforme de ce qui se trouve sur le disque dur d'un ordinateur. Ces images comprennent donc le système d'exploitation (qui, dans le cas de Porticor est un dérivé de Linux), les différents programmes qui y sont installés ainsi que les données déjà enregistrées sur ce disque. 47

54 Figure 28: Début avec VMWare Player Après l'importation de l'image de la machine, il faut ajouter des disques durs sur lesquels seront stockées les informations chiffrées. Pour cela, il suffit de modifier les options de la machine virtuelle et, sous l'onglet "Hardware", cliquer sur "Add" pour ajouter un composant hardware fictif, dans notre cas, un disque dur. Figure 29: Ajout des disques durs Pour notre exemple, deux disques durs de 1Go ont été ajoutés. 48

55 Ensuite, il faut démarrer la machine en double-cliquant sur l image. Une fois cette étape remplie, la machine virtuelle Porticor est installée et démarrée sur l'ordinateur local. Cette machine possède aussi un serveur qui démarre simultanément et automatiquement avec elle et qui est joignable à tout moment en tapant son adresse IP dans un navigateur web (avec une connexion protégée en SSL): Pour faciliter la vie du client, une fois la machine démarrée, elle affiche à l'écran son adresse IP sur laquelle il faut se connecter pour atteindre le serveur. Figure 30: Adresse IP du serveur web L'étape suivante est la connexion sur le serveur web de la machine. Pour l'exemple, nous avons utilisé le navigateur web Opera. 49

56 Figure 31: Login Dès l accès à cette page, des informations personnelles sont demandées pour pouvoir se connecter aux services offerts par Porticor. Figure 32: Informations supplémentaires 50

57 Une fois des données enregistrées, le client doit encore remplir quelques formalités nécessaires à l'élaboration d'un Cloud. Figure 33: Début du projet Porticor Ensuite, débute une des étapes les plus importantes mais également la plus dangereuse: la communication au client de sa Master Key. C'est en effet à ce moment-là que le niveau de sécurité est au plus bas et si un pirate accède à ce moment précis à l'ordinateur du client, il peut, sans encombres, lui voler sa clé. Figure 34: Master Key 51

58 De plus, on peut remarquer qu'une option existe pour permettre à la clé du client d avoir le statut "persistant", c'est-à-dire que la clé va être stockée dans le navigateur web du client et s'afficher quand un site web la demande. Cette option ne devrait jamais être utilisée car elle stocke la clé la plus essentielle sans protection dans le navigateur web. Une fois cette étape remplie, l'utilisateur a enfin accès à tous les services proposés par Porticor. Figure 35: Porticor Project Setup Pour garantir la confidentialité des informations, une étape supplémentaire est encore nécessaire : la création de disques durs sécurisés sur lesquels le client pourra stocker ses données de manière sécurisée. Pour cela, il faut se rendre dans l'onglet "Protected File Systems". Dans cet onglet apparaissent les deux disques ajoutés sur la machine virtuelle. 52

59 Figure 36: Disques durs Avant de pouvoir les utiliser, il faut configurer le type de stockage que le client veut utiliser. En effet, Porticor en propose quatre différents. Figure 37: Type de stockage Le premier est le Network File System (NFS) [37] [38].C'est en réalité un système de partage de fichiers en réseau développé pour les systèmes UNIX mais dont des versions existent pour Macintosh ou Microsoft Windows. Le second type est le Windows Share qui n'est ni plus ni moins le système développé par Microsoft Windows pour le partage de fichiers en réseau. Le troisième et le quatrième type correspondent au protocole iscsi (Internet Small Computer System Interface) [39] [40]. C'est un protocole de stockage en réseau basé sur le protocole IP destiné à relier les installations de stockage de données. En fonction de l'environnement du client et de ses désirs, il devra choisir un type de stockage adéquat. Si le client utilise, par exemple, Microsoft Windows, et qu'il désire juste stocker des fichiers sur la machine, le plus judicieux pour lui sera de choisir le Windows Share. C'est la solution que nous avons retenu pour notre exemple. 53

60 Figure 38: Titre Notons au passage, le nom du "Disque 1" (qui correspond au "Volume ID" dans la figure 38): hl-4dec5a3f22d6 Figure 39: Adresse du Cloud L'étape suivante consiste à appuyer sur "use it". Une fenêtre apparaît alors donnant au client l'adresse réseau du disque sécurisé. Il ne reste donc plus au client qu'à entrer cette adresse dans son explorateur Windows pour être redirigé de manière sécurisée sur ce disque faisant office de Cloud. 54