FHE/Zama: le futur du chiffrement

Introduction

Certaines technologies sont révolutionnaires et pourtant totalement méconnues du grand public.

Souvent, on utilise de véritables prouesses scientifiques, notamment mathématiques dans notre quotidien de tous les jours, sans qu’on en ait connaissance.

Par exemple, aujourd’hui, Internet ne serait pas ce qu’il est sans l’usage de la cryptographie. Si on peut acheter des biens et des services en ligne, consulter ses comptes bancaires, envoyer des informations sensibles, c’est grâce aux multiples protocoles de chiffrements disponibles. Ils ont évolué au fil du temps et, sous certaines conditions, permettent de se protéger quand on échange des données sur le web.

Je suis loin d’être un expert du sujet, mais je vais tenter de résumer certaines méthodes utilisées actuellement dans l'objectif de vous faire découvrir le FHE (Fully Homomorphic Encryption) et la startup française Zama.

Petit disclaimer, il est possible que j’écorche certains concepts, voire que je me trompe dans ma vulgarisation. S’il vous plait, soyez indulgent et, si vraiment des erreurs sont commises n’hésitez pas à me contacter et m’apporter vos lumières, je serais ravi d’améliorer l’article si besoin.

Principes des clefs

Cliquez sur l'image pour l'agrandir.

Pour traiter la problématique de chiffrement de l'information, le plus souvent, on va parler de clefs de chiffrement. Il s’agit d’une valeur secrète (souvent une suite de bits, ou un mot de passe dérivé d’une suite de bits) qui sert à:

• chiffrer des données (rendre illisibles aux personnes étrangères à l'échange).
• déchiffrer ces données (rendre à nouveau lisible aux personnes impliquées dans l'échange. Et par pitié, arrêtons de dire Décrypter).

Clefs symétriques

L’une des formes les plus simples de la cryptographie exploitant une clef est l’usage de clefs dites symétriques.

Cliquez sur l'image pour l'agrandir.

L’objectif est de chiffrer et déchiffrer une donnée via l’usage d’une seule et même clef. Cette clef est à définir entre les parties prenantes d’un échange et doit être secrètement gardée par ces dernières.

Prenons comme exemple les célèbres personnages Alice et Bob, qu’on retrouve dans la majorité des illustrations d’explication du chiffrement.

Alice et Bob veulent échanger des informations dont ils seront les seuls à pouvoir chiffrer et déchiffrer la donnée.

Ils définissent alors une clef quelconque, puis Bob chiffre son message avec cette clef et envoie son information à Alice. Alice ayant connaissance de la clef, elle déchiffre le message, puis rédige une réponse quel renvoi à Bob en ayant pris soin au préalable de la chiffrer avec la fameuse clef.

C’est basique, efficace, rapide et facile à implémenter.

C’est ce qui est utilisé aujourd’hui par des algorithmes comme AES-256 qu’on va retrouver dans des solutions de chiffrement de fichiers, comme VeraCrypt, Bitlocker…

Le problème reste l’échange de cette clef. Il faut bien que tout participant aux conversations s’échange au moins une fois la clef, et si celle-ci est interceptée ou récupérée par un acteur malveillant, (souvent appelé Eve dans les démonstration) toute la protection s’effondre.

On parle de Man In The Middle.

C’est le problème du secret initial particulièrement gênant si Alice et Bob sont éloignés l’un de l’autre.

Clefs asymétriques

C’est pour cela que d’autres mécanismes sont apparus, qu’on appelle clefs asymétriques.

Cliquez sur l'image pour l'agrandir.

C’est à partir de 1970, grâce à des inventions telles que l’algorithme RSA et le protocole d’échange de clefs Diffie-Hellman, que le chiffrement asymétrique a fait son apparition. Ce type de chiffrement utilise une paire de clefs distinctes:

• Une clef publique à partager librement
• Une clef privée à garder secrète.

Les deux sont liées mathématiquement, mais il est impossible de retrouver la clef privée à partir de la clef publique, du moins pour le moment et sous condition d’une longueur de clef suffisante….

Si on repart sur le principe de Alice et Bob:

Chacun génère sa paire de clefs privées/clef publique, et chacun envoie à l’autre sa clef publique.

Cette clef publique ne peut servir qu’à chiffrer la donnée à destination de son propriétaire d’origine.

La donnée ainsi chiffrée ne peut être déchiffrée que via la clef privée qui a été générée en même temps que la clef publique.

Bob peut ainsi chiffrer son message avec la clef publique d’Alice, et seule Alice pourra déchiffrer ce message à l’aide de sa clef privée.

Ainsi, seule la clef publique a besoin d’être échangée, et son interception par un acteur malveillant ne lui donne aucune possibilité de déchiffrer un message sans l’obtention des clefs privées resté du côté de leur propriétaire d’origine.

Les clefs asymétriques ont donc beaucoup de vertu.

• Plus besoin d’échanger de clef secrète au préalable.
• Permets l’authentification (signature numérique).
• Repose sur des problèmes mathématiques très difficiles (RSA, ECC).

Par contre, le chiffrement asymétrique est plus lourd que le chiffrement symétrique. Heureusement, nos équipements informatiques actuels sont suffisamment puissants pour gérer la charge… avec, comme inconvénient, de devoir utiliser des tailles de clé de plus en plus grandes à mesure que les évolutions matérielles se succèdent.

L’objectif est d’empêcher que les principes mathématiques associés ne deviennent caducs, ce qui pourrait compromettre la sécurité des algorithmes de chiffrement utilisant des clés trop petites qui pourraient être découvertes après de nombreux calculs. (Avantage: ajouter des bits augmente les difficultés de cassage de clef de manière exponentielle...mais aussi la puissance nécessaire à leur manipulation).

C’est pourquoi on préconise aujourd’hui au minimum des clefs de 2048 bits, voire 4096 bits (données très sensibles).

Attention également à la criticité de sa clef privée. Si elle n’a pas besoin d’être partagée, il est crucial de la protéger adéquatement et de s’assurer qu’elle ne soit pas accessible à tous. Cela signifie qu’on ne divulgue pas sa clef privée d’un appareil à un autre, par exemple par mail, et qu’on ne la stocke pas dans la racine de son serveur web.

Ce principe de clef asymétrique est au cœur de notre internet actuel et du fameux HTTPS avec les certificats associés.

On va notamment retrouver cette mécanique dans des protocoles comme TLS.

Les messageries sécurisées comme Signal exploitent aussi ce type de principe.

J’en profite également pour éclaircir les différences entre SSL, TLS et HTTPS qu’on a souvent tendance à confondre.

Problème des méthodes de chiffrements actuelles

Qu’il s’agisse de clef symétrique ou asymétrique, tous les usages actuels sont confrontés à la même problématique: on ne peut pas réaliser d’opération sur des données chiffrées.

Dans le cas de Alice et Bob cela n’est pas vraiment un soucis, mais, dans la vie de tous les jours, cela peut devenir gênant.

C’est notamment l’une des raisons derrière les fuites de données et autres pertes d’informations personnelles dont on entend souvent parler… et dont le marketing cyber est friand pour vous inviter à acquérir des missions d'audit ou des nouveaux produits révolutionnaires….

Si, lors de l’usage d’un service quelconque (achat en ligne, par exemple), vos échanges avec les serveurs de l’entreprise que vous sollicitez sont bien chiffrés, vos données le sont souvent en clair une fois déchiffrées sur le serveur distant.

Prenons un exemple basique. Vous devez justifier de votre âge pour l’accès à un service sensible (pas d’allusions graveleuses…):

1. Vous renseignez votre âge sur la page web du site.
2. La donnée est chiffrée sur votre ordinateur (avec la clef publique du serveur) et envoyée au serveur distant.

3. Une fois sur le serveur, l’information est déchiffrée (avec la clef privée du serveur).
4. Votre âge est comparé à une valeur de référence pour savoir si l’accès vous est autorisé.
5. La réponse est chiffrée sur le serveur (avec votre clef publique) et vous est retournée.
6. Vous déchiffrez à votre tour la réponse sur votre ordinateur (avec votre clef privée).

Problème: imaginons que le serveur avec lequel vous avez partagé votre âge a été corrompu. Dans ce cas au moment où la donnée a été déchiffrée de son côté, votre âge a pu être récupéré par un acteur malveillant. Sans etre corrompu, le serveur peut aussi conserver la donnée sans votre consentement et cette derniere pourrait etre volée par la suite ou utiliser à d'autres fins.

Dans mon exemple, les conséquences ne sont pas très graves, mais imaginons qu’on rencontre le même souci avec des données médicales, ou bancaires, par exemple.

C’est toute la difficulté. Le plus souvent, vos données doivent être traitées d’une manière ou d’une autre, et, pour cela, elles doivent être déchiffrées. Elles peuvent donc être potentiellement accessibles à un attaquant qui aurait réussi à s’infiltrer dans le système avec lequel vous communiquez.

Le FHE

Et c’est là qu’apparait le FHE (Fully Homomorphic Encryption) ou chiffrement homomorphe complet.

Cliquez sur l'image pour l'agrandir.

C’est une forme de chiffrement qui permet d’effectuer des calculs sur des données chiffrées, sans jamais avoir à les déchiffrer.

Prenons à nouveau un exemple basique.

On souhaite chiffrer deux données sensibles, comme le chiffre 5 et le chiffre 7 avec une clef privée.

On envoie la donnée chiffrée à un serveur tiers pour qu’il réalise une opération sur ces données, par exemple une addition.

Le serveur récupère les données, mais ne les déchiffre pas. Il réalise l’opération sur les données chiffrées, renvoie le résultat qui reste sous sa forme chiffrée. Même le serveur ne sait donc pas le résultat, il n’a en mémoire que sa forme chiffrée.

De notre côté on réceptionne le résultat, on le déchiffre avec la clef utilisée à l’envoi: on obtient 12. Je vous laisse apréhender le principe dans la démo ci-dessous

Mon exemple est basique et peu utile, il est avant tout pédagogique.

Un exemple concret avec l'usage de l'IA et la supply chain

Mais imaginez maintenant que vous souhaitiez tirer parti d’une IA dans le cloud, disposant d’une énorme puissance de calcul. Vous aimeriez entrainer cette IA avec vos données, par exemple, les données de votre entreprise (vos clients, vos contrats…), mais le service IA que vous avez retenu n’est pas européen et vous craigniez que vos données ne soient utilisées à mauvais escient malgré le contrat signé avec votre partenaire qui vous garantit la totale souveraineté de vos données...

Eh bien, avec le FHE, ce serait possible… vous enverriez vos données chiffrées avec votre propre clef, l’IA pourrait s’entrainer dessus sans avoir à les déchiffrer. De votre côté vous pourriez ensuite dans votre entreprise implémenter les réponses de l’IA sur vos applications, en déchiffrant ses dernières avec votre clef privée.

À aucun moment votre prestataire cloud ne manipule vos données en clair… et donc est dans l’incapacité d’en faire un usage autre que celui que vous souhaitez.

De même, s’il venait à être piraté, vous ne seriez pas inquiété, les données récupérées par le pirate ne pouvant être exploitées sans votre clef.

Dans la cybersécurité, on parle souvent des attaques de chaines d’approvisionnement (supply chain) ou l’attaquant passe par un des partenaires de sa cible pour porter atteinte à cette dernière. FHE limite ce risque.

Quantique Ready

Autre avantage du FHE, sa résistance aux ordinateurs quantiques.

Précédemment, j’ai dit que, dans l’usage d’un système de clef asymétrique, il n’était pas possible de retrouver une clef privée à partir d’une clef publique… et bien c’est justement ce que pourrait faire un ordinateur quantique… Du moins, pas tout de suite, car les quelques ordinateurs quantiques, qui s’approchent plus de prototypes que de produits finis, ne sont pas assez puissants pour traiter nos tailles de clefs actuelles.

Selon certains, on ne devrait pas attendre si longtemps pour que le « choc » quantique se produise.

L’organisme américain NIST (National Institute of Standards and Technology) qui joue un rôle mondial dans la standardisation des algorithmes de chiffrement (c’est lui qui a validé AES et SHA par exemple) a officiellement recommandé le passage à des algorithmes quantiques résistant dès 2035 .

FHE est déjà prêt pour cela.

Problèmes du FHE

Mais tout n’est pas rose pour FHE.

En fait, certains principes derrière FHE sont connus depuis 1978, avec RSA, qui permet une forme partiellement homomorphe, c’est-à-dire qu’on peut appliquer quelques opérations sur les données chiffrées mais ceci de manière très limitée et peu performante.

Le FHE comme évoqué aujourd’hui, a été mis en place pour la première fois en 2009 par Craig Gentry, un chercheur chez IBM. Le problème c’est que c’était extraordinairement lent (plusieurs heures pour une simple addition), mais la preuve de faisabilité était là.

C’est le point de départ de toute la recherche moderne sur le FHE.

Depuis, des schémas plus performants ont vu le jour. De nombreuses entreprises de renommée mondiale (IBM, Google, Microsoft, etc.) travaillent activement sur le sujet, mais l’implémentation et l’utilisation du FHE demeurent complexes. Elles requièrent à la fois des compétences humaines très spécialisées et des ressources matérielles importantes.

Zama

Heureusement une petite révolution est arrivée en 2020 et elle est française.

Il s’agit de la startup Zama.

Cliquez sur l'image pour l'agrandir.

Elle est fondée par Pascal Paillier, qui a déjà développé une première solution d’addition homomorphe en 1999, et Rand Hindi un entrepreneur français doctorat en bio-informatique.

Cliquez sur l'image pour l'agrandir.

Zama s’appuie sur un schéma moderne d’application du FHE : le TFHE (Torus Fully Homomorphic Encryption). Ce modèle introduit en 2018 a été optimisé pour des opérations logiques rapides (booléens, bits, entiers).

Le TFHE demeure complexe, mais Zama a réussi le tour de force de fournir une bibliothèque Open Source Rust et à proposer un compilateur FHE pour Python, Concrete.

Ces librairies rendent l’usage des circuits FHE bien plus simple à utiliser en offusquant tous les principes mathématiques compliqués, pour un usage clef en main dans les applications.

Cliquez sur l'image pour l'agrandir.

C’est donc bien une véritable révolution que Zama est en train de mener. C’est un énorme changement de paradigme.

Auparavant, il fallait détenir un doctorat en cryptographie pour exploiter le FHE. Grâce à Zama, un développeur Python peut maintenant en faire une démo en 5 minutes...surtout si il utilise l'IA pour l'aider.

Vous pouvez essayer d’installer le package Python Concrete. Cependant, il faut que vous le fassiez sous Linux, car le code n’est pas encore compatible avec Windows. Au besoin vous pouvez utiliser WSL (Windows Subsystem for Linux).

Cliquez sur l'image pour l'agrandir.

Voici un code purement pédagogique exploitant la technologie de Zama pour faire une addition homomorphique:

  
# Exemple d'addition FHE avec Concrete de Zama
# Ce code nécessite : pip install concrete-python

from concrete import fhe
import numpy as np

# Étape 1 : Définir la fonction à compiler en circuit FHE
@fhe.compiler({"x": "encrypted", "y": "encrypted"})
def add_encrypted(x, y):
    """
    Fonction qui additionne deux nombres.
    Cette fonction sera compilée en circuit FHE permettant
    l'addition sur données chiffrées.
    """
    return x + y

# Étape 2 : Définir un jeu de données d'entraînement
inputset = [
    (np.int64(i), np.int64(j)) 
    for i in range(0, 50) 
    for j in range(0, 50)
]

# Étape 3 : Compiler le circuit FHE
print("🔧 Compilation du circuit FHE...")
circuit = add_encrypted.compile(inputset)
print("✓ Circuit compilé avec succès !")

# Étape 4 : Générer les clés de chiffrement
print("🔑 Génération des clés...")
circuit.keygen()
print("✓ Clés générées !")

# Étape 5 : Définir nos valeurs en clair
a = np.int64(5)
b = np.int64(7)
print(f"\n📝 Valeurs en clair : {a} + {b}")

# Étape 6 : Chiffrer les valeurs
# CORRECTION : encrypt() prend TOUS les arguments de la fonction
print("🔒 Chiffrement des données...")
encrypted_args = circuit.encrypt(a, b)
print("✓ Données chiffrées !")

# Étape 7 : Effectuer l'addition sur les données CHIFFRÉES
print("⚙️  Calcul sur données chiffrées...")
encrypted_result = circuit.run(encrypted_args)
print("✓ Addition effectuée sur données chiffrées !")

# Étape 8 : Déchiffrer le résultat
print("🔓 Déchiffrement du résultat...")
decrypted_result = circuit.decrypt(encrypted_result)
print(f"✓ Résultat déchiffré : {decrypted_result}")

# Vérification
expected = a + b
print(f"\n✅ Vérification : {a} + {b} = {decrypted_result}")
print(f"✅ Résultat correct : {decrypted_result == expected}")

Cliquez sur l'image pour l'agrandir.

FHE devient réellement utilisable, même si les implémentations sont encore peu nombreuses en raison du besoin de démocratiser son usage et surtout à cause de la puissance de calcul encore nécessaire pour l’exploiter pleinement.

Mais les besoins sont là: machine learning chiffré, statistique sécurisée, finance confidentielle. Et bien d’autres encore.

La blockchain et le web3 ont été parmi les premiers écosystèmes à s’essayer à l’implémentation FHE à grande échelle. Zama est d’ailleurs pleinement impliqué à ce niveau.

En effet, Zama cherche à rendre la confidentialité computationnelle compatible avec la transparence souvent affichée dans les blockchains publiques.

Bitcoin ou Ethereum, par exemple, rendent leur transaction transparente, vérifiable et immuable.

C’est comme cela qu’elles garantissent la confiance sans intermédiaire, l’un des piliers du web3.

Or, dans certains cas (finance, santé, identité, IA), les utilisateurs veulent prouver qu’une opération est correcte sans révéler les données sous-jacentes.

C’est exactement le rôle du chiffrement homomorphe complet (FHE) et c’est là que Zama permet d’implémenter FHE simplement.

Il est important de noter qu’il existe d’autres mécanismes, tels que les ZK-SNARKs ou les preuves à divulgation nulle de connaissance. Ce sont d’autres principes mathématiques qui permettent de prouver une chose sans avoir à dévoiler la preuve. Imaginer jouer à « Où est Charlie » et à pouvoir démontrer que vous saviez où il est sur l’image, sans avoir à le montrer.

Mais c’est un autre sujet que je ne vais pas détailler ici. Sachez simplement que FHE et zk-SNARKS peuvent se compléter. FHE reste une approche plus générale et plus expressive.

On peut alors imaginer des blockchains confidentielles, où le réseau exécute des transactions chiffrées, mais où les résultats restent cohérents et vérifiables publiquement.

Cliquez sur l'image pour l'agrandir.

Zama développe d’ailleurs une FHE Virtual Machine (FHE VM). Une machine virtuelle compatible avec Ethereum qui peut exécuter des smart contracts sur des données chiffrées.

Grâce à sa vision open source et son approche orientée développeur, Zama pourrait réussir à rendre le FHE exploitable à très grande échelle et peut être à transformer notre internet actuel pour plus de souveraineté et de sécurité.

En outre, l’entreprise n’hésite pas à promouvoir son idéal de transition du protocole HTTPS au protocole HTTPZ, dans lequel tout serait crypté de bout en bout, sans craindre les avancées de la technologie quantique ou les défaillances des systèmes concernées par un traitement de données.

Toute la question est maintenant de savoir s’ils vont y arriver. En tout cas, on peut être fière d’avoir ce type d’entreprise dans notre pays. Il reste à espérer qu’elle ne finisse pas dans les mains d’un GAFAM et que le FHE aille au bout de ses promesses.