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