Trust Center All docs PDF
SNT ChatPrivate messaging

Document public · Trust Center

Security Whitepaper

Architecture, cryptographie, modèle de menace et transparence pour la messagerie SNT Chat · beta Android et feuille de route E2EE.

Version
1.0.0
Date
6 août 2026
Classification
Public · sntchat.com
© 2026 SNT Chat · Vos messages. Vos clés. Votre @. · support@sntchat.com

Résumé exécutif

SNT Chat est une messagerie privée en beta (Android V1) centrée sur l’identité @username, la transparence (Trust Center public) et une feuille de route chiffrement bout en bout alignée sur les standards reconnus (Signal Protocol, AES-256-GCM, X25519).

Ce whitepaper décrit l’implémentation visée et l’état honnête du produit au moment de la version 1.0.0 du document : ce n’est pas une promesse marketing floue. Les éléments non livrés (E2EE complet sur tous les flux, iOS App Store, audit externe) sont listés explicitement.

Pilier Beta V1 / roadmap
Messagerie Chats, demandes d’ami, @username, Security Center
Chiffrement messages Double Ratchet (Signal), déploiement progressif
Pièces jointes Chiffrement côté client avant envoi stockage
Transport TLS 1.3 (HTTPS)
Identité authentification cloud + profil SNT ID
Auth renforcée 2FA TOTP, passkeys (Android), OAuth
Vérification contact Numéros de sécurité, scan QR
Transparence Trust Center, schémas, statut services
RGPD Export, suppression compte, politique publique
Attestation app Attestation app (intégrité appareil, etc.)

1. Introduction et périmètre

1.1 Objectif du service

SNT Chat permet à un utilisateur de :

SNT Chat n’est pas une application de stockage cloud grand public type « sauvegarde photos illimitée » : le cloud sert aux données de compte, métadonnées de chat et pièces jointes chiffrées, pas à remplacer un drive généraliste.

1.2 Périmètre document v1.0.0

Inclus dans la beta Android visée :

Exclus ou en cours (annoncés publiquement) :

1.3 Principes de conception

  1. Zero-knowledge (objectif) : le backend ne doit pas pouvoir lire le contenu des messages ni des fichiers chiffrés côté client.
  2. Défense en profondeur : TLS, règles d’accès cloud strictes, Attestation app, durées limitées sur URLs signées.
  3. Transparence : ce document, pages Trust, changelog, statut automatisé.
  4. Minimisation : collecte limitée aux métadonnées nécessaires au service.

2. Modèle de menace

2.1 Adversaires considérés

Adversaire Capacité Mitigation
Opérateur malveillant Accès base cloud, stockage objet, logs Chiffrement client, pas de clés privées sur serveur
Attaquant réseau (MITM) Interception HTTPS TLS 1.3, stacks OS
Compte cloud compromis Lecture règles cloud Isolation par UID, pas d’accès cross-user
Phishing identifiants Vol e-mail / MDP Passkeys, 2FA TOTP
Malware sur appareil Lecture mémoire / clés Verrou PIN/biométrie, limite du modèle E2EE
Usurpation de contact Mauvaise personne Numéros de sécurité, QR, Security Center
Client non autorisé (script) Appels API sans app Attestation app (intégrité appareil, etc.)

2.2 Hors périmètre explicite

3. Architecture système

3.1 Vue d’ensemble

[Appareil Android / iOS]
    │ Mobile UI · moteurs crypto / chat locaux
    │ Chiffrement messages & PJ (progressif E2EE)
    ▼
[authentification cloud]     identité, OAuth, passkeys
[base de données cloud]   conversations, messages, profils (UID-scoped)
[services backend]   logique métier, invites, RGPD, notifications push
[stockage objet chiffré]      blobs chiffrés (pièces jointes)
[notifications push]               push génériques (sans corps de message)
[site sécurisé (HTTPS)]  site · Trust Center · docs · .well-known

3.2 Composants

Composant Rôle Contenu message en clair ?
Application mobile Chiffrement, UI, sync Oui (sur appareil déverrouillé)
authentification cloud Sessions, OAuth Non
cloud database Métadonnées, enveloppes Non (selon phase E2EE)
services backend Orchestration, URLs signées, push Non
Stockage objet Stockage objet chiffré Non
notifications push Alertes Non (titre générique)

3.3 Régions

4. Cryptographie des messages

4.1 Standards retenus

Alignement SNT Crypto Engine (pas d’algorithmes « marketing » non standard) :

Roadmap post-quantique documentée : hybride X25519 + ML-KEM-768, signatures ML-DSA / SLH-DSA.

4.2 État beta (transparence)

Le déploiement E2EE est progressif : certaines phases peuvent transporter des enveloppes ou métadonnées en clair côté serveur le temps de la migration. Le Trust Center (/trust/visibility) décrit ce que SNT Chat voit aujourd’hui par rapport au contenu des messages.

4.3 Clés et sessions

4.4 Ce que le serveur ne reçoit jamais

5. Pièces jointes et stockage

Les fichiers joints suivent un modèle chiffrement client puis envoi :

  1. Lecture locale du fichier ;
  2. Chiffrement AES-256-GCM (clé dérivée / envelope selon implémentation) ;
  3. Upload direct vers stockage objet via URL signée à durée limitée ;
  4. Métadonnées (nom, taille, hash, clé de référence) en cloud database via Functions.

Le serveur ne reçoit jamais : mot de passe vault, clé maître, contenu fichier en clair.

6. Gestion des clés et verrou appareil

6.1 Identité cryptographique

6.2 PIN SNT (6 chiffres)

6.3 Biométrie

7. Authentification et session

7.1 Méthodes V1

Méthode Statut V1
E-mail / mot de passe Oui
Google Sign-In Oui
Facebook Oui (Android)
GitHub Oui (Android)
Apple Sign-In Selon plateforme / store
Passkeys Oui Android
2FA TOTP Oui

7.2 Cloud session

7.3 Vérification compte

8. Passkeys (WebAuthn / FIDO2)

8.1 Implémentation V1 (Android)

8.3 Limites

9. Authentification à deux facteurs (TOTP)

9.1 Standard

9.2 Codes de récupération

9.3 Flux login

  1. Auth primaire (e-mail, Google, passkey, etc.) ;
  2. Si 2FA activé : demande code TOTP ou récupération ;
  3. Vérification côté Function avant session complète.

10. Messagerie, sync et cloud database

10.1 Modèle de données

10.2 Temps réel

10.3 Pièces jointes

11. Invitations et liens

11.1 Parrainage / invite

12. Infrastructure cloud

12.1 cloud (Google Cloud)

12.2 stockage objet chiffré

12.3 CDN / DNS

13. Règles d’accès cloud database

13.1 Principes

13.2 Exemples

Collection Client read Client write
users/{uid} Propre UID Champs limités
usernames/{name} Contrôlé Transaction inscription
Secrets 2FA Non Non

14. URLs signées stockage objet chiffré

14.1 Upload

14.2 Download

15. CDN et transport

15.1 TLS

15.2 Intégrité

16. Notifications (notifications push)

16.1 Usage messagerie

16.2 Confidentialité

17. attestation application

17.1 Objectif

17.2 Providers

Plateforme Production
Android Play Integrity
iOS App Attest / Device Check
Web reCAPTCHA v3 (si applicable)

Déploiement progressif : mode Monitoring puis Enforced (voir documentation projet Attestation app).

18. RGPD : export et suppression

18.1 Export

18.2 Suppression

18.3 Sous-traitants

19. Journalisation et données visibles

19.1 Ce que SNT Chat peut voir

Donnée Visible serveur ?
E-mail, UID, @username, plan Oui
Horodatages, IDs conversation Oui
Corps message (cible E2EE) Non
Pièce jointe déchiffrée Non
PIN / clés privées Non

19.2 Logs

20. Trust Center et transparence

20.1 Pages publiques

20.2 Statut automatisé

20.3 Communauté

21. Divulgation responsable

21.1 Contact

21.2 Scope

22. Limites connues V1

  1. E2EE non universalisé sur tous les flux ;
  2. Pas de pentest externe publié ;
  3. iOS : parité selon calendrier store ;
  4. Pas de SLA contractuel public complet ;
  5. Malware local : hors garantie zero-knowledge standard.

23. Roadmap sécurité

Item Cible
Double Ratchet généralisé Post-beta
Attestation app enforced Après monitoring
Hybride post-quantique Roadmap moteur crypto
Pentest indépendant Post-beta
Bug bounty rémunéré Préparation

24. Glossaire

Terme Définition
E2EE Chiffrement bout en bout : seuls les participants lisent le contenu
Double Ratchet Protocole Signal pour forward secrecy
Prekey Clé publique prépubliée pour établir une session
Zero-knowledge Le serveur ne possède pas les secrets de déchiffrement
TOTP Mot de passe à usage unique basé sur le temps
Passkey Credential WebAuthn liée au domaine / app
Attestation app Attestation que la requête vient de l’app officielle

25. Références

26. Contrôle documentaire

Champ Valeur
Titre SNT Chat Security Whitepaper
Version 1.0.0
Date 6 août 2026
Classification Public
Domaine sntchat.com
Langue Français · English edition: same structure, EN summary + cover

Annexe A · FAQ technique sécurité

Q : SNT Chat peut-il lire mes messages ?
R : Consultez /trust/visibility. L’objectif produit est le zero-knowledge sur le contenu ; l’état exact de déploiement E2EE est documenté publiquement.

Q : Que contient une notification push ?
R : Un libellé générique, pas le corps du message dans le payload.

Q : Comment vérifier un contact ?
R : Numéro de sécurité ou scan QR dans le Security Center.

Q : Où signaler une vulnérabilité ?
R : /trust/disclosure et security.txt.

Annexe B · Scénarios de menace (synthèse)

B.1 Compte d’un autre utilisateur compromis

Impact : métadonnées, pas de déchiffrement sans clés victime.
Mitigations : 2FA, passkeys, isolation cloud database.

B.2 Fuite stockage objet

Impact : blobs chiffrés uniquement.
Mitigations : URLs signées courtes, chiffrement client.

B.3 Ingénierie sociale support

Procédure : pas de backdoor, pas de récupération des clés privées ; suppression compte si demandé (RGPD).

Signature éditoriale

Document approuvé pour publication publique par SNT Chat · Security & Privacy.

Contact : support@sntchat.com · Divulgation responsable : sntchat.com/trust/disclosure

SNT Chat Security & Privacy

© 2026 SNT Chat. Tous droits réservés.