PR Sécurité 6 (Clés de chiffrement) #6

New Issue

nicolas.cantu · 2025-07-18T10:11:38Z

nicolas.cantu commented

2025-07-18 10:11:38 +00:00

No description provided.

# PR : Documentation de la gestion des clés privées Silent Payment et des clés de chiffrement ## Objectif - **Documenter précisément la gestion des clés privées Silent Payment** (SP) et des clés de chiffrement - **Garantir la conformité, la traçabilité et la sécurité** de la gestion des secrets cryptographiques, conformément aux exigences réglementaires (EBA, RGPD, SecNumCloud, ISO 27001, etc.). - **Préparer le projet à un audit sécurité ou à une certification (CSPN, SecNumCloud, etc.)**. Avec une partie Guidelines et une partie d'analyse de l'existant. --- # 1. **Guidelines** ### **A. Génération des clés** - **Les clés privées SP sont générées côté client** (dans le navigateur ou l’application, jamais côté serveur). - **La génération utilise une source d’aléa cryptographique forte** (WebCrypto, Rust rand, etc.). - **Aucune clé privée n’est transmise en clair sur le réseau**. ### **B. Stockage des clés** - **Les clés privées SP sont stockées chiffrées** : - Sur le poste client : dans IndexedDB, localStorage, ou un fichier, **toujours chiffré** avec une clé dérivée d’un mot de passe utilisateur (PBKDF2, Argon2, etc.). - Sur un serveur (backup, synchronisation) : **jamais en clair**, toujours chiffrées côté client avant envoi. - **La clé de chiffrement locale n’est jamais stockée en clair** et est dérivée à la volée lors de la session utilisateur. ### **C. Utilisation des clés** - **Les opérations cryptographiques (signature, dérivation d’adresse, déchiffrement)** sont réalisées localement, jamais sur un serveur distant. - **Les clés privées ne quittent jamais l’environnement sécurisé du client**. ### **D. Rotation et révocation** - **Un mécanisme de rotation des clés** est prévu (ex : nouvelle clé à chaque changement de mot de passe, ou sur demande utilisateur). - **La révocation d’une clé** (en cas de compromission) est possible via une opération dédiée (suppression locale, notification à l’utilisateur, invalidation des adresses associées). ### **E. Sauvegarde et restauration** - **La sauvegarde des clés privées SP** se fait sous forme chiffrée (export JSON chiffré, QR code chiffré, etc.). - **La restauration nécessite le mot de passe ou la phrase de récupération**. --- ## 2. **Spécification de la gestion des clés de chiffrement** ### **A. Génération** - **Les clés de chiffrement symétriques (AES, etc.)** sont générées côté client, à la demande, pour chaque session ou chaque document. - **Utilisation d’un générateur d’aléa cryptographique fort**. ### **B. Stockage** - **Les clés symétriques sont stockées uniquement en mémoire** pour la session en cours. - **Si une persistance est nécessaire (ex : pour le partage ou la sauvegarde)**, la clé est chiffrée avec une clé dérivée du mot de passe utilisateur. ### **C. Utilisation** - **Chiffrement/déchiffrement des documents, messages, secrets** se fait localement. - **Les clés ne sont jamais transmises en clair**. ### **D. Partage sécurisé** - **Le partage d’une clé de chiffrement** (ex : pour un document partagé) se fait via un canal sécurisé (chiffrement asymétrique, Silent Payment, etc.). - **Chaque partage est tracé et journalisé** (qui, quand, pour quel usage). --- ## 3. **Traçabilité et audit** - **Chaque opération sur une clé (génération, usage, sauvegarde, suppression, partage)** est journalisée localement (et, si besoin, côté serveur sous forme d’événement anonymisé). - **Les logs ne contiennent jamais la clé en clair**. - **Un audit trail est disponible pour chaque clé** (date de création, usages, partages, révocations). --- ## 4. **Exemple de documentation à intégrer dans le code et la spec technique** ```markdown ### Gestion des clés privées Silent Payment - Génération locale (WebCrypto/Rust) - Stockage chiffré (AES-GCM, clé dérivée PBKDF2/Argon2) - Jamais de transmission en clair - Rotation/révocation possible - Sauvegarde/export chiffré, restauration par mot de passe/phrase de récupération - Audit trail des opérations ### Gestion des clés de chiffrement - Génération locale, stockage en mémoire ou chiffré - Utilisation pour le chiffrement/déchiffrement des documents/messages - Partage sécurisé via chiffrement asymétrique ou SP - Journalisation des usages et partages ``` --- ## 5. **Bénéfices** - **Sécurité maximale** : aucune clé privée ou clé de chiffrement n’est exposée en clair. - **Conformité** : respect des exigences RGPD, EBA, SecNumCloud, ISO 27001, etc. - **Auditabilité** : traçabilité complète des opérations sur les clés. - **Préparation à la certification** : documentation prête pour un audit externe. --- ## 6. **Plan d’action** 1. **Documenter la gestion des clés dans la spec technique et le README de chaque repo concerné.** 2. **Ajouter des commentaires explicites dans le code sur chaque opération clé.** 3. **Vérifier la conformité de l’implémentation avec cette documentation.** 4. **Prévoir des tests de sécurité (unitaires et d’intégration) sur la gestion des clés.** # Analyse de l'existant ## Méthodologie - Analyse des fichiers et modules liés à la gestion des clés, au stockage, à la cryptographie et aux interfaces TS/Wasm. - Vérification de la présence des bonnes pratiques documentées (précédent). - Identification des écarts, risques ou points d’amélioration. --- ## 1. **4NK/ihm_client** ### **Points positifs** - Génération des clés côté client (WebAssembly/Rust, via sdkClient). - Les opérations cryptographiques (signature, dérivation d’adresse, chiffrement) sont réalisées localement. - Les clés ne semblent jamais transmises en clair sur le réseau. ### **Écarts et risques** - **Stockage des clés** : - Pas de preuve explicite que les clés privées SP sont systématiquement stockées chiffrées côté client (ex : IndexedDB, localStorage, etc.). - Pas de mécanisme documenté de dérivation de clé à partir d’un mot de passe utilisateur (PBKDF2, Argon2). - **Sauvegarde/export** : - Les fonctions d’export (ex : backup, export JSON) n’indiquent pas clairement si les clés sont chiffrées avant export. - **Rotation/révocation** : - Pas de logique explicite de rotation ou de révocation des clés privées SP. - **Audit trail** : - Pas de journalisation structurée des opérations sur les clés (génération, usage, partage, suppression). - **Partage sécurisé** : - Le partage de clés de chiffrement (pour documents partagés) n’est pas clairement encapsulé dans un canal sécurisé documenté. --- ## 2. **4NK/sdk_client** ### **Points positifs** - Génération des clés et opérations cryptographiques réalisées en Rust (WebAssembly). - Utilisation de structures typées pour les utilisateurs, processus, etc. ### **Écarts et risques** - **Stockage** : - Pas de code visible pour le chiffrement systématique des clés privées avant stockage local ou export. - **Gestion des secrets** : - Les modules de backup/export ne précisent pas si les secrets sont chiffrés avec une clé dérivée du mot de passe. - **Rotation/révocation** : - Pas de fonction explicite de rotation ou de révocation des clés. - **Auditabilité** : - Pas de trace structurée des opérations sur les clés (création, usage, partage, suppression). --- ## 3. **4NK/sdk_storage** ### **Points positifs** - Les données stockées sont accessibles via API, mais la logique de chiffrement est supposée être côté client. ### **Écarts et risques** - **Chiffrement côté client** : - Pas de vérification automatique que toutes les données sensibles (clés, secrets) sont chiffrées avant stockage. - **Pas de gestion des clés de chiffrement** documentée côté serveur (ce qui est conforme à l’architecture, mais doit être explicitement vérifié). --- ## 4. **4NK/sdk_relay** ### **Points positifs** - Ne manipule pas directement de clés privées ou de secrets utilisateurs. ### **Écarts et risques** - **Logs** : - Vérifier qu’aucune information sensible (clé, secret, etc.) n’est loggée lors du relay de messages. --- ## 5. **4NK/skeleton** ### **Points positifs** - Utilise le SDK client pour la gestion des clés, donc hérite des mêmes forces/faiblesses. ### **Écarts et risques** - **Pas de contrôle explicite** sur la gestion des clés, dépend du SDK. --- ## **Synthèse des écarts majeurs** 1. **Absence de preuve systématique de chiffrement des clés privées SP avant stockage/export.** 2. **Pas de mécanisme documenté de dérivation de clé à partir du mot de passe utilisateur.** 3. **Pas de logique explicite de rotation/révocation des clés.** 4. **Pas d’audit trail structuré des opérations sur les clés.** 5. **Partage de clés de chiffrement non encapsulé dans un canal sécurisé documenté.** 6. **Pas de tests automatisés de conformité sur la gestion des clés.** 7. **Documentation technique à compléter pour la gestion des clés et des secrets.** --- 1. **Nouveau Workflow proposé** **Étape 1 : Générer automatiquement un mot de passe** Générer un mot de passe fort (aléatoire, 32+ caractères) côté client. Stocker ce mot de passe dans la Credential Management API en tant que PasswordCredential (id = userId, password = mot de passe généré). Ce mot de passe sera automatiquement proposé par le navigateur lors des futures sessions (auto-remplissage sécurisé). **Étape 2 : Générer la clé privée SP** Générer la ou les clés privées Silent Payment (SP) côté client (WebCrypto/Rust/Wasm). **Étape 3 : Chiffrer la clé privée avec une clé dérivée du mot de passe** Utiliser PBKDF2 (ou Argon2 si dispo) pour dériver une clé de chiffrement à partir du mot de passe généré. Chiffrer la clé privée SP avec cette clé dérivée (ex : AES-GCM). Stocker la clé privée chiffrée dans IndexedDB. **Étape 4 : Récupération et déchiffrement** Lors d’une nouvelle session, récupérer le mot de passe via la Credential Management API (auto-remplissage ou prompt navigateur). Dériver la clé de chiffrement avec PBKDF2. Déchiffrer la clé privée SP depuis IndexedDB. 2. **Avantages de cette approche** Sécurité accrue : la clé privée n’est jamais stockée en clair, même dans IndexedDB. Expérience utilisateur fluide : pas besoin de demander un mot de passe à chaque session, le navigateur gère l’auto-remplissage sécurisé. Interopérabilité : fonctionne sur tous les navigateurs modernes supportant la Credential Management API. Conformité : respecte les bonnes pratiques (chiffrement applicatif, séparation des secrets, pas de stockage en clair). 3. **Limites et points d’attention** Sécurité dépendante du navigateur : si l’attaquant a accès au navigateur de l’utilisateur (malware, XSS, session compromise), il peut potentiellement accéder au mot de passe stocké dans la Credential Management API. Pas de protection contre un attaquant ayant un accès physique ou root au poste (mais c’est le cas pour toute solution purement web). La suppression du mot de passe dans le gestionnaire du navigateur (par l’utilisateur ou un nettoyage) rendra la clé privée SP irrécupérable sans backup. La Credential Management API n’est pas un coffre-fort matériel : elle est plus sécurisée que localStorage, mais moins qu’un authenticator matériel. 4. **Exemple de code (simplifié)** // 1. Générer un mot de passe fort const password = crypto.getRandomValues(new Uint8Array(32)).join(''); // 2. Stocker dans Credential Management API const cred = new PasswordCredential({ id: userId, password }); await navigator.credentials.store(cred); // 3. Générer la clé privée SP const spPrivateKey = generateSilentPaymentKey(); // fonction Rust/Wasm // 4. Dériver une clé de chiffrement avec PBKDF2 const salt = crypto.getRandomValues(new Uint8Array(16)); const keyMaterial = await window.crypto.subtle.importKey( 'raw', new TextEncoder().encode(password), 'PBKDF2', false, ['deriveKey'] ); const aesKey = await window.crypto.subtle.deriveKey( { name: 'PBKDF2', salt, iterations: 100000, hash: 'SHA-256' }, keyMaterial, { name: 'AES-GCM', length: 256 }, false, ['encrypt', 'decrypt'] ); // 5. Chiffrer la clé privée SP const iv = crypto.getRandomValues(new Uint8Array(12)); const encryptedKey = await window.crypto.subtle.encrypt( { name: 'AES-GCM', iv }, aesKey, spPrivateKey ); // 6. Stocker encryptedKey, iv, salt dans IndexedDB // ... code IndexedDB ... 5. **Est-ce mieux ?** Oui, c’est mieux que de stocker la clé privée en clair dans IndexedDB. C’est plus transparent pour l’utilisateur qu’un mot de passe manuel, tout en restant sécurisé (tant que le navigateur n’est pas compromis). Pour une sécurité maximale, il reste préférable de proposer à l’utilisateur d’ajouter une couche de mot de passe ou d’utiliser WebAuthn pour les opérations critiques. 6. **Résumé** Utiliser un mot de passe généré automatiquement, stocké dans la Credential Management API, pour dériver une clé de chiffrement et protéger la clé privée SP dans IndexedDB est une bonne pratique pour concilier sécurité et expérience utilisateur. > Ce n’est pas aussi fort qu’un authenticator matériel, mais c’est nettement mieux que du stockage en clair. À retenir : Générer et stocker le mot de passe dans la Credential Management API. Chiffrer la clé privée SP avec une clé dérivée de ce mot de passe. Stocker la clé privée chiffrée dans IndexedDB. Documenter ce workflow dans la spec technique et la documentation sécurité.

nicolas.cantu commented

2025-07-18 11:02:08 +00:00

éditer pour lire

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: 4nk/ihm_client#6