Tag: Privacy

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

1. Unikaj rozmów na wysoce wrażliwe tematy na niezaufanych sieciach; jeśli musisz — wyłącz streaming (gdy dostawca na to pozwala).
2. VPN dodaje warstwę tunelowania i utrudnia korelację ruchu per usługa, choć nie eliminuje samego side-channelu po stronie dostawcy.
3. 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

Podsumowanie / kluczowe wnioski

1. TLS chroni treść, nie metadane. W dobie LLM-ów metadane w streamingu wystarczą, by z dużą pewnością odgadnąć temat rozmowy.
2. Ryzyko jest praktyczne: wysokie AUPRC i scenariusz 10 000:1 z precyzją 100% (częściowo) pokazują użyteczność dla cenzury/surveillance.
3. Mitigacje istnieją, ale to trade-off między prywatnością a latencją/kosztem. Część ekosystemu już wdrożyła obrony, część — nie.
4. 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)