La sicurezza è architettura, non un ripensamento.
Q-Audion è cifrato end-to-end fin dalla prima riga di codice, con uno scambio di chiavi ibrido classico e post-quantistico, chiavi ancorate all'hardware su ogni piattaforma, e un processo di ingegneria misurato su standard di sicurezza pubblicati e scritti da terzi.
Uno scambio di chiavi ibrido pensato per i prossimi vent'anni, non solo per oggi.
Ogni sessione è protetta da due problemi crittografici indipendenti contemporaneamente. Comprometterla — anche con un futuro computer quantistico — significa romperli entrambi.
Scambio di chiavi post-quantistico
ML-KEM-1024, il meccanismo di key encapsulation post-quantistico standardizzato dal NIST (FIPS 203), combinato con X25519 classico in una costruzione ibrida — la sicurezza non scende mai sotto quella già garantita da X25519 da solo.
FIPS 203 · Categoria 5Identità autenticata
Ogni dispositivo firma il proprio materiale di chiave con Ed25519 (RFC 8032). L'identità è verificabile end-to-end — anche di persona, tramite confronto del safety number e verifica NFC tap-to-verify.
Chiavi ancorate all'hardware
Il materiale di chiave privata viene generato e utilizzato dentro StrongBox su Android e la Secure Enclave su iOS ovunque il dispositivo lo supporti — il materiale di chiave non lascia mai quel confine hardware.
Sessioni a forward secrecy
Le chiavi di messaggi e chiamate avanzano continuamente in ratchet. Una chiave recuperata in un istante non espone le conversazioni precedenti né successive.
Pensato per lasciare meno tracce di te da esporre.
I fallimenti di privacy sono quasi sempre fallimenti di metadati. La nostra infrastruttura server è costruita per trattenere il minimo indispensabile su chi parla con chi.
Mittente sigillato
Le notifiche push trasportano un identificatore opaco e salted — mai un nome del mittente, un'anteprima del contenuto, o qualunque cosa una pipeline di notifica esterna al nostro controllo potrebbe leggere.
Allegati cifrati
Foto, note vocali e file sono sigillati con XChaCha20-Poly1305 prima ancora di lasciare il dispositivo, poi mantenuti sotto un secondo livello AES-256-GCM con chiave hardware per tutto il tempo in cui restano in cache su disco.
Effimero per scelta
I timer per messaggi e allegati a scomparsa sono applicati allo stesso modo su ogni piattaforma, con i dispositivi dei peer mantenuti sincronizzati.
Numeri di telefono, sotto hash
La contact discovery funziona a partire da un hash monodirezionale e salted del numero di telefono — mai il numero in chiaro — così le liste contatti restano illeggibili per il servizio che le confronta.
Le parti che non vedi mai, misurate sullo stesso standard.
Un sistema di messaggistica vale quanto la pipeline che lo costruisce e lo distribuisce. Ogni commit passa attraverso gli stessi gate automatizzati prima di raggiungere un dispositivo.
Certificate pinning, verificato di continuo
Ogni client fissa il certificato TLS del server — e un job automatico giornaliero verifica in modo indipendente che il certificato live corrisponda ancora a quello fissato, su ogni piattaforma, così un drift viene individuato lo stesso giorno.
Dipendenze fissate e verificate
Ogni libreria di terze parti è bloccata a una versione esatta, verificata via checksum. Una build non può essere unita con una dipendenza non fissata o non verificata — la pipeline la rifiuta automaticamente.
Scansione di sicurezza continua
Il codice sorgente di ogni client e del server passa attraverso scansioni di sicurezza automatizzate in modo continuativo, alla ricerca delle classi di vulnerabilità più rilevanti per un'applicazione crittografica in rete.
Segreti mai nel sorgente
Le credenziali di produzione vivono solo nell'ambiente runtime della macchina che ne ha bisogno, iniettate all'avvio del processo — mai committate, mai templatizzate in un file di configurazione nel repository.
Ci misuriamo sullo stesso metro che userebbe un auditor.
Invece di dichiarare una nostra definizione di "sicuro", teniamo il nostro processo di ingegneria ancorato a framework scritti e mantenuti dalla comunità di sicurezza — e ci rivalutiamo man mano che il prodotto evolve.
Il riferimento di settore per ciò che un'app mobile attenta alla sicurezza deve fare bene — dallo storage locale dei dati all'interazione con la piattaforma fino alla crittografia.
Applicato ai nostri servizi backend: autenticazione, gestione delle sessioni, controllo degli accessi e design delle API, verificati sulla stessa checklist usata dagli auditor indipendenti.
Guida come governiamo, identifichiamo, proteggiamo, rileviamo, rispondiamo e recuperiamo come organizzazione di ingegneria — non solo come è scritta una singola feature.
Come leggere questa sezione: sono self-assessment interni, condotti rispetto a framework pubblicati e aggiornati man mano che il codice cambia — non un certificato rilasciato da terzi. Dove esiste un badge formale con audit indipendente per un'affermazione che facciamo, indicheremo l'auditor e collegheremo direttamente la credenziale.
Contatto
Sarà pubblicata qui insieme al public key block prima della release 1.0 pubblica.
Aprire una draft security advisory nel tab Security del repository Q-Audion rilevante (GitHub private vulnerability reporting).
I nostri impegni
- Acknowledgement entro 48 ore lavorative dalla ricezione
- Triage e classificazione severità entro 5 giorni lavorativi
- Finestra di disclosure coordinata di 90 giorni di default, estesa solo con accordo del reporter quando una fix complessa lo richiede
- Credito pubblico nelle release notes salvo richiesta di anonimato
Bug bounty
Un programma bug bounty gestito sarà operativo prima della 1.0 pubblica. Nel frattempo offriamo ricompense in buona fede caso per caso per finding ad alto impatto.
Scope
- +Tutto il codice server Q-Audion (identità, gestione chiavi, trasporto, gruppi, prekey, file storage)
- +Tutti i client Q-Audion pubblicati su Android, iOS e Desktop (Windows / macOS / Linux quando rilasciato)
- +Design dei protocolli crittografici (handshake PQ, double ratchet post-quantistico, protezione dei metadati sul mittente, Sigsum Key Transparency)
- +Drift della wire spec che causa comportamenti cross-platform non sicuri
- −Problemi che richiedono accesso fisico a un dispositivo sbloccato
- −XSS self-inflicted senza attraversare un confine di fiducia
- −Versioni browser/OS obsolete fuori dalle finestre di supporto vendor
- −DDoS volumetrico senza logic flaw
- −Social engineering del personale Q-Audion
- −Report basati su output di scanner automatici senza proof-of-concept funzionante
Wire specification aperta
Il contratto cross-platform del protocollo è byte-identico fra tutti i client Q-Audion. La spec è mirrorata nei repository client e in quello server come commit gating per qualunque cambio wire. Revisori indipendenti possono leggerla prima di aprire una sessione — e le implementazioni di libreria (liboqs, BouncyCastle, @noble/post-quantum) sono cross-validate contro vettori KAT condivisi.
Build riproducibili (target 1.0)
Tutti gli artifact di release 1.0 (APK, IPA, installer Desktop) saranno firmati Sigstore. La riproducibilità indipendente dai sorgenti è criterio di go-release: chiunque può verificare che il binario distribuito corrisponda al sorgente pubblico.