Per valutare la sicurezza di una chiamata, non chiedere solo «È cifrata?», ma dove termina la cifratura e che cosa cambia con la registrazione.
La cifratura della chat, da sola, non dimostra che audio, video, condivisione dello schermo o registrazioni delle chiamate abbiano la stessa protezione. Per valutare una chiamata, bisogna chiedere fino a dove i flussi multimediali rimangono cifrati, chi possiede le chiavi e che cosa cambia quando si attivano funzioni come la registrazione.
Questa guida scompone le affermazioni sulla sicurezza in livelli che si possono esaminare; il nome di un protocollo o l’icona di un lucchetto non sostituisce le risposte a queste domande.
Tre percorsi diversi nella stessa applicazione
| Percorso | Esempi di dati | Domanda di sicurezza |
|---|---|---|
| Messaggi conservati | Testo, foto, file e note vocali | Chi può leggere le copie sui dispositivi, sui server e nei backup? |
| Flussi multimediali in diretta | Audio del microfono, video e condivisione dello schermo | La cifratura termina sul dispositivo dell’interlocutore o su un server intermedio? |
| Segnalazione | Invito alla chiamata, risposta e informazioni per coordinare la connessione | Chi può modificare i messaggi di controllo o l’identità del destinatario? |
Una nota vocale inviata in chat è un file; una chiamata vocale è un flusso in diretta. Un prodotto può usare chiavi e meccanismi diversi per i due casi. Anche una buona qualità audio o la mancata consegna di un messaggio di testo, da sole, non dicono nulla sulla sicurezza dell’altro percorso.
Che cosa ci dice DTLS-SRTP?
In WebRTC, SRTP protegge il flusso multimediale e DTLS-SRTP offre un modo per stabilire il relativo materiale crittografico per le chiavi. RFC 5764 spiega il meccanismo DTLS-SRTP, mentre RFC 3711 descrive la protezione dei pacchetti multimediali.
Tuttavia, «usiamo WebRTC» non chiarisce, da solo, se il server di conferenza decifri i flussi multimediali. Devono essere specificati i punti terminali della cifratura e la loro autenticazione. La connessione tra utente e server può essere cifrata, mentre il server accede ai contenuti decifrati per elaborarli o registrarli. Questo non equivale alla cifratura end-to-end (E2EE) tra i partecipanti.
L’architettura di sicurezza di WebRTC in RFC 8827 mostra inoltre che, accanto alla protezione dei flussi multimediali, contano la fiducia nell’applicazione web, il percorso di segnalazione e l’identità dell’interlocutore. Il fatto che i pacchetti siano cifrati non significa che ogni componente del prodotto sia affidabile.
Perché la segnalazione va valutata separatamente?
La segnalazione coordina chi chiama chi e come si stabilisce la connessione. Anche se un’applicazione protegge i messaggi di controllo, occorre comunque esaminare come questa protezione sia collegata all’identità reale dei partecipanti e alle chiavi dei flussi multimediali.
Tre domande bastano per orientare la lettura della documentazione:
- L’invito, la risposta e le informazioni sulle chiavi sono protetti dalle modifiche?
- Come fa l’utente a sapere che la chiave appartiene al contatto desiderato?
- Quale avviso viene mostrato quando cambia una chiave o un dispositivo?
Le informazioni di instradamento, gli orari e i partecipanti alla chiamata possono essere noti al servizio anche in una chiamata E2EE. L’articolo I metadati della messaggistica spiegati approfondisce questa distinzione.
Registrare una chiamata introduce un nuovo confine di sicurezza
«Chiamata cifrata» non risponde completamente alle domande sulla copia registrata. Un partecipante può acquisire audio o video con il proprio dispositivo. Anche la registrazione lato server va documentata separatamente: il server ottiene accesso ai flussi multimediali in chiaro per registrarli? Chi conserva il file? Quando viene eliminato?
Se l’attivazione della registrazione cambia la modalità di sicurezza, la modifica deve essere chiara ai partecipanti. Prima di una conversazione sensibile, verifica lo stato della registrazione e il consenso di tutti; l’indicatore di registrazione integrato spento non garantisce che nessuno stia registrando con un altro dispositivo.
Come leggere la documentazione attuale di Livara?
La pagina sulla sicurezza di Livara descrive le chiamate dirette e di gruppo come E2EE, ma prevede un’eccezione per la registrazione facoltativa lato server: nella modalità REC visibile, la protezione della chiamata passa alla cifratura di trasporto. Questa è un’affermazione della documentazione del prodotto, non il risultato di un test o di un audit indipendente svolto per questo articolo.
La limitazione di tutte le chiamate di gruppo a «da 2 a 6 persone su Android» nel vecchio testo non è coerente con la documentazione attuale e non viene usata come base di questa guida. Per la capacità, la piattaforma e la versione che ti interessano, consulta la guida aggiornata e verifica il comportamento effettivo dell’applicazione; questo articolo non presenta un test di capacità.
Allo stesso modo, citare algoritmi della chat come ML-KEM non dimostra, da solo, che lo stesso algoritmo sia usato per i flussi multimediali delle chiamate. Affermare che le chiamate abbiano una protezione post-quantistica richiede prove specifiche sul percorso multimediale e sull’autenticazione. Leggi il modello di minaccia di Livara insieme alla pagina delle funzionalità, non al posto di un test indipendente.
Una breve checklist prima di confrontare due servizi
Per ogni «sì», annota anche la versione e la fonte:
- Le chiamate tra due persone, quelle di gruppo e la condivisione dello schermo sono descritte separatamente?
- È chiaro se il server si limita a inoltrare i pacchetti o può decifrare i flussi multimediali?
- È possibile verificare l’identità e la chiave di un partecipante?
- I cambi di dispositivo, l’arrivo di nuovi partecipanti e l’attivazione della registrazione sono visibili?
- Il percorso della chiamata è uguale sul web e nell’applicazione, oppure ci sono differenze?
- È spiegata la conservazione dei file registrati e dei metadati?
- Le prove dei test o degli audit riguardano la stessa versione e funzionalità?
Se la documentazione non risponde a una domanda, scrivi «non noto»; l’assenza di una risposta non dimostra né la sicurezza né la presenza di intercettazioni.
Domande frequenti
Una chiamata E2EE impedisce all’interlocutore di registrarla?
No. Il destinatario autorizzato ha accesso al contenuto in chiaro e può registrarlo tramite software o un altro dispositivo.
La cifratura di trasporto è un male?
La cifratura di trasporto offre una protezione importante contro le intercettazioni lungo il percorso di trasmissione. La differenza è che il servizio che funge da punto terminale può accedere al contenuto decifrato; questo non va chiamato E2EE tra utenti.
La cifratura post-quantistica nella chat rende post-quantistiche anche le chiamate?
No. L’affermazione deve riferirsi allo stesso livello, agli stessi algoritmi e alla stessa versione dell’implementazione. Valuta chat e chiamate separatamente.
