یک پیام‌رسان می‌تواند نماد قفل نشان دهد، خود را خصوصی بنامد و همچنان پرسش‌های مهمی را بی‌پاسخ بگذارد.
کدام گفت‌وگوها رمزگذاری می‌شوند؟ آیا پیوست‌ها محافظت می‌شوند؟ کلیدها کجا ذخیره می‌شوند؟ سرور چه اطلاعاتی نگه می‌دارد؟ هنگام گم شدن دستگاه چه اتفاقی می‌افتد؟ آیا کلیدهای رمزگذاری می‌توانند بدون هشدار تغییر کنند؟
این جزئیات به شما کمک می‌کنند هم حفاظت‌های مفید و هم شواهدی را که هنوز وجود ندارند بشناسید. هیچ چک‌لیستی به‌تنهایی گواهی امن بودن یک محصول نیست.
این راهنما ۱۲ پرسش کاربردی در اختیارتان می‌گذارد تا پیش از سپردن گفت‌وگوهای شخصی، فایل‌های محرمانه یا کارهای حساس به یک پیام‌رسان رمزگذاری‌شده بپرسید.
پیام‌رسان امن چیست؟
پیام‌رسان امن سرویسی ارتباطی است که برای حفاظت از گفت‌وگوها در برابر دسترسی غیرمجاز، شنود، تصاحب حساب و افشای ناخواستهٔ داده‌ها طراحی شده است.
یک پیام‌رسان خصوصی جدی باید دست‌کم از انتقال امن شبکه، احراز هویت قوی حساب، کنترل‌های دسترسی دقیق و رویه‌های روشن مدیریت داده استفاده کند.
برای گفت‌وگوهای بسیار خصوصی، باید رمزگذاری سرتاسری نیز ارائه دهد.
رمزگذاری سرتاسری یا E2EE با رمزگذاری محتوای پشتیبانی‌شده روی دستگاه فرستنده و رمزگشایی آن روی دستگاه گیرندهٔ مجاز، از آن محافظت می‌کند. سرویس می‌تواند داده‌های رمزگذاری‌شده را بدون نیاز به متن خوانای پیام تحویل دهد.
بااین‌حال، رمزگذاری فقط بخشی از امنیت پیام‌رسانی است.
ارزیابی کامل باید این موارد را نیز در نظر بگیرد:
- کدام گفت‌وگوها رمزگذاری می‌شوند
- آیا عکس‌ها و فایل‌ها همان حفاظت را دریافت می‌کنند
- کلیدهای خصوصی کجا ذخیره می‌شوند
- مخاطبان چگونه می‌توانند کلیدها را تأیید کنند
- چه فراداده‌ای همچنان قابل مشاهده است
- بازیابی حساب و کلید چگونه کار می‌کند
- هنگام نفوذ به دستگاه چه اتفاقی می‌افتد
- سرویس چگونه محدودیت‌های خود را مستند می‌کند
برای آشنایی عمیق‌تر، مطلب «توضیح رمزگذاری سرتاسری» را بخوانید.
چرا واژهٔ «رمزگذاری‌شده» کافی نیست
تقریباً همهٔ سرویس‌های پیام‌رسان امروزی ترافیک شبکه را با HTTPS، TLS یا روش انتقال محافظت‌شدهٔ دیگری رمزگذاری می‌کنند.
این حفاظت مهم است، اما لزوماً به معنای رمزگذاری سرتاسری گفت‌وگو نیست.
در رمزگذاری انتقال، داده‌ها هنگام جابه‌جایی بین دستگاه شما و سرویس محافظت می‌شوند. سرویس همچنان ممکن است محتوای خوانا را دریافت کند و سپس از طریق اتصال محافظت‌شدهٔ دیگری تحویل دهد.
در E2EE، محتوای پشتیبانی‌شدهٔ پیام پیش از رسیدن به سرویس پیام‌رسان، برای شرکت‌کنندگان رمزگذاری می‌شود.
این تفاوت تعیین می‌کند چه کسی از نظر فنی ممکن است به متن پیام دسترسی داشته باشد.
به همین دلیل باید پرسش‌های دقیق بپرسید، نه اینکه برچسب کلی «رمزگذاری‌شده» را بپذیرید.
| ادعا | پرسشی که باید بپرسید |
|---|---|
| «چت‌های شما رمزگذاری می‌شوند» | فقط هنگام انتقال رمزگذاری می‌شوند یا به‌صورت سرتاسری؟ |
| «داده‌های شما امن هستند» | کدام داده‌ها، در برابر کدام تهدیدها و برای چه مدت؟ |
| «ما نمی‌توانیم پیام‌های شما را بخوانیم» | آیا این موضوع چت‌های مستقیم، گروه‌ها، رسانه‌ها، تماس‌ها و نسخه‌های پشتیبان را شامل می‌شود؟ |
| «خصوصی از پایه» | چه فراداده و اطلاعات عملیاتی همچنان در دسترس می‌ماند؟ |
| «بازیابی امن» | چه کسی می‌تواند کلیدهای رمزگذاری را بازگرداند و به چه اطلاعات محرمانه‌ای نیاز است؟ |
۱. کدام گفت‌وگوها رمزگذاری سرتاسری دارند؟
فرض نکنید یک جمله دربارهٔ رمزگذاری به همهٔ بخش‌های برنامه مربوط می‌شود.
یک سرویس پیام‌رسان ممکن است برای این موارد حفاظت‌های متفاوتی ارائه کند:
- گفت‌وگوهای مستقیم دونفره
- گروه‌های خصوصی
- گروه‌های عمومی
- کانال‌های انتشار
- تماس‌های صوتی و تصویری
- استوری‌ها یا پست‌های موقت
- ربات‌ها و حساب‌های خودکار
- تاریخچهٔ همگام‌شدهٔ گفت‌وگو
از ارائه‌دهنده بخواهید مرز دقیق را مشخص کند.
پاسخ قوی چیزی شبیه این است:
متن پیام‌های مستقیم و رسانه‌ها روی دستگاه‌های شرکت‌کنندگان رمزگذاری می‌شوند. گروه‌های خصوصی سازگار با LGS1 رمزگذاری سرتاسری دارند و هنگام تغییر عضویت، کلید فرستنده به‌طور خودکار تعویض می‌شود. کانال‌ها از معماری جداگانه‌ای استفاده می‌کنند که محتوا در آن برای سرور خواناست و به‌عنوان E2EE توصیف نمی‌شوند.
پاسخ ضعیف چیزی شبیه این است:
ارتباطات شما با رمزگذاری در سطح نظامی محافظت می‌شود.
پاسخ اول اطلاعاتی برای ارزیابی در اختیارتان می‌گذارد. پاسخ دوم از زبان پرطمطراق استفاده می‌کند، بدون اینکه محتوای محافظت‌شده یا مدل تهدید را تعریف کند.
۲. آیا عکس‌ها، ویدئوها و پیوست‌ها هم رمزگذاری می‌شوند؟
ممکن است برنامه متن را رمزگذاری کند، اما رسانه‌های بارگذاری‌شده را از طریق سامانهٔ دیگری مدیریت کند.
این موضوع پرسش مهمی ایجاد می‌کند: آیا عکس پیش از بارگذاری در سمت کاربر رمزگذاری می‌شود، یا فقط مجوزهای سرور و رمزگذاری انتقال از آن محافظت می‌کنند؟
دربارهٔ این موارد بپرسید:
- عکس‌ها و ویدئوها
- اسناد
- پیام‌های صوتی
- پیش‌نمایش لینک‌ها
- تصاویر بندانگشتی
- فایل‌های موقت بارگذاری
- رسانه‌های ذخیره‌شده در حافظهٔ نهان
- مجوز دانلود
حفاظت از رسانه‌ها باید جداگانه توضیح داده شود، نه اینکه در عبارتی کلی دربارهٔ «پیام‌ها» پنهان بماند.
دسترسی به بایت‌های رمزگذاری‌شده و دسترسی به کلید رمزگشایی را جداگانه بررسی کنید. برخی طراحی‌ها پیوست‌های رمزگذاری‌شده را از طریق فضای ذخیره‌سازی با محدودیت کمتر توزیع می‌کنند؛ این موضوع خودبه‌خود به معنای افشای متن آشکار نیست. پرسش اصلی این است که آیا فرد غیرمجاز می‌تواند رسانهٔ خوانا یا کلید آن را به دست آورد و مسیر ذخیره‌سازی چه فراداده‌ای آشکار می‌کند.
۳. کلیدهای رمزگذاری کجا تولید و ذخیره می‌شوند؟
قابلیت اعتماد رمزگذاری به شیوهٔ مدیریت کلیدهای آن بستگی دارد.
در E2EE سمت کاربر، داده‌های کلید خصوصی باید تحت کنترل دستگاه‌های شرکت‌کنندگان بمانند. کلیدهای عمومی را می‌توان به اشتراک گذاشت تا مخاطبان ارتباط رمزگذاری‌شده برقرار کنند، اما کلیدهای خصوصی به حفاظت قوی‌تری نیاز دارند.
برای این پرسش‌ها به‌دنبال پاسخ روشن باشید:
- آیا کلید خصوصی روی دستگاه تولید می‌شود؟
- آیا هیچ‌وقت بدون رمزگذاری بارگذاری می‌شود؟
- آیا ارائه‌دهنده می‌تواند آن را استخراج یا جایگزین کند؟
- آیا دستگاه دیگری که به حساب وارد شده می‌تواند آن را خودکار دریافت کند؟
- آیا محل ذخیرهٔ محلی کلید محافظت می‌شود؟
- پس از بازنشانی کلید چه اتفاقی می‌افتد؟
- آیا نصب دوبارهٔ برنامه کلید هویتی جدیدی ایجاد می‌کند؟
لازم نیست مستندات همهٔ جزئیات پیاده‌سازی را آشکار کنند. بااین‌حال، باید مالکیت و چرخهٔ عمر کلیدهای خصوصی را توضیح دهند.
۴. آیا مخاطبان می‌توانند کلیدهای یکدیگر را تأیید کنند؟
رمزگذاری سرتاسری فقط زمانی از گفت‌وگو محافظت می‌کند که کلیدهای رمزگذاری متعلق به شرکت‌کنندگان موردنظر باشند.
بسیاری از سامانه‌های پیام‌رسان امن، کلید عمومی را با اثر انگشت، شمارهٔ ایمنی، کد QR یا مقدار تأیید دیگری نمایش می‌دهند.
دو مخاطب می‌توانند آن مقدار را از طریق کانالی مورداعتماد مقایسه کنند، مانند:
- دیدار حضوری
- تماس صوتی تأییدشده
- حسابی که از قبل احراز هویت شده است
- فهرست راهنمای مورداعتماد شرکت
تأیید کلید اطمینان بیشتری می‌دهد که کلیدهای مورد انتظار استفاده می‌شوند؛ اما به‌تنهایی اثبات هویت شخص نیست. برخی محصولات بررسی‌های شفافیت کلید نیز ارائه می‌کنند، مانند تأیید خودکار Signal. به‌جای الزام همهٔ محصولات به روندی صرفاً دستی، شرایط حساب و نسخه‌های پشتیبانی‌شده را بررسی کنید.
همچنین بپرسید هنگام تغییر اثر انگشت چه اتفاقی می‌افتد.
تغییر کلید ممکن است توضیحی بی‌خطر داشته باشد، مانند بازنشانی، تعویض دستگاه یا عملیات بازیابی. اما تغییر باید قابل مشاهده باشد. جایگزینی بی‌صدا تشخیص تغییر غیرمنتظرهٔ کلید هویت را دشوارتر می‌کند.
۵. سرویس چه فراداده‌ای نگه می‌دارد؟
محتوای پیام و فرادادهٔ پیام دو دستهٔ متفاوت هستند.
ممکن است سرویس نتواند متن پیام دارای E2EE را بخواند، اما همچنان اطلاعات لازم برای مسیریابی، همگام‌سازی و نمایش گفت‌وگو را پردازش کند.
بسته به سامانه، این اطلاعات ممکن است شامل این موارد باشند:
- شناسه‌های حساب فرستنده و گیرنده
- عضویت در گفت‌وگو
- زمان‌مهرهای پیام
- رسیدهای تحویل و خواندن
- اندازهٔ پیام
- رویدادهای واکنش و ویرایش
- نشست‌های دستگاه
- نشانگرهای همگام‌سازی
- داده‌های کلید عمومی
- توکن‌های اعلان فشاری
- سوابق پیشگیری از سوءاستفاده و امنیت
وجود فرادادهٔ عملیاتی خودبه‌خود سرویس را ناامن نمی‌کند.
پرسش‌های مهم این‌ها هستند:
- چه چیزی جمع‌آوری می‌شود؟
- چرا به آن نیاز است؟
- چه مدت نگهداری می‌شود؟
- چه کسی به آن دسترسی دارد؟
- آیا کاربر می‌تواند از آن خروجی بگیرد یا حذفش کند؟
- آیا برای تبلیغات یا پروفایل‌سازی نامرتبط استفاده می‌شود؟
وقتی ارائه‌دهنده بدون تعریف آنچه فراداده می‌داند ادعا می‌کند «هیچ فراداده‌ای» ذخیره نمی‌کند، محتاط باشید.
۶. حساب شما چگونه احراز هویت می‌شود؟
رمزگذاری قوی پیام، ضعف امنیت حساب را جبران نمی‌کند.
مهاجمی که کنترل حساب را به دست می‌آورد ممکن است بتواند خود را جای کاربر جا بزند، کلید جدید ثبت کند، به محتوای خوانا برای سرور دسترسی پیدا کند یا در بازیابی اختلال ایجاد کند.
ارزیابی کنید آیا سرویس حفاظت‌هایی مانند این موارد ارائه می‌دهد:
- مدیریت امن گذرواژه
- محدودسازی نرخ درخواست
- لغو نشست‌ها
- مدیریت روشن دستگاه‌ها یا نشست‌ها
- حفاظت در برابر بازپخش اطلاعات ورود
- رویه‌های امن بازنشانی گذرواژه
- احراز هویت چندعاملی در موارد مناسب
- اعلان تغییرات مهم حساب
همچنین احراز هویت حساب را از رمزگذاری پیام متمایز کنید.
ورود به حساب نشان می‌دهد کسی اطلاعات ورود حساب را دارد. لزوماً ثابت نمی‌کند که دستگاه، کلید خصوصی اصلی رمزگذاری را در اختیار دارد.
۷. بازیابی رمزگذاری‌شده چگونه کار می‌کند؟
بازیابی یکی از دشوارترین مصالحه‌ها در پیام‌رسانی خصوصی را ایجاد می‌کند.
طبیعی است که کاربران پس از تعویض دستگاه به تاریخچهٔ گفت‌وگو دسترسی بخواهند. اما اگر ارائه‌دهنده بتواند همهٔ کلیدهای خصوصی را بی‌سروصدا بازگرداند، ممکن است توان رمزگشایی بیشتری از انتظار کاربران داشته باشد.
طراحی بازیابی محافظت‌شده ممکن است نسخهٔ پشتیبان را در سمت کاربر رمزگذاری کند و به اطلاعات محرمانهٔ بازیابی، کلید عبور یا تأیید دستگاه مورداعتماد نیاز داشته باشد. ابتدا مشخص کنید نسخهٔ پشتیبان چه چیزی دارد: هویت حساب، مخاطبان و تاریخچهٔ پیام‌ها چیزهای متفاوتی هستند.
بپرسید:
- آیا نسخهٔ پشتیبان پیش از بارگذاری رمزگذاری می‌شود؟
- آیا گذرواژهٔ حساب برای بازگردانی آن کافی است؟
- آیا ارائه‌دهنده اطلاعات محرمانهٔ بازیابی را می‌داند؟
- آیا کارکنان پشتیبانی می‌توانند آن اطلاعات محرمانه را بازنشانی کنند؟
- اگر اطلاعات محرمانه گم شود چه اتفاقی می‌افتد؟
- آیا بازگردانی همان اثر انگشت کلید عمومی را حفظ می‌کند؟
- آیا می‌توان بازیابی را غیرفعال کرد؟
پاسخ قابل اعتماد ممکن است محدودیتی ناخوشایند را هم بیان کند: گم شدن هم‌زمان کلید خصوصی و اطلاعات محرمانهٔ بازیابی می‌تواند محتوای رمزگذاری‌شدهٔ قدیمی را غیرقابل بازیابی کند.
این پیامد می‌تواند نشانهٔ یک مرز امنیتی واقعی باشد، نه نقص محصول.
۸. وقتی اتصال شما قطع می‌شود چه اتفاقی می‌افتد؟
امنیت و قابلیت اطمینان باید با هم کار کنند.
اتصال موبایل قطع می‌شود. مرورگرها به خواب می‌روند. دستگاه‌ها شبکه عوض می‌کنند. پیام‌رسانی با طراحی خوب باید قطع موقت اتصال را بدون تکرار پیام‌ها، به‌هم‌ریختن ترتیب یا تضعیف رمزگذاری مدیریت کند.
به‌دنبال مدل آفلاین و همگام‌سازی‌ای باشید که بتواند:
- عمل خروجی را به‌صورت محلی آماده و در صف نگه دارد.
- شناسه‌ای پایدار به آن اختصاص دهد.
- پس از اتصال دوباره، با ایمنی تلاش مجدد کند.
- از ارسال تکراری جلوگیری کند.
- تأیید دریافت سرور را با وضعیت محلی تطبیق دهد.
- تغییرات ازدست‌رفته در زمان آفلاین بودن را دریافت کند.
جداگانه بپرسید برنامه هنگام انتظار پیام، چگونه از محمولهٔ شبکه و صندوق خروجی محلی محافظت می‌کند. E2EE خودبه‌خود ثابت نمی‌کند صف محلی در حالت ذخیره رمزگذاری شده است.
تلاش مجدد شبکه نباید مستلزم تحویل نسخهٔ خوانای پیامی به سرویس تحویل باشد که در حالت عادی رمزگذاری سرتاسری دارد.
۹. مجوز بارگذاری‌ها و اشیای ذخیره‌شده چگونه کنترل می‌شود؟
امنیت رسانه فراتر از رمزگذاری است.
سرویس ممکن است آواتارها، پیوست‌های پیام، تصاویر پس‌زمینه، استوری‌ها، بارگذاری‌های موقت و تصاویر بندانگشتی تولیدشده را مدیریت کند. هر شیء به سیاست دسترسی نیاز دارد.
بررسی کنید آیا برنامه:
- برای دریافت رسانهٔ خصوصی احراز هویت لازم می‌داند
- تأیید می‌کند حساب درخواست‌کننده عضو گفت‌وگوی مرتبط است
- دارایی‌های عمومی را از اشیای پیام خصوصی جدا می‌کند
- بارگذاری‌های بدون پیوست به پیام را پاک‌سازی می‌کند
- اشیای موقت منقضی‌شده را حذف می‌کند
- از ذخیره‌سازی نهان مشترک میان حساب‌ها جلوگیری می‌کند
- از شناسه‌های غیرقابل پیش‌بینی استفاده می‌کند، بدون اینکه غیرقابل پیش‌بینی بودن را جایگزین مجوز دسترسی بداند
فایل خصوصیِ خوانا نباید صرفاً با حدس زدن نشانی آن قابل خواندن شود. برای اشیای رمزگذاری‌شده، نحوهٔ توزیع و لغو کلیدها و قابلیت‌های دسترسی را بررسی کنید. راهنمای مجوزدهی OWASP توصیه می‌کند تصمیم‌های دسترسی به‌طور یکدست، از جمله برای منابع ایستا، اعمال شوند؛ شناسهٔ غیرقابل پیش‌بینی به‌تنهایی سیاست کامل مجوزدهی نیست.
۱۰. آیا چت‌های گروهی به‌شکلی متفاوت محافظت می‌شوند؟
رمزگذاری گروه و کنترل‌های عضویت پرسش‌هایی متفاوت از رمزگذاری چت مستقیم ایجاد می‌کنند.
تغییر عضویت، چند دستگاه، تاریخچهٔ پیام، نقش‌های مدیر، دعوت، حذف اعضا و تعویض کلید همگی الزامات طراحی بیشتری به وجود می‌آورند.
برخی سرویس‌ها برای چت‌های مستقیم و گروهی هر دو E2EE ارائه می‌دهند. برخی دیگر فقط گفت‌وگوهای مستقیم را سرتاسری رمزگذاری می‌کنند و از گروه‌ها با TLS، فضای ذخیره‌سازی نیازمند احراز هویت و کنترل‌های دسترسی سمت سرور محافظت می‌کنند.
مدل دوم همچنان می‌تواند امنیت معناداری ارائه کند، اما مرز اعتماد متفاوتی دارد.
بپرسید آیا سرور می‌تواند محتوای گروه را پردازش کند و آیا در این وضعیت‌ها حفاظت تغییر می‌کند:
- عضوی می‌پیوندد
- عضوی خارج می‌شود
- مدیر کسی را حذف می‌کند
- پیامی ویرایش می‌شود
- تاریخچه با دستگاه جدید همگام می‌شود
- ربات یا یکپارچه‌سازی وارد گروه می‌شود
هرگز فرض نکنید قفلی که در یک نوع گفت‌وگو دیده می‌شود خودبه‌خود به همهٔ انواع دیگر مربوط است.
۱۱. کاربر چه کنترل‌هایی برای حریم خصوصی دارد؟
حریم خصوصی به کنترل پس از رسیدن اطلاعات به سرویس نیز مربوط می‌شود.
به‌دنبال کنترل‌های کاربردی حساب و گفت‌وگو باشید، مانند:
- خروجی گرفتن از داده‌های حساب
- حذف حساب
- لغو نشست‌ها
- پاک کردن تاریخچهٔ محلی یا همگام‌شده
- حذف پیام‌های ارسال‌شده در موارد مجاز
- مدیریت رسیدهای خواندن
- کنترل نمایش پروفایل
- مسدود کردن مخاطبان ناخواسته
- مدیریت پیش‌نمایش اعلان‌ها
- غیرفعال کردن یا حذف نسخه‌های پشتیبان کلید
ارائه‌دهنده باید توضیح دهد حذف فقط نسخهٔ شما، نسخهٔ همهٔ شرکت‌کنندگان یا خود سابقهٔ سرور را از بین می‌برد.
ممکن است گیرنده از قبل پیام را دانلود، کپی، فوروارد یا از آن عکس گرفته باشد. هیچ قابلیت حذفی نمی‌تواند پاک شدن از همهٔ دستگاه‌های نهایی را تضمین کند.
۱۲. آیا ادعاهای امنیتی مشخص و قابل بررسی هستند؟
قوی‌ترین مستندات امنیتی مرزها را تعریف می‌کنند.
به‌دنبال گزاره‌های مشخص دربارهٔ این موارد باشید:
- الگوریتم‌ها و اندازهٔ کلیدها
- عملیات سمت کاربر در برابر سمت سرور
- انواع گفت‌وگوی مشمول E2EE
- رمزگذاری رسانه
- اطلاعات ذخیره‌شده
- احراز هویت
- بازیابی
- تغییر کلیدها
- کنترل‌های دسترسی
- محدودیت‌های شناخته‌شده
- تاریخ آخرین به‌روزرسانی مستندات
با عبارت‌های مبهم محتاطانه برخورد کنید:
- رمزگذاری شکست‌ناپذیر
- حریم خصوصی مطلق
- امنیت در سطح نظامی
- کاملاً ناشناس
- فرادادهٔ صفر
- غیرقابل هک
- رمزگذاری تضمین‌شده برای آینده
هیچ سامانهٔ ارتباطی پیچیده‌ای را نباید فقط با شعار ارزیابی کرد.
ممیزی مستقل، مستندات فنی عمومی، کلاینت‌های دارای ساخت بازتولیدپذیر، بررسی‌های حرفه‌ای و گزارش‌های امنیتی با دامنهٔ روشن می‌توانند اطمینان بیشتری ایجاد کنند. همهٔ آن‌ها سطح یکسانی از شواهد ارائه نمی‌کنند، اما از صفات عالیِ بی‌پشتوانه مفیدترند.
پیام‌رسانی امن: نشانه‌های قوی و علائم هشدار
| نشانهٔ قوی | علامت هشدار |
|---|---|
| ارائه‌دهنده مشخص می‌کند کدام گفت‌وگوها E2EE دارند | همهٔ قابلیت‌ها صرفاً «رمزگذاری‌شده» توصیف می‌شوند |
| مالکیت کلید خصوصی توضیح داده شده است | هرگز دربارهٔ مدیریت کلید صحبت نمی‌شود |
| تغییر کلیدها قابل مشاهده است | کلیدها می‌توانند بی‌صدا تغییر کنند |
| محدودیت‌های بازیابی مستند شده‌اند | پشتیبانی می‌تواند همه‌چیز را بدون توضیح روش بازگرداند |
| دسته‌های فراداده فهرست شده‌اند | ارائه‌دهنده بدون تعریف، ادعای «فرادادهٔ صفر» دارد |
| حفاظت رسانه جداگانه توضیح داده شده است | فقط پیام‌های متنی ذکر شده‌اند |
| گروه‌ها مرز اعتماد مشخصی دارند | ادعاهای چت مستقیم تلویحاً شامل گروه‌ها دانسته می‌شوند |
| صفحات امنیتی جزئیات پیاده‌سازی فعلی را دارند | زبان بازاریابی با مستندات فنی تناقض دارد |
| محدودیت‌ها روشن بیان شده‌اند | سرویس ادعای حفاظت مطلق یا شکست‌ناپذیر دارد |
به‌کارگیری چک‌لیست برای ادعاهای عمومی Livara
صفحهٔ امنیت Livara مستندات محصول ارائه می‌کند، نه گواهی مستقل. مرزهای فعلی آن این موارد را از هم جدا می‌کنند:
- پیام‌های مستقیم: LVR1 برای محتوای پشتیبانی‌شده از توافق کلید ترکیبی P-256 و ML-KEM-768 و رمزگذاری احرازشده استفاده می‌کند.
- گروه‌های خصوصی سازگار: حفاظت کلید فرستندهٔ LGS1؛ عضویت و نقش‌ها همچنان مرزی جداگانه تحت اختیار سرور هستند. گروه‌های قدیمی ناسازگار نباید برچسب E2EE را به ارث ببرند.
- کانال‌های عمومی: محتوای خوانا برای سرور، نه E2EE.
- بازیابی: داده‌های هویتی پیش از بارگذاری رمزگذاری و بسته می‌شوند؛ بازگرداندن آن‌ها بازگرداندن تاریخچهٔ چت نیست.
- فراداده و دستگاه‌ها: سوابق مسیریابی و دستگاه‌های نهاییِ مورد نفوذ خارج از وعدهٔ رمزگذاری محتوا باقی می‌مانند.
این‌ها را ادعاهایی بدانید که باید با نسخهٔ نصب‌شده و مدل تهدید تطبیق دهید. مشخصات پروتکل، بردار آزمون محلی، ممیزی یک نسخهٔ خاص و مشاهدهٔ سرویس زنده شکل‌های متفاوتی از شواهد هستند. جای شواهد مفقود را با فرض امنیت کامل یا آسیب‌پذیری اثبات‌شده پر نکنید.
چک‌لیست ۶۰ ثانیه‌ای پیام‌رسانی امن
پیش از ساخت حساب، بررسی کنید آیا می‌توانید به هر پرسش پاسخ دهید:
- کدام انواع گفت‌وگو رمزگذاری سرتاسری دارند؟
- آیا تصاویر، ویدئوها، اسناد و پیام‌های صوتی مشمول هستند؟
- آیا کلیدهای خصوصی روی دستگاه‌های شرکت‌کنندگان تولید و نگهداری می‌شوند؟
- آیا مخاطبان می‌توانند اثر انگشت کلید یا شمارهٔ ایمنی را مقایسه کنند؟
- آیا تغییر کلیدها قابل مشاهده است؟
- آیا سیاست حریم خصوصی فرادادهٔ ذخیره‌شده را مشخص می‌کند؟
- آیا احراز هویت حساب توضیح داده شده است؟
- آیا فرایند بازیابی کلید از ورود معمولی جداست؟
- آیا درخواست‌های رسانهٔ خصوصی احراز هویت و مجوزدهی می‌شوند؟
- آیا رمزگذاری هنگام ماندن در صف آفلاین فعال می‌ماند؟
- آیا گروه‌ها و کانال‌ها مرز امنیتی دقیقی دارند؟
- آیا محدودیت‌ها بدون وعده‌های اغراق‌آمیز مستند شده‌اند؟
موارد بی‌پاسخ را «نامشخص» علامت بزنید، نه خودبه‌خود «امن» یا «ناامن». ارائه‌دهنده لازم نیست معماری یکسانی با همهٔ رقبا داشته باشد.
اما باید پاسخ‌هایی به‌اندازهٔ کافی دقیق ارائه کند تا کاربران بفهمند به چه چیزی اعتماد می‌کنند.
امن‌ترین انتخاب به مدل تهدید شما بستگی دارد
هیچ پیام‌رسان جهان‌شمولی وجود ندارد که خودبه‌خود برای همهٔ افراد و موقعیت‌ها بهترین باشد.
گروه خانوادگی، محیط کار، روزنامه‌نگار و منبع او، تیم درمانی و جامعهٔ عمومی ممکن است به ترکیب‌های متفاوتی از این موارد نیاز داشته باشند:
- محرمانگی
- تأیید هویت
- ناشناس‌بودن
- مدیریت گروه
- نگهداری پیام‌ها
- انطباق با مقررات
- بازیابی
- پشتیبانی از چند دستگاه
- کد متن‌باز
- ممیزی مستقل
- سهولت استفاده
ابتدا بپرسید از چه چیزی و در برابر چه کسی محافظت می‌کنید.
برای ارتباطات شخصی معمول، خطرهای اصلی ممکن است سرقت حساب، شبکهٔ ناامن، دستگاه گم‌شده یا جمع‌آوری بیش‌ازحد داده باشند.
برای ارتباطات پرخطرتر، شاید به هویت‌های تأییدشده، سیاست پیام‌های ناپدیدشونده، دستگاه‌های ایمن‌سازی‌شده، رویه‌های عملیاتی سخت‌گیرانه و بررسی امنیتی مستقل نیز نیاز داشته باشید.
رمزگذاری نمی‌تواند دستگاه مورد نفوذ را ترمیم کند یا مانع اشتراک‌گذاری پیام توسط گیرندهٔ مورداعتماد شود.
حریم خصوصی با انتظارهای دقیق آغاز می‌شود
پیام‌رسان قابل اعتماد از کاربران نمی‌خواهد باور کنند همهٔ خطرها از بین رفته‌اند.
توضیح می‌دهد:
- چه چیزی محافظت می‌شود
- کدام دستگاه‌ها کلیدها را دارند
- سرور چه چیزی را پردازش می‌کند
- چه فراداده‌ای باقی می‌ماند
- بازیابی چگونه کار می‌کند
- E2EE از کجا شروع می‌شود و کجا پایان می‌یابد
- کدام حفاظت‌ها هنوز پیاده‌سازی نشده‌اند
این شفافیت به کاربران امکان تصمیم‌گیری آگاهانه می‌دهد.
مستندات روشن برای ارزیابی ضروری‌اند، اما برای تشخیص امن‌ترین برنامه کافی نیستند. کیفیت پیاده‌سازی، به‌روزرسانی به‌موقع، یافته‌های مستقل و خطرهای استفادهٔ واقعی شما نیز مهم‌اند. راهنمای انتخاب ابزار EFF نیز توصیه می‌کند از تهدیدهای خود شروع کنید و باز بودن را فرصتی برای بررسی بدانید، نه تضمین.
برای گام بعدی، آزمایشی بی‌خطر انجام دهید: یک مخاطب را تأیید کنید، پیوستی نمونه بفرستید، دستگاه‌های پیوندشده را مرور کنید، دامنهٔ پشتیبان‌گیری را بررسی کنید و مطمئن شوید هر دو شرکت‌کننده می‌توانند تنظیمات را به‌طور قابل اتکا به کار ببرند. آزمایش را با همان اطلاعات محرمانه‌ای که می‌خواهید محافظت کنید انجام ندهید.
پرسش‌های متداول
چه چیزی یک پیام‌رسان را امن می‌کند؟
پیام‌رسان امن انتقال محافظت‌شدهٔ شبکه، احراز هویت قوی، کنترل‌های دسترسی دقیق، مدیریت امن کلید، مدیریت مسئولانهٔ داده و مرزهای حریم خصوصیِ روشن و مستند را ترکیب می‌کند. برای محتوای پیام خصوصی، رمزگذاری سرتاسری لایهٔ مهم دیگری فراهم می‌کند.
آیا پیام‌رسان رمزگذاری‌شده خودبه‌خود خصوصی است؟
خیر. برنامه می‌تواند محتوای پیام را رمزگذاری کند و همچنان اطلاعات حساب، زمان‌مهرها، عضویت، رسیدها، اطلاعات دستگاه یا دیگر فراداده‌ها را پردازش کند. حریم خصوصی هم به رمزگذاری و هم به رویه‌های گسترده‌تر داده در سرویس بستگی دارد.
آیا رمزگذاری سرتاسری پنهان می‌کند به چه کسی پیام می‌دهم؟
نه لزوماً. E2EE در درجهٔ اول از محتوای پشتیبانی‌شدهٔ پیام محافظت می‌کند. سرویس ممکن است همچنان برای تحویل و همگام‌سازی گفت‌وگوها به اطلاعات فرستنده، گیرنده، عضویت، زمان‌بندی و مسیریابی نیاز داشته باشد.
آیا ارائه‌دهندهٔ پیام‌رسان می‌تواند پیام‌های E2EE را بازیابی کند؟
این موضوع به طراحی کلید و نسخهٔ پشتیبان بستگی دارد. ممکن است ارائه‌دهنده تاریخچهٔ رمزگذاری‌شدهٔ پیام را ذخیره کند، اما کلید خصوصی لازم برای باز کردن آن را نداشته باشد. سامانهٔ بازیابی ممکن است فقط زمانی کلید را بازگرداند که کاربر اطلاعات محرمانهٔ بازیابی جداگانه‌ای ارائه کند.
آیا پیام‌رسانی امنِ مبتنی بر مرورگر ایمن است؟
مرورگر می‌تواند رمزنگاری قوی سمت کاربر انجام دهد، اما امنیت همچنان به پیاده‌سازی برنامه، سلامت مرورگر، امنیت دستگاه، ذخیره‌سازی کلید، تحویل کد برنامه توسط سرور و افزونه‌ها و سیستم‌عامل کاربر بستگی دارد.
آیا چت‌های گروهی همیشه رمزگذاری سرتاسری دارند؟
خیر. برخی سرویس‌ها برای گروه‌ها E2EE ارائه می‌دهند و برخی آن را فقط برای گفت‌وگوهای مستقیم به کار می‌برند. برای مرز دقیق، مستندات ارائه‌دهنده را بررسی کنید.
اگر کلید رمزگذاری من تغییر کند چه می‌شود؟
تغییر کلید ممکن است ناشی از دستگاه جدید، نصب دوباره، بازنشانی کلید یا فرایند بازیابی باشد. پیام‌رسان امن باید تغییر را قابل مشاهده کند و به مخاطبان اجازه دهد اثر انگشت جدید را تأیید کنند.
آیا E2EE برای ارتباطات بسیار حساس کافی است؟
E2EE از محتوا میان دستگاه‌های نهایی پشتیبانی‌شده محافظت می‌کند، اما از دستگاه آلوده یا قفل‌گشایی‌شده محافظت نمی‌کند، رفتار گیرنده را تضمین نمی‌کند و خودبه‌خود فراداده را پنهان نمی‌کند. کاربران پرخطرتر به امنیت قوی دستگاه و امنیت عملیاتی نیز نیاز دارند.
