### 4NK vs Nostr vs Pubkey — Modèles, Sécurité, Identité, Stockage, Processus, Contrats, Usages, et Chiffrement de bout en bout #### Portée et hypothèses - Centralisation locale par nœud: chaque nœud 4NK héberge ses propres `confs/`, `data/`, `logs/`, `backups/`, isolés des autres nœuds. - Le relais applicatif (`sdk_relay`) charge sa configuration au runtime via `docker-compose.yml` (montage hôte → `/app/.conf`), sans variable “baked” au build. - Ce document compare 4NK, Nostr et la primitive Pubkey, puis propose un modèle de chiffrement E2E aligné avec l’identité 4NK. --- ### Panorama synthétique - 4NK (nœud local): plateforme orientée processus, stockage maîtrisé, observabilité, paiements conditionnels (BTC), preuves par ancrage on‑chain. - Nostr: protocole d’événements signés (pub/sub), minimaliste, décentralisé, best‑effort (rétention non garantie), identité = clé publique. - Pubkey: primitive d’identité cryptographique (clé publique); ni protocole ni réseau. --- ### Identité - 4NK: identités de services/utilisateurs adossées à des paires de clés, enrichies par métadonnées locales (rôles, domaines, politiques). Rotation/revocation gérées par le nœud. - Nostr: identité = clé publique (npub). AuthN par signatures d’événements, découverte/délégation via NIPs. - Pubkey: ancre cryptographique brute; toute sémantique (droits, révocation) est hors‑bande. ### Authentification et Autorisation - 4NK: AuthN par clés/secrets; AuthZ via ACL/RBAC/politiques locales (exposition minimale, séparation par service). - Nostr: AuthN par signature d’événements. AuthZ hors‑protocole, dépend de chaque relay. - Pubkey: permet signatures/vérifications; pas d’AuthZ native. ### Données et Stockage - 4NK: données d’état/processus, artefacts, logs structurés; persistance locale (FS/DB) par nœud; schémas contrôlés; rétention et sauvegardes, bdd chiffrée répliquée coté utilisateur final. - Nostr: événements append‑only JSON signés; pas d’état global; persistance best‑effort selon les relays. - Pubkey: pas de stockage associé. ### Processus et Orchestration - 4NK: formalisation d’états, transitions, pré/post‑conditions, timeouts et retries; observabilité (healthchecks, métriques) et dépendances explicites. - Nostr: processus exprimables comme flux d’événements, sans garanties d’ordre/persistance; orchestration côté clients/serveurs. - Pubkey: utilisée pour authentifier/attester des étapes, pas pour orchestrer. ### Contrats et Garanties - 4NK: contrats métier explicites (conditions, tarifs, SLAs, GDPR, clauses contractuelles ou tout autre types) exécutés par code local; preuves via ancrage périodique sur Bitcoin (intégrité temporelle, non‑répudiation) et Client Side Validation depuis la collecte des preuves. - Nostr: conventions via NIPs; pas de mécanismes d’exécution contraignants. - Pubkey: base pour signatures de contrats; exécution hors‑bande. ### Paiements et Économie - 4NK: BTC on‑chain (ou LN si ajouté) conditionnant des actions (ex. ancrage). Traçabilité des paiements liée aux processus. - Nostr: « zaps » LN (NIPs); micro‑paiements sociaux; intégration limitée aux workflows contraints. - Pubkey: N/A. ### Sécurité (vue d’ensemble) - 4NK (local): surface d’attaque réduite; réseaux privés et globaux mais sgementés par services, exposition contrôlée; journaux centralisés; preuves on‑chain. Contrôles: ACL/RBAC, politiques de secrets, durcissement de conteneurs, Tor optionnel. - Nostr: résilience à la censure (publication multi‑relays), mais hétérogénéité de sécurité; risque de spam/DoS; confidentialité limitée hors DM chiffrés. - Pubkey: sécurité dépend de la gestion du cycle de vie des clés (génération, stockage, rotation, révocation). --- ## Chiffrement de bout en bout (E2E) dans 4NK ### Objectifs 1) Confidentialité de contenu entre identités 4NK (utilisateur ↔ service, service ↔ service, groupes). 2) Intégrité et authentification d’origine en s’appuyant sur les identités 4NK. 3) Forward secrecy (selon profil), rotation et révocation praticables par nœud. 4) Compatibilité avec transport TLS et stockage chiffré au repos. ### Matériel d’identité et primitives recommandées - Identité 4NK par service/utilisateur: paires de clés longue durée pour signature ET pour échange de clé (séparation des usages recommandée). - Signature: Ed25519 (libsodium/ed25519‑dalek). - Échange de clé: X25519 (ECDH) pour établir des secrets partagés sans interraction (flux utilisateurs) - Symétrique: XChaCha20‑Poly1305 (AEAD) pour messages volumineux/streams; ChaCha20‑Poly1305 acceptable (Vault local des secrets) - KDF: HKDF‑SHA‑256 pour dérivations de clés à partir des secrets partagés. - Chiffrement côté utilisateur des clés privées : PBKDF2 depuis le modèle de sécurité du host ou de l'application (navigateur) depuis les API natives de gestion des crédentials ### Établissement de session (1‑to‑1) 1) Échange (ou découverte) des clés publiques d’accord de clé (X25519) des deux entités 4NK. 2) ECDH(X25519) → secret partagé; HKDF → clés de chiffrement et d’auth. 3) Encapsulation du message via AEAD (XChaCha20‑Poly1305) avec nonce unique; ajout d’horodatage et d’ID de session. 4) Option forward secrecy: introduire une clé éphémère côté émetteur (Noise‑like) pour sessions courtes; ou adopter Double Ratchet pour dialogues persistants. ### Sessions persistantes (Double Ratchet, optionnel) - Mise en place d’une session initiale (X3DH/Noise‑XX) puis ratchets symétriques périodiques. - Avantages: forward secrecy et post‑compromise security; coûts accrus de gestion. ### Groupes (N‑to‑N) - Schéma « sender keys »: une clé de groupe symétrique par canal/processus, chiffrée pour chaque membre via sa clé X25519. - Rotation périodique des clés de groupe; gestion des entrées/sorties (rekey à l’arrivée/départ). ### Signatures et métadonnées - Signatures Ed25519 sur l’enveloppe (ou l’empreinte) des messages avant chiffrement pour l’authentification d’origine. - Minimiser les métadonnées en clair: utiliser identifiants pseudonymes de session, timestamp borné; éviter les sujets sensibles dans headers. ### Stockage chiffré au repos (data/, backups/) - Envelope encryption: DEK (Data Encryption Key) aléatoire par objet/fichier; DEK chiffrée par KEK (Key Encryption Key) gérée localement (ex. 4NK_vault ou HSM/TPM). - Rotation KEK programmée; re‑chiffrement progressif des DEK. - Index/metadata sensibles chiffrés (ou hachés) pour réduire l’exfiltration d’information. ### Logs et observabilité - Journaux: éviter les données sensibles en clair; masquer/pseudonymiser; option de logs chiffrés par service. - Prometheus/Grafana: exporter des métriques non sensibles; secrets exclus des séries temporelles. ### Sauvegardes - Chiffrer intégralement les backups; gérer versions et rotation; stocker séparément les clés de déchiffrement (split knowledge si possible). ### Gestion du cycle de vie des clés - Génération: entropie forte; préférer matériel (HSM/TPM/YubiKey) pour racines d’identité critiques. - Stockage: scindé par service; secrets en mémoire le strict minimum; pas d’inclusion en image Docker. - Rotation: planifiée par service et par canal; compatibilité avec Double Ratchet et rekey de groupes. - Révocation: listes locales (CRL interne), horodatages des états, invalidation des sessions. ### Transport - TLS obligatoire entre services exposés; E2E assure confidentialité indépendamment du transport. - WebSockets/HTTP internes: réseau privé; limiter les surfaces publiques via reverse‑proxy/Nginx. ### Ancrage et confidentialité - Ancrer des empreintes (hashes, Merkle roots) et non des données en clair. - Publier des preuves minimales (révélations sélectives) lors des vérifications tierces pour les oracles sur les relais qui ancrent les flux. - A faire : ajouter des « salts »/domain separators pour éviter la corrélation inter‑domaines. --- ## Comparatif décisionnel | Dimension | 4NK (nœud local) | Nostr | Pubkey | |---|---|---|---| | Identité | Clés + rôles/politiques locales | npub (clé publique) | Clé publique | | AuthN/AuthZ | Signatures + ACL/RBAC | Signatures; AuthZ relay‑dépendant | Signatures | | Données | État/processus/logs persistants | Événements best‑effort | N/A | | Processus | Orchestration locale, garanties | Flux client‑driven | N/A | | Contrats | Exécutables + preuve on‑chain | Conventions NIPs | N/A | | Paiements | BTC on‑chain conditionnels | LN zaps (NIPs) | N/A | | Sécurité | Périmètre local + E2E | Ouvert; modération variable | Dépend de l’usage | | Chiffrement E2E | Natif proposé (X25519/XChaCha20) | DM (NIP‑04/44) | Base crypto | | Observabilité | Centralisée (logs/metrics) | Non standardisée | N/A | | Conformité | Forte (preuves, rétention) | Complexe | N/A | --- ## Interop et usages recommandés - 4NK comme socle d’exécution local: workflows, conformité, chiffrement E2E, preuves on‑chain. - Nostr comme couche de diffusion publique: publication optionnelle de résumés signés (hash, état, timestamp, référence de preuve) pour visibilité. - Pubkey comme identifiant portable: unifier l’authentification et les signatures inter‑systèmes. --- ## Bonnes pratiques opérationnelles (résumé) - Séparer les clés de signature et d’accord de clé; privilégier HSM/TPM pour identités critiques. - Ne jamais « baker » des secrets dans les images; charger au runtime via volumes/env_file. - Mettre en place rotation/révocation; surveiller l’usage des clés et les anomalies. - Chiffrer au repos (envelope encryption), chiffrer en transit (TLS), chiffrer E2E au niveau applicatif pour contenus sensibles. - Limiter les métadonnées; journaliser sans secrets; supervision continue.