Spécifications cryptographiques de CryptPeer
Système de messagerie et d'authentification à clé segmentée

1. À propos de ce document

Ce document spécifie les aspects cryptographiques et de sécurité de CryptPeer, plateforme collaborative de communications privées chiffrées de bout en bout, reposant sur un système d'authentification à clé segmentée.

Objectifs :

• décrire de manière normative :
  • les primitives cryptographiques utilisées ;
  • la hiérarchie de clés et les KDF ;
  • les protocoles applicatifs (messagerie, fichiers, backups, modes Masqué / Defense) ;
• formaliser le rôle du moteur d'authentification à clé segmentée comme racine de tous les secrets applicatifs ;
• fournir une base pour :
  • l'implémentation de référence ;
  • les audits cryptographiques indépendants ;
  • d'éventuelles évaluations réglementaires (type CSPN ou équivalentes).

Le public visé est technique : développeurs, architectes sécurité, cryptographes, auditeurs. Ce document est normatif pour les composants de référence de CryptPeer. Toute divergence doit être explicitement documentée.

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 (dont audio/vidéo) ;
• enregistrements audio/vidéo capturés localement puis envoyés chiffrés ;
• appels audio/vidéo et visio-conférence, y compris partage d'écran, dans un environnement auto-hébergé ;
• backup chiffré 3-2-1 sur plusieurs supports (USB, SSD, NAS, cloud, etc.) ;
• chiffrement / déchiffrement autonome de fichiers ;
• export / import de fils de discussion (JSON brut, mode discussion, restauration) ;
• modes de fonctionnement :
  • CryptPeer (standard),
  • CryptPeer Masqué,
  • CryptPeer Defense ;
• moteur d'authentification à clé segmentée et son API (K_pair, K_seg) ;
• hiérarchie de clés :
  • K_seg, K_base, K_conv_v2, K_file_v2, K_msg, K_view, K_tunnel_def ;
• mécanismes de PFS locale (clé unique par message ou par epoch) ;
• chiffrement des bases/métadonnées côté serveur (de manière abstraite) ;
• topologies :
  • serveur relais autonome auto-hébergé,
  • mode local-only,
  • accès distant via NAT / reverse proxy,
  • liste de serveurs favoris côté client.

2.2 Hors périmètre

Ne sont pas couverts, sauf mention explicite :

• aspects purement ergonomiques (UI, flux UX) ;
• durcissement OS détaillé (chiffrement de disque, MDM, politiques système) ;
• procédures organisationnelles (RH, contrôle d'accès physique, etc.) ;
• analyses de conformité complètes (AIPD RGPD, politique NIS2 détaillée) ;
• les mécanismes cryptographiques internes de gestion de licence (EviEngine), décrits uniquement au niveau architectural, sans détailler leur implémentation cryptographique.

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é en big-endian sur une taille fixée (généralement 64 bits) lorsqu'il est inclus dans les entrées de KDF.

3.2 Opérations

• Concaténation : X || Y.
• Hachage : H(x) (fonction précisée en Partie III).
• PBKDF2 : PBKDF2_HMAC_SHA256(P, salt, iter, L) → sortie de longueur L octets.
• HKDF : HKDF_SHA256(salt, IKM, info, L) / HKDF_SHA3_256(...).
• Encodage d'un entier 64 bits : encodeUint64(n).

3.3 Notation des clés

• K_pair : clé d'appairage segmentée, gérée par le moteur de clé segmentée, non manipulée en clair par CryptPeer.
• K_seg : clé racine locale exposée à CryptPeer par le moteur.
• K_base : clé de base d'une conversation (v1).
• K_conv_v2 : clé de conversation v2.
• K_file_base, K_file_v2 : clés associées au chiffrement de fichiers / exports.
• K_msg : clé éphémère associée à un message ou une epoch.
• K_view : clé utilisée pour le déchiffrement temporaire à l'affichage (mode Masqué).
• K_tunnel_def : clés de tunnel en mode Defense.

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

4. Référentiels et principes de conception

CryptPeer s'appuie sur :

• des primitives symétriques standards (AES-256-GCM, SHA-256 / SHA-3) ;
• des KDF standardisés (PBKDF2, HKDF) ;
• le système d'authentification à clé segmentée breveté (WO2018154258A1), modélisé comme un composant fournissant :
  • une API restreinte,
  • des garanties de non-export et de volatilité.

La conception respecte les principes :

• robustesse symétrique 256 bits ;
• séparation claire des rôles :
  • moteur segmenté,
  • client,
  • serveur relais aveugle ;
• minimisation des métadonnées et des traces.

5. Architecture globale de CryptPeer

5.1 Composants

Une instance CryptPeer comprend :

• un serveur relais S :
  • auto-hébergé (local, on-premise, NAS, VPS sous contrôle) ;
  • stockant uniquement des contenus/métadonnées déjà chiffré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 ;
• un annuaire local structurant les utilisateurs en catégories.

Une instance CryptPeer ne participe à aucune fédération. Les messages ne transitent jamais par d'autres serveurs CryptPeer.

5.2 Rôles

• Client :
  • dérive toutes les clés applicatives à partir de K_seg et de données publiques ;
  • effectue tout chiffrement/déchiffrement ;
  • gère l'affichage (mode normal, Masqué, Defense).
• Moteur de clé segmentée :
  • gère K_pair et ses segments ;
  • restitue éphémèrement K_seg selon une politique.
• Serveur relais S :
  • sert le client web ;
  • authentifie les connexions (sans jamais manipuler de clair) ;
  • stocke et relaie des blocs chiffrés.
• Supports de sauvegarde :
  • reçoivent des backups chiffrés (aucun secret en clair).

5.3 Gestion de licence matérielle (EviEngine)

CryptPeer intègre la technologie EviEngine de Freemindtronic pour la gestion des licences sans serveur ni base de données. Ce composant ne fait pas partie du chemin de chiffrement des messages ou des fichiers, mais il est structurant pour le modèle de souveraineté, d'anonymat et d'autonomie de la plateforme.

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

• Licence liée au matériel :
  • la licence est associée à des caractéristiques matérielles de la machine (par exemple, numéro de série de carte mère) ;
  • elle n'est pas liée à l'identité civile de l'utilisateur.
• Sans serveur ni base de données de licence :
  • aucun serveur de licence externe n'est interrogé pour valider l'usage de CryptPeer ;
  • aucune base de données centralisée de licences n'est nécessaire ;
  • la vérification de la licence est réalisée localement, sur l'instance, via EviEngine.
• Fonctionnement hors ligne :
  • la validation de licence fonctionne en mode local-only, sans connexion Internet ;
  • la continuité de service ne dépend pas d'un tiers de licence distant.
• Anonymat préservé :
  • la licence étant liée au matériel et non à une identité nominative, aucun compte utilisateur centralisé n'est requis ;
  • aucune télémétrie de licence vers un cloud tiers n'est nécessaire.

D'un point de vue cryptographique, la gestion de licence via EviEngine est orthogonale à la sécurité des contenus (messages, fichiers, backups). Les primitives, la hiérarchie de clés et les protocoles décrits dans les Parties III à VII restent inchangés, que la licence soit présente ou non. En revanche, du point de vue de la doctrine « Zero Trust. Zero Cloud. Zero Trace. », ce modèle de licence :

• élimine les risques liés aux serveurs de licence (exfiltration, indisponibilité, traçage des usages) ;
• évite la constitution d'une base de données centralisée d'identifiants de clients ;
• permet à une instance CryptPeer de fonctionner de manière souveraine, y compris sur des réseaux totalement fermés.

Les détails cryptographiques internes d'EviEngine (formats de licence, algorithmes exacts pour le liage matériel, etc.) ne relèvent pas du présent document. Ils peuvent faire l'objet d'une spécification séparée et d'un audit spécifique centré sur la chaîne de licence.

6. Modes de déploiement

6.1 Mode local-only

En mode local-only :

• S n'est accessible que sur un réseau local (LAN, Wi-Fi privé, AP dédié) ;
• aucune visibilité directe depuis Internet ;
• toutes les communications restent dans la bulle réseau locale.

Ce mode est privilégié pour les environnements :

• régaliens, militaires, diplomatiques ;
• sites sensibles ;
• réseaux air-gap avec synchronisation physique.

6.2 Mode avec accès distant

En mode distant :

• S est derrière un routeur/pare-feu ;
• un reverse proxy/NAT expose un nom de domaine ou sous-domaine ;
• TLS est utilisé pour sécuriser le transport HTTP(S).

Le contenu applicatif est chiffré de bout en bout : TLS protège la couche transport, AES-256-GCM (avec clés dérivées de K_seg) protège les données applicatives.

6.3 Auto-portabilité

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

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

L'instance est auto-portée : le code serveur + la base chiffrée peuvent être déplacés physiquement, sous réserve de protéger les secrets de déploiement (identifiants admin, éventuelles clés de chiffrement de la base ou de l'OS).

7. Client web universel

7.1 Principe

CryptPeer fournit un client unique :

• implémenté en JS/TS/WASM ;
• exécuté dans un navigateur moderne (desktop, mobile, TV, média) ;
• aucune application native spécifique n'est fournie.

7.2 Conséquences

• une seule base de code cliente à auditer et durcir ;
• mises à jour centralisées via S :
  • dès qu'un nouveau bundle est servi, tous les clients l'utilisent au prochain chargement ;
• absence de versions obsolètes installées sur les terminaux.

Les risques spécifiques au navigateur (extensions, 0-day) sont pris en compte dans le modèle de menace (section 12).

8. Modes de fonctionnement

8.1 Mode CryptPeer (standard)

Fonctionnalités :

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

Propriétés cryptographiques :

• E2E basé sur K_seg ;
• PFS locale via K_msg ;
• aucune clé de contenu sur le serveur.

8.2 Mode CryptPeer Masqué

Objectif : réduire l'exposition visuelle.

Caractéristiques :

• affichage chiffré par défaut ;
• déchiffrement explicite d'une conversation ;
• re-chiffrement automatique de la vue :
  • au bout d'un délai ;
  • ou sur évènement (changement d'onglet, perte de focus, etc.) ;
• effacement en mémoire des buffers de clair après re-chiffrement.

Utilise une clé de vue K_view dérivée de K_seg.

8.3 Mode CryptPeer Defense

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

Caractéristiques :

• instance de serveur et moteur dédiés ;
• tunnel chiffré avec clés segmentées et éphémères (K_tunnel_def) ;
• politique RAM-only :
  • pas de logs persistants ;
  • pas de métadonnées durables exploitables ;
  • auto-purge agressive de la mémoire ;
• historique réduit voire absent selon configuration.
• Aucun stockage : chiffrement tunnelisé avec transfert direct de messages et fichiers chiffrés sans stockage sur le serveur relais.

Le mode Defense privilégie l'absence de trace à la capacité d'historisation.

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

Il n'y a :

• ni routage inter-serveurs ;
• ni fédération ;
• ni annuaire global.

Conséquences :

• chaque instance S est une bulle totalement indépendante ;
• la cartographie globale des communications est difficile à établir pour un adversaire externe.

10. Annuaire, catégories et cloisonnement logique

10.1 Annuaire local

Chaque instance S maintient un annuaire :

• ensemble d'utilisateurs U ;
• identifiants, informations de contact (pseudonymes, éventuellement attributs) ;
• informations nécessaires à l'authentification, stockées chiffrées.

10.2 Catégories de contacts

L'administrateur associe chaque utilisateur u à une ou plusieurs catégories :

C = { C_1, C_2, … }  avec  C_i ⊆ U

Règles :

• l'appartenance à une catégorie est décidée par l'admin ;
• un utilisateur ne peut pas s'auto-affecter.

10.3 Groupes et cloisonnement

Un groupe de discussion G est défini comme :

G = (groupId, C_i, Members)

avec Members ⊆ C_i

Par défaut :

• les groupes ne mélangent pas directement plusieurs catégories ;
• un utilisateur ne peut inviter que des membres de ses catégories autorisées.

Ce cloisonnement limite la propagation latérale d'une compromission de compte et les risques d'espionnage 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 fiable par construction ;
• S ne détient aucune clé de déchiffrement ;
• S ne dérive jamais de clé à partir des identifiants :
  • toutes les dérivations sont 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 (NAS, cloud) 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 ;
• journaux minimaux côté serveur :
  • et inexistants en mode Defense.

Les modes Masqué et Defense renforcent cette doctrine sur la dimension visuelle et sur les traces mémoire.

12. Modèle de menace et hypothèses

12.1 Adversaires pris en compte

• Adversaire serveur :
  • contrôle total de S (root, DB, code servi) ;
• Adversaire réseau :
  • interception, MITM, observation massive ;
• Adversaire local :
  • malware, vol de terminal, forensique post-mortem ;
• Adversaire visuel :
  • capture d'écran, observation directe, caméra espionne ;
• Adversaire organisationnel :
  • création de comptes non autorisés, mauvais paramétrage de catégories.

12.2 Hypothèses de confiance

• moteur segmenté conforme à la Partie IV ;
• navigateurs et OS raisonnablement à jour ;
• adversaire ne disposant pas simultanément et durablement de tous les segments de K_pair.

12.3 Hors périmètre

• attaques matérielles sophistiquées (TEMPEST, side-channels profonds) ;
• compromission simultanée et durable de tous les segments sur tous les supports ;
• 0-day critiques non corrigés 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 côté secret de contenu), DOIT utiliser une source CSPRNG appropriée.

13.2 Usage

Le RNG est utilisé pour :

• IV/nonce AES-GCM ;
• salts aléatoires (fichiers v2, certains backups) ;
• identifiants aléatoires (groupId, etc.) lorsqu'ils ne sont pas dérivés.

14. Fonctions de hachage

CryptPeer utilise par défaut :

• SHA-256 pour :
  • hachage d'identifiants,
  • dérivation de salts déterministes v1 ;
• optionnellement SHA3-256 pour certaines dérivations renforcées.

Notation :

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

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

15.1 PBKDF2-HMAC-SHA-256

Paramètres par défaut :

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

Usage :

• dérivation de K_base à partir de keyMaterial_ids ;
• dérivation de K_file_base à partir de userId.

15.2 HKDF

Deux variantes :

• HKDF_SHA256 (par défaut) ;
• HKDF_SHA3_256 (option de durcissement).

Appel :

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

Usage :

• dérivation de K_conv_v2, K_file_v2, K_msg, K_view, K_tunnel_def à partir de K_base, K_file_base et K_seg.

16. Chiffrement authentifié

16.1 AES-256-GCM

Paramètres :

• 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é d'un compteur unique par clé, de manière à assurer l'unicité.

Dans CryptPeer :

• pour les messages : IV aléatoire 96 bits ;
• pour les fichiers : IV aléatoire 96 bits ;
• le formalisme de stockage est décrit en Annexe D.

17. Rôle et positionnement du moteur segmenté

Le moteur de clé segmentée :

• gère K_pair, clé d'appairage segmentée ;
• ne l'expose jamais en clair ;
• restitue à CryptPeer des clés racines K_seg via une API locale ;
• applique des politiques de segmentation (ordre des segments, 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 (système d'authentification à clé segmentée) 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 de données abstrait

18.1 Entités

• K_pair : clé d'appairage logique ;
• Segment : unité stockée sur un support / facteur :
  • segment matériel (NFC, HSM, etc.) ;
  • segment logiciel (secret local chiffré) ;
  • segment cognitif (PIN, phrase) ;
  • segment contextuel (présence d'un device, d'un réseau) ;
• Policy :
  • policyId ;
  • liste ordonnée de segments requis ;
  • paramètres (limites de tentatives, expire, contexte).

18.2 Contexte

Le moteur prend en compte un contexte abstrait :

RootContext = {
  mode: "standard" | "masque" | "defense",
  serverId: string,      // identifiant cryptographique de l'instance S
  localId: string,       // identifiant logique de l'instance (URL, label)
  categoryId?: string,   // optionnel : catégorie de contacts
  deviceId?: string,     // identifiant du terminal
  appVersion?: string    // version du client CryptPeer
}

Ce contexte est incorporé dans la dérivation de K_seg.

19. Interface fonctionnelle

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 de K_seg ;
• tout matériel sensible temporaire lié à la recomposition dans la mémoire 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.
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
   • K_seg est une fonction de :
     • K_pair ;
     • policyId ;
     • context ;
     • label (usage, ex : "CryptPeer-root").
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.

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 ne requiert 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 + IDs publics
K_base, K_file_base
   ↓ HKDF + K_seg
K_conv_v2, K_file_v2
   ↓ HKDF + index/epoch
K_msg

Plus :

• K_view dérivée de K_seg pour le mode Masqué ;
• K_tunnel_def dérivée de K_seg pour le mode Defense.

23. Clé racine locale K_seg

Formellement :

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

Taille minimale : 256 bits.

24. Clés de base de conversation K_base

24.1 Conversations 1:1

Soient userId_A, userId_B, conversationId.

On définit :

ids_sorted      = sortLex(userId_A, userId_B)
keyMaterial_ids = ids_sorted[0] || ":" || ids_sorted[1] || ":" || conversationId

salt_v1 = H256("CryptPeer/salt/v1" || keyMaterial_ids)

K_base = PBKDF2_HMAC_SHA256(
  P    = keyMaterial_ids,
  salt = salt_v1,
  iter = 100000,
  L    = 32
)

24.2 Groupes

Pour un groupe groupId :

keyMaterial_ids = "group:" || groupId

salt_v1 = H256("CryptPeer/salt/v1" || keyMaterial_ids)

K_base = PBKDF2_HMAC_SHA256(
  P    = keyMaterial_ids,
  salt = salt_v1,
  iter = 100000,
  L    = 32
)

K_base reste dérivable par le serveur en v1 ; en v2, le contenu est protégé par l'ancrage sur K_seg.

25. Clés de conversation v2 : K_conv_v2

Pour chaque conversation (1:1 ou groupe) :

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

Propriétés :

• dépend simultanément de :
  • la structure d'identifiants (K_base) ;
  • la racine locale K_seg ;
• non dérivable par le serveur.

26. Clés fichiers v2 : K_file_v2

26.1 Clé de base fichiers par utilisateur

salt_file_v1 = H256("CryptPeer/file/salt/v1" || userId)

K_file_base = PBKDF2_HMAC_SHA256(
  P    = userId,
  salt = salt_file_v1,
  iter = 100000,
  L    = 32
)

26.2 Clé fichiers v2

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

Pour chaque fichier, un salt aléatoire et un IV aléatoire sont utilisés au niveau AES-GCM. On peut optionnellement dériver une clé par fichier en incluant un identifiant de fichier dans info.

27. Clés éphémères de message : K_msg

27.1 Clé seed de conversation

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

27.2 Clé par message ou epoch

Soit epochId, typiquement un entier 64 bits (index de message, ou fenêtre de temps).

K_msg = HKDF_SHA256(
  salt = encodeUint64(epochId),
  IKM  = K_conv_v2_seed,
  info = "CryptPeer/msg/epoch",
  L    = 32
)

Chaque message est chiffré avec un K_msg distinct ; l'effacement des clés précédentes fournit une PFS locale.

28. Clés de vue K_view (mode Masqué)

Pour une session d'affichage donnée, identifiée par viewSessionId (aléatoire) :

K_view = HKDF_SHA256(
  salt = viewSessionId,
  IKM  = K_seg,
  info = "CryptPeer/view/v1",
  L    = 32
)

Usage : chiffrer/déchiffrer temporairement les buffers d'affichage de la conversation. K_view est invalidée dès que la vue est re-chiffrée.

29. Clés de tunnel K_tunnel_def (mode Defense)

En mode Defense, un canal tunnel est établi entre client et S :

• K_tunnel_seed dérivée de K_seg :

K_tunnel_seed = HKDF_SHA256(
  salt = H256("CryptPeer/defense/serverId:" || serverId),
  IKM  = K_seg,
  info = "CryptPeer/defense/seed/v1",
  L    = 32
)

• pour chaque epoch réseau netEpoch :

K_tunnel_def = HKDF_SHA256(
  salt = encodeUint64(netEpoch),
  IKM  = K_tunnel_seed,
  info = "CryptPeer/defense/tunnel/v1",
  L    = 32
)

Ces clés ne sont jamais persistées ; le serveur Defense ne conserve pas d'état durable.

30. Migration v1 → v2

Les messages ou fichiers v1 peuvent être :

• reconnus par un champ de version ;
• déchiffrés avec les clés v1 dérivées sans K_seg ;
• éventuellement re-chiffrés en v2.

La cohabitation v1/v2 doit être strictement encadrée dans le temps. À terme, la dérivation sans K_seg est désactivée.

31. Chiffrement des messages 1:1

Pour une conversation 1:1 entre userId_A et userId_B :

1. Dérivation de K_conv_v2 : selon la section 25, à partir de K_base et K_seg.
2. Dérivation de K_msg : selon la section 27, pour chaque message ou epoch.
3. Chiffrement :
   • IV aléatoire 96 bits généré via CSPRNG ;
   • chiffrement AES-256-GCM avec K_msg ;
   • format : IV || ciphertext || tag.
4. Envoi : le message chiffré est envoyé au serveur relais S avec les métadonnées minimales (conversationId, timestamp, version).

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

32. Conversations de groupe

Pour un groupe groupId :

1. Clé de groupe : K_base est dérivée selon la section 24.2, puis K_conv_v2 selon la section 25.
2. Gestion des participants :
   • ajout/retrait de participants : le créateur ou administrateur du groupe peut modifier la liste ;
   • départ volontaire : tout participant peut quitter le groupe ;
   • départ du créateur/admin : un nouveau administrateur doit être désigné parmi les participants restants.
3. Chiffrement : identique à la section 31, avec K_conv_v2 et K_msg dérivés du groupId.
4. Distribution : le serveur S relaie le message chiffré à tous les membres du groupe actifs.

Les clés de groupe ne sont jamais partagées en clair : chaque participant dérive K_conv_v2 localement à partir de K_seg et du groupId.

33. Transfert de fichiers et pièces jointes

Pour un fichier associé à un utilisateur userId :

1. Dérivation de K_file_v2 : selon la section 26, à partir de K_file_base et K_seg.
2. Chiffrement :
   • salt aléatoire 256 bits généré via CSPRNG ;
   • IV aléatoire 96 bits par fichier ;
   • chiffrement AES-256-GCM avec K_file_v2 ;
   • format : salt || IV || ciphertext || tag.
3. Métadonnées : nom de fichier, taille, type MIME peuvent être chiffrés séparément ou inclus dans le blob.
4. Stockage : le fichier chiffré est stocké sur S ou sur un support de backup (section 34).

Pour les pièces jointes dans les messages, le fichier est chiffré avec K_file_v2 et une référence est incluse dans le message chiffré.

34. Backups chiffrés 3-2-1

La stratégie de backup 3-2-1 consiste à :

• 3 copies des données ;
• 2 supports différents ;
• 1 copie hors site.

Implémentation CryptPeer :

1. Chiffrement : les backups utilisent K_file_v2 selon la section 26, avec un salt unique par backup.
2. Supports :
   • USB, SSD externe (local) ;
   • NAS (réseau local) ;
   • cloud (optionnel, données préalablement chiffrées).
3. Format : archive chiffrée contenant :
   • métadonnées de structure (chiffrées) ;
   • messages, fichiers, annuaire (tous chiffrés) ;
   • manifest de vérification.
4. Restauration : nécessite K_seg pour dériver toutes les clés de déchiffrement.

Aucun secret en clair n'est stocké dans les backups : seule la possession de K_seg (via le moteur segmenté) permet la restauration.

35. Exports / imports JSON de discussions

L'export permet de sauvegarder une conversation dans un format JSON portable :

1. Format d'export :
   • métadonnées de conversation (conversationId, participants, dates) ;
   • messages chiffrés (IV, ciphertext, tag) ;
   • fichiers joints (références chiffrées) ;
   • version du format, paramètres cryptographiques utilisés.
2. Chiffrement de l'export : l'archive JSON complète peut être chiffrée avec K_file_v2 pour protection supplémentaire.
3. Import :
   • vérification de l'intégrité et de l'authenticité ;
   • déchiffrement avec K_conv_v2 et K_msg dérivés localement ;
   • restauration dans une nouvelle instance ou conversation.

L'import nécessite que l'instance de destination partage le même K_seg (même moteur segmenté) ou que les clés soient migrées selon la section 30.

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

Pour les communications temps réel :

1. Établissement de session :
   • négociation via messages chiffrés (WebRTC ou protocole propriétaire) ;
   • clés de session dérivées de K_conv_v2 avec un nonce unique par session.
2. Chiffrement du flux média :
   • chiffrement SRTP ou équivalent avec clés dérivées de la session ;
   • IV/nonce unique par paquet ;
   • authentification de chaque paquet.
3. Partage d'écran :
   • capture d'écran chiffrée frame par frame ;
   • compression optionnelle avant chiffrement ;
   • transmission via le même canal chiffré.
4. Enregistrement : si activé, les flux sont enregistrés localement avec K_file_v2 selon la section 33.

Le serveur S relaie uniquement les paquets chiffrés, sans déchiffrement ni inspection du contenu média.

37. Mise en œuvre pratique de la PFS locale

La Perfect Forward Secrecy locale est assurée par :

1. Dérivation de K_msg par message : selon la section 27, chaque message utilise un K_msg unique dérivé de K_conv_v2_seed et d'un epochId.
2. Effacement des clés :
   • après déchiffrement d'un message, K_msg est effacé de la mémoire ;
   • les clés d'epochs antérieures ne sont pas conservées.
3. Gestion des epochs :
   • epoch = index de message ou fenêtre temporelle ;
   • changement d'epoch : dérivation d'un nouveau K_msg ;
   • les anciens K_msg ne peuvent pas être recalculés sans K_conv_v2_seed.
4. Protection mémoire :
   • effacement sécurisé des buffers contenant les clés ;
   • pas de swap/paging des zones mémoire sensibles (si possible) ;
   • purge automatique après inactivité.

En cas de compromission locale, seuls les messages de l'epoch courante sont exposés. Les messages antérieurs restent protégés car leurs K_msg ont été effacés.

38. 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 ;
   • le serveur relais ne peut pas accéder aux clés de déchiffrement.
2. Intégrité :
   • détection de toute modification des messages ou fichiers ;
   • authentification de l'origine des messages ;
   • protection contre les attaques de type man-in-the-middle.
3. Authentification :
   • vérification de l'identité des participants ;
   • protection contre les usurpations d'identité ;
   • intégrité de l'annuaire et des catégories.
4. Disponibilité :
   • fonctionnement en mode local-only (sans dépendance Internet) ;
   • résilience aux pannes serveur (backups, redondance) ;
   • auto-hébergement pour contrôle total de l'infrastructure.
5. Non-répudiation (optionnel selon contexte) :
   • preuves cryptographiques de l'origine des messages ;
   • traçabilité pour usages régaliens (si configuré).

39. Propriétés de confidentialité et d'intégrité

39.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.
• PFS locale : chaque message utilise une clé éphémère K_msg distincte (section 37).
• Absence de métadonnées exploitables : le serveur ne peut pas dériver de clés à partir des identifiants publics.

39.2 Intégrité

L'intégrité est garantie par :

• Tag d'authentification GCM : chaque message/fichier inclut un tag de 128 bits vérifiant l'intégrité et l'authenticité.
• Protection contre la modification : toute altération du ciphertext ou du tag est détectée lors du déchiffrement.
• Protection contre la relecture : l'unicité des IV/nonce empêche la réutilisation de messages chiffrés.
• Vérification de l'origine : seuls les participants possédant K_seg peuvent générer des messages valides.

40. Propriétés Zero Trust / Zero Cloud / Zero Trace

40.1 Zero Trust

Le serveur S est considéré comme non fiable :

• aucune clé de déchiffrement n'est stockée sur S ;
• S ne peut pas dériver de clés à partir des identifiants ;
• toutes les dérivations de clés sont effectuées côté client avec K_seg ;
• le compromission totale de S n'expose pas les contenus chiffrés.

40.2 Zero Cloud

Aucun secret structurant n'est confié à un service cloud tiers :

• K_pair et ses segments restent locaux ;
• K_seg n'est jamais transmis ni stocké sur un cloud externe ;
• les backups cloud (si utilisés) contiennent uniquement des données préalablement chiffrées ;
• fonctionnement possible en mode local-only sans connexion Internet.

40.3 Zero Trace

Minimisation des traces et métadonnées exploitables :

• dérivation à la demande des clés, effacement rapide après usage ;
• pas de clair persistant côté client (sauf mode standard avec historique) ;
• journaux minimaux côté serveur (inexistants en mode Defense) ;
• métadonnées chiffrées ou minimisées ;
• mode Masqué : affichage chiffré par défaut, re-chiffrement automatique.

41. Résilience à la compromission serveur

En cas de compromission totale du serveur S :

1. Données chiffrées : le serveur ne détient que des blobs chiffrés, non déchiffrables sans K_seg.
2. Absence de clés : S ne peut pas dériver K_seg, K_conv_v2, ou K_msg à partir des identifiants publics.
3. Métadonnées limitées : même si les métadonnées (conversationId, timestamps) sont exposées, elles ne permettent pas le déchiffrement.
4. Pas de compromission rétroactive : grâce à la PFS locale, les messages antérieurs restent protégés même si S est compromis.
5. Récupération : restauration depuis backups chiffrés (section 34) sur un nouveau serveur, sans exposition des secrets.

La compromission de S peut permettre :

• l'interception de nouveaux messages (mais pas leur déchiffrement) ;
• l'analyse de trafic (volumes, fréquences, patterns) ;
• des attaques de disponibilité (DoS).

Ces risques sont limités par l'auto-hébergement et le contrôle de l'infrastructure.

42. Résilience à la compromission locale

En cas de compromission du terminal client :

1. Protection par segmentation :
   • K_pair est segmentée et non stockée en clair ;
   • l'accès à K_seg nécessite la recomposition des segments selon la politique ;
   • les segments matériels (NFC, HSM) ne sont pas accessibles via malware logiciel.
2. Effacement mémoire :
   • K_seg n'est maintenue en mémoire que temporairement ;
   • effacement actif après usage ou inactivité ;
   • protection contre le dump mémoire (si possible via OS).
3. PFS locale :
   • les clés K_msg des messages antérieurs sont effacées ;
   • seuls les messages de l'epoch courante sont exposés en cas de compromission.
4. Mode Masqué :
   • affichage chiffré par défaut ;
   • re-chiffrement automatique après déchiffrement temporaire ;
   • protection contre les captures d'écran et l'espionnage visuel.

Limites : un malware avec accès root durable et accès physique aux segments peut compromettre K_seg. La segmentation et les segments matériels réduisent cette surface d'attaque.

43. Résilience aux ransomwares et infostealers

Protection contre les malwares exfiltrant ou chiffrant les données :

1. Données déjà chiffrées :
   • les messages et fichiers sont stockés chiffrés sur le terminal ;
   • un ransomware ne peut pas re-chiffrer des données déjà chiffrées de manière exploitable ;
   • l'exfiltration de blobs chiffrés est inutile sans K_seg.
2. Protection de K_seg :
   • K_seg n'est pas stockée en clair sur le disque ;
   • accès via le moteur segmenté avec politique de segmentation ;
   • segments matériels non accessibles aux malwares logiciels.
3. Backups chiffrés :
   • backups 3-2-1 sur supports externes (section 34) ;
   • restauration possible sans dépendre du terminal compromis ;
   • les backups sont chiffrés indépendamment du système de fichiers.
4. Mode Defense :
   • stockage RAM-only, pas de persistance disque ;
   • auto-purge agressive de la mémoire ;
   • réduction de la surface d'attaque pour les infostealers.

Un infostealer peut exfiltrer des blobs chiffrés, mais ne peut pas les déchiffrer sans accès aux segments et à K_seg.

44. Résilience à l'espionnage visuel

Protection contre l'observation directe de l'écran :

1. Mode Masqué :
   • affichage chiffré par défaut (contenu non lisible) ;
   • déchiffrement explicite à la demande de l'utilisateur ;
   • re-chiffrement automatique après délai ou événement (changement d'onglet, perte de focus).
2. Clés de vue K_view :
   • dérivation de K_view selon la section 28 ;
   • chiffrement temporaire des buffers d'affichage ;
   • invalidation de K_view après re-chiffrement.
3. Protection contre les captures :
   • détection et blocage des captures d'écran (si supporté par l'OS/navigateur) ;
   • watermarking optionnel pour traçabilité ;
   • masquage automatique lors de partage d'écran (si détecté).
4. Protection physique :
   • filtres de confidentialité d'écran (mesure organisationnelle) ;
   • zones d'exclusion visuelle pour usages sensibles.

Le mode Masqué réduit significativement la fenêtre d'exposition visuelle, mais ne peut pas protéger contre une observation continue pendant le déchiffrement temporaire.

45. Considérations post-quantiques symétriques

45.1. Modèle d'attaquant quantique

On considère un attaquant disposant :

• d'un calculateur quantique capable d'exécuter :
  • Shor sur RSA/ECC (non utilisés dans CryptPeer),
  • Grover sur les primitives symétriques,
• d'une capacité illimitée de stockage ("store now, decrypt later") :
  • il peut archiver tout le trafic chiffré,
  • les bases de données serveur,
  • et tenter de les déchiffrer des années plus tard.

But de la méthode :

Même dans ce modèle, aucune clé utile pour déchiffrer les messages/fichiers ne doit être dérivable sans :

• casser AES-256 / SHA-3-512 sous Grover, et
• reconstruire la clé segmentée K_seg à partir de ses segments, ce qui suppose de casser la mécanique brevetée locale.

45.2. Choix de primitives et longueurs "quantum-informed"

Pour résumer :

• Chiffrement : AES-256-GCM
  • Sous Grover, la sécurité effective ≈ 128 bits, ce qui reste largement suffisant pour des usages réalistes de très long terme.
• Hachage / KDF :
  • SHA-256 pour compat (PBKDF2),
  • SHA-3-512 pour les dérivations critiques (HKDF) et dans le moteur segmenté.
• Longueurs de clés :
  • K_seg : au moins 256 bits, idéalement 256 ou 512 bits de sortie HKDF_SHA3_512,
  • K_conv_v2, K_file_v2, K_msg : 256 bits (clés AES-256).

Avec Grover, une clé de 256 bits se comporte approximativement comme une clé de 128 bits contre un adversaire quantique ; une marge encore très confortable.

45.3. Impact du quantique sur chaque étage de la méthode

Rappel de la chaîne :

Segments S1..Sn  ──>  Z  ──>  H = SHA3-512(Z || policyId || deviceContext)
                          │
                          └─>  K_pair = HKDF_SHA3_512(H, policySalt, "EviLink/SegmentedPairKey", 64)
                                    │
                                    └─>  K_seg = HKDF_SHA3_512(K_pair, appSalt, "CryptPeer/RootKey", 32..64)
                                              │
                                              ├─> K_conv_v2    = HKDF_SHA3_512(K_base_conv, K_seg, contextConv, 32)
                                              └─> K_file_v2    = HKDF_SHA3_512(K_file_base, K_seg, contextFile, 32)
                                                        │
                                                        └─> AES-256-GCM (messages, fichiers)

Effets quantiques :

Sur les segments et K_pair

Les segments ne sont pas le résultat d'un échange cryptographique à clé publique (pas d'ECDH à casser via Shor). Ils sont locaux, souvent matériels ou cognitifs.

Pour reproduire K_pair, un attaquant doit :

• soit obtenir tous les segments (compromission physique / sociale),
• soit casser directement SHA3-512 / HKDF_SHA3_512 (préimage) via Grover sur un espace de 512 bits → sécurité effective toujours très élevée.

Sur K_seg

K_seg est dérivé via HKDF_SHA3_512 à partir de K_pair et d'un sel d'application. Même en présence d'un ordinateur quantique, la recherche préimage sur un espace de 512 bits avec Grover reste impraticable, et K_seg n'est jamais en transit ni stocké côté serveur.

Sur les étapes PBKDF2-SHA-256 (K_base_conv, K_file_base)

Ces KDF restent basés sur SHA-256 : Grover réduit la sécurité asymptotiquement, mais on reste en pratique à un niveau proche de 128 bits. Surtout, K_base_conv et K_file_base ne suffisent plus : il faut aussi K_seg pour obtenir les clés finales.

Sur HKDF_SHA3_512 (K_conv_v2, K_file_v2, K_msg)

L'attaquant, même quantique, doit :

• soit casser HKDF_SHA3_512 (préimage) sur une sortie de 256 bits sous Grover,
• soit s'attaquer à AES-256-GCM directement,
• soit remonter à K_seg → ce qui ramène au problème précédent.

En pratique, à chaque étage, on impose un coût d'attaque exponentiel, divisé au mieux par √N avec Grover, mais toujours hors de portée.

45.4. Neutralisation du scénario "store now, decrypt later"

Scénario typique :

• L'attaquant enregistre aujourd'hui :
  • tout le trafic TLS (même si TLS est classiquement sécurisé),
  • toutes les BD serveur (messages chiffrés, fichiers chiffrés, IDs, etc.).
• Dans 20 ans, il dispose d'un calculateur quantique puissant.

Dans la méthode actuelle :

Il n'existe :

• aucune clé publique / privée à casser par Shor,
• aucun secret d'établissement de session sur le réseau,
• aucune copie de K_seg côté serveur.

Pour déchiffrer des données :

Il doit casser AES-256-GCM ou HKDF_SHA3_512 pour remonter à une clé utile, et même en remontant à K_base_conv / K_file_base, il lui manque toujours K_seg, qui n'est pas dans les données archivées.

Le modèle "je stocke maintenant et je casserai l'ECDH plus tard" n'a tout simplement pas de prise, parce que :

• il n'y a pas d'ECDH,
• la racine de sécurité est locale et segmentée, hors canal.

45.5. PFS locale et horizon d'exposition

La méthode peut être renforcée par une Forward Secrecy locale, en dérivant des clés éphémères :

K_epoch  = HKDF_SHA3_512(K_conv_v2, 0x00..00, "CryptPeer/msg/epoch", 32)
K_msg    = HKDF_SHA3_512(K_epoch, encodeUint64(msgIndex), "CryptPeer/msg", 32)

Conséquences (même face à un attaquant quantique) :

La compromission d'une clé K_msg ou même d'un petit ensemble de messages ne permet pas :

• de remonter à K_conv_v2,
• ni à K_seg,
• ni aux messages hors de l'"époque" considérée.

Tu peux inscrire dans ta doctrine : un horizon temporel explicite (par exemple : "au-delà de N années, l'accès à l'historique nécessite une re-validation segmentée stricte"), ce qui limite encore plus la valeur d'un dump de données anciennes, même pour un attaquant quantique.

45.6. Résumé "quantique" de la méthode de chiffrement à clé segmentée

La clé d'appairage segmentée est :

• locale,
• reconstruite à partir de segments multiples,
• hachée / dérivée avec SHA-3-512 + HKDF,
• jamais transmise ni stockée côté serveur.

La clé racine d'application K_seg :

• est obtenue à partir de K_pair,
• sert de sel fort dans des dérivations HKDF_SHA3_512 vers K_conv_v2, K_file_v2, K_msg.

Les clés opérationnelles chiffrent avec AES-256-GCM :

• Shor n'est pas applicable (pas de crypto asymétrique),
• Grover réduit la sécurité, mais on part de tailles de clés largement dimensionnées (256 bits).

Même avec un calculateur quantique :

• la recomposition de K_seg ne peut pas être attaquée via un "bruteforce réseau" (tout est local et segmenté),
• l'attaquant doit combiner une attaque contre AES-256/HKDF_SHA3_512 et contre la segmentation brevetée elle-même.

On peut donc présenter la méthode comme une architecture symétrique segmentée "quantum-informed" :

• elle ne dépend pas encore des schémas post-quantiques à clé publique (KEM/PKE),
• mais elle est conçue pour rester robuste même face à un adversaire quantique fort, grâce à :
  • l'absence de crypto asymétrique exposée,
  • le dimensionnement des primitives symétriques,
  • et la segmentation brevetée comme racine de confiance non exportable.

46. Protection des données (RGPD, LCPDP)

CryptPeer est conçu pour respecter les principes de protection des données personnelles, notamment le Règlement Général sur la Protection des Données (RGPD) de l'Union Européenne et la Loi Cadre sur la Protection des Données Personnelles (LCPDP) d'Andorre.

Les principes clés de minimisation des données sont intégrés dans l'architecture : chiffrement de bout en bout, absence de collecte centralisée d'identifiants personnels pour les communications, et contrôle utilisateur sur les clés de chiffrement.

46.1 Rôle d'EviEngine dans la protection des données

Le modèle de licence matérielle EviEngine contribue directement au principe de minimisation des données (RGPD, LCPDP) en évitant toute collecte centralisée d'identifiants personnels pour la gestion des licences. La licence est liée à des caractéristiques matérielles de la machine, et non à l'identité civile des utilisateurs.

En pratique, cela signifie que l'exploitant de CryptPeer n'a pas besoin :

• de maintenir une base de données nominative spécifique aux licences ;
• de remonter vers un tiers les informations de licence des instances déployées ;
• de traiter des couples « identité réelle ↔ licence » dans un service cloud.

EviEngine n'a pas vocation à remplacer une analyse d'impact RGPD ou LCPDP, mais il réduit la surface de données personnelles potentiellement traitées pour la seule gestion des licences, en cohérence avec une approche « privacy by design » :

• moins de données personnelles techniquement nécessaires ;
• moins d'intermédiaires ayant accès à ces données ;
• moins de flux de données vers des services externes.

47. NIS2 et maîtrise de l'infrastructure

La directive NIS2 (Network and Information Systems Directive) de l'Union Européenne impose aux opérateurs de services essentiels et d'importantes entités de maîtriser leur infrastructure critique et de réduire les dépendances vis-à-vis de tiers.

CryptPeer répond à ces exigences par son modèle d'auto-hébergement : l'opérateur contrôle entièrement l'infrastructure de communication, sans dépendance à des services cloud externes pour le relais des messages ou le stockage des données.

47.1 EviEngine et maîtrise des dépendances externes

Dans le contexte NIS2, la maîtrise des dépendances critiques (fournisseurs de services essentiels à la disponibilité ou à la sécurité) est centrale. L'utilisation d'EviEngine pour la gestion de licence évite de créer une dépendance supplémentaire envers un service de licence externe basé sur le cloud.

Concrètement, pour un opérateur :

• la disponibilité de CryptPeer ne dépend pas de la disponibilité d'un serveur de licence tiers ;
• aucun tiers n'a de visibilité en temps réel sur l'inventaire des instances déployées ;
• la validation de licence reste sous le contrôle de l'organisation, dans son périmètre réseau.

EviEngine renforce ainsi la cohérence du modèle « 100 % auto-hébergé » : l'opérateur de l'instance CryptPeer contrôle à la fois l'infrastructure de communication et le mécanisme de licence, sans back-end cloud caché. Cette réduction des dépendances externes s'inscrit dans une démarche de conformité NIS2 axée sur la résilience, la souveraineté opérationnelle et la limitation des tiers de confiance imposés.

48. Export de cryptographie (Llei 10/2025 et contexte UE)

La Llei 10/2025 d'Andorre et les réglementations européennes encadrent l'export de technologies cryptographiques. CryptPeer, développé en Andorre, respecte ces cadres réglementaires.

Les primitives cryptographiques utilisées (AES-256-GCM, SHA-256, SHA3-512, PBKDF2, HKDF) sont des standards internationaux largement déployés et ne sont pas soumis à des restrictions d'export spécifiques dans le contexte européen.

Partie IX – Implémentation, durcissement et journalisation

Annexes

Annexe A – Paramètres cryptographiques

Annexe B – Pseudo-code des dérivations de clés

B.1 Dérivation de K_seg

function derive_K_seg(K_pair, policyId, context):
    // Encodage déterministe du contexte
    contextBytes = encodeContext(context)
    
    // Dérivation via HKDF_SHA3_512
    K_seg = HKDF_SHA3_512(
        salt = K_pair,
        IKM = H3_512(policyId || contextBytes),
        info = "CryptPeer/RootKey",
        L = 32  // 256 bits
    )
    
    return K_seg
end function

B.2 Dérivation de K_base (conversation 1:1)

function derive_K_base(userId_A, userId_B, conversationId):
    // Tri lexicographique des IDs
    ids_sorted = sort([userId_A, userId_B])
    keyMaterial = ids_sorted[0] || ":" || ids_sorted[1] || ":" || conversationId
    
    // Salt déterministe
    salt = SHA256("CryptPeer/salt/v1" || keyMaterial)
    
    // PBKDF2
    K_base = PBKDF2_HMAC_SHA256(
        P = keyMaterial,
        salt = salt,
        iter = 100000,
        L = 32
    )
    
    return K_base
end function

B.3 Dérivation de K_conv_v2

function derive_K_conv_v2(K_base, K_seg):
    K_conv_v2 = HKDF_SHA256(
        salt = K_seg,
        IKM = K_base,
        info = "CryptPeer/msg/v2",
        L = 32
    )
    
    return K_conv_v2
end function

B.4 Dérivation de K_msg

function derive_K_msg(K_conv_v2_seed, epochId):
    // Encodage de l'epoch (64 bits big-endian)
    epochBytes = encodeUint64(epochId)
    
    K_msg = HKDF_SHA256(
        salt = epochBytes,
        IKM = K_conv_v2_seed,
        info = "CryptPeer/msg/epoch",
        L = 32
    )
    
    return K_msg
end function

Annexe C – Profils de politiques de segmentation

Les politiques de segmentation définissent les segments requis pour obtenir K_seg :

C.1 Politique standard

• Segments requis : 2 minimum
• Types :
  • 1 segment matériel (NFC, HSM) ou logiciel chiffré
  • 1 segment cognitif (PIN, phrase de passe)
• Ordre : matériel/logiciel puis cognitif
• Limite de tentatives : 3 échecs → verrouillage temporaire

C.2 Politique renforcée

• Segments requis : 3 minimum
• Types :
  • 1 segment matériel (HSM)
  • 1 segment logiciel chiffré
  • 1 segment cognitif (PIN fort)
• Ordre : matériel → logiciel → cognitif
• Limite de tentatives : 2 échecs → verrouillage
• Contexte : validation de l'instance et du mode

C.3 Politique Defense

• Segments requis : 3+ avec contexte
• Types :
  • 1 segment matériel dédié (HSM Defense)
  • 1 segment logiciel chiffré
  • 1 segment cognitif
  • 1 segment contextuel (présence réseau, device)
• Ordre : strict, avec validation de contexte à chaque étape
• Limite de tentatives : 1 échec → verrouillage immédiat
• Expiration : K_seg expire après durée limitée

Annexe D – Formats de messages et de fichiers

D.1 Format de message chiffré

MessageChiffre = {
    version: uint8,           // Version du format (1 ou 2)
    conversationId: bytes,     // Identifiant de conversation
    epochId: uint64,          // Identifiant d'epoch (pour K_msg)
    timestamp: uint64,        // Timestamp Unix
    iv: bytes[12],            // IV 96 bits pour AES-GCM
    ciphertext: bytes,        // Message chiffré
    tag: bytes[16]            // Tag d'authentification GCM 128 bits
}

D.2 Format de fichier chiffré

FichierChiffre = {
    version: uint8,           // Version du format (1 ou 2)
    userId: bytes,            // Identifiant utilisateur
    fileId: bytes,            // Identifiant unique du fichier
    salt: bytes[32],          // Salt 256 bits pour K_file_v2
    iv: bytes[12],            // IV 96 bits pour AES-GCM
    metadata: bytes,          // Métadonnées chiffrées (nom, type, taille)
    ciphertext: bytes,        // Fichier chiffré
    tag: bytes[16]            // Tag d'authentification GCM 128 bits
}

D.3 Format d'export JSON

ExportJSON = {
    formatVersion: string,    // "1.0"
    exportDate: string,       // ISO 8601
    conversationId: bytes,
    participants: [bytes],   // Liste des userId
    messages: [
        {
            epochId: uint64,
            timestamp: uint64,
            iv: base64,
            ciphertext: base64,
            tag: base64
        }
    ],
    files: [
        {
            fileId: bytes,
            salt: base64,
            iv: base64,
            metadata: base64,
            ciphertext: base64,
            tag: base64
        }
    ],
    cryptographicParams: {
        algorithm: "AES-256-GCM",
        kdf: "HKDF-SHA256",
        keyDerivation: "v2"
    }
}

D.4 Encodage

• Bytes : encodés en base64 pour JSON, binaires pour stockage binaire
• Entiers : big-endian, uint8 (1 octet), uint64 (8 octets)
• Chaînes : UTF-8 pour les champs texte

Annexe E – Glossaire

K_pair

Clé d'appairage segmentée gérée par le moteur.

K_seg

Clé racine locale dérivée de K_pair.

PFS locale

Perfect Forward Secrecy limitée au périmètre des messages et de l'historique sur un terminal donné.

Mode local-only

Mode de déploiement sans dépendance à Internet.

Mode Masqué

Mode d'affichage chiffré par défaut.

Mode Defense

Mode RAM-only, no-logs, pour usages régaliens.

Annexe F – Modèle de licence matérielle (EviEngine)

Cette annexe résume le rôle d'EviEngine dans CryptPeer. EviEngine est utilisé pour associer une licence logicielle à une plateforme matérielle donnée, sans serveur de licence et sans base de données centralisée. Ce mécanisme permet :

• de contrôler l'usage de CryptPeer à un parc de machines autorisées ;
• de respecter un modèle économique sans exposer d'informations d'identité personnelle ;
• de conserver la capacité de fonctionner en réseau fermé (local-only, air-gap).

EviEngine n'intervient pas dans la génération ou la dérivation des clés cryptographiques utilisées pour le chiffrement des messages, des fichiers, des sauvegardes ou des tunnels. Il est donc analytiquement séparé de la sécurité E2E décrite dans ce document, tout en contribuant à la souveraineté opérationnelle de la solution.