Spécifications cryptographiques de CryptPeer
Spécification cryptographique publique de référence fondée sur un système d'authentification à clé segmentée

1. À propos de ce document

Ce document spécifie les aspects cryptographiques publics de CryptPeer, système de communication sécurisé reposant sur un système d'authentification à clé segmentée et sur une architecture de chiffrement de bout en bout.

Objectifs :

• décrire de manière normative les primitives cryptographiques publiques utilisées ;
• formaliser le rôle du moteur de clé segmentée dans l’architecture applicative ;
• décrire la hiérarchie logique des clés applicatives et leurs séparations d’usage ;
• fournir une base publique de lecture pour développeurs, architectes sécurité et auditeurs.

Le présent document n’expose pas les mécanismes internes non publics du moteur, les paramètres sensibles d’implémentation, les constructions propriétaires complémentaires, ni les dispositifs non nécessaires à la compréhension du modèle public.

2. Périmètre fonctionnel et cryptographique

2.1 Fonctions couvertes

Sont couverts :

• messagerie chiffrée 1:1 et de groupe au sein d'une instance CryptPeer ;
• transferts de fichiers et pièces jointes ;
• enregistrements audio/vidéo capturés localement puis protégés ;
• appels audio/vidéo et partage d'écran ;
• sauvegardes chiffrées multi-supports ;
• chiffrement et déchiffrement autonome de fichiers ;
• exports et imports protégés de données ;
• modes standard, masqué et défense ;
• moteur d'authentification à clé segmentée et son API publique logique ;
• hiérarchie de clés applicatives fondée sur K_seg.

2.2 Hors périmètre

Ne sont pas couverts, sauf mention explicite :

• mécanismes internes non publics du moteur de clé segmentée ;
• formats internes propriétaires, paramètres sensibles et politiques détaillées d’implémentation ;
• mécanismes propriétaires complémentaires de licence, d’attestation, d’audit ou de protection locale ;
• procédures organisationnelles et mesures physiques ;
• analyses réglementaires détaillées par juridiction.

3. Notations, types et conventions

3.1 Types

• Un octet : valeur dans {0,…,255}.
• Chaîne d'octets : b ∈ {0,1}^* ; on note |b| la longueur en octets.
• Chaîne de caractères : encodée en UTF-8 avant tout traitement cryptographique.
• Entier non signé : encodé de manière déterministe lorsqu'il est inclus dans une entrée de KDF.

3.2 Opérations

• Concaténation : X || Y.
• Hachage : H(x).
• PBKDF2 : PBKDF2_HMAC_SHA256(P, salt, iter, L).
• HKDF : HKDF_SHA256(salt, IKM, info, L).
• Encodage d’un entier : encodeUint64(n) si requis par le contexte.

3.3 Notation des clés

• K_pair : clé logique d'appairage ou d’autorisation, gérée par le moteur segmenté ;
• K_seg : clé racine locale d’application exposée à CryptPeer par le moteur ;
• K_conv : clé de conversation ;
• K_file : clé associée au chiffrement de fichiers, d’exports ou de sauvegardes ;
• K_msg : clé éphémère associée à un message, une session ou une fenêtre d’usage ;
• K_view : clé utilisée pour un affichage temporairement déchiffré.

Sauf mention explicite, les clés symétriques utilisées pour le chiffrement applicatif sont de longueur 256 bits.

3.4 Conventions normatives

Dans ce document :

• DOIT exprime une exigence normative ;
• NE DOIT PAS exprime une interdiction normative ;
• DEVRAIT exprime une recommandation forte ;
• PEUT exprime une possibilité ou une option d’implémentation.

4. Référentiels et principes de conception

CryptPeer s'appuie publiquement sur :

• AES-256-GCM pour le chiffrement authentifié des contenus applicatifs ;
• SHA-256 et, selon les usages publics documentés, SHA3-256 ;
• PBKDF2-HMAC-SHA-256 et HKDF-SHA-256 pour les dérivations publiques décrites ;
• le système d'authentification à clé segmentée breveté (WO2018154258A1), modélisé comme un composant fournissant :
  • une API restreinte ;
  • des garanties de non-export direct ;
  • une exposition éphémère des secrets applicatifs utiles.

La conception respecte les principes :

• robustesse symétrique 256 bits ;
• séparation claire des rôles :
  • moteur segmenté,
  • client,
  • serveur relais ;
• séparation cryptographique des usages par labels et contextes ;
• dérivation locale à la demande ;
• volatilité maximale des secrets applicatifs ;
• minimisation des métadonnées et des traces ;
• absence de divulgation publique des mécanismes internes non nécessaires à la compréhension du modèle.

5. Architecture globale de CryptPeer

5.1 Composants

Une instance CryptPeer comprend :

• un serveur relais S :
  • auto-hébergé ou exploité sous contrôle ;
  • stockant uniquement des contenus et métadonnées déjà protégés ;
• un bundle client web :
  • code JS/TS/WASM servi par S ;
  • exécuté dans le navigateur du terminal ;
• un moteur local de clé segmentée :
  • logiciel et/ou matériel ;
  • exposant K_seg au client via une interface locale restreinte ;
• un annuaire local structurant les utilisateurs en catégories.

Une instance CryptPeer ne repose pas sur une fédération globale obligatoire.

5.2 Rôles

• Client :
  • dérive toutes les clés applicatives à partir de K_seg et de données publiques ;
  • effectue tout chiffrement et tout déchiffrement ;
  • gère l'affichage et les protections locales associées.
• Moteur de clé segmentée :
  • gère K_pair et ses segments ;
  • restitue éphémèrement K_seg selon une politique locale.
• Serveur relais S :
  • sert le client web ;
  • authentifie et relaie les connexions ;
  • stocke et relaie des blocs chiffrés.
• Supports de sauvegarde :
  • reçoivent des backups déjà chiffrés.

5.3 Gestion de licence matérielle (EviEngine)

CryptPeer peut intégrer la technologie EviEngine de Freemindtronic pour la gestion des licences sans serveur externe ni base de données centralisée. Ce composant ne fait pas partie du chemin de chiffrement des contenus applicatifs, mais contribue au modèle de souveraineté, d’autonomie opérationnelle et de fonctionnement hors ligne.

Propriétés principales du modèle de licence :

• Licence liée au matériel :
  • la licence PEUT être associée à des caractéristiques matérielles de la machine ;
  • elle n'est pas conçue comme une identité nominative centralisée.
• Sans serveur ni base de données de licence :
  • aucun serveur de licence externe n'est requis pour valider l'usage local ;
  • aucune base de données centralisée n'est nécessaire ;
  • la vérification de la licence est réalisée localement.
• Fonctionnement hors ligne :
  • la validation de licence PEUT fonctionner sans connexion Internet ;
  • la continuité de service ne dépend pas d'un tiers distant.
• Minimisation des données :
  • aucun compte utilisateur centralisé n'est structurellement requis pour la licence ;
  • aucune télémétrie de licence vers un cloud tiers n'est nécessaire dans le modèle souverain.

D'un point de vue cryptographique, la gestion de licence via EviEngine est orthogonale à la sécurité des contenus. Les primitives, la hiérarchie de clés et les protocoles décrits dans les parties suivantes restent analytiquement séparés de cette fonction.

Les détails cryptographiques internes d'EviEngine ne relèvent pas du présent document public.

6. Modes de déploiement

6.1 Mode local-only

En mode local-only :

• S n'est accessible que sur un réseau local ou fermé ;
• aucune visibilité directe depuis Internet n'est requise ;
• toutes les communications restent dans la bulle réseau locale.

6.2 Mode avec accès distant

En mode distant :

• S est derrière un routeur, un pare-feu ou un reverse proxy ;
• un nom de domaine ou sous-domaine PEUT être exposé ;
• TLS DOIT être utilisé pour sécuriser le transport HTTP(S).

Le contenu applicatif est protégé côté client avant transit et stockage.

6.3 Auto-portabilité

L'instance S PEUT être déployée sur :

• Raspberry Pi 5 ;
• mini-PC fanless ;
• serveurs, NAS, VPS Linux.

Le code serveur et les données protégées PEUVENT être déplacés sous réserve de protéger les secrets d'administration et de respecter le niveau de durcissement requis.

7. Client web universel

7.1 Principe

CryptPeer fournit un client unique :

• implémenté en JS/TS/WASM ;
• exécuté dans un navigateur moderne ;
• déployé de manière homogène sur différents terminaux.

7.2 Conséquences

• une seule base de code cliente à auditer et durcir ;
• mises à jour centralisées via S ;
• homogénéité de comportement entre terminaux compatibles.

Les risques spécifiques au navigateur restent pris en compte dans le modèle de menace.

8. Modes de fonctionnement

8.1 Mode CryptPeer (standard)

Fonctionnalités :

• messagerie 1:1 et de groupe ;
• transferts de fichiers et pièces jointes ;
• enregistrements audio/vidéo protégés ;
• appels audio/vidéo et conférences ;
• backups chiffrés.

Propriétés cryptographiques :

• chiffrement de bout en bout fondé sur K_seg ;
• dérivations locales séparées par usage ;
• aucune clé de contenu sur le serveur.

8.2 Mode CryptPeer Masqué

Objectif : réduire l'exposition visuelle.

• affichage protégé par défaut selon la configuration ;
• déchiffrement explicite d'une conversation ;
• re-protection automatique de la vue :
  • au bout d'un délai ;
  • ou sur évènement (changement d'onglet, perte de focus, etc.) ;
• effacement des buffers de clair après usage lorsque possible.

Ce mode PEUT utiliser une clé de vue K_view dérivée de K_seg.

8.3 Mode CryptPeer Defense

Objectif : usages régaliens ou hautement sensibles. En savoir plus →

• instance et paramètres dédiés ;
• réduction maximale de la persistance ;
• politique RAM-only ou no-logs selon configuration ;
• historique réduit voire absent selon les besoins.

9. Multi-serveurs favoris et absence de fédération

9.1 Liste de favoris

Le client maintient localement :

Favorites = { (label_i, url_i) }_i

L'utilisateur choisit à tout instant un seul serveur S auquel se connecter.

9.2 Aucun maillage obligatoire

Il n'y a pas, dans l’architecture de référence :

• de fédération globale imposée ;
• d’annuaire universel imposé ;
• de dépendance systémique à un routage inter-instances.

Conséquences :

• chaque instance S PEUT rester une bulle indépendante ;
• la cartographie globale des communications est réduite.

10. Annuaire, catégories et cloisonnement logique

10.1 Annuaire local

Chaque instance S PEUT maintenir un annuaire :

• ensemble d'utilisateurs ;
• identifiants et informations nécessaires à l'authentification ;
• données protégées selon leur sensibilité.

10.2 Catégories de contacts

L'administrateur PEUT associer chaque utilisateur à une ou plusieurs catégories :

C = { C_1, C_2, … }

Ces catégories servent à structurer les autorisations et le cloisonnement logique.

10.3 Groupes et cloisonnement

Ce cloisonnement limite la propagation latérale d'une compromission de compte et les risques d’exposition inter-périmètres au sein d'une même instance.

11. Doctrine « Zero Trust. Zero Cloud. Zero Trace. »

11.1 Zero Trust

• le serveur S est non porteur des secrets de contenu ;
• S ne détient aucune clé de déchiffrement applicative ;
• les dérivations applicatives critiques DOIVENT être réalisées côté client avec K_seg.

11.2 Zero Cloud

• aucun secret structurant (K_pair, segments, K_seg, clés de contenus) n'est confié à un service cloud tiers ;
• les supports distants ne reçoivent que des données préalablement chiffrées.

11.3 Zero Trace

• dérivation à la demande, effacement rapide des clés ;
• pas de clair persistant côté client au-delà de ce qui est strictement nécessaire au fonctionnement ;
• journaux minimaux côté serveur ;
• réduction maximale des traces persistantes selon le mode choisi.

12. Modèle de menace et hypothèses

12.1 Adversaires pris en compte

• Adversaire serveur :
  • contrôle de S (root, base, code servi) ;
• Adversaire réseau :
  • interception, MITM, observation ;
• Adversaire local :
  • malware, vol de terminal, analyse post-mortem ;
• Adversaire visuel :
  • capture d'écran, observation directe, caméra ;

12.2 Hypothèses de confiance

• moteur segmenté conforme au modèle public du brevet de référence ;
• navigateurs et OS raisonnablement à jour ;
• adversaire ne disposant pas simultanément et durablement de tous les segments requis.

12.3 Hors périmètre

• attaques matérielles sophistiquées de laboratoire ;
• compromission simultanée et durable de tous les segments sur tous les supports ;
• 0-day critiques permettant l'exfiltration instantanée de toute la mémoire sensible.

13. Générateur de nombres aléatoires

13.1 Source d'entropie

Le client DOIT utiliser :

• l'API CSPRNG du système / navigateur (ex : window.crypto.getRandomValues) ;
• ou un équivalent de robustesse comparable.

Le serveur, lorsqu'il génère des valeurs aléatoires non critiques pour les secrets applicatifs, DOIT utiliser une source CSPRNG appropriée.

13.2 Usage

Le RNG est utilisé pour :

• IV/nonce AES-GCM ;
• salts aléatoires ;
• identifiants techniques aléatoires lorsqu'ils ne sont pas dérivés.

14. Fonctions de hachage

CryptPeer utilise publiquement :

• SHA-256 pour :
  • hachage d'identifiants techniques ;
  • construction de certains salts déterministes publics ;
• SHA3-256 comme option publique de durcissement pour certains usages documentés.

Notation :

• H256(x) = SHA-256(x) ;
• H3_256(x) = SHA3-256(x).

15. Fonctions de dérivation de clés (KDF)

15.1 Principes généraux

• toute dérivation DOIT être déterministe pour un même jeu d’entrées ;
• les usages distincts DOIVENT être séparés par le champ info ou un label équivalent ;
• une même clé NE DOIT PAS être réutilisée directement pour plusieurs finalités applicatives différentes ;
• les dérivations publiques documentées n’exposent pas les détails internes de la KDF segmentée du moteur.

15.2 PBKDF2-HMAC-SHA-256

Paramètres publics par défaut :

• iter = 100000 ;
• L = 32 octets (256 bits).

Usage :

• dérivations publiques déterministes de base sur identifiants ou contextes non secrets ;
• construction de clés de base servant ensuite d’entrée à des dérivations ancrées sur K_seg.

15.3 HKDF-SHA-256

Appel :

HKDF_SHA256(salt, IKM, info, L) -> OKM

Usage :

• dérivation de K_conv, K_file, K_msg, K_view à partir de K_seg et de contextes applicatifs ;
• séparation cryptographique des usages par le champ info.

16. Chiffrement authentifié

16.1 AES-256-GCM

Paramètres publics :

• clé : 256 bits ;
• nonce/IV : 96 bits ;
• tag d'authentification : 128 bits.

L'IV DOIT être :

• soit généré aléatoirement pour chaque chiffrement ;
• soit dérivé de manière à garantir son unicité par clé.

Dans CryptPeer :

• les messages utilisent un IV unique par chiffrement ;
• les fichiers utilisent un IV unique par chiffrement ;
• les formats logiques publics sont décrits en Annexe D.

16.2 Données authentifiées associées

Lorsque des AAD sont utilisées, elles DEVRAIENT inclure des éléments non secrets de contexte, par exemple :

• version du format ;
• identifiant logique de conversation ou de fichier ;
• type de message ou de bloc ;
• mode d’usage applicable.

16.3 Échec de déchiffrement

En cas d’échec d’authentification GCM :

• le contenu DOIT être rejeté ;
• aucun plaintext partiel NE DOIT être exposé ;
• la tentative DOIT être traitée comme une erreur d’intégrité ou de contexte.

17. Rôle et positionnement du moteur segmenté

Le moteur de clé segmentée :

• gère K_pair, clé logique d'appairage ou d’autorisation segmentée ;
• n'expose pas directement K_pair en clair au client ;
• restitue à CryptPeer une clé racine locale K_seg via une API locale restreinte ;
• applique des politiques de segmentation (ordre, facteurs, limites de tentatives, contexte).

CryptPeer le considère comme une boîte noire présentant les propriétés de la section 20. Les détails d'implémentation internes relèvent du brevet international WO2018154258A1 de Freemindtronic et de documents techniques internes non publics.

Référence : Pour plus d'informations sur le brevet de référence implémenté dans CryptPeer, consultez la page Brevet Clé Segmentée.

18. Modèle fonctionnel public

18.1 Entités

• K_pair : clé logique d'appairage ou d’autorisation ;
• Segment : unité stockée sur un support, un facteur ou un contexte ;
• Policy : politique locale définissant les conditions d’obtention de K_seg ;
• K_seg : clé racine locale d’application fournie au client.

18.2 Propriétés publiques

Le moteur présente publiquement les propriétés suivantes :

• la clé logique d’origine est répartie en plusieurs segments ;
• les segments PEUVENT être portés par plusieurs supports ou facteurs ;
• la recomposition utile n’est que temporaire et en mémoire volatile ;
• l’application ne manipule pas directement le secret complet d’origine ;
• une racine locale d’application peut être fournie à un composant autorisé.

19. Interface fonctionnelle publique

Interface minimale exposée au client CryptPeer :

type RootContext = {
  mode: "standard" | "masque" | "defense";
  serverId: string;
  localId: string;
  categoryId?: string;
  deviceId?: string;
  appVersion?: string;
};

interface SegmentedKeyEngine {
  getRootKey(policyId: string, context: RootContext): Promise<ArrayBuffer>; // K_seg
  clear(): Promise<void>;
}

19.1 getRootKey

• entrée :
  • policyId : identifiant de la politique de segmentation à utiliser ;
  • context : contexte logique (instance, mode, appareil).
• sortie :
  • K_seg : chaîne d'octets de longueur au moins 32 octets.

Conditions :

• la recomposition de K_pair, si nécessaire, est effectuée en mémoire volatile ;
• K_seg n'est maintenue qu'en mémoire, pour une durée minimale.

19.2 clear

Efface :

• toute copie temporaire de K_seg ;
• tout matériel sensible temporaire lié à l’usage du moteur.

20. Propriétés de sécurité requises

Le moteur DOIT garantir au minimum :

1. Non-export de K_pair et des segments
   • aucun appel d'API ne permet de récupérer K_pair ou un segment brut exploitable.
2. Recomposition éphémère
   • K_pair, si recomposé, et K_seg ne résident qu'en mémoire volatile ;
   • effacement actif après usage.
3. Politique de segmentation
   • respect des policyId :
     • nombre et type de segments requis ;
     • ordre ;
     • limites de tentatives ;
     • contextes autorisés.
4. Liage au contexte d’usage
   • K_seg DOIT dépendre de :
     • K_pair ;
     • policyId ;
     • context ;
     • d’un libellé d’usage applicatif.
5. Résistance aux attaques locales raisonnables
   • extraction directe des segments ou de K_pair rendue difficile ;
   • protection contre la simple inspection du stockage logiciel.
6. Fail-closed logique
   • si la politique n’est pas satisfaite, K_seg NE DOIT PAS être restituée ;
   • aucun secret partiel exploitable NE DOIT être exposé à l’application.

21. Intégration avec les supports matériels

Le moteur PEUT intégrer :

• des HSM NFC ;
• des HSM PGP (PC) ;
• d'autres supports souverains.

CryptPeer n'impose pas un type particulier de support, mais exige que :

• les segments stockés sur ces supports soient non-exportables en clair ;
• l'utilisation du support s'intègre dans la politique de segmentation.

22. Vue d'ensemble

K_pair (segmentée, moteur)
   ↓  KDF_segmented(policyId, context, "CryptPeer-root")
K_seg
   ↓ PBKDF2/HKDF + contextes publics
K_conv, K_file, K_view
   ↓ HKDF + index/epoch/session
K_msg

Principes :

• séparation cryptographique des usages ;
• dérivation locale côté client ;
• absence d’exposition serveur des secrets structurants ;
• isolation des contextes conversation, fichier, affichage et session.

23. Clé racine locale d’application K_seg

Formellement :

K_seg = KDF_segmented(
  K_pair,
  label   = "CryptPeer-root",
  policyId,
  context // encodé de manière déterministe
)

Taille minimale : 256 bits.

K_seg n'est ni portée par le serveur relais ni exposée dans les protocoles réseau.

24. Clés de conversation

Les conversations utilisent des clés dérivées localement à partir de K_seg et de contextes applicatifs déterministes propres à chaque échange.

Exemple logique :

K_conv = HKDF_SHA256(
  salt = K_seg,
  IKM  = K_base,
  info = "CryptPeer/msg/v2",
  L    = 32
)

Cette séparation garantit qu’un contexte conversationnel n’utilise pas directement la même clé de travail qu’un autre contexte.

25. Clés de fichiers et d’exports

Les fichiers, pièces jointes, exports et sauvegardes utilisent des dérivations distinctes, séparées logiquement des clés de conversation.

K_file = HKDF_SHA256(
  salt = K_seg,
  IKM  = K_file_base,
  info = "CryptPeer/file/v2",
  L    = 32
)

26. Clés éphémères de message ou de session

Des clés éphémères peuvent être dérivées localement pour réduire la portée d’exposition d’un message, d’une session ou d’un affichage temporaire.

K_msg = HKDF_SHA256(
  salt = epochOrSessionContext,
  IKM  = K_conv_seed,
  info = "CryptPeer/msg/epoch",
  L    = 32
)

Cette approche contribue à limiter la fenêtre de compromission utile en cas d’accès local transitoire.

27. Chiffrement des messages

Les messages DOIVENT être chiffrés côté client avant transmission :

1. dérivation locale de la clé de conversation ;
2. dérivation éventuelle d'une clé éphémère K_msg ;
3. génération d’un IV unique ;
4. chiffrement AES-256-GCM du contenu ;
5. transmission du message protégé au serveur relais.

Le serveur S stocke uniquement le blob chiffré, sans possibilité de déchiffrement.

28. Conversations de groupe

Pour un groupe :

1. une clé de conversation de groupe est dérivée localement ;
2. la gestion des participants reste pilotée par les autorisations applicatives ;
3. le chiffrement des contenus suit les mêmes principes que la messagerie 1:1 ;
4. le serveur relaie le message chiffré à tous les membres autorisés.

Les clés de groupe ne sont jamais partagées en clair : chaque participant dérive localement sa clé de travail.

29. Transfert de fichiers et pièces jointes

Pour un fichier :

1. dérivation locale d’une clé K_file ;
2. génération d’un salt et d’un IV adaptés ;
3. chiffrement AES-256-GCM du fichier et, selon la configuration, des métadonnées associées ;
4. stockage du blob protégé sur S ou sur un support de sauvegarde.

Les pièces jointes suivent le même principe de séparation des contextes de dérivation.

30. Sauvegardes chiffrées

La stratégie de sauvegarde chiffrée consiste à :

• multiplier les copies ;
• diversifier les supports ;
• préserver une copie hors site si nécessaire.

Implémentation CryptPeer :

1. les backups utilisent une clé dérivée localement fondée sur K_seg ;
2. les supports reçoivent uniquement des archives déjà chiffrées ;
3. la restauration nécessite l’accès légitime à K_seg via le moteur segmenté.

Aucun secret en clair n'est stocké dans les backups.

31. Appels audio/vidéo et partage d'écran

Pour les communications temps réel :

1. l’établissement de session s’appuie sur des échanges applicatifs protégés ;
2. des clés de session sont dérivées côté client ;
3. les flux média sont chiffrés avant transit ;
4. le serveur agit comme relais ou point de coordination sans accès aux secrets de contenu.

32. Objectifs de sécurité

CryptPeer vise à garantir :

1. Confidentialité de bout en bout :
   • les messages et fichiers ne sont jamais en clair sur le serveur ;
   • seuls les participants légitimes peuvent déchiffrer le contenu.
2. Intégrité :
   • détection de toute modification des messages ou fichiers ;
   • authentification cryptographique intégrée aux schémas utilisés.
3. Authentification locale forte :
   • usage d’une racine locale issue d’un système à clé segmentée ;
   • réduction de l’exposition directe des secrets structurants.
4. Disponibilité souveraine :
   • fonctionnement possible en mode local-only ;
   • maîtrise locale de l’infrastructure et des sauvegardes.

33. Confidentialité et intégrité

33.1 Confidentialité

La confidentialité est assurée par :

• Chiffrement E2E : toutes les données applicatives sont chiffrées avec AES-256-GCM avant transmission.
• Ancrage sur K_seg : les clés de chiffrement dépendent de K_seg, non accessible au serveur.
• Séparation des usages : conversation, fichier, affichage et session utilisent des contextes de dérivation distincts.
• Réduction des métadonnées exploitables selon la configuration retenue.

33.2 Intégrité

L'intégrité est garantie par :

• Tag d'authentification GCM : chaque message ou fichier inclut un tag vérifiant l’intégrité et l’authenticité du ciphertext.
• Détection des modifications : toute altération du ciphertext ou du tag est détectée lors du déchiffrement.
• Unicité des contextes de chiffrement : l'unicité des IV/nonces et la séparation des dérivations empêchent la réutilisation triviale des contextes cryptographiques.

34. Résilience à la compromission serveur

En cas de compromission totale du serveur S :

1. le serveur ne détient que des blobs chiffrés, non déchiffrables sans K_seg ;
2. il ne porte pas la racine locale d’application ;
3. des métadonnées techniques peuvent être exposées, mais pas les secrets de contenu ;
4. la restauration sur une nouvelle infrastructure reste possible à partir de sauvegardes protégées.

La compromission de S peut toutefois permettre :

• l’analyse de trafic ;
• l’interception de nouveaux messages protégés ;
• des attaques de disponibilité.

35. Résilience à la compromission locale

En cas de compromission du terminal client :

1. Protection par segmentation :
   • K_pair reste segmentée et non exposée directement ;
   • l'accès à K_seg nécessite la satisfaction de la politique retenue ;
   • les segments matériels ne sont pas assimilables à un secret logiciel unique en clair.
2. Effacement mémoire :
   • K_seg n'est maintenue en mémoire que temporairement ;
   • effacement actif après usage ou inactivité.
3. Clés éphémères :
   • les clés de message ou de session PEUVENT être renouvelées ;
   • la portée temporelle d’exposition est ainsi réduite.
4. Mode Masqué :
   • réduit l’exposition visuelle locale ;
   • re-protège rapidement les contenus affichés.

36. Considérations de résilience quantique (symétrique)

L’architecture publique de CryptPeer repose principalement sur des briques symétriques de niveau 256 bits et sur une racine locale non exposée sur le réseau.

Dans cette perspective :

• l’absence d’exposition distante des secrets structurants réduit la valeur d’un archivage réseau seul ;
• les primitives symétriques retenues offrent une marge de sécurité élevée à long terme ;
• la séparation entre le serveur et K_seg demeure un élément central du modèle.

Cette section n’énonce pas de garantie post-quantique complète ; elle décrit uniquement la robustesse attendue des briques symétriques publiquement utilisées dans ce modèle.

37. Protection des données

CryptPeer est conçu selon une logique de minimisation des données : chiffrement de bout en bout, contrôle local des secrets et limitation des dépendances à des services tiers.

Cette approche soutient les principes de protection des données personnelles dans les juridictions applicables, sous réserve des politiques opérationnelles et du cadre de déploiement retenu.

38. NIS2 et maîtrise de l’infrastructure

L’auto-hébergement, la maîtrise locale des secrets et la réduction des dépendances externes renforcent la souveraineté opérationnelle et la résilience de l’infrastructure.

39. Export de cryptographie

Les primitives mentionnées dans cette version publique relèvent de standards internationaux largement connus. Toute analyse réglementaire détaillée dépend du périmètre exact de distribution et des juridictions concernées.

40. Implémentation côté client web

Le client web est implémenté en JavaScript/TypeScript avec WebAssembly pour les opérations cryptographiques critiques :

1. Architecture :
   • code JS/TS servi par le serveur S ;
   • exécution dans le navigateur ;
   • WASM pour AES-256-GCM, HKDF et PBKDF2 lorsque pertinent.
2. Gestion des clés :
   • interface avec le moteur segmenté via API locale ;
   • dérivation de toutes les clés applicatives à partir de K_seg ;
   • stockage mémoire volatile uniquement, effacement actif.
3. Sécurité navigateur :
   • Content Security Policy stricte ;
   • réduction de la surface d’attaque liée aux scripts ;
   • contrôle des ressources servies.
4. Mises à jour :
   • déploiement centralisé via S ;
   • homogénéité des versions clientes à chaque chargement.

41. Implémentation côté serveur relais

Le serveur S agit comme un relais aveugle :

1. Fonctions :
   • servir le bundle client web ;
   • authentifier les connexions ;
   • stocker et relayer des blobs chiffrés ;
   • gérer l'annuaire et les catégories selon la configuration.
2. Stockage :
   • base de données pour messages, fichiers et métadonnées protégées ;
   • backups réguliers de la base protégée.
3. Sécurité :
   • durcissement OS ;
   • TLS pour le transport HTTP(S) ;
   • authentification des connexions client.

Le serveur ne doit jamais détenir de clé de déchiffrement applicative.

42. Durcissement logiciel et matériel

42.1 Durcissement logiciel

• OS :
  • chiffrement de disque lorsque pertinent ;
  • mises à jour de sécurité régulières ;
  • configuration minimale.
• Navigateur :
  • version récente et à jour ;
  • extensions limitées ;
  • isolation des processus lorsque disponible.
• Réseau :
  • pare-feu correctement configuré ;
  • restriction des accès ;
  • VPN ou cloisonnement réseau selon le contexte.

42.2 Durcissement matériel

• Segments matériels :
  • HSM NFC, HSM PGP, ou équivalents ;
  • protection physique contre l'extraction.
• Terminal :
  • contrôle d'accès physique ;
  • sécurisation du poste ;
  • mesures anti-altération selon le niveau de sensibilité.

43. Journalisation minimale

Principe : minimiser les traces exploitables tout en conservant les logs nécessaires à l'exploitation :

1. Logs serveur :
   • logs techniques sans données déchiffrées ni secrets ;
   • métadonnées minimales ;
   • pas de logs de contenu en clair.
2. Logs client :
   • pas de logs de clés ni de contenu déchiffré ;
   • logs d'erreurs techniques uniquement ;
   • rotation ou effacement rapide selon la configuration.
3. Rétention :
   • durée de rétention limitée ;
   • effacement automatique après expiration quand applicable.