La sécurité est l'architecture, pas une réflexion après coup.
Q-Audion est chiffré de bout en bout dès la première ligne de code, avec un échange de clés hybride classique et post-quantique, des clés ancrées au matériel sur chaque plateforme, et un processus d'ingénierie mesuré à l'aune de référentiels de sécurité publiés et rédigés par des tiers.
Un échange de clés hybride pensé pour les vingt prochaines années, pas seulement pour aujourd'hui.
Chaque session est protégée par deux problèmes cryptographiques indépendants à la fois. La compromettre — même avec un futur ordinateur quantique — suppose de casser les deux.
Accord de clé post-quantique
ML-KEM-1024, le mécanisme d'encapsulation de clé post-quantique standardisé par le NIST (FIPS 203), combiné à X25519 classique dans une construction hybride — la sécurité ne redescend jamais sous ce que X25519 seul garantit déjà.
FIPS 203 · Catégorie 5Identité authentifiée
Chaque appareil signe son propre matériel de clé avec Ed25519 (RFC 8032). L'identité est vérifiable de bout en bout — y compris en personne, par comparaison de safety number et vérification NFC tap-to-verify.
Clés ancrées au matériel
Le matériel de clé privée est généré et utilisé dans StrongBox sur Android et dans la Secure Enclave sur iOS partout où l'appareil le permet — ce matériel de clé ne quitte jamais cette frontière matérielle.
Sessions à confidentialité persistante
Les clés de messages et d'appels avancent en continu par ratchet. Une clé récupérée à un instant donné n'expose ni les conversations précédentes ni les suivantes.
Conçu pour laisser le moins de traces possible de vous.
Les défaillances de vie privée sont presque toujours des défaillances de métadonnées. Notre infrastructure serveur est conçue pour retenir le minimum sur qui parle à qui.
Expéditeur scellé
Les notifications push transportent un identifiant opaque et salé — jamais un nom d'expéditeur, un aperçu du contenu, ou quoi que ce soit qu'un pipeline de notification hors de notre contrôle pourrait lire.
Pièces jointes chiffrées
Photos, notes vocales et fichiers sont scellés avec XChaCha20-Poly1305 avant même de quitter l'appareil, puis maintenus sous une seconde couche AES-256-GCM à clé matérielle tant qu'ils restent en cache sur disque.
Éphémère par choix
Les minuteries de messages et pièces jointes éphémères sont appliquées de la même façon sur chaque plateforme, avec les appareils des pairs maintenus synchronisés.
Numéros de téléphone, hachés
La découverte de contacts fonctionne à partir d'un hachage salé et à sens unique du numéro de téléphone — jamais le numéro brut — afin que les listes de contacts restent illisibles pour le service qui les met en correspondance.
Les parties que vous ne voyez jamais, tenues au même niveau d'exigence.
Une messagerie ne vaut que ce que vaut le pipeline qui la construit et la distribue. Chaque commit passe par les mêmes portes automatisées avant d'atteindre un appareil.
Certificate pinning, vérifié en continu
Chaque client épingle le certificat TLS du serveur — et une tâche automatisée quotidienne vérifie indépendamment que le certificat en production correspond toujours à celui épinglé, sur chaque plateforme, afin qu'une dérive soit détectée le jour même.
Dépendances épinglées et vérifiées
Chaque bibliothèque tierce est verrouillée à une version exacte, vérifiée par checksum. Une build ne peut pas fusionner avec une dépendance non épinglée ou non vérifiée — le pipeline la refuse automatiquement.
Analyse de sécurité continue
Le code source de chaque client et du serveur passe par des analyses de sécurité automatisées de façon continue, à la recherche des classes de vulnérabilités les plus pertinentes pour une application cryptographique en réseau.
Secrets jamais dans le code source
Les identifiants de production ne vivent que dans l'environnement d'exécution de la machine qui en a besoin, injectés au démarrage du processus — jamais commités, jamais intégrés dans un fichier de configuration du repository.
Nous nous mesurons au même niveau d'exigence qu'un auditeur.
Plutôt que de déclarer notre propre définition du « sécurisé », nous tenons notre processus d'ingénierie au niveau de référentiels rédigés et maintenus par la communauté de sécurité — et nous nous réévaluons à mesure que le produit évolue.
La référence du secteur pour ce qu'une application mobile soucieuse de sécurité doit réussir — du stockage local des données à l'interaction avec la plateforme jusqu'à la cryptographie.
Appliqué à nos services backend : authentification, gestion de session, contrôle d'accès et conception d'API, vérifiés selon la même checklist que les auditeurs indépendants.
Guide la façon dont nous gouvernons, identifions, protégeons, détectons, répondons et récupérons en tant qu'organisation d'ingénierie — pas seulement la façon dont une fonctionnalité est codée.
Comment lire ceci : il s'agit d'auto-évaluations internes, menées par rapport à des référentiels publiés publiquement et actualisées à mesure que le code évolue — pas d'un certificat délivré par un tiers. Lorsqu'un badge formel audité de façon indépendante existe pour une affirmation que nous faisons, nous nommerons l'auditeur et relierons directement le justificatif.
Contact
Sera publiée ici avec le public key block avant la release 1.0 publique.
Ouvrir une draft security advisory dans l'onglet Security du repository Q-Audion concerné (GitHub private vulnerability reporting).
Nos engagements
- Accusé de réception sous 48 heures ouvrées
- Triage et classification de sévérité sous 5 jours ouvrés
- Fenêtre de divulgation coordonnée de 90 jours par défaut, étendue uniquement avec l'accord du reporter quand un correctif complexe l'exige
- Crédit public dans les release notes sauf demande d'anonymat
Bug bounty
Un programme bug bounty géré sera opérationnel avant la 1.0 publique. En attendant, nous offrons des récompenses de bonne foi au cas par cas pour les findings à fort impact.
Scope
- +Tout le code serveur Q-Audion (identité, gestion des clés, transport, groupes, prekeys, file storage)
- +Tous les clients Q-Audion publiés sur Android, iOS et Desktop (Windows / macOS / Linux quand livré)
- +Design des protocoles cryptographiques (handshake PQ, double ratchet post-quantique, protection des métadonnées de l'expéditeur, Sigsum Key Transparency)
- +Drift de la wire spec causant un comportement cross-platform non sûr
- −Problèmes nécessitant un accès physique à un dispositif déverrouillé
- −XSS auto-infligé sans franchir une frontière de confiance
- −Versions navigateur/OS obsolètes hors fenêtres de support fournisseur
- −DDoS volumétrique sans logic flaw
- −Ingénierie sociale du personnel Q-Audion
- −Rapports basés sur sortie de scanner automatisé sans proof-of-concept fonctionnel
Wire specification ouverte
Le contrat cross-platform du protocole est octet-identique entre tous les clients Q-Audion. La spec est mirrorée dans les repositories clients et le repository serveur comme commit gating pour tout changement wire. Les reviewers indépendants peuvent la lire avant d'ouvrir une session — et les implémentations de bibliothèque (liboqs, BouncyCastle, @noble/post-quantum) sont cross-validées contre des vecteurs KAT partagés.
Builds reproductibles (cible 1.0)
Tous les artifacts de release 1.0 (APK, IPA, installeurs Desktop) seront signés Sigstore. La reproductibilité indépendante depuis les sources est un critère go-release: quiconque peut vérifier que le binaire livré correspond aux sources publiques.