Przeglądarka może wykonywać silną kryptografię; kod dostarczony do przeglądarki nadal musi być godny zaufania.
Przeglądarka może lokalnie wykonywać szyfrowanie end-to-end, w tym postkwantowe ustanawianie kluczy, bez instalowania natywnego komunikatora. Trudne pytanie nie brzmi, czy obliczenia matematyczne można wykonać w karcie. Chodzi o to, czy dostarczona aplikacja, obsługa kluczy i ścieżka aktualizacji zasługują na zaufanie wymagane przez rozmowę.
Dostęp przez przeglądarkę bywa wygodny, gdy instalacja jest niemożliwa. Nie zapewnia aplikacji odporności na cenzurę, przejęcie hostingu, złośliwe rozszerzenia ani przejęcie urządzenia.
Kryptograficzne elementy składowe przeglądarki
WebCrypto udostępnia niskopoziomowe operacje szyfrowania, wyprowadzania kluczy, podpisywania i zarządzania kluczami. Typowe implementacje zapewniają prymitywy takie jak AES-GCM i ECDH. Operacje te są elementami składowymi, a nie kompletnym uwierzytelnionym protokołem komunikatora.
Aplikacja internetowa może dodać poddaną analizie implementację ML-KEM w JavaScript lub WebAssembly tam, gdzie wymagane natywne API jest niedostępne. Obsługa w przeglądarkach się zmienia, dlatego programiści powinni sprawdzać dostępność funkcji w konkretnych wersjach docelowych, zamiast zakładać, że każda przeglądarka oferuje te same algorytmy.
Koncepcyjny przebieg hybrydowy wygląda następująco:
- Wygeneruj odpowiednie klucze przy użyciu kryptograficznie bezpiecznej losowości.
- Uwierzytelnij materiał kluczowy rozmówcy za pomocą mechanizmu tożsamości protokołu.
- Uzyskaj klasyczne i postkwantowe wkłady do wspólnego sekretu.
- Połącz je zgodnie z określonym harmonogramem wyprowadzania kluczy i kontekstem rozmowy.
- Użyj wyprowadzonych kluczy do szyfrowania uwierzytelnionego, prawidłowo obsługując nonce i stan.
To zarys objaśniający, nie przepis na implementację. FIPS 203 standaryzuje ML-KEM; nie certyfikuje konkretnej aplikacji przeglądarkowej ani nie definiuje wszystkich kroków protokołu czatu.
Dostarczanie przez HTTPS jest częścią modelu zaufania
Serwer zazwyczaj dostarcza JavaScript i WebAssembly przetwarzające tekst jawny. Złośliwie zmieniona aplikacja może odczytać wiadomość przed szyfrowaniem lub po odszyfrowaniu, nawet jeśli jej biblioteka kryptograficzna używa poprawnych algorytmów.
HTTPS pomaga uwierzytelnić dostarczanie i chronić je przed ingerencją sieciową. Nie dowodzi, że operator źródła, jego system wdrażania lub zależności nie zostały przejęte. Zwykła strona HTTPS nie jest automatycznie niezależnie podpisanym pakietem aplikacji.
Uwagi W3C dotyczące bezpieczeństwa WebCrypto omawiają wstrzykiwanie skryptów i potrzebę ochrony integralności aplikacji. Content Security Policy, staranne zarządzanie zależnościami i inne zabezpieczenia internetowe ograniczają ryzyko, lecz żadne nie zmienia dowolnego skryptu z tego samego źródła w niezaufanego obserwatora niezdolnego do dostępu do danych aplikacji.
WebAssembly również dzieli granicę bezpieczeństwa aplikacji. Jego piaskownica ogranicza dostęp do hosta przez określone interfejsy; nie czyni wywołującej strony godną zaufania. Kompilowanie C do Wasm nie zapewnia językowi źródłowemu bezpieczeństwa pamięci.
Klucze niekoniecznie istnieją tylko w RAM
Komunikator przeglądarkowy może trwale przechowywać klucze lub zaszyfrowany stan, aby użytkownik mógł wrócić do tej samej tożsamości. Może też oferować łączenie urządzeń lub szyfrowane odzyskiwanie. Zachowania te trzeba udokumentować, a nie zakładać, że nie występują.
Warto zadać następujące pytania:
- Które klucze są trwale przechowywane i w jakim magazynie przeglądarki?
- Co dzieje się po wyczyszczeniu danych witryny lub zakończeniu sesji prywatnej?
- Czy złośliwy kod działający w kontekście aplikacji nadal może używać klucza nieeksportowalnego?
- Czy nowo dostarczona aktualizacja może uzyskać dostęp do starego stanu lokalnego?
- Czy odzyskiwanie przywraca tożsamość, historię wiadomości czy obie te rzeczy?
Nieeksportowalny klucz WebCrypto ogranicza eksport przez API. Sam w sobie nie powstrzymuje wrogiego kodu aplikacji przed żądaniem dozwolonych operacji lub zbieraniem tekstu jawnego.
Klienci internetowi i natywni mają różne kompromisy
| Kwestia | Klient przeglądarkowy | Klient natywny |
|---|---|---|
| Dystrybucja | Źródło, hosting i potok aktualizacji internetowych | Sklep z aplikacjami lub dystrybucja pakietów i potok podpisywania |
| Trwałość lokalna | Magazyn przeglądarki i zachowanie profilu | Magazyn aplikacji w systemie i cykl życia aplikacji |
| Narażenie | Skrypty tego samego źródła, rozszerzenia i luki przeglądarki | Zależności aplikacji i luki systemu/aplikacji |
| Dostępność | Osiągalna domena i wymagane usługi sieciowe | Zainstalowana aplikacja nadal potrzebuje wymaganych usług sieciowych |
Żadna kolumna nie wskazuje zwycięzcy bez zbadania implementacji. Aplikacja internetowa może pozostać dostępna po usunięciu ze sklepu, ale zablokowana domena lub brak trasy sieciowej nadal mogą uniemożliwić dostęp.
Mierz wydajność zamiast ją obiecywać
Zgodnie z FIPS 203 ML-KEM-768 używa klucza enkapsulacji o wielkości 1184 bajtów i szyfrogramu o wielkości 1088 bajtów. Te rozmiary pomagają wyjaśnić, dlaczego protokoły mogą planować aktualizacje KEM zamiast dołączać świeży materiał do każdej krótkiej wiadomości. Nie są to pomiary przepustowości ani szybkości całej aplikacji.
Użyteczny benchmark podaje przeglądarkę, urządzenie, kompilację, metodę rozgrzewania, mierzoną operację i rozkład czasów. Uwzględnij uruchamianie strony, ładowanie modułów, użycie pamięci, słabsze urządzenia i narzut sieciowy. Twierdzenia takie jak „poniżej dwóch milisekund na wszystkich współczesnych telefonach” wymagają opublikowanych pomiarów; ten artykuł ich nie dostarcza.
Zastosowanie do Livary
Przegląd bezpieczeństwa Livary dokumentuje LVR1 i granice odzyskiwania. Jej Proof Lab demonstruje wybrane lokalne operacje P-256, HKDF i AES-GCM; strona wyraźnie wyłącza pełną kompozycję LVR1/LGS1 z zakresu tego stanowiska testowego. Udana demonstracja nie dowodzi więc bezpieczeństwa całego dostarczanego kodu internetowego.
Przed wrażliwą rozmową w przeglądarce użyj autentycznego, utrzymywanego klienta, zapoznaj się z aktualnym modelem zagrożeń, chroń profil przeglądarki i zweryfikuj rozmówcę za pomocą obsługiwanego procesu sprawdzania kluczy. Wygoda i użyteczna kryptografia mogą współistnieć, o ile granica dostarczania przez internet pozostaje częścią oceny.
