فصل دوم: پروتکل WEP
سه شنبه 17 بهمن 1391 5:52 PM
در ابتدای این فصل، به بیان سه سرویسی که IEEE برای شبکه های وایرلس تعریف کرده است، میپردازیم.
پروتکل WEP یک پروتکل برای شبکه های وایرلس IEEE 802.11 میباشد. هویت سنجی در این پروتکل برپایه یک کلید مشترک میباشد. شکل زیر هویت سنجی توسط WEP را نشان میدهد:
در ابتدای کار، آداپتور یا مخدوم(کسی که میخواهد به شبکه وصل شود) یک درخواست هویت سنجی به AP میفرستد، سپس AP یک رشته تصادفی تولید کرده و آن را به آداپتور میفرستد. آداپتور این رشته را با استفاده از کلید از پیش تعیین شده، رمز میکند و حاصل را برای AP ارسال میکند، AP با توجه به رشته تصادفی، پاسخ آداپتور را بررسی میکند و در صورتی که پاسخ به صورت صحیح رمز شده باشد، تایید موافقت را به آداپتور میدهد. روش رمزنگاری و رمزگشایی در این پرتکل، RC4 میباشد.
محرمانگی نیز در این روش برپایه کلید به اشتراک گذاشته شده میباشد. که با استفاده از این کلید و رمزنگاری RC4 اطلاعات را رمز میکند. کلیدها در این روش میتوانند اندازه هایی از 40 بیت تا 104 بیت داشته باشند. این کلید با IV[1] 24 بیتی ترکیب شده و یک کلید 64 بیتی (یا 128 بیتی) را تشکیل میدهند.
ابتدا فرستنده یک IV را تولید میکند و به همراه کلید به الگوریتم RC4 میفرستد. از طرفی فرستنده اطلاعاتی را که میخواهد بفرستند، آماده میکند و این داده ها را با خروجی الگوریتم RC4، XOR میکند، که به این اطلاعات جدید بدست آمده اصطلاحا Cipher text میگوییم. به عکس زیر که گویای این کارها میباشد، توجه کنید:
پروتکل WEP برای سرویس Integrity اطلاعات، از CRC استفاده میکند. یک کد CRC قبل از اینکه داده ها رمزنگاری شوند، تولید میشود. در گیرنده، بعد از رمزگشایی اطلاعات، یک CRC از اطلاعات بدست آمده، تولید میشود و با CRC فرستنده مقایسه میشود. اگر تفاوتی بین دو کد باشد، نشان دهنده تغییر اطلاعات در بین راه بوده است. نکته ای که در اینجا حایز اهمیت است این است که عدم تفاوت در CRC تولید شده(در گیرنده) با CRC فرستنده ، به معنای عدم دست کاری داده ها در بین راه نمیباشد. به عبارت دیگر احتمال اینکه فردی در وسط راه داده ها را به همراه CRC طوری دست کاری کرده باشد که قابل تشخیص در گیرنده نباشد، وجود دارد.
شکل زیر گویای انجام رمزنگاری و رمزگشایی در پروتکل WEP میباشد:
یک کد CRC قبل از رمز شدن بسته تولید شده است. در گیرنده، بعد از رمزگشایی اطلاعات، یک CRC از اطلاعات بدست آمده تولید میشود و با CRC کد فرستنده مقایسه میشود(که البته این قسمت در شکل دیده نمیشود، اگر یادمان ماند، سعی میشود که این قسمت نیز انجام شود). اگر تفاوتی بین دو کد باشد، نشان دهنده تغییر اطلاعات در بین راه بوده است.
انشالله در این بخش میخواهیم در مورد ضعف های امنیتی WEP بحث کنیم. WEP به خاطر ضعف هایی که دارد در سال 2004 جای خود را به پروتکل WPA داد. در ادامه به بررسی بعضی از این ضعف ها میپردازیم:
از آنجا که برای ساخت کلید، از یک رشته رندم با عنوان IV استفاده میشود، یک نفوذگر میتواند با تحلیل IV ها و بسته های رمزشده نسبتا زیادی به کلید اصلی دست پیدا کند. حملات اولیه علیه پروتکل WEP بر این قسم بودند. البته این حمله، زمان زیادی برای شکستن کلید نیاز دارد، ولی بالاخره یک ضعف محسوب میشود.
این مشکل زمانی حاد میشود که کارت شبکه از IVهای تکراری یا مشابه هم استفاده کند و این بدین معنا میباشد که هر چند لحظه با یک IV تکراری یک کلید رمزنگاری ساخته میشود.
در قسمت های قبل گفتیم که WEP، CRC یک بسته را به صورت رمز نشده میفرستد. یک نفوذگر از این خصوصیت میتواند بدین صورت عمل کند که محتوای بسته (غیر از CRC) را عوض کند و CRC را نیز حدس بزند، سپس به عنوان یک بسته جدید به AP بفرستد و متظر عکس العمل آن باشد. این روش، در حمله ای تحت عنوان ChopChop به کار رفته است که شاید در قسمت حمله به شبکه های وایرلس آن را مطرح کردیم.
یکی از ابتدایی ترین ضعف های موجود در شبکه های وایرلس استفاده از کلید های مشابه توسط کاربران به مدت طولانی میباشد. این ضعف بیشتر به خاطر نبود یک مکانیزم مدیریت کلید رخ میدهد. برای مثال اگر کلید یک ایستگاه کاری بنا به هر دلیلی به سرقت برود، از آنجا که بیشتر ایستگاه های کاری از مشابه کلید لو رفته استفاده میکنند، عملا بیشتر این ایستگاههای کاری نا امن میباشند.
استفاده از 24 بیت IV، باعث میشود که بعد از مدتی، Keystreamهای تکراری تولید شوند(البته اگر کلید اصلی تغییر پیدا نکند) و این باعث آسان شدن رمزگشایی توسط یک مهاجم میشود.
در جدول زیر برخی دیگر از ضعف های امنیتی WEP به صورت خلاصه آورده شده است.
|
ردیف |
آسیب پذیری |
توضیح |
|
1 |
کوتاه بودن Key |
یک کلید 40 بیتی برای هر سیستمی ناکافی میباشد، به طور معمول کلید با اندازه بزرگتر از 80 بیت یک کلید قوی محسوب میشود، چرا که کلیدهای زیر 80 بیت به راحتی با حمله Brute-Force شکسته میشوند.[2] |
|
2 |
عدم تغییر کلید به صورت اتوماتیک و پریودیک |
کلید باید به صورت اتوماتیک و پریودیک تغییر پیدا کند تا از حملههای مبتنی بر Brute-Force در امان باشد. |
|
3 |
RC4 به صورت نادرست در WEP استفاده شده است. |
24 بیت از کلید در WEP آشکار سازی شده است، و این به نوعی ضعف محسوب میشود. بعضی دیگر از Applicationهای RC4 قسمتی از کلید را آشکار سازی نمیکنند و همچنین در هر پکت آنرا ریستارت نیز نمیکنند. |
|
4 |
Integrity بسته بسیار ضعیف میباشد. |
CRC32 و سایر کدهای بلوک خطی برای Integrity بسیار ناکافی میباشند. اصلاح پیغام در این روش، ممکن میباشد. کدهای خطی برای حفاظت از حملههایی که روی Integrity دادهها صورت میگیرد، بسیار ناکافی میباشد. |
|
5 |
عدم انجام تصدیق کاربر |
در این روش، به جای اینکه کاربر مورد تصدیق قرار بگیرد، دستگاهش مورد تصدیق قرار میگیرد، که مثلا با آدرس MAC این کار انجام میگیرد. هر کسی که بتواند یک دستگاه تصدیق شده را جعل کند، میتواند به این شبکه وصل شود. |
|
6 |
احراز هویت فعال نمیباشد، بلکه فقط شناسایی SSID اتفاق می افتد. |
شناسایی بر پایه سیستم، در سیستم های وایرلس، بسیار آسیب پذیر میباشد. |
|
7 |
تدبیر ساده احراز هویت کلید مشترک با Challenge-Response. |
یک حمله به احراز هویت Challenge-Response، حمله Man-In-The-Middle میباشد. یک احراز هویت دوطرفه لازم است تا مطمئن شویم که هم کاربر، کاربری مشروع است و هم شبکهای که کاربر به آن وصل میشود، شبکهای مشروع است. |
انشالله بحث و تحقیق خواهد شد.
[1] - Initialization Vector
[2] - اگر بخواهیم به صورت عملی این را نشان دهیم، میتوانیم به شکستن تابع MD5 برای کلیدهای زیر 8 کلمهای(هر کلمه، دارای 8 بیت میباشد)، اشاره میکنیم. یک رشته 7 بیتی مانند «Morteza» را با تابع MD5 رمز میکنیم(یا هش میکنیم)، سپس با استفاده از ابزارهای موجود، از هش این عبارت به خودِ کلمهی «Morteza» میرسیم. سایت http://md5.rednoize.com ما را در رسیدن به این هدف کمک میکند، هش عبارت «Morteza» را که «251befc74613a58d21fc39be6cfc10d1» میباشد، در قسمت Enter your MD5 Hash here … وارد کرده، سپس اینتر میزنیم، سپس مشاهده میکنیم که کلمه «Morteza» به عنوان جواب نشان داده میشود.
I'm It's me, m.m.
یادمان باشد که خدا می بیند.
همین
