Whisper Leak  یک حمله side-channel  است که با مشاهدهی ترافیک TLS بین کاربر و سرویس LLM، و تحلیل دقت‌محورِ «اندازه بسته‌ها» و «فواصل زمانی»، قادر است موضوع (topic) گفت‌وگو را با دقت بالایی پیش‌بینی کند. حتی وقتی محتوای پیام‌ها رمزگذاری شده باشد.

تهدید و مدل تهدید (Threat model)

✔️ حمله‌گر:   passive.کاربر/ناظر شبکه‌ای که می‌تواند ترافیک رمزگذاری‌شده را ببیند (ISP، مانیتور داخلی، ناظر روی لینک شبکه، یا مجرم داخل شبکه).

✔️ هدف: استنباط موضوع یا دسته‌ کلیِ prompt (مثلاً «مالی»، «سیاسی»، «دارویی») نه بازیابی متن کامل.

✔️ پیش‌فرض‌ها: سرویس پاسخ‌ها را به‌صورت streaming ارسال می‌کند (token یا group token streaming). حمله‌گر به نمونه‌های آموزشی برای همان سرویس/پیاده‌سازی دسترسی یا توانایی تولید داده آموزشی مشابه دارد .

چطور کار می‌کند؟ پایپ‌لاین فنی حمله

مشاهده و ضبط ترافیک

حمله‌گر جریان TLS را ضبط می‌کند (pcap یا flow) و جهت بسته‌ها (server→client) را تفکیک می‌کند. در حالت streaming، سرور معمولاً پاسخ را در چند بسته متوالی ارسال می‌کند که الگوهای اندازه/فاصله تولید می‌کنند.

استخراج ویژگی‌ها (feature extraction)

از جریانِ بسته‌ها ویژگی‌هایی استخراج می‌شود، مثلاً:

✔️ توالی اندازه بسته‌ها (bytes per packet)

✔️ فواصل زمانی بین بسته‌ها (inter-arrival times)

✔️ الگوی bursts (تعداد بسته‌های پیاپی سمت سرور)

✔️ آماره‌های خلاصه: mean/std/entropy/quantiles طول بسته‌ها و زمان‌ها
سپس این توالی‌ها یا بردارهای آماری نرمال‌سازی/باکت‌بندی می‌شوند تا ورودی مدل قرار گیرند.

آموزش مدل طبقه‌بندی (offline)

با یک دیتاست برچسب‌خورده از جلسات (labels  = موضوعات) مدل‌های متنوع بسته به نوع ویژگی استفاده می‌شوند: LightGBM برای ویژگی‌های آماری، Bi-LSTM/Transformer برای توالی‌های زمانی. مقاله Whisper Leak نشان می‌دهد که در بسیاری از حالت‌ها می‌توان به دقت (AUPRC/Precision) بسیار بالا رسید.

استنتاج (online passive inference)

وقتی حمله‌گر ترافیک جدید را می‌بیند، همان ویژگی‌گیری را اجرا و مدل را برای پیش‌بینی موضوع اعمال می‌کند. با افزایش نمونه‌های آموزشی از یک هدف خاص (مثلاً users→service) عملکردِ مدل به‌مرور بهتر می‌شود.

نتایج و اهمیت عملی

محققان مایکروسافت و تیم‌های همکار گزارش داده‌اند که برای برخی موضوع‌ها دقت طبقه‌بندی خیلی بالا (در مواردی ≈۹۸٪) قابل دستیابی است. برای برخی موضوع‌ها درصد بازیابی (recall) ممکن است کمتر (مثلاً ۵–۲۰٪) باشد، اما precision در برخیِ موضوعات حساس بسیار بالا است. این یعنی حتی اگر فقط بخش کوچکی از گفتگوها بازیابی شوند، آن‌ها با دقت بالا شناسایی می‌شوند که برای ناظران (مانند دولت‌ها یا ISPهای معین) بسیار کاربردی است.

چرا رمزگذاری (TLS) کافی نیست

TLS  محافظتِ محتوایی می‌کند اما متادیتا شبکه اندازه بسته و زمان ارسال قابل مشاهده است و اطلاعات ساختاری درباره نحوه تولید پاسخ (طول پاسخ، مکث‌ها، گروه‌بندی توکن‌ها) را لو می‌دهد. این همان کلاس قدیمیِ مشکلات side-channel است که حالا به دنیای LLMها منتقل شده است.

راهکارهای فنی (Mitigations) مزایا، معایب و پیاده‌سازی پیشنهادی

نکته مهم: هیچ یک از راهکارها به‌تنهایی «کامل» نیست. ترکیب چند رویکرد و انتخابِ مناسب برای گره‌های مختلف معمولا لازم است. مقاله تحقیقاتی و مایکروسافت هم همین نتیجه را نشان داده‌اند.

در سطح ارائه‌دهنده سرویس (LLM provider)

1. Random padding (پد کردن تصادفی بسته‌ها)

✔️ چه می‌کند: هر پاسخ را تا اندازه‌ای از پیش‌تعریف‌شده یا تصادفی پد (pad) می‌کند تا توالی اندازه‌ها یکنواخت‌تر شود.

✔️ مزایا: نسبت به حمله، سیگنال اندازه را مخدوش می‌کند.

✔️ معایب: مصرف پهنای‌باند و احتمال افزایش latency. هزینه عملیاتی برای provider .

✔️ پیاده‌سازی پیشنهادی :  adaptive padding با پارامترهای قابل تنظیم (min_size, max_noise) و فعال‌سازی برای کلاس‌های حساس یا کاربران سازمانی.

1. Token batching / grouped sending

✔️ چه می‌کند: به‌جای ارسال توکن به توکن، خروجی را در بلاک‌های ثابت یا متغیرِ از قبل تعیین‌شده ارسال می‌کند.

✔️ مزایا: از نشت توالی زمانی می‌کاهد (مخصوصا وقتی streaming توکن‌به‌توکن است).

✔️ معایب: ممکن است UX (تأخیر در دریافت اولین بخش پاسخ) را تغییر دهد. پیاده‌سازی برای real-time agents چالش‌زا است.

1. Packet injection / dummy traffic

✔️ چه می‌کند: ترافیک بی‌معنی یا بسته‌های دمی را بین بسته‌های واقعی وارد می‌کند تا توالی زمانی را به‌هم بزند.

✔️ مزایا: می‌تواند الگوهای زمانی را بسیار پرنویز کند.

✔️ معایب: افزایش ترافیک، پیچیدگی پیاده‌سازی در لایهٔ اپلیکیشن/شبکه و احتمال تداخل با QoS.

1. Edge/proxy mitigation

✔️ چه می‌کند: در لبه شبکه (CDN / reverse proxy) بسته‌ها را aggregate یا re-packetize می‌کنند تا تولید الگوهای قابل پیش‌بینی کاهش یابد.

✔️ مزایا: قابل اعمال برای همه‌ی ترافیک خروجی بدون نیاز به تغییر عمیق در مدل.

✔️ معایب: نیاز به هماهنگی با CDN/ISP و تأثیر بر latency. مایکروسافت به همکاری با سایر ارائه‌دهندگان برای پچ‌ها اشاره کرده است.

در سطح سازمان/مشتری

1. استفاده از مدل‌های on-prem / VPC-isolated برای گفتگوهای حساس

نگهداری مدل یا private instance در شبکه کنترل‌شده باعث می‌شود که یک ناظر خارجی (ISP) نتواند ترافیک را ببیند. (هزینه و پیچیدگی بیشتر اما مؤثر).

1. انتخاب ارائه‌دهنده‌ای که mitigations را فعال کرده

پیش از استفاده، از provider بپرسید که از چه countermeasures ای استفاده می‌کند (padding, batching, edge aggregation). چندین ارائه‌دهنده پس از افشای Whisper Leak اصلاحاتی عرضه کرده‌اند.

1. خط‌ مشی‌های استفاده (Policy)

طبقه‌بندیِ موضوعات حساس و منع استفاده از سرویس‌های عمومی LLM برای آنها؛ آموزش کارکنان برای اجتناب از گفتگوهای حساس روی شبکه‌های عمومی.

ترکیب و trade-offs

✔️ ترکیب padding + batching در اغلب موارد بهتر از هر کدام به‌تنهایی است.

✔️ همه این‌ها هزینه (پهنای‌باند، latency، UX) دارند .باید SLA و موارد حساس سازمان را مبنای تصمیم‌گیری قرار داد.

تشخیص، مانیتورینگ و آزمایش (Detection & Validation)

برای ارائه‌دهندگان:

اجرای تست‌های red-team و privacy-testing (شبیه‌سازی Whisper Leak) برای ارزیابی اثربخشی mitigations. استفاده از metrics مانند AUPRC/precision در شرایط noisy .

برای سازمان‌ها:

✔️ در صورت استفاده از سرویسِ خارجی، مانیتورینگ ترافیک خروجی برای الگوهای غیرمعمول و بررسی اینکه آیا provider padding/batching فعال است.

✔️ تست‌های کنترل‌شده (generate labeled prompts) برای ارزیابی اینکه آیا شبکه/ISP فرضی می‌تواند موضوعات را تشخیص دهد.

ابزارها:

تولید pcapهای آزمایشی، استخراج ویژگی‌ها (packet sizes, iat) و اجرای مدل‌های ساده (LightGBM/Bi-LSTM) برای بررسی leakage در محیط خودتان.

نمونه فنی ساده — استخراج ویژگی Python-style

# فرض: server_packets = list of packets (with payload length and timestamp) filtered for server->client

sizes = [p.length for p in server_packets]

times = [p.timestamp for p in server_packets]

iat = [times[i+1]-times[i] for i in range(len(times)-1)]


# خلاصه‌سازی (stat features)

features = {

  'mean_size': np.mean(sizes),

  'std_size': np.std(sizes),

  'max_burst': max_consecutive_server_packets(sizes),

  'mean_iat': np.mean(iat),

  # ... یا توالی bucketized sizes for LSTM

}

# سپس feed به LightGBM یا ساخت sequence windows برای Bi-LSTM

این فقط الگویی برای شروع است. دیتاست واقعی نیاز به پیش-پردازش و همسان‌سازی بیشتر دارد.

توصیه‌های عملی و checklist برای اجرا

برای Provider (LLM owner)

فوری: ارزیابی امکان فعال‌سازی token batching یا padding برای سرویس‌های استریم.

پیاده‌سازی آزمایشی: adaptive padding با پارامترهای قابل تنظیم.

کار با CDN/Proxyها برای edge aggregation.

 انجام red-team / privacy tests مطابق با دیتاست‌های واقعی.

برای سازمان / مشتری

طبقه‌بندی موضوعات حساس و تعیین policy: چه چیزهایی نباید روی سرویس عمومی پرسیده شود.

در صورت نیاز به محرمانگی بالا: انتخاب on-prem یا VPC isolated models.

از ارائه‌دهنده درخواست کنید که mitigationها را روشن کند و نتایج تست آن‌ها را ارائه دهد.

آموزش کاربران درباره خطر متادیتا و اجتناب از گفتگوهای حساس در شبکه‌های عمومی.

محدودیت‌ها و چشم‌انداز

Whisper Leak ✔️نیازمند یک ناظر شبکه «در مسیر» است. برای کار در سطح اینترنتِ باز نیاز به دید مناسب وجود دارد.

✔️ دفاع کامل ممکن است هزینه‌بر باشد. تمرکز منطقی روی حفاظت از گفتگوهای حساس و ترکیب چند mitigation است.

✔️ این نوع تحقیقات نشان می‌دهد که حریم خصوصی در عصر سرویس‌های توزیع‌شدهLLM نیازمند تجدیدنظر در اصول قدیمی رمزگذاری است: متادیتا هم تهدید است.