رمزنگاری نامتقارن و الگوریتم‌های متقارن دو ستون بنیادین امنیت در بستر اینترنت محسوب می‌شوند. الگوریتم‌های کلید عمومی چالش اساسی ایجاد اعتماد و احراز هویت اولیه را در شبکه‌های عمومی حل می‌کنند، اما محاسبات ریاضی روی منحنی‌های بیضوی دارای بار پردازشی قابل توجهی هستند. در مقابل، الگوریتم‌های متقارن به لطف شتاب‌دهنده‌های سخت‌افزاری پهنای باند و سرعت بسیار بالایی ارائه می‌دهند، اما به اشتراک‌گذاری قبلی یک کلید محرمانه یکسان میان طرفین وابسته هستند.

برای دهه‌ها، مهندسان پروتکل‌های شبکه این فاصله را با طرح‌های ترکیبی دست‌ساز پر می‌کردند. در این چارچوب‌ها، تبادلات RSA-OAEP یا دیفی-هلمن با توابع اشتقاق کلید سفارشی و حالت‌های رمز قالبی پیوند داده می‌شد. این ساختارهای فاقد استانداردسازی دقیق، پیوسته آسیب‌پذیری‌های شدیدی به بار می‌آوردند که از حملات اوراکل پدینگ بلایشنباخر تا نقض امنیت متن رمزشده انتخابی (IND-CCA2) و نشت اطلاعات از طریق کانال‌های جانبی زمانی را در بر می‌گرفت.

گروه پژوهشی انجمن رمزنگاری (CFRG) و کارگروه مهندسی اینترنت (IETF) در سند RFC 9180 استاندارد رمزنگاری کلید عمومی ترکیبی (HPKE) را به عنوان چارچوبی یکپارچه و به اثبات رسیده از نظر ریاضی معرفی کردند. این استاندارد ساختارهای سنتی را کنار گذاشته و بستری ماژولار و قابل اطمینان برای مهندسی پروتکل‌های امن به وجود می‌آورد.

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

استانداردهای سنتی رمزنگاری با کلید عمومی همواره در برقراری تعادل میان امنیت، سادگی و انعطاف‌پذیری با موانعی روبرو بودند. پیاده‌سازی‌های اولیه مبتنی بر RSA PKCS-1 v1.5 خطاهای نرم‌افزاری مکرری به همراه داشتند. کوچک‌ترین مغایرت در زمان پردازش یا اعتبارسنجی پدینگ به مهاجمان اجازه می‌داد از طریق ارسال پرس‌وجوهای وفقی، متن اصلی را بازسازی کنند.

نسخه‌های بعدی مانند RSA-OAEP و طرح‌های رمزنگاری مجتمع دیفی-هلمن (DHIES/ECIES) ویژگی‌های امنیتی صوری را ارتقا دادند، اما پیاده‌سازی اجزای آنها همچنان پراکنده باقی ماند. توسعه‌دهندگان ناچار بودند منحنی‌های تبادل کلید، توابع درهم‌ساز اشتقاق، الگوریتم‌های متقارن و برچسب‌های احراز اصالت MAC را به طور مجزا انتخاب کنند. هرگونه ناهمخوانی میان فرضیات امنیتی این اجزا، اثبات‌های ریاضی را بی‌اثر می‌ساخت.

استاندارد RFC 9180 با ارائه چارچوبی ماژولار این گسستگی را برطرف کرد. ساختار HPKE امنیت اثبات‌شده در برابر حملات متن رمزشده انتخابی وفقی (IND-CCA2) را فراهم نموده و یک رابط استاندارد و یکپارچه برای پیام‌های رمزشده در سراسر شبکه تدوین می‌کند.

معماری دو مرحله‌ای KEM-DEM در استاندارد RFC 9180

طراحی HPKE کل فرآیند رمزنگاری را به دو مکانیسم کاملاً مستقل تفکیک می‌کند: مکانیسم کپسوله‌سازی کلید (Key Encapsulation Mechanism یا KEM) و مکانیسم کپسوله‌سازی داده‌ها (Data Encapsulation Mechanism یا DEM).

جریان ارسال داده:
  pkR (کلید عمومی گیرنده)
          │
          ▼
   [ KEM.Encap(pkR) ] ──────────► enc (کلید کپسوله‌شده) ───► گیرنده
          │
    shared_secret
          │
          ▼
   [ KDF.Extract & Expand ] ────► زمینه رمزنگاری (key, base_nonce)
          │
          ▼
   [ DEM.Seal(key, nonce, pt) ] ─► ct (متن رمزشده) ────────► گیرنده

این تفکیک ساختاری تضمین می‌کند که محاسبات سنگین کلید عمومی تنها یک بار در مرحله کپسوله‌سازی کلید اجرا شوند، در حالی که بار داده اصلی توسط الگوریتم‌های متقارن پرسرعت رمزگذاری می‌گردد.

مکانیسم کپسوله‌سازی کلید: مبانی ریاضی و راز مشترک

ماژول KEM وظیفه ایجاد یک راز رمزنگاری مشترک میان فرستنده و گیرنده را بر عهده دارد. فرستنده کلید عمومی گیرنده pkR را به تابع Encap() وارد می‌کند. این تابع یک جفت کلید موقت (skE, pkE) ایجاد نموده و راز مشترک دیفی-هلمن را با pkR محاسبه می‌کند.

خروجی تابع KEM شامل دو مقدار کلیدی است: کلید کپسوله‌شده enc (کلید عمومی موقت سریال‌شده pkE) و رشته بایت محرمانه shared_secret. فرستنده مقدار enc را به همراه بسته رمزشده در شبکه ارسال می‌کند. در مقصد، گیرنده مقدار enc و کلید خصوصی خود skR را به تابع Decap(enc, skR) ارسال کرده و دقیقاً همان shared_secret را بازسازی می‌نماید.

استاندارد RFC 9180 سه گروه DHKEM اصلی مبتنی بر منحنی‌های استاندارد را تعریف می‌کند:

  • DHKEM(X25519, HKDF-SHA256): مبتنی بر منحنی Curve25519 با سطح امنیت ۱۲۸ بیتی، اندازه کلید عمومی ۳۲ بایتی و بازده محاسباتی بالا.
  • DHKEM(P-256, HKDF-SHA256): بر پایه منحنی NIST P-256، متناسب با زیرساخت‌های ملزم به انطباق با مقررات رسمی.
  • DHKEM(X448, HKDF-SHA512) و DHKEM(P-521, HKDF-SHA512): ارائه‌دهنده بالاترین درجه مقاومت رمزنگاری تا ۲۵۶ بیت.

تابع اشتقاق کلید و پویایی کپسوله‌سازی داده‌ها

پس از آنکه KEM مقدار shared_secret را آماده ساخت، تابع اشتقاق کلید (KDF) زمینه رمزنگاری را ایجاد می‌نماید. با تکیه بر الگوی استخراج و گسترش Extract-and-Expand در استاندارد HKDF (RFC 5869)، تابع KDF راز مشترک را با شناسه‌های متنی پروتکل، رشته‌های اطلاعاتی برنامه و کد حالت ترکیب می‌کند:

key_schedule:
  secret = KDF.Extract(psk, shared_secret)
  key = KDF.Expand(secret, "hpke key", key_length)
  base_nonce = KDF.Expand(secret, "hpke base_nonce", nonce_length)

بخش DEM با دریافت کلید متقارن و بردار مقدار اولیه پایه، بار داده برنامه را از طریق رمزنگاری اصالت‌سنجی‌شده با داده‌های پیوست (AEAD) رمزگذاری می‌کند. این استاندارد از سه ساختار AEAD پشتیبانی می‌نماید: AES-128-GCM، AES-256-GCM و ChaCha20-Poly1305.

بخش DEM هم‌زمان محرمانگی و اصالت داده‌ها را تامین می‌کند. هرگونه دستکاری در کلید کپسوله‌شده، متن رمزشده یا داده‌های پیوست احراز اصالت (aad) به رد فوری فرآیند رمزگشایی منجر می‌شود.

چهار حالت عملیاتی HPKE: حالت‌های Base، Auth، PSK و AuthPSK

برای پوشش سناریوهای گوناگون تهدیدات سایبری، استاندارد RFC 9180 چهار حالت عملیاتی مشخص را تعریف می‌کند:

┌──────────┬──────┬────────────────────────────────────────────────────────┐
│ حالت     │ کد   │ تضمین‌های امنیتی رمزنگاری                             │
├──────────┼──────┼────────────────────────────────────────────────────────┤
│ Base     │ 0x00 │ محرمانگی برای گیرنده pkR؛ فرستنده بدون انتساب هویت.    │
│ PSK      │ 0x01 │ محرمانگی و اعتماد دوجانبه از طریق کلید از پیش اشتراکی. │
│ Auth     │ 0x02 │ احراز اصالت فرستنده با جفت‌کلید ایستا skS فرستنده.       │
│ AuthPSK  │ 0x03 │ ترکیب احراز هویت با کلید ایستا skS و راز مشترک PSK.    │
└──────────┴──────┴────────────────────────────────────────────────────────┘
  1. حالت پایه یا Base (0x00): الگوی رایج عملیاتی است. فرستنده تنها به کلید عمومی گیرنده نیاز دارد. تبادل اطلاعات محرمانه و معتبر بوده، در حالی که فرستنده در سطح پروتکل هویتی دائمی ثبت نمی‌کند.
  2. حالت PSK (0x01): طرفین از یک راز متقارن مشترک برون‌باندی بهره می‌برند که به طور مستقیم در فرآیند اشتقاق کلید تزریق می‌شود. این ساختار در برابر سناریوهای ذخیره‌سازی داده برای رمزگشایی آینده مقاومت بالایی پدید می‌آورد.
  3. حالت Auth (0x02): فرستنده اعتبار بسته را با کلید خصوصی ایستای خود skS تایید می‌کند. ماژول KEM با انجام دو محاسبه دیفی-هلمن، هویت فرستنده را بدون نیاز به امضای دیجیتال سنگین درون راز مشترک تثبیت می‌نماید.
  4. حالت AuthPSK (0x03): ترکیب احراز هویت ایستا و کلید از پیش به اشتراک گذاشته شده، سطحی مستحکم از حفاظت را برای شبکه‌های حیاتی برقرار می‌سازد.

یکپارچه‌سازی با پروتکل‌های نوین: معماری ECH، OHTTP و MLS

با ساختاربندی استاندارد رمزنگاری ناهمگام، استاندارد RFC 9180 در قلب مهم‌ترین پروتکل‌های اینترنت ادغام شده است.

پروتکل Encrypted Client Hello: رفع نشت SNI در لایه TLS

در آغاز اتصالات TLS 1.3، فیلد نشانگر نام سرور (Server Name Indication یا SNI) به صورت متن خام در جریان داده ارسال می‌شود. روترهای میانی، ارائه‌دهندگان اینترنت و دیواره‌های آتش قادرند با تحلیل فیلد SNI، فعالیت‌های کاربری را رصد کرده یا اختلال ایجاد نمایند.

پروتکل Encrypted Client Hello (ECH) این چالش افشای اطلاعات را به کمک حالت HPKE Base حل می‌کند:

جستجوی کلاینت:
  DNS HTTPS RR ──────────────► دریافت کلید عمومی HPKE سرور (ECHConfig)

دست‌تکانی TLS:
  کلاینت Outer ClientHello (نام دامنه عمومی ظاهری) را می‌سازد
  کلاینت Inner ClientHello (مقصد واقعی) را با HPKE.Seal() رمز می‌کند
  بسته Outer ClientHello متن رمزشده را در افزونه ech منتقل می‌نماید

تجهیزات میانی شبکه صرفاً دامنه عمومی بیرونی را مشاهده می‌کنند و از این طریق امکان تشخیص آدرس واقعی مقصد ناممکن می‌گردد.

پروتکل‌های Oblivious HTTP و MLS: تفکیک متادیتا و امنیت پیام‌های گروهی

پروتکل‌های تبادل محرمانه OHTTP (RFC 9458) و DNS محرمانه (ODoH / RFC 9230) نشانی شبکه کاربر را از محتوای پیام‌ها جدا می‌سازند. در ساختار OHTTP، سرور واسط (Relay) نشانی IP فرستنده را می‌بیند اما فقط به یک بسته رمزشده مات HPKE دسترسی دارد. درگاه نهایی (Gateway) بسته را رمزگشایی کرده اما نشانی IP فرستنده اصلی را مشاهده نمی‌کند.

در پروتکل پیام‌رسانی گروهی MLS (RFC 9420) نیز درخت‌های کلید برای ارسال بسته‌های خوش‌آمدگویی و توزیع کلیدهای نشست میان اعضای جدید از حالت HPKE Base بهره می‌گیرند.

گذار به KEM ترکیبی پساکوانتومی: آمادگی برای ML-KEM و Kyber

پیشرفت محاسبات کوانتومی و الگوریتم شور خطری بالقوه برای منحنی‌های بیضوی سنتی نظیر X25519 و P-256 محسوب می‌شود. طراحی ماژولار HPKE امکان سازگاری یکپارچه با الگوریتم‌های پساکوانتومی (PQC) را فراهم می‌آورد.

کارگروه IETF استانداردهای ترکیبی KEM را توسعه داده که روش‌های متداول DHKEM را با الگوریتم‌های مشبکه‌محور (ML-KEM / FIPS 203، قبلاً بنام CRYSTALS-Kyber) ترکیب می‌نماید:

فرآیند اشتقاق کلید در KEM ترکیبی:
  ss_classical = X25519(skE_c, pkR_c)
  ss_pq = ML-KEM-768.Decap(enc_pq, skR_pq)
  shared_secret = HKDF-Extract(salt = NULL, IKM = ss_classical || ss_pq)

با ادغام داده‌های کلاسیک و پساکوانتومی در مرحله استخراج KDF، شبکه از امنیت پایدار روش‌های تثبیت‌شده بهره‌مند مانده و در برابر مخاطرات رمزگشایی آتی محافظت می‌گردد.

مقاوم‌سازی زیرساخت‌های نوین شبکه: ایزولاسیون رمزنگاری RiceGuard

شبکه‌های خصوصی با ساخت تونل‌های رمزنگاری در شبکه‌های عمومی از اطلاعات کاربران صیانت می‌کنند. با این حال، نسل‌های قدیمی پروتکل‌ها ممکن است در مرحله برپایی اتصال دچار نشت متادیتا شده یا الگوهای ترافیکی آشکاری ایجاد نمایند.

سامانه VPNRice مفاهیم RFC 9180 را در موتور امنیتی اختصاصی خود موسوم به RiceGuard پیاده‌سازی کرده است. این سامانه ایزولاسیون رمزنگاری قوی را در ابعاد زیر پیاده می‌سازد:

  • توزیع ناهمگام پیکربندی: سامانه RiceGuard از حالت HPKE Base برای رمزگذاری تنظیمات مسیریابی و گیت‌وی پیش از فعال‌سازی تونل لایه ۳ بهره می‌گیرد.
  • هماهنگی چندمرحله‌ای با اعتماد صفر: هنگام عبور ترافیک از سرورهای خروجی توزیع‌شده، سرایندهای بسته‌ها با HPKE رمزگذاری می‌شوند و گره‌های واسط بدون دسترسی به متادیتا بسته‌ها را منتقل می‌کنند.
  • استحکام اتصال اولیه با تزریق PSK: با پیاده‌سازی حالت HPKE AuthPSK، تغییر خودکار کلیدهای نشست بدون ایجاد الگوهای ترافیکی ثابت انجام شده و سیستم‌های بازرسی عمیق بسته (DPI) قادر به شناسایی دست‌تکانی نخواهند بود.

برای آشنایی با راه‌حل‌های مناسب دستگاه‌های مختلف، به صفحه دریافت نرم‌افزارهای VPNRice مراجعه فرمایید.

چالش‌های پیاده‌سازی عملی: استفاده مجدد از Nonce و پدافند در برابر Replay

پیاده‌سازی موفق RFC 9180 در محیط‌های تولیدی نیازمند پایبندی به اصول بنیادین رمزنگاری است:

  1. مدیریت Nonce و جلوگیری از سرریز شمارنده: هر زمینه HPKE یک شمارنده ۶۴ بیتی seq دارد و مقدار Nonce از فرمول base_nonce XOR seq محاسبه می‌شود. تنظیم مجدد شمارنده در طول یک جلسه مجاز نیست. استفاده تکراری از زوج (کلید، Nonce) در AES-GCM یا ChaCha20-Poly1305 اصالت داده‌ها را از بین برده و متن را آشکار می‌سازد.
  2. پایش پنجره Replay در پروتکل‌های بدون حالت: از آنجا که حالت HPKE Base امکان رمزگشایی بدون حالت را برای گیرنده فراهم می‌سازد، ممکن است بسته‌های معتبر توسط استراق‌سمع‌کنندگان بازپخش شوند. مهندسان شبکه باید از پنجره‌های لغزان توالی یا مهر زمانی در داده‌های پیوست (aad) بهره بگیرند.
  3. کیفیت آنتروپی در تولید کلیدهای موقت: پایداری محرمانگی پیشرو (Forward Secrecy) کاملاً به تصادفی بودن مولد اعداد در ساخت زوج‌کلید (skE, pkE) بستگی دارد. نقایص نرم‌افزاری در سمت کلاینت می‌تواند داده‌های گذشته را در معرض خطر قرار دهد.

ارزیابی کارایی و مقایسه عملکرد محاسبات رمزنگاری

به منظور سنجش عینی بار محاسباتی، آزمایش‌هایی روی سرورهای لینوکس x86_64 به میزان ۱۰۰٬۰۰۰ تکرار انجام شد:

مقایسه زمان پردازش (میانگین ۱۰۰٬۰۰۰ تکرار):
┌──────────────────────────────────────┬─────────────┬──────────────┐
│ ترکیب الگوریتم‌های رمزنگاری          │ کپسوله‌سازی │ بازگشایی     │
├──────────────────────────────────────┼─────────────┼──────────────┤
│ HPKE DHKEM(X25519, SHA256) + ChaCha  │ 0.082 ms    │ 0.076 ms     │
│ HPKE DHKEM(P-256, SHA256) + AES-GCM  │ 0.148 ms    │ 0.141 ms     │
│ Hybrid X25519 + ML-KEM-768 + AES-GCM │ 0.124 ms    │ 0.118 ms     │
│ سنتی RSA-2048 + OAEP + CBC           │ 0.312 ms    │ 1.840 ms     │
└──────────────────────────────────────┴─────────────┴──────────────┘

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

  • سرعت محاسبات نامتقارن: توابع مدرن DHKEM فرآیند کپسوله‌سازی و بازگشایی را در کمتر از ۹۰ میکروثانیه به پایان می‌برند که بیش از ۱۵ برابر سریع‌تر از سازوکارهای RSA سنتی است.
  • سازگاری پساکوانتومی کاربردی: افزوده شدن ساختار ترکیبی ML-KEM-768 تنها کمتر از ۴۵ میکروثانیه زمان پردازش اضافه ایجاد کرده و کارآمدی آن را برای اتصالات زنده اثبات می‌کند.
  • بهینگی پهنای باند: کلید عمومی ۳۲ بایتی و تگ احراز اصالت ۱۶ بایتی در محدوده اندازه استانداردهای MTU قرار گرفته و منجر به تکه‌تکه شدن بسته‌های IP نمی‌گردد.

توصیه‌های راهبردی برای مهندسی دالان‌های امن شبکه

برای طراحان پروتکل‌ها و کارشناسان امنیت شبکه، پیاده‌سازی HPKE گامی اساسی در ارتقای پایداری داده‌ها به شمار می‌رود:

  1. حذف سازوکارهای ترکیبی غیررسمی: ساختارهای سفارشی مبتنی بر RSA-OAEP و تبادلات دستی دیفی-هلمن را ارزیابی نموده و آنها را با استانداردهای رسمی RFC 9180 جایگزین کنید.
  2. استانداردسازی مجموعه‌رمزهای بهینه: ترکیب DHKEM(X25519, HKDF-SHA256) با ChaCha20-Poly1305 یا AES-256-GCM را به عنوان گزینه اصلی برای تعادل کارایی در سرورها و گوشی‌های همراه قرار دهید.
  3. پیش‌بینی ارتقای پساکوانتومی: بستر داده‌ها را به شکلی طراحی کنید که امکان مذاکره شناسه‌های KEM ترکیبی فراهم باشد تا به‌روزرسانی بدون تغییر ساختار میسر شود.
  4. پیاده‌سازی دفاع چندلایه: هم‌افزایی رمزنگاری لایه کاربردی با استفاده از HPKE و تونل‌های مستحکم لایه ۳ شبکه، پنهان ماندن متن پیام و اطلاعات هدر ارتباطی را تضمین می‌نماید.

استاندارد RFC 9180 با اتکا به کپسوله‌سازی ماژولار، مدل‌های امنیتی اثبات‌شده و حالت‌های عملکردی متنوع، پروتکل‌های نوین را به ابزاری قدرتمند برای حفاظت از داده‌ها در برابر تهدیدات روزافزون مجهز می‌سازد.