„Whisper Leak” — atak kanałem bocznym na LLM, który ujawnia temat rozmowy mimo TLS

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja luki
2 W skrócie
3 Kontekst / historia / powiązania
4 Analiza techniczna / szczegóły luki
5 Praktyczne konsekwencje / ryzyko
6 Rekomendacje operacyjne / co zrobić teraz
7 Różnice / porównania z innymi przypadkami
8 Podsumowanie / kluczowe wnioski
9 Źródła / bibliografia

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 normal

Uwaga: 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.stream

Dla 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 p do 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)