اشتراک X IN
رمزگذاری سرتاسری نفوذ به سرور را ناممکن نمی‌کند؛ کاری می‌کند که سرورِ تصاحب‌شده کلید خواندن مکالمات خصوصی را نداشته باشد.

اگر سرور پیام‌رسان هک شود، مهاجم چه می‌بیند؟ پاسخ به معماری بستگی دارد: داده‌های حساب و فراداده‌هایی مانند فرستنده، مقصد و زمان تحویل ممکن است افشا شوند، اما دسترسی به گذرواژه، کلیدها و محتوای خصوصی قطعی نیست. در یک پیام‌رسان مقاوم در برابر نفوذ سرور، تصاحب پایگاه داده به‌تنهایی نباید برای خواندن پیام‌های مستقیم و گروهی خصوصی یا بازیابی گذرواژه کافی باشد.

نکات کلیدی

  • هک سرور پیام‌رسان می‌تواند داده‌های حساب و فراداده مسیریابی را افشا کند، حتی اگر محتوای خصوصی رمزگذاری سرتاسری شده باشد.
  • ذخیره هش گذرواژه بهتر از ذخیره متن آشکار است، اما در برابر حدس آفلاین گذرواژه‌های ضعیف مصونیت کامل نمی‌دهد.
  • SRP دانستن گذرواژه را بدون ارسال خود گذرواژه اثبات می‌کند، اما امنیت حساب همچنان به انتخاب گذرواژه قوی و حفاظت از دستگاه وابسته است.
  • رمزگذاری سمت سرور مانع مهاجمی نمی‌شود که هم داده‌های رمزگذاری‌شده و هم کلید رمزگشایی سرور را تصاحب کرده است.
  • در Livara، پیام‌های مستقیم LVR1 و گروه‌های خصوصی LGS1 سرتاسری رمزگذاری می‌شوند؛ کانال‌ها عمداً برای سرور خواندنی‌اند تا محتوای سوءاستفاده‌گر بررسی و حذف شود.
  • رسانه تماس Livara پساکوانتومی نیست و پروتکل‌های Livara نیز مستقل ممیزی نشده‌اند.

هک سرور پیام رسان چه اطلاعاتی لو می رود؟

هر چیزی که سرور بتواند به‌صورت آشکار بخواند، همراه با داده‌های عملیاتی ذخیره‌شده، ممکن است در دسترس مهاجم قرار گیرد. «فراداده» یعنی اطلاعات پیرامون ارتباط، نه متن آن؛ برای نمونه، چه حسابی به کدام مقصد پیام فرستاده و پیام چه زمانی تحویل شده است.

سروری تصاحب‌شده در مرکز دیده می‌شود که داده‌های حساب و مسیرهای فراداده را در دسترس دارد، در حالی که متن پیام‌های رمزگذاری‌شده و کلیدهای روی دو تلفن جدا باقی مانده‌اند.

دامنه افشا به سطح دسترسی مهاجم بستگی دارد. یک نسخه ربوده‌شده از پایگاه داده با کنترل کامل سرور فعال یکسان نیست: مهاجمی که کد سرویس، حافظه یا سامانه استقرار را نیز در اختیار دارد، ممکن است نشست‌ها را بدزدد، پاسخ‌های مخرب بفرستد یا داده‌های تازه گردآوری کند. رمزگذاری سرتاسری می‌تواند محتوای خصوصی را از سرور پنهان کند، اما دستگاه آلوده یا هویت تأییدنشده همچنان نقطه شکست است. برای تفکیک محتوا از اطلاعات جانبی، راهنمای فراداده در پیام‌رسان‌ها را بخوانید.

در Livara، فراداده استاندارد مسیریابی شامل فرستنده، مقصد و زمان تحویل برای همگام‌سازی بلادرنگ دستگاه‌ها ذخیره می‌شود. بنابراین نفوذ به زیرساخت می‌تواند این داده‌ها را آشکار کند. پیام‌های مستقیم و گروه‌های خصوصی به‌صورت سرتاسری رمزگذاری می‌شوند، اما این ادعا شامل کانال‌ها نمی‌شود. شرح این مرزها در مدل تهدید Livara آمده است.

امنیت پیام رسان در نشت پایگاه داده میان پنج معماری چه تفاوتی دارد؟

تفاوت اصلی این است که آیا پایگاه داده به‌تنهایی برای ورود به حساب یا خواندن پیام‌ها کافی است. این مقایسه معماری امنیت پیام رسان، طیفی از «همه‌چیز در اختیار سرور» تا «سرور حامل متن رمز» را نشان می‌دهد.

معماری مهاجم با تصاحب پایگاه داده چه می‌بیند؟ آیا محتوای خصوصی خواندنی است؟ محدودیت اصلی
۱. ذخیره آشکار حساب‌ها، گذرواژه‌ها، پیام‌ها و فراداده بله هیچ مرز رمزنگاری معناداری وجود ندارد
۲. هش گذرواژه، پیام آشکار هش‌ها، پیام‌ها و فراداده بله گذرواژه ضعیف ممکن است آفلاین حدس زده شود
۳. رمزگذاری سمت سرور متن رمز و فراداده؛ کلیدها ممکن است در بخش دیگری از زیرساخت باشند اگر مهاجم کلید سرور را نیز به دست آورد، بله سرور برای ارائه خدمت قادر به رمزگشایی است
۴. رمزگذاری سرتاسری با نسخه پشتیبان ضعیف متن رمز و فراداده؛ احتمالاً مسیر بازیابی آسیب‌پذیر چت زنده معمولاً نه؛ نسخه پشتیبان شاید امنیت تاریخچه به طراحی بازیابی وابسته است
۵. احراز هویت SRP، رمزگذاری سرتاسری و بازیابی رمزگذاری‌شده داده حساب، متن رمز و فراداده با نسخه پایگاه داده به‌تنهایی، نه دستگاه، هویت مخاطب و عبارت بازیابی باید امن بمانند

در معماری پنجم Livara، SRP یا «پروتکل گذرواژه از راه دور امن» دانستن گذرواژه را بدون فرستادن خود گذرواژه روی شبکه اثبات می‌کند. پیام‌های مستقیم با LVR1 و گروه‌های خصوصی با LGS1 سرتاسری رمزگذاری می‌شوند؛ طبق طراحی اعلام‌شده Livara، پایگاه داده سرور کلید لازم برای خواندن آن مکالمات را در خود ندارد.

این جدول تضمین نمی‌کند که هر محصولی با برچسب «سرتاسری» تمام لایه‌ها را درست پیاده کرده است. دامنه رمزگذاری، مدیریت کلید، احراز هویت مخاطب، نسخه پشتیبان و انتشار نرم‌افزار باید جداگانه بررسی شوند. ۱۲ پرسش برای ارزیابی پیام‌رسان امن نقطه شروع مناسبی است.

SRP در نشت اطلاعات چگونه از گذرواژه محافظت می‌کند؟

SRP مانع ارسال مستقیم گذرواژه به سرور می‌شود. کاربر به‌جای تحویل گذرواژه، دانستن آن را از طریق یک تبادل رمزنگاری اثبات می‌کند. مشخصات اصلی این پروتکل در RFC 5054 منتشرشده از سوی IETF آمده است. در نتیجه، شنود تبادل ورود یا سرقت لاگی که متن گذرواژه را ثبت نکرده باشد، نباید خود گذرواژه را آشکار کند.

Livara از SRP برای اثبات دانستن گذرواژه بدون ارسال آن استفاده می‌کند. این طراحی خطر انتقال مستقیم گذرواژه را کاهش می‌دهد، اما گذرواژه ضعیف را قوی نمی‌سازد و بدافزار روی دستگاه می‌تواند ورودی کاربر را پیش از اجرای پروتکل سرقت کند.

SRP با رمزگذاری پیام تفاوت دارد. این پروتکل از فرایند ورود محافظت می‌کند؛ LVR1 و LGS1 از محتوای مکالمه خصوصی. معماری خوب هر دو مسئله را جداگانه حل می‌کند، زیرا امن‌بودن ورود به‌تنهایی مانع خواندن پیام‌هایی نمی‌شود که به‌صورت آشکار ذخیره شده‌اند.

آیا پیام‌رسان مقاوم در برابر نفوذ سرور محتوای خصوصی را حفظ می‌کند؟

اگر کلیدهای لازم برای رمزگشایی نزد دستگاه‌های طرفین بمانند و سرور فقط متن رمز را حمل کند، تصاحب پایگاه داده به‌تنهایی نباید محتوای پیام‌های خصوصی را آشکار کند. بااین‌حال، فراداده، دستگاه آلوده، تعویض مخفیانه کلید هویت و نسخه پشتیبان ضعیف همچنان خطر ایجاد می‌کنند.

طبق مشخصات Livara، LVR1 برای پیام مستقیم یک دابل‌رتچت هیبریدی است که رتچت ECDH P-256 و رتچت دوره‌ای ML-KEM-768 را ترکیب می‌کند. NIST در FIPS 203 استاندارد ML-KEM را مشخص کرده است. هدف این طراحی محدودکردن اثر افشای کلید و بازیابی محرمانگی پیام‌های بعدی پس از خروج مهاجم است. این توضیح، جای تحلیل یا ممیزی مستقل پیاده‌سازی را نمی‌گیرد؛ پروتکل‌های Livara مستقل ممیزی نشده‌اند.

این ویژگی به رسانه تماس تعمیم ندارد: رسانه تماس Livara پساکوانتومی نیست.

طبق مشخصات Livara، LGS1 برای گروه‌های خصوصی از کلید فرستنده استفاده می‌کند و هر کلید فرستنده را در پاکت‌های جفت‌به‌جفت LVR1 می‌بندد. متن، ویرایش، عکس، ویدئو، فایل، زیرنویس و پیام صوتی گروه پوشش داده می‌شوند. هر پیوست نیز پیش از بارگذاری با یک کلید محتوای تصادفی ۳۲‌بایتی تازه رمز می‌شود و کلید درون LVR1 یا LGS1 انتقال می‌یابد.

این حفاظت شامل کانال‌ها نمی‌شود. کانال Livara یک جریان پخش برای مخاطب نامحدود است و عمداً برای سرور خواندنی است تا محتوای گزارش‌شده بررسی و کانال‌های سوءاستفاده‌گر حذف شوند. مرزهای امنیتی Livara این تمایز و محدودیت‌های محصول را شرح می‌دهد.

نسخه پشتیبان و بازیابی پس از هک سرور چه نقشی دارند؟

نسخه پشتیبان می‌تواند معماری امن چت را دور بزند: اگر سرور نتواند پیام زنده را بخواند اما بتواند تاریخچه بازیابی‌شده را رمزگشایی کند، نفوذ همچنان محتوای خصوصی را در معرض خطر می‌گذارد. پس ادعای رمزگذاری سرتاسری بدون توضیح درباره بازیابی کامل نیست.

Meta در مستند مهندسی Backup Key Vault توضیح می‌دهد که نسخه پشتیبان سرتاسری رمزگذاری‌شده WhatsApp می‌تواند با گذرواژه یا کلید ۶۴رقمی محافظت شود و سامانه برای محدودکردن تلاش‌های بازیابی از زیرساخت HSM استفاده می‌کند. این مدل وابستگی به زیرساخت سخت‌افزاری و سازوکار استقرار را حذف نمی‌کند؛ آن را به بخشی از مرز اعتماد تبدیل می‌کند.

این نمونه نشان می‌دهد عبارت «ذخیره ابری رمزگذاری‌شده» به‌تنهایی کافی نیست. باید پرسید کلید بازیابی کجاست، چه کسی می‌تواند تلاش‌های بازیابی را کنترل کند و چه شواهدی درباره استقرار ارائه شده است.

طبق مستندات Livara، بازیابی رمزگذاری‌شده v7 هویت رمزنگاری کاربر را زیر یک کلید بازیابی ۲۵۶‌بیتی مشتق‌شده از عبارت بازیابی مهروموم می‌کند. در این مدل، سرقت پایگاه داده به‌تنهایی نباید این هویت را باز کند؛ اما افشای عبارت بازیابی یا دسترسی به دستگاهی که آن را نمایش می‌دهد، این مرز را تضعیف می‌کند.

پس از نفوذ به سرور، کاربر چگونه هویت و نرم‌افزار را بررسی کند؟

کاربر باید کلید مخاطب و اصالت فایل برنامه را از مسیری مستقل بررسی کند، زیرا رمزگذاری قوی در برابر نرم‌افزار دست‌کاری‌شده یا تعویض تأییدنشده هویت کافی نیست. این بررسی‌ها نفوذ را خنثی نمی‌کنند، اما تغییرات را آشکارتر می‌سازند.

شماره‌های ایمنی v3 در Livara به دو نفر اجازه می‌دهند اثرانگشت کلیدها را خارج از همان چت مقایسه کنند. اگر شماره تغییر کرده باشد، پیش از ادامه مکالمه حساس باید علت آن، مانند تعویض دستگاه یا بازیابی حساب، از کانالی مستقل تأیید شود.

برای Android، Livara مجموع‌های مقابله‌ای SHA-256 هر APK را منتشر می‌کند و کاربر می‌تواند آن‌ها را محلی و آفلاین در Proof Lab بررسی کند. این مقایسه فقط نشان می‌دهد فایل با نسخه‌ای که Livara منتشر کرده منطبق است؛ ثابت نمی‌کند دستگاه عاری از بدافزار است یا کد نقص ندارد. Proof Lab برای بررسی APK مرز این ادعا را توضیح می‌دهد.

پرسش‌های متداول

آیا هک سرور یعنی مهاجم همه پیام‌ها را می‌خواند؟

نه. اگر پیام‌های خصوصی درست رمزگذاری سرتاسری شده باشند و کلیدها فقط روی دستگاه‌ها بمانند، نسخه پایگاه داده سرور باید متن رمز را در اختیار مهاجم بگذارد، نه متن پیام را. بااین‌حال، فراداده، کانال‌های سرورخوان، دستگاه آلوده و نسخه پشتیبان ضعیف ممکن است اطلاعات مهمی افشا کنند.

آیا هش‌شدن گذرواژه در نشت پایگاه داده کافی است؟

خیر. هش مناسب بهتر از ذخیره گذرواژه آشکار است، اما مهاجم می‌تواند حدس‌های آفلاین را علیه داده سرقت‌شده آزمایش کند، به‌ویژه وقتی گذرواژه ضعیف یا تکراری باشد. SRP گذرواژه را مستقیماً برای سرور نمی‌فرستد، ولی همچنان به گذرواژه قوی و دستگاه امن نیاز دارد.

مهاجم از فراداده پیام‌رسان چه می‌فهمد؟

فراداده ممکن است نشان دهد کدام حساب با چه مقصدی ارتباط داشته و تحویل چه زمانی رخ داده است. این داده متن پیام نیست، اما می‌تواند الگوی ارتباط را آشکار کند. Livara برای همگام‌سازی بلادرنگ، فرستنده، مقصد و زمان تحویل را ذخیره می‌کند.

آیا گروه‌های خصوصی Livara هم رمزگذاری سرتاسری دارند؟

طبق مشخصات Livara، بله. LGS1 متن، ویرایش، عکس، ویدئو، فایل، زیرنویس و پیام صوتی گروه خصوصی را رمزگذاری سرتاسری می‌کند و کلید هر فرستنده در پاکت‌های جفت‌به‌جفت LVR1 منتقل می‌شود. این حکم درباره کانال‌ها صدق نمی‌کند؛ کانال‌ها برای سرور خواندنی‌اند و امکان بررسی محتوای گزارش‌شده را می‌دهند.

بازیابی رمزگذاری‌شده v7 در برابر چه چیزی محافظت می‌کند؟

طبق طراحی Livara، v7 هویت رمزنگاری کاربر را با کلید بازیابی ۲۵۶‌بیتی مشتق‌شده از عبارت بازیابی مهروموم می‌کند؛ بنابراین تصاحب پایگاه داده به‌تنهایی نباید برای بازکردن آن کافی باشد. این حفاظت جای نگهداری امن عبارت بازیابی را نمی‌گیرد: دسترسی به آن عبارت یا دستگاه بازشده می‌تواند این مرز را دور بزند.

مقایسه امنیت Livara
پایان / اگر سرور پیام‌رسان هک شود، چه اطلاعاتی لو می‌رود؟ مقایسه ۵ معماری امنیتیساختهٔ لیوار ↗