* 1. [Documents de référence](#Documentsderfrence) * 2. [Détails de conception](#Dtailsdeconception) * 3. [Mot de passe](#Motdepasse) * 4. [Cache](#Cache) * 5. [Chiffrement des communications](#Chiffrementdescommunications) * 6. [Confidentialité des `Pcd` et Prd](#ConfidentialitdesPcdetPrd) * 7. [Confidentialité des messages sur les relais](#Confidentialitdesmessagessurlesrelais) * 8. [Clé de chiffrement robuste](#Cldechiffrementrobuste) * 8.1. [Résistance aux attaques cryptanalytiques](#Rsistanceauxattaquescryptanalytiques) * 8.2. [Diffusion et confusion](#Diffusionetconfusion) * 8.3. [Non-linéarité](#Non-linarit) * 9. [Fonctions de hashage](#Fonctionsdehashage) * 10. [Exigences génériques](#Exigencesgnriques) * 10.1. [Pas de secret de la conception](#Pasdesecretdelaconception) * 10.2. [Validé par la communauté scientifique](#Validparlacommunautscientifique) * 10.3. [Implémentation correcte](#Implmentationcorrecte) * 10.4. [Détermination](#Dtermination) * 10.5. [Rapidité de calcul](#Rapiditdecalcul) * 10.6. [Diffusion (ou effet avalanche)](#Diffusionoueffetavalanche) * 10.7. [Résistance aux collisions](#Rsistanceauxcollisions) * 10.7.1. [Résistance aux collisions faibles](#Rsistanceauxcollisionsfaibles) * 10.7.2. [Résistance aux collisions fortes](#Rsistanceauxcollisionsfortes) * 10.8. [Résistance à la pre_id](#Rsistancelapre_id) * 10.8.1. [Résistance à la pre_id](#Rsistancelapre_id-1) * 10.8.2. [Résistance à la seconde pre_id](#Rsistancelasecondepre_id) * 10.9. [Compression](#Compression) * 10.10. [Non réversibilité](#Nonrversibilit) * 10.11. [Absence de toute structure prévisible](#Absencedetoutestructureprvisible) * 11. [Gestion sécurisée des clés](#Gestionscurisedescls) * 12. [Performance](#Performance) * 13. [Disponibilité](#Disponibilit) * 14. [Évolutivité](#volutivit) * 15. [Autres Mesures de sécurité](#AutresMesuresdescurit) * 16. [Todo](#Todo) # Exigences de sécurité et de confidentialité ## 1. Documents de référence Voir [_Doc_references.md](_Doc_references.md). ## 2. Détails de conception Tous les chiffrements symétriques sont opérés avec l'algorithme AES-GCM 256 bits. Tous les hash sont opérés avec l'algorithme SHA256. La librairie Rust `Nakamoto`, permet de scanner les blocs (et bientôt la mempool) côté client et de détecter des transactions Bitcoin correspondant aux clés publiques des clés cryptographiques privées du HD Wallet Bitcoin contenant les clés Bitcoin de mainnet et de signet. ## 3. Mot de passe Utilisation du mot de passe strictement en mémoire. Mot de passe fort (18 caractères minimum avec minuscules, majuscules, lettre, nombres, et caractères spéciaux) ou mnémonique de 12 mots à noter ou certificat (ou équivalent) stocké de façon sécurisée. ## 4. Cache Stockage sécurisé du cache par un chiffrement par le mot de passe. ## 5. Chiffrement des communications Le chiffrement du transport des données se fait par TLS entre les clients et le noeuds entrants pour palier aux restrictions sur les flux non TLS par les navigateurs et les applications mobiles. Néanmoins tous les messages chiffrent les `Pcd` et `Prd` avec une clé de chiffrement conforme aux exigences suivantes et échangée dans le Diffie-Hellman de la transaction SP, en parallèle donc des flux `Pcd` et `Prd`.Ces clés ne sont accessibles donc qu'avec la clé privée du destinataire ou de l'émetteur, qui ne sont jamais partagées. ## 6. Confidentialité des `Pcd` et Prd Le stockage chiffré de cache est un chiffrement symétrique conformément aux exigences suivantes. Le chiffrement des `Pcd` est un chiffrement symétrique conformément aux exigences suivantes. Le chiffrement des clés de chiffrement dans les `Prd` est un chiffrement symétrique conformément aux exigences suivantes selon : * **Données publiques**: un chiffrement symétrique conformément aux exigences suivantes depuis la `ProcessKey`. Tout le monde peut donc déchiffrer. * **Données confidentielles avec les membres d'un `role` d'un `ItemProcess` dans les Pcd**: un chiffrement symétrique conformément aux exigences suivantes depuis une clé de chiffrement générée à la volée par champs par items d'une liste d'un Pcd. * **Données confidentielles avec les membres d'un `role` d'un `ItemProcess` dans les Prd**: un chiffrement symétrique conformément aux exigences suivantes depuis les clés de chiffrement AES-GCM-256 générée à la volée dans les `Pcd` et alors transmises par le Prd, chiffrées par la `KeyConfiditial` d'une transaction `SP`. * **Données privées**: un chiffrement symétrique conformément aux exigences suivantes depuis le chiffrement par la clé de spend de login (`recover`) du signet (voir Login - Specs). ## 7. Confidentialité des messages sur les relais Les `Pcd` et les `Prd` sont envoyés aux relais dans des enveloppes appelées `Message`. Ces enveloppent communique les `Pcd` et les `Prd` de façon chiffrée par la `ProcessKey`. Ainsi les messages sont rendus fongibles sur le réseau de relais. Tous les `Prd` sont confirmés par un et chiffrent les clés transamises par une `KeyConfiditial`. Les relais peuvent déchiffrer les enveloppes avec la `ProcessKey`, le contenu étant chiffré en plus en fonction des niveaux de confidentialité. L'objectif du chiffrage des enveloppe est de donner, un temps, un coût et une complexité aux analyses systématiques des flux. ## 8. Clé de chiffrement robuste La force d'un algorithme de chiffrement symétrique repose largement sur la complexité de sa clé. Une clé plus longue offre généralement une meilleure sécurité. Les tailles de clé typiques pour un chiffrement fort sont de 128 bits, 192 bits, ou 256 bits. Pour l'AES-GCM, les clés de 256 bits sont à ce stade réputées "quantum-resistant" et sont donc à privilégier, elles satisfont aussi les contraintes suivantes. ### 8.1. Résistance aux attaques cryptanalytiques Un algorithme fort doit résister à diverses attaques, y compris les attaques par force brute (où un attaquant essaie toutes les clés possibles), les attaques par texte clair connu, les attaques par texte clair choisi, les attaques par texte chiffré choisi, et plus encore. L'AES-GCM les clés de 256 bits n'est pas par design robuste à ces attaques, mais avec une clé suffisamment longue (de longueur quantique) le temps nécessaire est estimé comme équivalent à une résistance. ### 8.2. Diffusion et confusion Ces deux principes, introduits par Claude Shannon, sont essentiels à la sécurité d'un algorithme. La diffusion vise à disperser l'influence d'un seul caractère du texte clair sur de nombreux caractères du texte chiffré, tandis que la confusion vise à complexifier la relation entre la clé de chiffrement et le texte chiffré. ### 8.3. Non-linéarité L'algorithme doit incorporer des éléments non linéaires pour contrer les attaques linéaires et différentielles. Cela rend la prédiction du comportement de l'algorithme plus difficile pour un attaquant. ## 9. Fonctions de hashage Les fonctions de hachage jouent un rôle crucial dans de nombreux domaines de la cryptographie et de la sécurité informatique, notamment dans la vérification de l'intégrité des données, l'authentification, la signature numérique, et la génération de jetons sécurisés. Pour être efficaces et sécurisées, ces fonctions doivent répondre à plusieurs exigences essentielles : ## 10. Exigences génériques ### 10.1. Pas de secret de la conception La sécurité d'un bon système cryptographique ne doit pas reposer sur le secret de son algorithme (principe de Kerckhoffs) et doit être basée sur des principes cryptographiques éprouvés. ### 10.2. Validé par la communauté scientifique Un algorithme est considéré comme plus fort s'il a été soumis à l'examen et à l'analyse de la communauté cryptographique internationale, qui cherche des vulnérabilités potentielles. ### 10.3. Implémentation correcte Une implémentation fautive d'un algorithme de chiffrement fort peut introduire des vulnérabilités. Il est crucial que l'implémentation soit vérifiée pour être sécurisée. La librairie utilisée doit avoir été l'objet d'un audit ([librairie aes-gcm de rust a été auditée](https://research.nccgroup.com/2020/02/26/public-report-rustcrypto-aes-gcm-and-chacha20poly1305-implementation-review/)). ### 10.4. Détermination Pour toute entrée donnée, la fonction de hachage doit toujours produire la même sortie. ### 10.5. Rapidité de calcul La fonction doit être capable de générer le hachage rapidement, même pour de grandes quantités de données. ### 10.6. Diffusion (ou effet avalanche) Un changement minime dans l'entrée (même un seul bit) doit entraîner un changement significatif et imprévisible dans la sortie. Cela garantit qu'il est difficile de prédire comment la sortie changera en fonction des modifications apportées à l'entrée. ### 10.7. Résistance aux collisions Il doit être pratiquement impossible de trouver deux entrées distinctes qui produisent la même sortie. Cela se décline en deux sous-catégories : #### 10.7.1. Résistance aux collisions faibles Il est difficile de trouver une seconde entrée qui a le même hachage qu'une entrée spécifiée. #### 10.7.2. Résistance aux collisions fortes Il est difficile de trouver deux entrées distinctes qui produisent le même hachage. ### 10.8. Résistance à la pre_id Pour une sortie de hachage donnée, il doit être difficile de trouver une entrée qui correspond à cette sortie. Cela se décline également en deux sous-catégories : #### 10.8.1. Résistance à la pre_id Il est difficile de trouver une entrée qui hache vers une sortie de hachage spécifiée. #### 10.8.2. Résistance à la seconde pre_id Étant donné une entrée, il est difficile de trouver une autre entrée qui produit le même hachage. ### 10.9. Compression La fonction de hachage doit pouvoir prendre une entrée de taille arbitraire et produire une sortie de taille fixe. ### 10.10. Non réversibilité Il doit être infaisable de retrouver l'entrée à partir de la sortie du hachage. Cela signifie que la fonction est à sens unique. ### 10.11. Absence de toute structure prévisible La fonction de hachage ne doit pas produire des sorties qui montrent des patterns ou des structures prévisibles, quelles que soient les entrées. ## 11. Gestion sécurisée des clés La manière dont les clés sont générées, stockées, distribuées, révoquées, et détruites est tout aussi importante que l'algorithme de chiffrement lui-même. Les clés seront générées strictement par l'utilisateur et feront l'objet d'un traitement `MPC` avec un chiffrement des parties par le mot de passe connu de l'utilisateur seul et jamais stocké. Les parties sont pour la moitié stockées dans le contexte utilisateur (chiffrées par le mot de passe) et pour une autre partie, chiffrées en morceaux (`Shamir Secret Sharing`) (chiffrés par le mot de passe) et distribuées par les membres choisis d'un `ItemProcess` choisi par le rôle des gestionnaires des listes de membres (`member`) en charge de restituer ces morceaux à la demande. L'utilisateur seul peut détruire une clé de révocation (`revoke`) ou supprimer l'image de login qui contient la première partie de la clé de login, indispensable pour recomposer sa clé. ## 12. Performance Le temps de réponse doit être rapide pour les opérations de login. Ce temps sera estimé de façon empirique au fur et à mesure des implémentations. ## 13. Disponibilité La haute disponibilité et la reprise après sinistre sont permises par la redondance des `relais` sans système central ou critique et robustes à la défaillance d'une partie des participants. C'est idem pour la redondance au sein des `membres` des gestionnaires des membres dans les `processus`, qui ont tous des actions égales et robustes à la défaillance d'une partie des participants. En cas de perte, vol, corruption, ou expiration des clés, l'utilisateur peut de son initiative et en toute autonomie révoquer une identité et en générer une nouvelle. ## 14. Évolutivité La capacité à gérer une augmentation du nombre d'`utilisateurs` est un équilibre arbitré par les parties prenantes, en fonction du besoin de `relais` et de `membres`. Les parties prenantes ont les moyens d'enrôler par eux-mêmes les relais et les membres par `rôles` et par `ItemProcess` . ## 15. Autres Mesures de sécurité Les mécanismes de défense contre les vulnérabilités courantes doivent être implémentés (CSRF, XSS). À noter, que les seules bases de données sont dans l'IndexedDB des navigateurs et applications mobiles, côté utilisateur et écrasées des données confirmées reçues du réseau et toutes vérifiables. Tous les autres composants et utilisateurs ont un stockage en mémoire, non persisté (mais restauré à leur propre récupération de leur identité). ## 16. Todo