9.8 KiB
9.8 KiB
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 viadocker-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
- Confidentialité de contenu entre identités 4NK (utilisateur ↔ service, service ↔ service, groupes).
- Intégrité et authentification d’origine en s’appuyant sur les identités 4NK.
- Forward secrecy (selon profil), rotation et révocation praticables par nœud.
- 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)
- Échange (ou découverte) des clés publiques d’accord de clé (X25519) des deux entités 4NK.
- ECDH(X25519) → secret partagé; HKDF → clés de chiffrement et d’auth.
- Encapsulation du message via AEAD (XChaCha20‑Poly1305) avec nonce unique; ajout d’horodatage et d’ID de session.
- 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.