Chiffrement homomorphe dans le cloud : promesses et limites réelles

Éditorial

Enquête sur le chiffrement homomorphe présenté comme la solution ultime à la confidentialité des calculs cloud, face aux coûts de performance qui le cantonnent à des cas de niche.

~8 min de lecture8 sections

Chiffrement homomorphe dans le cloud : promesses et limites réelles

Le chiffrement homomorphe permet à un serveur de calculer sur des données qu’il ne peut pas lire : il reçoit des chiffrés, renvoie un chiffré, et seul le client déchiffre le résultat. Sur le papier, externaliser un calcul n’exige plus de faire confiance à l’hébergeur. En pratique, la facture en temps de calcul, en mémoire et en complexité le cantonne à quelques usages étroits, et cette situation dure depuis bien plus longtemps que ses annonces de démocratisation.

Explication de la marmotte

On confie un coffre fermé à un artisan en lui demandant de réparer l’objet à l’intérieur sans jamais l’ouvrir, en travaillant à travers des gants fixés à la paroi. Il rend le coffre toujours fermé, avec l’objet réparé. Le résultat est parfait pour la discrétion ; reste à savoir combien de temps prend la réparation à travers les gants.

→ Lire l’explication complète de la marmotte

La promesse du chiffrement homomorphe complet

Les schémas partiellement homomorphes existent depuis longtemps : RSA (Rivest-Shamir-Adleman) sans bourrage multiplie des chiffrés, Paillier (1999) les additionne. La rupture date de 2009, quand Craig Gentry construit le premier FHE (Fully Homomorphic Encryption), capable d’évaluer n’importe quel circuit. Chaque chiffré, fondé sur les réseaux euclidiens, porte un bruit qui grossit à chaque opération, surtout à chaque multiplication. Au-delà d’un seuil, le déchiffrement échoue. Le bootstrapping, qui réévalue homomorphiquement le déchiffrement pour remettre le bruit à zéro, rend le calcul illimité.

La première implémentation, en 2011, demandait une trentaine de minutes par bootstrapping. Les générations suivantes ont apporté des gains réels : BGV (Brakerski-Gentry-Vaikuntanathan) et BFV (Brakerski-Fan-Vercauteren) pour l’arithmétique entière exacte, CKKS (Cheon-Kim-Kim-Song, 2017) pour les nombres approchés utiles à l’apprentissage automatique, TFHE (Torus FHE) pour le calcul booléen avec un bootstrapping de l’ordre de la dizaine de millisecondes par porte logique. Plusieurs ordres de grandeur gagnés : c’est remarquable. La démocratisation du FHE, elle, est imminente depuis 2009, ce qui en fait l’une des imminences les plus stables du secteur.

Le coût réel : bruit, profondeur multiplicative et expansion

Le compromis central tient en une phrase : on gagne une confidentialité qui ne dépend ni de l’opérateur ni du matériel, on la paie par un surcoût de quatre à six ordres de grandeur sur un calcul générique. Les causes sont structurelles.

• Pas de branchement. Le serveur ne voit pas les valeurs, donc ne peut pas choisir une branche : un if s’évalue des deux côtés, une boucle s’exécute toujours dans son pire cas. Tri, jointure et recherche perdent leur efficacité.
• Profondeur multiplicative. Les paramètres se dimensionnent selon le nombre de multiplications enchaînées. Une fonction de profondeur élevée impose de grands paramètres ou des bootstrappings coûteux ; les comparaisons, triviales en clair, sont chères en BFV et en CKKS.
• Expansion. Un chiffré FHE pèse plusieurs mégaoctets (il transporte certes des milliers de valeurs par empaquetage) et les clés d’évaluation envoyées au serveur atteignent des centaines de mégaoctets. La bande passante devient un poste de coût au même titre que le processeur.
• Approximation. CKKS renvoie un résultat approché : acceptable pour un score, pas pour un solde bancaire.

Les accélérateurs matériels dédiés figurent sur les feuilles de route depuis des années, et sur les étagères des fournisseurs cloud beaucoup moins.

Où le chiffrement homomorphe fonctionne vraiment

Les déploiements qui tiennent partagent un profil : fonction petite et figée, profondeur faible, clé côté client, serveur à qui l’on ne confie rien.

• Recherche privée d’information (PIR, Private Information Retrieval) : interroger une base sans révéler la clé cherchée, par exemple vérifier si un mot de passe figure dans une base de fuites ou identifier un numéro appelant.
• Agrégations : sommes, moyennes, votes, compteurs de télémétrie, où Paillier ou un schéma additif suffit.
• Intersection d’ensembles privée entre deux parties qui ne veulent révéler que l’intersection.
• Inférence de petits modèles : régression linéaire, arbres peu profonds, petits réseaux.

Le reste (base chiffrée interrogeable librement, entraînement de grands modèles, logique métier arbitraire) relève de la démonstration de salon. La recommandation est donc nette : envisager le FHE seulement quand la fonction tient en quelques dizaines de multiplications enchaînées et que la confiance envers l’opérateur est explicitement exclue du modèle de menace. Sinon, ne pas s’obstiner.

Ce que le chiffrement homomorphe ne garantit pas

• L’intégrité. Un schéma homomorphe est malléable par construction. Le serveur peut calculer une autre fonction que celle demandée, ou renvoyer un chiffré fabriqué : rien ne le détecte sans preuve de calcul vérifiable, qui ajoute son propre coût.
• La sécurité après déchiffrement partagé. L’attaque de Li et Micciancio (2021) montre qu’avec CKKS, publier ou renvoyer des résultats déchiffrés peut suffire à reconstituer la clé secrète. Le modèle de sécurité classique (IND-CPA, indistinguabilité sous attaque à clair choisi) ne couvre pas ce cas.
• La confidentialité de la fonction. Par défaut, le serveur connaît le circuit qu’il évalue, donc l’algorithme.

L’exploitation reste une gestion de clés classique : clé secrète côté client, rotation qui impose de rechiffrer, clés d’évaluation versionnées côté serveur. Un HSM (Hardware Security Module) garde la clé sans faire le calcul ; voir Le HSM n’est pas un coffre-fort.

Enclaves, calcul multipartite ou FHE : la question qui décide

Trois familles répondent au même besoin. Les TEE (Trusted Execution Environment), comme AMD SEV-SNP (Secure Encrypted Virtualization, Secure Nested Paging) ou Intel TDX (Trust Domain Extensions), calculent en clair dans une mémoire chiffrée, avec une attestation distante : performances quasi natives, mais confiance placée dans le fondeur et un historique chargé d’attaques par canaux auxiliaires. Le MPC (Multi-Party Computation) répartit le calcul entre des parties supposées ne pas s’entendre : rapide sur certaines fonctions, bavard sur le réseau. Le FHE ne fait confiance à personne et le fait payer.

Le choix dépend d’une seule question : à qui accepte-t-on de faire confiance ? Au fondeur du processeur, le TEE gagne presque toujours. À plusieurs opérateurs indépendants, le MPC. À personne, le FHE, pour une fonction étroite. L’éditorial sur la souveraineté du cloud traite cette confiance sous l’angle juridique.

Exemple : mesurer le prix d’une addition chiffrée

Paillier est seulement additif, mais il rend le coût tangible en quelques lignes. Avec Python 3 et la bibliothèque phe (python-paillier) :

# pip install phe
import time
from phe import paillier

# Clé de 2048 bits : chaque chiffré est un entier modulo n², soit environ 512 octets
pub, priv = paillier.generate_paillier_keypair(n_length=2048)
valeurs = [3120, 2890, 4410, 3675, 5020] * 20          # 100 valeurs

t0 = time.perf_counter()
chiffres = [pub.encrypt(v) for v in valeurs]            # côté client
t1 = time.perf_counter()
somme_chiffree = sum(chiffres[1:], chiffres[0])         # côté serveur, sans la clé
t2 = time.perf_counter()
assert priv.decrypt(somme_chiffree) == sum(valeurs)     # côté client

print(f"chiffrement : {t1 - t0:.2f} s, somme chiffrée : {t2 - t1:.4f} s")
print(f"taille d'un chiffré : {somme_chiffree.ciphertext().bit_length() // 8} octets")

# Multiplier deux chiffrés lève NotImplementedError : Paillier n'additionne que
# chiffres[0] * chiffres[1]

Une somme instantanée en clair coûte ici des secondes et multiplie la taille des données par plusieurs centaines. Un FHE complet ajoute la multiplication, et son bruit.

🐝 Ce qui arrive si on s’en passe

Sans chiffrement homomorphe, un calcul délégué à un serveur distant exige que les données soient déchiffrées avant traitement : le texte clair réside en mémoire vive chez l’hébergeur pendant toute la durée du calcul. Tout accès à l’hyperviseur, tout droit d’administration sur l’hôte ou toute lecture d’un vidage mémoire expose les entrées, les résultats intermédiaires et les sorties. La clé de déchiffrement doit elle aussi être disponible côté serveur, ce qui étend la surface d’exposition à son stockage et à sa rotation. Le chiffrement au repos et en transit ne couvre pas cette fenêtre : journaux applicatifs, fichiers d’échange et rapports de plantage peuvent capturer des valeurs en clair. La confidentialité repose alors sur la confiance accordée à l’opérateur, et non sur une garantie cryptographique vérifiable.

🦫 Explication de la marmotte 🍫

Normalement, pour qu’un ordinateur distant fasse un calcul sur des données secrètes, il doit d’abord les déchiffrer, donc il peut les lire. Le chiffrement homomorphe change cela : les données sont chiffrées d’une façon spéciale qui permet d’additionner et de multiplier les messages chiffrés directement. Le serveur fait le calcul sans jamais voir les valeurs, puis renvoie un résultat chiffré que seul le propriétaire de la clé peut lire. Le problème, c’est le prix. Chaque message chiffré contient un peu de désordre volontaire, qui grandit à chaque opération, surtout à chaque multiplication. Trop de désordre, et le résultat devient illisible ; il faut alors une opération de nettoyage très lente. De plus, comme le serveur ne voit pas les valeurs, il ne peut pas décider « si c’est plus grand, je fais ceci » : il doit calculer tous les cas possibles. Les messages chiffrés sont aussi des centaines de fois plus gros que les originaux. Un calcul d’une seconde en clair peut donc prendre des heures, et la méthode sert surtout à des calculs courts : additionner des votes, vérifier si un mot de passe a fuité. Elle ne prouve pas non plus que le serveur a fait le bon calcul.

À lire aussi

• Partager un secret et distribuer la confiancePrésenter les mécanismes qui évitent de concentrer un secret ou une décision dans une seule machine: partage, seuil, conférence et calcul distribué.
• Équité, vote, contrats et divulgation contrôléeConserver les protocoles avancés classiques en les réorganisant autour des problèmes d’équité, de décision collective et de divulgation contrôlée.

Pages voisines

La citent

• Chiffrement au niveau champ dans une base de données
• Équité, vote, contrats et divulgation contrôlée

Chiffrement homomorphe dans le cloud : promesses et limites réelles

Elle cite

• ⇄Lien dans les deux sens :Calculer, engager et anonymiser avec des primitives spécialisées
• Ce que « hébergé en France » garantit
• Le HSM n'est pas un coffre-fort
• Sécuriser les données en mémoire dans le cloud
• SGX et TrustZone pour isoler du code sensible

⇄ : les deux pages se citent l’une l’autre.