Pourquoi l'isolation matérielle plutôt qu'un meilleur logiciel ?

Si l'OS peut lire le microphone, n'importe quel spyware ayant root sur l'OS peut aussi le lire. L'isolation matérielle lie le bus microphone au Secure World au démarrage — le Normal World ne peut littéralement pas le reconfigurer.

Qu'est-ce que le DMA Air-Gap ?

DMA Air-Gap est notre motif patent-pending (UIBM 2026, brevet n°1) pour lier les descripteurs DMA des périphériques au Secure World au premier démarrage. Le périphérique n'apparaît pas comme device au Normal World. C'est l'épine dorsale architecturale de la garantie anti-interception de Q-AUDION.

Pourquoi ML-KEM-1024 et pas seulement AES ?

AES est un chiffre symétrique — les deux parties ont besoin de la même clé. ML-KEM-1024 est le mécanisme d'encapsulation de clé qui permet à deux parties de se mettre d'accord sur cette clé AES sans qu'un attaquant (même quantique futur) ne puisse la récupérer. Les deux sont utilisés ensemble.

Le wire est-il identique sur Android, iOS et Desktop ?

Oui — byte-identique. Nous l'imposons en CI via des vecteurs Known-Answer-Test que les trois plateformes doivent passer avant chaque release.

Technologie · Key Management

Souverain par conception. Vos clés, pas les nôtres.

Name: Q-AUDION
Brand: Q-AUDION

Notre Key Management System garde des conteneurs opaques — jamais leur contenu. La clé maître vit entre vos mains, liée au matériel, vérifiée par vous, à jamais hors de notre périmètre d'opérateur.

Gestion souveraine des clés

Le coffre-fort qui ne peut pas regarder à l'intérieur de lui-même.

Client

Master Key

Coffre-fort à conteneurs opaques

KMS Vault

Liée au matériel · porte s'ouvrant uniquement vers l'extérieur

Ciphertext en sortie

Opaque · Illisible

Le client détient la clé maître. Toujours.

Le serveur garde des conteneurs opaques. Jamais leur contenu.

Zero-knowledge by design. Liée au matériel. BYOK sur la feuille de route.

La porte du coffre s'ouvre uniquement vers le client. Même un opérateur de serveur entièrement compromis ne peut dériver le plaintext — la clé de déballage n'existe que dans les mains du client et à l'intérieur de frontières liées au matériel.

Identité liée au matériel

Une confiance enracinée dans le matériel, pas des promesses d'opérateur

Chaque clé d'identité d'appareil est liée au matériel — Android StrongBox ou Secure Enclave d'Apple — et appairée via le Trust-On-First-Use, le même modèle de premier contact qu'utilisent Signal et WhatsApp. Les cérémonies complètes d'attestation HSM par opération, vérifiables de manière indépendante par le client, figurent sur notre feuille de route vers le FIPS 140-3 Level 2.

Clés d'identité adossées au matériel (StrongBox / Secure Enclave) — disponibles dès aujourd'hui
Attestations signées par opération — feuille de route
Cérémonies administratives à quorum — feuille de route

BYOK · Key Wrapping (feuille de route)

Bring Your Own Key — bientôt sur le Sovereign Server

Pour le déploiement Sovereign Server, les clients généreront leur propre clé maître et envelopperont (wrap) nos clés de chiffrement de données avec elle, de sorte qu'aucun opérateur BCrypto ne puisse produire de plaintext sans un unwrap actif côté client. Il s'agit d'un élément actif de notre feuille de route, pas encore disponible.

Protocoles de wrapping compatibles PKCS#11 / KMIP — prévus
Wrapping hybride post-quantique (ML-KEM + AES-256-GCM) — prévu
Révocation client conçue pour être immédiate et côté serveur

Garde Zero-Knowledge

La porte du coffre s'ouvre vers l'extérieur, jamais vers l'intérieur

Des conteneurs chiffrés entrent dans le KMS. Des conteneurs chiffrés sortent du KMS. Rien à l'intérieur du serveur ne peut en dériver le plaintext. Notre control plane autorise le mouvement des conteneurs et la politique d'accès ; le data plane ne voit jamais les clés en clair. Les clés de session sont éphémères et liées au matériel.

Architecture zero-knowledge: compromission du serveur ≠ compromission des données
Protocole de session forward-secret avec échange DH éphémère
Pas de backdoor, pas de master-recovery, pas de surface d'escrow

Sigsum Key Transparency (feuille de route)

Des clés d'identité en route vers un log public vérifiable

Nous travaillons à la mise en place d'un log de transparence Sigsum — sur le modèle de la Certificate Transparency du web — afin que tout client puisse auditer le log et détecter un serveur tentant d'injecter une clé malveillante dans une conversation. Aujourd'hui, la confiance dans les identités repose sur l'appairage Trust-On-First-Use et la vérification d'empreinte out-of-band ; le log public de transparence figure sur notre feuille de route, pas encore en production.

Log append-only vérifiable des clés publiques d'identité — feuille de route
Les clients détecteraient les substitutions de clés indépendamment du serveur — feuille de route
Appairage d'identité Trust-On-First-Use — disponible dès aujourd'hui

Modèle de confiance

TOFU aujourd'hui. Niveaux INTRODUCED et VERIFIED sur la feuille de route.

La confiance envers un contact n'est pas binaire. Aujourd'hui, Q-Audion utilise le Trust-On-First-Use (TOFU) — le même modèle de premier contact qu'utilisent Signal et WhatsApp — affiché dans l'UI pour chaque appel. Deux niveaux de confiance supplémentaires figurent sur notre feuille de route : INTRODUCED (recommandé par un contact déjà de confiance) et VERIFIED (correspondance d'empreinte out-of-band), conçus pour que le protocole se dégrade de manière contrôlée même en cas de compromission partielle.

TOFU — clé observée, affichée dans l'UI comme non vérifiée — disponible dès aujourd'hui
INTRODUCED — recommandé par un contact de confiance — feuille de route
VERIFIED — correspondance d'empreinte out-of-band — feuille de route

Examinez le threat model. Auditez la frontière.

Les équipes d'ingénierie et les évaluateurs achats peuvent demander le technical brief complet du KMS, incluant notre modèle actuel d'identité liée au matériel et la feuille de route BYOK/Sigsum.

Demander le technical brief du KMS