دامنهٔ افشا به نوع کلید و مدت دسترسی مهاجم بستگی دارد؛ رتچت تضمین نمی‌کند فقط یک پیام در خطر باشد.
رمزنگاری قوی به اجرای درست روی دستگاه هم نیاز دارد. یک آسیب‌پذیری سیستم‌عامل، پیاده‌سازی رمزنگاری یا سخت‌افزار ممکن است به دادهٔ حساس راه باز کند؛ اما از وجود پژوهش دربارهٔ حملات پردازنده نمی‌توان نتیجه گرفت که هر گوشی یا پیام‌رسانی به همان روش قابل‌نفوذ است.
پرسش مفید این است: مهاجم چه دسترسی‌ای دارد، کدام کلید یا متن را می‌تواند ببیند، و آیا دسترسی او موقتی است یا ادامه دارد؟ پاسخ این سؤال‌ها از نام الگوریتم مهم‌تر است.
کانال جانبی با برداشت حافظه چه فرقی دارد؟
در برداشت مستقیم حافظه، مهاجم ممکن است بتواند بخش‌هایی از فضای حافظهٔ فرایند یا دستگاه را بخواند. در حملهٔ کانال جانبی، از نشانه‌هایی مانند زمان اجرای عملیات یا رفتار کش برای استنباط اطلاعات استفاده می‌شود. این دو الزاماً پیش‌نیاز یا نتیجهٔ یکسان ندارند.
پژوهش اصلی FLUSH+RELOAD رفتار کش و صفحات حافظهٔ مشترک را در محیط آزمایش مشخص بررسی کرد و استخراج کلید از نسخه‌ای از GnuPG را نشان داد. این نتیجه، آزمون امنیت لیوارا یا مدرک آسیب‌پذیری همهٔ پردازنده‌های گوشی نیست.
| نوع دسترسی | پرسش لازم برای ارزیابی |
|---|---|
| اجرای برنامهٔ عادی روی همان دستگاه | آیا جداسازی فرایند و پیش‌نیازهای حمله اجازهٔ مشاهده می‌دهد؟ |
| دسترسی سطح بالای سیستم‌عامل | کدام داده یا عملیات کلیدی در اختیار مهاجم قرار می‌گیرد؟ |
| دسترسی فیزیکی یا آزمایشگاهی | وضعیت قفل، مدل سخت‌افزار و حفاظت کلید چیست؟ |
| دسترسی ادامه‌دار به برنامه | آیا مهاجم می‌تواند متن یا کلیدهای تازه را دوباره جمع کند؟ |
عبارت کلی «هک RAM» بدون این جزئیات، توضیح فنی کافی نیست.
Keystore و سخت‌افزار امن چه کمکی می‌کنند؟
Android Keystore می‌تواند استفاده از کلید را محدود کند و در دستگاه‌های مناسب، عملیات را با پشتیبانی سخت‌افزاری انجام دهد. در این طراحی، غیرقابل‌استخراج‌بودن کلید با غیرقابل‌استفاده‌بودن آن توسط مهاجم یکی نیست: برنامهٔ آلوده ممکن است در برخی شرایط بتواند از عملیات مجاز کلید سوءاستفاده کند، حتی اگر بایت‌های کلید را بیرون نیاورد. راهنمای Android Keystore.
همهٔ کلیدها و همهٔ الگوریتم‌ها نیز خودکار در سخت‌افزار امن قرار نمی‌گیرند. نوع کلید، پشتیبانی دستگاه و نحوهٔ استفادهٔ برنامه باید مشخص باشد. گفتن «کلید روی دستگاه است» به‌تنهایی محل یا سطح حفاظت آن را اثبات نمی‌کند.
آیا یک کلید افشاشده فقط یک پیام را لو می‌دهد؟
گاهی افشای یک کلید پیامِ مستقل دامنه‌ای محدود دارد. اما اگر مهاجم کلید زنجیره، وضعیت نشست، کلید هویت، تاریخچهٔ قابل‌خواندن یا چندین بافر را به‌دست آورد، نتیجه متفاوت است. بنابراین نمی‌توان بدون تعیین دادهٔ افشاشده گفت «حداکثر یک پیام» در خطر است.
همچنین تغییر کلید برای هر پیام لزوماً دسترسی مهاجم را قطع نمی‌کند. اگر کلیدهای بعدی از وضعیتی مشتق شوند که مهاجم دارد، یا او همچنان روی دستگاه حضور داشته باشد، ممکن است به پیام‌های بعدی هم برسد. حفاظت از گذشته و بازیابی امنیت آینده دو ویژگی جدا با فرض‌های مشخص‌اند.
رتچت و پاکسازی حافظه چه محدودیتی دارند؟
رتچت می‌تواند کلیدها را در طول گفتگو تحول دهد. بازیابی پس از افشا به ورود اطلاعات تازه‌ای نیاز دارد که مهاجم به آن دسترسی ندارد؛ صرف ارسال یک پیام این شرط را ثابت نمی‌کند. مشخصات Double Ratchet علاوه بر بازیابی، خطرِ دسترسی ماندگار و بازیابی دادهٔ حذف‌شده را توضیح می‌دهد.
کوتاه‌کردن عمر دادهٔ حساس و پاکسازی بافرها مفید است، اما هیچ ادعای کلی دربارهٔ پاک‌شدن تمام کپی‌ها در RAM از آن نتیجه نمی‌شود. کتابخانه‌ها، زبان برنامه‌نویسی و مسیرهای نمایش باید بررسی شوند.
دربارهٔ لیوارا چه می‌توان گفت؟
صفحهٔ امنیت لیوارا از ساختار هیبریدی و تحول کلید در LVR1 صحبت می‌کند. این مقاله آزمایش کانال جانبی، ممیزی حافظه یا تأیید استفادهٔ تمام کلیدها از Keystore نیست. به‌ویژه، مستندات عمومی مدل تهدید حفاظت از دستگاه آلوده را تضمین نمی‌کند.
بنابراین وعدهٔ «خنثی‌شدن نفوذ سخت‌افزاری با پیام بعدی» یا «افشای حداکثر یک پیام» را نباید به محصول نسبت داد مگر شواهد مشخص برای همان نسخه و سناریو وجود داشته باشد.
تصمیم عملی برای کاربر
سیستم‌عامل و برنامه را به‌روز نگه دارید، دستگاهی با پشتیبانی امنیتی فعال انتخاب کنید، از نصب نامطمئن و دسترسی‌های اضافی پرهیز کنید و قفل مناسب داشته باشید. اگر احتمال نفوذ جدی مطرح است، تغییر پیام‌رسان یا ارسال پیام تازه جای بررسی و پاکسازی دستگاه را نمی‌گیرد.
برای خواندن یک ادعای امنیتی، چهار چیز بخواهید: نسخهٔ آزمایش‌شده، دسترسی مهاجم، دادهٔ افشاشده و محدودیت نتیجه. نام یک پردازنده یا استاندارد رمزنگاری به‌تنهایی پاسخ این چهار سؤال نیست.
