Usunięcie kogoś z szyfrowanej grupy powinno uniemożliwić mu otrzymywanie sekretów potrzebnych do przyszłych chronionych wiadomości. Sama zmiana listy członków nie osiąga tego celu, jeśli pozostali nadawcy nadal używają materiału kluczowego, który były członek już zna.
Przejście nie jest też natychmiastowe w zawodnej sieci. Bezpieczny projekt grupy musi określać, do którego stanu członkostwa należy wiadomość i co robi nadawca, zanim przetworzy usunięcie.
Wiadomości przeszłe i przyszłe to różne problemy
Były członek może zachować wiadomości, pliki i klucze otrzymane, gdy był uprawniony. Usunięcie nie sprawi, że zapomni historię ani że znikną jego zrzuty ekranu.
Osiągalnym celem jest wykluczenie go z nowego stanu kryptograficznego po wejściu usunięcia w życie. Podobnie dodanie osoby rodzi osobne pytanie: czy otrzyma dostęp do starej historii. Produkty i protokoły stosują terminy takie jak forward secrecy w różnych kontekstach, dlatego jasny opis zamierzonej reguły dostępu jest często czytelniejszy niż niejednoznaczna etykieta.
Dlaczego grupy z kluczami nadawców potrzebują nowego stanu
W projekcie z kluczami nadawców każdy uczestnik może szyfrować zwykłe wiadomości grupowe za pomocą łańcucha współdzielonego z uprawnionymi odbiorcami. Pozwala to uniknąć osobnego szyfrowania pełnej treści dla każdego odbiorcy przy każdym wysłaniu.
Po usunięciu były członek może nadal posiadać stary łańcuch. Pozostali nadawcy potrzebują więc nowego stanu, który nie jest przekazywany wykluczonemu członkowi, a klienci potrzebują uzgodnionego kontekstu członkostwa, aby go używać. Rotacja musi obejmować odpowiednich nadawców i urządzenia; zmiana jednej flagi po stronie serwera nie wystarcza.
Znaczenie ma dokładny protokół. MLS, zdefiniowany w RFC 9420, obsługuje usunięcie przez zatwierdzoną zmianę epoki, która dostarcza nową entropię pozostałym członkom. To przykład zdefiniowanego przejścia stanu, a nie twierdzenie, że Livara implementuje MLS.
Co Livara dokumentuje dla LGS1
Strona bezpieczeństwa Livara opisuje jeden podpisany łańcuch nadawcy na każdego nadawcę, z kluczami nadawców rozsyłanymi przez sesje LVR1 między parami uczestników. Podaje, że nowe klucze nadawców są tworzone i rozsyłane przy zmianie członkostwa.
Uzasadnia to twierdzenie o opublikowanym projekcie wymiany kluczy. Nie ustala zmierzonego czasu „natychmiastowego odebrania dostępu” ani nie dowodzi poprawnego obsłużenia każdego wyścigu zdarzeń, scenariusza urządzenia offline i ponowienia. Wymaga to analizy implementacji i testów.
Kontrola członkostwa po stronie serwera i wykluczenie kryptograficzne mają też różne zadania. Usługa może odmówić dostarczenia lub dostępu, natomiast szyfrowanie powinno uniemożliwiać wykluczonej stronie posiadającej kopię późniejszego szyfrogramu jego odczytanie bez nowych sekretów.
Przydatny plan testowania usunięcia
W autoryzowanej grupie testowej sprawdź te scenariusze przy użyciu wiadomości bez wrażliwych danych:
| Scenariusz | Pytanie do rozstrzygnięcia |
|---|---|
| Członek zostaje usunięty, gdy wszyscy są online | Która wiadomość jest pierwszą w nowym stanie członkostwa? |
| Jeden z pozostałych nadawców jest offline | Czy przed ponownym wysłaniem musi odświeżyć członkostwo i klucze? |
| Usunięty członek łączy się później | Czy może otrzymać nowe klucze nadawców, czy tylko stare, wcześniej dozwolone treści? |
| Kilka zmian członkostwa następuje jednocześnie | Czy wszystkie pozostałe urządzenia osiągają ten sam stan? |
| Ponawiane jest wysłanie starej wiadomości | Czy zachowana jest jej pierwotna epoka, zamiast błędnego oznaczenia jako nowej treści? |
Test ograniczony do interfejsu może potwierdzić widoczne zachowanie, ale sam nie dowodzi wykluczenia kryptograficznego. Rzetelna ocena musi sprawdzić, jakie klucze i szyfrogramy może uzyskać wykluczone urządzenie testowe.
O czym powinni pamiętać administratorzy
Usuń niepotrzebnych uczestników, przejrzyj pozostałe członkostwo i nie wysyłaj nowych wrażliwych materiałów, dopóki aplikacja nie przetworzy zmiany. Jeśli obecny uczestnik celowo przekaże treść dalej, wymiana kluczy grupy nie zapobiegnie ujawnieniu.
Przy bardzo wrażliwych zastosowaniach poproś dostawcę o zasady usuwania członków, zachowanie przy odebraniu uprawnień urządzeniu i dowody testowe. Ważną obietnicą jest jasno zdefiniowana granica dla przyszłych wiadomości, a nie niepoparte twierdzenie, że przycisk usunięcia niszczy wszystkie przeszłe kopie.
