Brevet FR3144732A1 — publié le 20240705

La présente invention concerne un système client-serveur mettant en œuvre un client, un serveur de calcul, et un fournisseur de service déléguant au serveur de calcul une opération à effectuer dans le domaine homomorphe sur des données confidentielles du client. Ledit système peut être protégé contre des collusions éventuelles d’un premier type entre le serveur de calcul et le fournisseur de service grâce à un module HSM SP équipant ce dernier. Ledit module HSM SP contient le cryptosystème homomorphe du fournisseur de service et est adapté à effectuer pour son compte un déchiffrement du résultat d’une opération réalisée par le serveur de calcul. Ledit système peut être protégé contre des collusions éventuelles d’un second type entre le serveur de calcul et le client grâce à un module HSM CL équipant ce dernier. Ledit module HSM CL contient le cryptosystème homomorphe du client et est adapté à effectuer pour son compte un déchiffrement du résultat d’une opération réalisée par le serveur de calcul. Fig. 3 PROCÉDÉ ET SYSTÈME CLIENT-SERVEUR ANTI-COLLUSION POUR DONNÉES CHIFFRÉES EN HOMOMORPHE La présente invention concerne le domaine du chiffrement homomorphe. Elle trouve notamment application dans le domaine du calcul confidentiel ( Confidential Computing ) et dans celui de la création/ l’interrogation confidentielle d’une base de données hébergée par un serveur distant. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Le développement de l’informatique en nuage ( Cloud Computing ) conjugué avec les contraintes de confidentialité de certaines données ont conduit à l’essor de la cryptographie homomorphe. Dans un contexte d’application classique, un client souhaitant faire exécuter une opération sur des données confidentielles, chiffre ces données au moyen de la clé publique du cryptosystème homomorphe d’un destinataire, et les transmet à un serveur de calcul (CS) distant. Ce serveur de calcul effectue l’opération dans le domaine homomorphe sur les données chiffrées et transmet le résultat obtenu au destinataire. Celui-ci n’a alors plus qu’à déchiffrer le résultat au moyen de la clé privée de son cryptosystème homomorphe pour obtenir le résultat en clair. On entend ici par cryptosystème homomorphe un couple de clé publique-clé privée permettant de réaliser un chiffrement homomorphe et son déchiffrement. Cette configuration de délégation de calcul du client à un serveur de calcul CS présente toutefois des risques de collusion entre les différentes entités en jeu. Un premier cas de collusion est illustré en dans lequel on a représenté de manière schématique un client CL, un serveur de calcul CS et un destinataire du résultat, ici un fournisseur de service SP. On suppose que le serveur de calcul CS et le fournisseur de service SP sont honnêtes mais curieux. Le client CL souhaitant effectuer une opération sur des données confidentielles les chiffre en 110 au moyen de la clé publique du cryptosystème homomorphe du destinataire SP, et les transmet au serveur de calcul CS. Celui-ci effectue l’opération en 120 dans le domaine homomorphe sur les données chiffrées, à savoir sur . Le résultat est transmis en 130 au destinataire SP qui les déchiffre en 140 à l’aide de sa clé privée pour obtenir le résultat en clair . Un premier type de collusion est susceptible d’intervenir entre le serveur de calcul CS et le destinataire SP : le serveur de calcul peut en effet transmettre directement les données chiffrées au destinataire, auquel cas ce dernier peut accéder aux données en clair en les déchiffrant avec la clé privée . Or ces données sont confidentielles et ne doivent en aucun cas être transmises au destinataire du résultat (fournisseur de service). Un second type de collusion est illustré en , les entités intervenant dans la configuration représentée étant identiques à celles de la . On suppose ici que le client CL et le serveur de calcul CS sont honnêtes mais curieux. Dans cette configuration, le destinataire du résultat n’est autre que le client CL, le fournisseur de service SP fournissant au serveur de calcul CS l’opération (par exemple une opération d’inférence ou une opération de recherche dans une base de données confidentielles de SP) à effectuer dans le domaine homomorphe. L’opération est confidentielle vis-à-vis du serveur de calcul CS et le cryptosystème homomorphe est celui du client CL. Le fournisseur de service, SP, transmet en 210, au serveur de calcul CS, l’expression de l’opération en question dans le domaine homomorphe, soit . Lorsque le client CL transmet au serveur de calcul en 220 des données confidentielles chiffrées au moyen de la clé publique , ce dernier effectue en 230 l’opération dans le domaine homomorphe sur les données chiffrées, à savoir . Le résultat est retourné au client CL en 240 qui les déchiffre en 250 à l’aide de sa clé privée pour obtenir le résultat en clair . Une collusion peut intervenir entre le client CL et le serveur de calcul CS en ce que le second transmette au premier l’opération chiffrée, , le client CL pouvant alors découvrir l’opération qui est déléguée au serveur CS par le fournisseur de service SP. Ainsi, dans le cas d’une opération de recherche dans une base de données confidentielles, par exemple une base de données biométriques chiffrées par , le client peut avoir accès au contenu en clair de la base en question. Différentes mesures ont été envisagées dans l’état de la technique pour se prémunir contre les risques de collusion entre entités d’un système client-serveur opérant sur des données chiffrées en homomorphe. Ainsi l’article de J. Li et al. intitulé « A lattice-based homomorphic proxy re-encryption scheme with strong anti-collusion for cloud computing » publié dans Sensors, 2021, vol. 21, no 1, 288, pp. 1-20 propose une technique de rechiffrement par un serveur proxy, chaque entité disposant d’une clé publique de chiffrement, d’une clé publique d’évaluation et d’une clé secrète de déchiffrement. Cette solution présente toutefois l’inconvénient d’être complexe à mettre en œuvre. L’article de D. Natarajan et al. intitulé « CHEX-MIX: Combining homomorphic encryption with trusted execution environments for two-party oblivious inference in the Cloud » publié dans Cryptology ePrint Archive (2021), pp. 1-21 décrit une méthode d’inférence bipartite dans le Cloud, le fournisseur de service SP transmettant à une enclave SGX du serveur de calcul CS les paramètres du modèle d’inférence dans le domaine homomorphe et le client CL transmettant de son côté au serveur de calcul CS les données confidentielles chiffrées en homomorphe pour traitement à l’intérieur de l’enclave. Le client CL déchiffre le résultat avec sa clé privée. La présence de l’enclave au sein du serveur de calcul CS permet d’éviter les collusions du second type décrites plus haut. Cette solution n’est toutefois pas immune à des attaques par canal auxiliaire ou l’insertion de portes dérobées dans le code de l’enclave. L’objet de la présente invention est par conséquent de proposer un système client-serveur permettant d’éviter les risques de collusion entre les différentes entités de ce système tout en remédiant aux inconvénients de l’état de la technique, autrement dit qui soit simple et robuste aux attaques précitées. La présente invention est définie par un système client-serveur comprenant un client, un serveur de calcul et un fournisseur de service, ledit fournisseur de service déléguant au serveur de calcul une opération à effectuer sur des données confidentielles du client, le serveur de calcul étant adapté à effectuer ladite opération sur les données confidentielles, chiffrées au moyen de la clé publique d’un cryptosystème homomorphe, ledit système client-serveur étant original en ce que le fournisseur de service, respectivement le client, est équipé d’un module matériel de sécurité (HSM SP , HSM CL ) contenant ledit cryptosystème homomorphe et adapté à déchiffrer le résultat de l’opération au moyen de la clé privée du dit cryptosystème homomorphe pour le transmettre au fournisseur de service, respectivement au client. Avantageusement, le client est adapté à chiffrer lesdites données confidentielles au moyen de la clé publique du cryptosystème homomorphe et les transmettre ainsi chiffrées au serveur de calcul. Selon un premier mode de réalisation, le module matériel de sécurité équipe ledit client et le fournisseur de service transmet au serveur de calcul les paramètres de l’opération à effectuer, chiffrés au moyen de la clé publique du cryptosystème homomorphe. Selon un second mode de réalisation, le fournisseur de service est équipé du module matériel de sécurité et le serveur de calcul héberge une base de données chiffrée au moyen de la clé publique du cryptosytème homomorphe, l’opération étant une primitive fournissant une indication de présence ou d’absence des données confidentielles dans la base de données, le fournisseur de service renvoyant au serveur de calcul un code d’accès pour stocker les données dans la base de données si l’indicateur indique une absence dans la base de données. Dans ce cas, pour requêter des données confidentielles dans la base de données, un client tiers transmet au serveur de calcul une requête chiffrée au moyen de la clé publique du cryptosystème homomorphe, ladite requête étant évaluée dans le domaine homomorphe, le résultat de la requête étant ensuite transmis au module matériel de sécurité pour y être déchiffré au moyen de la clé secrète du cryptosystème homomorphe. Selon une variante du second mode de réalisation, le fournisseur de service est équipé du module matériel de sécurité et que le serveur de calcul héberge une base de données chiffrée au moyen de la clé publique d’un second cryptosystème homomorphe distinct du cryptosystème homomorphe stocké dans le module matériel de sécurité. Dans ce cas, le client transmet au serveur de calcul les données confidentielles chiffrées au moyen de la clé publique du second système homomorphe et que le serveur de calcul effectue l’opération dans le domaine homomorphe du second système homomorphe, le serveur de calcul effectuant ensuite une commutation de chiffrement du résultat de l’opération pour obtenir un résultat chiffré dans le premier système homomorphe. Pour requêter des données confidentielles dans la base de données, un client tiers peut transmettre au serveur de calcul une requête chiffrée au moyen de la clé publique du second cryptosystème homomorphe, ladite requête étant alors évaluée par le serveur dans le domaine homomorphe du second système homomorphe, puis faisant l’objet d’une commutation de chiffrement vers le premier système homomorphe, le résultat chiffré de la requête étant ensuite transmis au module matériel de sécurité pour y être déchiffré au moyen de la clé secrète du premier cryptosystème homomorphe. Le cryptosystème homomorphe est de préférence un cryptosystème FHE. D’autres caractéristiques et avantages de l’invention apparaîtront à la lecture d’un mode de réalisation préférentiel de l’invention, fait en référence aux figures jointes parmi lesquelles : , déjà décrite, représente un premier type de collusion entre le serveur d’un fournisseur de service et un serveur de calcul dans une architecture client-serveur ; , déjà décrite, représente un second type de collusion entre un client et un serveur de calcul dans une architecture client-serveur ; représente de manière schématique un système client-serveur anti-collusion du premier type, selon un premier mode de réalisation de l’invention ; et représentent de manière schématique la création et l’interrogation d’une base de données privée utilisant un système client-serveur selon le premier mode de réalisation de l’invention ; représentent de manière schématique la création et l’interrogation d’une base de données privée utilisant un système client-serveur selon une variante du premier mode de réalisation de l’invention ; représente de manière schématique un système client-serveur anti-collusion du second type, selon un second mode de réalisation de l’invention ; représente de manière schématique un système client-serveur anti-collusion du second type, selon une variante du second mode de réalisation de l’invention. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS Nous considérons dans la suite un système client serveur présentant une configuration de base identique à celle décrite précédemment, autrement dit comprenant un client CL, un fournisseur de service SP déléguant une opération (dans le domaine homomorphe) à un serveur de calcul CS. Dans tous les cas, le client transmet au serveur de calcul des données confidentielles, , chiffrées au moyen de la clé publique d’un cryptosystème homomorphe, que ce soit celui du fournisseur de service ou son propre cryptosystème . L’idée à la base de la présente invention est d’ajouter un module matériel de sécurité (encore dénommé quelquefois boîte transactionnelle de sécurité) ou HSM ( Hardware Security Module ), certifié TTP ( Trusted Third Party) au fournisseur de service (pour éviter les collusions du premier type) ou bien au client (pour éviter les collusions du second type), ce module HSM étant le seul élément du système à pouvoir avoir accès à la clé privée du cryptosystème homomorphe servant à chiffrer les données du client (prévention d’une collusion du premier type) ou à chiffrer les paramètres de l’opération déléguée par le fournisseur de service (prévention d’une collusion du second type). Ainsi, dans tous les cas, l’entité destinataire de l’information chiffrée (données confidentielles auxquelles s’applique l’opération, ou bien paramètres de l’opération confidentielle) ne peut directement accéder à la clé privée du système homomorphe et l’utiliser à d’autres fins que celle du déchiffrement de ladite information. En particulier, une collusion du premier type est évitée en ce que le fournisseur de service SP ne peut utiliser la clé privée pour déchiffrer les données confidentielles chiffrées que pourrait lui transmettre le serveur de calcul. A supposer même que le fournisseur de service soit malicieux, il ne pourra pas davantage transmettre la clé privée au serveur de calcul pour que celui-ci les déchiffre. De manière similaire, une collusion du second type est évitée en ce que le client ne peut utiliser la clé privée pour déchiffrer les paramètres de l’opération (par ex. les paramètres du modèle d’inférence ou de l’opération de recherche) que pourrait lui transmettre le serveur de calcul. A supposer même que le client soit malicieux, il ne pourra pas davantage transmettre sa clé privée au serveur de calcul pour que celui déchiffre les paramètres en question. La représente de manière schématique un système client-serveur anti-collusion du premier type, selon un premier mode de réalisation de l’invention. Dans ce mode de réalisation, le destinataire du résultat de l’opération sur les données confidentielles du client, , à savoir le fournisseur de service SP dispose d’un module HSM ( Hardware Security Module ), noté HSM SP . On rappelle qu’un module HSM est un module permettant de générer, stocker et protéger des clés cryptographiques ainsi que d’exécuter des primitives cryptographiques utilisant ces clés. Ce module peut se présenter sous la forme d’une carte électronique enfichable sur un ordinateur ou encore sous la forme d’un boîtier externe. Ce module est choisi certifié TTP, autrement dit il est habilité à effectuer des opérations cryptographiques en tant que tiers de confiance. Le module HSM SP génère le couple de clés publique et privée du cryptosystème homomorphe , la clé publique est partagée avec le client CL et le serveur de calcul CS. Comme en Fig. 1, le client CL souhaitant effectuer une opération sur des données confidentielles les chiffre en 310 au moyen de la clé publique du cryptosystème homomorphe et les transmet au serveur de calcul CS. Celui-ci effectue l’opération en 320 dans le domaine homomorphe sur les données chiffrées, et le résultat est transmis en 330 au module HSM qui les déchiffre au moyen de la clé privée qui y est stockée. A l’étape 340, le résultat est fourni en clair voire sous forme chiffrée (notée ) au fournisseur de service SP. Ce chiffrement peut être un chiffrement asymétrique classique (non homomorphe) ou bien un chiffrement symétrique. La présence du module HSM SP prévient toute collusion entre le serveur de calcul CS et le fournisseur de service SP étant donné que ce dernier n’a plus accès à la clé de déchiffrement . De préférence, le module HSM SP s’assure, avant de fournir le résultat du déchiffrement à SP, que ce dernier correspond bien au format attendu de l’opération . A cette fin, on pourra recourir à des fonctions de calcul dites vérifiables ou VC ( Verifiable Computing ) permettant de prouver que l’opération a bien été effectuée correctement. Cette mesure permet d’éviter que le module HSM SP soit utilisé comme oracle de déchiffrement, c’est-à-dire qu’il déchiffre n’importe quel message qui lui serait transmis dans le but d’obtenir des informations sur la clé . Le système client-serveur anti-collusion selon le premier mode de réalisation de l’invention peut être utilisé dans le contexte de la création et l’interrogation d’une base de données DB comme illustré en Figs. 4A et 4B. L’opération sert à identifier si une information confidentielle est déjà présente dans la base de données DB. Ainsi, par exemple, le résultat pourra être si l’information confidentielle est absente et si cette information est déjà présente dans un enregistrement de la base. Lorsqu’un client veut créer un nouvel enregistrement dans la base, il transmet en 410 l’information chiffrée au serveur de calcul, hébergeant la base de données. Celle-ci est supposée stockée sous forme chiffrée par la clé publique du cryptosystème homomorphe, soit . Le serveur de calcul évalue en 420 la fonction dans le domaine homomorphe et détermine si l’information y est présente. La fonction peut être par exemple une primitive de protocole PIR ( Private Information Retrieval ). Le résultat de l’évaluation dans le domaine homomorphe, soit , est transmis en 430 au module HSM SP du fournisseur de service SP. Le module HSM SP déchiffre le résultat au moyen de la clé privée qui y est stockée et fournit en 440 à SP l’indicateur de présence/absence de l’enregistrement, soit . Optionnellement, le module HSM SP chiffre cet indicateur à l’aide de la clé publique d’un chiffrement asymétrique classique (non homomorphe) ou de la clé secrète d’un chiffrement symétrique avant de le fournir, à SP. Le fournisseur de service SP peut ensuite retourner en 450 au serveur de calcul CS, un code d’accès (par exemple une valeur de hachage) en sus de l’indicateur de présence/absence. Selon le type d’application, code d’accès et l’indicateur peuvent être transmis en clair ou sous forme chiffrée (par un chiffrement classique) au serveur de calcul. Si l’indicateur indique une absence de l’enregistrement, la base de données DB peut être mise à jour en stockant l’information à l’adresse codée par le code d’accès. Une fois la base de données constituée, un client CL peut l’interroger en transmettant en 460 au serveur de calcul CS qui l’héberge une requête chiffrée au moyen de la clé publique du système homomorphe, soit . Le serveur de calcul CS effectue l’opération sur la requête pour évaluer en 470 la réponse dans ce domaine, à savoir . La réponse est transmise en 480, au module HSM SP , qui la déchiffre au moyen de la clé privée qu’il contient. Celui-ci peut la transmettre en clair ou sous forme chiffrée ( ) à l’aide d’un chiffrement classique (asymétrique non homomorphe ou symétrique) au fournisseur de service SP, en 490. Selon une variante, la base de données DB hébergée par le serveur de calcul CS peut être chiffrée à l’aide (de la clé publique) d’un cryptosystème homomorphe distinct de celui stocké dans le module HSM SP . Plus précisément, on notera le premier cryptosystème associé au serveur de calcul et le second cryptosystème associé au module HSM SP du fournisseur de service. La création de la base de données DB selon cette variante de système client-serveur anti-collusion est illustrée en . Le client CL chiffre à l’aide la clé publique l’information confidentielle et la transmet en 510 au serveur de calcul CS dont la base de données est elle-même stockée sous forme chiffrée par la clé . Le serveur de calcul dispose en outre d’une clé de commutation . Comme précédemment, le serveur de calcul évalue en 520 la fonction sur l’entrée dans le domaine homomorphe pour déterminer si cette information est présente dans un enregistrement de la base. Le résultat de cette évaluation fait ensuite l’objet, en 525, d’une commutation de chiffrement dans le domaine homomorphe au moyen de la clé de commutation . Différentes techniques de commutation de chiffrement ( Key Switching ) sont connues de l’état de la technique. On pourra notamment en trouver une description dans l’article de A. Kim et al. intitulé « Revisiting homomorphic encryption schemes for finite fields » publié dans International Conference on the Theory and Application of Cryptology and Information Security. Springer, Cham, 2021. p. 608-639. Le résultat de la commutation de chiffrement, est ensuite transmis en 530 au module HSM SP . Le module HSM SP déchiffre ce résultat au moyen de la clé privée du second cryptosystème qu’il contient et fournit en 540 un indicateur en clair, , à SP. Alternativement, le module HSM SP pourra fournir cet indicateur à SP sous une forme chiffrée, , à l’aide d’un chiffrement classique (non homomorphe, asymétrique ou symétrique). Comme précédemment, le fournisseur de service SP peut ensuite retourner en 550 au serveur de calcul CS, un code d’accès (par exemple une valeur de hachage) en sus de l’indicateur de présence/absence. L’interrogation de la base de données DB selon la seconde variante est illustrée en . Un client CL peut interroger la base DB en transmettant en 560 au serveur de calcul CS, une requête chiffrée au moyen de la clé publique du premier système homomorphe, soit . Le serveur de calcul CS effectue en 570 l’opération sur la requête dans le domaine homomorphe, et obtient la réponse chiffrée . Il effectue ensuite une commutation de chiffrement en 575 de la réponse ainsi obtenue au moyen de la clé de commutation , pour obtenir . La réponse est transmise en 580, au module HSM SP , qui la déchiffre au moyen de la clé privée, , du second cryptosystème qu’il contient. Celui-ci peut la transmettre en clair ou sous forme chiffrée ( ) à l’aide d’un chiffrement classique (asymétrique non homomorphe ou symétrique) au fournisseur de service SP, en 590. Alternativement, selon une troisième variante (non représentée), la base de données pourra être chiffrée au moyen de , l’information confidentielle chiffrée transmise par le client en Fig. 5A faisant alors d’abord l’objet d’une commutation de chiffrement au moyen de , avant l’évaluation par la fonction . De manière similaire, la requête chiffrée transmise par le client en Fig. 5B pourra faire d’abord l’objet d’une commutation de chiffrement au moyen de avant l’évaluation de la fonction . L’homme du métier comprendra qu’il est alors possible de partager une même base de données entre deux fournisseurs de service distincts, le premier opérant comme décrit en relation avec les Figs. 4A et 4B et le second comme décrit en relation avec les Figs. 5A et 5B. Pour ce faire, il suffit que le module HSM SP du premier fournisseur de service transmette la clé de commutation au serveur de calcul CS, hébergeant la base BD chiffrée avec la clé du premier cryptosystème .Inversement, si la base de données est chiffrée avec la clé du second cryptosystème, il suffira que le premier fournisseur de service transmette la clé de commutation au serveur de calcul. Dans tous les cas, la présence du module HSM SP permet d’éviter la collusion entre le serveur de calcul et chacun des deux fournisseurs de service. Le risque de collusion du second-type entre client et serveur de calcul peut être écarté en adoptant un système client-serveur selon un second mode de réalisation, tel que représenté en . Dans ce mode de réalisation, le fournisseur de service SP délègue au serveur de calcul CS l’opération à effectuer sur les données confidentielles du client, . Cette opération, par exemple un modèle d’inférence dans une application d’intelligence artificielle, doit également rester confidentielle vis-à-vis du serveur de calcul. Le risque de collusion est évité ici en ce que le client dispose d’un module HSM, noté ci-après HSM CL , contenant le cryptosystème homomorphe associé au client. Le module HSM CL peut se présenter sous la forme d’une carte électronique enfichable dans l’ordinateur du client ou encore d’un boîtier externe. Il est adapté à calculer des primitives cryptographiques homomorphes et est avantageusement certifié TTP, comme HSM SP . Les paramètres de l’opération (par exemple ceux d’un modèle d’inférence) sont transmis sous forme chiffrée par le fournisseur de service SP au serveur de calcul, en 610. Lorsqu’un client CL souhaite faire exécuter l’opération sur ses données confidentielles, , il les transmet, en 615, sous forme chiffrée, au serveur de calcul. Celui-ci effectue en 620 l’opération dans le domaine homomorphe et retourne, en 630, le résultat au module HSM CL . Le module HSM CL déchiffre le résultat au moyen de la clé privée du cryptosystème homomorphe qu’il contient et le transmet en clair, , au client CL. Le cas échéant, le module HSM CL peut rechiffrer le résultat obtenu au moyen d’un chiffrement classique (asymétrique non homomorphe ou symétrique) avant de le transmettre, , au client qui le déchiffre alors à l’aide de la clé privée ou secrète correspondante. La représente un système client-serveur anti-collusion du second type, selon une variante du second mode de réalisation de l’invention. Dans cette variante, le module HSM CL du client utilise un cryptosystème distinct de celui du fournisseur de service. Plus précisément, on note ici le premier cryptosystème associé au module HSM CL et le second cryptosystème associé au serveur de calcul (ou bien, avantageusement, d’un module HSM SP non représenté). Le serveur de calcul ou bien le module HSM SP , lorsqu’il est présent, transmet en outre la clé de commutation Le fournisseur de service SP transmet en 710, sous forme chiffrée par , les paramètres de l’opération à effectuer, au serveur de calcul. Lorsqu’un client CL souhaite faire exécuter l’opération sur ses données confidentielles, , il les transmet, en 715, sous forme chiffrée, au serveur de calcul. Le module HSM CL transmet en outre la clé de commutation au serveur de calcul. En 720, le serveur de calcul effectue d’abord une commutation de chiffrement de au moyen de la clé de commutation .Il calcule ensuite l’opération dans le domaine homomorphe et obtient le résultat . Ce résultat fait ensuite l’objet d’une commutation de chiffrement en sens inverse à l’aide de la clé de commutation , ce qui conduit au résultat chiffré . Le résultat ainsi obtenu est transmis en 740 au module HSM CL qui en effectue le déchiffrement au moyen de la clé privée qu’il stocke et fournit le résultat en clair, , au client, en 750. Alternativement, postérieurement au déchiffrement, le module HSM CL peut chiffrer à nouveau le résultat au moyen d’un chiffrement classique (asymétrique non homomorphe ou symétrique) avant de le transmettre, au client qui le déchiffre avec la clé privée ou la clé secrète correspondante. Système client-serveur comprenant un client, un serveur de calcul et un fournisseur de service, ledit fournisseur de service déléguant au serveur de calcul une opération à effectuer sur des données confidentielles du client, le serveur de calcul étant adapté à effectuer (320, 620, 720) ladite opération sur les données confidentielles, chiffrées au moyen de la clé publique d’un cryptosystème homomorphe, caractérisé en ce que le fournisseur de service, respectivement le client, est équipé d’un module matériel de sécurité (HSM SP , HSM CL ) contenant ledit cryptosystème homomorphe et adapté à déchiffrer le résultat de l’opération au moyen de la clé privée du dit cryptosystème homomorphe pour le transmettre (340, 640, 740) au fournisseur de service, respectivement au client. Système client-serveur selon la revendication 1, caractérisé en ce que le client est adapté à chiffrer lesdites données confidentielles au moyen de la clé publique du cryptosystème homomorphe et les transmettre ainsi chiffrées au serveur de calcul (310, 615,715). Système client-serveur selon la revendication 2, caractérisé en ce que, le module matériel de sécurité équipant ledit client, le fournisseur de service transmet (610) au serveur de calcul les paramètres de l’opération à effectuer, chiffrés au moyen de la clé publique du cryptosystème homomorphe. Système client-serveur selon la revendication 2, caractérisé en ce que le fournisseur de service est équipé du module matériel de sécurité et que le serveur de calcul héberge une base de données chiffrée au moyen de la clé publique du cryptosytème homomorphe, l’opération étant une primitive fournissant une indication de présence ou d’absence des données confidentielles dans la base de données, le fournisseur de service renvoyant au serveur de calcul un code d’accès pour stocker les données dans la base de données si l’indicateur indique une absence dans la base de données. Système client-serveur selon la revendication 4, caractérisé en ce que, pour requêter des données confidentielles dans la base de données, un client tiers transmet au serveur de calcul une requête chiffrée (460) au moyen de la clé publique du cryptosystème homomorphe, ladite requête étant évaluée (470) dans le domaine homomorphe, le résultat de la requête étant ensuite transmis (480) au module matériel de sécurité pour y être déchiffré au moyen de la clé secrète du cryptosystème homomorphe. Système client-serveur selon la revendication 1, caractérisé en ce que le fournisseur de service est équipé du module matériel de sécurité et que le serveur de calcul héberge une base de données chiffrée au moyen de la clé publique d’un second cryptosystème homomorphe distinct du cryptosystème homomorphe stocké dans le module matériel de sécurité. Système client-serveur selon la revendication 6, caractérisé en ce que le client transmet au serveur de calcul les données confidentielles chiffrées au moyen de la clé publique du second système homomorphe et que le serveur de calcul effectue l’opération dans le domaine homomorphe du second système homomorphe, le serveur de calcul effectuant ensuite une commutation de chiffrement du résultat de l’opération pour obtenir un résultat chiffré dans le premier système homomorphe. Système client-serveur selon la revendication 7, caractérisé en ce que pour requêter des données confidentielles dans la base de données, un client tiers transmet au serveur de calcul une requête chiffrée (560) au moyen de la clé publique du second cryptosystème homomorphe, ladite requête étant évaluée (570) par le serveur dans le domaine homomorphe du second système homomorphe, puis faisant l’objet d’une commutation de chiffrement (575) vers le premier système homomorphe, le résultat chiffré de la requête étant ensuite transmis (580) au module matériel de sécurité pour y être déchiffré au moyen de la clé secrète du premier cryptosystème homomorphe. Système client-serveur selon l’une des revendications précédentes caractérisé en ce que le cryptosystème homomorphe est un cryptosystème FHE.