|
مقدمه
میگن در زمانهای دور پادشاهی به نام حاج اسمال در جنگ سختی با دشمنانش بود که از یه مشت سامورایی خطرناک، یه دوجین آدم فضایی، گودزیلا و همچنین دسته ایی نینجای شورشی تشکیل شده بود !
حاج اسمال بعد از اینکه 200 بار یه پیام رو به خط خوانا نوشت و برای سوپرمن که جنرال اولش در خط مقدم بود فرستاد، تازه متوجه شد که نینجاهای دشمن پیام رو از حامل میدزدند و بعدش میفهمن که میخواد چیکار کنه و سپس بهش رودستی میزنن !
حاجی بعد از فهمیدن اینکه IQ درون مغزش دارای برابری نزدیکی با IQ یک تکه گوشت کوبیده ی رها شده درون قابلمه هست، خیلی شاکی شد و تصمیم گرفت چاره ایی برای این مشکل (یعنی فرستادن نامه طوری که دشمن متوجه نشه) در نظر بگیره.
حاجی اولش تصمیم گرفت که نامه رو به کمک یک ورقه راهنما تبدیل به رمز کنه. مثلا توی اون ورقه هه نوشته شده بود که "اگه میخواین بنویسین حمله، از کلمه ی کلوچه فندقی استفاده کنین ! و اگه میخواین بنویسین عقب نشینی به جاش کلمه ی نخود فرنگی باید استفاده بشه !". اسم این ورقه هه کلید بودش...
حاجی با این راهکار خیلی حال کرد و تصمیم گرفت که پیامهاش رو رمز کنه و بعدش برای سوپرمن و دوستان در خط مقدم بفرسته. در اولین اقدام حاج اسمال پیام رو رمز کرد و بدون کلیدش برای سوپرمن فرستاد. سوپرمن با دیدن یه مشت شر و ور که غیرقابل خوندن بودن شاکی شد و جواب رو با فحشهای رکیک پس فرستاد !
حاجی تازه متوجه شد که چه گندی زده ! پس تصمیم گرفت تا پیام رو رمز کنه و بعدش هم پیام و هم کلید رمز شیکن رو برای سوپرمن بفرسته. ایندفعه به نظر میرسید همه چیز باید درست پیش بره ولی باز هم نینجاها به پشتیبانی گودزیلا موفق شدن که هم پیام رو بدزدن و هم کلیدش رو و اوضاع بدتر از قبل شد !
در آخر حاج اسمال دید که هنوز نه کامپیوتر اختراع شده، نه زیرساختی به نام PKI و نه شبکه ایی به نام اینترنت ! پس تصمیم گرفت که سوپرمن رو فرابخونه و یه کلید رمز شکن رو خودش شخصا بهش بده. اینطوری هر وقت پیامی رمز شده به دست سوپرمن میرسید، چونکه فقط و فقط اون کلید رمز شکنش رو داشت که از قبل توسط حاجی بهش داده شده بود میتونست پیام رو باز کنه، بخونه و دستورات رو اجرا کنه.
420 تا کلمه تا اینجا نوشتم و به خاطر این داستان بی سر و ته شرمنده ی خودم و دوستان شدم تا بتونم ایده ی رمزگذاری و رمز شکنی رو به صورت خیلی ساده در ذهنها تداعی کنم و ذهنتون رو برای ور رفتن با موضوع جدیدی که قراره یاد بگیرین آماده کنم!
برمیگردم به موضوع امروز که در مورد زیرساختی به نام Public Key هستش. داستان بالا تو ذهنتون هستش دیگه ؟! فکر کنین حاج اسمال معجون عمر قورت میداد و به دوران ما میرسید، حالا پشت یه کامپیوتر نشسته و میخواد یه پیام امن رو به یه کامپیوتر دیگه بفرسته...
چونکه عقلش هنوز قد نمیده، یه پیام عشقی رو برای کلثوم دختر عصمت خانوم رمز میکنه و کلیدش رو هم میذاره کنار پیامه و اونرو با Chat ارسال میکنه به کلثوم ! دلش هم خوش بود که پیامه رمز شده هستش و کسی حالیش نمیشه الا گیرنده ی پیام (کلثوم) که کلید رو دریافت میکنه.
غافل از اینکه این وسط هم یه هکر نشسته و هر پیامی رو که روی شبکه قرار میگیره رو برمیداره و محتوای داخلش رو چک میکنه.
همونطور که متوجه شدیم حتی اگه حاج اسمال پیامش رو با پیچیده ترین و هزینه بر ترین الگوریتمهای رمزنگاری به رمز در بیاره، هکره راحت میتونه با در دست داشتن کلید رمز، اقدام به شکوندن قفل پیام و خوندن پیامی کنه که نباید بکنه !
پس به نتیجه میرسیم که فرستادن یک پیام رمز شده و کلید رمزش بر روی شبکه های امروزی کار ساده ایی نیست. ایده های مختلفی میتونه به ذهنمون برسه ولی اکثرشون یا مفت نمی ارزن یا اینکه ناکارآمد هستند.
مثلا میتونیم اول پیامه رو بفرستیم و 1 هفته بعد کلیدش رو بفرستیم. ولی مشکل اینجاست که هکره هم یک هفته بعد همونجا نشسته و منتظر بیده ! برای همین این راهکار نه تنها مفت نمی ارزه (هکره کلید رو بالاخره به دست میاره !) بلکه ناکارآمد هم هستش (یه هفته یه طول عمره !).
یا اینکه میتونیم توی پیام ذکر کنیم "کلثوم ! وقتی که پیام رو گرفتی یه رمز جدید روش بگذار و بعدش پیامهای بعدی رو با اون رمزه برام بفرست ! منم هر دفعه که پیام جدید میگیرم، رمز رو عوض میکنم !"
راهکار بالا هم با دونستن این حقیقت که هکره میتونه متن اولیه رو بخونه، مفت نخواهد ارزید !
عکس 1 : اشاره به نقش خرابکار یک هکر در ارتباطی که نیاز به امنیت دارد.
Symmetric
سیستمهای رمزگذاری رو میشه به دو گروه Symmetric و Asymmetric تقسیم کرد.
در حالت Symmetric (متقارن) رمزگذاری هم با یک کلید یکسان به رمز در میاد و هم رمزش شکسته میشه. در این نوع سناریوها هم طرف اول و هم طرف دوم از رمزی که روی یک سیستم و یا فایل گذاشته شده با خبر هستند و میتونن با همون رمز فایلها رو هم باز کنن و هم رمز کنن.
مثال بارز این نوع رمزگذاری هم یک فایل رمز شده ی RAR هست که مثلا پسورد 123 رو روش میگذارین و به طرف خبر میدین که برای باز کردن فایله از 123 استفاده کنه.
همونطوری که متوجه شدین این نوع رمزگذاری فقط ممکنه وقتی به درد بخوره که ما به طرف مقابلمون قبلا و به طور شخصی پسورد رو داده باشیم وگرنه اگر بخوایم طبق سناریوی حاج اسمال و کلثوم (!) عمل کنیم و به همراه فایل یک متن بفرستیم که "هوی ! رمزش 123 هست !"، هکره باز هم میتونه فایله رو باز کنه !
موارد استفاده ی Symmetric Encryption بسیار زیاد هستش ولی در اغلب اوقات در ارتباطات شبکه ایی بر این مبنا ازش استفاده میشه که اگر ارتباط بر اساس یک رمز اولیه برقرار شد، کسی وسط کار نتونه بپره روی ارتباط و با Sniff کردن خط متوجه اطلاعات در حال انتقال بشه !
کلا Symmetric Algorithm مثل کلید قفل انباری خونه مون هستش که هم با اون کلیده قفله رو باز میکنیم و هم با اون کلیده میبندیمش !
یه اشاره هم میکنم که Symmetric-Key Algorithm ها خودشون به دو دسته ی Stream Cipher و Block Cipher تقسیم میشن. Stream Cipher ها همونطوری که از اسمشون برمیاد، یک رشته (Stream) از اطلاعات رو بیت به بیت رمز میکنن در حالیکه Block Cipher ها میان و یه بلاک اطلاعاتی رو انتخاب میکنن و بعدشم کیلویی رمز میکنن. سرعت و دقت رمزگذاری بین این دو نوع الگوریتمها متفاوت هستش که بر اساس نیاز رمزگذار مشخص میشه.
از الگوریتمهای رمزگذاری Stream Cipher ها میشه به سه الگوریتم روبرو اشاره کرد : Data Encryption Standard (DES) , Triple DES (3DES) , Advanced Encryption Standard
از الگوریتمهای رمزگذاری Block Cipher ها هم میشه به A5 ، RC4 و SEAL اشاره کرد.
ولی همونطور که قبلا هم گفتم، رمزگذاری Symmetric مشکل هکری رو که همیشه روی خط حاضر و در حال Sniff خط هستش رو نمیتونه حل کنه. ولی چیکار میشه کرد ؟ ما که هر غلطی بخوایم بکنیم باید اولش طرف رو خبر کنیم و به همین دلیل هر هکری که این وسط نشسته باشه میتونه متوجه زر زر های خصوصی حاج اسمال و کلثوم بشه !
اینجاست که پای زیرساختی به نام Public Key Infrastructure و یا همون PKI میاد وسط.
عکس 2 : طرز کار سیستم رمزگذاری Symmetric
Asymmetric
قبل از هر چیز ترجیح میدم اول شما رو با موضوعی به نام Hashing آشنا کنم که به درک بهترتون از PKI میانجامد :
ساختار رمزگذاری Asymmetric بر اساس Hashing کار میکنه. Hashing نوعی به هم ریختن اطلاعات هستش و از نظر ریاضی یک تابع یک طرفه هست بدین معنی که هر مقداری بهش بدی، یک جواب کاملا استثنائی بهت میده.
الگوریتم Hash رو کارخونه ایی در نظر بگیرین که از یه طرف هر چیزی که بهش بدی، از اون طرف یک مقدار استثنایی و فقط مخصوص ورودی بیرون میده. بدین ترتیب بر اساس الگوریتمهای Hash اگر بخوایم اسم "محمد مهدی حاجی اسمعیلی" رو رمز کنیم ممکنه خروجی اول “s$dn2-|/jkn” باشه و بعدش اگر بیایم و "محمد مهدی حاجی اسمعیلی " رو با تغییر فقط یک حرف تبدیل به "محمذ مهدی حاجی اسمعیلی " کنیم خروجی کاملا متفاوت با اولی خواهد بود !
اینطوری ما میتونیم در ساختار کامپیوترها از الگوریتمهایی استفاده کنیم که به ازای هر مقدار خاص، یک جواب استثنایی بهمون میده و مثلا من میتونم از اسم خودم (محمد مهدی حاجی اسمعیلی) یک Hash بگیرم که در تمام دنیا فقط و فقط مختص به من هستش و هیچکس دیگه ایی اونرو نخواهد داشت و جالب اینجاست که این الگوریتمها غالبا یک طرفه هستند بدین معنی که اگر یک متن Hash شده رو داشته باشین، به هیچ وجه نمیتونین با کمک الگوریتمهای دیگر این Hash رو برگردونین تا بتونین بفهمین فایل اولیه چی بوده.
از Hashing در بازه ی واقعا بزرگی در دنیای کامپیوتر استفاده میشه و مثالی که اینجا میتونم براش بزنم اینه :
شما یک سایت دارین که بر اساس استاندارهای Web 2.0 اجازه میده کاربران درش ثبت نام کنن و به تبادل اطلاعات بپردازن. هر کاربر باید یک Password برای خودش انتخاب کنه و شما هم این Password ها رو در یک بانک اطلاعاتی وارد میکنین.
شما شبها توی کابوس میبینین که یه هکر بالاخره میتونه به بانک اطلاعاتی دسترسی پیدا کنه و سپس Password های تمام کاربرها رو به دست بیاره. میشینین و با خودتون فکر میکنین که "چه خاکی تو سرم بریزم ؟!" و بعدش به نتیجه ی زیر میرسین :
کاربران به هنگام ثبت نام Password شون رو در محلی که باید وارد بشه، مینویسن. سپس اسکریپت تحت وب شما (که میتونه PHP , ASP یا هر چیز دیگه باشه) این Password رو میگیره و Hashش میکنه. این Hash در تمام دنیا فقط مختص به اون Password هستش و هیچ Password دیگه ایی اونرو نخواهد داشت. حالا شما میاین و اون Hash رو به جای Password در بانک اطلاعاتیتون ذخیره میکنین.
هر وقت که کاربرا بخوان به سایت وصل بشن، پسوردشون رو مینویسن، این پسورد Hash میشه و بعدش Hashش با Hashیی که در بانک اطلاعاتی هست چک میشه و سپس اگر هر دو مثل هم بودند اجازه ی ورود داده میشه.
بدین ترتیب حتی اگر هکر دستش به این Password های Hash شده برسه، هیچ غلطی نمیتونه باهاش بکنه برای اینکه این Hash ها برگشت ناپذیرند و فقط به صورت یک طرف به دست میان.
بیشتر از این وارد موضوع واقعا پیچیده ی Hashing نمیشم، ولی هدف از مطرح کردن توابع و الگوریتمهای Hash چی بود ؟! یادتون باشه که ما هنوز مشکل اولمون حل نشده ! مشکل اولمون چی بود ؟! این بود که چطوری میتونیم اطلاعات رو طوری از حاج اسمال به کلثوم بفرستیم تا هکره اگه اونرو بشنوه نتونه هیچ غلطی باهاش بکنه...
عکس 3 : Hashing و خروجی آن.
حالا میرسیم به موضوع اصلی…
Public Key Infrastructure
یه مشت دانشمند باحال (!) اومدن و به مشکلی که در بالا ذکر کردیم اندیشیدند ! اولین دسته ی این دانشمندها Whitfield Diffie و Martin Hellman بودند. این دو تا اومدن و به کمک ریاضیات (این علم توپ !) یک الگوریتم دو طرفه ی Hashing برای رمزگذاری اختراع کردند که به الگوریتم دفی-هلمن معروف شد.
یادتون هست که الگوریتمهای Hashing یی که در بالا نام بردم همه شون یکطرفه و متقارن بودند ؟! ولی این دو دانشمند تونستن که این الگوریتمها رو دو طرفه و در عین حال نامتقارن بکنند که در پایین توضیح میدم چطوری :
ساز و کار این الگوریتم اینطوری هست که از دو تا کلید برای رمز گذاری و رمزگشایی استفاده میکنه. کلید اول Private Key نام داره و کلید دوم هم Public Key. ساختار این کلیدها طوری هستش که یکی میتونه اطلاعات رو رمز کنه و فقط و فقط دیگری هستش که میتونه رمز کلید اول رو بشکونه. این ساختار دو طرفه هستش بدین معنی که اگر Public Key اطلاعات رو رمز کنه، فقط Private Key میتونه رمز رو بشکونه و اگر Private Key اطلاعات رو رمز کنه فقط Public Key میتونه اون رمز رو منهدم کنه !
در اینحالت شما میتونین با یک کلید اطلاعات رو رمز کنین ولی اگر کلید دوم رو نداشته باشین (کلیدی که با کلید اول متقارن هست) اگر هزاران سال هم وقت بگذارین و سعی کنین که با سوپر کامپیوترها و روشهایی همچون آزمون و خطا رمز رو بشکونین، نخواهید توانست مگر وقتیکه استخوناتون هم پودر بشن !
و این یک حقیقت هستش ! هر چقدر که قدرت کلید بیشتر باشه (مثلا 128 بیتی و یا 1024 بیتی باشه) زمان بسیار زیادتری طول خواهد کشید تا یک علاف بتونه با یک سوپر کامپیوتر اون رمز رو بشکونه.
خب ! حالا تکنولوژی پیشرفت کرده و هم حاج اسمال و هم کلثوم با کامپیوترهاشون میتونن Public Key و Private Key هایی درست کنن که فقط و فقط مختص به تنظیمات کامپیوترشون هستش و در دنیا الگوریتم Hashing این دو کلید تک هست.
اینجا رو خوب توجه کنین برای اینکه همینجاست که ما میزنیم و دهن هکره رو برای اولین بار سرویس میکنیم (!) :
1. دو کامپیوتر A و B با روشی شبیه به روش 3 Way Handshake اقدام به تبادل کلیدهای Public شون با همدیگر میکنند. حالا کامپیوتر A کلیدKey B Public رو داره و کامپیوتر B کلید Public Key A. به فرآیند تبادل کلید بین دو کامپیوتر Public Key Exchange و یا PKE میگن.
2. اگر کامپیوتر A بخواد اطلاعاتی رو رمز کنه و برای B بفرسته، میاد و اون اطلاعات رو با Public Key B رمز میکنه و برای کامپیوتر B میفرسته.
3. اطلاعات رمز شده به دست کامپیوتر B میرسه. حالا کامپیوتر B با Private Key B اقدام به شکوندن اطلاعاتی میکنه که با Public Key B رمز شده بود !
ممکنه درک روند بالا اولش یه کم سخت باشه...بیاین ! من راحت ترش میکنم :
هر کامپیوتری در دنیا اجازه داره که Public Key کامپیوترهای دیگر رو داشته باشه. چرا ؟! برای اینکه Public Key اصلا درست شده تا به دست عموم برسه و مشکلی هم نیست ! Private Key همیشه و همیشه باید در دست کامپیوتر صاحب باقی بمونه ولی پخش شدن Public Key در دست دیگران مشکلی نداره. باز هم تاکید میکنم که Private Key نباید اصلا از داخل کامپیوتر خارج بشه و دلیلش هم اینه :
Public Key از کامپیوتر A خارج میشه و دست کامپیوتر B میفته. کامپیوتر B هیچ کاری با این کلید نمیتونه بکنه الا رمز کردن داده ! و جالب اینجاست که وقتی کامپیوتر B این اطلاعات رو با کلید A رمز میکنه، دیگه حتی خودش هم نمیتونه اون اطلاعات رو بخونه ! در واقع دیگه هیچکسی توی این دنیا نمیتونه این رمز رو بشکونه مگر کسی که کلید متقارن رو داشته باشه و اون هم کسی جز خود کامپیوتر A نیست !
بدین ترتیب حتی اگر یک هکر هم سر راه نشسته باشه و خط رو Sniff کنه، در ابتدا فقط میتونه Public Key های دو کامپیوتر A و B رو به هنگام مبادله گیر بیاره که به هیچ دردیش نمیخوره !
بعدش هم اگر اطلاعاتی رمز بشه و دست این هکره بیفته چونکه Private Key کامپیوترهای A و B رو نداره (این کلیدها همیشه در کامپیوترهای صاحب، باقی خواهند موند!) هیچ غلطی نمیتونه با این اطلاعات رمز شده بکنه و بدین ترتیب همیشه اطلاعات فقط در حضور کامپیوتری که صاحبشون هست رمزگشایی خواهند شد.
عکس 4 : ساز و کار Public Key Infrastructure
در طول زمان این الگوریتمها پیشرفته شدند. به عنوان مثال الگوریتم Diffie-Hellman در ابتدا جزو الگوریتمهای موفق نامتقارن به حساب میرفت ولی به خاطر اینکه این الگوریتم برای ارتباطات شبکه ایی و ایجاد Session های ارتباطی بهینه سازی نشده بود، به خاطر سرعت پایین و هزینه ی محاسباتی بالاش کم کم جاش رو به جوونترها داد !
یک سال بعد الگوریتم RSA که از نام فامیلی سه مخترعش یعنی Rivest , Shamir , Adleman گرفته شده بود پا به عرصه گذاشت و تونست سریع خودش رو معروف و محبوب کنه. این الگوریتم تا مدت زمان طولانی به طور انحصاری دست شرکتهایی بود که از اون استفاده تجاری میکردند و پیاده سازی اون از طریق برنامه نویسی تا حدی سخت بود که استادهای کلاسهای برنامه نویسی برای خوابوندن کل دانشجویانشون اونها رو با درخواست پیاده سازی الگوریتم RSA به چالش میکشیدند ! ولی این الگوریتم چند وقت هستش که در اختیار عموم قرار گرفته و انحصارش شکسته است.
انواع و اقسام الگوریتمهای رمزگذاری نامتقارن اکنون در دنیای IT حضور دارن که از بینشون میشه مثلا به الگوریتمهایی همچون ECC و یا El Gamal اشاره کرد ولی میشه این ادعا رو کرد که درصد زیادی از سیستمهای رمزگذاری و Certificate های امروزی بیشتر به RSA روی آورده ن تا دیگر الگوریتمها، که این برتری غالبا به سرعت بالا و هزینه ی محاسباتی پایین این الگوریتم مرتبط هستش.
Digital Signature
فرض کنیم که شما اومدین و با کامپیوتری به نام CyberLone ارتباط برقرار کرده و در این حین فرآیند PKE بین شما و کامپیوتر طرف صورت گرفته و بدین ترتیب شما و CyberLone کلیدهای Public همدیگر را دارید.
سوال اساسی اینجاست : وقتی بسته ایی اطلاعاتی و رمز شده به دست شما میرسه، شما چطور میخواین مطمئن بشین که این بسته ی اطلاعاتی واقعا از طرف CyberLone اومده ؟!
اینجاست که پای مقوله ایی به نام Digital Signature و یا همون امضای دیجیتالی میاد وسط.
امضای دیجیتالی مثل هلو قابل درکه ! اگه PKI رو یاد گرفته باشین، درک Digital Signature هم اصلا دردی نداره !
وقتی که CyberLone میخواد ثابت کنه که فرستنده واقعا خودش هست، میاد و یک شناسه ی قابل درک (مثلا یه عکس یا متن یا گواهینامه) رو به کمک Private Keyش رمز میکنه. ما میدونیم که این محتوای رمز شده فقط با Public Key میتونه از رمز باز بشه و از این نظر مشکلی نیست ! چرا ؟ برای اینکه قبلا هر کامپیوتری که میخواسته با ما ارتباط امن برقرار کنه، Public Key مون رو ازمون گرفته !
حالا CyberLone میاد و این پیام رمز شده رو به ما ارسال میکنه. پیام دست ما میرسه و ما به کمک Public Key مخصوص CyberLone (که در PKE ازش گرفته بودیم) پیام رو رمزگشایی میکنیم و متوجه میشیم که محتوا همون چیزی که باید باشه هستش !
حالا ما میایم دو دو تا چهار تا میکنیم :
1. اطلاعاتی رمز شده دست ما رسیده که با Public Key مربوط به CyberLone باز میشه.
2. باز شدن این اطلاعات به این معنی هست که با Private Key مربوط به CyberLone رمز شده بوده.
3. فقط CyberLone این Private Key رو داره.
4. پس CyberLone فرستنده ی حقیقی محتوای رمز شده بوده !
اینطوری میشه که کلثوم میتونه حاج اسمال رو از بقیه ی نامردای محل تشخیص بده !
عکس 5 : ساز و کار Digital Signature
Digital Certificate
مطمئنا تا بحال سر و کارتون به سایتهایی افتاده که وقتی بهشون وصل میشین یه دفعه میبینین که HTTP بالای صفحه ی این سایتها تبدیل به HTTPS میشه. و یا حتی مواردی که وقتی با پروتکل HTTP به سایته وصل میشین، میبینین که سایته صفحه ی اصلی رو نشون نمیده و به جاش ازتون درخواست میکنه که از HTTPS به جای HTTP استفاده کنین تا بتونین اون صفحه رو ببینین.
تا حالا نشستین و فکر کردین که چرا ؟! اصلا مهم نیست عژیژانم ! برای اینکه اگر هم نمیدونستید، قراره که اینجا یه کشف خلاصه از این موضوع داشته باشیم !
عکس 6 : صفحه ی Login سایت Gmail و استفاده ی آن از پروتکل SSL
Digital Certificate ها کارشون بسیار نزدیک به نامشون هست! و نامشون تقریبا یه چیزی مثل "مدرک دیجیتالی" میشه. چی هستن ؟! Digital Certificate ها حاوی کلیدهای Public و Private یی هستند که از طرف یک Authority بهشون اعطا شده... موضوع رو روشنتر میکنم :
ما تا اینجا با ساختار Public Key Infrastructure آشنا شدیم و فهمیدیم که اگر دو طرف ارتباط اولیه مبنی بر PKE رو قبول کنن، کلیدهاشون با همدیگر تبادل میشه و سپس میتونن به طور کاملا امن با هم تبادل اطلاعات کنن و هیچ ننه قمری هم نمیتونه متوجه محتوای رمز شده ی بین این دو بشه الا خودشون.
حالا فکر کنین که طرف مقابل شما به جای اینکه کلثوم (یک آشنای همیشگی !) باشه، یک سایت هستش. برای سایت هم صفحه ی اول ورود به Gmail رو در نظر بگیرین. چرا Gmail رو مثال زدم ؟ برای اینکه در صفحه ی اول Gmail شما باید UserName و Password تون رو وارد کنین و اگر هکری وسط راه اقدام به Sniffing کنه، چونکه ارتباطتون امن و رمزشده نیست میتونه متوجه اطلاعات کاربریتون بشه.
این سایت برای شما ناشناخته هستش بطوریکه نمیتونین بهش اطمینان کنین. ممکنه که سازندگان سایت مقابل یه مشت خلافکار و کلاه بردار باشن، پس شما چطور میتونین به ایجاد ارتباط امن باهاشون فکر کنین ؟!
اینجاست که پای Digital Certificate ها میاد وسط. Google بلند میشه میره سراغ شرکتی که به طور بین المللی توسط همه ی کشورها مورد اعتماد هستش (Trust اولیه) و سپس از اون شرکت درخواست میکنه تا یک جفت کلید Public و Private برای امن کردن ارتباطات سایتش یعنی Gmail بهش اختصاص بده.
این شرکت میاد گوگل رو تا حدی برانداز میکنه و وقتیکه مطمئن میشه طرف قابل اعتماد هستش، یک جفت کلید مخصوص Gmail میاد درست میکنه و سپس این کلید رو به صورت بین المللی امضا میکنه و بعدش هم اونرو به Gmail میده.
حالا گوگل میاد و در صفحه ی اول Gmail این Certificate رو پیاده سازی میکنه. پس از پیاده سازی این Certificate در صفحه ی اول Gmail، هر کاربری که از اون به بعد بخواد به Gmail متصل بشه، ارتباطاتش بر اساس زیرساخت Public Key امن خواهد شد به طوریکه حتی اگر یک هکر هم بین او و Gmail بشینه و استراق سمع کنه، چونکه ارتباط بر اساس PKI رمز شده، نمیتونه متوجه چیزی به جز یه مشت شر و ور بشه !
پس متوجه شدین که Digital Certificate ها چی هستن دیگه ؟! Digital Certificate ها حاوی کلیدهای رمزنگاری هستند.
به چه درد میخورن ؟! به درد کسانی میخورن که میخوان صفحه ی مورد نظرشون به صورت بین المللی به عنوان یک (و یا چند) صفحه ی امن شناخته بشه.
کاربران هر وقت به سایتی وصل بشن که به کمک یک Digital Certificate امن شده، در قسمت آدرس URL میتونن متوجه بشن که ارتباط به جای اینکه مثل همیشه بر اساس HTTP باشه، ایندفعه بر اساس HTTPS هستش و HTTPS چیه ؟!
HTTPS = HTTP + SSL
SSL یکی از پروتکلهای زیرمجموعه ی TCP/IP هستش که برای ایجاد ارتباطات امن بر اساس ساختار PKI به کار میره. این پروتکل تمامی وظایف PKE و پیاده سازی ارتباط و همچنین رمزگذاری داده های در حال ارسال رو به عهده میگیره. پورتی که این پروتکل ازش استفاده میکنه، پورت شماره 443 هستش و یکی از دلایلی که برخی سایتها که با HTTP باز نمیشدن، یه دفعه با HTTPS باز میشدن (خدا سال پیش اینکارا اتفاق میفتاد ! الان دیگه نه !) همین تفاوت پورت بودش.این پروتکل امروزه تبدیل به TLS شده که برای اطلاعات بیشتر در موردش میتونین به منابع خودتون (ترجیحا RFC ها بهتر هستند) رجوع کنین.
وقتی سایتی یک Digital Certificate داشته باشه و ارتباطش بر اساس HTTPS باشه، کاربر میتونه با کلیک کردن بر روی نام Certificate به اطلاعات اون مدرک دست پیدا کنه. چرا اینکار لازمه ؟ تا کاربر مطمئن بشه که شرکت و بنیان اختصاص دهنده ی Certificate مورد نظر قابل اعتماد هستش یا نه.
امروزه شرکتهای خاصی در این زمینه ( اختصاص دادن Digital Certificate) در حال کار هستند که از بین اونها میشه به شرکتی مثل VeriSign اشاره کرد.
بعد از کلیک کاربر بر روی این مدرک، اطلاعاتی از قبیل موارد زیر به نمایش در میاد :
• Serial Number : این شماره به طور بین المللی مختص به مدرک فوق هست و بدین طریق میتونین با مراجعه به شرکت مدرک دهنده، اون مدرک رو شناسایی و پیگیری کنین.
• Signature Algorithm : الگوریتمی که برای ایجاد کلیدها و امضا به کار رفته.
• Subject : نام شخص و یا سایتی که این مدرک بهش اختصاص یافته.
• Valid-From : اولین روزی هستش که مدرک معتبر شناخته میشود.
• Valid-To : آخرین روز اعتبار مدرکه هستش.
• Issuer : شرکتی که این مدرک رو به سایت فوق اختصاص داده است.
• Public Key : کلید Public یی که همونطوری که در بالا گفتم به طور عمومی در دست همه قرار میگیره تا بتونن اطلاعاتشون رو باهاش رمز کنن و به صاحب کلید بفرستن تا فقط اون بتونه اطلاعات رمز شده رو باز کنه.
حالا بیاین به سناریوی زیر فکر کنیم :
شما یه شرکت دارین که یک شبکه ی اینترانت داخلی درش راه انداختین. برای یک سری اهداف اومدین و Web Server یی در این شرکت پیاده سازی کردین که سایت مورد نظرتون رو روی اون سرور آپلود کردین. قسمتی از این سایت مربوط به Login کردن کاربران هستش و شما برای جلوگیری از Sniff شدن اطلاعات در حال ارسال توسط کاربران، میخواین اقدام به پیاده سازی یک ارتباط امن مبتنی بر PKI بکنین.
آیا باید برین و باز هم از شرکتهای معتبر بین المللی این مدرک رو بگیرین ؟!
نه ! اینجاست که بحث ما به توضیح در مورد Certificate Authority ها و یا همون CA ها کشیده میشه :
اون شرکته رو یادتونه ؟ همونی که مدرک میداد ؟! به اینها میگن Certificate Authority یعنی "کسی که مجوز و صلاحیت دادن Certificate ها رو داره" و میدونین جالبی قضیه کجاست ؟
جالبیش اینجاست که هر کسی در دنیا میتونه به کمک یک نرم افزار خاص، کامپیوترش رو تبدیل به یک CA کنه. چطوری ؟! هیچی ! میرین نرم افزاره رو نصب میکنین و سپس هر درخواستی رو که برای دریافت مدرک دارین، بهش میدین و اون هم پس از چک کردن درستی درخواستتون، به شما یک Digital Certificate اختصاص میده تا بتونین اونرو در جایی که میخواین پیاده سازی کنین.
بارزترین مثالی که برای این نوع نرم افزار دارم، خود Certificate Authority هستش که درون سیستم عاملهای Windows Server به طور داخلی پیاده سازی شده و بدین صورت شما میتونین یک CA Server درون شبکه تون پیاده سازی کنین و سپس درخواستهای داخلی تون برای دریافت مدرک رو به اون CA بفرستین.
ولی پس فرق این نوع CA با اون CA های بین المللی چیه ؟!
فرقش اینه که CA های بین المللی شناخته شده هستند و تمام بنیانهای کره ی زمین بهشون اعتماد دارن و بهمین دلیل وقتیکه مدرکی صادر میکنن، این مدرک توسط همگی قابل قبول و اعتماد هستش ولی CA هایی که به صورت کیلویی توسط کاربران متفاوت پیاده سازی میشن، میزان اعتمادشون در حد همون شبکه ی محلی هستش که اون CA Server رو درش پیاده سازی کردین و نباید انتظار داشته باشین که کسی از شبکه ایی دیگر به این شبکه وصل بشه و سپس به سایتی که توسط این CA مدرک گرفته بخواد اطمینان کنه.
عکس اول مقاله رو یادتونه ؟! ایناهاش ! یه دونه بهترش رو گذاشتم !
عکس 7 : ساختار درختی Certificate Authority ها
این عکس داره یک ساختار درختی رو نشون میده. در این ساختار درختی که بطور بین المللی هم پذیرفته شده ما یک درخت اصلی داریم که بهش میگن Root CA.
کار Root CA مدیریت و نظارت بر تمامی مدارک داده شده در بالاترین سطح هستش. این سرور یک سرور خیلی حساس هستش و باید در اغلب اوقات از شبکه جدا بشه و در یک گاوصندوق امن نگهداری بشه. تنها وظیفه ی این سرور اختصاص دادن نهایی مدارک و ذخیره سازی اطلاعات اونها هستش. اگر امنیت این سرور در خطر بیفته، امنیت تمامی اطلاعات امنی که در دنیا بر اساس SSL (و امروزه TLS) شکل گرفتن به خطر میفته و بهمین دلیل نگهداری این سرور در جایی امن خیلی مهمه.
پس از Root CA، سرورهای زیرمجموعه ایی به نام Subordinate CA (و یا Intermediate CA) قرار دارن که کارشون برداشتن بار اضافی از روی دوش Root CA هستش.
پس از Subordinate CA ها هم Issuing CA ها قرار گرفتن که طرف حساب با کاربران سطح اینترنت هستند و مدارک اصلی که ما ازشون استفاده میکنیم رو اونها میدن. مثال بارز Issuer CA ها هم شرکتهایی مثل Verisign , Equifax , Digicert و یا Thawte هستند.
جالب اینجاست که اگر شرکت شما در سطح Enterprise باشه و نیاز به استفاده از Certificate ها درش خیلی حیاتی باشه، شما میتونین یک ساختار درختی مثل اون چیزی که بالا نام بردم در شرکتتون پیاده سازی کنین تا بتونین عمل دادن مدارک دیجیتالی رو به صورت خیلی حرفه ایی و گسترده پیاده سازی و کنترل کنین.
عکس 8 : نمادی از اطلاعات یک Digital Certificate
همونطوری که در بالا میبینین سایت Gmail اقدام به گرفتن مدرک دیجیتالیش از شرکت Thawte کرده که خود این شرکت هم از Verisign مدرکش رو گرفته !
موضوعات متفرقه
مشکلات Digital Certificate ها
شرکتهای اختصاص دهنده ی مدارک در 20 سال اخیر یک بازار به دست آورده ن، ولی این بازار اون چیزی که باید میبوده نشده. مدارک دیجیتالی خیلی از اون چیزهایی که ادعا میشد رو نتونستن به بار بیارن و در نهایت وظیفه ی اصلیشون پیاده سازی یک بستر امن برای ارسال اطلاعات به طرف مقابل هست به طوریکه در این بین کسی قادر به درک اطلاعات ارسالی نباشه ولی این ساختار نمیتونه جلوی Hack کردن سرور و یا حتی Hack شدن کسی که به این سرور هستش رو بگیره و مقاصد امنیتی که در نظر داره محدود هستش.
شاید بتونم بگم که موفقترین مکان برای پیاده سازی این تکنولوژی، ادارات دولتی و همچنین Smart Cardها باشه. ادارات دولتی به خاطر اهمیت و حساس بودن اطلاعاتشون نیاز به یک ساختار قابل اعتماد برای رمزگذاری داده ها دارند که PKI میتونه این ساختار رو براشون فراهم کنه.
موارد استفاده ی Certificateها
• Digital Signature : برای مطمئن شدن از هویت اصلی فرستنده
• Encrypting File System : این ساختار با رمز کردن محتوای فایلهای درون درایوهای NTFS سیستم عاملهای ویندوز به کمک هر دو ساختار Symmetric و Asymmetric، دسترسی به این فایلها را کاملا محدود به دارنده ی Private Key اصلی کاربر رمزکننده میکند. اگر خدا خواست در این مورد یک مقاله ی کامل خواهم نوشت، یادم هم رفت، یادم بندازین !
• Internet Authentication : همان بحث امن کردن قسمتهای Login سایتها برای جلوگیری از سرقت هویت کاربران هستش که در بالا نیم ساعت درباره ش توضیح دادم !
• IPSec : یکی از راههای امن کردن اطلاعات به کمک پروتکل IPSec استفاده از Digital Certificate ها هستش که اگر خدا خواست بعدا در موردش توضیح میدم.
• Secure Email : با زیاد شدن استفاده ی ISP ها از Firewall های لایه هفتی، این احتمال که بشینن و Email های شما رو زرت و زرت چک بکنن داره بالا میره و یکی از راههای جلوگیری از انجام اینکار هم پیاده سازی Certificate ها در ساختار Email تون هست که خودش یک مقاله ی جدا میطلبه.
• Wireless Network Authentication : یکی دیگر از راههای امن کردن ارتباطات بی سیم هم استفاده از مدارک دیجیتالی میتونه باشه.
موخره
جون عمه تون نذارین من دوباره بگم که این مطلب بالا فقط یه مقدمه بودش و برای درک بهترش باید خودتون برین دنبال بقیه ی موضوع و تازه اشکالات من رو هم تصحیح کنین و بهم بگین تا اینجا درستشون کنم !
دوباره گفتمش آره ؟! ای تف به این...
این مقاله مثل یه گلوله ی کوچیک برفی بود که از بالای یه کوه سر بخوره و سر راهش اینقده برف با خودش به حرکت در بیاره که در نهایت یک بهمن عظیم به وجود میاره ! پس بدونین که از اینجا به بعدش رو خودتون باید به عهده بگیرین و جلو ببرین.
هر دفعه که مقاله مینویسم سعی میکنم که به تمام چیزها یه اشاره ی کوچیکی بکنم، ولی نمیدونین که این دنیا چقدر بزرگه ! مثلا نمیدونین که من چقدر دوست داشتم در مورد EFS در سیستم عاملهای ویندوز صحبت کنم ولی به خاطر جلوگیری از طولانی شدن مقاله بیخیالش شدم (انشاءالله در مقاله های بعدی !)
پس کاری که میکنین اینه که هر چند وقت یکبار به سایت CyberLone.com یا فروم iLearn.ir برای مطالب جدید سر میزنین و در زمانهایی غیر از این میرین و خر میزنین ! حالیتون شد ؟! خوبه !
اگه مقاله ش تونسته کمکی بهتون بکنه یه صلوات برای فرج امام زمان بفرستین و بعدشم برای بنده و CyberLone.com دعا کنین تا بازم باشیم و بتونیم از این مقاله ها بنویسیم !
موفق باشید
دانلود مقاله ی بالا به صورت نسخه ی PDF :
|
ببخشيدا انقدر سوال مي كنم. اگر من روي كامپيوتر خودم كه روش فايل Encrypt شده دارم Certificate م روبه همراه Private Key Export كنم واين Cer به دست يك هكر بيفته مي تونه اطلاعات روي شبكه من رو بعد از اسنيف كردن Decrypt كنه؟ 
سایت جدیدنون رو تبریک می گم .
جداً خیلی خوشگله !
شنیدم که خودتون طراحی ش کردید ؟ درسته ! ( این همه سلیقه بعیده از شما ! _ جداً شوخی کردم _ )
امیدوارم هر چی عمر وبلاگ ماست بقای سایت شما باشه !
موفق باشید .