تغییر صورت مسئله
ویتفیلد دیفی همراه مارتین هلمن در مقالهٔ ۱۹۷۶ «جهت‌های تازه در رمزنگاری» به ایده‌هایی بنیادین در رمزنگاری کلید عمومی پرداخت. این کار به روش‌های تازهٔ برقراری ارتباط امن و امضای دیجیتال مربوط بود.
نکتهٔ آموزشی
توافق بر یک کلید با احراز هویت طرف مقابل یکسان نیست. در یادگیری رمزنگاری، این دو مسئله را جدا کنید؛ امنیت یک پروتکل از ترکیب صحیح اجزا به دست می‌آید، نه از نام یک الگوریتم مشهور.
مسئلهٔ اعتماد پیش از نخستین پیام
اگر دو طرف برای رمزگذاری به یک راز مشترک نیاز داشته باشند، پرسش اولیه این است که آن راز چگونه و از چه مسیر امنی میان آن‌ها توزیع شود. با زیادشدن تعداد کاربران و ارتباط‌ها، مدیریت این رابطه‌ها دشوارتر می‌شود. اندیشهٔ رمزنگاری کلید عمومی، راه تازه‌ای برای صورت‌بندی این مسئله مطرح کرد؛ لازم نیست همهٔ اطلاعاتی که برای آغاز ارتباط استفاده می‌شوند محرمانه باشند.
این توضیح نباید به یک تصور نادرست منجر شود: عمومی‌بودن یک مقدار به معنی بی‌اهمیت‌بودن اصالت آن نیست. ممکن است مقدار قابل انتشار باشد، اما هنوز باید بدانیم آن را به شخص یا سرویس درست نسبت داده‌ایم. محرمانگی و احراز هویت دو نیاز مرتبط ولی متفاوت‌اند.
توافق کلید با احراز هویت فرق دارد
در یک توضیح آموزشی، دو طرف می‌توانند با تبادل مقادیر عمومی و استفاده از رازهای محلی خود، به کلیدی مشترک برسند. اما اگر هیچ راهی برای احراز هویت طرف مقابل وجود نداشته باشد، یک واسطهٔ فعال ممکن است خود را به جای دو طرف معرفی کند. به همین دلیل پروتکل کامل باید علاوه بر ساخت کلید، مسئلهٔ هویت و تمامیت پیام‌ها را هم حل کند.
امضای دیجیتال نیز با رمزکردن کل پیام برای محرمانگی یکسان نیست. یک امضا می‌تواند برای بررسی منشأ و تغییرنکردن داده به کار رود، بدون آنکه لزوماً متن را از همه پنهان کند. جداکردن این نقش‌ها به فهم بهتر TLS، گواهی و اعتماد در سرویس‌های آنلاین کمک می‌کند.
برداشت آموزشی IROSG
وقتی در مرورگر هشدار گواهی می‌بینی، آن را صرفاً مزاحم ظاهر صفحه تصور نکن. ابتدا نام دامنه، تاریخ اعتبار و زنجیرهٔ اعتماد را بررسی کن. اینکه اتصال از نوع رمزگذاری‌شده است، به‌تنهایی ثابت نمی‌کند به سرویس موردنظر وصل شده‌ای.
برای یادگیری، نقش هر جزء یک ارتباط امن را جداگانه بنویس: تبادل کلید، احراز هویت، رمزگذاری داده و بررسی تمامیت. این تمرین جای طراحی پروتکل جدید را نمی‌گیرد؛ در کاربرد واقعی باید از کتابخانه‌ها و پروتکل‌های بررسی‌شده استفاده کرد. تاریخ دیفی و هلمن، نقطهٔ شروع فهم این تمایزهای مهم است.
مسئلهٔ آغاز اعتماد را جدا تعریف کنیم
دو نفر را تصور کنید که می‌خواهند ارتباط محرمانه داشته باشند، اما پیش‌تر رازی مشترک ردوبدل نکرده‌اند. پیش از انتخاب الگوریتم باید روشن شود مهاجم چه چیزی را می‌بیند، چه چیزی را می‌تواند تغییر دهد و هر طرف دربارهٔ هویت دیگری چه می‌داند. این مثال آموزشی به مسئلهٔ آغاز ارتباط اشاره دارد؛ پیاده‌سازی رمزنگاری یا دستور ساخت پروتکل تازه نیست. برای تاریخ کار دیفی و همکاران به منابع اصلی صفحه مراجعه کنید.
یک نقشه با دو طرف و یک مسیر ارتباطی بکشید. سپس تفاوت شنود و تغییر پیام را مشخص کنید. راهکاری که در برابر دیدن پیام‌ها مسئله‌ای را حل می‌کند، الزاماً هویت طرف مقابل را هم تأیید نمی‌کند. همین جداسازی، یکی از مهم‌ترین عادت‌ها در خواندن توضیح‌های رمزنگاری است: باید بدانیم هر ابزار دقیقاً کدام خاصیت را فراهم می‌کند و کدام خاصیت هنوز به سازوکار دیگری نیاز دارد.
محرمانگی، اصالت و تمامیت را مخلوط نکنیم
محرمانه‌بودن محتوا، تغییرنکردن آن و شناخت فرستنده پرسش‌های متفاوت‌اند. اگر در یک طرح فقط بگوییم «داده رمز شده»، هنوز همهٔ این پرسش‌ها پاسخ نگرفته‌اند. برای تمرین، یک جدول از خاصیت مورد نیاز و شاهد یا سازوکار مربوط بسازید. هر خانهٔ خالی، موضوعی برای بررسی است و نباید با نام یک الگوریتم مشهور پر شود.
مثلاً در یک پیام فرضیِ تغییر تنظیمات، دریافت‌کننده باید بداند چه کسی آن را فرستاده، آیا در مسیر تغییر کرده و آیا تکرار پیام مجاز است. حتی اگر متن برای دیگران خوانا نباشد، اجرای دوبارهٔ یک فرمان قدیمی ممکن است مشکل‌ساز شود. این مثال، حمله به سامانهٔ واقعی را توصیف نمی‌کند؛ نشان می‌دهد امنیت کاربردی به معنای عملیات و چرخهٔ پیام نیز وابسته است.
کلید، هویت و چرخهٔ عمر
داشتن یک کلید عمومی با دانستن اینکه کلید متعلق به فردِ مورد نظر است برابر نیست. روش اتصال هویت به کلید باید در طرح مشخص شود. همچنین تغییر، انقضا و از دست‌رفتن کلید پرسش‌های عملی مهمی هستند. این بخش توصیه به طراحی مستقل سازوکار رمزنگاری نیست؛ برای کاربرد واقعی باید از پروتکل‌ها و کتابخانه‌های شناخته‌شده و تنظیم‌های مستند استفاده شود.
در تمرین کاغذی، سه حالت را دنبال کنید: شروع ارتباط، تعویض کلید و اعلام بی‌اعتباری یک کلید قدیمی. بنویسید هر طرف چه چیزی را باید بداند تا تصمیم درست بگیرد. اگر پاسخ به یک فرض شفاهی یا حافظهٔ یک نفر وابسته است، آن فرض را ثبت کنید. چنین تمرینی کمک می‌کند مسئولیت عملیاتی را کنار محاسبات ببینیم و تصور نکنیم انتخاب یک الگوریتم، تمام مسیر اعتماد را حل کرده است.
امنیت یک جزء با امنیت کل سامانه متفاوت است
حتی یک جزء رمزنگاریِ درست ممکن است در برنامه‌ای با کنترل دسترسی نامناسب استفاده شود. ثبت راز در لاگ، ارسال داده به مقصد اشتباه یا مدیریت بد کلید می‌تواند هدف سامانه را نقض کند. هنگام ارزیابی، مسیر داده را از تولید تا مصرف دنبال کنید. این پیشنهاد عمومی است و ادعای وجود نقص در محصول یا پروژهٔ مشخصی محسوب نمی‌شود.
برای یک بررسی آموزشی، بدون استفاده از کلید واقعی، محل‌های ذخیره و انتقال رازهای ساختگی را علامت بزنید. سپس بپرسید چه کسی حق خواندن هر محل را دارد و چه زمانی داده باید حذف شود. مستند عمومی نباید خودِ راز را در بر داشته باشد. جداسازی نمونهٔ ساختگی از اطلاعات عملیاتی، اجازه می‌دهد تیم روش را تمرین کند بدون آنکه تمرین، عامل افشای اطلاعات شود.
چگونه متن رمزنگاری را انتقادی بخوانیم؟
هر ادعای امنیتی را همراه مدل تهدید و پیش‌شرط آن بخوانید. واژه‌هایی مانند امن، تصادفی و غیرقابل شکست بدون تعریف و محدوده کافی نیستند. اگر نویسنده از یک نتیجهٔ نظری به تضمین عملی می‌رسد، ببینید مراحل میانی چگونه پوشش داده شده‌اند. این عادتِ خواندن، هم از بدبینی بی‌پایه جلوگیری می‌کند و هم از اطمینان بیش از شواهد.
در پایان، یک برگه دربارهٔ ارتباط فرضی دو خدمت بنویسید: هویت‌ها، دادهٔ حساس، خاصیت‌های لازم، ابزارِ معتبرِ انتخاب‌شده و مسئول نگه‌داری. بخش تاریخی معرفی دیفی را به‌عنوان زمینه بخوانید و برداشت آموزشی خود را جدا بنویسید. هدف، استفاده از شهرت یک نام برای تأیید یک طرح شخصی نیست؛ باید بتوان حدود اعتماد و پرسش‌های بی‌پاسخ را با زبانی روشن توضیح داد.
