تمامیت رمزنگاری ثابت میکند بسته در مسیر دستکاری نشده است؛ نه اینکه تاریخچه گفتگو تغییرناپذیر یا اسکرینشات، مدرکی قطعی است.
بله، یک پیامرسان میتواند قابلیت ویرایش یا حذف داشته باشد؛ اما در سامانهای با رمزگذاری اصالتسنجیشده، سرور نباید بتواند متن رمزشده را بیصدا عوض کند و همچنان پیام معتبری تحویل دهد. تمامیت پیام در پیامرسان یعنی گیرنده بتواند تشخیص دهد داده پس از رمزگذاری تغییر کرده است؛ این ویژگی با حفظ تاریخچه کامل یا اثبات حقوقی گفتگو یکسان نیست.
نکات کلیدی
- رمزگذاری اصالتسنجیشده دستکاری متن رمزشده را آشکار میکند، اما لزوماً تاریخچه ویرایشها و حذفها را نگه نمیدارد.
- طبق اسناد فنی Livara، AES-256-GCM پیامهای خصوصی را همراه با برچسب اصالت محافظت میکند؛ بسته دستکاریشده نباید معتبر رمزگشایی شود.
- ویرایش مجاز باید رویدادی تازه و سرتاسری رمزشده باشد، نه بازنویسی مخفیانه بسته قبلی به دست سرور.
- شمارههای ایمنی به بررسی کلید طرف مقابل کمک میکنند، نه سنجش صداقت او یا اعتبار حقوقی اسکرینشات.
- برای اختلافهای حساس، فایل اصلی، زمانها، وضعیت ویرایش و مدارک مستقل را خارج از رشته گفتگو نیز نگه دارید.
تمامیت پیام در پیامرسان دقیقاً چیست؟
تمامیت پیام یعنی گیرنده بتواند تغییر غیرمجاز در داده رمزشده را تشخیص دهد. محرمانگی میپرسد «چه کسی میتواند متن را بخواند؟»؛ تمامیت میپرسد «آیا همان دادهای رسیده که فرستنده رمز کرده بود؟». توضیح رمزگذاری سرتاسری و مرزهای آن این تفاوت را بیشتر شرح میدهد.
طبق اسناد فنی Livara، پیامهای مستقیم با LVR1 و گروههای خصوصی با LGS1 سرتاسری رمز میشوند. این اسناد میگویند LVR1 برای مشتقسازی کلید پیام از ECDH P-256 و ML-KEM-768 استفاده میکند. مؤسسه ملی استاندارد و فناوری امریکا، NIST، الگوریتم ML-KEM را در FIPS 203 استاندارد کرده است. Livara سپس برای حفاظت از محتوا از AES-256-GCM استفاده میکند.
این حفاظت، بنا بر مستندات محصول، متن، ویرایشها و پیوستهای گفتگوهای خصوصی را در بر میگیرد. اما کانالهای Livara سرتاسری رمز نشدهاند: سرور عمداً میتواند محتوای آنها را بخواند تا از جمله محتوای سوءاستفاده را حذف کند. عضویت گروهها نیز زیر کنترل سرور است. رسانه تماسها هم پساکوانتومی نیست.
تشخیص دستکاری پیام رمزگذاریشده و رمزگذاری AES-256-GCM پیامرسان
AES-GCM علاوه بر رمزکردن محتوا، برچسب اصالت میسازد. اگر متن رمزشده یا داده اصالتسنجیشده تغییر کند، بررسی برچسب باید شکست بخورد. NIST SP 800-38D حالت GCM را تعریف میکند و هشدار میدهد که تکرار nonce با یک کلید میتواند امنیت را بهشدت تضعیف کند.
طبق مشخصات فنی Livara، پیامهای خصوصی از AES-256-GCM استفاده میکنند. اگر سرور بخشی از بسته محافظتشده را تغییر دهد، بدون کلید پیام نمیتواند برچسب اصالت تازهای بسازد؛ بنابراین گیرنده نباید بسته را سالم بپذیرد. پاسخ کوتاه به پرسش «آیا سرور میتواند پیام را تغییر دهد؟» این است: سرور میتواند داده را حذف، نگه دارد، مسدود کند یا دیر برساند، اما نباید بتواند محتوای دستکاریشده را معتبر جلوه دهد.
این تضمین نامحدود نیست. رمزنگاری نمیتواند بدافزار روی دستگاه، دسترسی مهاجم به صفحه باز یا ویرایش مجاز کاربر را خنثی کند. تمامیت محتوا نیز لزوماً متادیتا را پنهان نمیکند. راهنمای متادیتای پیامرسان و آنچه فاش میکند این مرز را توضیح میدهد.
آیا سرور میتواند پیام را تغییر دهد یا ویرایش چیز دیگری است؟
سرور نباید بتواند بسته رمزشده قبلی را پنهانی بازنویسی کند، اما میتواند رویداد ویرایشی را که فرستنده ساخته است تحویل دهد. امنیت ویرایش پیام به این بستگی دارد که ویرایش نیز مانند پیام اصلی احراز اصالت و سرتاسری رمز شود، نه آنکه سرور متن ذخیرهشده را مستقیم عوض کند.
طبق مستندات Livara، ویرایش در چت مستقیم زیر LVR1 و در گروه خصوصی زیر LGS1 محافظت میشود. برنامه باید وضعیت «ویرایششده» را نشان دهد؛ بااینحال، رمزنگاری بهتنهایی نسخه قبلی را برای همیشه روی همه دستگاهها نگه نمیدارد.
«حذف برای همه» نیز درخواست کنارگذاشتن محتواست، نه اثبات نابودی همه نسخهها. گیرنده ممکن است پیام را دیده، اعلان را خوانده، فایل را ذخیره کرده یا از صفحه عکس گرفته باشد. پیام ناپدیدشونده ماندگاری را کاهش میدهد، اما پاکشدن همه نسخهها را تضمین نمیکند.
احراز اصالت پیام چت چه چیزی را ثابت میکند؟
احراز اصالت پیام چت نشان میدهد پیام با کلیدهای نشست ساخته شده و در مسیر دستکاری نشده است. این ویژگی ثابت نمیکند صاحب حساب شخصاً دستگاه را در دست داشته، متن حقیقت دارد یا گیرنده بعداً میتواند آن را برای شخص ثالث بهطور قطعی اثبات کند.
Livara در اسناد فنی خود شمارههای ایمنی را راهی برای تشخیص تغییر کلید معرفی میکند. دو نفر میتوانند اثرانگشت کلیدها را از مسیری مستقل مقایسه کنند؛ راهنمای بررسی چت با شمارههای ایمنی مراحل عملی را شرح میدهد. این بررسی خطر جایگزینی کلید مخاطب با کلید مهاجم را کاهش میدهد، اما دستگاه آلوده را ایمن نمیکند.
احراز هویت حساب نیز مسئلهای جداست. هر سازوکار ورود، هرقدر قوی، جای تمامیت پیام، بررسی کلید مخاطب یا امنیت دستگاه را نمیگیرد.
برای اختلاف حساس چه مدرکی باید نگه دارید؟
تنها به حباب فعلی چت یا یک اسکرینشات تکی تکیه نکنید. فایل اصلی، زمان دریافت، نشانه ویرایش یا حذف، هویت حساب و هر تأیید مستقل را نگه دارید؛ رابط برنامه ممکن است تغییر کند و اسکرینشات نیز قابل برش یا ساخت است.
یک بسته مدرک عملی بسازید
- از کل رشته مرتبط، شامل نام مخاطب، تاریخها و برچسب «ویرایششده»، ثبت تصویری پیوسته تهیه کنید.
- فایل دریافتی را در قالب اصلی نگه دارید و نسخه کاری جداگانه بسازید.
- برای موضوع مهم، خلاصه توافق را در سند، ایمیل سازمانی یا مسیری مستقل تأیید کنید.
- زمان و شیوه مقایسه شمارههای ایمنی را یادداشت کنید، اما آن را اثبات حقیقت محتوا ندانید.
- اگر احتمال دعوای رسمی وجود دارد، پیش از حذف، انتقال یا دستکاری دستگاه از متخصص ادله دیجیتال یا مشاور حقوقی صلاحیتدار کمک بگیرید.
بازیابی رمزشده نیز آرشیو تغییرناپذیر نیست. قابلیت بازیابی برای بازگرداندن حساب یا هویت رمزنگاری است، نه صدور رسید مستقل برای هر پیام. راهنمای پشتیبانگیری امن از چتهای رمزشده کمک میکند بازیابی را با نگهداری مدرک اشتباه نگیرید.
چگونه ادعای تمامیت یک پیامرسان را بسنجیم؟
به عبارت «رمزگذاریشده» بسنده نکنید. بپرسید:
- کدام گفتگوها و فایلها سرتاسری رمز میشوند؟
- سرویس از کدام الگوریتم AEAD استفاده میکند؟
- ویرایش و حذف چگونه ثبت و نمایش داده میشوند؟
- کاربر چگونه تغییر کلید مخاطب را تشخیص میدهد؟
- سرور چه متادیتا، محتوا یا عضویتی را کنترل میکند؟
- آیا تماسها همان تضمینهای پیامها را دارند؟
- آیا پروتکل مستقل ممیزی شده است؟
Livara مشخصات و ابزارهایی برای بررسی برخی ادعاهای خود منتشر میکند و کاربران Android میتوانند checksum فایل APK را در Proof Lab برای بررسی آفلاین برنامه با SHA-256 مقایسه کنند. بااینحال، پروتکلهای Livara مستقلاً ممیزی نشدهاند. انتشار مشخصات و بردارهای آزمون به بررسی کمک میکند، اما جای ممیزی مستقل را نمیگیرد.
برای گفتگوهای خصوصی، ادعای اصلی Livara محدود و روشن است: AES-256-GCM باید دستکاری بسته را آشکار کند و ویرایشها نیز باید رمز شوند. این ادعا به معنای دفتر ثبت تغییرناپذیر، حذف قطعی همه نسخهها یا مدرک حقوقی خودکار نیست.
پرسشهای رایج
آیا مدیر سرور میتواند متن پیام رمزشده را عوض کند؟
در طراحی درست با AES-256-GCM، مدیر سرور بدون کلید پیام نمیتواند متن رمزشده را تغییر دهد و برچسب اصالت معتبری بسازد. او همچنان میتواند بسته را حذف، مسدود یا دیر تحویل دهد. این تضمین دستگاه آلوده یا ویرایش مجاز فرستنده را پوشش نمیدهد.
آیا برچسب «ویرایششده» ثابت میکند نسخه قبلی چه بوده است؟
خیر. این برچسب فقط میگوید محتوای نمایشدادهشده پس از ارسال تغییر کرده است، مگر آنکه برنامه تاریخچه نسخهها را نیز نگه دارد. رمزگذاری میتواند اصالت رویداد ویرایش را بررسی کند، اما خودبهخود متن قبلی را حفظ نمیکند.
آیا شماره ایمنی اصالت همه پیامها را تضمین میکند؟
خیر. شماره ایمنی به بررسی تعلق کلید رمزنگاری به مخاطب و تشخیص تغییر آن کمک میکند. این بررسی نمیگوید چه کسی هنگام ارسال دستگاه را در دست داشته، پیام راست است یا دستگاه بدافزار ندارد.
آیا حذف برای همه، پیام را از همهجا پاک میکند؟
خیر. این قابلیت ممکن است نسخه داخل برنامه را کنار بگذارد، اما فایل ذخیرهشده، اعلان، اسکرینشات یا ثبت قبلی را پس نمیگیرد. حذف برای همه ماندگاری را کاهش میدهد؛ پاکشدن از دستگاه گیرنده یا سامانههای دیگر را تضمین نمیکند.
