نتیجهٔ فورنزیک به وضعیت واقعی دستگاه و کلیدها وابسته است، نه صرفاً نام دیتابیس یا الگوریتم.
رمزنگاری سرتاسری و حفاظت از دادهٔ محلی دو مسئلهٔ مرتبط اما متفاوتاند. پیامی که در مسیر شبکه محافظت شده، برای نمایش روی دستگاه باید قابلخواندن شود. نتیجهٔ بررسی فورنزیک به وضعیت دستگاه، نوع دسترسی، نسخهٔ سیستم و برنامه و محل کلیدها بستگی دارد؛ هیچ نام الگوریتمی بهتنهایی نتیجه را تعیین نمیکند.
بنابراین هم ادعای «با دسترسی فیزیکی همهچیز فوراً خوانده میشود» و هم وعدهٔ «استخراج هرگز ممکن نیست» نیازمند احتیاطاند.
چهار لایهٔ حفاظت را جدا بررسی کنید
| لایه | کار اصلی | محدودیت مهم |
|---|---|---|
| E2EE پیام | حفاظت محتوا میان دستگاههای شرکتکنندگان | سلامت دستگاه و نسخههای محلی را تضمین نمیکند |
| جداسازی برنامهها | محدودکردن دسترسی برنامههای معمول به دادهٔ یکدیگر | دسترسی سطح بالا یا آسیبپذیری میتواند مدل را تغییر دهد |
| رمزنگاری فایل یا دیسک | حفاظت از دادهٔ ذخیرهشده تحت شرایط مشخص | وضعیت قفل و دسترسپذیری کلید مهم است |
| رمزنگاری دیتابیس در برنامه | یک مرز اضافی برای فایل پایگاه داده | شیوهٔ نگهداری و استفاده از کلید تعیینکننده است |
مستندات FBE اندروید فضای وابسته به اعتبار کاربر و فضای در دسترس در Direct Boot را جدا میکند. از عبارت «گوشی قفل است» بهتنهایی نمیتوان تمام وضعیت کلیدها را فهمید؛ پیش یا پس از اولین بازکردن قفل بعد از راهاندازی نیز ممکن است مهم باشد.
فایل SQLite چه چیزی را ثابت میکند؟
SQLite قالب و موتور ذخیرهسازی است، نه برچسبی که بهتنهایی وجود یا نبودِ همهٔ حفاظتها را نشان دهد. فایل میتواند داخل فضای رمزنگاریشدهٔ سیستمعامل باشد یا با راهکار جداگانهای محافظت شود.
همچنین حذف یک ردیف، لزوماً تمام آثار آن را در همهٔ فایلها از بین نمیبرد. مستندات SQLite دربارهٔ تنظیمات حذف امن و محدودیتهای جدولهای مجازی توضیح میدهد. فایلهای جانبی و نسخههای پشتیبان نیز باید در بررسی چرخهٔ داده لحاظ شوند. این به معنی تضمین بازیابی هر پیام حذفشده در هر گوشی نیست.
دستورات نگهداری دیتابیس را بدون شناخت برنامه روی دادهٔ واقعی اجرا نکنید؛ تغییر مستقیم فایلهای برنامه میتواند داده را خراب کند یا شواهد را تغییر دهد.
SQLCipher و Keystore راهکارند، نه گواهی مصونیت
SQLCipher برای رمزنگاری شفاف پایگاه داده طراحی شده است، ولی مشخصات را باید با نسخه خواند. صفحهٔ طراحی SQLCipher ساختار AES-CBC همراه با احراز اصالت را شرح میدهد؛ معرفی نسخهٔ ۵ بتا در سپتامبر ۲۰۲۶ تغییر به AES-GCM را بیان میکند. بنابراین نسبتدادن یک حالت رمز به تمام نسخهها دقیق نیست.
Android Keystore هم میتواند حفاظت و کنترل استفاده از کلید را فراهم کند، اما لازم است مشخص شود برنامه واقعاً از چه قابلیت و چه سطح سختافزاری استفاده کرده است. نام StrongBox در یک مقاله، مدرک استفادهٔ محصول از آن نیست. راهنمای Keystore.
کلیدِ غیرقابلاستخراج نیز ممکن است در شرایطی از طریق عملیات مجاز قابلاستفاده باشد. «نمیتوان کلید را کپی کرد» با «مهاجم نمیتواند هیچ دادهای را باز کند» یک ادعا نیست.
RAM و رتچت چه نقشی دارند؟
محدودکردن عمر کلید و متنِ حساس، تعداد فرصتهای افشا را کاهش میدهد. اما پاکسازی یک بافر اثبات نمیکند هیچ کپی دیگری در کتابخانه، پیشنمایش یا فرایند نمایش باقی نمانده است.
رتچت هم بسته به نوع کلید افشاشده و ادامهداشتن دسترسی مهاجم، دامنهٔ متفاوتی دارد. نمیتوان از «کلید مجزا برای هر پیام» نتیجه گرفت که یک برداشت حافظه حداکثر یک پیام را افشا میکند. ذخیرهٔ تاریخچهٔ خواندنی روی دستگاه مسئلهای جدا از کلیدهای انتقال است.
دربارهٔ لیوارا چه چیزی تأیید نشده است؟
مدل تهدید لیوارا حفاظت از دستگاه آلوده یا باز را تضمین نمیکند. این مقاله استفادهٔ نسخهٔ مشخص لیوارا از SQLCipher، StrongBox، پاکسازی کامل RAM یا نبودِ دادهٔ محلی تماس را مستقلاً تأیید نمیکند. این موارد بدون گزارش آزمون و شواهد پیادهسازی نباید به محصول نسبت داده شوند.
همچنین بستهٔ بازیابی هویت در مستندات امنیت با بکاپ تاریخچه یکی نیست. بررسی هش APK در Proof Lab میتواند تطابق فایل و هشِ مورداعتماد را نشان دهد؛ نتیجهٔ آن، ممیزی ذخیرهسازی یا آزمون ضدفورنزیک نیست.
یک ادعای فورنزیک معتبر چه اطلاعاتی باید داشته باشد؟
مدل دستگاه، نسخهٔ سیستم و برنامه، وضعیت قفل، روش و سطح دسترسی، نوع دادهٔ بهدستآمده و محدودیت آزمون را بخواهید. شکست یک ابزار در یک آزمایش، اثبات ناممکنبودن همهٔ روشها نیست؛ موفقیت محدود هم مجوز تعمیم به تمام کاربران نیست.
برای کاربر معمولی، بهروزرسانی، قفل قوی، کاهش نسخههای اضافی رسانه و مراقبت از راههای بازیابی اولویت دارند. در حادثهٔ جدی، پیش از اقداماتی که داده یا شواهد را تغییر میدهند از متخصص مجاز کمک بگیرید.



