توسعه چندمنظوره پست الکترونیک اینترنت/امن

S/MIME (توسعه چند منظوره پست الکترونیک اینترنت/امن) استانداردی برای رمزنگاری با کلید عمومی و امضایی از دادهٔ MIME است. S/MIME یکی از استانداردهای IETF است که در تعدادی از اسناد از جمله RFCها تعریف شده‌است. S/MIME را در اصل شرکت امنیت داده RSA توسعه داده‌است.[1] مشخصات اصلی که به تازگی استفاده می‌شود توسعه یافته مشخصات MIME با استاندارد غیررسمی صنعت PKCS#7 فرمت پیام امن است. کنترل تغییر به S/MIME از آن زمان به نیروی ضربت مهندسی اینترنت محول گردیده و مشخصات در حال حاضر در سینتکس پیام رمز شده گنجانده شده‌است. یک مشخصه IETF در بسیاری از جهات با PKCS #7 یکسان است. عملکرد S/MIME در اکثر نرم‌افزارهای پست الکترونیکی مدرن قرار گرفته و با آن‌ها نیز کار می‌کند.

عملکرد

S/MIME، خدمات امنیتی رمزنگاری زیر را برای برنامه‌های پیام الکترونیکی فراهم می‌کند: احراز هویت، یکپارچگی پیام، عدم انکار مبدأ (با استفاده از امضاهای دیجیتال) و حفظ حریم خصوصی و امنیت داده (با استفاده از رمزنگاری). S/MIME نوع MIME را مشخص می‌کند application/pkcs7-mime[2](نوع smim "داده دربرگرفته شده"). S/MIME در جایی که تمام موجودیت MIME ی (که از قبل آماده شده) که باید پنها ن شود را رمز نموده و در شی ای که متعاقباً در موجودیت application/pkcs7-mime MIME وارد می‌شود بسته‌بندی می‌کند.

گواهی نامه S/MIME

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

یک نمونه اولیه("کلاس ۱") گواهی شخصی، هویت مالکش را تأیید می‌کند تنها تا آنجا که فرستنده را به عنوان مالک "From:" در آدرس پست الکترونیکی اعلام می‌دارد به این معنی که فرستنده می‌تواند امیل‌های فرستاده شده به آن آدرس را دریافت نماید و بنابراین تنها ثابت می‌شود که یک امیل دریافت شده واقعاً از "From:" آدرس داده شده آمده‌است و آن نام شخص و نام شرکت را تأیید نمی‌کند. اگر یک فرستنده بخواهد به گیرنده امیل اجازه بدهد که هویت فرستنده را تأیید کند این به این معنا می‌باشد که نام گواهی دریافت شده نام فرستنده یا نام سازمان را در بر می‌گیرد. فرستنده نیاز دارد که گواهی ("کلاس ۲") را از مرکز صدور گواهی(CA)که فرایند تأیید هویت را با عمق بیشتری انجام می‌دهد تهیه نماید، و این شامل سوالاتی دربارهٔ دارنده گواهی نامه می‌شود. برای جزئیات بیشتر در مورد تأیید هویت، امضای دیجیتال را مشاهده کنید.

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

موانع گسترش S/MIMEدر عمل
  • همه نرم‌افزارهای پست الکترونیکی با امضاهای S/MIME کار نمی‌کنند در نتیجه پیوستی که smimee.p7s نام دارد ممکن است برخی از مردم را گیج کند.

S/MIME

  • در بعضی از مواقع برای استفاده توسط مشتریان webmailها مناسب در نظر گرفته نمی‌شود. اگر چه پشتیبان می‌تواند از مرورگر مورد نفوذ واقع شود، برخی از تدابیر امنیتی به این نیاز دارند که کلید خصوصی برای کاربر نگهداری شود اما از طریق سرور webmail قابل دسترسی نباشد و این برتری کلید webmail که از همه جا قابل دسترسی می‌باشد را پیچیده می‌کند. این مسئله به‌طور کاملاً مشخص مختص به S/MIME نیست. دیگر روش‌های امن امضای دیجیتال webmail نیز ممکن است نیاز به یک مرورگر برای اجرای کد داشته باشند تا امضا را تولید کنند. استثناهایی مثل PGP Desktop و نسخه‌هایی از GnuPG وجود دارند، که داده از webmail با شتاب خارج می‌شود و این توسط یک امیل امضا می‌شود و برگشت دادهٔ امضا شده را به صفحه webmail قرار می‌دهد. ملاحظه از این منظر امنیتی حتی راه حل امن تری می‌باشد.
    • برخی از سازمان‌ها آن را برای سرورهای webmail که از دیگران «مخفی» باشد قابل قبول در نظر می‌گیرند و بعضی نه. برخی از ملاحظات در مورد نرم‌افزارهای مخرب در زیر ذکر شده‌است. یکی دیگر از استدلالاتی که می‌توان به آن اشاره کرد این می‌باشد که سرورها اغلب داده ایی را که به هر حال برای سازمان محرمانه است در بر می‌گیرند، پس اگر داده اضافه از جمله کلیدهای خصوصی مورد استفاده برای رمزنگاری، در این سرورها ذخیره شده و استفاده شوند چه تفاوتی حاصل می‌شود؟
    • بسیاری بین کلید خصوصی استفاده شده برای رمزنگاری و آن‌هایی که برای امضای دیجیتال استفاده می‌شود تمایز قائل می‌شوند و آن‌ها اشتراک‌گذاری اولی را نسبت به بعدی با احتمال بیشتری قبول می‌کنند. این مسئله به خصوص زمانی درست است که جنبه عدم انکار امضاهای دیجیتال یک نگرانی باشد (این ممکن است نباشد). اجماع جهانی بی‌طرفانه‌ای وجود دارد که عدم انکار را مستلزم یک کلید خصوصی می‌داند که در تمام طول چرخه حیات آن تنها تحت کنترل مالکش باشد؛ بنابراین رمزنگاری انجام شده با سرورهای webmail احتمال بیشتری دارد که از امضاهای دیجیتال قابل قبول تر بشود.
  • S/MIME برای امنیت انتها به انتها طراحی شده‌است. رمزنگاری نه تنها پیام را رمز می‌کند بلکه نرم‌افزارهای مخرب را نیز رمز می‌کند؛ بنابراین اگر امیلی برای نرم‌افزارهای مخرب در هر جایی اسکن شده باشد اما در نقاط انتهایی مانند Gateway شرکت شما، رمزنگاری برای آشکار کردن نرم‌افزارهای مخرب و تحویل موفقیت‌آمیز شکست خواهد خورد. راه حل‌ها:
    • انجام اسکن نرم‌افزارها در ایستگاه‌های انتهایی کاربر بعد از رمزگشایی.
    • ذخیره کلیدهای خصوصی در سرور gateway، تا رمزگشایی قبل از اسکن نرم‌افزارهای مخرب آن بتواند اتفاق بیفتد (اگر چه این امر باعث شکست برخی از اهداف رمزنگاری می‌شود، چون به هر کسی اجازه می‌دهد به سرور gateway دسترسی یابد و امیل کاربر دیگر را بخواند)
    • می‌توان از اسکنرهای محتوای پیام که به‌طور خاص برای چک کردن محتوای پیام رمز شده در زمان انتقال جهت حفظ امضاها و رمزنگاری انتها به انتها طراحی شد استفاده کرد. چنین راه حل‌هایی می‌بایست شامل حفاظت‌های تعبیه شده‌ای برای کلیدهای خصوصی ای که هم برای رمزگشایی پیام و هم برای رمزگشایی مطالب به‌طور موقت استفاده می‌شود باشند.
  • با توجه به نیاز به پیاده‌سازی یک گواهی نامه، همه کاربران نمی‌توانند از مزایای S/MIME بهره‌مند شوند، برخی ممکن است یک جفت کلید عمومی/خصوصی را به عنوان مثال آرزو کنند تا بدون هیچ درگیری یا سربار اجرایی گواهی نامه‌ها یک پیام را رمز کنند.

حتی به‌طور کلی، هر پیامی که یک مشتری S/MIME به فرم رمز شده ذخیره می‌کند اگر گواهی نامه/کلیدخصوصی ای که برای رمزگشایی استفاده می‌شود منقضی شده باشد یا اینکه در دسترس نباشد رمزگشایی نخواهد شد. هچنین به دلیل ذخیرهٔ رمزشده، جستجو و ایندکس‌گذاری محتویات پیام رمزشده برای بسیاری از مشتریان امکان‌پذیر نمی‌باشد و البته این مختص به S/MIME نیست و مشکلی نیست که فقط در پیام‌هایی که با S/MIME امضا می‌شوند وجود داشته باشد.

امضای S/MIME معمولاً با چیزی که «امضای جدا یا منفصل» نامیده می‌شود انجام می‌گردد. اطلاعات امضا از متن امضا شده جدا می‌باشد. به سبب این امر نوع MIME با دومین قسمت که دارای زیر نوع application/(x-)pkcs7-signature است بخش‌بندی و امضا شده‌است. نرم‌افزار Mailing list به دلیل تغییر قسمت متنی و در نتیجه بی‌اعتبار کردن امضا بدنام می‌باشد. هر چند این اختصاص به S/MIME ندارد و یک امضای دیجیتال فقط محتویات امضا شده‌ای که تغییر کرده‌است را نشان می‌دهد.

جستارهای وابسته

منابع
  1. RFC 2045: Multipurpose Internet Mail Extensions (MIME). Part One was published in November 1996.
  2. Mission-critical Active Directory: Architecting a Secure and Scalable Infrastructure for Windows 2000. 2001. p. 550. S/MIME adds new MIME content types that provide data confidentiality, integrity protection, nonrepudiation, and authentication services: application/pkcs7-mime, multipart/signed, and application/pkcs7-signature

پیوند به بیرون
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.