رمزنگاری کلید عمومی: تفاوت میان نسخه‌ها

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

زوج کلیدهای مختلف می‌توانند کاربردهای متفاوت داشته باشند. خصوصاً اینکه یک زوج کلید در الگوریتم [[امضای دیجیتال]]ی (DSA) زمانیکهزمانی‌که بر طبق خصوصیاتی پیاده‌سازی شده‌است، نمی‌تواند برای رمزگذاری یا رمزگشایی بکار رود. بطور مشابه زوج کلید DH نمی‌تواند برای امضا نمودن داده‌ها و راست‌آزمایی امضا بکار رود. بعلاوهبه‌علاوه حتی یک زوج کلید بر اساس الگوریتم RSA _ که بصورتبه صورت ریاضی برای تصدیق، یکپارچگی، محرمانگی یا معاوضه کلید بکار می‌رود_ ممکن است به وسیلة سیاستها، احکام، یا انتخاب پیاده‌سازی برای استفادة تک منظوره محدود شود.

پیامد کشف رمز کلید یک موجودیت نهایی، بستگی به نوع کلید دارد. اگر کلید امضا کنندهامضاکننده کشف رمز شده باشد، دارندة این کلید باید گواهی مورد نظر را باطل کند و همین کار از دسترسی بیشتر افراد غیرمجاز جلوگیری خواهد کرد. اما اگر کلید کشف رمز شده، کلید خصوصی و برای از رمز درآوردن اسناد باشد، بعلاوة نکتة بالا، باید تمام اسنادی که با این کلید از رمز خارج می‌شدند و کلیدهایی که این اسناد را به رمز درآورده‌اند، شناسایی شوند.

;آگاه ساختن طرف اعتماد کنندهاعتمادکننده

در صورتی که کلید CA کشف رمز شود، به دلیل تعدد افراد، وی نمی‌تواند به طرفهای اعتماد کنندهاعتمادکننده اطلاع دهد که این مسئله اتفاق افتاده‌است و هیچ راه قابل اعتمادی برای این شکل از [[اطلاع‌رسانی]] وجود ندارد.

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

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

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

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

بعلاوه، گواهی‌های جداگانة در ارتباط با زوج کلیدهای جداگانه، از نظر ساخت مستقلند: آنهاآن‌ها از نظر دورة اعتبار، سیاستها، کاربرد و رویه‌های مدیریتی مستقلند؛ بنابراین ابطال یکی از آنهاآن‌ها بر بقیه تأثیرگذار نیست. داشتن یک کلید عمومی در چند گواهی، مدیریت آن را پیچیده می‌کند.

برای پشتیبانی از عدم انکار، شرط لازم آن است که کلید خصوصی همراه با فعالیت [[عدم انکار]] مورد نظر (مانند امضای یک رسید برای اثبات انتقال آن) نباید برای بخشهایبخش‌های دیگر شناخته شده باشد. در غیر اینصورت، موجودیت مزبور به سادگی می‌تواند اعلام کند که بخش دیگری عدم انکار نموده‌است؛ بنابراین [[سرویس عدم انکار]] به مانع برخورد می‌کند.

[[کلید خصوصی]] مربوط به گواهی که هدفش پشتیبانی از عدم انکار است، نباید در معرض دید موجودیت‌های دیگر قرار گیرد. در بعضی محیطها، لازم است که چنین کلیدهایی تولید شوند تا از کلیدهایی که درگیر با فعالیتهایفعالیت‌های عدم انکار نیستند، توسط یک موجودیت مورد اعتماد نسخة پشتیبان تهیه شود یا این کلیدها در نرم‌افزار ذخیره گردند.<ref>Understanding PKI: Concepts, Standards, and Deployment Considerations, Second Edition, Addison Wesley.</ref>