مبادله کلیدی – کاربرد عملی پروتکل اینترکال چیست؟

من اخیرا کپی قدیمی من از رمزنگاری کاربردی را پاک کردم. فصل اول پروتکل اینترفیس را ذکر می کند. از ویکی:

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

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

رمزگذاری – توزیع کلید از یک سرور مرکزی

من یک سیستم متشکل از رایانه های مختلف که باید در یک زمینه زمان واقعی ارتباط برقرار کنند.

تمام ارتباطات باید رمزگذاری شوند و این سیستم به اینترنت متصل نیست، فقط یک دسته از رایانه ها هستند که از طریق سوئیچ های مختلف متصل می شوند.

هر کامپیوتر می تواند اتصالات متفاوتی با دیگر آن ها داشته باشد، که هر دو به عنوان سرور و / یا مشتری عمل می کنند، با استفاده از هر دو UDP و / یا TCP.

آنچه که من می خواهم انجام دهم این است که چیزی را انجام دهیم نه بزرگ و پیچیده برای یک سیستم که باید در اینترنت باقی بماند. ایده من این بود که به نحوی از AES 128 (یا 256) و حالت GCM استفاده کنم.

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

رمز عبور ایجاد شده در سرور مرکزی می تواند به صورت دستی یا به صورت خودکار هر روز تغییر یابد.

شما در مورد این طرح چه فکر میکنید؟ من قصد دارم همه چیز را در C ++ توسعه دهم، هر گونه پیشنهادی در مورد اینکه چه تکنولوژی / کتابخانه باید استفاده کنم؟

من دیده ام سطح پایین سطح libcrypto ++ وجود دارد، اما OpenSSL نیز وجود دارد که قابلیت های TLS و DTLS را فراهم می کند. آیا می توان OpenSSL را برای ایجاد یک سیستم مانند آنچه که من توصیف کرده ام و یا باید از سایر کتابخانه ها مانند libcrypto ++ استفاده کنم؟

پروتکل TLS، کلید جلسه برای اتصال امن

در ویکیپدیا، به عنوان بخشی از برقراری ارتباط بین یک مشتری و یک سرور، یک کلید رمزگذاری عمومی به عنوان بخشی از گواهی دیجیتال ارسال می کند.
سپس مشتری از مبادله کلیدی Diffie-Hellman استفاده می کند تا ایمن کلید نشست تصادفی و منحصر به فرد را برای رمزگذاری و رمزگشایی تولید کند.
سوالات:
1. کلید عمومی فرستاده شده توسط سرور رمزگذاری شده یا روشن است؟ فرض میکنم از آنجا که عمومی است روشن است
2. آیا کلید جلسه و کلید عمومی مرتبط است؟ آیا سرویس گیرنده کلید session را به سرور می فرستد؟
کلید جلسه فرستاده شده: f (Random_gen_number، Public_key) جایی که f یک تابع رمزگذاری است

مدیریت جلسه – این طرح نامیده می شود و چگونه باید دقیقا کار کند؟

بنابراین من درباره ارتباطات سرویس گیرنده سرور و چگونگی حفظ این خصوصی، به ویژه از حملات میان محور، فکر کردم. من با یک طرح که من مطمئن هستم در حال حاضر وجود دارد، اما من می توانم نتایج جستجوی دقیق بتن را پیدا کنید برای کسب اطلاعات بیشتر در مورد آن. [1965،9002] این فکر من آغاز شد که زمانی که یک مشتری به سرور متصل می شود، آنها می خواهم ایجاد یک کانال ارتباطی امن، بنابراین مشتری می تواند یک جفت کلید خصوصی / عمومی تولید کند و کلید عمومی را به سرور ارسال کند. مشکل این است که کلید عمومی را به سرور بطور ایمن (در غیر این صورت یک مرد در وسط می تواند تمام پیام ها را با استفاده از کلید عمومی که از اولین پیام گرفته شده است، رمزگشایی کند، کلید عمومی خود را به پیام متصل کند، از کلید خصوصی مربوط به رمزگشایی استفاده کند پاسخ و پس از ذخیره آن، دوباره رمزگذاری شده با کلید عمومی واقعی مشتری).

بنابراین من یک راه حل ممکن را تصور کردم: مشتری ابتدا کلید عمومی را از سرور دریافت می کند، آن را برای رمزگذاری کلید عمومی خود استفاده می کند. MitM می تواند تمام پیام ها را تحت تأثیر قرار دهد، اما قادر به رمزگشایی هر یک از آنها نیست – فقط سرور واقعی می تواند درخواست مشتری را رمزگشایی کند و پاسخ تنها توسط مشتری واقعی رمزگشایی می شود. هنگامی که سرور کلید عمومی مشتری را می داند، آن را ایمن آن را ذخیره می کند و از آن برای رمزگذاری هر گونه ارتباط بیشتر استفاده می کند.

من چند سوال مرتبط دارم.

  1. این نوع امنیت / دستخط چیست؟
  2. I کلمه nonce را نادیده گرفته است اما درست است که این در مورد جلوگیری از حملات پخش و نه مشکل MitM من در حال تلاش برای حل کردن
  3. کلید اولیه که سرور به مشتری می فرستد، باید ثابت می شود و احتمالا در جایی منتشر می شود، بنابراین مشتریان می توانند "مراحل عمومی کلید من را در جلسات بعدی به من برگردانند؟" یا باید یک کلید تازه تولید شده برای هر مشتری در هر درخواست جلسه جدید باشد؟
  4. در عوض، آیا کلید عمومی مشتری باید با هر جلسه تغییر کند یا مشتری بتواند همان کلید را دوباره استفاده کند، پس از آنکه به طور امن به سرور منتقل شد؟ 19659006] خطراتی برای این مسئله وجود دارد، به غیر از نقص آشکار یکی از طرفین درگیر برای حفظ خصوصی private private؟

من مطمئن هستم که این نسبتا رایج است و احتمالا در حال حاضر چگونه بسیاری از مدارک احراز هویت کار می کنند، از پاسخ دادن به تمام این سؤالات به طور جداگانه، اگر کسی بتواند اصطلاحات مناسب را به من ارائه دهد، من خوشحال خواهم شد (من برخی از ترکیب کلمات کلیدی مانند «سرویس گیرنده / سرور»، «رمزنگاری نامتقارن»، «ایجاد جلسه» را امتحان کردم؛ هر چیزی مفید پیدا کنید) و حتی اگر این یک SE نظری باشد، حدس می زنم که مانند همه ی امنیتی خوب نباید اجرای خود را رول کند، بنابراین هر نمونه از یک برنامه مناسب برای سرویس دهنده / سرور (به عنوان مثال در PHP) با استفاده از کتابخانه های معتبر می تواند خوشایند باشد.

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

چه عواملی برای تبادل کلیدهای عمومی با شخص دیگری برای ارسال ایمیل وجود دارد، به غیر از روش آشکار دستی چسباندن کلید عمومی به ایمیل که می گوید: "در اینجا کلید عمومی من است"؟

  1. آیا مشتریان ایمیل که معمولا رمزگذاری را پشتیبانی می کنند کلید های کلیدی را از سرورهای کلید به طور خودکار (بر اساس آدرس ایمیل شخص دیگری) انتخاب کنید، بنابراین شما حتی نباید در مورد آن فکر کنید؟
  2. اگر کسی از سرورهای کلید استفاده نمی کند، مشتریان ایمیل دارای یک روش ساخته شده در تبادل کلید عمومی بدون دخالت انسان، به جز احتمالا با کلیک بر روی "OK" برای پذیرش مبادله؟