HVKM: matematyka RSA, kapsułki kluczy i kontrola odczytu

Administrator serwera nie powinien uzyskiwać dostępu do treści tylko dlatego, że zarządza infrastrukturą. UseCrypt Safe odpowiadał na ten problem przez lokalne szyfrowanie plików i rozdzielenie operacji prywatnej pomiędzy urządzenie użytkownika a serwer. Serwer wykonywał część obliczenia, lecz odzyskanie klucza pliku wymagało dopełnienia operacji po stronie klienta. Zmienia się więc zestaw zasobów, których przejęcie wystarcza do odczytu danych.

Ta analiza dotyczy opisu kryptograficznego UseCrypt Safe, wersja 1.3 z 8 października 2018. Nie jest raportem z audytu aktualnego buildu ani opisem mechanizmów UseCrypt Messenger. Rozdzielamy treść dokumentu, własne wnioski matematyczne oraz właściwości wymagające testu implementacji.

1. Klucz pliku nie jest udziałem klucza RSA

Niech F oznacza treść pliku, K_F jego klucz symetryczny, a C_F zaszyfrowaną treść. Para publiczna RSA ma postać (n,e), gdzie n=pq dla różnych liczb pierwszych p i q. Wykładnik prywatny d spełnia relację z e. Udziały wykładnika oznaczamy d_u po stronie klienta i d_s po stronie serwera. Wynik częściowej operacji to t.

K_F, d_u i d_s mają różne funkcje. Klucz pliku służy do szybkiego przetwarzania treści. Udziały RSA uczestniczą w odzyskaniu materiału pozwalającego otrzymać ten klucz. Nie dzielimy każdego klucza AES na dwie połowy i nie szyfrujemy ogromnego pliku bezpośrednio RSA.

Wykradziony K_F dotyczy konkretnego obiektu. Przejęta ścieżka wykonywania operacji prywatnych może dotyczyć wielu obiektów chronionych dla użytkownika. Ochrona granularna i ochrona nadrzędnej zdolności odczytu muszą być oceniane osobno.

2. Matematyczny rdzeń RSA

n = p * q
phi(n) = (p - 1) * (q - 1)
e * d ≡ 1 (mod phi(n))
c = z^e mod n
z = c^d mod n

Z jest reprezentantem matematycznym, nie całym plikiem i niekoniecznie bezpośrednio K_F. Przy poprawnych parametrach operacja prywatna odwraca odpowiadającą jej operację publiczną. Ten zapis nie definiuje jeszcze bezpiecznego szyfrowania dowolnych wiadomości. Schemat potrzebuje właściwego kodowania i pozostałych warstw ochrony.

RFC 8017, sekcja 5: prymitywy RSA rozdziela operacje matematyczne i schematy, w których są używane. Jest punktem odniesienia dla terminologii RSA, nie specyfikacją HVKM.

Poprawność dla reprezentantów względnie pierwszych z n wynika z własności potęgowania. Dla pozostałych można rozpatrzyć osobno reszty modulo p i modulo q, a następnie zastosować chińskie twierdzenie o resztach. Zakładamy poprawną generację klucza i zgodność parametrów.

3. HVKM opisuje podział multiplikatywny

W rozdziale 4 specyfikacji Safe podano relację d_u*d_s ≡ d modulo phi(n). Normalną operację przedstawiamy jako częściowe potęgowanie przez serwer, a następnie dopełnienie przez klienta:

t = c^d_s mod n
z = t^d_u mod n
z = (c^d_s)^d_u mod n
  = c^(d_s*d_u) mod n
  = c^d mod n

Serwer przekazuje wynik częściowy, nie musi przekazywać swojego udziału. Klient kończy operację własnym udziałem. Rozdzielenie jest algebraiczne i operacyjne. Nie oznacza przecięcia zapisu klucza na dwie równe części ani użycia dwóch modułów RSA o połowie długości.

Równanie nie dowodzi, że każda para spełniająca relację jest bezpiecznym podziałem. Para d_u=1 i d_s=d także ją spełnia, lecz pozostawia pełną operację serwerowi. Dystrybucja udziałów i wykluczenie degeneracji są częścią konstrukcji bezpieczeństwa. Test poprawności nie jest dowodem odporności na odzyskanie sekretu.

4. Przykład liczbowy: co obliczają obie strony

Dla demonstracji wybierzmy p=61, q=53, n=3233, e=17. Otrzymujemy phi(n)=3120 i d=2753. Wybierzmy d_u=7 oraz d_s=839. Zachodzi 7*839=5873, a 5873 modulo 3120 daje 2753.

Dla z=42 operacja publiczna daje c=2557. Serwer oblicza t=439. Klient otrzymuje 439^7 modulo 3233, czyli 42. Wynik można odtworzyć bez aplikacji UseCrypt.

Parametry są celowo bardzo małe i całkowicie niebezpieczne do realnego zastosowania. Przykład wyjaśnia składanie operacji, nie rekomenduje generacji udziałów. Nie sprawdza paddingu, KEM, KDF, uwierzytelniania ani kodu klienta.

Test dydaktyczny sprawdził poprawne odwracanie dla wszystkich 3233 reprezentantów tego modułu: 3233/3233. Niektóre reprezentanty szczególne mogą pozostać niezmienione również przy niepełnych operacjach. Próba pojedynczych udziałów nie jest definicją bezpieczeństwa kryptograficznego. To test modelu, nie audyt produktu.

5. Generacja: pełny klucz istnieje podczas rejestracji

Opis Safe przewiduje wygenerowanie pełnej pary RSA po stronie klienta, podział i przesłanie części serwerowej, która następnie zostaje usunięta po stronie klienta. Poprawne zdanie brzmi: późniejsze zwykłe operacje wykorzystują rozdzielone udziały. Zdanie „pełny klucz nigdy nie istnieje” nie odpowiada opisanemu procesowi.

Implementacja musi zabezpieczyć moment generacji. Nieusunięte d, p lub q mogą obejść zamierzony podział. Trzeba sprawdzić kopie w pamięci, serializację, pliki tymczasowe i ścieżki błędów. Wyczyszczenie jednej zmiennej nie jest dowodem usunięcia wszystkich kopii.

Ilustracja algebraiczna może wybierać d_u odwracalne modulo phi(n) i obliczać d_s=d*d_u^(-1) modulo phi(n). Nie potwierdzono, że aktualny produkt właśnie tak realizuje generację. Bezpieczny algorytm musi określić rozkład losowania, zakresy, walidację i niszczenie pierwotnego materiału.

6. Podział addytywny i multiplikatywny to różne konstrukcje

W podziale addytywnym zachodzi d_u+d_s ≡ d modulo odpowiedniego modułu wykładników. Naturalne złożenie ma wtedy postać iloczynu c^d_u oraz c^d_s. W podziale multiplikatywnym złożenie jest sekwencyjne: wynik jednej potęgi podnosimy do drugiej.

Bibliografia wskazująca wariant addytywny nie dowodzi automatycznie bezpieczeństwa multiplikatywnego. Przeniesienie wyniku naukowego wymaga zgodności założeń, protokołu i modelu przeciwnika.

Boneh, Ding, Tsudik i Wong: mediated RSA, USENIX Security 2001 to wcześniejszy kontekst współpracy użytkownika z mediatorem i odwołania jego udziału. Nie rozstrzyga pierwszeństwa ani unikalności implementacji Safe.

7. Kapsułka: ochrona klucza, nie całego pliku RSA

Safe deklaruje osobny losowy klucz pliku i jego zabezpieczenie mechanizmem KEM. To model hybrydowy: szyfrowanie symetryczne treści i mechanizm asymetryczny krótkiego materiału kluczowego. Źródło produktowe: rozdział 10.

W standardowym opisie RSA-KEM losowy reprezentant daje kapsułkę RSA i sekret wyprowadzany przez KDF. W zastosowaniu CMS z tego sekretu wyprowadza się KEK, którym opakowuje się klucz treści CEK. KEM, KDF i key-wrap są osobnymi elementami. RFC 9690, sekcje 1.2 i 1.3.

Nie dopisujemy do Safe parametrów tego standardu. Dostępna specyfikacja nie podaje kompletnego formatu kapsułki, szczegółowej KDF ani całej procedury opakowania. Nie wykazano zgodności Safe z RFC 9690. Standard pomaga stawiać właściwe pytania, nie uzupełnia brakującego kodu.

Kapsułkowanie nie dowodzi szyfrowania homomorficznego ani odporności postkwantowej. ML-KEM ma inne podstawy matematyczne. NIST FIPS 203: ML-KEM nie jest dowodem implementacji tego algorytmu w UseCrypt.

8. Cykl pliku i klucz w pamięci

Zapis zaczyna się od wygenerowania K_F i lokalnego zaszyfrowania treści. Klucz zostaje zabezpieczony dla użytkownika. Odczyt wymaga odzyskania materiału pozwalającego odtworzyć K_F. Operacja serwera jest dopełniana po stronie klienta; treść odszyfrowuje się lokalnie.

Specyfikacja opisuje usuwanie klucza pliku z RAM po użyciu. Audyt musi zbadać bufor, kopie obiektów, biblioteki, swap i ścieżki awaryjne. Deklaracja cyklu nie jest pomiarem zachowania pamięci. Pytanie brzmi: które sekrety i jak długo istnieją w działającym procesie?

Szyfrowanie nazwy i treści nie dowodzi ukrycia długości obiektu, czasu transmisji, adresów sieciowych czy liczby operacji. Każda właściwość wymaga oddzielnego mechanizmu i testu.

9. Udostępnienie bez ponownego szyfrowania wielkiego obiektu

W opisanej ścieżce klient odzyskuje K_F i zabezpiecza go dla odbiorcy. Szyfrogram treści może pozostać ten sam. Udostępnienie nie wymaga wtedy ponownego zaszyfrowania całego pliku.

Dla długości L i liczby odbiorców r przetwarzanie obejmuje pierwotne szyfrowanie zależne od L oraz przygotowanie materiału kluczowego dla odbiorców. Koszt drugich operacji nie musi rosnąć z długością pliku. To analiza struktury obliczeń, nie benchmark czasu lub przepustowości.

Nie jest to automatycznie proxy re-encryption wykonywane wyłącznie na serwerze: klient odzyskuje klucz pliku. Wycofanie odbiorcy, który go zachował, jest innym problemem niż odmowa pierwszego odczytu. Dotychczasowy klucz nie przestaje działać po usunięciu odbiorcy z listy.

10. Odwołanie dostępu: trzy przypadki

Przeciwnik ma szyfrogram i udział klienta, ale nie dostał potrzebnego wyniku częściowego. Odmowa nowej operacji serwera może uniemożliwić zakończenie ścieżki. To zamierzona korzyść współpracy online.

Przeciwnik zachował t dla konkretnej kapsułki i posiada d_u. W prostym modelu t^d_u można obliczyć bez nowego wywołania. To wniosek z równania, nie stwierdzona luka aktualnego produktu. Dodatkowe rotacje i powiązania protokołu mogą zmieniać rezultat; wymagają specyfikacji i testu.

Przeciwnik ma K_F lub treść. Cofnięcie autoryzacji nie usuwa już poznanej informacji. Ochrona nowych obiektów i dotychczasowego szyfrogramu to różne cele.

Raport powinien podać, co odwołano: konto, instalację, udział, kapsułkę czy uprawnienie do operacji. Musi również wymienić materiały zachowane przed odwołaniem. Bez tego „natychmiastowe cofnięcie dostępu” nie określa właściwości kryptograficznej.

11. Uwierzytelnianie i zaufane instalacje

Safe opisuje lokalną konfigurację z zaszyfrowanym udziałem klienta. Odzyskanie klucza konfiguracji wiąże z hasłem, wartością losową R i sekretem S udostępnianym po uwierzytelnieniu. To opis zależności, nie kompletna specyfikacja KDF.

Opisuje też autoryzację instalacji tokenem wysłanym na pocztę oraz identyfikator związany z wartością losową i parametrami urządzenia. Nie wynika z tego automatycznie sprzętowa attestation ani niemożliwość odtworzenia identyfikatora. Trzeba sprawdzić sposób wyliczania, transportu i związania z sesją.

Przenoszenie konfiguracji i autoryzacja kolejnej instalacji są opisane wprost. Odczyt nie jest więc na zawsze przypisany wyłącznie do jednej fizycznej stacji roboczej. Wiązanie z autoryzowanymi instalacjami i zakaz migracji to inne właściwości.

12. Recovery zmienia rzeczywisty rozkład zaufania

Konfiguracja ratunkowa zawiera zabezpieczony udział klienta i korzysta z osobnego hasła. Źródło zaleca osobne przechowywanie pliku i hasła; użycie ratunkowe anuluje dotychczasowe autoryzacje. Wskazuje też możliwość korporacyjnego zabezpieczenia recovery przez IT.

Odbiorca musi wiedzieć, kto może odzyskać konto. Rola mająca oba elementy recovery dysponuje szerszą zdolnością niż operator mający wyłącznie udział serwerowy. Podział kryptograficzny nie zwalnia z rozdziału obowiązków organizacyjnych.

Audyt obejmuje utworzenie, transport, kopie, użycie i rotację. Deklaracja „serwer nie ma pełnego klucza” nie opisuje wszystkich alternatywnych ścieżek do udziału użytkownika.

13. Parametry historyczne i współczesna ocena

Specyfikacja z 2018 wymienia RSA 2048, AES-256-CBC, SHA-512, Diffiego-Hellmana i OpenSSL 1.0.2p. To zapis historyczny, nie potwierdzenie obecnych zależności ani rekomendacja konfiguracji na 2026.

RSA 2048 nie oznacza 2048 bitów odporności i nie jest odpowiednikiem AES-256. NIST przyporządkowuje RSA 2048 klasycznej sile około 112 bitów. NIST SP 800-57 Part 1 Rev. 5, tabela 2.

CBC nie zapewnia samodzielnie pełnego uwierzytelniania szyfrogramu. Trzeba sprawdzić wykrywanie modyfikacji i przetwarzanie błędów. Nazwa AES ani wzmianka o HMAC nie odtwarzają całej kompozycji. NIST SP 800-38A: tryby szyfrów blokowych.

14. Równanie nie jest dowodem bezpieczeństwa protokołu

Dowód musi nazwać cel przeciwnika i jego dozwolone zapytania. Czy kontroluje jednego uczestnika? Czy modyfikuje kapsułki? Czy adaptacyjnie wywołuje częściową operację? Czy przejmuje klienta przed generacją czy po podziale? Jak modeluje recovery i współdziałanie ról?

Relacja arytmetyczna potwierdza składanie, nie ogranicza wszystkich dróg ujawnienia. Implementacja wymaga walidacji, ochrony przed kanałami bocznymi, separacji zastosowań kluczy i obsługi błędów komunikacji.

OpenSSL na GitHubie pozwala badać standardowe komponenty biblioteki, ale nie zawiera z tego powodu kodu HVKM. CFRG FROST na GitHubie dokumentuje inny protokół progowy, dotyczący podpisów. To kontekst techniczny, nie raport z testów UseCrypt.

15. Reprodukowalne badanie aktualnej realizacji

Pierwszy artefakt to manifest: wersja, hash buildu, platforma, zależności i konfiguracja. Drugi to specyfikacja formatu kapsułki i pełnego protokołu częściowej operacji. Trzeci to model zagrożeń rozdzielający serwer, endpoint, recovery i aktualizacje. Na tej podstawie powstają przypadki testowe.

Matematycznie sprawdzamy poprawność kluczy, zgodność udziałów i odrzucanie niedozwolonych reprezentantów. W protokole: autoryzację, wiązanie odpowiedzi z żądaniem, powtórzenia i błędne odpowiedzi. W kliencie: pamięć, eksport, zamknięcie procesu i awarie. Odwołanie testujemy dla nowej operacji i zapisanego rezultatu. Każdy test ma warunki początkowe, oczekiwany wynik, obserwację i log.

Wydajność mierzymy osobno dla sieci, autoryzacji, operacji kluczowej i szyfrowania lokalnego. Raport podaje rozkłady, nie tylko średnią. Test dostępności pokazuje awarię i odtworzenie bez niejawnego przełączenia do trybu łamiącego granicę zaufania.

Takiego badania nie zastępuje niniejszy tekst. Mamy historyczną specyfikację i sprawdzenie równania, nie kompletny audyt aktualnego kodu. To pozwala rozmawiać z architektem i kryptografem bez mieszania modelu z produktem.

16. Zmiana systemowa

HVKM ogranicza samodzielną zdolność operacyjną każdej ze stron normalnej ścieżki odczytu. Klient nie musi otrzymywać udziału serwera, a serwer udziału klienta. Kontrola nowych operacji staje się elementem użycia klucza, nie tylko listą ACL przed pobraniem obiektu.

Przedmiotem oceny nie jest mocniejszy AES, lecz ograniczenie pojedynczych domen, których kompromitacja wystarcza do odczytu. Najlepsza baza wiedzy pokazuje równanie, cykl klucza, role, koszty, scenariusze i wynik testu właściwej wersji. Głębokość pochodzi z mechanizmu.

17. Pełny cykl klucza: od rejestracji do odczytu pliku

Model matematyczny staje się systemem dopiero wtedy, gdy wiadomo, skąd pochodzą klucze, gdzie są przechowywane i kiedy można ich użyć. Opis Safe 1.3 pozwala odtworzyć ten cykl. Rozdział 4 dotyczy generacji i podziału RSA; rozdział 5 ochrony konfiguracji; rozdział 6 uwierzytelniania i współpracy HVKM; rozdział 10 zarządzania kluczami plików. To cztery różne warstwy, nie cztery nazwy tego samego klucza.

Podczas rejestracji klient generuje parę RSA. Następnie powstają udziały wykładnika prywatnego. Udział serwerowy trafia do serwera, a opis przewiduje usunięcie pierwotnego pełnego klucza prywatnego po stronie klienta. Dlatego poprawną tezą jest rozdzielenie zwykłych operacji po rejestracji. Teza „pełny klucz nigdy nie istnieje” nie wynika z dokumentu. Sama rejestracja wymaga ochrony generatora losowości, pamięci tymczasowej i kanału przekazania udziału.

Udział klienta nie pełni funkcji klucza wszystkich plików. Jest elementem nadrzędnej zdolności wykonania operacji prywatnej. Każdy nowy plik otrzymuje swój klucz symetryczny. Klucz pliku chroni dużą treść, natomiast kapsułka chroni możliwość odzyskania tego klucza. Oddzielenie tych poziomów pozwala zmieniać odbiorców i uprawnienia bez utożsamiania ich z szyfrowaniem całego magazynu.

18. Konfiguracja klienta: hasło, lokalne R i serwerowe S

Rozdział 5 opisuje zaszyfrowaną konfigurację zawierającą udział klienta. Do odtworzenia klucza jej ochrony wykorzystywane są informacje związane z hasłem, lokalną wartością R i wartością S wydawaną przez serwer po uwierzytelnieniu. To dodatkowa granica: kopia konfiguracji nie jest automatycznie gotowym do użycia udziałem prywatnym.

Oceniając ten mechanizm, trzeba rozdzielić atak offline na kopię od prób wymagających współpracy serwera. Istotne są format konfiguracji, funkcja wyprowadzania klucza, jej parametry, sposób potwierdzania poprawnego hasła oraz ograniczenia prób. Dokument pozwala wskazać role R i S, ale nie wystarcza do odtworzenia wszystkich parametrów implementacji. Nie należy dopisywać konkretnego KDF tylko dlatego, że jest obecnie popularny.

W praktyce istnieją zatem co najmniej trzy odrębne pytania: czy przeciwnik ma plik konfiguracji, czy potrafi uzyskać materiał do jej otwarcia oraz czy uprawniona instalacja może wykonać operację HVKM. Raport sprowadzony do zdania „hasło chroni klucz” pomija zależności, które stanowią istotę tego modelu.

19. Ścieżka pliku według rozdziału 10

Rozdział 10.1 opisuje szyfrowanie pliku i jego nazwy z użyciem nowego klucza symetrycznego. Rozdział 10.2 opisuje dostęp: klient uzyskuje częściowy wynik operacji z serwera, dopełnia operację własnym udziałem i odzyskuje klucz pliku. Odszyfrowanie treści następuje lokalnie.

PLIK F + nowy klucz K_F
  -> zaszyfrowana treść i nazwa
  -> oddzielnie chroniony dostęp do K_F

ODCZYT
  -> uwierzytelniona instalacja
  -> częściowa operacja serwera
  -> dopełnienie operacji klienta
  -> odzyskany lokalnie K_F
  -> lokalne odszyfrowanie F

Serwis kluczowy nie musi przetwarzać wszystkich bajtów dużego pliku, żeby uczestniczyć w udostępnieniu jego klucza. Ma to znaczenie dla projektowania obciążenia i podziału usług. Nie daje jednak samo w sobie pomiaru przepustowości ani dowodu konkretnego kosztu infrastruktury. Takie liczby wymagają benchmarku obejmującego operacje kluczowe, uwierzytelnianie, sieć i równoległych użytkowników.

Opis przewiduje nadpisywanie materiału kluczowego w RAM po użyciu. Weryfikacja tej właściwości obejmuje rzeczywiste kopie pamięci, zachowanie bibliotek, zrzuty awaryjne i optymalizacje kompilatora. Deklarowany cykl życia jest instrukcją, co mierzyć, a nie zastępnikiem pomiaru aplikacji.

20. Udostępnianie: nowa ochrona klucza, nie nowy ogromny szyfrogram

Rozdział 10.3 opisuje odzyskanie klucza pliku przez uprawnionego klienta i zabezpieczenie go kluczem publicznym odbiorcy. Duża zaszyfrowana treść może pozostać taka sama. Zmienia się materiał umożliwiający odbiorcy uzyskanie klucza oraz uprawnienia do operacji na obiekcie.

To konkretna korzyść konstrukcyjna: dodanie odbiorcy nie musi oznaczać ponownego szyfrowania całego pliku. Operację na niewielkim materiale kluczowym oddzielono od kosztu przetworzenia treści. Równocześnie odbiorca, który już odzyskał treść i zapisał ją poza systemem, posiada własną kopię. Cofnięcie nowych operacji na serwerze nie usuwa takiej kopii. Uprawnienia odczytu, zapisu i usunięcia oraz kontrola nad wcześniej ujawnionym tekstem jawnym są różnymi zagadnieniami.

21. Zaufane instalacje, transfer i kontrola tożsamości

Rozdział 7 łączy uwierzytelnianie użytkownika z konfiguracją i tożsamością instalacji. Opis obejmuje lokalny identyfikator oraz identyfikację urządzenia, autoryzację przez token mailowy i rejestrację nowych instalacji lub adresów sieciowych. Nie sprowadza dostępu do samego posiadania loginu i hasła.

Rozdział 8 opisuje eksport, import oraz zdalne przeniesienie konfiguracji. W transferze pomiędzy starą i nową instalacją występuje wymiana Diffiego-Hellmana oraz porównanie odcisków na obu końcach. Serwer pośredniczy w przekazaniu zaszyfrowanego materiału. Porównanie odcisków służy weryfikacji właściwego partnera wymiany; samo uzgodnienie sekretu bez sprawdzenia tożsamości odpowiada na inne pytanie.

HVKM nie oznacza więc, że istnieje tylko jeden nieprzenoszalny komputer. Istnieje kontrolowana ścieżka ustanawiania kolejnych instalacji. Jej bezpieczeństwo zależy między innymi od autoryzacji transferu, poprawności sprawdzenia odcisków i zakresu przekazywanego materiału. To osobny przedmiot testu od równania RSA.

22. Zmiana hasła i recovery to różne operacje

Rozdział 9 opisuje zmianę hasła. Konfiguracja na bieżącej instalacji zostaje zabezpieczona nowym hasłem. Na pozostałych instalacjach opis odróżnia nowe hasło do uwierzytelnienia od starego hasła potrzebnego do otwarcia dotychczasowej lokalnej konfiguracji, zanim zostanie ona ponownie zabezpieczona. Aktualizacja konta i aktualizacja lokalnego sekretu nie są tą samą czynnością.

Recovery korzysta z oddzielnej konfiguracji chronionej innym hasłem. Opis przewiduje jej eksport podczas rejestracji oraz możliwość rezygnacji z tego wariantu. W firmie materiał odzyskiwania może pozostawać pod kontrolą wyznaczonej osoby. Dostęp tej osoby trzeba wskazać w modelu zaufania: nie jest zwykłym prawem do obsługi dysków.

Odzyskanie dostępu unieważnia dotychczasowe zaufane instalacje w opisanym obiegu. Zwykły reset hasła przez administratora nie jest równoważny odzyskaniu zaszyfrowanej konfiguracji. Gdy użytkownik zapomni sekret potrzebny do jej otwarcia, konieczna jest właściwa ścieżka odzyskiwania, o ile została przygotowana. Plan wdrożenia musi więc określać posiadaczy konfiguracji recovery, posiadaczy jej hasła oraz procedurę użycia i odtworzenia.

23. Lokalny szyfrogram nadal może wymagać usługi kluczowej

Rozdział 10.4 opisuje szyfrowanie lokalne. Chroniony plik może pozostać poza magazynem Safe, również na fizycznym nośniku. To rozdziela miejsce przechowywania od odzyskiwania klucza. Z opisu nie wynika jednak brak zależności sieciowej: usługa kluczowa nadal uczestniczy w ścieżce odczytu.

Ta właściwość jest ważna dla projektu organizacyjnego. Firma może rozważać osobno administratora storage, operatora usługi kluczowej i właściciela stacji roboczej. Nie oznacza to automatycznej odporności na przejęcie odblokowanego procesu ani braku potrzeby kopii i ciągłości działania. Zmiana polega na rozdzieleniu zdolności odczytu, a nie na usunięciu wszystkich pozostałych obowiązków operacyjnych.

Angielski opis pełnego obiegu Safe i Messengera porządkuje te mechanizmy w ramach rodziny produktów. Osobna analiza Messenger dotyczy bazy SQLite, kluczy aplikacji i powiadomień, nie tego samego protokołu HVKM.

24. UST chroni kanał operacji, nie zastępuje HVKM

Rozdział 3 opisuje UseCrypt Secure Tunnel jako szyfrowany kanał aplikacyjny między klientem a serwerem. Opis inicjalizacji zaczyna się od weryfikacji certyfikatu serwera wydanego przez UseCrypt CA i zgodności domeny. Następnie opisuje wymianę Diffiego-Hellmana oraz ochronę komunikacji przy użyciu AES. Wyróżnia klucz tunelu początkowego i nowy klucz sesji po zalogowaniu użytkownika.

Ta warstwa odpowiada na inne pytanie niż podział wykładnika RSA. UST dotyczy tego, z którym serwerem rozmawia klient i jak chroniony jest kanał przekazywania operacji. HVKM dotyczy tego, jakie materiały oraz obliczenia są potrzebne do zakończenia operacji prywatnej. Zaszyfrowany kanał nie dowodzi rozdzielenia zdolności odczytu, a podział klucza nie zastępuje uwierzytelnienia partnera połączenia.

W badaniu należy więc sprawdzić osobno błędny certyfikat, niezgodną domenę, odnowienie sesji, powtórzenie żądania i obsługę przerwanego połączenia. Dokument nie podaje kompletnego zapisu komunikatów i wszystkich parametrów DH. Z jego opisu nie wyprowadzamy uniwersalnej przewagi nad TLS ani odporności na dowolną aplikację działającą na przejętym urządzeniu. Zachowujemy natomiast konkretny podział zadań: kanał chroni wymianę, a współpraca udziałów umożliwia właściwą operację na materiale kluczowym.

Źródło produktowe i dalsza lektura

Opis Kryptograficzny UseCrypt Safe, wersja 1.3, 8 października 2018, 11 stron. Kotwice: rozdział 2 parametry; 4 generacja i podział; 5 konfiguracja i recovery; 6 uwierzytelnianie i odwołanie; 7 instalacje; 8 migracja; 9 zmiana hasła; 10 zarządzanie kluczami plików; 10.4 szyfrowanie lokalne. Artykuł publikuje analizę mechanizmów, nie kopię dokumentu.

Publiczny opis historyczny: AVLab: UseCrypt Safe i model ochrony. Standardy i repozytoria wskazane przy odpowiednich sekcjach nie są certyfikatami produktu.

Mapa technologii UseCrypt · Zakresy ocen bezpieczeństwa · Osobny opis Messengera · Kontekst prywatności na Bringing Privacy Back

Opracowanie: redakcja UseCrypt. Nie znaleziono publicznego repozytorium implementacji HVKM w zakresie tej analizy. Nie przypisujemy tej konstrukcji czterem patentom Messengera bez właściwego rekordu patentowego.