AES-GCM می‌تواند از محرمانگی پیام محافظت و تغییرات غیرمجاز را شناسایی کند. اما به‌تنهایی به گیرنده نمی‌گوید آیا پیامی که از جهات دیگر معتبر است قبلاً پردازش شده یا نه.
سه نیاز به‌آسانی با هم اشتباه گرفته می‌شوند: زوج‌های یکتای کلید/نانس برای رمزنگاری، احراز اصالت پیام و زمینهٔ آن، و رسیدگی به بازپخش در سطح پروتکل. HKDF می‌تواند در مشتق‌سازی کلید کمک کند، اما هر سه را خودکار برآورده نمی‌کند.
استفادهٔ مجدد از نانس و بازپخش دو رویداد متفاوت‌اند
| رویداد | چه اتفاقی می‌افتد | محافظت لازم |
|---|---|---|
| استفادهٔ مجدد از نانس هنگام رمزنگاری | متن‌های آشکار متفاوت با همان کلید GCM و نانس رمزنگاری می‌شوند | راهبرد قابل‌اعتماد تخصیص کلید/نانس |
| دست‌کاری | متن رمزشده یا زمینهٔ احرازاصالت‌شده تغییر می‌کند | رمزگشایی همراه با احراز اصالت و رد کردن در صورت شکست بررسی |
| بازپخش | یک پیام رمزنگاری‌شدهٔ قبلاً معتبر دوباره تحویل می‌شود | وضعیت و قواعد برنامه برای تشخیص پیام‌های تکراری یا کهنه |
| جابه‌جایی ترتیب | پیام‌های معتبر با ترتیب متفاوت می‌رسند | ترتیب تعریف‌شده در پروتکل و رسیدگی محدود به پیام‌های خارج از ترتیب |
یک متن رمزشدهٔ بازپخش‌شده همچنان می‌تواند برچسب احراز اصالت معتبری داشته باشد؛ چیزی تغییر نکرده است. بنابراین این ادعا که هر پیام تکراری خودکار در احراز اصالت AES-GCM شکست می‌خورد نادرست است. RFC 5116 صریحاً رابط AEAD را از خدمات ضدبازپخش جدا می‌کند.
چرا زوج کلید و نانس نباید تکرار شود؟
نانس GCM لازم نیست محرمانه باشد، اما زیر یک کلید معین باید الزامات یکتایی این طرح را رعایت کند. نانس ۹۶ بیتی یا ۱۲ بایتی رایج است؛ انتخاب این طول، تولید صحیح را تضمین نمی‌کند.
استفادهٔ دوباره از همان کلید و نانس برای متن‌های آشکار متفاوت، جریان کلید رمزنگاری را تکرار می‌کند و روابط میان متن‌های آشکار را آشکار می‌سازد. همچنین می‌تواند اصالت را تضعیف و جعل را ممکن کند. پیامد جدی است، اما نباید آن را افشای خودکار تمام کلیدهای قدیمی یا تمام پیام‌های یک حساب توصیف کرد. دامنهٔ آسیب به کلید تکرارشده و پروتکل بستگی دارد.
NIST SP 800-38D GCM و الزاماتش را تعریف می‌کند. پیاده‌سازی‌ها باید محدودیت‌های فراخوانی و قواعد تولید نانسِ قابل‌اعمال را رعایت کنند، نه یک قاعدهٔ سرانگشتی ساده مانند «تا این تعداد پیام امن است».
HKDF چه کمکی می‌کند؟
HKDF، تعریف‌شده در RFC 5869، از مواد محرمانهٔ ورودی و با مراحل استخراج و گسترش، مواد کلیدی مشتق می‌کند. پروتکل‌ها می‌توانند از برچسب‌های زمینه و ورودی‌های متمایز برای جداسازی کلیدهای کاربردهای مختلف استفاده کنند.
HKDF قطعی است. اگر کلاینتی پس از خرابی یا بازگردانی وضعیت، همان وضعیت و ورودی‌ها را تکرار کند، ممکن است دوباره همان خروجی را مشتق کند. پس افزودن HKDF به طراحی، استفادهٔ مجدد از نانس را ناممکن نمی‌کند.
کلیدهای جداگانه برای هر پیام می‌توانند مقدار محتوای محافظت‌شده زیر هر کلید را کاهش دهند، اما پیش‌برد امن وضعیت، جداسازی کلیدها و حذف همچنان مهم‌اند. مقدار نانس یکسان زیر کلیدهایی که واقعاً متفاوت‌اند، همان خطای تکرار زوج کلید/نانس نیست؛ پروتکل باید اطمینان دهد کلیدها واقعاً متفاوت‌اند.
جلوگیری از بازپخش وظیفهٔ پروتکل است
گیرنده ممکن است شناسه‌های پیام، موقعیت‌های توالی، دوره‌های نشست یا کلیدهای مصرف‌شدهٔ رچت را دنبال کند. فیلدهای مربوط باید احراز اصالت شوند تا مهاجم نتواند برچسب پیام قدیمی را به پیام جدید تغییر دهد.
سپس برنامه باید تعیین کند پیام تکراری چه معنایی دارد. نمایش حباب چت تکراری آزاردهنده است؛ اجرای دوبارهٔ همان عمل ممکن است جدی‌تر باشد. تلاش مجدد شبکه عادی است، بنابراین در کنار بررسی‌های رمزنگاری، اغلب به پردازش هم‌توان نیاز است؛ یعنی تکرار پردازش اثر اضافه‌ای نداشته باشد.
رسیدن کاملاً مرتب تمام پیام‌های معتبر را الزامی نکنید، مگر اینکه پروتکل چنین رفتاری را مشخص کرده باشد. کلاینت‌های موبایل مرتب دوباره متصل می‌شوند، تلاش مجدد می‌کنند و پیام‌های دیررس می‌گیرند. رسیدگی امن، پیام دیررسِ مشروع را از پیام قبلاً مصرف‌شده یا دارای زمینهٔ نادرست تشخیص می‌دهد.
پیش از ادعای محافظت چه چیزهایی را باید آزمود؟
- پس از تخصیص نانس و پیش از ثبت ارسال، راه‌اندازی مجدد کنید: آیا تخصیص می‌تواند تکرار شود؟
- تصویر قدیمی‌تری از وضعیت را بازیابی کنید: آیا کلیدها، شمارنده‌ها یا سوابق بازپخش ممکن است عقب برگردند؟
- از دو پردازشگر کاری یا دستگاه هم‌زمان ارسال کنید: آیا حوزه‌های کلید/نانس آن‌ها جداست؟
- همان پیام معتبر را دو بار تحویل دهید: آیا عمل برنامه فقط یک بار اجرا می‌شود؟
- شناسهٔ نشست یا سرآیند را تغییر دهید: آیا زمینه با سازوکار رمزنگاری مقید شده است؟
- پیام‌های معتبر را خارج از ترتیب تحویل دهید: آیا تأخیرهای پشتیبانی‌شده بدون پذیرش وضعیت کهنه مدیریت می‌شوند؟
APIهای رمزگشاییِ همراه با احراز اصالت باید فقط پس از تأیید موفق، متن آشکار را به برنامه بازگردانند. این یک الزام رابط است؛ نه ادعایی مبنی بر اینکه هیچ پیاده‌سازی‌ای هرگز در داخل، بافر موقت متن آشکار محاسبه نمی‌کند.
خواندن دقیق ادعاهای لیوارا
مستندات امنیتی لیوارا از AES-256-GCM، زنجیره‌های مختص هر پیام و زمینهٔ LVR1/LGS1 نام می‌برد. این مؤلفه‌های پایه به‌تنهایی درستی بازیابی پس از خرابی، تخصیص نانس یا رد بازپخش را اثبات نمی‌کنند. چنین ادعاهایی به جزئیات نسخه‌دار پروتکل و شواهد آزمون نیاز دارند.
یک طراحی قوی هر وظیفه را صریح تعیین می‌کند: مشتق‌سازی کلید، کلیدهای موردنظر را می‌سازد؛ AEAD اصالت محتوا و زمینه را احراز می‌کند؛ و منطق وضعیت‌مند پروتکل تصمیم می‌گیرد آیا یک پیام معتبر اکنون پذیرفتنی است یا نه.
