Architecture à connaissance nulle expliquée

« Nous ne pouvons pas voir vos données. » C'est une affirmation qui figure sur chaque page produit axée confidentialité, et c'est aussi celle qui est le plus souvent fausse. La plupart du temps, elle signifie en réalité « nous promettons de ne pas regarder » — ce qui est une politique, pas une garantie.

L'architecture à connaissance nulle est ce qui transforme cette affirmation en fait. C'est une conception technique précise dans laquelle l'opérateur du service n'a aucune capacité cryptographique de lire les données des utilisateurs — même s'il le voulait, même si ses serveurs étaient saisis, même si son personnel était compromis. Dans cet article, nous expliquons exactement ce que cela signifie, comment cela fonctionne en pratique et comment Schweizerform l'implémente pour les soumissions de formulaires.

Ce que « connaissance nulle » signifie réellement

En cryptographie, « connaissance nulle » a une définition académique précise liée aux preuves à divulgation nulle de connaissance. Dans le monde des produits de sécurité, le terme est utilisé plus largement pour décrire un système dans lequel :

• Tout chiffrement et déchiffrement se produit sur l'appareil de l'utilisateur, jamais sur le serveur
• Les clés nécessaires au déchiffrement ne parviennent jamais au serveur sous une forme exploitable
• Le serveur ne stocke que du texte chiffré et ne peut pas déduire, deviner ou récupérer le texte clair
• La confiance envers l'opérateur n'est pas requise — l'architecture est prouvable plutôt que promise

L'opposé de la connaissance nulle est un système basé sur la confiance où le serveur détient les clés et promet un comportement responsable. La plupart des SaaS grand public sont conçus ainsi. Ce n'est pas du mauvais génie logiciel — c'est juste un modèle de confiance différent. La connaissance nulle est le modèle que l'on choisit lorsque les données sont trop sensibles pour qu'une promesse suffise.

Le problème difficile que la connaissance nulle doit résoudre

La question évidente : si le serveur ne détient aucune clé, comment les utilisateurs se connectent-ils, partagent-ils des formulaires, déchiffrent-ils des soumissions sur plusieurs appareils et récupèrent-ils d'un mot de passe oublié ? C'est le vrai défi de conception. N'importe qui peut construire un système sûr mais inutilisable — l'art consiste à en construire un qui soit sûr ET utilisable.

Chaque système à connaissance nulle converge vers une poignée de primitives cryptographiques centrales pour résoudre cela :

Comment Schweizerform assemble tout cela

Schweizerform est une plateforme de formulaires, donc la question de conception spécifique est : comment permettre à quelqu'un de créer un formulaire, de partager un lien public, d'accepter des soumissions chiffrées de n'importe qui sur Internet et de permettre à seul le propriétaire du formulaire de les lire — tout en veillant à ce que le serveur ne détienne jamais de copie déchiffrable ?

La réponse implique trois couches de clés : une clé maîtresse dérivée de votre Code d'Accès, une paire de clés RSA au niveau du formulaire et une clé AES unique par soumission. Passons-les en revue.

Couche 1 — Votre clé maîtresse

Lorsque vous vous inscrivez sur Schweizerform, vous créez un Code d'Accès. Ce n'est pas un mot de passe ordinaire. Il n'est jamais envoyé à nos serveurs et ne peut être récupéré en cas de perte — car les garanties de sécurité dépendent précisément de cette propriété. Dans votre navigateur, le Code d'Accès est injecté dans une fonction de dérivation de clé (PBKDF2 avec un nombre élevé d'itérations et un sel par utilisateur) pour produire une clé maîtresse AES-256.

La clé maîtresse n'existe que dans la mémoire du navigateur. Elle ne touche jamais le disque en clair. Elle ne quitte jamais l'appareil. C'est elle qui déverrouille tout le reste.

Couche 2 — Votre paire de clés de formulaire

Lorsque vous créez un formulaire, le navigateur génère une paire de clés RSA-OAEP. La clé publique est envoyée à nos serveurs et incluse lors du rendu du formulaire public — c'est ainsi que les répondants chiffreront des données à votre intention. La clé privée est immédiatement chiffrée avec votre clé maîtresse et stockée sur nos serveurs sous forme de texte chiffré. Nous stockons la clé privée chiffrée, mais nous ne pouvons pas la déchiffrer.

Comme la clé publique est, eh bien, publique, quiconque ouvre le formulaire peut l'utiliser pour chiffrer une soumission. Mais seule une personne possédant votre Code d'Accès peut dériver la clé maîtresse, déverrouiller la clé privée et lire la soumission. Le serveur est cryptographiquement exclu.

Couche 3 — Une clé unique par soumission

RSA est puissant mais lent, et la longueur de son texte chiffré est limitée par la taille de la clé. Nous ne chiffrons donc pas directement les réponses du formulaire avec RSA. À la place, lorsqu'un répondant soumet :

1. Le navigateur génère une clé AES-256-GCM fraîche — unique à cette soumission
2. Toutes les réponses (et pièces jointes) sont chiffrées avec cette clé AES, côté client
3. La clé AES elle-même est ensuite chiffrée avec la clé publique RSA du formulaire
4. Les réponses chiffrées et la clé AES chiffrée sont envoyées au serveur

Ce motif — une clé symétrique protégée par une clé asymétrique — est le modèle de chiffrement hybride standard et est utilisé par TLS, PGP et essentiellement tout système sérieux. Il combine la rapidité de l'AES avec les propriétés d'échange de clés de RSA.

Le rôle des données authentifiées supplémentaires (AAD)

AES-GCM n'est pas seulement du chiffrement — c'est du chiffrement authentifié. Il produit une étiquette que le déchiffreur vérifie pour confirmer que le texte chiffré n'a pas été modifié. GCM prend également en charge les Additional Authenticated Data : contexte supplémentaire non chiffré mais lié au texte chiffré. Si ce contexte change, le déchiffrement échoue.

Schweizerform utilise l'AAD pour lier chaque soumission à son formulaire et à son ID de soumission spécifiques. Le format AAD est :

submission_payload:{formId}:{submissionId}

Cela ferme une classe d'attaques subtile : même si un attaquant obtenait d'une manière ou d'une autre un blob de soumission chiffré, il ne pourrait pas le rejouer contre un autre formulaire, ni échanger des enregistrements de soumission dans la base de données, sans que le déchiffrement échoue côté propriétaire. Le texte chiffré est soudé à son contexte.

Le cycle complet, de bout en bout

À chaque étape où le texte clair existe, il existe dans un navigateur. À chaque étape où le serveur touche les données, les données sont du texte chiffré. C'est l'entière définition de la connaissance nulle pour ce cas d'usage.

Contre quoi cela protège — concrètement

Être honnête sur ce que la connaissance nulle ne résout pas

La connaissance nulle est une couche puissante — mais ce n'est pas une solution miracle. Un lectorat bien informé mérite un compte rendu honnête de ses limites :

• Elle ne protège pas l'appareil du répondant — si le navigateur est compromis, le texte clair est exposé à la source
• Elle ne protège pas contre une mise à jour malveillante du code côté client — d'où l'importance de l'intégrité du code, du CSP et de l'intégrité des sous-ressources
• Elle ne chiffre pas les métadonnées comme les horodatages, les compteurs de soumissions ou la structure des questions — elles sont nécessaires au fonctionnement de l'application
• Elle ne survit pas à la perte de votre Code d'Accès — la récupération nécessite une clé de récupération partagée détenue par un tiers de confiance, que nous prenons en charge mais que vous devez configurer à l'avance
• Elle ne remplace pas une sécurité de transport forte, une authentification correcte ou des opérations serveur sécurisées — elle les complète

La connaissance nulle n'est pas un substitut à l'ingénierie sécurité — c'est ce que produit l'ingénierie sécurité quand le modèle de menace inclut l'opérateur lui-même.

Comment vérifier vous-même les affirmations de connaissance nulle

Vous n'avez pas à nous croire sur parole. Ouvrez les outils de développement de votre navigateur sur une page de soumission Schweizerform. Observez l'onglet réseau pendant que vous soumettez. Regardez la charge utile qui quitte votre appareil. Vous verrez :

• Un blob chiffré encodé en hexadécimal pour la charge utile des réponses — aucune valeur de champ lisible
• Une clé AES enveloppée — plus courte, également du texte chiffré
• Un IV et une liaison AAD — métadonnées nécessaires au déchiffrement, mais pas les données elles-mêmes

Vous ne verrez nulle part les réponses en clair dans la requête. C'est le test. Un système qui échoue à ce test n'est pas à connaissance nulle, quels que soient ses arguments marketing.

L'essentiel

La connaissance nulle n'est pas un simple point de fonctionnalité — c'est un principe de conception qui force des choix d'ingénierie difficiles. Tout ce qui semble « facile » dans un SaaS classique (accès admin aux données, récupération de mot de passe restaurant les données, recherche plein texte côté serveur sur les contenus utilisateurs) doit être repensé ou reconstruit sur d'autres fondations.

Mais pour les données de formulaires sensibles — antécédents de patients, admissions juridiques, signalements d'alertes professionnelles, divulgations financières — cet effort est le seul vrai but. L'objectif n'est pas qu'on nous confie les données ; l'objectif est de rendre la question de la confiance sans objet. Quand le serveur ne peut physiquement pas lire ce qu'il stocke, toute la catégorie de menaces côté opérateur disparaît.