EP4643490A1 - Procédé et système client-serveur anti-collusion pour données chiffrées en homomorphe - Google Patents

Procédé et système client-serveur anti-collusion pour données chiffrées en homomorphe

Info

Publication number
EP4643490A1
EP4643490A1 EP23841616.8A EP23841616A EP4643490A1 EP 4643490 A1 EP4643490 A1 EP 4643490A1 EP 23841616 A EP23841616 A EP 23841616A EP 4643490 A1 EP4643490 A1 EP 4643490A1
Authority
EP
European Patent Office
Prior art keywords
client
homomorphic
server
calculation server
cryptosystem
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23841616.8A
Other languages
German (de)
English (en)
Inventor
Renaud Sirdey
Aymen BOUDGUIGA
Martin Zuber
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique CEA
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commissariat a lEnergie Atomique CEA, Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique CEA
Publication of EP4643490A1 publication Critical patent/EP4643490A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/127—Trusted platform modules [TPM]

Definitions

  • the present invention relates to the field of homomorphic encryption. It finds particular application in the field of confidential computing (Confidential Computing) and in that of the confidential creation/query of a database hosted by a remote server. STATE OF PRIOR ART The development of cloud computing combined with the confidentiality constraints of certain data have led to the development of homomorphic cryptography. In a classic application context, a client wishing to perform an operation on confidential data, encrypts this data using the public key of a recipient's homomorphic cryptosystem, and transmits it to a remote calculation server (CS).
  • CS remote calculation server
  • This calculation server performs the operation in the homomorphic domain on the encrypted data and transmits the result obtained to the recipient. He then only has to decrypt the result using the private key of his homomorphic cryptosystem to obtain the result in clear text.
  • homomorphic cryptosystem we mean here a public key-private key pair making it possible to carry out homomorphic encryption and its decryption.
  • This configuration of delegation of calculation from the client to a CS calculation server presents risks of collusion between the different entities involved. 41118 FR EA-T 2
  • Fig.1 A first case of collusion is illustrated in Fig.1 in which a client CL, a calculation server CS and a recipient of the result, here a service provider SP, are schematically represented.
  • the client CL wishing to carry out an operation f on confidential data data c encrypts them in 110 using the public key FHE. pk of the homomorphic cryptosystem ! FHE. pk, FHE. sk ⁇ of the recipient SP, and transmits them to the calculation server CS.
  • This performs the operation at 120 in the homomorphic domain on the encrypted data, namely on FHE. pk ! data c ⁇ .
  • pk (res c ) is transmitted in 130 to the recipient SP who decrypts them in 140 using its private key to obtain the result in clear
  • the calculation server can in fact transmit the FHE encrypted data directly. pk ! data c ⁇ to the recipient, in which case the latter can access the data in clear data c by decrypting it with the private key FHE. sk.
  • this data is confidential and must under no circumstances be transmitted to the recipient of the result (service provider).
  • a second type of collusion is illustrated in Fig. 2, the entities involved in the configuration shown being identical to those in FIG. 1. We assume here that the client CL and the calculation server CS are honest but curious.
  • the recipient of the result is none other than the client CL, the service provider SP providing the calculation server CS 25 with the operation f (for example an inference operation or a search operation in a database). confidential data of SP) to be carried out in the homomorphic domain.
  • the operation f is confidential with respect to the server 41118 FR EA-T 3 CS calculation and the homomorphic cryptosystem ! FHE. pk', FHE. sk ' ⁇ is that of the client CL.
  • the service provider, SP transmits at 210, to the calculation server CS, the expression of the operation f in question in the homomorphic domain, i.e. 5 FHE. pk'(f).
  • the client CL transmits confidential data c encrypted using the public key FHE to the calculation server at 220.
  • pk ' the latter performs in 230 the operation in the homomorphic domain on the encrypted data, namely FHE. pk' ! data c ⁇ .
  • the FHE result. pk '(res c ) is returned to the client CL in 240 which decrypts them in 250 using its private key to obtain the result in clear res c .
  • Collusion can occur between the client CL and the calculation server CS in that the second transmits to the first the encrypted operation, FHE. pk '(f), the client CL can then discover the operation f which is delegated to the server CS by the service provider SP.
  • the object of the present invention is therefore to propose a client-server system making it possible to avoid the risks of collusion between the different entities of this system while overcoming the disadvantages of the state of the art, in other words which is simple and robust to the aforementioned attacks.
  • the present invention is defined by a client-server system 20 comprising a client, a calculation server and a service provider, said service provider delegating to the calculation server an operation to be performed on confidential data of the client , the calculation server being adapted to perform said operation on the confidential data, encrypted by means of the public key of a homomorphic cryptosystem, said client-server system 25 being original in that the service provider, respectively the client, is equipped with a hardware security module (HSM SP , HSM CL ) containing said homomorphic cryptosystem and adapted to decipher the result of the operation 41118 FR EA-T 5 means of the private key of said homomorphic cryptosystem to transmit it to the service provider, respectively to the client.
  • HSM SP hardware security module
  • HSM CL hardware security module
  • the client is adapted to encrypt said confidential data by means of the public key of the homomorphic cryptosystem and thus transmit them encrypted to the calculation server.
  • the hardware security module equips said client and the service provider transmits to the calculation server the parameters of the operation to be carried out, encrypted by means of the public key of the homomorphic cryptosystem.
  • the service provider is equipped with the security hardware module and the calculation server hosts a database encrypted by means of the public key of the homomorphic cryptosystem, the operation being a primitive providing an indication of presence or absence of confidential data in the database, the service provider sending back to the calculation server an access code to store the data in the database if the indicator indicates an absence in the database.
  • a third party client transmits to the calculation server a request encrypted by means of the public key of the homomorphic cryptosystem, said request being evaluated in the homomorphic domain, the result of the request being then transmitted to the hardware security module to be decrypted using the secret key of the homomorphic cryptosystem.
  • the service provider is equipped with the security hardware module and the calculation server hosts a database encrypted by means of the public key of a second homomorphic cryptosystem distinct from the stored homomorphic cryptosystem in the security hardware module.
  • the client transmits to the calculation server the confidential data encrypted by means of the public key of the second homomorphic system and the calculation server carries out the operation in the homomorphic domain of the second homomorphic system, the calculation server then performing an encryption switch of the result of the operation to obtain an encrypted result in the first homomorphic system.
  • a third party client can transmit to the calculation server a request encrypted by means of the public key of the second homomorphic cryptosystem, said request then being evaluated by the server in the homomorphic domain of the second system homomorphic, then subject to encryption switching to the first homomorphic system, the encrypted result of the request then being transmitted to the hardware security module to be decrypted there by means of the secret key of the first homomorphic cryptosystem.
  • the homomorphic cryptosystem is preferably an FHE cryptosystem.
  • FIG. 1 schematically represents an anti-collusion client-server system of the first type, according to a first embodiment of the invention
  • Figs. 4A and 4B schematically represent the creation and querying of a private database using a client-server system according to the first embodiment of the invention
  • Figs. 5A and 5B schematically represent the creation and querying of a private database using a client-server system according to a variant of the first embodiment of the invention
  • FIG. 6 schematically represents an anti-collusion client-server system of the second type, according to a second embodiment of the invention
  • FIG. 7 schematically represents an anti-collusion client-server system of the second type, according to a variant of the second embodiment of the invention.
  • DETAILED DESCRIPTION OF PARTICULAR EMBODIMENTS We consider below a client-server system having a basic configuration identical to that described previously, in other words20 comprising a client CL, a service provider SP delegating an operation f (in the homomorphic domain) to a CS calculation server. In all cases, the client transmits confidential data, data c , to the calculation server, encrypted using the public key of a homomorphic cryptosystem, whether that of the service provider ! FHE.
  • the idea behind the present invention is to add a hardware security module (also sometimes called security transactional box) or HSM (Hardware Security Module), TTP (Trusted Third Party) certified.
  • a hardware security module also sometimes called security transactional box
  • HSM Hard Security Module
  • TTP Trusted Third Party
  • this HSM module being the only element of the system to be able to have access to the private key of the homomorphic cryptosystem used to encrypt the client's data (prevention of a collusion of the first type) or to encrypt the parameters of the operation delegated by the service provider (prevention of a collusion of the second type).
  • the entity receiving the encrypted information cannot directly access the private key of the homomorphic system 10 and the 'use for purposes other than deciphering said information.
  • collusion of the first type is avoided in that the service provider SP cannot use the private key FHE. sk to decrypt FHE encrypted confidential data. pk ! data c ⁇ that the calculation server could transmit to it. Even assuming that the service provider is malicious, it will not be able to transmit the FHE private key. sk to the calculation server so that it decrypts them.
  • collusion of the second type is avoided in that the client cannot use the FHE private key. sk ' to decipher the parameters of the operation (eg the parameters of the inference model or the search operation) that the calculation server could transmit to it. Even assuming that the client is malicious, it will not be able to transmit its FHE private key.
  • FIG. 3 schematically represents an anti-collusion client-server system 25 of the first type, according to a first embodiment of the invention.
  • the recipient of the result of operation f on the client's confidential data, data c namely the service provider SP has an HSM module (Hardware Security Module), denoted HSM SP .
  • HSM module Hardware Security Module
  • HSM SP Hardware Security Module
  • This module is chosen TTP certified, in other words it is authorized to carry out cryptographic operations as a trusted third party.
  • the HSM SP module generates the public and private key pair of the homomorphic cryptosystem ! FHE. pk, FHE. sk ⁇ , the public key is shared with the client CL and the calculation server CS.
  • the client CL wishing to perform an operation f on confidential data data c encrypts them in 310 using the public key FHE. pk of the homomorphic cryptosystem and transmits them to the CS calculation server. This performs the operation in 320 in the homomorphic domain on the encrypted data, and the result f ! FHE. pk ! data c ⁇ ⁇ # FHE .
  • pk (res c ) is transmitted in 330 to the HSM module which decrypts them using the private key FHE. sk stored there.
  • the result is provided in clear or even encrypted form (denoted ⁇ res c% ) to the service provider SP.
  • This encryption can be a classic asymmetric encryption (non-homomorphic) or a symmetric encryption.
  • the presence of the HSMSP module prevents any collusion between the CS calculation server and the SP service provider since the latter no longer has access to the FHE decryption key. sk.
  • the HSM SP module ensures, before providing the decryption result to SP, that the latter corresponds to the expected format of the operation f.
  • VC Verifiable Computing
  • the result could be res c # 0 if the confidential information is absent and res c # 1 if this information is already present in a database record.
  • a client wants to create a new record in the database, it transmits the FHE encrypted information in 410. pk (data c ) to the calculation server, hosting the database. This is assumed to be stored in encrypted form by the public key of the homomorphic cryptosystem, i.e. FHE. pk(DB).
  • the calculation server evaluates at 420 the function f in the homomorphic domain and determines whether the information is present there.
  • the function f can for example be a PIR (Private Information Retrieval) protocol primitive.
  • the result of the evaluation in the homomorphic domain i.e. f ! FHE. pk (data c ) ⁇ # FHE. pk ! res c ⁇ , is transmitted in 430 to the HSMSP module of the 20 service provider SP.
  • the HSM SP module decrypts the result using the FHE private key. sk which is stored there and provides at 440 to SP the presence/absence indicator of the recording, i.e. res c .
  • the HSM SP module encrypts this indicator using the public key of a classic asymmetric encryption (non-homomorphic) or the secret key of a symmetric encryption before providing it, ⁇ res c% to SP.
  • the service provider SP can then return at 450 to the calculation server CS, an access code (for example a hash value) in addition to the presence/absence indicator.
  • an access code for example a hash value
  • the indicator can be transmitted in plain text or in encrypted form (using conventional encryption) to the calculation server.
  • the DB database can be updated by storing the data c information at the address encoded by the access code.
  • the calculation server CS performs the operation f on the request req c to evaluate in 10 470 the response in this domain, namely FHE. pk ! rep c ⁇ # f ! FHE. pk ! req c ⁇ ⁇ .
  • the response is transmitted at 480 to the HSM SP module, which decrypts it using the private key FHE. sk it contains.
  • the latter can transmit it in plain text or in encrypted form ( ⁇ rep c% ) using conventional encryption (asymmetric non-homomorphic or symmetric) to the service provider SP, in 490.
  • the base DB data hosted by the CS calculation server can be encrypted using (the public key) a homomorphic cryptosystem distinct from that stored in the HSM SP module. More precisely, we will note ! FHE. pk 1 , FHE. sk 1 ⁇ the first cryptosystem associated with the de20 calculation server and ! FHE. pk 2 , FHE. sk 2 ⁇ the second cryptosystem associated with the HSM SP module of the service provider.
  • the creation of the DB database according to this variant of the anti-collusion client-server system is illustrated in Fig.5A. The CL client encrypts using the FHE public key.
  • pk 1 the confidential information data c and transmits it in 510 to the calculation server CS whose database is itself stored in encrypted form by the FHE key. pk 1 .
  • THE 41118 FR EA-T 12 calculation server also has a switching key
  • the calculation server evaluates at 520 the function f on the data entry c in the homomorphic domain to determine if this information is present in a record of the base. The result of this evaluation f ! FHE. pk 1! data c ⁇ ⁇ # FHE . pk 1 (res c ) is then subject, in 525, to encryption switching in the homomorphic domain by means of the switching key KS 12 # FHE. pk 2! FHE. sk 1 ⁇ .
  • the HSM SP module can provide this indicator to SP in encrypted form, ⁇ res c% , using conventional encryption (non-homomorphic, asymmetric or symmetric).
  • the service provider SP can then return at 550 to the calculation server CS, an access code (for example a hash value) in addition to the presence/absence indicator.
  • an access code for example a hash value
  • 25 Querying the DB database according to the second variant is illustrated in Fig.5B.
  • a CL client can query the DB base by transmitting in 560 to the CS calculation server, a request encrypted using the public key of the first 41118 FR EA-T 13 homomorphic system, i.e. FHE. pk 1! req c ⁇ .
  • the calculation server CS performs at 570 the operation f on the query req c in the homomorphic domain, and obtains the encrypted response FHE. pk 1! rep c ⁇ # f ! FHE. pk 1! req c ⁇ ⁇ . It then carries out an encryption switch at 575 of the response thus obtained by means of the 5 switching key KS 12 , to obtain FHE. pk 2! rep c ⁇ .
  • the response is transmitted at 580 to the HSM SP module, which decrypts it using the private key, FHE. pk 2 , of the second cryptosystem it contains.
  • the latter can transmit it in clear or encrypted form ( ⁇ rep c% ) using conventional encryption (asymmetric non-homomorphic or symmetric) to the service provider SP, in 590.
  • the database can be encrypted using FHE. pk 2 , the confidential information encrypted FHE. pk 1! data c ⁇ transmitted by the client in Fig.5A then first subject to encryption switching by means of KS 12 , 15 before evaluation by the function f.
  • the FHE encrypted query. pk 1! req c ⁇ transmitted by the client in Fig. 5B may first be subject to encryption switching using KS 12 before evaluating the function f.
  • the presence of the HSM SP module makes it possible to avoid collusion between the calculation server and each of the two service providers.
  • the risk of collusion of the second type between client and calculation server can be avoided by adopting a client-server system according to a second embodiment, as shown in Fig.6. 10
  • the service provider SP delegates to the calculation server CS the operation f to be performed on the client's confidential data, data c .
  • This operation for example an inference model in an artificial intelligence application, must also remain confidential to the calculation server.
  • the risk of collusion is avoided here in that the client has an HSM module, hereinafter noted HSM CL , containing the homomorphic cryptosystem !FHE.
  • the HSM CL module can be in the form of an electronic card that can be plugged into the customer's computer or an external box. It is suitable for calculating homomorphic cryptographic primitives and is advantageously TTP certified, like HSM SP .
  • the parameters of the operation f (for example those of an inference model) are transmitted in encrypted form by the service provider SP to the calculation server, in 610.
  • data c When a client CL wishes to execute the operation on his confidential data, data c , he transmits them, in 615, in encrypted form, FHE. pk' ! data c ⁇ to the calculation server.
  • the HSM CL module decrypts the result using the FHE private key. sk' of the homomorphic cryptosystem that it contains and transmits it in clear, res c , to the 5 CL client. If necessary, the HSM CL module can re-encrypt the result obtained using conventional encryption (non-homomorphic asymmetric or symmetric) before transmitting it, ⁇ res c% , to the client who then decrypts it using the key corresponding private or secret. 10 Fig.
  • the client's HSM CL module uses a cryptosystem distinct from that of the service provider. More precisely, we note here !FHE. pk'1 , FHE. sk ' 1 ⁇ the first cryptosystem associated with the HSM CL module and 15 ! FHE. pk'2 , FHE. sk ' 2 ⁇ the second cryptosystem associated with the calculation server (or, advantageously, an HSM SP module not shown).
  • the calculation server or the HSM SP module when present, also transmits the switching key KS ' 2 1 # FHE. pk ' 1 ! FHE.
  • the service provider SP transmits in 710, in encrypted form par20 FHE. pk ' 2 , the parameters of the operation f to be performed, to the calculation server.
  • FHE. pk ' 2 the parameters of the operation f to be performed
  • the HSM CL module additionally transmits the switching key KS ' 1 2 # FHE. pk ' 2! FHE. sk ' 1 ⁇ to the calculation server. 25
  • the calculation server first performs an FHE encryption switch. pk ' !
  • the HSM CL module can re-encrypt the result res c by means of a classic encryption (asymmetric non-homomorphic or symmetric) before transmitting it, ⁇ res c% to the client who decrypts it with the private key10 or the corresponding secret key.
  • a classic encryption asymmetric non-homomorphic or symmetric

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

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 HSMSP équipant ce dernier. Ledit module HSMSP 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 HSMCL équipant ce dernier. Ledit module HSMCL 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.

Description

PROCÉDÉ ET SYSTÈME CLIENT-SERVEUR ANTI-COLLUSION POUR DONNÉES CHIFFRÉES EN HOMOMORPHE DESCRIPTION DOMAINE TECHNIQUE 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. 41118 FR EA-T 2 Un premier cas de collusion est illustré en Fig.1 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. 5 Le client CL souhaitant effectuer une opération f sur des données confidentielles data c les chiffre en 110 au moyen de la clé publique FHE . pk du cryptosystème homomorphe !FHE. pk , FHE . sk ∀ 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 FHE. pk ! data c ∀ . Le 10 résultat f ! FHE. pk ! datac ∀ ∀# FHE . pk ( res c ) 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 15 directement les données chiffrées FHE. pk ! data c ∀ au destinataire, auquel cas ce dernier peut accéder aux données en clair data c en les déchiffrant avec la clé privée FHE . sk . Or ces données sont confidentielles et ne doivent en aucun cas être transmises au destinataire du résultat (fournisseur de service). 20 Un second type de collusion est illustré en Fig. 2, les entités intervenant dans la configuration représentée étant identiques à celles de la Fig. 1. 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 25 l’opération f (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 f est confidentielle vis-à-vis du serveur de 41118 FR EA-T 3 calcul CS et le cryptosystème homomorphe !FHE. pk ', FHE . sk ' ∀ est celui du client CL. Le fournisseur de service, SP, transmet en 210, au serveur de calcul CS, l’expression de l’opération f en question dans le domaine homomorphe, soit 5 FHE . pk '( f ). Lorsque le client CL transmet au serveur de calcul en 220 des données confidentielles data c chiffrées au moyen de la clé publique FHE . pk ' , ce dernier effectue en 230 l’opération dans le domaine homomorphe sur les données chiffrées, à savoir FHE. pk ' ! data c ∀ . Le résultat FHE . pk '( resc ) est retourné au client CL en 240 qui les déchiffre en 250 à l’aide de sa clé privée pour 10 obtenir le résultat en clair res c . 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, FHE . pk '( f ) , le client CL pouvant alors découvrir l’opération f 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 15 dans une base de données confidentielles, par exemple une base de données biométriques chiffrées par FHE . pk '( f ) , 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-20 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 25 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. 41118 FR EA-T 4 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 5 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 10 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 15 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. EXPOSÉ DE L’INVENTION La présente invention est définie par un système client-serveur 20 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 25 étant original en ce que le fournisseur de service, respectivement le client, est équipé d’un module matériel de sécurité (HSMSP, HSMCL) contenant ledit cryptosystème homomorphe et adapté à déchiffrer le résultat de l’opération au 41118 FR EA-T 5 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 5 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 du10 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 15 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 20 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. 25 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é. 41118 FR EA-T 6 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 5 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 10 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. 15 Le cryptosystème homomorphe est de préférence un cryptosystème FHE. BRÈVE DESCRIPTION DES DESSINS D’autres caractéristiques et avantages de l’invention apparaîtront à la 20 lecture d’un mode de réalisation préférentiel de l’invention, fait en référence aux figures jointes parmi lesquelles : La Fig. 1, 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 ; 25 La Fig. 2, déjà décrite, représente un second type de collusion entre un client et un serveur de calcul dans une architecture client-serveur ; 41118 FR EA-T 7 La Fig. 3 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 ; Les Figs. 4A et 4B représentent de manière schématique la création et 5 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 ; Les Figs. 5A et 5B 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 ; 10 La Fig. 6 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 ; La Fig. 7 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éalisation15 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 dit20 comprenant un client CL, un fournisseur de service SP déléguant une opération f (dans le domaine homomorphe) à un serveur de calcul CS. Dans tous les cas, le client transmet au serveur de calcul des données confidentielles, data c , chiffrées au moyen de la clé publique d’un cryptosystème homomorphe, que ce soit celui du fournisseur de service ! FHE. pk , FHE . sk ∀ ou son propre cryptosystème25 !FHE. pk ', FHE . sk ' ∀ . 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) 41118 FR EA-T 8 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 5 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 10 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 FHE . sk pour déchiffrer les données confidentielles chiffrées FHE. pk ! data c ∀ que pourrait lui transmettre le serveur de calcul. A supposer même que le fournisseur de service soit 15 malicieux, il ne pourra pas davantage transmettre la clé privée FHE . sk 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 FHE . sk ' 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 20 le serveur de calcul. A supposer même que le client soit malicieux, il ne pourra pas davantage transmettre sa clé privée FHE . sk ' au serveur de calcul pour que celui déchiffre les paramètres en question. La Fig. 3 représente de manière schématique un système client-serveur 25 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 f sur les données confidentielles du client, data c , à savoir le fournisseur de service SP dispose d’un module HSM (Hardware Security Module), noté HSMSP. On 41118 FR EA-T 9 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 HSMSP génère le couple de clés publique et privée du cryptosystème homomorphe ! FHE. pk , FHE . sk ∀ , 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 f sur des données confidentielles data c les chiffre en 310 au moyen de la clé publiqueFHE . pk 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 f ! FHE. pk ! data c ∀ ∀ # FHE . pk ( res c ) est transmis en 330 au module HSM qui les déchiffre au moyen de la clé privée FHE . sk qui y est stockée. A l’étape 340, le résultat est fourni en clair voire sous forme chiffrée (notée ∃resc % ) 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 HSMSP 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 FHE . sk. De préférence, le module HSMSP s’assure, avant de fournir le résultat du déchiffrement à SP, que ce dernier correspond bien au format attendu de l’opération f . A cette fin, on pourra recourir à des fonctions de calcul dites vérifiables ou VC (Verifiable Computing) permettant de prouver que l’opération f a bien été effectuée correctement. Cette mesure permet d’éviter que le module HSMSP soit utilisé comme oracle de déchiffrement, c’est-à-dire qu’il 41118 FR EA-T 10 déchiffre n’importe quel message qui lui serait transmis dans le but d’obtenir des informations sur la clé FHE . sk . 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 f 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 resc # 0 si l’information confidentielle est absente et resc # 1 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 FHE . pk ( datac ) 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, soitFHE . pk ( DB ) . Le serveur de calcul évalue en 420 la fonction f dans le domaine homomorphe et détermine si l’information y est présente. La fonction f peut être par exemple une primitive de protocole PIR (Private Information Retrieval). Le résultat de l’évaluation dans le domaine homomorphe, soit f ! FHE. pk ( datac ) ∀# FHE . pk ! res c ∀ , est transmis en 430 au module HSMSP du 20 fournisseur de service SP. Le module HSMSP déchiffre le résultat au moyen de la clé privée FHE . sk qui y est stockée et fournit en 440 à SP l’indicateur de présence/absence de l’enregistrement, soit res c . Optionnellement, le module HSMSP 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, ∃resc % à 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 41118 FR EA-T 11 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 data c à 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 FHE. pk ! req c ∀ . Le serveur de calcul CS effectue l’opération f sur la requête req c pour évaluer en 10 470 la réponse dans ce domaine, à savoir FHE. pk ! repc ∀# f ! FHE . pk ! req c ∀ ∀. La réponse est transmise en 480, au module HSMSP, qui la déchiffre au moyen de la clé privée FHE . sk qu’il contient. Celui-ci peut la transmettre en clair ou sous forme chiffrée (∃repc % ) à l’aide d’un chiffrement classique (asymétrique non homomorphe ou symétrique) au fournisseur de service SP, en 490. 15 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 HSMSP. Plus précisément, on notera !FHE. pk1 , FHE . sk 1 ∀ le premier cryptosystème associé au serveur de20 calcul et !FHE. pk2 , FHE . sk 2 ∀ le second cryptosystème associé au module HSMSP 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 Fig.5A. Le client CL chiffre à l’aide la clé publique FHE. pk 1 l’information confidentielle data c 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é FHE. pk 1. Le 41118 FR EA-T 12 serveur de calcul dispose en outre d’une clé de commutation Comme précédemment, le serveur de calcul évalue en 520 la fonction f sur l’entrée data c dans le domaine homomorphe pour déterminer si cette 5 information est présente dans un enregistrement de la base. Le résultat de cette évaluation f ! FHE. pk1 ! datac ∀ ∀# FHE . pk 1 ( res c ) fait ensuite l’objet, en 525, d’une commutation de chiffrement dans le domaine homomorphe au moyen de la clé de commutation KS12# FHE. pk 2 ! FHE . sk 1 ∀. Différentes techniques de commutation de chiffrement (Key Switching) sont connues de l’état de la 10 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, FHE. pk 2 ( resc ) est ensuite15 transmis en 530 au module HSMSP. Le module HSMSP 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, res c , à SP. Alternativement, le module HSMSP pourra fournir cet indicateur à SP sous une forme chiffrée, ∃resc % , à l’aide d’un chiffrement classique (non homomorphe,20 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. 25 L’interrogation de la base de données DB selon la seconde variante est illustrée en Fig.5B. 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 41118 FR EA-T 13 système homomorphe, soit FHE. pk1 ! req c ∀ . Le serveur de calcul CS effectue en 570 l’opération f sur la requête req c dans le domaine homomorphe, et obtient la réponse chiffrée FHE. pk1 ! repc ∀# f ! FHE . pk 1 ! req c ∀ ∀ . Il effectue ensuite une commutation de chiffrement en 575 de la réponse ainsi obtenue au moyen de la 5 clé de commutation KS 12 , pour obtenir FHE. pk2 ! rep c ∀. La réponse est transmise en 580, au module HSMSP, qui la déchiffre au moyen de la clé privée, FHE. pk 2 , du second cryptosystème qu’il contient. Celui- ci peut la transmettre en clair ou sous forme chiffrée (∃repc % ) à l’aide d’un chiffrement classique (asymétrique non homomorphe ou symétrique) au10 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 FHE. pk 2 , l’information confidentielle chiffrée FHE. pk1 ! data c ∀ transmise par le client en Fig.5A faisant alors d’abord l’objet d’une commutation de chiffrement au moyen de KS 12 , 15 avant l’évaluation par la fonction f . De manière similaire, la requête chiffrée FHE. pk1 ! req c ∀ transmise par le client en Fig. 5B pourra faire d’abord l’objet d’une commutation de chiffrement au moyen de KS 12 avant l’évaluation de la fonction f . 20 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 HSMSP du premier fournisseur de service transmette la clé de commutation 25 KS12# FHE. pk 2 ! FHE . sk 1 ∀ au serveur de calcul CS, hébergeant la base BD chiffrée avec la clé du premier cryptosystème FHE. pk 1.Inversement, si la base 41118 FR EA-T 14 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 KS21# FHE. pk 1 ! FHE . sk 2 ∀ au serveur de calcul. Dans tous les cas, la présence du module HSMSP permet d’éviter la collusion entre le serveur de calcul et chacun 5 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 Fig.6. 10 Dans ce mode de réalisation, le fournisseur de service SP délègue au serveur de calcul CS l’opération f à effectuer sur les données confidentielles du client, data c . 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. 15 Le risque de collusion est évité ici en ce que le client dispose d’un module HSM, noté ci-après HSMCL, contenant le cryptosystème homomorphe !FHE. pk ', FHE . sk ' ∀ associé au client. Le module HSMCL 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 20 cryptographiques homomorphes et est avantageusement certifié TTP, comme HSMSP. Les paramètres de l’opération f (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, data c , il les transmet, en 615, sous forme chiffrée, FHE. pk ' ! data c ∀ au serveur de calcul. Celui-ci effectue en 620 l’opération f 41118 FR EA-T 15 dans le domaine homomorphe et retourne, en 630, le résultat module HSMCL. Le module HSMCL déchiffre le résultat au moyen de la clé privée FHE . sk ' du cryptosystème homomorphe qu’il contient et le transmet en clair, res c, au 5 client CL. Le cas échéant, le module HSMCL peut rechiffrer le résultat obtenu au moyen d’un chiffrement classique (asymétrique non homomorphe ou symétrique) avant de le transmettre, ∃resc % , au client qui le déchiffre alors à l’aide de la clé privée ou secrète correspondante. 10 La Fig. 7 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 HSMCL du client utilise un cryptosystème distinct de celui du fournisseur de service. Plus précisément, on note ici !FHE. pk '1 , FHE . sk ' 1 ∀ le premier cryptosystème associé au module HSMCL et 15 !FHE. pk '2 , FHE . sk ' 2 ∀ le second cryptosystème associé au serveur de calcul (ou bien, avantageusement, d’un module HSMSP non représenté). Le serveur de calcul ou bien le module HSMSP, lorsqu’il est présent, transmet en outre la clé de commutation KS' 21# FHE. pk ' 1 ! FHE . sk ' 2 ∀ Le fournisseur de service SP transmet en 710, sous forme chiffrée par20 FHE. pk ' 2 , les paramètres de l’opération f à effectuer, au serveur de calcul. Lorsqu’un client CL souhaite faire exécuter l’opération sur ses données confidentielles, data c , il les transmet, en 715, sous forme chiffrée, FHE. pk' 1 ! data c ∀ au serveur de calcul. Le module HSMCL transmet en outre la clé de commutation KS' 12# FHE. pk ' 2 ! FHE . sk ' 1 ∀ au serveur de calcul. 25 En 720, le serveur de calcul effectue d’abord une commutation de chiffrement de FHE. pk' ! dat KS ' 1 a c ∀ au moyen de la clé de commutation 12.Il calcule ensuite l’opération f dans le domaine homomorphe et obtient le 41118 FR EA-T 16 résultat Ce résultat fait ensuite l’objet d’une commutation de chiffrement en sens inverse à l’aide de la clé de commutation KS ' , ce qui conduit au résultat ch ' 21 iffré FHE. pk1 ! res c ∀. Le résultat ainsi obtenu est transmis en 740 au module HSMCL qui en effectue le yen de la clé privée FHE . s ' 5 déchiffrement au mo k 1 qu’il stocke et fournit le résultat en clair, res c , au client, en 750. Alternativement, postérieurement au déchiffrement, le module HSMCL peut chiffrer à nouveau le résultat res c au moyen d’un chiffrement classique (asymétrique non homomorphe ou symétrique) avant de le transmettre, ∃resc % au client qui le déchiffre avec la clé10 privée ou la clé secrète correspondante.

Claims

41118 FR EA-T 17 REVENDICATIONS 1. Système client-serveur comprenant un client, un serveur de calcul et 5 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,10 respectivement le client, est équipé d’un module matériel de sécurité (HSMSP, HSMCL) 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. 15 2. 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). 20 3. 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. 4. 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 41118 FR EA-T 18 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. 5. 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) 10 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. 6. Système client-serveur selon la revendication 1, caractérisé en ce que 15 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é. 20 7. 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 25 chiffrement du résultat de l’opération pour obtenir un résultat chiffré dans le premier système homomorphe. 8. 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 41118 FR EA-T 19 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 5 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. 9. Système client-serveur selon l’une des revendications précédentes10 caractérisé en ce que le cryptosystème homomorphe est un cryptosystème FHE.
EP23841616.8A 2022-12-29 2023-12-26 Procédé et système client-serveur anti-collusion pour données chiffrées en homomorphe Pending EP4643490A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2214638A FR3144732A1 (fr) 2022-12-29 2022-12-29 Procédé et système client-serveur anti-collusion pour données chiffrées en homomorphe
PCT/FR2023/052123 WO2024141743A1 (fr) 2022-12-29 2023-12-26 Procédé et système client-serveur anti-collusion pour données chiffrées en homomorphe

Publications (1)

Publication Number Publication Date
EP4643490A1 true EP4643490A1 (fr) 2025-11-05

Family

ID=86468730

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23841616.8A Pending EP4643490A1 (fr) 2022-12-29 2023-12-26 Procédé et système client-serveur anti-collusion pour données chiffrées en homomorphe

Country Status (3)

Country Link
EP (1) EP4643490A1 (fr)
FR (1) FR3144732A1 (fr)
WO (1) WO2024141743A1 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110213231B (zh) * 2019-04-26 2021-11-30 西安电子科技大学 一种面向sgx的轻量级的外包数据访问控制方法及控制系统

Also Published As

Publication number Publication date
WO2024141743A1 (fr) 2024-07-04
FR3144732A1 (fr) 2024-07-05

Similar Documents

Publication Publication Date Title
CN102318262B (zh) 受信云计算和服务框架
EP2323306B1 (fr) Procédé de transmission de données sécurisé et système de chiffrement et de déchiffrement permettant une telle transmission
EP3535923A1 (fr) Méthode de classification sécurisée utilisant une opération de transchiffrement
FR2930390A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise.
EP3840287B1 (fr) Plateforme securisee, decentralisee, automatisee et multi-acteurs de gestion d'identites d'objets au travers de l'utilisation d'une technologie de chaine de blocs
EP3391585B1 (fr) Procédé de sécurisation d'un enregistrement de contenu multimédia dans un support de stockage
EP3734901B1 (fr) Procédé de transmission sécurisée de données
CA3142763C (fr) Procede de chiffrement et de stockage de fichiers informatiques et dispositif de chiffrement et de stockage associe.
FR2930391A1 (fr) Terminal d'authentification d'un utilisateur.
CA2895189C (fr) Signature de groupe utilisant un pseudonyme
FR2898747A1 (fr) Procede de chiffrement cherchable dechiffrable, systeme pour un tel chiffrement
EP3724799A1 (fr) Technique de protection d'une clé cryptographique au moyen d'un mot de passe utilisateur
EP2919412B1 (fr) Procédé et système de chiffrement/déchiffrement de données à clé distante et vérification préalable de jeton
EP4241416B1 (fr) Procede de delegation d'acces a une chaine de blocs
FR3057122B1 (fr) Procede et dispositif de detection d'intrusions sur un reseau utilisant un algorithme de chiffrement homomorphe
WO2024141743A1 (fr) Procédé et système client-serveur anti-collusion pour données chiffrées en homomorphe
FR2892876A1 (fr) Procede de depot securise de donnees numeriques, procede associe de recuperation de donnees numeriques, dispositifs associes pour la mise en oeuvre des procedes, et systeme comprenant les dits dispositifs
WO2023001514A1 (fr) Sécurité des données
FR3108818A1 (fr) Procédé et dispositif d’authentification d’un utilisateur auprès d’une application.
FR3146777A1 (fr) procédé de certification de partage d’un fichier, procédé de confirmation de partage d’un fichier et dispositifs correspondants
FR3142314A1 (fr) Système de chiffrement hiérarchique hybride
EP4629558A1 (fr) Procédé et dispositif de communication sécurisé utilisant un identifiant dérivé de manière déterministe
WO2023062095A1 (fr) Procédé et dispositif de transfert d'une communication d'une station de base à une autre
FR3039022A1 (fr) Methode de delegation securisee de calculs couteux pour algorithmes de chiffrement a cle publique
HK1251369B (zh) 基於多重加密的消息传输方法及装置

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250703

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR