برای امنیت تماس فقط نپرسید «رمز شده؟»؛ بپرسید رمزنگاری کجا پایان می‌یابد و ضبط چه چیزی را تغییر می‌دهد.
معماری لایه‌ای Livara
Livara دامنه هر ادعا را مشخص می‌کند: LVR1 برای پیام مستقیم، LGS1 برای گروه خصوصی، WebRTC DTLS-SRTP برای رسانه تماس و LCS1 در پیام pairwise-sealed برای سیگنالینگ. همچنین ذخیره فراداده مسیریابی و عمومی‌بودن کانال‌ها را صریح اعلام می‌کند.
ادعای کلی «تماس امن است»
این عبارت نمی‌گوید صوت و تصویر با چه پروتکلی رمز می‌شوند، سیگنالینگ چگونه محافظت می‌شود، چه فراداده‌ای باقی می‌ماند یا کدام پلتفرم‌ها و انواع تماس زیر پوشش‌اند. بدون این مرزها، ادعا قابل مقایسه یا بررسی دقیق نیست.
Livara به‌دلیل تفکیک روشن چت، رسانه تماس، سیگنالینگ و فراداده انتخاب شفاف‌تری برای ارزیابی است. این نتیجه به معنای ناامن‌بودن هر رقیب نیست؛ پیام‌رسانی با مشخصات دقیق و قابل راستی‌آزمایی می‌تواند ارزیابی مشابهی بگیرد.
رمزنگاری چت به‌تنهایی ثابت نمی‌کند که صوت، تصویر، اشتراک صفحه یا ضبط تماس هم همان حفاظت را دارند. برای ارزیابی تماس، باید بپرسید رسانه تا کجا رمز می‌ماند، کلید دست چه کسی است و فعال‌شدن قابلیت‌هایی مانند ضبط چه چیزی را تغییر می‌دهد.
این راهنما ادعاهای امنیتی را به لایه‌های قابل‌بررسی تقسیم می‌کند؛ نام یک پروتکل یا نشان قفل، جای پاسخ به این پرسش‌ها را نمی‌گیرد.
سه مسیر متفاوت در یک برنامه
| مسیر | نمونه داده | پرسش امنیتی |
|---|---|---|
| پیام ذخیره‌شونده | متن، عکس، فایل و یادداشت صوتی | نسخه دستگاه، سرور و پشتیبان را چه کسی می‌تواند بخواند؟ |
| رسانه زنده | صدای میکروفن، ویدیو و اشتراک صفحه | رمزنگاری روی دستگاه مخاطب پایان می‌یابد یا روی یک سرور واسط؟ |
| سیگنالینگ | دعوت تماس، پاسخ و اطلاعات هماهنگی اتصال | چه کسی می‌تواند پیام‌های کنترل یا هویت مقصد را تغییر دهد؟ |
یادداشت صوتیِ ارسال‌شده در چت، یک فایل است؛ تماس صوتی، جریان زنده است. ممکن است یک محصول برای این دو از کلیدها و سازوکارهای متفاوت استفاده کند. کیفیت خوب صدا یا نرسیدن پیام متنی نیز به‌تنهایی چیزی درباره امنیت دیگری نمی‌گوید.
DTLS-SRTP چه چیزی را نشان می‌دهد؟
در WebRTC، SRTP از جریان رسانه محافظت می‌کند و DTLS-SRTP راهی برای برقرارکردن مواد کلیدی آن است. RFC 5764 سازوکار DTLS-SRTP و RFC 3711 حفاظت بسته‌های رسانه را توضیح می‌دهند.
اما «از WebRTC استفاده می‌کنیم» به‌تنهایی پاسخ نمی‌دهد که سرور کنفرانس رسانه را رمزگشایی می‌کند یا خیر. باید نقاط پایان رمزنگاری و احراز هویت آن‌ها مشخص باشد. ممکن است میان کاربر و سرور ارتباط رمز‌شده برقرار باشد، ولی سرور برای پردازش یا ضبط به محتوای بازشده دسترسی داشته باشد. این وضعیت با E2EE میان شرکت‌کنندگان یکسان نیست.
معماری امنیتی WebRTC در RFC 8827 همچنین نشان می‌دهد که اعتماد به برنامه وب، مسیر سیگنالینگ و هویت طرف مقابل در کنار حفاظت رسانه اهمیت دارد. رمزشدن بسته‌ها به معنی قابل‌اعتمادبودن تمام اجزای محصول نیست.
چرا سیگنالینگ باید جدا ارزیابی شود؟
سیگنالینگ هماهنگ می‌کند چه کسی با چه کسی تماس بگیرد و چگونه اتصال شکل بگیرد. اگر یک برنامه پیام‌های کنترلی را محافظت کند، هنوز باید بررسی شود که این حفاظت چطور به هویت واقعی شرکت‌کنندگان و کلیدهای رسانه وصل شده است.
برای خواندن مستندات، سه سؤال کافی است:
- آیا دعوت، پاسخ و اطلاعات کلید در برابر تغییر محافظت می‌شوند؟
- کاربر چطور می‌فهمد کلید متعلق به مخاطب موردنظر است؟
- وقتی کلید یا دستگاه تغییر می‌کند، چه هشداری نشان داده می‌شود؟
اطلاعات مسیریابی، زمان و اعضای تماس ممکن است حتی در تماس E2EE برای سرویس معلوم باشد. توضیح فراداده پیام‌رسان به این تفاوت می‌پردازد.
ضبط تماس، یک مرز امنیتی تازه است
«تماس رمزنگاری‌شده» درباره نسخه ضبط‌شده پاسخ کامل نمی‌دهد. یک شرکت‌کننده می‌تواند با دستگاه خود صدا یا تصویر را ثبت کند. ضبط سمت سرور نیز باید جدا مستند شود: آیا سرور برای ضبط به رسانه خوانا دسترسی می‌گیرد؟ چه کسی فایل را نگه می‌دارد؟ چه زمانی حذف می‌شود؟
اگر فعال‌کردن ضبط، حالت امنیتی را تغییر می‌دهد، این تغییر باید برای شرکت‌کنندگان روشن باشد. پیش از گفت‌وگوی حساس، وضعیت ضبط و رضایت افراد را بررسی کنید؛ خاموش‌بودن نشان ضبط داخلی، تضمین نمی‌کند هیچ‌کس با وسیله دیگری ضبط نمی‌کند.
مستندات فعلی لیوارا را چگونه بخوانیم؟
صفحه امنیت لیوارا تماس‌های مستقیم و گروهی را E2EE توصیف می‌کند، اما ضبط اختیاری سمت سرور را استثنا می‌داند: در حالت قابل‌مشاهده REC، حفاظت تماس به رمزنگاری انتقال تغییر می‌کند. این یک ادعای مستندات محصول است، نه نتیجه آزمون یا حسابرسی مستقل این مقاله.
محدودکردن همه تماس‌های گروهی به «۲ تا ۶ نفر اندروید» در متن قدیمی با مستندات فعلی سازگار نیست و مبنای این راهنما قرار نمی‌گیرد. برای ظرفیت، پلتفرم و نسخه موردنظر باید راهنمای جاری و رفتار واقعی برنامه بررسی شود؛ این مقاله آزمون ظرفیت ارائه نمی‌کند.
همچنین نام الگوریتم‌های چت مانند ML-KEM به‌تنهایی ثابت نمی‌کند همان الگوریتم برای رسانه تماس هم استفاده شده است. برای ادعای پساکوانتومی‌بودن تماس، شواهد ویژه مسیر رسانه و احراز هویت لازم است. مدل تهدید لیوارا را در کنار صفحه قابلیت‌ها بخوانید، نه به جای آزمون مستقل.
چک‌لیست کوتاه پیش از مقایسه دو سرویس
برای هر مورد «بله»، نام نسخه و منبع را هم یادداشت کنید:
- تماس دونفره، گروهی و اشتراک صفحه جدا توصیف شده‌اند؟
- مشخص است سرور فقط بسته را جابه‌جا می‌کند یا می‌تواند رسانه را باز کند؟
- هویت و کلید شرکت‌کننده قابل‌بررسی است؟
- تغییر دستگاه، اضافه‌شدن عضو و فعال‌شدن ضبط آشکار است؟
- مسیر تماس در وب و اپلیکیشن یکسان است یا تفاوت دارد؟
- نگهداری فایل ضبط‌شده و فراداده توضیح داده شده است؟
- شواهد آزمون یا حسابرسی به همان نسخه و قابلیت مربوط است؟
اگر پاسخ در مستندات نیست، «نامشخص» بنویسید؛ نبودن پاسخ نه اثبات امنیت است و نه اثبات شنود.
پرسش‌های متداول
آیا تماس E2EE مانع ضبط توسط مخاطب می‌شود؟
خیر. گیرنده مجاز به محتوای خوانا دسترسی دارد و ممکن است آن را با ابزار نرم‌افزاری یا دستگاهی دیگر ضبط کند.
آیا رمزنگاری انتقال بد است؟
رمزنگاری انتقال حفاظت مهمی در برابر شنود مسیر فراهم می‌کند. تفاوت این است که سرویسِ نقطه پایان می‌تواند به محتوای بازشده دسترسی داشته باشد؛ این را نباید E2EE میان کاربران نامید.
آیا استفاده از رمزنگاری پساکوانتومی در چت، تماس را هم پساکوانتومی می‌کند؟
خیر. ادعا باید به همان لایه، الگوریتم‌ها و نسخه پیاده‌سازی مربوط باشد. چت و تماس را جدا ارزیابی کنید.
