Q-Audion GEN-1: progettare il primo headset PQC europeo

La voce resta il canale di comunicazione enterprise più critico operativamente e più trascurato crittograficamente. Dirigenti, avvocati, team M&A e negoziatori governativi conducono conversazioni il cui valore strategico supera ampiamente le protezioni tecniche in essere. Lo stack dominante, headset consumer accoppiati via BLE a uno smartphone su cui gira un soft-client, si basa su assunzioni che nessun architetto di sicurezza accetterebbe per un altro asset di tier-1: chiavi in software mutabile, side-channel attraverso l'OS host e uno strato di trasporto che sarà crittanaliticamente violato entro la vita lavorativa della maggior parte degli attuali dirigenti [1].

Q-Audion GEN-1 è fra i primi prodotti di una categoria deliberatamente ristretta: un endpoint voce hardware-rooted, post-quantum, che non si fida del telefono, del laptop o del sistema operativo con cui dialoga. Ogni operazione crittografica avviene all'interno di un Secure Element tamper-resistant. Ogni byte di audio in chiaro esiste solo all'interno di un dominio DSP isolato. Il dispositivo host è trattato come una rete ostile, non come un peer.

Abbiamo avviato il programma GEN-1 con un unico impegno architetturale: se il progetto avesse imposto un compromesso fra forza crittografica, resistenza ai side-channel ed ergonomia operativa, sarebbe stata l'ergonomia a perdere. Il risultato è un dispositivo più pesante di un headset consumer, che assorbe più corrente di un true-wireless e che richiede qualche secondo per il primo pairing. Ognuno di questi numeri è la conseguenza deliberata del modello di minaccia.

Q-Audion GEN-1 deve proteggere la riservatezza e l'integrità di una conversazione vocale contro un avversario che controlli il dispositivo host (laptop, telefono, gateway dell'headset), possa osservare e modificare il traffico radio, possa montare attacchi side-channel fisici contro il dispositivo per brevi finestre temporali e possa avere accesso a un calcolatore quantistico tollerante ai guasti in qualche momento durante la vita operativa del dato protetto. Si presume che l'avversario non disponga di custodia fisica continuativa di più ore con strumentazione da laboratorio: quello è il confine in cui il modello di minaccia rinvia alla policy di sicurezza fisica.

Ogni scelta progettuale che segue è la traduzione diretta di una o più clausole di questo modello di minaccia in decisioni hardware, firmware o di protocollo. Non esiste alcun altro principio guida.

Internamente il dispositivo è suddiviso in due domini elettricamente e logicamente isolati. L'Application Domain gestisce BLE, l'interfaccia utente, la gestione della batteria e il link radio verso l'host accoppiato. Esegue un RTOS vincolato su un MCU general-purpose di classe Cortex fornito da un produttore europeo di silicio sicuro. Questo dominio è trattato come semi-fidato: può guastarsi, essere riprogrammato o compromesso senza mettere in pericolo lo stato crittografico.

Il Secure Domain è costruito attorno a un Secure Element certificato con acceleratore PQC integrato e DSP audio dedicato. Questo dominio conserva la chiave di identità di lungo termine, esegue tutte le operazioni ML-KEM-1024 [1] e ML-DSA-87 [2] ed è l'unico luogo in cui esistono campioni audio decifrati. I due domini comunicano su un canale di comando hardware-gated a formato fisso, senza accesso diretto in memoria dal lato Application al lato Secure. Non c'è bus condiviso, non c'è finestra DMA, non c'è percorso di debug che attraversi il confine nel firmware di produzione.

Questa separazione è la singola scelta architetturale più costosa del dispositivo. Raddoppia all'incirca il costo del silicio rispetto a un design a singolo MCU e rende considerevolmente più complessi gli aggiornamenti firmware. Rende anche irrilevante l'intera classe di compromissione lato host: anche con pieno controllo dell'Application Domain e dell'host accoppiato, un attaccante non può estrarre una chiave, decifrare un frame memorizzato o forgiare una firma.

L'identità è stabilita in fase di provisioning generando una coppia di chiavi ML-DSA-87 interamente all'interno del Secure Element [2]. La chiave privata non lascia mai il SE ed è legata all'identificatore unclonable univoco del dispositivo. La chiave pubblica è firmata dalla CA di provisioning BCrypto, producendo un certificato di dispositivo che viene poi presentato durante il pairing. Non esiste, né nel firmware né nella strumentazione di fabbrica, un percorso per esportare la chiave privata di firma.

Lo stabilimento di sessione utilizza ML-KEM-1024 ibrido con X25519 [7]. Quando due dispositivi Q-Audion stabiliscono una chiamata, ciascuno genera una coppia di chiavi effimere da entrambi gli schemi, scambia le chiavi pubbliche su un canale autenticato (firmato con l'identità ML-DSA-87 di lungo termine) e deriva una chiave di sessione a 256 bit tramite HKDF-SHA384 sulla concatenazione dei due segreti condivisi, con prefissi di lunghezza espliciti e separazione di dominio. Le componenti classica e post-quantistica sono indipendenti: la compromissione di una sola, isolatamente, non indebolisce la chiave di sessione risultante.

Il trasporto audio utilizza AES-GCM 256 con un nonce a 96 bit costruito da un sale per-sessione e da un contatore di frame a 64 bit strettamente monotono. La dimensione del frame è 20 ms di Opus a 16 kHz, producendo ciphertext di circa 320 byte. La protezione dal replay è applicata da una finestra scorrevole di 1024 frame. I frame fuori sequenza all'interno della finestra sono accettati; quelli al di fuori sono scartati senza ulteriore elaborazione. Questo progetto tollera il jitter intrinseco al BLE senza indebolire le difese dal replay.

La scelta del microfono raramente è trattata come una decisione di sicurezza, ma per un dispositivo che dichiara di proteggere una conversazione da un avversario remoto è una delle più conseguenti. Q-Audion GEN-1 utilizza un array MEMS a tre elementi con beamforming orientato verso la bocca dell'utente, posizionato per massimizzare la reiezione delle sorgenti ambientali oltre i 40 centimetri circa. Il beamformer gira all'interno del DSP del Secure Domain, su campioni PDM grezzi che non attraversano mai il confine di dominio in forma di chiaro.

L'obiettivo acustico è rendere sostanzialmente più difficile l'intercettazione remota tramite microfono laser, un attacco di beamforming parametrico da un dispositivo vicino o un microfono dell'host compromesso. Nessuna di queste minacce può essere eliminata dal solo headset, ma ciascuna può vedere aumentato il proprio costo. L'array MEMS riduce di 20-30 dB il segnale disponibile a un attaccante fuori asse rispetto a un microfono omnidirezionale a elemento singolo, traducendosi in un cambiamento significativo dell'inviluppo di ingaggio di uno scenario tipico di intercettazione.

Lo stesso percorso DSP include un mute hardware che interrompe fisicamente il front-end analogico dell'array microfonico. Il mute solo software, schema dominante negli headset consumer, è inaccettabile nel nostro modello di minaccia: un firmware compromesso può ignorarlo. Il mute hardware è esposto tramite un pulsante dedicato il cui stato è rilevato indipendentemente da entrambi i domini; un mismatch innesca uno shutdown fail-secure del percorso audio.

Tutte le primitive PQC sono implementate all'interno del Secure Element usando una libreria aritmetica constant-time certificata rispetto ai profili di resistenza ai side-channel rilevanti. In particolare, il percorso di decapsulamento ML-KEM è auditato rispetto ai canali di timing, potenza ed emanazione elettromagnetica, e l'implementazione è mascherata al primo ordine contro la differential power analysis [6]. Ci affidiamo alla certificazione del fornitore del Secure Element invece di sviluppare un'implementazione propria: è uno dei pochi punti del progetto in cui IP commerciale certificato è strettamente più sicuro di un lavoro su misura.

La resistenza fisica al tampering è mirata al livello EAL 4+, in linea con il profilo di certificazione di Secure Element commerciali comparabili [5]. Il Secure Domain è incapsulato sotto un composto di potting tamper-evident e lo chassis del dispositivo include tracce di intrusion detection che innescano lo zeroising di tutto il materiale di sessione e di identità in caso di violazione meccanica. La resistenza al cold-boot è fornita da un keystore volatile a perdita di carica per il materiale effimero e da uno storage cifrato per il materiale di lungo termine.

Il firmware è firmato con una chiave root ML-DSA-87 tenuta offline presso BCrypto [2]. Gli aggiornamenti sono recapitati over-the-air attraverso l'host accoppiato ma verificati all'interno del Secure Domain prima del commit nel boot bank. Un contatore di rollback, ancorato in fuse one-time-programmable, impedisce il downgrade a una precedente versione vulnerabile. Il percorso di boot impone un measured boot di entrambi i domini, con la misura del Secure Domain che estende quella dell'Application Domain in modo che una compromissione dell'uno o dell'altro sia rilevabile al successivo riavvio. Il modulo crittografico è mirato a FIPS 140-3 Level 3 [3].

Eseguire scambio di chiave ML-KEM-1024 e cifratura AES-GCM 256 continua all'interno del budget di batteria di un headset è fattibile solo perché l'acceleratore PQC all'interno del Secure Element esegue ciascun handshake in decine di millisecondi a potenza media sub-milliwatt. Un'implementazione software ingenua su un Cortex-M general-purpose brucerebbe alcuni joule per handshake e dominerebbe il budget di batteria. L'acceleratore hardware è il componente abilitante.

L'autonomia realistica in conversazione su singola carica è di circa 8 ore, ovvero circa 14 giorni di standby in idle con i beacon di paging attivi. Questi numeri erano obiettivi, non vincoli: abbiamo dimensionato la batteria per raggiungerli dopo aver caratterizzato il carico crittografico, non riducendo la sicurezza per adattarsi a una batteria scelta a priori. Il risultato è un dispositivo più pesante degli headset consumer tipici, compromesso che riteniamo accettabile dato il modello di minaccia.

Il raggio BLE è intenzionalmente limitato a circa 5 metri alla potenza di trasmissione predefinita, ben al di sotto del massimo BLE 5.x. La ragione è che qualunque necessità di operare a distanze maggiori implica un host accoppiato che non è sotto il controllo fisico immediato dell'utente, condizione che è di per sé un problema di sicurezza che nessuna contromisura a livello di trasporto può risolvere. Il design spinge l'utente verso una postura di deployment in cui il dispositivo host è addosso alla persona, non dall'altra parte della stanza.

Q-Audion GEN-1 deliberatamente non include biometria vocale, soppressione AI del rumore o alcuna elaborazione lato cloud. Ognuna di queste opzioni è stata valutata e respinta. La biometria vocale aggiunge una superficie d'attacco (estrazione di template, replay con audio sintetico) che eccede il beneficio di sicurezza che fornisce. La soppressione AI del rumore alla qualità attesa oggi richiederebbe pesi di modello che non possiamo auditare integralmente e computazione che non possiamo confinare al Secure Domain. L'elaborazione cloud di qualsiasi tipo è incompatibile con il modello di minaccia.

Inoltre non spediamo un servizio di directory, un indicatore di presenza o alcun metadato out-of-band su chi è online. Il dispositivo esegue un pairing point-to-point con conferma esplicita dell'utente su entrambi i lati, e una chiamata si connette o fallisce senza far trapelare nemmeno il fatto che sia stato fatto un tentativo a nessuno al di fuori dei due endpoint. È attrito; è anche l'unica risposta onesta a un modello in cui la rete è l'avversario.

GEN-2, attualmente in fase di architettura preliminare, rivedrà alcune di queste scelte alla luce del silicio NPU on-device dedicato emerso recentemente. Per GEN-1, tuttavia, il design è intenzionalmente minimale. Fa una cosa sola: rende una chiamata voce fra due utenti consenzienti che un avversario in possesso di ciphertext oggi non potrà leggere nella seconda metà degli anni 2030.

Q-Audion GEN-1 non è posizionato contro gli headset consumer e non dovrebbe essere confrontato con essi sulle dimensioni su cui i prodotti consumer ottimizzano. È una categoria a sé: un endpoint voce indossabile ingegnerizzato per il modello di minaccia della protezione esecutiva, delle comunicazioni sovrane e delle trattative ad alta posta. Il giusto acquirente lo valuta rispetto al costo della conversazione che protegge, non rispetto al costo di hardware audio consumer comparabile.

Se la Sua organizzazione ha traffico voce il cui contenuto Le arrecherebbe danno materiale se letto da un avversario fra cinque o dieci anni, la risposta convenzionale (headset consumer, soft-client, TLS) non è più adeguata. Q-Audion GEN-1 è una risposta difendibile. Le scelte architetturali alla sua base, la separazione a due domini, il Secure Element certificato, l'ibrido PQC [7][8], il mute hardware, sono il vocabolario ingegneristico che dovrebbe attendersi da qualsiasi vendor che faccia affermazioni credibili in questo spazio. Il CRA [4] renderà, da dicembre 2027, molte di queste scelte un floor di legge anziché un differenziatore.