Centre de sécurité → Chiffrement
Architecture de chiffrement à connaissance nulle
Six couches de protection cryptographique. Vos données sont chiffrées sur votre appareil avant même de le quitter. Nous ne stockons que du texte chiffré.
Le principe du minimum d'informations
Coffre à connaissance nulle ≠ vérification à connaissance nulle
Votre coffre reste scellé. La vérification ne voit jamais qu'un seul fait, celui dont elle a besoin — qu'un événement autorisé s'est produit.
LifeWyn maintient le contenu de votre coffre chiffré et hors de notre portée. Vos documents, messages privés, médias et autre contenu protégé sont chiffrés avant de quitter votre appareil, et nous ne détenons pas les clés permettant de les consulter.
Un service d'héritage numérique, cependant, doit faire plus que conserver une boîte scellée. Le signal de vie, la vérification d'un décès, la notification des bénéficiaires désignés, le traitement des demandes et vos instructions d'héritage dépendent tous de la constatation qu'un fait s'est réellement produit — et un système aveugle à tout fait ne peut rien vérifier. Nous appliquons donc un principe de minimum d'informations : à chaque étape, LifeWyn ne traite que ce que cette étape exige, et rien de plus.
Vérification
établit si un événement autorisé s'est produit.
Vos règles
décident de ce qui peut se produire ensuite.
Votre chiffrement
protège le contenu réel de votre coffre.
Accès au coffre
Le contenu chiffré de votre coffre — documents, messages privés, médias et identifiants.
Nécessite vos clés, qui ne quittent jamais votre appareil. Aucun membre de l'équipe LifeWyn et aucun processus côté serveur ne peut l'ouvrir.
Accès au dossier
Un dossier de vérification unique — par exemple, un certificat de décès qu'un bénéficiaire désigné soumet.
Un examinateur autorisé pour ce dossier ne voit que ce que le dossier exige. Cette autorisation n'atteint jamais votre coffre.
Accès de vérification
Si un événement autorisé s'est réellement produit — un signal de vie manqué, un certificat validé.
Répond à « cela s'est-il produit ? », jamais à « qu'y a-t-il dans le coffre ? ».
Un certificat de décès soumis par un bénéficiaire désigné, par exemple, peut être examiné pour confirmer un décès signalé. Cet examen ne déverrouille jamais le coffre du client, ses mots de passe ou des avoirs sans rapport — ils restent chiffrés tout du long. Chaque étape, de la vérification et de l'examen à la notification, à l'accès du bénéficiaire désigné et à la divulgation, est encadrée par les règles que vous avez configurées et par le minimum d'informations nécessaire pour l'accomplir.
Protection à six niveaux
Chaque couche a un rôle précis
De votre mot de passe maître jusqu'à nos serveurs — chaque couche ajoute une défense en profondeur.
Phrase secrète du coffre et biométrie
Vous saisissez votre phrase secrète de coffre (distincte du mot de passe de connexion de votre compte), avec déverrouillage biométrique optionnel
scrypt (N=2^15), résistant en mémoire → clé maîtresse 256 bits
Dérivation de clé
La clé maîtresse dérive les clés de catégorie via HKDF-SHA-256 avec séparation de domaine
HKDF-SHA-256 avec libellés de contexte : « vault », « credentials », « documents », etc.
Chiffrement des éléments et des documents
Les clés d'actifs sont dérivées de la clé de catégorie ; chaque document reçoit une nouvelle clé aléatoire enveloppée sous cette clé de catégorie
XChaCha20-Poly1305 (AEAD) — un seul chiffrement pour les éléments du coffre comme pour les octets de fichiers
Chiffrement par enveloppe
Les DEK sont enveloppées par les clés de catégorie ; seul le texte chiffré quitte l'appareil
Enveloppement de clé NIST SP 800-38F ; chiffrement authentifié (AEAD)
Partage de secret à seuil
La clé maîtresse du coffre est répartie en N parts ; K sont nécessaires pour la reconstituer
Shamir's Secret Sharing over GF(2^8)
Stockage serveur
Seuls le texte chiffré et les enveloppes de clé chiffrées sont stockés ; aucun texte en clair
PostgreSQL (blobs de texte chiffré) ; Redis (session) ; stockage d'objets (fichiers)
Spécifications des algorithmes
Primitives cryptographiques — aucune cryptographie maison
Nous n'utilisons que des algorithmes standardisés et éprouvés. Aucune construction propriétaire.
Robustesse
Clé 256 bits, nonce 192 bits (nonces aléatoires, aucun risque de réutilisation), tag Poly1305 128 bits
Norme
RFC 8439 (construction XChaCha20 à nonce étendu)
Robustesse
Gourmand en mémoire ; N=2^15, r=8, p=1 ; sel propre à chaque utilisateur ; entrée normalisée NFKC
Norme
RFC 7914
Robustesse
Hachage de mot de passe gourmand en mémoire ; jamais appliqué à la phrase secrète du coffre
Norme
RFC 9106 / lauréat du Password Hashing Competition
Robustesse
PRF SHA-256 ; séparation des domaines via le paramètre info
Norme
RFC 5869
Robustesse
TLS 1.2 minimum, 1.3 privilégié ; confidentialité persistante parfaite
Norme
RFC 8446 / RFC 5246
Robustesse
Corps GF(2^8) ; Shamir classique — les parts ne portent aucun engagement de vérifiabilité
Norme
Adi Shamir 1979 ; RFC 9570 (brouillon)
Modèle de menace
Contre quoi nous protégeons — et comment
Évaluation honnête des vecteurs d'attaque et de nos mesures d'atténuation.
Compromission du serveur
Le serveur ne détient que du texte chiffré et des DEK enveloppées. Aucune clé maîtresse, aucune clé de catégorie, aucun texte en clair ne touche jamais le serveur.
Fuite de base de données
Les données du coffre stockées sont du texte chiffré XChaCha20-Poly1305. Sans votre clé maîtresse — qui ne quitte jamais votre appareil —, il est impossible en pratique de le déchiffrer. Les coordonnées vous concernant, vous et vos bénéficiaires désignés, ne sont PAS chiffrées au repos : LifeWyn ne peut pas notifier ou vérifier un bénéficiaire désigné dont il ne peut pas lire l'adresse.
Attaque de l'intercepteur (« man-in-the-middle »)
TLS 1.2 au minimum avec préférence pour 1.3, épinglage de certificat sur mobile, et HSTS avec includeSubDomains sur chaque réponse.
Vol d'appareil
La clé maîtresse n'est jamais que redérivée à partir de votre phrase secrète avec scrypt. Le déverrouillage biométrique est lié au trousseau iOS / Android Keystore, avec verrouillage automatique en cas d'inactivité et effacement de la clé enveloppée en cas de refus biométrique.
Personne malveillante en interne
Il n'existe aucune capacité de déchiffrement côté serveur susceptible d'être détournée : toutes les opérations sur les clés se font côté client, et chaque porte de divulgation est contre-vérifiée depuis un déploiement distinct et échoue de manière sécurisée. Chaque action est auditée.
Chaîne d'approvisionnement
Dépendances figées par fichier de verrouillage, un SBOM et une vérification de licence générés à chaque exécution du pipeline, et un scanner de secrets qui fait échouer la build en cas de détection. La cryptographie provient de bibliothèques publiées et auditées, pas de nous.
Hiérarchie des clés
Du mot de passe maître aux clés d'actifs
Schéma visuel montrant comment votre mot de passe maître dérive chaque clé de chiffrement du système.
Clé maître (256 bits)
scrypt(phrase secrète, sel, N=2^15) → clé 256 bits
Clé du coffre
HKDF(master, 'vault')
Clé des identifiants
HKDF(master, 'credentials')
Clé des documents
HKDF(master, 'documents')
Clé des actifs
HKDF(master, 'assets')
Compte bancaire
Clé du document = 256 bits aléatoires
Enveloppée par la clé de catégorie
Police d'assurance
Clé du document = 256 bits aléatoires
Enveloppée par la clé de catégorie
Document de testament
Clé du document = 256 bits aléatoires
Enveloppée par la clé de catégorie
Portefeuille crypto
Clé du document = 256 bits aléatoires
Enveloppée par la clé de catégorie
Titre de propriété
Clé du document = 256 bits aléatoires
Enveloppée par la clé de catégorie
Investissement
Clé du document = 256 bits aléatoires
Enveloppée par la clé de catégorie
Dossier médical
Clé du document = 256 bits aléatoires
Enveloppée par la clé de catégorie
Compte numérique
Clé du document = 256 bits aléatoires
Enveloppée par la clé de catégorie
Vérification
Ne faites pas confiance — vérifiez
Ce que vous pouvez vérifier vous-même dès aujourd'hui — et ce que nous n'avons pas encore fait.
Primitives auditées, pas les nôtres
Chaque primitive ci-dessus est une norme publiée, implémentée par @noble/ciphers et @noble/hashes. Nous n'avons écrit aucune cryptographie nous-mêmes. Le code source de l'application n'est pas public.
Pas encore d'audit tiers
Aucun cabinet externe n'a audité LifeWyn, et aucun test d'intrusion n'a été commandé. Nous préférons le dire plutôt que laisser entendre le contraire. Quand ce sera fait, le rapport sera lié ici.
Divulgation coordonnée
Une politique publiée, un engagement de bonne foi (« safe harbour ») et un délai de réponse réel. Il n'existe pas de programme de récompense en espèces à ce jour.
Lire la politiqueFAQ
Questions fréquentes
Dernière vérification : September 2026 · Rédigé par l'équipe éditoriale de LifeWyn · À propos de LifeWyn
Prêt à sécuriser votre héritage numérique ?
Créez votre coffre à connaissance nulle en quelques minutes. Vos clés, vos règles, votre héritage.