نسخهٔ دیسک، کنترل زندهٔ سرور و دسترسی به گوشی سه سناریوی متفاوت‌اند؛ یک تضمین کلی برای هر سه کافی نیست.
اگر سرور یک پیام‌رسان تصرف شود، پاسخ دقیق به «چه چیزی فاش می‌شود؟» به داده‌های ذخیره‌شده، محل کلیدها و نوع دسترسی مهاجم بستگی دارد. گرفتن یک نسخه از دیسک با کنترل زندهٔ سرویس و مسیر انتشار برنامه یکسان نیست.
این مقاله یک سناریوی فرضی را با تکیه بر مستندات عمومی لیوارا بررسی می‌کند. دربارهٔ محل دیتاسنترهای لیوارا، وقوع مصادره یا تضمین کارکرد سرویس در قطعی اینترنت ادعایی نمی‌کند. رمزنگاری محتوا، دسترس‌پذیری شبکه و امنیت زیرساخت موضوعات جداگانه‌اند.
ابتدا نوع دسترسی را مشخص کنیم
نسخهٔ ذخیره‌شدهٔ سرور: مهاجم به فایل‌ها، پایگاه داده یا پشتیبان‌هایی که در آن نسخه وجود دارند دسترسی پیدا می‌کند. اگر محتوای خصوصی درست روی دستگاه رمز شده باشد و کلید بازکردن آن در اختیار سرور نباشد، داشتن آن نسخه به‌تنهایی متن گفتگو را آشکار نمی‌کند.
کنترل فعال سرویس: مهاجم می‌تواند علاوه بر خواندن داده‌های موجود، برخی درخواست‌ها را متوقف کند، دادهٔ قدیمی برگرداند یا رفتار بخش‌های تحت کنترل را تغییر دهد. بررسی هویت مخاطب، کنترل نسخه و صحت کلاینت در این سناریو اهمیت بیشتری دارد.
دسترسی هم‌زمان به دستگاه: گوشی باز، بدافزار یا نسخهٔ قابل‌خواندن نزد یک عضو گفتگو می‌تواند محتوا را از مسیری کاملاً متفاوت آشکار کند. مدل تهدید لیوارا نیز حفاظت از دستگاه باز یا آلوده را تضمین نمی‌کند.
چه داده‌هایی طبق مستندات لیوارا روی سرور دیده می‌شوند؟
صفحهٔ امنیت لیوارا، با برچسب نسخهٔ 0.1.68، محتوای چت مستقیم تحت LVR1 و گروه خصوصیِ سازگار تحت LGS1 را از اطلاعات عملیاتی جدا می‌کند. همان صفحه می‌گوید گروه قدیمیِ ناسازگار به‌طور آشکار خارج از E2EE می‌ماند؛ بنابراین باید وضعیت همان گفتگو را بررسی کرد.
| دستهٔ داده | مرز مستندشده و پیامد احتمالی |
|---|---|
| متن و پیوستِ گفتگوی محافظت‌شده | سرور نسخهٔ رمز‌شده را نگه می‌دارد؛ خواندن آن نیازمند کلید مناسب است |
| فرادادهٔ ارتباط | اطلاعاتی مانند طرفین، زمان، اندازه و وضعیت تحویل در دسترس سرویس است |
| عضویت گروه | بخشی از اطلاعات و اختیار عملیاتی سرور است |
| کانال عمومی | محتوای عمومی و قابل‌خواندن برای سرور است |
| بستهٔ بازیابی هویت v7 | پیش از بارگذاری رمز می‌شود و راز بازیابی جداگانه لازم دارد |
| حالت ضبط اختیاری روی سرور | با نشان REC از حالت E2EE متمایز است و نباید خصوصی‌بودن سرتاسری برای آن فرض شود |
کد LSS1 برای حفاظت فراداده در مستندات ذکر شده، اما به ارسال عادی پیام متصل نیست. وجود نام یک پروتکل در پروژه دلیل فعال‌بودن آن در تمام ارتباطات نیست.
این جدول شرح ادعای محصول است، نه نتیجهٔ آزمایش مصادرهٔ واقعی یا ممیزی مستقلِ تمام نسخه‌های پایگاه داده.
فراداده چقدر می‌تواند مهم باشد؟
اطلاعاتی دربارهٔ ارتباط افراد، زمان‌ها و عضویت گروه‌ها ممکن است حتی بدون متن پیام حساس باشد. با این حال، عبارت «تمام گراف ارتباطی برای همیشه فاش می‌شود» بدون دانستن مدت نگهداری، پوشش لاگ‌ها و نسخهٔ دادهٔ به‌دست‌آمده دقیق نیست.
برای ارزیابی واقعی باید پرسید کدام فیلدها جمع‌آوری شده‌اند، چه مدت مانده‌اند و کدام نسخه‌های پشتیبان در دسترس‌اند. رمزنگاری محتوا به‌تنهایی سیاست نگهداری داده را تعیین نمی‌کند. همچنین نمی‌توان از معماری یک پیام‌رسان نتیجه گرفت که همهٔ پیام‌رسان‌ها الزاماً فرادادهٔ یکسانی نگه می‌دارند.
کنترل سرور چه خطری برای پیام‌های آینده دارد؟
در یک بررسی امنیتی باید دستکاری فهرست اعضا، ارائهٔ کلید هویت متفاوت، جلوگیری از به‌روزرسانی و تحویل کلاینت مخرب را جداگانه آزمود. اثر هرکدام به اعتبارسنجی سمت کلاینت، نمایش تغییرات و تأیید هویت بستگی دارد.
نمی‌توان بدون آزمون پیاده‌سازی گفت هر سرور تسخیرشده حتماً می‌تواند عضو مخفی اضافه کند؛ همان‌طور که نمی‌توان گفت کنترل فعال سرور هیچ اثری ندارد. برای گفتگوی حساس، تغییر غیرمنتظرهٔ هویت یا اعضا باید بررسی شود. مقایسهٔ اثرانگشت کلید با مخاطب از یک مسیر مستقلِ مورد اعتماد، نسبت به اعتماد صرف به نام نمایشی اطلاعات بیشتری می‌دهد.
اگر مهاجم کدی را که روی دستگاه اجرا می‌شود عوض کند، ممکن است متن را پیش از رمزشدن ببیند. به همین دلیل امنیت انتشار و به‌روزرسانی برنامه بخشی از این سناریو است، نه موضوعی بیرون از رمزنگاری.
پسا‌کوانتومی بودن چه چیزی را اضافه می‌کند؟
استاندارد FIPS 203 مؤسسهٔ NIST برای ML-KEM به استقرار راز مشترک کمک می‌کند. استفادهٔ درست از آن در یک ترکیب هیبریدی می‌تواند خطر برخی حملات آینده به تبادل کلید را کاهش دهد. این ویژگی جایگزین امنیت دستگاه، نگهداری محدود فراداده یا کنترل دسترسی سرور نمی‌شود.
آزمایشگاه Proof Lab نیز تنها برخی عملیات محلی P-256، HKDF و AES-GCM را نمایش می‌دهد و ترکیب کامل LVR1/LGS1 را خارج از آن آزمایش می‌داند. نتیجهٔ موفق آن تضمین مقاومت کل محصول در برابر تصرف زیرساخت نیست.
در ارزیابی یا رخداد واقعی چه کنیم؟
- نوع دسترسی و اطلاعات تأییدشده را ثبت کنید؛ شایعهٔ اختلال را با رخداد امنیتی قطعی یکی ندانید.
- نسخهٔ برنامه و وضعیت رمزنگاری همان گفتگو را بررسی کنید.
- تغییرات هویت، اعضای گروه و نشست‌های ناشناس را از مسیر رسمی بررسی کنید.
- راز بازیابی، رمز عبور و محتوای خصوصی را برای «بررسی امنیت» در اختیار افراد ناشناس نگذارید.
- برای خطر جدی یا موضوع حقوقی، از متخصص مناسب کمک بگیرید و اقدامات برگشت‌ناپذیر را بر اساس یک مقاله انجام ندهید.
نتیجهٔ قابل‌اتکا باید مشخص کند کدام داده، در کدام نسخه و مقابل کدام دسترسی محافظت شده است. عبارت «سرور مصادره شود هم هیچ اتفاقی نمی‌افتد» جای این پاسخ را نمی‌گیرد.
