مجموعه رمزنگاری

از ویکی‌پدیا، دانشنامهٔ آزاد

مجموعه رمزنگاری (cipher suite) مجموعه ای از الگوریتم‌هایی است که به امن کردن برقراری اتصال به شبکه که از (Transport Layer Security (TLS یا نسخه قبلی آن (Secure Socket Layer (SSL استفاده می‌کند، کمک می‌کند. محموعه الگوریتم‌هایی کهٔ cipher suites معمولاً شامل آنهاست: الگوریتم تبادل کلید، الگوریتم رمزگذاری bulk و الگوریتم کد اصالت سنجی پیام (MAC) است.[۱]

مجموعهٔ رمز نگاری در حقیقت روش‌هایی است که می‌تواند برای رمزنگاری استفاده شود و کاربر از آن‌ها پشتیبانی می‌کند.

الگوریتم تبادل کلید: برای تبادل کلید بین دو دستگاه استفاده می‌شود. از این کلید برای رمزگذاری و رمزگشایی پیام‌های ارسال شده بین دو دستگاه استفاده می‌شود.

الگوریتم رمزگذاری bulk: برای رمزگذاری داده‌های ارسال شده استفاده می‌شود.

الگوریتم MAC: یکپارچگی داده‌ها را بررسی می‌کند تا اطمینان از عدم تغییر داده‌های انتقال یافته فراهم شود.

علاوه بر این، مجموعه رمزنگاری‌ها می‌توانند شامل امضاها و الگوریتم‌های تأیید هویت برای کمک به احراز هویت سرور یا کلاینت باشند.

به‌طور کلی صدهامدل مختلف از مجموعه رمزنگاری وجود دارد که شامل ترکیب‌های مختلفی از این الگوریتم‌ها است. برخی از مجموعه رمزنگاری‌ها نسبت به سایرین امنیت بهتری دارند.[۲]

ساختار و کاربرد مفهوم مجموعه رمزنگاری در سند استاندارد TLS تعریف شده‌است.[۳] TLS 1.2 رایج‌ترین نسخه TLS است. نسخه بعدی (TLS (TLS 1.3 شامل موارد دیگری برای رمزگذاری سوئیت‌ها است. TLS 1.3 اخیراً استاندارد شده‌است و هنوز مورد استفاده گسترده‌ای قرار نگرفته‌است. از مجموعه‌های رمزگذاری شده که برای TLS 1.2 تعریف شده‌است نمی‌توان در TLS 1.3 و برعکس استفاده کرد، مگر اینکه در تعریف آنها تصریح شده باشد.

یک لیست مرجع از مجموعه‌های رمزگذاری نام گذاری شده در TLS Cipher Suite Registry ارائه شده‌است.[۴]

تاریخچه[ویرایش]

پروتکل‌ها و الگوریتم‌ها ی رمز نگاری بخشی از پروتکل امنیت لایهٔ انتقال(Secure Socket Layer (SSL از زمان ایجادشان بوده‌اند. . SSL در بیشتر موارد موفق تر از TLS هنگام استفاده بوده‌است. با این وجود از نام مجموعه رمزنگاری در پیش نویس اصلی SSL استفاده نشده‌است در عوض، کلاینت و سرور از میان مجموعه ای کوچک از رمزگذارها برای تأمین امنیت ارتباط خود، توانایی انتخاب داشتند که Cipher-Choice نامیده می‌شد.[۵][۶] تا زمان SSL v3 (آخرین نسخه SSL)که از نام مجموعه رمزنگاری استفاده شد. در هر نسخه TLS از مجموعه رمزنگاری در استانداردسازی آن استفاده شده‌است.[۷] مفهوم و هدف یک مجموعه رمزنگاری از زمان ابداع این اصطلاح تغییر نکرده‌است. این ساختار به عنوان یک ساختار توصیف الگوریتم‌هایی که یک ماشین از آن پشتیبانی می‌کند، استفاده می‌شود تا دو دستگاه تصمیم بگیرند که از کدام یک از الگوریتم‌های مورد استفاده برای تأمین امنیت اتصال خود استفاده کنند. آنچه تغییر کرده نسخه‌های الگوریتم‌هایی هستند که در مجموعه رمزنگاری پشتیبانی می‌شوند. هر نسخه از TLS پشتیبانی از نسخه‌های قوی تر الگوریتم‌ها را اضافه و پشتیبانی از نسخه‌های الگوریتم‌هایی را که به عنوان ناامن شناخته شده‌اند حذف کرده‌است.

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

نحوهٔ نامگذاری[ویرایش]

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

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256[ویرایش]

معنی این نامگذاری این است:

  • TLS پروتکلی است که برای این مجموعه رمزنگاری تعریف شده‌است؛ که معمولاً در بیشتر موارد TLS پروتکل مورد استفاده است.
  • ECDHE_RSA الگوریتم تبادل کلید مورد استفاده را نشان می‌دهد. الگوریتم تبادل کلید برای تعیین اینکه چگونه کلاینت و سرور در حین دستیابی به اطلاعات اصالت سنجی می‌کنند، استفاده می‌شود.
  • AES_128_GCM بیانگر رمزگذاری قالبی است که برای رمزگذاری جریان پیام به همراه نحوه عملکرد رمزگذاری قالبی مورد استفاده قرار می‌گیرد.
  • SHA256 الگوریتم تأیید اعتبارسنجی پیام را نشان می‌دهد که برای تأیید اصالت یک پیام استفاده می‌شود.

فرایند شروع برقراری ارتباط: هماهنگی مجموعه‌های رمزنگاری[ویرایش]

برای استفاده از مجموعه رمزنگاری، کلاینت و سرور باید بر سر استفاده از مجموعه رمزنگاری خاص، برای استفاده در تبادل پیام‌ها توافق کنند. هم کلاینت و هم سرور باید مجموعه رمزنگاری مورد توافق را پشتیبانی کنند. اگر کلاینت و سرور در یک مجموعه رمزنگاری به توافق نرسند، هیچ ارتباطی برقرار نخواهد شد.[۸]این فرایند انتخاب، در طول TLS handshaking protocol رخ می‌دهد که می‌تواند اطلاعات قوانین مذاکره بین دو طرف را در بر بگیرد. TLS 1.3 شامل TLS handshaking protocol است که در مقایسه با گذشته و نسخه فعلی TLS / SSL متفاوت است.

بعد از هماهنگی و توافق بر سر انتخاب اینکه از کدام مجموعه رمزنگاری استفاده کنند، سرور و کلاینت هنوز هم می‌توانند با استفاده از پروتکل Change Cipher Spec در برقراری ارتباط فعلی یا ارتباطات جدید، مجموعه رمزنگاری را تغییر دهند.

برای آزمایش اینکه Tls cipher از کدام سرور پشتیبانی می‌کند، ممکن است از اسکنر SSL / TLS استفاده شود.[۱]

نمایشی تصویری از چگونگی هماهنگی و توافق یک کلاینت با سرور بر روی TLS 1.2 بر سر انتخاب اینکه از کدام مجموعه رمزنگاری استفاده کنند.

عملیات ارتباطی TLS 1.0–1.2[ویرایش]

ابتدا کاربر عملیات فرستادن پیام را آغاز می‌کند و پیام clientHello را که شامل لیستی ازمجموعه رمزنگاری‌ها و نسخهٔ TLS ای است که مورد استفاده قرار می‌دهد را برای سرور ارسال می‌کند. در پاسخ، سرور پیام SERVERHELLO را ارسال می‌کند که مشخص می‌کند سرور از بین مجموعه رمزنگاری‌هایی که کلاینت ارسال کرده‌است کدام را برای ادامه انتخاب می‌کند و پیام ارسالی شامل شناسه نیز است؛ و بعد سرور یک گواهی دیجیتال را برای تأیید هویت خود به کلاینت ارسال می‌کند؛ و ممکن است سرور در صورت لزوم گواهی هویت کلاینت را نیز درخواست کند.

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

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

نمایشی تصویری از چگونگی هماهنگی و توافق یک کلاینت با سرور بر روی TLS 1.3 بر سر انتخاب اینکه از کدام مجموعه رمزنگاری استفاده کنند.

عملیات ارتباطی TLS 1.3[ویرایش]

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

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

بعد از اینکه کاربر پیام نهایی سرور را دریافت کرد، اکنون با سروری که از آن پیام نهایی را دریافت کرده‌است بر سرمجموعه رمزنگاریه ماهنگ شده و به توافق می‌رسد.[۲]

الگوریتم‌های پشتیبانی شده[ویرایش]

در TLS 1.0–1.2[ویرایش]

الگوریتم‌های پشتیبانی شده در مجموعه رمزنگاری TLS 1.0-1.2
کلید تبادل/توافق احراز هویت بلوک/stream ciphers تأیید هویت پیام
RSA RSA RC4 مبتنی بر هش MD5
Diffie–هلمن DSA سه‌گانه DES SHA hash function
ECDH ECDSA AES
SRP IDEA
PSK DES
camellia
ChaCha20

برای کسب اطلاعات بیشتر در مورد الگوریتم‌های پشتیبانی شده در TLS 1.0–1.2 همچنین می‌توانید به لینک رو به رو مراجعه کنید: امنیت لایه انتقال

TLS 1.3[ویرایش]

در TLS 1.3، بسیاری از الگوریتم‌های موروثی که در نسخه‌های اولیه TLS پشتیبانی می‌شدند، برای تلاش در ایمن‌سازی پروتکل کاهش یافته و استفاده نمی‌شوند.[۹] علاوه بر این، همه الگوریتم‌های رمزگذاری و اعتبار سنجی در رمزگذاری تأیید هویت با استفاده از داده‌های مرتبط (AEAD) با هم ترکیب می‌شوند. همچنین یک الگوریتم هش اکنون باید در مشتق کلید مبتنی بر(HMAK) استفاده شود(HKDF).[۱۰] الگوریتم‌های رمزگذاری غیر AEAD (مانند AES_128_CBC) مجاز به استفاده نیستند. این تغییرات به دلیل نقص یا آسیب‌پذیری‌های احتمالی کشف شده از زمان آخرین انتشار انجام شده‌است که می‌تواند منجر به اتصال TLS ناامن شود.

مجموعه رمزنگاری با استفاده از DTLS[ویرایش]

(Datagram Transport Layer Security (DTLS مبتنی بر TLS است اما بجای اتصالات TCP برای اتصالات از UDP در آن استفاده می‌شود. از آنجا که DTLS مبتنی بر TLS است، قادر به استفاده از اکثر مجموعه رمزنگاری‌هایی که برای TLSتعریف شده‌است، می‌باشد. موارد خاصی وجود دارد که هنگام استفادهٔ مجموعه رمز نگاری TLS با DTLS باید در نظر گرفته شود. DTLS از رمزنگاری جریان آر سی ۴ پشتیبانی نمی‌کند، به این معنی که هیچ رمزگذاری TLS با استفاده از RC4 نمی‌تواند با DTLS استفاده شود.[۱۱]

برای تعیین اینکه آیا یک مجموعه رمزنگاری TLS با DTLS سازگار است یا نه نگاه به نامگذاری آنها کمکی نمی‌کند. هر مجموعه رمزگذاری TLS هنوز هم فضای شناسه TLS را به نام خود درج می‌کند.

به عنوان مثال: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

در عوض، تمام پارامترهای رجیسترها ی TLS اکنون شامل پرچم DTLS-OK هستند تا سیگنال‌های مجموعه رمزنگاری از DTLS پشتیبانی کنند.[۱۲]

آسیب‌پذیری[ویرایش]

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

هنگام شروع برقراری ارتباط، کلاینت مدرن بالاترین پروتکل پشتیبانی شده را ارائه می‌دهد. اگر اتصال رخ ندهد، به‌طور خودکار با یک پروتکل پایین‌تر مانند TLS 1.0 یا SSL 3.0 دوباره برقراری ارتباط را امتحان می‌کند تا برقراری ارتباط با سرور موفقیت‌آمیز باشد. هدف از downgrade به این ترتیب است که نسخه‌های جدید TLS با نسخه‌های قدیمی تر سازگار شود. با این وجود، یک حمله کننده می‌تواند از این ویژگی استفاده کند و آن را مورد استفاده قرار دهد تا کلاینت به‌طور خودکار به نسخه ای از TLS یا SSL که ازمجموعه رمزنگاری پشتیبانی می‌کند دست یابد که دارای الگوریتم‌هایی است که به دلیل ضعف امنیتی آسیب‌پذیر شناخته شده‌اند.[۱۳] این موضوع منجر به حمله‌هایی مانند POODLE شده‌است.

یکی از راه‌های جلوگیری از این نقص امنیتی، غیرفعال کردن توانایی سرور یا کلاینت است که می‌توانند به نسخه SSL 3.0 پروتکل خود را کاهش دهند. ایرادی که در این رفع مشکل وجود دارد این است که باعث می‌شود تا برخی سخت‌افزارهای قدیمی توسط سخت‌افزارهای جدید قابل دسترسی و پشتیبانی نباشند. اگر پشتیبانی سخت‌افزار SSL 3.0 برای سخت‌افزار سلسله مراتبی مورد نیاز باشد، یک مجموعه رمزگذاری TLS_FALLBACK_SCSV تأیید شده وجود دارد که تأیید می‌کند downgrade برای اهداف مخرب استفاده نشده‌است.[۱۴]

مجموعه رمزنگاری برای دستگاه‌ها با منابع محدود[ویرایش]

الگوریتم‌های رمزگذاری، تبادل کلید و تأیید اعتبار معمولاً به توان پردازشی زیاد و حافظهی زیادی احتیاج دارند. برای تأمین امنیت دستگاه‌هایی که با قدرت پردازش، حافظه یا ماندگاری باتری محدود هستند مانند آنهایی که به اینترنت اشیا دسترسی دارند، مجموعه رمزنگاری ویژه ای وجود دارد. دو مثال شامل:

هریک از این مجموعه رمزنگاری‌ها برای اجرا در دستگاه‌هایی با محدودیت در پردازش قدرت و حافظه پیاده‌سازی شده‌اند. هر دو در پروژه منبع باز یا کدباز TinyDTLS (یعنی کد و منبعی که قابلیت انجام ویرایش در کد اصلی وجود دارد) پیاده‌سازی شده‌اند.

دلیل اینکه آنها قادر به کار بر روی این وسایل با منابع محدود هستند به این دلیل است که می‌توان آنها را به مدل سبک‌وزن پیاده‌سازی کرد. از پیاده‌سازی‌های رمزگذاری شده کلید پیش فرض شده فقط ۱۸۸۹ بایت رم و ۳۸۲۶۶ فلش ROM استفاده می‌شود که نسبت به اکثر الگوریتم‌های رمزگذاری و امنیت بسیار آگاهانه تر است.[۱۶] این استفادهٔ کم از حافظه به دلیل این مجموعه‌های رمزگذاری شده با استفاده از الگوریتم‌های اثربخش اثبات شده، ایمن است، اما شاید به اندازه الگوریتم‌های مورد نیاز در دستگاه‌ها با منابع بیشتر امن نباشد.

برای مثال: با استفاده از رمزگذاری ۱۲۸ بیتی در مقابل رمزگذاری ۲۵۶ بیتی. علاوه بر این، آنها از کلید مشترک یا کلید عمومی خام که از قبل به اشتراک گذاشته شده استفاده می‌کنند و در مقایسه با استفاده اززیرساخت‌های کلید عمومی (PKIX) به فضای حافظه کمتری و قدرت پردازشی کمی نیاز دارند.[۱۷]

منابع برنامه‌نویسی[ویرایش]

در برنامه‌نویسی، یک مجموعه رمزنگاری به دو صورت فرم جمع و غیر جمع وجود دارد. هرکدام تعاریف متفاوتی دارند:

CipherSuite cipher_suites
لیستی از گزینه‌های رمزنگاری پشتیبانی شده توسط کلاینت.[۱۸] یک مثال از اینکه چگونه مجموعه رمزنگاری معمولاً در طول پروسهٔ شروع برقراری ارتباط استفاده می‌شود:
   struct {
       ProtocolVersion client_version;
       Random random;
       SessionID session_id;
       CipherSuite cipher_suites<2..2^16-2>;
       CompressionMethod compression_methods<1..2^8-1>;
       select (extensions_present) {
           case false:
               struct {};
           case true:
               Extension extensions<0..2^16-1>;
       };
   } ClientHello;
CipherSuite cipher_suite
cipher_suite انتخاب شده توسط سرور از مجموعه رمزنگاری کلاینت.[۱۹] نمونه ای از نحوه استفاده مجموعه رمزنگاری در طی فرایند شروع برقراری ارتباط:
      struct {
          ProtocolVersion server_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suite;
          CompressionMethod compression_method;
          select (extensions_present) {
              case false:
                  struct {};
              case true:
                  Extension extensions<0..2^16-1>;
          };
      } ServerHello;

جستارهای وابسته[ویرایش]

واژگان[ویرایش]

کلید: به اطلاعاتی گفته می‌شود که با استفاده از آن بتوان cipher text (متنی که cipher شده) را به plain text تبدیل کرد. (یا برعکس) به عبارت ساده یک متن رمزگذاری‌شده توسط یک کلید با الگوریتم مناسب، به متن ساده تبدیل می‌شود.

client: کامپیوتری است که از سرور تقاضایی دارد (در لغت به معنی مشتری است).

رمزگشایی: معکوس Encryption است و در Cryptography به رمزگشایی، استخراج و آشکارسازی اطلاعات پنهان شده گفته می‌شود.

پروتکل TLS: یکی از پروتکل‌هایی است که برای ایجاد ارتباط امن در شبکهٔ اینترنت مورد استفاده قرار می‌گیرد.

جستارهای پیوسته[ویرایش]

منابع[ویرایش]

  1. ↑ "Cipher Suites in TLS/SSL (Schannel SSP) (Windows)". docs.microsoft.com (به انگلیسی). Retrieved 2018-07-02.
  2. ↑ "tls and ssl cipher suites | research | sprawl". www.thesprawl.org (به انگلیسی). Archived from the original on 30 January 2019. Retrieved 2017-10-26.
  3. ↑ RFC&nbsp;5246
  4. ↑ TLS Cipher Suite Registry
  5. ↑ "The SSL 0.2 Protocol". www-archive.mozilla.org. Retrieved 2017-12-07.
  6. ↑ "draft-hickman-netscape-ssl-00". tools.ietf.org (به انگلیسی). Retrieved 2017-12-07.
  7. ↑ "SSL 3.0 Specification". www.freesoft.org. Retrieved 2017-12-07.
  8. ↑ Villanueva, John Carl. "An Introduction To Cipher Suites" (به انگلیسی). Retrieved 2017-10-25.
  9. ↑ "TLS 1.3 Protocol Support | wolfSSL Embedded SSL/TLS Library". wolfSSL (به انگلیسی). Retrieved 2017-10-26.
  10. ↑ E. Rescorla (November 4, 2016). "The Transport Layer Security (TLS) Protocol Version 1.3". Retrieved 2016-11-11.
  11. ↑ N., Modadugu; E., Rescorla. "Datagram Transport Layer Security". tools.ietf.org (به انگلیسی). Retrieved 2017-10-25.
  12. ↑ Eric, Rescorla; Nagendra, Modadugu. "Datagram Transport Layer Security Version 1.2". tools.ietf.org (به انگلیسی). Retrieved 2017-10-25.
  13. ↑ Bodo, Moeller; Adam, Langley. "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks". tools.ietf.org (به انگلیسی). Retrieved 2017-10-25.
  14. ↑ Bodo, Moeller; Adam, Langley. "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks". tools.ietf.org (به انگلیسی). Retrieved 2017-10-25.
  15. ↑ Daniel, Bailey; David, McGrew. "AES-CCM Cipher Suites for Transport Layer Security (TLS)". tools.ietf.org (به انگلیسی). Retrieved 2017-10-26.
  16. ↑ Perelmen, Vladislav (June 29, 2012). "Security in IPv6-enabled Wireless Sensor Networks: An Implementation of TLS/DTLS for the Contiki Operating System" (PDF): 38. Archived from the original (PDF) on 29 August 2017. Retrieved 21 May 2020. {{cite journal}}: Cite journal requires |journal= (help)
  17. ↑ Samuel, Weiler; John, Gilmore; Hannes, Tschofenig; Tero, Kivinen; Paul, Wouters. "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". tools.ietf.org (به انگلیسی). Retrieved 2017-12-07.
  18. ↑ RFC&nbsp;5246 , p. 41
  19. ↑ RFC&nbsp;5246 , pp. 42–43, 64
برگرفته از «https://fa.wikipedia.org/w/index.php?title=مجموعه_رمزنگاری&oldid=38253663»