Rimuovere qualcuno da un gruppo cifrato dovrebbe impedirgli di ricevere i segreti necessari per i futuri messaggi protetti. Modificare soltanto l’elenco dei membri non basta se i mittenti rimasti continuano a usare materiale crittografico che l’ex membro già conosce.
La transizione, inoltre, non è istantanea su tutta una rete inaffidabile. Un’architettura di gruppo sicura deve definire a quale stato di appartenenza corrisponde un messaggio e cosa fa un mittente prima di aver elaborato una rimozione.
I messaggi passati e futuri sono problemi differenti
Un ex membro può conservare messaggi, file e chiavi ricevuti quando era autorizzato. La rimozione non può fargli dimenticare la cronologia né cancellare i suoi screenshot.
L’obiettivo raggiungibile è escluderlo dal nuovo stato crittografico dopo che la rimozione ha effetto. Analogamente, aggiungere qualcuno solleva una domanda distinta: se riceva accesso alla vecchia cronologia. Prodotti e protocolli usano termini come forward secrecy in contesti diversi, quindi una descrizione semplice della regola di accesso prevista è spesso più chiara di un’etichetta ambigua.
Perché i gruppi con chiavi del mittente richiedono uno stato nuovo
In un’architettura con chiavi del mittente, ogni partecipante può cifrare i normali messaggi di gruppo con una catena condivisa con i destinatari consentiti. Questo può evitare di cifrare separatamente l’intero contenuto per ogni destinatario a ogni invio.
Dopo una rimozione, l’ex membro potrebbe ancora possedere la vecchia catena. I mittenti rimasti hanno quindi bisogno di uno stato sostitutivo che non venga distribuito al membro escluso, e i client di un contesto di appartenenza concordato per utilizzarlo. La rotazione deve coprire i mittenti e i dispositivi interessati; modificare un solo indicatore lato server non basta.
Il protocollo esatto conta. MLS, specificato nella RFC 9420, gestisce la rimozione attraverso un cambio di epoca confermato che fornisce nuova entropia ai membri rimasti. È un esempio di transizione di stato definita, non un’affermazione che Livara implementi MLS.
Cosa documenta Livara per LGS1
La pagina sulla sicurezza di Livara descrive una catena del mittente firmata per ciascun mittente, con chiavi distribuite tramite sessioni LVR1 a coppie. Dichiara che vengono create e distribuite nuove chiavi del mittente quando cambia la composizione del gruppo.
Questo sostiene un’affermazione sull’architettura pubblicata di rinnovo delle chiavi. Non stabilisce un tempo misurato di «revoca istantanea» né dimostra che ogni condizione di competizione, scenario con dispositivi offline e nuovo tentativo sia gestito correttamente. Per questo servono analisi dell’implementazione e test.
Anche i controlli di appartenenza lato server e l’esclusione crittografica hanno compiti diversi. Il servizio può negare consegna o accesso, mentre la crittografia dovrebbe impedire a una parte esclusa, in possesso di una copia del successivo testo cifrato, di aprirla senza i nuovi segreti.
Un piano utile per testare la rimozione
In un gruppo di test autorizzato, verifica questi scenari con messaggi non sensibili:
| Scenario | Domanda da chiarire |
|---|---|
| Un membro viene rimosso mentre tutti sono online | Qual è il primo messaggio nel nuovo stato di appartenenza? |
| Un mittente rimasto è offline | Deve aggiornare appartenenza e chiavi prima di inviare di nuovo? |
| Il membro rimosso si riconnette in seguito | Può ottenere nuove distribuzioni delle chiavi del mittente o solo vecchi contenuti a cui era autorizzato? |
| Cambiano più membri contemporaneamente | Tutti i dispositivi rimasti convergono sullo stesso stato? |
| Si ritenta l’invio di un vecchio messaggio | Viene preservata l’epoca originale invece di etichettarlo erroneamente come nuovo contenuto? |
Un test limitato all’interfaccia può confermare il comportamento visibile, ma da solo non può dimostrare l’esclusione crittografica. Una valutazione rigorosa deve esaminare quali chiavi e testi cifrati possa ottenere un dispositivo di test escluso.
Cosa devono ricordare gli amministratori
Rimuovi i partecipanti non necessari, verifica i membri rimasti ed evita di inviare nuovo materiale sensibile finché l’applicazione non ha elaborato la modifica. Se un partecipante attuale inoltra deliberatamente un contenuto, il rinnovo delle chiavi del gruppo non può impedirne la divulgazione.
Per impieghi particolarmente sensibili, chiedi al fornitore le regole precise di rimozione, il comportamento della revoca dei dispositivi e le prove dei test. La promessa importante è un confine ben definito per i messaggi futuri, non un’affermazione priva di fondamento secondo cui un pulsante di rimozione distrugga ogni copia passata.
