مرجع صدور گواهی دیجیتال

در رمزنگاری یک مرجع صدور گواهی دیجیتال (certificate authority) یا (certification authority) یا ( CA) یک شخص حقیقی یا حقوقی است که گواهی‌های دیجیتال (گواهی‌های کلید عمومی) را صادر می‌کند. گواهی دیجیتال تضمین می‌کند که موضوع گواهی مورد نظر ما به اسم همان صاحبی است که در آن گفته شده‌است. این گواهی به دیگران (کسانی که بر اساس این گواهی کار خود را انجام می‌دهند) اجازه می‌دهد که به امضاءها و بیانیه‌هایی که بر اساس کلید خصوصی گواهی یاد شده تولید شده‌اند اطمینان کنند. در این مدلِ ارتباط با اعتماد، یک مرجع صدور گواهی دیجیتال (CA) شخص ثالث مورد اطمینانی است که از سوی هر دو سمت گواهی (موضوع یا همان صاحب گواهی و شخص اعتمادکننده به گواهی) معتمد به حساب می‌آید. گواهی‌ها مشخصه‌هایی از طرح‌های گواهی دیجیتال (PKI) هستند.

مراجع صدور گواهی دیجیتال تجاری به منظور حمایت بیشتر مرورگرهای تارنما (Web) از آن‌ها و بکارگیری اعتماد خودکار در مروزگرها (Mozilla از فهرستی شامل حداقل ۳۶ صادرکننده گواهی دیجیتال پشتیبانی می‌کند).[1] به تعداد مروزگرهای تارنما و ادوات دیگری که به یک صادرکننده گواهی دیجیتال اعتماد دارند همه‌گیری (ubiquity) می‌گویند.

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

صدور یک گواهی دیجیتال

یک مرجع صدور گواهی دیجیتال، گواهی‌های دیجیتال دیجیتالی صادر می‌کند که شامل یک کلید عمومی و هویت صاحب آن است. کلید خصوصی متناظر به این سادگی در اختیار همه گذاشته نمی‌شود، و توسط کاربرِ مقابل که کلید برای آن تولید شده‌است مخفی می‌ماند. گواهی نیز به نوبه خود، تأیید یا اعتباری است از سوی مرجع صدور گواهی دیجیتال، به طوری که بیان می‌دارد کلید عمومی ذکر شده در گواهی متعلق به شخص، ارگان، سرویس‌دهنده یا هویتی که در گواهی به آن اشاره شده‌است. تعهد یک مرجع صدور گواهی دیجیتال برای طرح بیان شده در بالا، تضمین و مهر تأئیدی است برای استفاده‌کننده‌کنندگان از گواهی، به طوری که کاربران و شخصیت‌هایی که بر اساس گواهی کار می‌کنند بتوانند به اطلاعات منتقل شده بر اساس گواهی مذکور اعتماد کنند. مراجع صدور گواهی دیجیتال از استانداردها و آزمون‌های بسیاری برای منظور فوق استفاده می‌کنند. اصولاً مرجع صدور گواهی دیجیتال مسئول جمله زیر است: «بله، این شخص همان کسی است که ادعا می‌کند، و ما، مرجع صدور گواهی دیجیتال آن را تأیید می‌کنیم».

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

مثال

رمزگزاری با کلید عمومی را می‌توان برای رمز کردن ارتباط بین دو قسمت مورد استفاده قرار داد. این رخداد معمولاً زمانی که یک کاربر در یک سایت وارد می‌شود که قرارداد http امن را اجرا می‌کند. در این مثال فرض می‌کنیم که کاربر در صفحه خانگی بانک خود با آدرس www.bank.example وارد می‌شود تا خدمات بانکی برخط انجام دهد. وقتی که کاربر صفحه خانگی www.bank.example را باز می‌کند، یک کلید عمومی را همراه با تمام اطلاعاتی که صفحه مرورگر تارنما نمایش می‌دهد دریافت می‌کند. زمانی که کاربر اطلاعاتی را در صفحه بانک وارد و تأیید می‌کند (یعنی اطلاعاتی را به بانک برمی‌گرداند)، اطلاعات پیش از فرستاده شدن، به وسیلهٔ مرورگر تارنما و با استفاده از کلید عمومی که توسط www.bank.example ارائه شده، رمزی می‌شوند. به کلیدی که به وسیلهٔ آن اطلاعات را می‌توان از حالت رمزی خارج کرد، کلید خصوصی می‌گویند و تنها برای بانک شناخته شده‌است. در نتیجه حتی اگر کسی بتواند به داده‌هایی که رد و بدل شده‌اند دسترسی پیدا کند، تنها توسط بانک و با استفاده از کلید خصوصی قابل رمزگشایی هستند.

این مکانیزم تنها زمانی قابل اعتماد است که کاربر مطمئن باشد کسی که با او در ارتباط است بانک است. اگر کاربر آدرس www.bank.example را وارد کند ولی ارتباطش با بانک ربوده شده[2] و یک تارنمای تقلبی[3] (که سعی می‌کند خود را بانک نشان دهد) اطلاعات صفحه بانک را به مرورگر کاربر بفرستد، همزمان با صفحه تقلبی یک کلید عمومی تقلبی نیز به کاربر می‌فرستد. کاربر فرم را با اطلاعات شخصی‌اش پر می‌کند و با تأیید آن، داده‌ها با کلید عمومی تقلبی رمزی می‌شوند. صفحه تقلبی به اطلاعات کاربر دست پیدا می‌کند زیرا صفحه تقلبی دارای کلید خصوصی تقلبی متناظر با کلید عمومی است.

مرجع صدور گواهی دیجیتال یک سازمان است که کلیدهای عمومی، صاحب آن‌ها و هر طرفی که در ارتباط با اعتماد با این سازمان است را نگهداری می‌کند. زمانی که مرورگر تارنمای کاربر، کلید عمومی را از تارنمای www.bank.example دریافت می‌کند، می‌تواند با مرجع صدور گواهی دیجیتال تماس بگیرد تا مطمئن شود که آیا حقیقتاً کلید عمومی متعلق به www.bank.example است یا خیر. از آن‌جا که www.bank.example از یک کلید عمومی که مرجع صدور گواهی دیجیتال آن را تأیید کرده‌استفاده می‌کند، یک www.bank.example تقلبی تنها می‌تواند از همان کلید عمومی اصلی استفاده کند، و از آنجا که www.bank.example تقلبی کلید خصوصی متناظر را در اختیار ندارد، داده‌های کاربر را نمی‌تواند رمزگشایی کند.

سرنگونی مرجع صدور گواهی دیجیتال

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

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

یک مورد از این دست در سال ۲۰۰۱ اتفاق افتاد. زمانی که مرجع صادرکننده گواهی دیجیتال VeriSign دو گواهی برای کسی که ادعا می‌کرد microsoft است صادر کرد. این گواهی‌ها دارای نام "Microsoft Corporation" بودند، لذا می‌توانست برای فریب یک فرد استفاده شود و او را ترغیب کند که از نرم‌افزار به روزکننده شرکت Microsoft استفاده کند در صورتی که واقعاً این‌طور نبوده. این کلاه‌برداری در اوایل سال ۲۰۰۱ کشف شد. Microsoft و VeriSign اقداماتی را جهت محدود کردن مشکلات ناشی از این مسئله انجام دادند.[4][5]

امنیت

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

In some enterprise systems, local forms of authentication such as Kerberos can be used to obtain a certificate which can in turn be used by external relying parties. Notaries are required in some cases to personally know the party whose signature is being notarized; this is a higher standard than is reached by many CAs. According to the American Bar Association outline on Online Transaction Management the primary points of US Federal and State statutes enacted regarding امضای دیجیتالs has been to "prevent conflicting and overly burdensome local regulation and to establish that electronic writings satisfy the traditional requirements associated with paper documents." Further the US E-Sign statute and the suggested UETA code help ensure that:

برخی از نمونه‌های متن باز به شرح زیر است:

• EJBCA
• OpenCA
• OpenSSL, which is really an SSL/TLS library, but comes with tools allowing its use as a simple certificate authority.
• gnoMint
• DogTag
• XCA

بازدیدهای بیشتر

• Certificate revocation list
• Certificate server
• Robot certificate authority
• Intermediate certificate authorities
• Web of trust
• X.۵۰۹
• Server gated cryptography
• servers
• Extended Validation Certificate
• CAcert
• SAFE-BioPharma Association
• Root Key Ceremony

پی نویس

1. http://www.mozilla.org/projects/security/certs/included/, List of Trusted Root Certificate Authorities, ۲/۱۰/۲۰۱۰.
2. Hi-jacked
3. Fake
4. Verisign, Inc. (31 January 2001). "Jan 2001 - Advisory from VeriSign, Inc". Archived from the original on 24 November 2010. Retrieved 2008-12-02.
5. Microsoft, Inc. (22 March 2001). "Microsoft Security Bulletin MS01-017". Retrieved 2008-12-02.