Administrator serwera a dostęp do danych: zmiana systemowa w UseCrypt Safe

Firma nie musi przekazywać dostawcy samodzielnej zdolności odczytu dokumentów tylko dlatego, że kupuje od niego przestrzeń dyskową. Jeżeli ten sam system przechowuje dokument i może samodzielnie odzyskać jego klucz, przejęcie odpowiednio uprzywilejowanego dostępu może oznaczać przejęcie treści. Szyfrowanie dysku i szyfrowanie połączenia nie usuwają automatycznie tej zależności. Chronią inne miejsca procesu.

UseCrypt Safe opisywał inną organizację odczytu: plik szyfrowano na urządzeniu, a operacja potrzebna do odzyskania jego klucza wymagała współpracy klienta i serwera. Administrator samego serwera nie miał z tego tytułu pełnej zdolności odszyfrowania dokumentu. To projekt ograniczenia możliwości posiadanym materiałem kryptograficznym, a nie deklaracja dobrych intencji operatora. Analizujemy specyfikację Safe 1.3 z 8 października 2018, nie aktualny audyt produktu i nie mechanizmy Messengera.

Nie zakładamy, że każda osoba w IT czyta pocztę ani że każda chmura umożliwia operatorowi odczyt. Badamy konkretną zależność: kto posiada zasoby wystarczające do przejścia od kopii danych do czytelnego dokumentu? Matematyczne rozwinięcie znajduje się w analizie HVKM, RSA i kapsułek kluczy.

1. Szyfrowanie nie jest jedną właściwością całego systemu

Projekt przejęcia spółki powstaje na laptopie, trafia do usługi plikowej, zostaje skopiowany do backupu i udostępniony doradcy. Każdy etap tworzy inny punkt kontroli. Szyfrowanie transmisji chroni odcinek połączenia; nie przesądza, w jakiej postaci aplikacja końcowa zapisze dokument. Szyfrowanie nośnika chroni określony scenariusz dostępu do nośnika; nie przesądza, co otrzyma proces mający uprawnienia do odczytu.

TLS zabezpiecza komunikację pomiędzy swoimi stronami. Jeżeli stroną jest serwer aplikacyjny, ten serwer otrzymuje dane aplikacyjne. Nie jest to porażka TLS, lecz jego zakres. Nie dowodzi pozorności szyfrowania end-to-end. RFC 8446, specyfikacja TLS 1.3, opisuje ochronę kanału, nie cały model przechowywania aplikacji.

Oddzielamy zatem ochronę kanału, nośnika, treści i klucza. Zdanie „dane są zaszyfrowane” rozpoczyna analizę, a nie ją kończy. Specyfikacja powinna wskazywać miejsce szyfrowania, miejsce odszyfrowania i stronę zdolną uruchomić te operacje.

2. Konto uprzywilejowane: zdolność, nie tylko intencja

Administrator ma kopię bazy i kontroluje usługę zwracającą pełny klucz dokumentu. Rozdzielenie obu zasobów na dwie maszyny niewiele daje, jeśli to samo konto administracyjne steruje obiema. Izolacja fizyczna nie oznacza automatycznie izolacji zaufania.

Zmieńmy założenie: administrator kontroluje szyfrogramy i komponent serwerowy, lecz nie posiada udziału klienta potrzebnego do zakończenia operacji prywatnej. Kopia środowiska serwerowego nie zawiera wtedy wszystkich elementów normalnej ścieżki odczytu. Ogranicza to skutki kompromitacji jednej domeny. Nie rozstrzyga ataków na generator kluczy, klienta, aktualizację oprogramowania ani recovery.

Precyzyjna teza brzmi: administrator samego serwera nie odzyskuje treści wyłącznie przez przejęcie infrastruktury, przy poprawnej realizacji podziału sekretu i braku innych zdolności odczytu. Słowo „samego” jest istotne. Organizacja może przekazać tej samej osobie także pełny zestaw odzyskiwania kont i zarządzanie endpointami. Wtedy zakres zagrożenia jest inny.

3. Cztery modele ochrony

• Szyfrowanie kanału: kto kończy połączenie i otrzymuje dane aplikacyjne?
• Szyfrowanie po stronie usługi: czy usługa może sama odszyfrować obiekt?
• Szyfrowanie klienckie: gdzie znajduje się pełna zdolność odczytu?
• Safe z HVKM: czy normalny odczyt wymaga współpracy domeny klienta i serwera?

To porównanie modeli, nie ranking wszystkich produktów. Szyfrowanie klienckie istnieje poza UseCrypt. Konkretną realizację ocenia się przez zarządzanie uprawnieniami, odzyskiwanie, udostępnianie i działanie klienta. Historyczny Safe łączył brak samodzielnego odczytu po stronie serwera z udziałem tego serwera w zatwierdzaniu nowych operacji prywatnych. Samo wymienienie AES i RSA nie wyjaśnia tego połączenia.

4. Serwer pozostaje, ale zmienia rolę

Serwer nie znika. Obsługuje uwierzytelnienie i autoryzację, przechowuje swój udział i wykonuje częściowe obliczenie. Bez współpracy serwera nowy odczyt może być niedostępny. Dostawca może mieć możliwość odmowy usługi, nie posiadając samodzielnie możliwości poznania dokumentu. Dostępność i poufność to różne własności.

Potrzebne pozostają kopie, odtwarzanie, monitoring i procedura awarii usługi kluczowej. Ograniczenie powierzania pośrednikowi treści nie usuwa patchowania, ochrony endpointów, administracji i obsługi incydentów. Decentralizacja zdolności odszyfrowania nie dowodzi topologii peer-to-peer. Specyfikacja Safe opisuje współpracę z serwerem.

5. Dane i kontrola klucza: dwa przepływy

URZĄDZENIE UŻYTKOWNIKA
Dokument + losowy klucz pliku
  -> szyfrogram dokumentu -> storage / backup / nośnik
  -> zabezpieczony klucz pliku -> ścieżka odczytu
      -> autoryzowany udział serwera
      -> udział klienta na urządzeniu
      -> odzyskany klucz pliku i czytelna treść

To logiczny schemat historycznego opisu, nie diagram sieci produkcyjnej. Duży obiekt danych i mały obiekt umożliwiający odczyt pełnią odmienne funkcje. Przechwycenie jednego nie musi oznaczać zdobycia drugiego. Schemat nie przesądza fizycznego miejsca przechowywania obu obiektów.

Architekt analizuje osobno ruch danych i kontrolę klucza. Zwiększenie rozmiaru pliku nie musi proporcjonalnie zwiększać kosztu każdej operacji udostępnienia. Liczba odbiorców i liczba operacji odzyskania klucza są odrębnymi czynnikami obciążenia.

6. Osobny klucz pliku i granularność

Safe opisuje odrębny klucz symetryczny dla pliku, szyfrowanie treści i ochronę materiału kluczowego mechanizmem asymetrycznym. Ujawnienie klucza jednego pliku nie jest ujawnieniem wszystkich losowo wygenerowanych kluczy. To korzyść granularności, opisana w rozdziale 9 specyfikacji.

Nie oznacza pełnej niezależności wszystkich ścieżek odczytu. Jeśli konto ma dostęp do wielu kapsułek, kompromitacja działającego klienta i jego uprawnień może dotknąć wielu obiektów. Ocenia się zakres konta, sesji i recovery, nie tylko liczbę kluczy.

Udostępnianie opisano jako zabezpieczenie odzyskanego klucza dla odbiorcy bez ponownego szyfrowania całego dokumentu. Dla obiektu o rozmiarze L operacja na małym materiale kluczowym nie wymaga ponownego przetwarzania L bajtów treści. To wniosek z przepływu danych, nie zmierzony benchmark aktualnej aplikacji.

7. Cofnięcie uprawnień nie cofa wiedzy

Pełny skradziony klucz prywatny może działać niezależnie od późniejszego stanu konta. W modelu wymagającym współpracy online serwer może odmówić nowych operacji. To istotna różnica pomiędzy samodzielnym sekretem a zdolnością zależną od współpracy.

Odczytany dokument, poznany klucz pliku i wynik częściowej operacji mogą jednak zostać zachowane. Przy prostym modelu matematycznym zachowany wynik pośredni może pozwalać na późniejsze zakończenie obliczenia. Odwołanie dostępu nie jest zdalnym usunięciem wiedzy przeciwnika.

Boneh, Ding, Tsudik i Wong: mediated RSA, USENIX 2001 to wcześniejsza analiza kontroli udziału mediatora. Stanowi kontekst dla odmowy przyszłej współpracy, nie dowód identyczności HVKM ani dowód bezpieczeństwa produktu.

8. Recovery określa rzeczywistą granicę zaufania

Specyfikacja przewiduje konfigurację ratunkową i osobne hasło. W korporacji dopuszcza zabezpieczenie tych elementów przez dział IT. Organizacja może zatem świadomie przyznać wybranej roli zdolność odzyskania konta. To druga droga uzyskania udziału użytkownika, którą należy uwzględnić w polityce i testach.

Administrator storage, administrator usługi kluczowej i opiekun pakietu ratunkowego nie muszą być jedną osobą. Gdy są, granica zaufania może być węższa niż sugeruje diagram dwóch komponentów. Audyt obejmuje przechowywanie pliku ratunkowego, dostęp do hasła, zatwierdzenie użycia i dowód wykonanej operacji. Wyłączna kontrola osoby i instytucjonalne odzyskiwanie nie są jednym modelem „nikt poza tobą”.

9. Endpoint pozostaje miejscem jawnej treści

Dokument przeznaczony do czytania musi zostać odtworzony. Przeciwnik kontrolujący proces klienta w momencie odczytu może atakować pamięć, interfejs, eksport lub mechanizmy systemu operacyjnego. Podział udziałów nie gwarantuje odporności na wszystkie te scenariusze.

Administrator serwera plikowego może też zarządzać dystrybucją aplikacji na laptopach. Ochrona przed administratorem serwera i administratorem endpointu to różne wymagania. Test wskazuje objęte modelem role oraz ich uprawnienia. Podpisane aktualizacje, kontrola wersji, obsługa sekretów w pamięci i eksport to kryteria odbioru implementacji, nie funkcje aktualnego Safe potwierdzone przez ten tekst.

10. Zero Trust i podział operacji

NIST SP 800-207, Zero Trust Architecture nie uznaje położenia w sieci za wystarczającą podstawę zaufania. HVKM dotyczy rozdzielenia konkretnej operacji kryptograficznej. Organizacja może potrzebować kontroli wywołania usługi oraz ograniczenia tego, co sama usługa potrafi odszyfrować. Użycie HVKM nie potwierdza zgodności całego wdrożenia z NIST.

NIST Multi-Party Threshold Cryptography daje kontekst badawczy wykonywania operacji przez współpracujące strony z rozdzielonym sekretem. Nie certyfikuje UseCrypt. Umieszcza temat w konkretnym obszarze badawczym zamiast nieprecyzyjnego hasła „mocniejsze szyfrowanie”.

11. Plan odbioru przez zespół IT

Osobno badamy kopię storage, udział serwera, działający endpoint i recovery. Każdy scenariusz zachowuje wersję klienta, serwera, konfigurację oraz wynik. Próba storage ustala, czy przejęte obiekty i metadane wystarczają do odczytu bez udziału klienta. Próba serwerowa bada nadużycie usługi częściowych operacji. Próba odwołania obejmuje świeżą kapsułkę i wcześniej zachowane wyniki. Recovery pokazuje, kto faktycznie może przywrócić dostęp.

Poprawny odczyt nie wystarcza. Testujemy błędny udział, uszkodzoną kapsułkę, nieautoryzowaną instalację i niedostępny serwer. Błędy nie powinny ujawniać informacji o sekretach ani otwierać alternatywnej ścieżki odczytu. To propozycja testów, nie raport z ich wykonania na produkcie.

12. Wartość ekonomiczna: przechowywanie bez automatycznego prawa odczytu

Firma może porównywać dostawców storage przy innym założeniu o zaufaniu i ograniczać zakres zasobów, których przejęcie wystarcza do czytelnego wycieku. To kierunek wartości, nie wyliczona oszczędność. Koszt całkowity obejmuje klienta, usługę kluczową, wsparcie, odzyskiwanie, dostępność, administrację, migrację i zgodność. Cena jednej maszyny nie zastępuje rachunku.

Globalna wartość rynku cyberbezpieczeństwa nie jest wyceną produktu. Historyczny abonament nie dowodzi obecnego zakresu ochrony. Pilotaż powinien mierzyć medianę i wysokie percentyle otwarcia pliku, przepustowość operacji kluczowych, koszt przyrostu użytkowników, czas odtworzenia oraz nakład administratorów. Dopiero porównanie tych samych rezultatów ochrony pozwala mówić o oszczędności. Liczba pośredników mających treść pozostaje osobnym mierzalnym rezultatem.

13. Standardy i repozytoria: rola każdego źródła

OpenSSL na GitHubie jest odniesieniem dla biblioteki i standardowych mechanizmów, nie repozytorium HVKM. Safe w 2018 wymieniał OpenSSL 1.0.2p; nie przedstawiamy tej wersji jako obecnej rekomendacji. Repozytorium CFRG FROST pokazuje dokumentowanie protokołu progowego podpisów. Nie opisuje odzyskiwania kluczy plików Safe i nie dowodzi jego bezpieczeństwa.

RFC 8017, sekcja 5 definiuje prymitywy RSA. RFC 9690, sekcja 1.2 wyjaśnia RSA-KEM. Są podstawą terminologii i porównania konstrukcji, nie stwierdzeniem zgodności Safe z tymi standardami. Dokument produktu, standard, wcześniejsza praca, kod referencyjny i raport z badania pełnią różne funkcje dowodowe.

14. Zmiana systemowa, którą można zmierzyć

UseCrypt Safe proponował ograniczenie powiązania pomiędzy administracją infrastruktury a zdolnością odczytu treści. Technicznym kryterium zmiany jest zestaw zasobów wystarczających do kompromitacji poufności. Gdy przejęcie serwera nie wystarcza do samodzielnego odczytu, zmienia się model zagrożeń. Gdy nowa operacja wymaga autoryzowanego klienta, zmienia się organizacja uprawnień. Gdy udostępnienie przetwarza klucz zamiast całego obiektu, zmienia się koszt konkretnego procesu.

Każdy z tych rezultatów można opisać, porównać i przetestować. To podstawa Bringing Privacy Back: kontrola wynikająca z konstrukcji, nie wyłącznie z deklaracji dostawcy.

Źródło produktowe i dalsza lektura

Opracowanie redakcji UseCrypt na podstawie „Opisu Kryptograficznego UseCrypt Safe”, wersja 1.3, 8 października 2018, 11 stron. Kotwice: rozdział 4 podział udziałów; 5.1 recovery; 6.1 rola serwera; 10.1 szyfrowanie; 10.2 dostęp; 10.3 udostępnianie; 10.4 szyfrowanie lokalne. Analizę opisanych mechanizmów udostępniono za zgodą dysponenta materiału; nie zamieszczamy oryginalnego dokumentu. Aktualny build, biblioteki i konfiguracja wymagają osobnego potwierdzenia.

AVLab: historyczny opis architektury Safe · UseCrypt Technology · Oceny i zakres testów · Osobna dokumentacja Messengera · Bringing Privacy Back: Messenger.