Wprowadzenie do problemu / definicja luki
„Whisper Leak” to zaprezentowany przez badaczy Microsoftu atak kanałem bocznym na modele językowe udostępniane zdalnie (API/WWW), który nie łamie TLS ani nie odczytuje treści — zamiast tego wykorzystuje wzorce metadanych ruchu (rozmiary pakietów i odstępy czasowe w trybie streamingu), aby klasyfikować temat rozmowy użytkownika. Atak ma znaczenie praktyczne dla scenariuszy z podsłuchem na poziomie ISP, niezaufanego Wi-Fi lub obserwatora w tej samej sieci.
SecurityWeek podkreśla, że napastnik, który tylko przechwyci szyfrowany ruch, może z wysoką skutecznością ustalić, czy rozmowa dotyczy „wrażliwego” tematu (np. legalności prania pieniędzy, polityki, protestów, zdrowia).
W skrócie
- Zakres: dotyczy LLM w trybie streamingu (tokeny/porcje zwracane na bieżąco).
- Technika: analiza sekwencji {rozmiar TLS → czas między pakietami} do klasyfikacji tematu pierwszego promptu.
- Skuteczność: w testach na 28 popularnych LLM uzyskano zwykle >98% AUPRC; przy realnym niezrównoważeniu 10 000:1 możliwa była precyzja 100% przy 5–50% recall dla modelu-celu.
- Mitigacje: padding losowy, batchowanie tokenów, wtrysk „szumu”/syntetycznych pakietów; część dostawców wdrożyła już obrony (np. dodatkowe pole losowego tekstu w streamie w Azure/OpenAI, parametr „p” w Mistral).
- Ryzyko: ujawnienie kontekstu/tematu, nie treści; wystarcza pasywny podsłuch. Brak dowodów użycia w naturze, ale ryzyko praktyczne oceniono jako realne.
Kontekst / historia / powiązania
„Whisper Leak” wpisuje się w nową falę ataków side-channel na LLM. W 2024 r. pokazano m.in.:
- wyciek długości tokenów i częściową rekonstrukcję odpowiedzi ze strumieni TLS,
- zdalne ataki timingowe wynikające z optymalizacji inferencji (np. speculative decoding),
- korelację liczby tokenów wyjściowych z cechami wejścia,
- wycieki przez cache sharing (prefix/semantic caching).
Autorzy odnoszą się do tych prac i przesuwają akcent z rekonstrukcji treści na klasyfikację tematu.
Analiza techniczna / szczegóły luki
Model zagrożeń
- Adwersarz pasywny z widocznością ruchu sieciowego (ISP, wspólne Wi-Fi, lokalny admin, przejęty router).
- Brak dostępu do kluczy, brak aktywnej ingerencji — podgląd samych metadanych.
Wektor i cecha charakterystyczna
- LLM w streamingu wysyła wynik porcjami; wewnętrzna dynamika generowania (autoregresja, batching, UX-owe „flushowanie”) przekłada się na sekencję rozmiarów pakietów i interwałów.
- TLS (AES-GCM/ChaCha20) zachowuje relację długości: ciphertext ≈ plaintext + stała, więc rozmiar pakietu zdradza „długość tokenu/porcji”. Połączenie size + timing buduje fingerprint tematu.
Metodologia badaczy
- Zebrano ślady dla 28 usług LLM; zdefiniowano cel binarny: „pytania o legalność prania pieniędzy” vs. szum (11 716 losowych pytań z Quora).
- Trzy klasyfikatory: LightGBM, Bi-LSTM, BERT-based na sekwencjach (size/time bucketed).
- Miara: AUPRC (ze względu na silne niezrównoważenie zbioru).
Wyniki (wybrane)
- >98% AUPRC dla wielu modeli/prowadzących.
- W symulacji 10 000:1 (1 rozmowa wrażliwa na 10 000 zwykłych) uzyskano przypadki 100% precision przy 5–50% recall — czyli zero false positives przy „wyłapywaniu” części rozmów o temacie-celu.
Status vendorów i mitigacje
- OpenAI, Microsoft (Azure), Mistral, xAI: wdrożone obrony (m.in. losowy „obfuscation field” do streamu; parametr „p” w Mistral).
- Część innych dostawców według The Register nie wdrożyła poprawek lub była nie-responsywna (m.in. wskazywani: Anthropic, AWS, DeepSeek, Google; uwaga: AWS zakwestionował skuteczność ataku w swojej architekturze).
Praktyczne konsekwencje / ryzyko
- Prywatność użytkowników i compliance: wykrywanie tematów rozmów może samo w sobie stanowić dane wrażliwe (polityka, zdrowie, poglądy).
- Ryzyko profilowania i selekcji: przy precyzji 100% atak nadaje się do filtrowania ruchu pod kątem „zainteresowań” (np. AML, protesty).
- Bezpieczeństwo korporacyjne: sygnały „intencji” (np. rozmowy o produktach, planach, incydentach) mogą ujawnić strategie lub incydenty nawet bez wycieku treści. CSO Online ostrzega wprost przed ryzykiem dla przedsiębiorstw.
Rekomendacje operacyjne / co zrobić teraz
Dla użytkowników końcowych
- Unikaj rozmów na wysoce wrażliwe tematy na niezaufanych sieciach; jeśli musisz — wyłącz streaming (gdy dostawca na to pozwala).
- VPN dodaje warstwę tunelowania i utrudnia korelację ruchu per usługa, choć nie eliminuje samego side-channelu po stronie dostawcy.
- Preferuj dostawców, którzy wdrożyli mitigacje (padding/obfuscation, batching).
Dla SOC/Blue Team / architektów
- Polityka proxy/DLP: jeżeli organizacja korzysta z LLM-ów chmurowych, wymuś nie-streaming dla wrażliwych przepływów (np. przez nagłówki/parametry API).
- Segmentacja i bramki egress: kieruj ruch LLM przez pojedynczy egress (NAT/Proxy) i uśredniaj przepływy, by utrudnić fingerprinting per użytkownik.
- Traffic shaping (u Ciebie): rozważ grupowanie i bursty dla ruchu wychodzącego do hostów LLM (koszt: latency).
Przykładowe szkice (Linux, dla ruchu do API LLM — przykład edukacyjny):
# 1) Oznacz ruch do domen LLM (tu: fikcyjne *.api.llm.example)
ipset create llm dsthash
ipset add llm 203.0.113.10
ipset add llm 203.0.113.11
# 2) Przekieruj do kolejki HTB o docelowym kształtowaniu "burst + coalesce"
tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20mbit ceil 100mbit
tc qdisc add dev eth0 parent 1:30 handle 30: fq maxrate 20mbit flow_limit 1000 # uśrednianie/koalescencja
# 3) (Opcj.) Dodaj minimalny jitter (uwaga na SLA)
tc qdisc replace dev eth0 parent 1:30 netem delay 15ms 5ms distribution normalUwaga: to nie uniemożliwia ataku (napastnik przy ISP nadal widzi wzorce), ale zmniejsza rozróżnialność na wyjściu organizacji kosztem opóźnień.
- Monitoring anomalii TLS: buduj profile czasowo-rozmiarowe własnych połączeń z dostawcą; wykrywaj nietypowe „sondowanie” (wiele krótkich zapytań o podobnych strukturach, typowe dla zbierania datasetu treningowego napastnika).
Przykład prostego zbierania cech (packet size / IAT) do SIEM:
# Zeek: ekstrakcja metadanych TLS → TSV/JSON do SIEM
zeek -i eth0 tls
# W logach ssl.log / conn.log masz ts, id.resp_h, resp_p, orig_bytes, resp_bytes, resp_pkts, duration
# Inter-arrival time można przybliżyć z ts + duration + liczby pakietów; dokładniej użyj pcap + tshark:
tshark -r capture.pcap -Y "tls && ip.dst==203.0.113.10" \
-T fields -e frame.time_epoch -e frame.len -e tcp.streamDla dostawców / twórców integracji
- Padding/obfuscation: dodaj losowy „wypełniacz” (serwerowy) do porcji streamu; Microsoft i OpenAI wdrożyli pole z losową sekwencją tekstu. Mistral wprowadził parametr
pdo API o podobnym efekcie. - Batchowanie tokenów: wysyłaj grupy tokenów zamiast pojedynczych; zmniejsza liczbę obserwowalnych zdarzeń (trade-off: płynność UX).
- Wtrysk pakietów syntetycznych: wstrzykuj pakiety o losowych rozmiarach/odstępach, by zniszczyć korelację size/IAT.
- Tryb non-streaming jako opcja „high-privacy”.
- Audyt side-channel: udostępnij profil ruchu i parametry obrony w dokumentacji (transparency).
Różnice / porównania z innymi przypadkami
| Atak side-channel na LLM | Co wycieka | Na czym bazuje | Status/uwagi |
|---|---|---|---|
| Whisper Leak | Temat rozmowy (klasyfikacja) | Rozmiary pakietów + timing w streamingu | Skuteczny między dostawcami; częściowe mitigacje wdrożone. |
| Token-length leak (Weiss 2024) | Sekwencja długości tokenów → rekonstrukcja fragmentów | Rozmiary pakietów | Dotyczy stricte streamingu token-by-token. |
| Remote timing (Carlini/Nasr 2024) | Cechy promptu przez timing optymalizacji | Różnice czasu generacji | Zależny od mechanizmów typu speculative decoding. |
| Output-token count (Zhang 2024) | Atrybuty wejścia (np. język) | Łączny czas/liczba tokenów | Nie wymaga pełnego streamu. |
| Cache-sharing timing (Zheng 2024) | Semantyka przez trafienia cache | Opóźnienia przy współdzieleniu | Wymaga współdzielenia zasobów. |
Podsumowanie / kluczowe wnioski
- TLS chroni treść, nie metadane. W dobie LLM-ów metadane w streamingu wystarczą, by z dużą pewnością odgadnąć temat rozmowy.
- Ryzyko jest praktyczne: wysokie AUPRC i scenariusz 10 000:1 z precyzją 100% (częściowo) pokazują użyteczność dla cenzury/surveillance.
- Mitigacje istnieją, ale to trade-off między prywatnością a latencją/kosztem. Część ekosystemu już wdrożyła obrony, część — nie.
- Działaj warstwowo: polityka (non-streaming dla wrażliwych tematów), shaping, wybór dostawców z paddingiem, monitoring i edukacja użytkowników.
Checklist dla CISO/SOC (do wydrukowania):
- Zidentyfikowane przypadki użycia LLM z danymi wrażliwymi.
- Wymuszony tryb non-streaming dla tych przepływów (jeśli dostępny).
- Ocena dostawców pod kątem paddingu/parametrów obrony (Azure/OpenAI/Mistral/xAI — tak).
- Shaping/jitter na egress (świadomie, z testami SLA).
- Runbook SIEM: kolekcja metryk size/IAT dla TLS → detekcja sondowań.
- Program „AI side-channel testing” w SecEng/Red Team.
Źródła / bibliografia
- SecurityWeek — omówienie badań i zaleceń (11 listopada 2025). (SecurityWeek)
- Microsoft Security Blog — pełny opis metody, wyniki i mitigacje (7 listopada 2025). (Microsoft)
- ArXiv — artykuł techniczny „Whisper Leak: a side-channel attack on Large Language Models” (listopad 2025). (arXiv)
- The Register — status dostawców, komentarze badaczy i aktualizacja od AWS (11 listopada 2025). (The Register)
- CSO Online — konsekwencje dla przedsiębiorstw i streszczenie mitigacji (10 listopada 2025). (CSO Online)
