Att ta bort någon från en krypterad grupp bör hindra personen från att få de hemligheter som behövs för framtida skyddade meddelanden. Att bara ändra medlemslistan åstadkommer inte detta om de kvarvarande avsändarna fortsätter använda nyckelmaterial som den tidigare medlemmen redan känner till.
Övergången sker inte heller omedelbart i ett opålitligt nätverk. En säker gruppdesign måste definiera vilket medlemstillstånd ett meddelande tillhör och vad en avsändare gör innan den har behandlat en borttagning.
Tidigare och framtida meddelanden är olika problem
En tidigare medlem kan behålla meddelanden, filer och nycklar som mottogs medan personen var behörig. Borttagning kan inte få personen att glömma historiken eller radera personens skärmbilder.
Det möjliga målet är att utesluta personen från nytt kryptografiskt tillstånd efter att borttagningen har trätt i kraft. Att lägga till någon väcker på liknande sätt en separat fråga: om personen får tillgång till gammal historik. Produkter och protokoll använder termer som forward secrecy i olika sammanhang, så en enkel beskrivning av den avsedda åtkomstregeln är ofta tydligare än en tvetydig etikett.
Varför grupper med avsändarnycklar behöver nytt tillstånd
I en design med avsändarnycklar kan varje deltagare kryptera vanliga gruppmeddelanden med en kedja som delas med tillåtna mottagare. Det kan undvika att hela innehållet måste krypteras separat för varje mottagare vid varje sändning.
Efter en borttagning kan den tidigare medlemmen fortfarande ha den gamla kedjan. Kvarvarande avsändare behöver därför ett ersättande tillstånd som inte delas med den uteslutna medlemmen, och klienterna behöver ett överenskommet medlemskontext för att använda det. Rotationen måste omfatta relevanta avsändare och enheter; att ändra en enda flagga på servern räcker inte.
Det exakta protokollet spelar roll. MLS, specificerat i RFC 9420, hanterar borttagning genom ett fastställt epokbyte som tillför ny entropi till de kvarvarande medlemmarna. Det är ett exempel på en definierad tillståndsövergång, inte ett påstående om att Livara implementerar MLS.
Vad Livara dokumenterar för LGS1
Livaras säkerhetssida beskriver en signerad avsändarkedja per avsändare, med avsändarnycklar som distribueras genom parvisa LVR1-sessioner. Där anges att nya avsändarnycklar skapas och distribueras när medlemskapet förändras.
Det stöder ett påstående om den publicerade designen för nyckelbyte. Det fastställer inte en uppmätt tid för ”omedelbar återkallelse” och bevisar inte att varje kapplöpning, offline-scenario och återförsök hanteras korrekt. Det kräver implementationsanalys och testning.
Medlemskontroller på serversidan och kryptografisk uteslutning har också olika uppgifter. Tjänsten kan neka leverans eller åtkomst, medan krypteringen bör hindra en utesluten part som har en kopia av senare chiffertext från att öppna den utan de nya hemligheterna.
En användbar testplan för borttagning
Kontrollera dessa scenarier i en godkänd testgrupp med icke-känsliga meddelanden:
| Scenario | Fråga att besvara |
|---|---|
| En medlem tas bort när alla är online | Vilket meddelande är det första under det nya medlemstillståndet? |
| En kvarvarande avsändare är offline | Måste den uppdatera medlemskap och nycklar innan den skickar igen? |
| Den borttagna medlemmen ansluter senare | Kan den få nya avsändarnyckeldistributioner eller bara gammalt behörigt innehåll? |
| Flera medlemsändringar sker samtidigt | Når alla kvarvarande enheter samma tillstånd? |
| Ett gammalt meddelande skickas om | Bevaras dess ursprungliga epok i stället för att det felmärks som nytt innehåll? |
Ett test av enbart gränssnittet kan bekräfta synligt beteende, men kan inte ensamt bevisa kryptografisk uteslutning. En rigorös bedömning måste undersöka vilka nycklar och vilken chiffertext en utesluten testenhet kan få.
Vad administratörer bör komma ihåg
Ta bort onödiga deltagare, granska kvarvarande medlemskap och undvik att skicka nytt känsligt material tills appen har behandlat ändringen. Om en nuvarande deltagare avsiktligt vidarebefordrar innehåll kan gruppens nyckelbyte inte förhindra röjandet.
För mycket känslig användning bör du be leverantören om reglerna för borttagning, beteendet vid enhetsåterkallelse och testbelägg. Det viktiga löftet är en väldefinierad gräns för framtida meddelanden, inte ett obestyrkt påstående om att en borttagningsknapp förstör varje tidigare kopia.
