4NK_env/docs/COMPARISON_4NK_Nostr_Pubkey_E2E.md

148 lines
9.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

### 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 lidentité 4NK.
---
### Panorama synthétique
- 4NK (nœud local): plateforme orientée processus, stockage maîtrisé, observabilité, paiements conditionnels (BTC), preuves par ancrage onchain.
- Nostr: protocole dévénements signés (pub/sub), minimaliste, décentralisé, besteffort (rétention non garantie), identité = clé publique.
- Pubkey: primitive didentité 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 horsbande.
### 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 horsprotocole, dépend de chaque relay.
- Pubkey: permet signatures/vérifications; pas dAuthZ 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 appendonly JSON signés; pas détat global; persistance besteffort selon les relays.
- Pubkey: pas de stockage associé.
### Processus et Orchestration
- 4NK: formalisation détats, transitions, pré/postconditions, timeouts et retries; observabilité (healthchecks, métriques) et dépendances explicites.
- Nostr: processus exprimables comme flux dévénements, sans garanties dordre/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, nonrépudiation) et Client Side Validation depuis la collecte des preuves.
- Nostr: conventions via NIPs; pas de mécanismes dexécution contraignants.
- Pubkey: base pour signatures de contrats; exécution horsbande.
### Paiements et Économie
- 4NK: BTC onchain (ou LN si ajouté) conditionnant des actions (ex. ancrage). Traçabilité des paiements liée aux processus.
- Nostr: « zaps » LN (NIPs); micropaiements sociaux; intégration limitée aux workflows contraints.
- Pubkey: N/A.
### Sécurité (vue densemble)
- 4NK (local): surface dattaque réduite; réseaux privés et globaux mais sgementés par services, exposition contrôlée; journaux centralisés; preuves onchain. Contrôles: ACL/RBAC, politiques de secrets, durcissement de conteneurs, Tor optionnel.
- Nostr: résilience à la censure (publication multirelays), 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 dorigine en sappuyant 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 didentité 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/ed25519dalek).
- Échange de clé: X25519 (ECDH) pour établir des secrets partagés sans interraction (flux utilisateurs)
- Symétrique: XChaCha20Poly1305 (AEAD) pour messages volumineux/streams; ChaCha20Poly1305 acceptable (Vault local des secrets)
- KDF: HKDFSHA256 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 (1to1)
1) Échange (ou découverte) des clés publiques daccord de clé (X25519) des deux entités 4NK.
2) ECDH(X25519) → secret partagé; HKDF → clés de chiffrement et dauth.
3) Encapsulation du message via AEAD (XChaCha20Poly1305) avec nonce unique; ajout dhorodatage et dID de session.
4) Option forward secrecy: introduire une clé éphémère côté émetteur (Noiselike) pour sessions courtes; ou adopter Double Ratchet pour dialogues persistants.
### Sessions persistantes (Double Ratchet, optionnel)
- Mise en place dune session initiale (X3DH/NoiseXX) puis ratchets symétriques périodiques.
- Avantages: forward secrecy et postcompromise security; coûts accrus de gestion.
### Groupes (NtoN)
- 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 à larrivée/départ).
### Signatures et métadonnées
- Signatures Ed25519 sur lenveloppe (ou lempreinte) des messages avant chiffrement pour lauthentification dorigine.
- 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; rechiffrement progressif des DEK.
- Index/metadata sensibles chiffrés (ou hachés) pour réduire lexfiltration dinformation.
### 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 didentité critiques.
- Stockage: scindé par service; secrets en mémoire le strict minimum; pas dinclusion 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 reverseproxy/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 interdomaines.
---
## 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 relaydépendant | Signatures |
| Données | État/processus/logs persistants | Événements besteffort | N/A |
| Processus | Orchestration locale, garanties | Flux clientdriven | N/A |
| Contrats | Exécutables + preuve onchain | Conventions NIPs | N/A |
| Paiements | BTC onchain conditionnels | LN zaps (NIPs) | N/A |
| Sécurité | Périmètre local + E2E | Ouvert; modération variable | Dépend de lusage |
| Chiffrement E2E | Natif proposé (X25519/XChaCha20) | DM (NIP04/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 dexécution local: workflows, conformité, chiffrement E2E, preuves onchain.
- 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 lauthentification et les signatures intersystèmes.
---
## Bonnes pratiques opérationnelles (résumé)
- Séparer les clés de signature et daccord 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 lusage 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.