Livre Blanc Sécurité

3.1 Chiffrement Côté Client avec AES-256-GCM

Keeplas chiffre chaque élément du Vault en utilisant AES-256-GCM (Galois/Counter Mode), un algorithme de chiffrement authentifié qui fournit à la fois la confidentialité et l'intégrité. Chaque élément est chiffré avec une clé unique de 256 bits générée aléatoirement et un vecteur d'initialisation (IV) de 96 bits.

Algorithm:  AES-256-GCM
Key Size:   256 bits (32 bytes)
IV Size:    96 bits (12 bytes), randomly generated per encryption
Tag Size:   128 bits (16 bytes)
Output:     IV || Ciphertext || Authentication Tag

Le tag d'authentification garantit que toute altération du texte chiffré est détectée lors du déchiffrement. L'IV est préfixé au texte chiffré pour être disponible lors du déchiffrement sans stockage supplémentaire. Lorsque des clés doivent être partagées -- clés de chiffrement de données (DEK) par destinataire et fragments de récupération Shamir -- la couche d'enveloppement combine AES-256-GCM avec ML-KEM-768 (NIST FIPS 203), un mécanisme d'encapsulation de clés post-quantique, afin que le texte chiffré récolté reste protégé même face à de futurs adversaires quantiques.

3.2 Dérivation de Clé : Argon2id

La phrase de récupération de 24 mots de l'utilisateur est transformée en une Clé Racine à l'aide d'Argon2id, une fonction de dérivation de clé résistante à la mémoire. La Clé Racine enveloppe ensuite la clé maître AES-256 qui chiffre le Vault ; l'utilisateur ne saisit jamais directement la clé maître.

Primary KDF:  Argon2id (recommended)
  Memory:     64 MiB
  Iterations: 3
  Parallelism: 4
  Output:     256-bit master key

Fallback KDF: PBKDF2-HMAC-SHA256
  Iterations: 600,000
  Salt:       128-bit, randomly generated per account
  Output:     256-bit master key

Argon2id est utilisé car sa conception résistante à la mémoire résiste aux attaques par force brute basées sur GPU et ASIC. Le sel est unique par utilisateur et stocké à côté du Vault chiffré (il n'est pas secret). La phrase de récupération elle-même est générée sur l'appareil lors de l'intégration et n'est jamais transmise à Keeplas.

3.3 Aucun Texte en Clair ne Quitte le Client

La phrase de récupération et les clés qui en sont dérivées ne sont jamais transmises aux serveurs Keeplas. L'authentification est entièrement sans mot de passe -- codes à usage unique par e-mail (toujours requis comme facteur d'élévation) et OTP WhatsApp optionnel, passkeys (WebAuthn) ou applications d'authentification TOTP -- et est cryptographiquement indépendante du déchiffrement du Vault. Le serveur vérifie l'identité sans jamais connaître le secret utilisé pour déchiffrer le Vault.

4.1 Hiérarchie des Clés

Lorsqu'un utilisateur crée son compte, la hiérarchie de clés suivante est établie côté client. La phrase de récupération de 24 mots dérive une Clé Racine via Argon2id, la Clé Racine enveloppe la clé maître AES-256, et la clé maître protège les clés individuelles des éléments du Vault.

Master Password
  |
  +--[Argon2id / PBKDF2]--> Master Key (256-bit)
  |                            |
  |                            +--[HKDF-Expand "enc"]--> Encryption Key
  |                            +--[HKDF-Expand "auth"]--> Authentication Key
  |
  (never transmitted)

La clé maître est utilisée pour envelopper (chiffrer) les clés individuelles des éléments du Vault. L'identité de connexion est vérifiée séparément via une authentification sans mot de passe (codes à usage unique par e-mail et WhatsApp, passkeys ou TOTP), cryptographiquement indépendante des clés qui déchiffrent le Vault.

4.2 Enveloppement de Clés pour les Éléments du Vault

Chaque élément du Vault (document, identifiant, note) possède sa propre clé de 256 bits générée aléatoirement. Cette clé d'élément est utilisée pour chiffrer le contenu de l'élément via AES-256-GCM. La clé d'élément est ensuite enveloppée (chiffrée) à l'aide de la clé maître de l'utilisateur. Lorsqu'un élément est partagé avec un destinataire, sa clé de chiffrement de données est ré-enveloppée pour ce destinataire à l'aide de ML-KEM-768 combiné à AES-256-GCM, ce qui garde le partage sécurisé face au post-quantique.

Vault Item:
  item_key = random(256 bits)
  encrypted_content = AES-256-GCM(item_key, plaintext)
  wrapped_item_key  = AES-256-GCM(encryption_key, item_key)

Stored on server: wrapped_item_key + encrypted_content

Cette approche à deux niveaux permet de re-chiffrer des éléments individuels sans re-dériver la clé maître, et permet le partage sélectif et la rotation de clés au niveau de l'élément.

4.3 Stratégie de Rotation de Clés

Lorsqu'un utilisateur fait tourner ses clés, une nouvelle clé maître est générée et toutes les clés d'éléments enveloppées sont re-chiffrées avec elle ; la nouvelle clé maître est ensuite ré-enveloppée sous la Clé Racine dérivée de la phrase de récupération. Les clés d'éléments sous-jacentes et le contenu chiffré restent inchangés, rendant la rotation efficace même pour des Vaults contenant des milliers d'éléments. Keeplas recommande une rotation de clés au moins une fois par an ou immédiatement après une compromission suspectée.

5.1 Shamir Secret Sharing (SSS)

Pour prévenir le verrouillage permanent si un utilisateur perd sa phrase de récupération de 24 mots, Keeplas implémente un Protocole de Récupération Sociale basé sur le schéma de partage de secret de Shamir. La clé maître est divisée en 5 fragments de sorte que n'importe quels t fragments (le seuil) suffisent à la reconstruire, mais moins de t fragments ne révèlent rien. Chaque fragment est enveloppé pour son détenteur à l'aide de ML-KEM-768 combiné à AES-256-GCM, afin que les parts distribuées restent sécurisées face au post-quantique.

Shamir Secret Sharing Parameters:
  Secret:     Recovery Key (used to decrypt a backup of the Encryption Key)
  Shares (n): Configurable (default: 5)
  Threshold (t): Configurable (default: 3)
  Field:      GF(2^256)

Property: Any (t-1) shares reveal zero information about the secret.

5.2 Configuration du Seuil

Les utilisateurs choisissent leur propre seuil parmi les 5 fragments. Par défaut, il est de 2 sur 5 : cinq contacts de confiance détiennent chacun un fragment, et deux d'entre eux peuvent coopérer pour initier la récupération. L'utilisateur peut ajuster ce seuil à tout moment, générant un nouveau jeu de fragments.

5.3 Processus de Récupération

Le processus de récupération suit ces étapes :

1. Configuration : L'utilisateur divise sa clé maître en 5 fragments et les distribue à des gardiens de confiance, chaque fragment étant enveloppé avec ML-KEM-768 et transmis via des canaux sécurisés, chiffrés de bout en bout.
2. Initiation : Lorsque la récupération est nécessaire, l'utilisateur (ou son héritier désigné) crée une demande de récupération via Keeplas.
3. Approbation des Gardiens : Chaque gardien est notifié et doit soumettre indépendamment son fragment. Les fragments sont transmis via des canaux chiffrés et ne sont jamais stockés ensemble sur le serveur.
4. Reconstruction : Une fois le seuil de fragments soumis, la clé maître est reconstruite sur l'appareil d'un contact -- jamais sur les serveurs de Keeplas.
5. Renouvellement de Clé : L'utilisateur génère une nouvelle phrase de récupération de 24 mots et une nouvelle clé maître, ré-enveloppe toutes les clés d'éléments du Vault et redistribue de nouveaux fragments. Les anciens fragments sont invalidés.

6.1 Surveillance Automatisée

Keeplas surveille les signaux d'activité de l'utilisateur tels que les connexions à l'application, les interactions avec le Vault et les confirmations explicites de vérification. Ces signaux sont enregistrés sous forme d'horodatages uniquement -- aucun contenu ni métadonnée comportementale n'est stocké. Le système suit la présence, pas les actions.

6.2 Intervalles Configurables

Les utilisateurs configurent leur propre fréquence de vérification -- hebdomadaire, mensuelle ou trimestrielle. Si aucun signal d'activité n'est détecté dans l'intervalle, le système entre en phase d'alerte. Les utilisateurs peuvent également définir une période de grâce, qui ajoute du temps supplémentaire avant toute action. Le Mode Voyage peut suspendre entièrement la Vérification de Vie pendant l'absence d'un utilisateur.

6.3 Conditions de Déclenchement & Chaîne de Notification

Lorsqu'un seuil d'inactivité est atteint, la chaîne suivante est exécutée :

1. Alerte Utilisateur : Keeplas envoie des notifications escaladées à l'utilisateur par WhatsApp et e-mail (web push à venir) lui demandant de confirmer qu'il est actif.
2. Période de Grâce : S'il n'y a aucune réponse durant toute la fenêtre de vérification (environ 15 jours avec rappels), le système passe à l'étape suivante.
3. Notification des Contacts d'Urgence : Les contacts de confiance désignés sont invités à confirmer que l'utilisateur est injoignable, selon le seuil et la fenêtre définis par l'utilisateur.
4. Exécution de la Livraison : Après une période de grâce de 72 heures, si l'utilisateur reste injoignable et que les conditions configurées sont remplies, les règles de livraison configurées sont déclenchées (voir Section 7).

7.1 Diffusion Conditionnelle de Documents

Les utilisateurs peuvent spécifier quels éléments du Vault doivent être transmis à quels bénéficiaires dans chaque règle. Les clés d'éléments pour les éléments désignés sont pré-enveloppées avec la clé publique du bénéficiaire afin que le serveur puisse livrer le texte chiffré sans jamais le déchiffrer.

7.2 Déclencheurs Temporels et Événementiels

Les déclencheurs peuvent être temporels (ex. : « après 180 jours d'inactivité »), événementiels (ex. : « après confirmation de l'alerte de Vérification de Vie par 2 contacts d'urgence ») ou combinés. Plusieurs déclencheurs peuvent être enchaînés avec une logique ET/OU pour créer des conditions de diffusion sophistiquées.

7.3 Mécanismes de Vérification

Avant l'exécution d'une règle de livraison, le système effectue une vérification multi-facteurs : la condition de déclenchement doit être remplie, la période d'attente configurée doit s'être écoulée et (optionnellement) un quorum de contacts d'urgence doit confirmer la situation. Cette vérification multicouche empêche la diffusion accidentelle ou prématurée de données sensibles.

8.1 Données au Repos & Données en Transit

Toutes les données stockées sur les serveurs Keeplas sont déjà chiffrées côté client. Comme couche supplémentaire, les volumes de stockage côté serveur utilisent le chiffrement complet du disque AES-256. Toutes les données en transit sont protégées par TLS 1.3 avec confidentialité persistante. Le certificate pinning est appliqué dans nos applications mobiles natives pour prévenir les attaques MITM.

8.2 Architecture Serveur (Confiance Minimale)

Le serveur est conçu comme une couche de « stockage aveugle ». Il reçoit des blobs chiffrés, les stocke et les renvoie sur demande authentifiée. Il n'effectue jamais de déchiffrement, de dérivation de clé ni de traitement en clair. Les jetons d'authentification sont de courte durée et à portée limitée. Les services backend suivent un modèle de réseau Zero Trust avec TLS mutuel entre les services internes.

8.3 Journalisation & Piste d'Audit

Keeplas maintient un journal d'audit chaîné par hachage pour les événements pertinents en matière de sécurité (tentatives de connexion, rotation de clés, changements de règles de livraison) : chaque entrée est immuable et infalsifiable, chacune hachant la précédente. Les journaux contiennent le type d'événement, l'horodatage, l'IP source (hachée après 30 jours) et le résultat de l'action. Le contenu du Vault, les clés de chiffrement et les phrases de récupération sont architecturalement exclus de tous les pipelines de journalisation.

9.1 Conformité RGPD

Keeplas est conçu avec la conformité RGPD comme base. Les utilisateurs conservent la pleine propriété et le contrôle de leurs données. Comme le contenu du Vault est chiffré de bout en bout, Keeplas agit en tant que sous-traitant sans capacité d'accéder aux données traitées. Les utilisateurs peuvent exporter l'intégralité de leur Vault à tout moment, et la suppression de compte élimine définitivement tout le texte chiffré stocké et les métadonnées associées.

9.2 SOC 2 (Prévu)

Keeplas travaille vers la certification SOC 2 Type II pour les critères de services de confiance en matière de Sécurité, Disponibilité et Confidentialité. Notre infrastructure et nos processus opérationnels sont alignés sur ces exigences, avec un premier audit ciblé pour le T4 2026.

9.3 Audits Tiers (Prévu)

Nous nous engageons à des audits de sécurité indépendants réguliers de nos implémentations cryptographiques, applications clientes et infrastructure serveur. Les résultats des audits seront publiés sous forme de résumé sur notre page de sécurité. Notre premier test de pénétration tiers complet et notre revue cryptographique sont prévus pour le S2 2026.