گواهی دیجیتال - ویکی‌پدیا، دانشنامهٔ آزاد

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

پیشنهاد شده است که گواهی کلید عمومی در این مقاله ادغام شود. (بحث)

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

نوعاً در یک طرح زیرساخت کلید عمومی (به انگلیسی: Public Key Infrastructure یا PKI)، امضا از طرف مرجع صدور گواهی دیجیتال (به انگلیسی: Certificate authority یا CA) است. در یک طرح شبکه اعتماد، امضا یا از طرف خود کاربر یا کاربران است. در هر صورت، امضاها در یک گواهی از طرف یک امضاکننده رسمی است و مصداق این است که مشخصات هویت و کلید عمومی مربوط به هم می‌باشند.

• گواهی‌های کلید عمومی X.۵۰۹
• گواهی‌های زیرساخت کلید عمومی ساده SPKI یا (Simple Public Key Infrastructure)
• گواهی‌های کلید عمومی مخفی کردن نسبتا خوب PGP یا (Pretty Good Privacy)
• گواهی اختیاری (Attribute Certificate)

این گواهی‌ها فرمتهای متفاوتی دارند. در برخی موارد، ممکن است یک نوع گواهی نسخه‌های گوناگونی داشته باشد، و از یک نسخه واحد به روش‌های گوناگونی نمونه تهیه شود. برای مثال ۳ نسخه از گواهی کلید عمومی X.۵۰۹ موجود است. نسخه ۱ زیرمجموعه نسخه ۲ و نسخه ۲ زیرمجموعه نسخه ۳ می‌باشد. زیرا یک کلید عمومی نسخه ۳ شامل ضمائم متعدد انتخابی است که بنا به کاربرد می‌تواند در نمونه‌های مختلفی تهیه شود. برای مثال، گواهی‌های انتقال الکترونیکی امن (SET)، همان گواهی‌های کلید عمومی نسخه ۳ از X.۵۰۹ هستند که ضمائم آن منحصرا برای تبادلات SET تعریف شده‌اند. در اینجا منظور از گواهی همان گواهی کلید عمومی نسخه ۳ از X.۵۰۹ است. حال به ساختار و محتوای این گواهی می پردازیم.^[۱]

• گواهی کلاس۱: مخصوص امضا الکترونیکی و رمزنگاری پست الکترونیک
• گواهی کلاس۲: مخصوص امضا الکترونیکی و رمزنگاری فایل‌های الکترونیکی ونرم‌افزارها
• گواهی کلاس۳: مخصوص تولید گواهی برای مراجع گواهی دیگر
• گواهی کلاس SSL: مخصوص تأمین امنیت سرورهای سازمان‌ها و مراکزی که وب‌گاه دارند یا خدمات تحت وب ارائه می نمایند. این گواهی در سه شکل مخصوص سرور و مخصوص کاربر و هردو صادر می‌گردد.

در ژانویه ۱۹۹۹ IETF استانداردی تحت عنوان RFC۲۴۵۹ برای کلید عمومی X.۵۰۹ (PKIX) ارائه نموده‌است. در سال ۲۰۰۲ استاندارد RFC۳۲۸۰ جایگزین استاندارد قبلی شد. اگرچه RFC۳۲۸۰ به منظور کاربردهای اینترنتی تدوین شده بود، اما تعدادی از توصیه‌های آن می‌توانند در محیط سازمان و به طبع هر جای دیگر به کار برده شوند. شکل زیر ساختار کلی یک گواهی X.۵۰۹ نسخه ۳ را نشان می‌دهد. فیلدهای موجود در گواهی در زیر آمده‌است.

^[۲]

• نسخه (Version): نشاندهنده نسخه گواهی است (۱، ۲ یا ۳)
• شماره سریال (Serial Number): شناسه‌ای یکتاست که هویت صادرکننده را تعیین می‌کند.
• الگوریتم امضا (Signature): نوع الگوریتمی که با آن گواهی تولید و صادر شده‌است. امضا نماینگر شناسه الگوریتمی است (که شامل شناسه عنصر یا OID، و پارامترهای مربوط به آن می‌باشد) که برای محاسبه امضای دیجیتالی روی گواهی به کار برده می‌شود.

OID، نمایشی منحصر به فرد از یک عنصر است. OID، دنباله‌ای از ارقام است که با ممیز اعشاری یا نقطه از هم جدا شده اند (مثل یک آدرس اینترنتی IP که در آن ارقام با نقطه از هم جدا شده اند). OID‌ها به‌طور طبیعی سلسله مراتبی هستند و در RA‌های بین‌المللی، ملی، یا سازمانی ثبت شده اند تا اطمینان حاصل شود که یک OID منحصر به فرد به هر عنصر نسبت داده شده‌است. برای متال OID برای SHA-۱ با RSA به این صورت می‌باشد: ۱٫۲.۸۴۰٫۱۱۳۵۴۹٫۱.۱٫۵.

• صادرکننده (Issuer): نام متمایز (DN) یک مرجع صدور گواهی است که همیشه باید درج شده باشد.

DN یک نام‌گذاری سلسله مراتبی قراردادی است که در توصیه‌های X.۵۰۰ درج شده‌است. DN‌ها برای این طراحی شده اند تا مطمئن شویم که نامهای موجودیت‌ها یکتاست. DN‌ها تسلسلی از نام‌های متمایز وابسته (RDN) هستند که از نودِ سطح بالا یا ریشه تا آخرین نود نام گذازی شده‌اند. برای مثال "C=CA, O=ADGA OU=AEPOS Technologies, CN=Steve Lloyd " نمونه‌ای از یک DN است. دقت داشته باشید که هر RDN (C=CA یک RDN است، O=ADGA یک RDN است و...) باید در هر سطح منحصر به فرد باشد، در غیر اینصورت تضمینی برای یکتا بودن DN نخواهد بود.

• اعتبار (Validity): بازه زمانی که در آن مدت گواهی معتبر بوده و پس از آن باید باطل گردد. شامل تاریخ شروع و خاتمه اعتبار است.
• موضوع (Subject): DNِ دارنده گواهی است که نباید خالی باشد. مگر اینکه از فرمِ نام دیگر استفاده شود. (به فیلد ضمائم مراجعه کنید)
• اطلاعات کلید عمومی دارنده گواهی (Subject Public Key Info): کلید عمومی (و الگوریتم معین‌کننده) مربوط به موضوع که باید همیشه درج شده باشد.
• ID یکتای صادرکننده گواهی (Issuer Unique ID): یک شناسه اختیاری یکتا برای صادرکننده گواهی است که تنها در نسخه‌های ۲ و ۳ می‌آید. این فیلد به ندرت در عمل استفاده می‌شود و در RFC۳۲۸۰ نیز به آن توصیه نشده است.
• ID یکتای موضوع (Subject Unique ID): یک شناسه اختیاری یکتا برای دارنده گواهی است که تنها در نسخه‌های ۲ و ۳ می‌آید. این فیلد به ندرت در عمل استفاده می‌شود و در RFC۳۲۸۰ نیز به آن توصیه نشده است.

یک نشانه اهمیت به هر ضمیمه گواهی نسبت داده شده‌است. در حالت کلی ضمائم می‌توانند مهم یا بی اهمیت باشند. ضمیمه‌ای که نشان با اهمیت دارد باید به کاربرده شود، در غیر اینصورت نباید از گواهی استفاده شود. اگر یک ضمیمه بی اهمیت شناخته شده باشد، می‌توان آن را در نظر نگرفت یا در صورت امکان آن را به کار نگرفت.^[۱]

همانطور که قبلاً گفته شد، علاوه بر نسخه ۳ گواهی X.۵۰۹ انواع دیگر گواهی نیز وجود دارند. در زیر مختصری توضیح برای آن‌ها آورده شده‌است.

در مقابلِ IETF PKIX Working Group که بر موارد استفاده X.۵۰۹ در اینترنت تمرکز دارد، گروه کاری IETF دیگری با عنوان SPKI تشکیل گردید که بر زیرساخت ساده‌تری از کلید عمومی برای کاربرد اینترنت تمرکز داشت. پروانه IETF SPKI Working Grou در زیر آمده‌است: ساخت استاندارد اینترنتی برای ساختار گواهی کلید عمومی IETF، امضای مربوط به آن، ساختارهای دیگر آن، و پروتکل‌های دریافت کلید. ساختار گواهی کلید و پروتکل‌های مربوطه باید برای فهم، پیاده‌سازی و استفاده، آسان باشند. IETF SPKI Working Group تعدادی مستند فنی و اطلاعاتی تهیه کرده‌است:

• SPKI certificate format
• SPKI certificate theory
• SPKI requirements
• SPKI examples

که در آدرسِ https://web.archive.org/web/20080324204135/http://www.ietf.org/html.charters/REMOVED/spki-charter.html موجود می‌باشند. از آنجا که تاکیید SPKI بیشتر بر اجازه است تا هویت، به آن گواهی اجازه نیز گفته می‌شود. هدف اصلی گواهی اجازه SPKI، تعیین دسترسی‌ها است. همچنین تواناییِ محول کردن دسترسی را نیز دارد. اگرچه گواهی اجازه SPKI اشتراک‌هایی با گواهی کلید عمومی X.۵۰۹ دارد (مثل صادرکننده و اعتبار)، اما syntax و معنای این فیلدها در بسیاری از موارد یکی نمی‌باشد. در حال حاضر تقاضای کمی برای این گواهی‌ها وجود دارد، و مشتریان CA و PKI تمایلی به پیاده‌سازی گواهی دیگری با syntax‌های متفاوت از گواهی‌های نسخه ۳ ازX.۵۰۹ ندارند.

PGP روشی برای امضا و رمزگذاری دیجیتالی فایلها و ایمیل‌ها می‌باشد. آخرین نسخه آن که OpenPGP خوانده می‌شود، یک استاندارد IETF به نام OpenPGP Message Format [RFC۲۴۴۰] است. PGP ساختار پکت‌هایی که پیام‌ها و فایلها را از جانب یک موجودیت برای موجودیت دیگر حمل می‌کنند مشخص می‌کند. همچنین PGP ساختار پکت‌هایی که کلیدهای PGP (گواهی‌های PGP) را بین موجودیت‌ها حمل می‌کنند را نیز مشخص می‌کند. اگرچه PGP کاربرد زیادی در سطح اینترنت دارد، اما گزینه مناسبی برای استفاده در سطح اینترانت سازمانی نیست. چونکه تصمیماتِ اعتماد به جای سازمان به افراد واگذار می‌شود. از آنجا که اکثر مشتریان CA و PKI تمرکز بر قلمرو سازمانی دارند، تمایلی بر خریدِ محصولاتِ OpenPGP ندارند.

مشخصه‌های معاملات الکترونیکی امن SET، [SET۱; SET۲; SET۳] استانداردی برای پشتیبانی از پرداخت‌های کارت‌های اعتباری در سطح شبکه‌های توزیعی مانند اینترنت را تعریف می‌کنند. SET پروتکل استاندارد پرداخت را تعریف می‌کند. SET از ساختار نسخه ۳ از گواهی X.۵۰۹ پیروی می‌کند و ضمیمه‌های خصوصی به آن می افزاید که تنها در زمینه SET معنا دارند. شکل زیر یک گواهی SET را نشان می‌دهد. البته تمام ضمائم در ان آوده نشده‌اند. مثلاً ضمیمه Hashed Root Key که در یک گواهی SET root CA می‌آید را نشان نمی‌دهد^[۱]

نسخه ۲۰۰۰ از X.۵۰۹ مفهوم و کاربرد گواهی‌های اختیاری را به تفصیل شرح داده و حتی چارچوبی برای اساسِ ایجادِ زیرساخت‌های مدیریت ویژه PMIs ارائه می‌دهد. موضوع PMI بسیار گسترده است و می‌تواند عنوان یک کتاب باشد. در اینجا تنها کافی است بدانید که اگرچه گواهی هایاختیاری در توصیه‌های X.۵۰۹ تعریف شده اند، ولی گواهی‌های اختیاری گواهی‌های کلید عمومی نیستند. گواهی‌های اختیاری برای حمل ویژگی‌های یک موضوع طراحی شده اند تا مدیریت ویژه انعطاف پذیر و مقیاس پذیر را سهولت بخشند. گواهی اختیاری ممکن است برای تصدیق هویت دارنده گواهی اختیاری به یک گواهی کلید عمومی اشاره داشته باشد.^[۱]

علاوه بر ذخیره گواهی ها، ابزارهای Administrator خدمات صدور، ابطال و انتشار CRL (Certificate Revocation List) و وارد و صادر کردن گواهی‌ها را ارائه می‌دهد. Administrator می‌تواند از این ابزارها برای مدیریت گواهی‌های خودشان و کاربران دیگر، یک کامپیوتر یا یک service دیگر استفاده کند.

وظایف مربوط به صدور گواهی:

• پذیرفتن یک درخواست گواهی
• صادر کردن یک درخواست گواهی

هنگامی که کاربر درخواست برای گواهی را در یک stand-alone CA ثبت می‌کند، درخواستِ او در وضعیتِ pending قرار می‌گیرد تا زمانی‌که CA Administrator آن درخواست را قبول یا رد کند. کاربر همچنین به صفحات وب که خدمات گواهی را ارائه می‌کنند، دسترسی داشته و از وضعیت گواهی‌های خود مطلع می‌شود. این رویه تنها برای یک stand-alone CA به کار برده می‌شود. که در آن تنظیم شده هر درخواست جدید گواهی را در وضعیتِ pending قرار دهد.

برای حفظ تمامیتِ (integrity) PKI در یک سازمان ممکن است لازم شود که CA administrator گواهی‌ها را قبل از تاریخ انقضاءشان باطل کند. برای مثال، اگر شخصی که برای او گواهی صادر شده سازمان را ترک کند، باید گواهی او باطل گردد. یا اینکه کلید خصوصیِ یک گواهی کشف شود، یا یک حادثه امنیتی بر اعتبار یک گواهی تأثیر بگذارد. Administrator گواهی‌ها را در CA باطل می‌کند. پس از اینکه یک گواهی باطل شد، به پوشه گواهی‌های باطل شده منتقل می‌شود. و گواهی‌های باطل شده در نوبت بعدیِ انتشار CRL در لیست قرار می‌گیرد.

یک CA به‌طور خودکار CRL را در فواصل زمانی که administrator تعریف کرده، به روز رسانی و انتشار می‌کند. می‌توان بنا به درخواست نیز CRL را با استفاده از CRL publishing wizard انتشار کرد. Clientهایی (سرویس گیرنده ای) که یک کپی از CRL انتشار شده قبلی را در حافظه خود دارند، تا زمانی که نوبت بعدی به روز رسانی نرسیده آن را به کار می‌گیرند. اگرچه در این فاصله بنا به درخواست CRL جدیدی منتشر شده باشد.

وظایف مربوطه:

• بررسی ساختار فایل گواهی (Examining Certificate File Formats)
• وارد کردن گواهی
• صادر کردن گواهی

Snap-in گواهی ابزارهایی در اختیار administrator می گذارد تا بتوان گواهی‌ها را به همراه مسیرهای گواهی و کلیدهای خصوصی وارد یا خارج کند. می‌توان گواهی را از یک کاربر دیگر، کامپیوتر، یا CA دیگر وارد کرد. یا می‌توان گواهی را برای استفاده در کامپیوتر دیگر صادر نمود. گواهی‌ها را می‌توان با ساختار فایلهای استاندارد گوناگون دیگر وارد یا صادر کرد.

ممکن است لازم باشد سازمان صحت کاربران خارجی که در Active Directory حساب ندارند را، تصدیق کند. وظایفی که مربوط به تنظیماتِ Active Directory برای گواهی‌ها می‌باشد:

• کاربران خارجی باید یک گواهی داشته باشند
• کاربران خارجی باید یک حساب کاربری (user account) داشته باشند
• گواهی‌های کاربران خارجی باید توسط یک CA مورد اعتماد (trusted CA) صادر شوند
• باید بین گواهی کاربر خارجی و حساب Active Directory نگاشت نامها (Name Mapping) وجود داشته باشد.^[۳]