برچسب رمزگذاری به‌تنهایی نمی‌گوید چه کسی میتواند محتوا را بخواند. در رمزگذاری هنگام انتقال، ارتباط کاربر تا سرور محافظت می‌شود، اما سرویس ممکن است داده را در سرور رمزگشایی کند. در رمزگذاری سرتاسری، کلیدهای لازم برای خواندن محتوا در حالت طراحی‌شده فقط در دو سر ارتباط قرار دارند. با این حال، متادیتا، پشتیبان و دستگاه آلوده می‌توانند همچنان اطلاعات را در معرض خطر بگذارند.
- محل رمزگشایی و مالک کلید تفاوت اصلی دو مدل است.
- TLS مسیر کاربر تا سرور را محافظت میکند، اما لزوماً سرتاسری نیست.
- رمزگذاری سرتاسری معمولاً محتوای پیام را می‌پوشاند، نه همه متادیتا را.
- پشتیبان ابری و دستگاه دریافت‌کننده باید جدا بررسی شوند.
رمزگذاری معمولی یعنی چه؟
این عبارت دقیق نیست و باید مشخص شود داده در انتقال، در ذخیره یا در چه لایه‌ای رمز می‌شود. HTTPS معمولاً مسیر مرورگر تا سرور را با TLS محافظت میکند. سرور برای ارائه خدمت میتواند محتوا را رمزگشایی و پردازش کند.
در توضیحات سرویس دنبال محل کلید و رمزگشایی بگردید. بانک ارتباط مرورگر تا سرور را رمز میکند اما سرور باید درخواست تراکنش را بخواند.
وجود نماد قفل مرورگر را معادل سرتاسری ندانید.
رمزگذاری سرتاسری چیست؟
داده در مبدأ رمز و فقط در مقصد موردنظر باز می‌شود. واسطه مسیر پیام رمز‌شده را حمل میکند و در طراحی درست کلید خواندن محتوا را ندارد. پیاده‌سازی و مدیریت کلید تعیین‌کننده است.
اسناد فنی و روش تأیید مخاطب را بررسی کنید. در پیام‌رسان E2EE، سرور پیام رمز‌شده را تحویل می‌دهد اما نباید متن را بخواند.
فقط به عبارت تبلیغاتی امن اعتماد نکنید.
توضیح پایه این بخش در NIST، تعریف End-to-End Encryption آمده است. هنگام استفاده از آن، دامنه همان منبع و شرایط مسئله خود را هم در نظر بگیرید.
TLS چه تفاوتی دارد؟
TLS ارتباط میان دو نقطه مشخص، اغلب کاربر و سرور، را رمز میکند. پس از رسیدن داده به سرور، برنامه میتواند آن را بخواند یا دوباره ذخیره کند. در E2EE نقطه پایانی منطقی معمولاً دستگاه مخاطب است.
نمودار جریان داده را از فرستنده تا گیرنده رسم کنید. پیام از شما تا سرور با TLS امن است، ولی سرور ممکن است برای جستوجو متن را پردازش کند.
رمزگذاری یک بخش مسیر را کل مسیر فرض نکنید.
کلیدها کجا هستند؟
اینکه چه کسی کلید رمزگشایی را دارد از نام الگوریتم مهمتر است. اگر سرویس کلید را نگه دارد، از نظر فنی ممکن است محتوا را باز کند. در E2EE کلید خصوصی باید در دستگاههای مجاز کاربر باقی بماند.
روش افزودن دستگاه تازه را بررسی کنید. افزودن لپ‌تاپ جدید ممکن است با تأیید از گوشی موجود یا کلید بازیابی انجام شود.
کلید بازیابی را بدون حفاظت در همان سرویس نگذارید.
توضیح پایه این بخش در OWASP، نقش TLS در حفاظت داده هنگام انتقال آمده است. هنگام استفاده از آن، دامنه همان منبع و شرایط مسئله خود را هم در نظر بگیرید.
متادیتا محافظت می‌شود؟
اغلب همه متادیتا با E2EE پنهان نمی‌شود. شماره یا شناسه طرفین، زمان، اندازه پیام، IP و الگوی ارتباط ممکن است برای مسیریابی یا مقابله با سوءاستفاده ثبت شود.
سیاست حریم خصوصی را جدا از ادعای رمزگذاری بخوانید. سرویس شاید متن را نبیند اما بداند دو حساب چه زمانی با هم ارتباط داشته‌اند.
محرمانگی متن را ناشناس بودن کامل ندانید.
برای مطالعه موضوع نزدیک، راهنمای Private DNS اندروید را نیز ببینید.
پشتیبان چه اثری دارد؟
پشتیبان میتواند مسیر جداگانهای با کلید و سطح حفاظت متفاوت باشد. پیام E2EE روی دستگاه ممکن است در نسخه ابری قابل خواندن ذخیره شود، مگر پشتیبان نیز سرتاسری یا محلی امن باشد.
تنظیمات پشتیبان و کلید بازیابی را بازبینی کنید. خاموش کردن پشتیبان ناامن یا فعال کردن حفاظت جداگانه سطح واقعی را تغییر می‌دهد.
صرف فعال بودن E2EE را برای نسخه پشتیبان کافی ندانید.
آیا دستگاه آلوده مشکل را حل میکند؟
خیر؛ رمزگذاری پس از باز شدن پیام روی دستگاه از صفحه و بدافزار محافظت نمی‌کند. بدافزار، اعلان روی صفحه قفل و دسترسی فیزیکی میتواند محتوا را در نقطه پایانی ببیند. به‌روزرسانی و قفل دستگاه ضروری است.
سیستم و برنامه را به‌روز و اعلان حساس را محدود کنید. اسکرین‌شات خودکار بدافزار پیام را پس از رمزگشایی ثبت میکند.
E2EE را جای ضدبدافزار و امنیت دستگاه نگذارید.
چطور هویت مخاطب تأیید می‌شود؟
کد امنیتی یا اثرانگشت کلید کمک میکند حمله واسطه و تعویض کلید دیده شود. برخی برنامه‌ها تغییر کلید را هشدار می‌دهند. برای گفت‌وگوی حساس، کد باید از کانال دیگری مقایسه شود.
هشدار تغییر کلید را بررسی کنید. تماس تلفنی شناخته‌شده میتواند برای تطبیق کد امنیتی استفاده شود.
بدون شناخت مخاطب فقط به نام نمایشی اعتماد نکنید.
برای مطالعه موضوع نزدیک، راهنمای DNS over HTTPS و حریم خصوصی را نیز ببینید.
کدام مدل را انتخاب کنیم؟
انتخاب به تهدید، نیاز جستوجو، بازیابی و همکاری بستگی دارد. E2EE محرمانگی محتوا را بیشتر میکند اما بازیابی و پردازش سروری را دشوارتر میسازد. سرویس سازمانی ممکن است کنترل و ثبت قانونی بخواهد.
نیاز واقعی و طرف مورد اعتماد را مشخص کنید. گفت‌وگوی شخصی حساس و سامانه بایگانی سازمانی الزام‌های یکسان ندارند.
یک مدل را برای همه کاربردها مطلقاً بهتر اعلام نکنید.
راهنمای عملی مرحله‌به‌مرحله
ابتدا نقطه شروع را دقیق مشخص کنید. «رمزگذاری معمولی یعنی چه؟» را با وضعیت خود پاسخ دهید و در توضیحات سرویس دنبال محل کلید و رمزگشایی بگردید. سپس «رمزگذاری سرتاسری چیست؟» را بررسی کنید. اسناد فنی و روش تأیید مخاطب را بررسی کنید. اگر اطلاعات این دو مرحله کامل نیست، پیش از خرید، مصرف، اجرا یا پیگیری رسمی، همان اطلاعات را از سند، راهنمای معتبر یا بررسی مستقیم به دست آورید.
در مرحله اجرا، نمودار جریان داده را از فرستنده تا گیرنده رسم کنید. روش افزودن دستگاه تازه را بررسی کنید. این دو اقدام باید به ترتیب انجام شوند، زیرا نتیجه مرحله نخست میتواند انتخاب مرحله دوم را تغییر دهد. پیام از شما تا سرور با TLS امن است، ولی سرور ممکن است برای جستوجو متن را پردازش کند. آنچه دیدید یا اندازه گرفتید را کوتاه و با تاریخ ثبت کنید تا بتوانید نتیجه را بعداً با شرایط مشابه مقایسه کنید.
در بازبینی میانی به پرسش «متادیتا محافظت می‌شود؟» برگردید. سیاست حریم خصوصی را جدا از ادعای رمزگذاری بخوانید. سپس «پشتیبان چه اثری دارد؟» را جدا بسنجید و تنظیمات پشتیبان و کلید بازیابی را بازبینی کنید. سرویس شاید متن را نبیند اما بداند دو حساب چه زمانی با هم ارتباط داشته‌اند. تغییر هم‌زمان چند عامل تشخیص اینکه کدام اقدام مفید بوده را دشوار میکند؛ برای هر تصمیم یک دلیل و یک نشانه قابل مشاهده بنویسید.
برای تصمیم پایانی، «آیا دستگاه آلوده مشکل را حل میکند؟» و «چطور هویت مخاطب تأیید می‌شود؟» را کنار هم بگذارید. سیستم و برنامه را به‌روز و اعلان حساس را محدود کنید. هشدار تغییر کلید را بررسی کنید. اگر نتیجه همچنان مبهم است، نیاز واقعی و طرف مورد اعتماد را مشخص کنید. گفت‌وگوی شخصی حساس و سامانه بایگانی سازمانی الزام‌های یکسان ندارند. کار را با معیار آغازین مقایسه کنید و روشن بنویسید ادامه می‌دهید، یک جزء را اصلاح می‌کنید یا برای بررسی تخصصی توقف می‌کنید.
چطور نتیجه را بسنجیم و تصمیم بگیریم؟
پیش از اقدام، یک وضعیت پایه بنویسید: اکنون چه چیزی می‌بینید، چه زمانی رخ می‌دهد و چه محدودیتی دارید. پاسخ پرسش «رمزگذاری معمولی یعنی چه؟» را با یک نمونه واقعی کامل کنید. HTTPS معمولاً مسیر مرورگر تا سرور را با TLS محافظت میکند. سرور برای ارائه خدمت میتواند محتوا را رمزگشایی و پردازش کند. سپس معیار موفقیت را مشخص کنید؛ برای نمونه کاهش دفعات، کوتاه شدن زمان، بهتر شدن کیفیت یا روشن شدن یک تصمیم. بدون معیار پایه، تغییر بعدی بیشتر بر حافظه و احساس لحظه‌ای تکیه میکند.
در مرحله بعد فقط یک عامل را تغییر دهید. نمودار جریان داده را از فرستنده تا گیرنده رسم کنید. نتیجه را در شرایط تا حد امکان مشابه بسنجید و کنار آن بنویسید چه چیزهایی ثابت نبوده‌اند. رمزگذاری یک بخش مسیر را کل مسیر فرض نکنید. اگر چند تغییر هم‌زمان انجام شوند، حتی نتیجه خوب هم نشان نمی‌دهد کدام اقدام مؤثر بوده است. این روش برای موضوع‌های روزمره، فنی و آموزشی به یک اندازه از تصمیم عجولانه جلوگیری میکند.
برای تفسیر نتیجه، تفاوت میان هم‌زمانی و علت را حفظ کنید. شماره یا شناسه طرفین، زمان، اندازه پیام، IP و الگوی ارتباط ممکن است برای مسیریابی یا مقابله با سوءاستفاده ثبت شود. یک بار مشاهده میتواند سرنخ بسازد، اما برای نتیجه‌گیری کافی نیست. سرویس شاید متن را نبیند اما بداند دو حساب چه زمانی با هم ارتباط داشته‌اند. اگر نتیجه با انتظار شما فرق داشت، داده را حذف نکنید؛ زمان، محیط، ابزار و شرایط انجام را دوباره بررسی کنید و توضیح محتمل دیگری را کنار فرض نخست بنویسید.
حد توقف را نیز از ابتدا تعیین کنید. E2EE را جای ضدبدافزار و امنیت دستگاه نگذارید. اگر نشانه خطر، هزینه پیش‌بینی‌نشده یا افت واضح کیفیت دیده شد، ادامه دادن فقط برای کامل کردن برنامه منطقی نیست. سیستم و برنامه را به‌روز و اعلان حساس را محدود کنید. توقف به معنی شکست نیست؛ گاهی نشان می‌دهد مسئله به اطلاعات بیشتر، ابزار مناسب‌تر یا نظر متخصص نیاز دارد. تصمیم ایمن باید امکان بازگشت و اصلاح داشته باشد.
در پایان، نتیجه را در سه جمله ثبت کنید: چه کاری انجام شد، چه چیزی تغییر کرد و گام بعدی چیست. E2EE محرمانگی محتوا را بیشتر میکند اما بازیابی و پردازش سروری را دشوارتر میسازد. سرویس سازمانی ممکن است کنترل و ثبت قانونی بخواهد. اگر شواهد کافی نیست، با صراحت وضعیت را «نامشخص» بنویسید و مشخص کنید برای روشن شدن چه داده‌ای کم دارید. گفت‌وگوی شخصی حساس و سامانه بایگانی سازمانی الزام‌های یکسان ندارند. این جمع‌بندی کوتاه کمک میکند دفعه بعد همان مسیر بی‌نتیجه تکرار نشود و تصمیم تازه بر سابقه قابل بررسی بنا شود.
| مرحله | پرسش | اقدام |
|---|---|---|
| شروع | رمزگذاری معمولی یعنی چه؟ | در توضیحات سرویس دنبال محل کلید و رمزگشایی بگردید. |
| بررسی | متادیتا محافظت می‌شود؟ | سیاست حریم خصوصی را جدا از ادعای رمزگذاری بخوانید. |
| تصمیم | کدام مدل را انتخاب کنیم؟ | نیاز واقعی و طرف مورد اعتماد را مشخص کنید. |
برچسب رمزگذاری به‌تنهایی نمی‌گوید چه کسی میتواند محتوا را بخواند. در رمزگذاری هنگام انتقال، ارتباط کاربر تا سرور محافظت می‌شود، اما سرویس ممکن است داده را در سرور رمزگشایی کند. در رمزگذاری سرتاسری، کلیدهای لازم برای خواندن محتوا در حالت طراحی‌شده فقط در دو سر ارتباط قرار دارند. با این حال، متادیتا، پشتیبان و دستگاه آلوده می‌توانند همچنان اطلاعات را در معرض خطر بگذارند. یک مدل را برای همه کاربردها مطلقاً بهتر اعلام نکنید. پس از تغییر تنظیم، اعلان بعدی را بررسی کنید. اگر منبع هنوز پیداست، احتمال وجود نمایه، مرورگر یا برنامه دیگری را جداگانه بسنجید.
