چابکی رمزنگاری یعنی توانایی انتقال یک پروتکل از یک مجموعهٔ رمزنگاری به مجموعه‌ای دیگر، بدون از دست دادن تعهدات امنیتی روشن. در پیام‌رسانی، این کار فراتر از اضافه کردن نام یک الگوریتم جدید است. کلاینت‌های قدیمی، گیرندگان آفلاین، پیام‌های ذخیره‌شده و دستگاه‌های پیوندشده همگی باید در طول این گذار رفتاری قابل پیش‌بینی داشته باشند.
سند RFC 7696 از IETF، چابکی الگوریتم را مسئله‌ای مربوط به مهاجرت توصیف می‌کند که شناسه‌ها، پیاده‌سازی‌ها و تغییرات عملیاتی را در بر می‌گیرد. شمارهٔ نسخه به شناسایی آنچه در حال استفاده است کمک می‌کند؛ اما به‌تنهایی مهاجرت را امن نمی‌کند.
سه نسخه‌ای که به‌راحتی با هم اشتباه می‌شوند
یک پیام‌رسان می‌تواند نسخهٔ برنامه، نسخهٔ پروتکل ارتباطی و شناسهٔ مجموعهٔ رمزنگاری داشته باشد. این‌ها به پرسش‌های متفاوتی پاسخ می‌دهند:
| شناسه | به ارزیاب چه می‌گوید | چه چیزی را اثبات نمی‌کند |
|---|---|---|
| انتشار برنامه | کدام بیلد نرم‌افزار نصب شده است | اینکه همهٔ گفت‌وگوها از جدیدترین پروتکل استفاده می‌کنند |
| نسخهٔ پروتکل | کدام قالب پیام و قواعد وضعیت اعمال می‌شوند | اینکه پیاده‌سازی آن قواعد را درست رعایت می‌کند |
| شناسهٔ الگوریتم یا مجموعه | کدام مؤلفه‌های رمزنگاری انتخاب شده‌اند | اینکه امکان تنزل در مذاکره وجود ندارد |
یادداشت‌های انتشار باید رابطهٔ این موارد را روشن کنند. اگر فقط گفت‌وگوهای تازه‌ساخته‌شده از روش جدید استفاده کنند یا یک کلاینت پیوندشدهٔ قدیمی باعث بازگشت به روش قبلی شود، عبارت «رمزنگاری جدید عرضه شد» مبهم است.
یک مهاجرت امن باید چه چیزهایی را مشخص کند
از یک سناریوی مشخص شروع کنید: آلیس امروز به‌روزرسانی می‌کند؛ باب با یک گوشی قدیمی همچنان آفلاین است. آلیس پیامی می‌فرستد و بعد دستگاه دومی اضافه می‌کند. هر دستگاه باید چه چیزی را بپذیرد، ذخیره کند و نمایش دهد؟
طرحی که بتوان آن را بررسی کرد، دست‌کم به این پرسش‌ها پاسخ می‌دهد:
- هر طرف چگونه از نسخه‌های پشتیبانی‌شدهٔ طرف دیگر باخبر می‌شود؟
- آیا نسخهٔ انتخاب‌شده به‌عنوان بخشی از نشست احراز اصالت می‌شود؟
- وقتی هیچ نسخهٔ قابل‌قبول مشترکی وجود ندارد، چه اتفاقی می‌افتد؟
- آیا یک واسط مخرب می‌تواند اطلاعات یک قابلیت را حذف کند و استفاده از حالت ضعیف‌تری را القا کند؟
- آیا پیام‌های قدیمی همچنان خواندنی‌اند و کدام کلیدهای قدیمی هنوز لازم‌اند؟
- آیا بازیابی نسخهٔ پشتیبان، وضعیت منسوخ پروتکل را دوباره فعال می‌کند؟
- الگوریتم‌های منسوخ‌شده چه زمانی غیرفعال می‌شوند، به‌جای اینکه فقط استفاده از آن‌ها توصیه نشود؟
یک شکست آشکار اغلب امن‌تر از تغییر بی‌سروصدا به حالتی است که کاربر قصد استفاده از آن را نداشته است. اما رفتار دقیق هنگام شکست و بازیابی باید مستند شود تا افراد برای دور زدن مشکل به کانالی بدون حفاظت پناه نبرند.
یک ماتریس عملی برای آزمون ارتقا
ارتقای امنیتی به چیزی بیش از یک گفت‌وگوی موفق میان دو نصب تازه نیاز دارد. این موارد را با داده‌های غیرحساس آزمایش کنید:
| آزمون | شواهدی که باید ثبت شوند |
|---|---|
| ارتباط کلاینت جدید با کلاینت قدیمی | پروتکل انتخاب‌شده یا نتیجهٔ روشن ناسازگاری |
| آفلاین بودن گیرنده هنگام ارتقا | رفتار تحویل و رمزگشایی پس از اتصال دوباره |
| بازگشت دستگاه پیوندشدهٔ قدیمی | اینکه آیا می‌تواند بخواند، ارسال کند یا حالت پیش‌بینی‌نشده‌ای را تحمیل کند |
| اضافه شدن عضو ناسازگار به گروه | سیاست صریح گروه و وضعیت قابل‌مشاهده برای کاربر |
| بازیابی نسخهٔ پشتیبان پس از کنار گذاشتن یک روش | اینکه وضعیت پشتیبانی‌نشده رد می‌شود یا مهاجرت می‌کند |
| دست‌کاری فرادادهٔ نسخه | شکست احراز اصالت به‌جای تنزل پنهانی |
این‌ها معیارهای ارزیابی‌اند، نه ادعای اینکه محصولی مشخص این آزمون‌ها را گذرانده است. شناسه‌های بیلد و نتایج مشاهده‌شده را نگه دارید تا بتوان پسرفت بعدی را از تغییر مستندات تشخیص داد.
نام پروتکل‌های Livara را چگونه بخوانیم
Livara در مستندات امنیتی خود نام LVR1 را برای گفت‌وگوهای مستقیم و LGS1 را برای گروه‌های خصوصی به کار می‌برد. این نام‌ها مسئولیت‌ها را از هم جدا می‌کنند؛ نباید آن‌ها را نشانهٔ استانداردسازی یا ممیزی مستقل دانست. آن صفحه همچنین رفتار کلاینت‌ها یا گروه‌هایی را توضیح می‌دهد که نمی‌توانند پیش‌نیازهای حالت رمزنگاری‌شده را برآورده کنند.
شواهد مفید بعدی عبارت‌اند از مشخصات نسخه‌دار، بردارهای آزمون، قواعد سازگاری و نتایج بررسی مرتبط با یک انتشار مشخص. Proof Lab به‌روشنی محدودتر بودن دامنهٔ نمایش خود را بیان می‌کند. اجرای عملیات پایهٔ رمزنگاری در مرورگر با آزمودن همهٔ مسیرهای مهاجرت در برنامه یکسان نیست.
کاربران هنگام ارتقای رمزنگاری چه کنند
کلاینت‌های پشتیبانی‌شده را به‌روز نگه دارید، اطلاعیه‌های امنیتی دربارهٔ سازگاری دستگاه‌ها را بخوانید و به تغییر نشانه‌های هویت یا وضعیت رمزنگاری توجه کنید. تصور نکنید آیکون جدید برنامه یعنی همهٔ گروه‌ها و نسخه‌های پشتیبان قدیمی از حفاظت تازه برخوردار شده‌اند. اگر محصول نمی‌تواند توضیح دهد حفاظت کدام داده‌ها تغییر کرده است، پیش از اشتراک‌گذاری مطالب حساس سؤال کنید.
چابکی رمزنگاری خوب، تغییر را قابل بررسی می‌کند. مشخص می‌کند چه چیزی تغییر کرده، طرف‌های ارتباط چگونه بر سر آن توافق می‌کنند، چه چیزهایی ممکن است اشتباه پیش برود و سازوکار قدیمی از چه زمانی دیگر پذیرفته نمی‌شود.
