نام یک الگوریتم، جای شواهد مربوط به محل ذخیره داده و حفاظت از کلید را نمیگیرد.
رمزنگاری در حالت سکون یا Data-at-Rest از دادههای ذخیرهشده محافظت میکند؛ رمزنگاری سرتاسری از محتوای پیام میان دستگاههای مجاز. برای ارزیابی امنیت یک پیامرسان باید هر دو را بررسی کرد. نام یک الگوریتم یا عبارت «پساکوانتومی» بهتنهایی نشان نمیدهد که دیتابیس، کش رسانه و فایلهای خروجی روی گوشی چگونه محافظت شدهاند.
در فورنزیک موبایل نیز «بهدستآوردن فایل» با «خواندن محتوای رمزشده آن» یکسان نیست. نتیجه به مدل دستگاه، نسخه سیستمعامل، وضعیت قفل، نوع داده، کلیدهای قابل استفاده و روش بررسی بستگی دارد. نمیتوان فقط با نام یک ابزار، موفقیت یا شکست استخراج را برای همه گوشیها پیشبینی کرد.
سه لایهای که نباید با هم اشتباه گرفت
| لایه | از چه چیزی محافظت میکند؟ | پرسش مهم |
|---|---|---|
| رمزنگاری سرتاسری پیام | محتوای مبادلهشده میان دستگاههای مجاز | کلیدها دست چه کسی است و مخاطب چگونه تأیید میشود؟ |
| رمزنگاری ذخیرهسازی دستگاه | فایلهای نگهداریشده روی حافظه | چه زمانی و با چه مجوزی کلیدهای مربوط قابل استفادهاند؟ |
| حفاظت داخل برنامه و بکاپ | دیتابیس، خروجیها یا نسخههای جداگانه | کدام دادهها پوشش داده شدهاند و کلید هر نسخه کجاست؟ |
برای مثال، تصویری که از چت در گالری ذخیره شده دیگر فقط تابع سیاست نگهداری همان پیامرسان نیست. بکاپ ابری یا خروجی دستی هم باید جدا بررسی شود. راهنمای امنیت بکاپ چت این تفاوت را توضیح میدهد.
BFU و AFU چه معنایی دارند؟
این اصطلاحات معمولاً وضعیت دستگاه نسبت به اولین بازشدن قفل پس از راهاندازی را توصیف میکنند:
- BFU یا Before First Unlock: از زمان روشنشدن یا راهاندازی مجدد، کاربر هنوز اولین بازکردن قفل را انجام نداده است.
- AFU یا After First Unlock: اولین بازکردن قفل انجام شده است؛ دستگاه ممکن است اکنون دوباره صفحه قفل را نشان دهد.
این دو برچسب، امتیاز امنیت یا نتیجه قطعی یک بررسی فورنزیک نیستند. AFU به معنی «همه کلیدها قابل استخراجاند» نیست؛ BFU هم به معنی «هیچ دادهای در دسترس نیست» نیست.
در رمزنگاری مبتنی بر فایل اندروید، فضای Credential Encrypted یا CE پس از بازشدن قفل کاربر در دسترس قرار میگیرد. فضای Device Encrypted یا DE برای عملکردهای لازم در Direct Boot نیز قابل استفاده است. محل نگهداری هر داده و سیاست کلید اهمیت دارد؛ همه فایلها یک وضعیت دسترسی مشترک ندارند.
چرا مدیریت کلید مهمتر از ذکر نام AES است؟
رمزنگاری دیتابیس زمانی مفید است که کلید آن نیز بهدرستی محافظت شود. نگهداری فایل رمزشده کنار یک کلید بدون حفاظت، همان مرزی را ایجاد نمیکند که کلید وابسته به احراز هویت و سختافزار امن ایجاد میکند. همچنین باید مشخص باشد فایلهای موقت، پیوستها و گزارشهای برنامه چه وضعیتی دارند.
Android Keystore امکان استفاده از کلیدهای غیرقابلخروج را فراهم میکند و برخی کلیدها میتوانند به سختافزار امن متکی باشند. اما غیرقابلخروجبودن کلید با غیرقابلاستفادهبودن آن توسط مهاجم یکی نیست: طبق مستندات اندروید، مهاجمی که فرایند برنامه را تصرف کرده ممکن است بتواند از کلید استفاده کند، حتی اگر نتواند خود کلید را استخراج کند.
قفل ظاهری برنامه نیز لزوماً ثابت نمیکند که دیتابیس با کلیدی مستقل رمز شده است. برای چنین ادعایی باید طراحی ذخیرهسازی، شرایط احراز هویت و اجرای همان نسخه بررسی شود.
درباره لیوارا چه چیزی را میتوان نتیجه گرفت؟
مستندات امنیت لیوارا و مدل تهدید توضیح ارائهدهنده درباره طراحی و مرزهای محصول هستند؛ جای آزمون مستقل فورنزیک را نمیگیرند.
بهویژه، بازیابی هویت با فرمت v7 را نباید بکاپ تاریخچه چت یا مدرک رمزنگاری دیتابیس محلی دانست. توضیح یک پروتکل پیام مانند LVR1 نیز بهتنهایی مشخص نمیکند که هر فایل روی گوشی با چه کلیدی و در چه وضعیتهایی محافظت میشود.
در این مقاله آزمونی روی ابزارهای تجاری فورنزیک یا دیتابیس یک نسخه مشخص لیوارا انجام نشده است. بنابراین ادعاهایی مانند «هیچ ابزار فورنزیکی نمیتواند لیوارا را بخواند» یا «ML-KEM همه فایلهای حافظه را رمز میکند» نتیجه قابل دفاعی نیستند.
برای ارزیابی یک پیامرسان چه مدرکی بخواهیم؟
بهجای جدول رتبهبندی بدون آزمون، این پرسشهای مشخص را دنبال کنید:
- کدام نسخه برنامه و کدام مدل و نسخه سیستمعامل بررسی شده است؟
- متن پیام، فایلها، تصویر بندانگشتی، کش و خروجی دستی هرکدام کجا ذخیره میشوند؟
- کلید دیتابیس چگونه ایجاد و نگهداری میشود؟ آیا استفاده از آن به احراز هویت وابسته است؟
- در حالت قفل، پس از بازکردن قفل و هنگام اجرای برنامه چه تفاوتی وجود دارد؟
- بکاپ دقیقاً چه چیزهایی را شامل میشود و رمز یا کلید بازیابی آن در اختیار چه کسی است؟
- آیا گزارش مستقل، روش آزمایش، محدودیتها و تاریخ بررسی منتشر شده است؟
عبارت «رمزنگاریشده» بدون پاسخ این پرسشها برای مقایسه محصولات کافی نیست. انتشار مستندات فنی ارزشمند است، اما نباید آن را معادل تأیید مستقل همه ادعاها معرفی کرد.
اقدامهای عملی برای حفاظت روزمره
از قفل دستگاه با رمز مناسب استفاده کنید، بهروزرسانیهای سیستمعامل و برنامه را نصب کنید و نمایش متن حساس روی صفحه قفل را محدود کنید. نسخههای اضافی در گالری، پوشه دانلود و بکاپ را آگاهانه مدیریت کنید؛ یک کپی خارج از پیامرسان ممکن است سیاست حفاظتی دیگری داشته باشد.
برای مکالمه حساس، سلامت دستگاه مخاطب هم اهمیت دارد. اگر بدافزار بتواند متن را پس از بازشدن برنامه بخواند، بحث فقط استخراج یک فایل رمزشده نیست. راهنمای امنیت نشست در اندروید این مرز را باز میکند.
پرسشهای رایج
آیا خاموشبودن گوشی یعنی استخراج اطلاعات غیرممکن است؟
خیر. وضعیت دستگاه یکی از عوامل است، نه تضمین نتیجه. جزئیات سختافزار، نرمافزار، داده و روش بررسی باید مشخص باشد.
آیا رمزنگاری پساکوانتومی پیام، امنیت حافظه را تضمین میکند؟
خیر. حفاظت از تبادل کلید و پیام، جای طراحی و بررسی ذخیرهسازی محلی را نمیگیرد.
آیا بازیابی حساب یعنی همه پیامها برمیگردند؟
لزومی ندارد. بازیابی هویت، اتصال دوباره به حساب و بازگرداندن تاریخچه سه قابلیت متفاوتاند. قبل از تعویض گوشی، دامنه بکاپ همان محصول و نسخه را بررسی کنید.



