Architecture & Sécurité Technique

Comprendre l'implémentation du chiffrement local, la gestion des clés via fragment d'URL et la suppression irréversible.

Architecture en Bref
  • Chiffrement AES-256-GCM
  • ClĂ©s GĂ©nĂ©rĂ©es cĂŽtĂ© client, stockĂ©es dans le fragment URL (#)
  • Transport TLS 1.3 Strict
  • Stockage serveur Capsule chiffrĂ©e opaque uniquement
  • DĂ©chiffrement OpĂ©rĂ© localement par le navigateur destinataire
  • Destruction Automatique (suppression irrĂ©versible) aprĂšs lecture

🧠 Le Principe Fondamental

La sécurité d'un systÚme ne se mesure pas à ses promesses commerciales, mais à son incapacité mathématique à compromettre les données qu'il traite.

Le protocole ITYLOS adopte un modÚle Zero-Trust vis-à-vis de l'infrastructure serveur : le serveur ne doit jamais disposer des informations nécessaires pour reconstituer une donnée en clair (Clé + Algorithme + Donnée). La confiance est déportée vers le navigateur de l'utilisateur.

⚙ Flux d'Architecture et de Transmission

Le systÚme repose sur la séparation stricte entre la donnée chiffrée (envoyée au serveur) et la clé de déchiffrement (conservée dans l'URL).

đŸ’»

1. Navigateur Expéditeur

  • GĂ©nĂ©ration de clĂ© (WebCrypto)
  • Chiffrement AES-256-GCM local
  • PrĂ©paration du payload
→
đŸ—„ïž

2. Serveur ITYLOS

  • RĂ©ception de la capsule chiffrĂ©e
  • GĂ©nĂ©ration d'un UUID
  • ClĂ© de dĂ©chiffrement inconnue
→
🔗

3. Lien ÉphĂ©mĂšre

  • La clĂ© est placĂ©e dans le fragment URL (#key)
  • Le fragment n'est jamais transmis au serveur par le navigateur
→
đŸ”„

4. Navigateur Destinataire

  • RĂ©cupĂ©ration de la capsule opaque
  • DĂ©chiffrement local via la clĂ© du #
  • Ordre de suppression irrĂ©versible

🔐 ImplĂ©mentations Cryptographiques

Nous n'inventons pas notre propre cryptographie. ITYLOS s'appuie exclusivement sur des primitives standardisées, auditées et intégrées nativement dans les navigateurs modernes.

AES-256-GCM

Standard de référence pour le chiffrement symétrique authentifié. Assure à la fois la confidentialité totale de la capsule et la garantie qu'elle n'a pas été altérée.

→ Chiffrement des capsules

Web Crypto API

L'entropie (l'aléatoire) nécessaire est produite directement par le systÚme d'exploitation via crypto.getRandomValues().

→ GĂ©nĂ©ration de clĂ©s cĂŽtĂ© client

Ed25519

Courbe elliptique asymétrique performante utilisée pour signer les certificats rendant notre journal d'audit infalsifiable.

→ Signature du registre d'audit

TLS 1.3 / HSTS

Le transport de l'enveloppe chiffrée entre le client et l'infrastructure est protégé contre l'interception réseau (MitM).

→ Transport sĂ©curisĂ© des flux

🎯 HypothĂšses de sĂ©curitĂ© & Limites

Tout modĂšle de sĂ©curitĂ© a un pĂ©rimĂštre d'action dĂ©fini. L'honnĂȘtetĂ© technique impose de clarifier ce que le systĂšme couvre, et ce qu'il ne peut matĂ©riellement pas empĂȘcher.

HypothÚses de sécurité (Trust Model)

  • Le navigateur client n'est pas compromis (pas de malware/keylogger).
  • L'implĂ©mentation de la Web Crypto API du navigateur est fiable.
  • Le canal de transport HTTPS (TLS) est intact.
  • L'infrastructure serveur n'est pas compromise Ă  la racine (intĂ©gritĂ© du code source distribuĂ©).

Limites connues du systĂšme

  • ITYLOS ne peut pas empĂȘcher une capture d'Ă©cran par le destinataire.
  • Ne protĂšge pas contre la copie volontaire du secret en clair une fois dĂ©chiffrĂ©.
  • Ne protĂšge pas contre l'interception locale si le poste client est infectĂ©.
  • Ne remplace pas un outil de messagerie asynchrone permanent (type Signal ou PGP).

📋 Politique de Journalisation (Logs)

Une bonne sécurité implique une transparence totale sur ce qui est stocké. Voici le détail de notre politique de journalisation applicative :

Ce que nous ignorons

  • Le contenu du message en clair
  • La clĂ© de dĂ©chiffrement (URL fragment)
  • Les fichiers tĂ©lĂ©versĂ©s en clair
  • Le mot de passe de protection optionnel
  • Les adresses IP persistantes au niveau applicatif

Ce que nous traitons

  • L'identifiant technique (UUID) de la capsule
  • Le "blob" de donnĂ©es chiffrĂ©es opaques
  • Les paramĂštres d'expiration (Horodatage UTC)
  • Les signatures de l'audit cryptographique public
  • Les IP temporaires (Exclusivement au niveau pare-feu/anti-DDoS)

Poursuivre l'audit de sécurité

ModĂšle de Menace

Ce que le systĂšme protĂšge... et ce qu'il ne protĂšge pas.

Politique de Sécurité

Programme de divulgation responsable et signalement de vulnérabilités.

Registre Public

Accédez au journal cryptographique append-only en temps réel.

Le Manifeste

Comprendre notre philosophie sur le droit à l'oubli numérique.