Une Architecture Fondée sur la Confidentialité

Contrairement aux applications traditionnelles, iCanText est bâti sur un réseau pair-à-pair (P2P) direct, éliminant tout intermédiaire central.

Architecture du Réseau iCanTextABCDEFAucun Serveur CentralLes données circulent directemententre les utilisateurs.

Chapitre 1 : Identité Souveraine et Gestion des Clés

Le fondement de notre sécurité : chaque utilisateur est le seul et unique gardien de son identité numérique.

Génération et Propriété des Clés

Toutes les clés cryptographiques sont générées et stockées exclusivement sur votre appareil. Elles ne sont jamais transmises. Votre identité est mathématiquement dérivée de votre clé publique, supprimant tout besoin de compte centralisé.

Stockage Sécurisé de l'Identité

Si vous choisissez de la conserver, votre identité est chiffrée sur votre appareil avec une clé dérivée de votre mot de passe. L'accès physique à l'appareil ne suffit pas pour compromettre vos clés, et les attaques par force brute sont rendues infructueuses.

Identités Éphémères

Pour une confidentialité maximale, iCanText permet de créer des identités "éphémères" qui n'existent qu'en mémoire pour la durée de la session. C'est le mode par défaut, ne laissant aucune trace sur votre appareil.

Toile de Confiance Décentralisée

Chaque identité possède une "empreinte" unique. Vous pouvez comparer ces empreintes avec vos contacts via un canal externe (de vive voix, par exemple) pour vous prémunir contre toute usurpation d'identité et garantir que vous parlez à la bonne personne.

Chapitre 2 : Gouvernance et Contrôle d'Accès Décentralisés

Sans serveur central, iCanText s'appuie sur une "chaîne de confiance" cryptographique pour gérer les permissions et l'autorité au sein d'un espace de travail.

La Chaîne de Confiance

Racine de Confiance (Fondateur)

Le premier utilisateur à créer un espace de travail devient sa "racine de confiance". Il s'auto-attribue un certificat cryptographique de "WORKSPACE_ADMIN", qui sert de point de départ à toute délégation d'autorité.

Certificats de Permission

Toute permission (devenir admin, créer un canal, accéder à un canal) est accordée via un certificat numérique signé par une autorité existante (le fondateur ou un autre admin). Ces certificats sont infalsifiables.

Chaîne de Preuve (Proof Chain)

Lorsqu'un admin accorde une permission, il joint sa propre "chaîne de preuve" : la séquence de certificats qui remonte jusqu'au fondateur et qui prouve son autorité. Chaque membre du réseau peut ainsi vérifier de manière indépendante la validité de chaque permission.

Portefeuille de Preuves (Proof Wallet)

Chaque utilisateur maintient localement un "portefeuille" contenant tous les certificats valides qu'il a observés. C'est cette base de données locale qui lui permet de décider instantanément si un utilisateur a le droit d'effectuer une action, sans jamais consulter un serveur.

Modes d'Accès Sécurisés au Workspace

Accès Public

Le mode par défaut. N'importe qui connaissant l'ID de l'espace de travail peut le rejoindre. La sécurité repose alors sur les permissions des canaux internes.

Protégé par Mot de Passe

L'accès est conditionné par un mot de passe. Le processus de vérification se fait via un défi-réponse cryptographique entre le nouvel arrivant et un membre du réseau, sans que le mot de passe ne transite jamais en clair.

Sur Invitation Uniquement

Un administrateur génère un lien d'invitation à usage unique. Ce lien contient un certificat d'accès temporaire signé. Lorsqu'un nouvel utilisateur l'utilise, le réseau vérifie la validité du certificat et le "brûle" pour empêcher sa réutilisation.

Chapitre 3 : Sécurité des Communications

Chaque message et interaction sur le réseau est protégé par de multiples couches de sécurité cryptographique.

Chiffrement de Bout-en-Bout (E2EE)

Les conversations privées sont protégées par un chiffrement de bout-en-bout. Seuls vous et votre correspondant pouvez lire les messages. Aucun nœud intermédiaire relayant le message ne peut en déchiffrer le contenu.

Confidentialité Future des Canaux (Ratchet)

Chaque canal utilise une clé de session partagée. Pour renforcer la sécurité, iCanText implémente un mécanisme de "ratchet" : chaque message est chiffré avec une clé unique et éphémère, dérivée mathématiquement de la clé de session et d'un compteur. Ainsi, la compromission future de la clé de session ne permettrait pas de déchiffrer les messages passés, garantissant une confidentialité persistante (Forward Secrecy).

Authenticité et Intégrité Garanties

Chaque message est numériquement signé par son expéditeur. À la réception, cette signature est vérifiée. Cela garantit que l'expéditeur est bien qui il prétend être et que le message n'a pas été altéré en cours de route. Tout message modifié est automatiquement rejeté.

Chapitre 4 : Confidentialité des Métadonnées

Protéger le contenu ne suffit pas. iCanText intègre des mécanismes avancés pour dissimuler qui parle à qui.

Absence de Serveur Central

iCanText n'utilise pas de serveur central pour gérer les identités, contacts ou messages. Cela élimine le point de défaillance unique et la cible de surveillance la plus évidente. Un service minimaliste est utilisé uniquement pour la découverte initiale, sans jamais voir vos données.

Routage Scellé ("Onion Routing")

Les messages privés sont encapsulés dans plusieurs couches de chiffrement. Chaque nœud intermédiaire ne peut déchiffrer que sa propre couche, qui ne lui révèle que le prochain saut. Personne sur le chemin ne connaît à la fois l'expéditeur original et le destinataire final.

Diffusion par Inondation Contrôlée

Les messages publics et les annonces réseau sont diffusés sur le maillage P2P. Pour éviter la saturation, chaque message a une durée de vie limitée (TTL) et les nœuds rejettent intelligemment les messages qu'ils ont déjà vus pour éviter les boucles et les surcharges.

Chapitre 5 : Réseau Dynamique et Résilient

Conçu pour un monde instable, le réseau iCanText est vivant, autonome et ne dépend d'aucune infrastructure centralisée.

Auto-réparation du Maillage

Le réseau P2P est en constante évolution. Si un nœud se déconnecte, les autres participants recalculent dynamiquement les meilleures routes pour contourner la panne. Le réseau se "guérit" lui-même pour maintenir la connectivité sans aucune intervention.

Persistance des Données sans Serveur

L'historique des conversations n'est pas stocké sur un serveur central, mais distribué entre les participants. Tant qu'au moins un utilisateur membre d'un canal est en ligne, l'historique de ce canal reste accessible et peut être synchronisé par les nouveaux arrivants.

Aucune Installation Requise

iCanText fonctionne entièrement dans un navigateur web moderne. Il n'y a rien à télécharger ou à installer, ce qui réduit la surface d'attaque et garantit que vous utilisez toujours la version la plus à jour et la plus sécurisée de l'application.

Session Volatile, Aucune Trace

En mode éphémère, votre identité et vos messages n'existent qu'en mémoire. À la fermeture de l'onglet, tout s'évapore. L'application est conçue pour ne laisser aucune trace dans le cache du navigateur ou dans votre historique d'utilisation local.

Routage Robuste (Poison Reverse)

Pour maintenir une carte du réseau à jour, les nœuds échangent des informations sur les meilleures routes. Pour éviter les "boucles de routage" (où un message tournerait en rond), iCanText utilise la technique du "Poison Reverse" : un nœud annonce à son voisin qu'une route passant par lui a un coût infini, l'empêchant de la lui renvoyer. Cela stabilise le réseau et garantit une livraison efficace des messages.

Chapitre 6 : Protection de l'Interface Web

Au-delà du réseau, la sécurité de l'application elle-même est renforcée contre les attaques courantes du web.

Prévention du Cross-Site Scripting (XSS)

Tous les messages et contenus affichés dans l'interface sont systématiquement nettoyés et "sanétisés". Ce processus neutralise tout code (ex: JavaScript) potentiellement malveillant qu'un attaquant tenterait d'injecter dans un message, protégeant ainsi votre navigateur et vos données.

Défense Anti-Clickjacking

iCanText implémente un mécanisme de "frame-busting". Il empêche l'application d'être chargée de manière invisible à l'intérieur d'un autre site web. Cela vous protège contre les attaques de "clickjacking", où un attaquant vous incite à cliquer sur des boutons de l'application sans que vous le sachiez.

Chapitre 7 : Analyse des Menaces et Mitigation

Aucun système n'est infaillible, mais iCanText est conçu pour résister aux attaques les plus courantes et les plus sophistiquées.

Menace / AttaqueDescriptionMitigation dans iCanText
Usurpation d'Identité (MitM)Un attaquant se fait passer pour un autre utilisateur pour intercepter ou altérer les communications.Chiffrement E2EE & Signatures : Le contenu est illisible et non modifiable.
Vérification d'empreintes : La comparaison hors-bande des empreintes cryptographiques permet de détecter l'attaque.
Attaque SybilUn attaquant crée une multitude de fausses identités pour obtenir une influence disproportionnée sur le réseau.Gouvernance Décentralisée : L'élection des nœuds importants (Portiers) est basée sur un score de performance (stabilité, connectivité), rendant l'attaque coûteuse. Les fausses identités n'ont aucune autorité sans être validées par des membres de confiance.
Attaque par ÉclipseUn attaquant isole un nœud du reste du réseau en contrôlant tous ses voisins directs.Topologie Dynamique : Les mécanismes d'auto-réparation et de recherche de raccourcis encouragent une connectivité diversifiée, rendant l'isolement complet d'un nœud très difficile.
Analyse de TraficUn observateur analyse les flux de données pour déduire qui communique avec qui.Routage Scellé : Dissimule l'origine et la destination finale des messages privés aux nœuds intermédiaires qui ne font que relayer des données chiffrées.
Attaque par RejeuUn attaquant intercepte un message valide et le renvoie plus tard pour perturber le système.ID de Message Uniques : Chaque message possède un identifiant unique. Les nœuds maintiennent un cache des ID récents et rejettent systématiquement tout message déjà vu.
Déni de Service (DDoS)Un attaquant sature le réseau ou un nœud avec un grand volume de messages.Décentralisation : L'absence de serveur central rend une attaque DDoS classique inefficace.
TTL & Blocage : La durée de vie des messages est limitée et les utilisateurs peuvent bloquer les nœuds malveillants, les isolant du réseau.

Chapitre 8 : Périmètre et Limites de la Confidentialité

L'hyper confidentialité est notre objectif. Il est important de définir clairement ce qui est protégé et ce qui constitue un compromis inhérent à l'architecture.

Ce qui EST Protégé :

Limites et Compromis Actuels :

Comment iCanText se compare-t-il ?

Une analyse comparative face aux messageries centralisées et décentralisées populaires.

CaractéristiqueiCanTextSignalTox / JamiBriarWhatsApp / MessengerTelegram
ArchitectureP2P (Maillage Partiel Dynamique)CentraliséeP2P (DHT)P2P (Réseau d'amis + Tor)CentraliséeCentralisée
Chiffrement E2EE Oui (par défaut) Oui (par défaut) Oui (par défaut) Oui (par défaut) Oui (par défaut)⚠️ Optionnel
Protection des Métadonnées Élevée (Routage Scellé) Limitée⚠️ Partielle Très Élevée (via Tor) Nulle Nulle
Anonymat de l'Identité Total (basée sur clé crypto) Non (N° tél.) Élevé Élevé Non (N° tél. / Profil) Non (N° tél.)
Mise à l'échelle (Scalabilité) Élevée (Routage optimisé) Très Élevée⚠️ Limitée (DHT) Faible (petits groupes) Très Élevée Très Élevée
Stockage des Messages En mémoire (par défaut)⚠️ Sur appareil⚠️ Sur appareil⚠️ Sur appareil⚠️ Sur appareil + Cloud (backup) Sur serveur (par défaut)
Fonctionnement sans Internet Non Non Non Oui (offline) Non Non
Aucune Installation Requise Oui (Web App) Non (App) Non (App) Non (App) Non (App) Non (App)
Résilience aux Pannes Réseau Très Élevée (auto-réparation) Nulle (point central)⚠️ Moyenne Très Élevée Nulle (point central) Nulle (point central)
Contrôle d'Accès Avancé Oui (Mots de passe, Invitations)⚠️ Groupes privés simples Non Non (basé sur contact direct)⚠️ Groupes privés simples⚠️ Groupes privés/publics
Comparez également avec Viber, Discord, Teams, Tchap, Olvid, Session, Slack et cwtch

Une Transparence Totale : Notre Endpoint Open Source

Pour atteindre un niveau de souveraineté absolue, iCanText vous donne la possibilité d'héberger vous-même le seul composant centralisé : le service de signalisation. Le code de ce service est entièrement open source.

Cela signifie que vous pouvez créer un univers de communication totalement indépendant, où même nous, les créateurs d'iCanText, n'avons plus aucune visibilité technique sur l'existence de votre réseau. C'est la garantie ultime de confidentialité pour les organisations et les communautés les plus exigeantes.

Découvrez comment déployer votre propre endpoint →

Le message le plus privé est celui qui ne passe par aucun intermédiaire.