AES-GCM-HKDF جریان AEAD

این سند به طور رسمی تابع ریاضی نشان‌داده‌شده توسط کلیدهای جریانی AES-GCM-HKDF را تعریف می‌کند که در قالب پروتو به‌عنوان type.googleapis.com/google.crypto.tink.AesGcmHkdfStreamingKey کدگذاری شده‌اند.

این رمزگذاری بر اساس HRRV15 1 است. برای تجزیه و تحلیل امنیتی، به HS20 2 مراجعه می کنیم.

کلید و پارامترها

کلیدها با قسمت های زیر توصیف می شوند (همه اندازه های این سند بر حسب بایت هستند):

  • \(\mathrm{KeyValue}\)، یک رشته بایت.
  • \(\mathrm{CiphertextSegmentSize} \in \{1, 2, \ldots, 2^{31}-1\}\).
  • \(\mathrm{DerivedKeySize} \in \{16, 32\}\).
  • \(\mathrm{HkdfHashType} \in \{\mathrm{SHA1}, \mathrm{SHA256}, \mathrm{SHA512}\}\).

کلیدهای معتبر علاوه بر این ویژگی های زیر را برآورده می کنند:

  • \(\mathrm{len}(\mathrm{KeyValue}) \geq \mathrm{DerivedKeySize}\).
  • \(\mathrm{CiphertextSegmentSize} > \mathrm{DerivedKeySize} + 24\) (این برابر است با \(\mathrm{len}(\mathrm{Header}) + 16\) همانطور که بعدا توضیح داده شد).

کلیدهایی که هیچ یک از این ویژگی‌ها را برآورده نمی‌کنند توسط Tink رد می‌شوند، چه زمانی که کلید تجزیه می‌شود یا زمانی که کلید اولیه مربوطه ایجاد می‌شود.

عملکرد رمزگذاری

برای رمزگذاری یک پیام \(\mathrm{Msg}\) با داده های مرتبط\(\mathrm{AssociatedData}\)، یک سرصفحه ایجاد می کنیم، پیام را به بخش هایی تقسیم می کنیم، هر بخش را رمزگذاری می کنیم و بخش های رمزگذاری شده را به هم متصل می کنیم.

سربرگ را ایجاد کنید

یک رشته تصادفی یکنواخت \(\mathrm{Salt}\) به طول\(\mathrm{DerivedKeySize}\) و یک رشته تصادفی یکنواخت \(\mathrm{NoncePrefix}\)به طول 7 انتخاب می کنیم.

سپس \(\mathrm{Header} := \mathrm{len}(\mathrm{Header}) \| \mathrm{Salt} \| \mathrm{NoncePrefix}\)را تنظیم می کنیم، جایی که طول هدر به صورت یک بایت کدگذاری می شود. توجه داشته باشید که \(\mathrm{len}(\mathrm{Header}) \in \{24, 40\}\).

در مرحله بعد، از HKDF 3 با تابع هش ارائه شده توسط \(\mathrm{HkdfHashType}\)و ورودی های \(\mathrm{ikm} := \mathrm{KeyValue}\)، \(\mathrm{salt} := \mathrm{Salt}\)و \(\mathrm{info} := \mathrm{AssociatedData}\)، با طول خروجی \(\mathrm{DerivedKeySize}\)استفاده می کنیم. ما نتیجه را \(\mathrm{DerivedKey}\)می نامیم.

پیام را تقسیم کنید

پیام \(\mathrm{Msg}\) در مرحله بعدی به بخش هایی تقسیم می شود: \(\mathrm{Msg} = M_0 \| M_1 \| \cdots \| M_{n-1}\).

طول آنها برای برآوردن موارد زیر انتخاب شده است:

  • \(\mathrm{len}(M_0) \in \{0,\ldots, \mathrm{CiphertextSegmentSize} - \mathrm{len}(\mathrm{Header}) - \mathrm{16}\}\).
  • اگر \(n>1\)، پس \(\mathrm{len}(M_1), \ldots, \mathrm{len}(M_{n-1}) \in \{1,\ldots, \mathrm{CiphertextSegmentSize} - \mathrm{16}\}\).
  • اگر \(n>1\)، پس \(\mathrm{len}(M_{0}), \ldots, \mathrm{len}(M_{n-2})\) باید حداکثر طول را مطابق با محدودیت های بالا داشته باشد.

\(n\) ممکن است حداکثر \(2^{32}\)باشد. در غیر این صورت، رمزگذاری با شکست مواجه می شود.

بلوک ها را رمزگذاری کنید

برای رمزگذاری بخش \(M_i\)، ما \(\mathrm{IV}_i := \mathrm{NoncePrefix} \| \mathrm{i} \| b\)را محاسبه می کنیم، که در آن \(\mathrm{i}\) در رمزگذاری big-endian 4 بایت است و بایت $b$ 0x00 است اگر $i < n-1$ و 0x01 در غیر این صورت.

سپس \(M_i\) با استفاده از AES-GCM 4 رمزگذاری می کنیم، که در آن کلید\(\mathrm{DerivedKey}\)است، بردار اولیه \(\mathrm{IV}_i\)است، و داده های مرتبط رشته خالی است. \(C_i\) نتیجه این رمزگذاری است (یعنی الحاق \(C\) و \(T\) در بخش 5.2.1.2 مرجع مرتبط AES-GCM).

بخش های رمزگذاری شده را به هم متصل کنید

در نهایت، همه بخش‌ها به‌عنوان \(\mathrm{Header} \| C_0 \| \cdots \| C_{n-1}\)به هم متصل می‌شوند که متن رمز نهایی است.

رمزگشایی

رمزگشایی رمزگذاری را معکوس می کند. ما از هدر برای بدست آوردن\(\mathrm{NoncePrefix}\)استفاده می کنیم و هر بخش از متن رمز شده را به صورت جداگانه رمزگشایی می کنیم.

APIها ممکن است (و معمولاً اجازه می دهند) دسترسی تصادفی یا دسترسی به ابتدای یک فایل را بدون بازرسی انتهای فایل مجاز کنند. این عمدی است، زیرا امکان رمزگشایی \(M_i\) از \(C_i\)، بدون رمزگشایی همه بلوک های متن رمز شده قبلی و باقی مانده وجود دارد.

با این حال، APIها باید مراقب باشند که به کاربران اجازه ندهند خطاهای انتهای فایل و رمزگشایی را با هم اشتباه بگیرند: در هر دو مورد، API احتمالاً باید یک خطا را برگرداند، و نادیده گرفتن تفاوت می‌تواند منجر به این شود که حریف بتواند به طور مؤثر فایل‌ها را کوتاه کند.

سریال سازی و تجزیه کلیدها

برای سریال سازی یک کلید در قالب "Tink Proto"، ابتدا پارامترها را به روشی واضح در پروتوی ارائه شده در aes_gcm_hkdf_streaming.proto نگاشت می کنیم. version فیلد باید روی 0 تنظیم شود. سپس این را با استفاده از سریال‌سازی پروتو معمولی سریال می‌کنیم و رشته حاصل را در مقدار فیلد یک پروتوی KeyData قرار می‌دهیم. فیلد type_url روی type.googleapis.com/google.crypto.tink.AesGcmHkdfStreamingKey تنظیم کردیم. سپس key_material_type روی SYMMETRIC قرار می دهیم و آن را در یک مجموعه کلید قرار می دهیم. ما معمولا output_prefix_type روی RAW قرار می دهیم. استثنا این است که اگر کلید با مقدار متفاوتی برای output_prefix_type تجزیه شود، Tink ممکن است RAW یا مقدار قبلی را بنویسد.

برای تجزیه یک کلید، فرآیند فوق را معکوس می کنیم (به روش معمول هنگام تجزیه پروتوها). فیلد key_material_type نادیده گرفته می شود. مقدار output_prefix_type را می توان نادیده گرفت یا کلیدهایی را که output_prefix_type متفاوت از RAW دارند رد کرد. کلیدهایی که دارای version متفاوت از 0 هستند باید رد شوند.

مشکلات شناخته شده

انتظار نمی رود که پیاده سازی های تابع رمزگذاری فوق امن باشد. به ایمنی چنگال مراجعه کنید.

منابع

  1. Hoang, Reyhanitabar, Rogaway, Vizar, 2015. رمزگذاری آنلاین تأیید شده و عدم استفاده مجدد از آن. CRYPTO 2015. https://eprint.iacr.org/2015/189 ↩

  2. Hoang, Shen, 2020. امنیت رمزگذاری جریان در کتابخانه Tink Google. https://eprint.iacr.org/2020/1019 ↩

  3. RFC 5869. تابع استخراج و بسط کلید استخراج (HKDF) مبتنی بر HMAC. https://www.rfc-editor.org/rfc/rfc5869 ↩

  4. NIST SP 800-38D. توصیه برای حالت‌های عملیات رمز بلوکی: حالت Galois/Counter Mode (GCM) و GMAC. https://csrc.nist.gov/pubs/sp/800/38/d/final ↩