آزمون آفلاین باید یک نتیجهٔ مشخص داشته باشد؛ هش یا نمایش رمزنگاری، ممیزی کامل محصول نیست.
بررسی آفلاین میتواند نشان دهد یک محاسبهٔ مشخص بدون پاسخ زندهٔ سرور انجام میشود. این ارزشمند است، اما به معنی اثبات امنیت تمام پیامرسان نیست. برای نتیجهٔ قابلاستفاده باید دقیق بنویسید چه فایل، نسخه، ورودی و خروجیای را آزمودهاید.
هش فایل، امضای انتشار، تستوکتور، ساخت بازتولیدپذیر و ممیزی امنیتی به سؤالهای متفاوت پاسخ میدهند. ترکیب شواهد از تبدیل یکی از آنها به «مهر امنیت کامل» مفیدتر است.
هر مدرک چه چیزی را نشان میدهد؟
| مدرک | نتیجهٔ محدود و درست | چیزی که خودبهخود ثابت نمیشود |
|---|---|---|
| SHA-256 فایل | فایل با digest مرجع تطابق دارد | منبع مرجع صادق است یا کد بینقص است |
| امضای APK | امضا برای بسته معتبر است و به کلید امضاکننده مرتبط است | آن کلید متعلق به ناشر موردنظر شماست، مگر جدا بررسی شود |
| تستوکتور | موارد پوششدادهشده خروجی موردانتظار میدهند | تمام حالتها و خطاهای محصول پوشش داده شدهاند |
| ساخت بازتولیدپذیر | منبع و محیط مشخص خروجی یکسان میسازند | کد منبع فاقد آسیبپذیری است |
| ممیزی | دامنه و نسخهٔ معین بررسی شدهاند | تغییرات بعدی و اجزای خارج از دامنه هم تأیید شدهاند |
تعریف ساخت بازتولیدپذیر بر ورودی و محیط مشخص تکیه دارد. ابزار رسمی apksigner اندروید نیز برای بررسی امضای APK است؛ این کار با محاسبهٔ هش یکی نیست.
Proof Lab لیوارا اکنون چه محدودهای دارد؟
صفحهٔ Proof Lab ابزار محلی هش APK و نمایش عملیات P-256، HKDF و AES-GCM را معرفی میکند؛ از جمله دستکاری یک بیت برای مشاهدهٔ شکست بررسی اصالت. خود صفحه صریحاً میگوید ترکیب کامل LVR1/LGS1 خارج از این میز آزمایش است.
بنابراین نتیجهٔ صحیح را اینگونه بنویسید: «این فایل با digest مرجع تطابق داشت» یا «این نمایش رمزنگاری، دستکاریِ مورد آزمون را رد کرد». نگویید «تمام پروتکل هیبریدی و تمام نسخهٔ نصبشده مستقلاً ممیزی شد». این مقاله آزمون اجرایی تازهای از آن ابزار گزارش نمیکند.
یک آزمون آفلاینِ قابلتکرار چگونه آماده میشود؟
- هدف را مشخص کنید. میخواهید هویت فایل را بررسی کنید یا رفتار یک عملیات رمزنگاری را؟
- نسخه و منبع را ثبت کنید. نام APK، شمارهٔ نسخه، نشانی دریافت و digest همان انتشار باید با هم مرتبط باشند.
- ابزار و ورودی را از منبع مورداعتماد آماده کنید. آفلاینشدن، کدی را که از ابتدا مخرب بوده معتبر نمیکند.
- از دادهٔ آزمایشی غیرحساس استفاده کنید. برای نمایش رمزنگاری به پیام خصوصی یا راز واقعی نیاز نیست.
- ارتباط را قطع و آزمون را تکرار کنید. این مرحله وابستگی به پاسخ زنده را میسنجد، نه اعتماد به کدی که قبلاً دریافت شده است.
- نتیجه و خطا را ثبت کنید. تفاوت نسخه، شکست بارگیری و خروجی نامنطبق را با «قبول» جایگزین نکنید.
اگر هش متفاوت شد، نصب را متوقف و ابتدا نسخه، فایل و منبع مرجع را بررسی کنید. اختلاف ممکن است ناشی از انتخاب انتشار متفاوت باشد؛ بدون بررسی آن را قطعی بدافزار یا قطعی بیاهمیت ندانید.
تستوکتور با گواهی رسمی چه تفاوتی دارد؟
تستوکتور ورودی و خروجی موردانتظار یک رفتار را مشخص میکند. مجموعههایی مانند Wycheproof برای آزمون کتابخانهها در برابر موارد مرتبط با حملات شناختهشده مفیدند. عبور از آنها پوشش موارد ناشناخته را ثابت نمیکند.
NIST CAVP فرایند اعتبارسنجی الگوریتم دارد. اجرای چند بردار عمومی در مرورگر، همان دریافت گواهی اعتبارسنجی نیست؛ استفاده از الگوریتم استاندارد نیز محصول را خودکار تأییدشده نمیکند.
برای مقایسهٔ پیامرسانها چه چیزی بخواهیم؟
برای Livara، Signal، WhatsApp، Session یا Element، سؤال ثابت بپرسید: نسخهٔ دقیق چیست؟ فایل رسمی کدام است؟ کلید امضاکننده یا digest مرجع چگونه تأیید میشود؟ چه آزمونهایی قابلاجراست؟ کدام کد و اجزا در گزارش ممیزی بودهاند؟
این مقاله رتبهبندی آزمایششدهٔ این محصولات نیست. نبودن یک ابزار تکصفحهای، اثبات نبودن شواهد امنیتی نیست؛ وجود آن هم برتری کل محصول را ثابت نمیکند. اسناد رسمی همان نسخه و گزارش قابلتکرار را مقایسه کنید.
یک برگهٔ نتیجهٔ مفید
در گزارش کوتاه خود این موارد را بنویسید: هدف، نسخه، منبع فایل، hash، ابزار و نسخهٔ آن، وضعیت شبکه، ورودی غیرحساس، خروجی موردانتظار، خروجی مشاهدهشده و محدودیت. اگر آزمایش دیگری انجام نشده، آن را «آزمودهنشده» ثبت کنید.
تأیید کلید مخاطب نیز بررسی جداگانهای است. ابزار محلی میتواند یک عملیات را نشان دهد، اما بهجای شما هویت طرف گفتگو یا سلامت گوشی او را تأیید نمیکند. مرزهای امنیتی لیوارا را کنار نتایج بخوانید، نه آنکه یک امتیازِ کامل در ابزار را ضمانت همهٔ مرزها بدانید.



