امنیت وب

1. امنیت وب مبتنی بر فصل 14 از کتاب Network Security, Principles and Practice,2nd Ed. ویرایش شده توسط: حمید رضا شهریاری http://www.fata.ir http://mehr.sharif.edu/~shahriari

2. فهرست مطالب • خطرات تهدیدكننده وب • روشهای مختلف تامین امنیت وب • SSL • TLS • SET

3. خطرات تهدیدكننده وب • با توجه به سادگی و گستردگی استفاده از مرورگرها و خدمات وب و راه اندازی سرورها، امنیت وب از پیچیدگی بالایی برخوردار است. • نمونه ای از خطرات متداول: • حمله به وب سرورها • تهدید اعتبار برنامه های تجاری مهم • وجود كاربران عام و ناآشنا به خطرات امنیتی • دسترسی به حریم خصوصی افراد و آزار و اذیت آنها

4. Threats on the Web Sharif Network Security Center

5. روشهای مختلف تامین امنیت وب • استفاده از IPSec . مزایا : • همه منظوره • شفاف از دید كاربران لایه بالاتر • سربار اضافی استفاده از IPSec با استفاده از فیلترینگ قابل حل است • استفاده از SSL/TLS • شفاف از دید Applicationها • پشتیبانی مرورگرهایی مانند Netscape و IE و نیز بسیاری از وب سرورها • سرویسهای امنیتی وابسته به كاربرد خاص • SET

6. Web Security Approaches Sharif Network Security Center

7. Netscape Support for SSL Sharif Network Security Center

8. SSL - تاریخچه • July, 1994 • شرکت Netscape طراحی SSL 1.0 را انجام داد. • این نسخه هیچگاه منتشر نشد! • Dec, 1994 • مرورگر Netscape همراه با SSL 2.0 به بازار عرضه شد. • آسیب پذیر بود. کمتر از 1 ساعت می شد به آن نفوذ کرد. • محدودیت استفاده از کلیدهای 40 بیتی در خارج آمریکا

9. SSL– تاریخچه(...ادامه) • July, 1995 • مایکروسافت نسخه جدیدی از IE را به بازار عرضه کرد که از SSL پشتیبانی می کرد. • پشتیبانی از مدهای کاری جدید و افزایش طول کلیدهای قابل استفاده • Nov, 1995 • شرکت Netscape توصیف SSL 3.0 را منتشر کرد • با تغییرات و جهش عمده نسبت به نسخه های قبلی همراه بود • ضمن اینکه نسبت به نسخه SSL v2.0، Backward Compatible بود

10. SSL– تاریخچه(...ادامه) • May, 1996 • IETF گروه کاری TLS را تشکیل داد و مسئولیت پاسخگویی به مشکلات قرارداد SSL را برعهده گرفت. • Jan, 1999 • TLS 1.0 بطور رسمی همراه با RFC 2246 به بازار عرضه شد. • در واقع همان SSL v3.1 بود که به دلایل تجاری تغییر نام داده بود.

11. SSL • لایه امنیتی در بالای لایه انتقال • ارائه شده توسط شرکت Netscape و نسخه 3 آن نسخه استاندارد اینترنت می باشد • سرویس قابل اطمینان انتها به انتها(end to end) و مبتنی بر TCP • پروتكل آن در دو لایه پیاده سازی می شود

12. SSL - معماری • لایه اول بالای لایه انتقال و لایه دوم در لایه کاربرد • لایه اول شامل پروتکل Record و لایه دوم مربوط به سرویسهای مدیریتی بوده و شامل پروتکلهایزیر می شود

13. SSL– پروتكلها • SSL Record Protocol : دو سرویس برای SSL فراهم می كند: • محرمانگی : • با استفاده از یك كلید متقارن مخفی كه در پروتكل Handshake به اشتراك گذاشته شده است. • استفاده از یكی از الگوریتمهای IDEA، RC2-40،DES-40، DES، 3DES، Fortezza، RC4-40، RC4-128 • تمامیت پیغام • تولید MAC با استفاده از کلید متقارن مخفی • استفاده از SHA-1 یا MD5 • وظیفه تولید و توزیع کلیدهای متقارن برای انجام رمزگذاری مرسوم و نیز محاسبه MAC برعهده پروتکل handshake است

14. Netscape’s Ciphersuites Sharif Network Security Center

15. Record Protocol Operation Sharif Network Security Center

16. SSL– پروتكلها اعمال انجام شده در پروتكل Record • قطعه بندی: تولید بلاكهای به طول 214یا كمتر . • فشرده سازی : اختیاری و بدون از دست رفتن داده. • تولید MAC : مشابه HMAC و روی ورودی زیر انجام می گیرد: • (محتوای بلاك، طول بلاك، نوع فشرده سازی، شماره سریال) • الگوریتم تولید کد احراز هویت MD5 یا SHA-1 می باشد. • رمزنگاری : استفاده از رمز بلاكی یا نهری. • اضافه كردن سرآیند : به ابتدای بلاك رمزشده می چسبد و شامل موارد زیر است: (نوع محتوا، نسخه اصلی SSL، نسخه فرعی SSL، طول داده فشرده شده) نوع محتوا(Content Type) بیان كننده پروتكل استفاده كننده از این سرویس در لایه بالاتر می باشد

17. SSL Record Format Sharif Network Security Center

18. SSL– پروتكلها پروتكل Change Cipher Spec: • یكی از 3 پروتكل لایه دوم SSL كه از پروتكل Record استفاده می كنند. • شامل 1 بایت می باشد • منجر به نوشته شدن مشخصات رمزنگاری معلق(pending) بجای مشخصات فعلی می شود تا در اتصال جاری مورد استفاده قرار گيرد.

19. SSL– پروتكلها پروتكل SSL Alert: • هشدارها و خطاهای مربوط به SSL را به طرف مقابل منتقل می كند • شدت خطای پیش آمده : Warning or Fatal • مانند بقیه داده های SSL فشرده سازی و رمزنگاری می شود. • نمونه خطاها : unexpected message, bad record mac, decompression failure, handshake failure

20. SSL– پروتكلها پروتكل SSL Handshake • پیش از انتقال هر نوع داده ای تحت SSL انجام می شود. • با استفاده از آن کارفرما و کارگزار می توانند : • همدیگر را شناسایی كنند • الگوریتم های رمزنگاری، توابع درهم ساز مورد استفاده و کلیدهای رمزنگاری متقارن و نامتقارن را رد و بدل كنند.

21. قرارداد توافق – فاز Hello پروتكل SSL Handshake شامل 4 فاز اصلی زیر می باشد • مشخص كردن قابلیتهای رمزنگاری دو طرف • احراز هویت کارگزار به کارفرما و مبادله كلیدهای آن • احراز هویت کارفرما به کارگزار و مبادله كلیدهای آن • جایگزینی پارامترهای رمزنگاری جدید به جای قبلی و خاتمه توافق

22. Sharif Network Security Center SSL Handshake Protocol

23. Sharif Network Security Center

24. قرارداد توافق – فاز Hello ارسال پیغام Hello توسط کارفرما(آغازگر جلسه) • پیشنهاد نسخه قرارداد: آخرین نسخه پشیبانی شده توسط کارفرما • پیشنهاد الگوریتم های مناسب و روش تبادل کلید آنها • پیشنهاد مکانیزم فشرده سازی مناسب • انتخاب نسخه و الگوریتم های مورد قبول کارگزار • کارگزار بررسی می کند که آیا این پیشنهاد قابل قبول است یا نه؟

25. قرارداد توافق – فاز تبادل کلید • ارسال گواهی کارگزار برای کارفرما • همراه با کلید عمومی(RSA) یا پارامترهای DH • تولید و ارسال کلید سری • کارفرما کلید سری را تولید کرده و برای کارگزار می فرستد • یا این که هر دو با استفاده از پارامترهای DH کلید سری را محاسبه می کنند.

26. قرارداد توافق – فاز خاتمه • فعال کردن قرارداد تغییر مشخصات رمز • کارفرما قرارداد تغییر مشخصات رمز را فعال کرده و برای کارگزار می فرستد. • کارگزار نیز قرارداد تغییر مشخصات رمز را فعال کرده و ارسال می کند. • پایان • ارسال پیغام پایانی • آغاز تبادل اطلاعات به صورت محرمانه و با پارامترهای جدید

27. Handshake Payload and Types Sharif Network Security Center

28. SSL– نتیجه گیری • SSL نیازهای امنیتی زیر را فراهم می کند • محرمانگی • رمزنگاری متقارن • تمامیت داده • کد احراز هویت داده • احراز هویت • استاندارد x.509 • امروزه مهمترین کاربرد SSL در قرارداد HTTPS می باشد.

29. TLS(Transport Layer Security) • یك استاندارد از IETF • به دنبال ایجاد یك نسخه استاندارد اینترنتی از SSL می باشد • بسیار شبیه SSL نسخه 3 بدون در نظرگرفتن تفاوتهای جزئی زیر: • بهره گیری از HMAC واقعی در محاسبه MAC(استفاده از عملگر XOR) • تابع تولید اعداد تصادفی همان HMAC است • در TLS کد خطای no-certificate قابل قبول نیست • الگوریتم Fortezza از الگوریتمهای توزیع كلید و رمزگذاری پیغام حذف شده

30. SET: Secure Electronic Transactions

31. SET: Secure Electronic Transactions • عبارت است از مجموعه ای از پروتكلها و فرمتها كه امكان استفاده از كارتهای اعتباری عادی در شبكه های گسترده را فراهم می سازد(معرفی شده توسط MasterCard&Visa) • سه سرویس زیر را فراهم می سازد: • فراهم آوردن یك كانال ارتباطی امن بین افراد درگیر در یك انتقال مالی(transaction). • استفاده از گواهی های قابل اعتماد X.509v3 • محافظت از حریم خصوصی افراد: اطلاعات فقطبرای اشخاصی كه به آن نیاز دارند، قابل رویت است

32. SET نیازمندیهای تجاری و فنی SET • حفظ محرمانگی اطلاعات پرداخت و سفارش خرید • احراز هویت صاحب كارت اعتباری • حفظ تمامیت كلیه داده های منتقل شده • استفاده از بهترین ابزارهای امنیتی(پروتكلها و الگوریتمها) و نیز بهترین تكنیكهای طراحی سیستم. • عدم وابستگی به وجود یا عدم وجود مكانیسمهای امنیتی لایه انتقال (مانند IPSec یا SSL) • به وجود آوردن امکان عملکرد متقابل بین نرم افزارها و سرویس دهندگان شبكه: مستقل بودن SET از بستر نرم افزاری یا سخت افزاری

33. SET قابلیت های كلیدیSET • محرمانگی اطلاعات : شماره كارت اعتباری خریدار از دید فروشنده مخفی می ماند(استفاده از DES) • حفظ جامعیت داده ها : با استفاده از امضاء رقمی RSA، كد درهم SHA-1و HMAC • احراز هویت دارنده كارت : امضاء رقمی با گواهی X.509v3 • احراز هویت فروشنده : امضاء رقمی با گواهی X.509v3

34. SET Components Sharif Network Security Center

35. SET افراد و نهادهای درگیر عبارتند از : • صاحب كارت(Card Holder): كاربر صاحب كارت اعتباری • فروشنده(Merchant): فرد یا سازمانی كه قصد فروختن كالای خود را از طریق اینترنت دارد. • صادركننده كارت(Issuer) : موسسه مالی مانند بانك كه برای كاربران كارت صادر می كند و مسئول پرداخت كاربر در مقابل خرید او می باشد

36. SET افراد و نهادهای درگیر در سیستم (ادامه) • موسسه حسابرسی مالی(Acquirer): یک موسسه مالی موظف با وظایف زیر: • باز کردن حساب برای فروشنده • تعیین سقف اعتبار کارتها و فعال بودن آنها • واریز مبلغ دریافت شده از طریق کارت به حساب فروشنده • دروازه پرداخت (Payment Gateway): جهت پردازش پیامهای پرداختی و فروشنده توسط Acquirer یا فرد سوم • مرجع صدور گواهی(CA) : صادركننده گواهی X509 برای صاحبان کارتها، فروشنده ها و دروازه های پرداخت

37. SET مراحل انتقال مالی • افتتاح حساب توسط مشتری: حساب كارت اعتباری در بانكی كه SET را پشتیبانی می كند • دریافت گواهی توسط مشتری: گواهی X509 كه به امضای بانك رسیده باشد. • دریافت گواهی توسط فروشنده: یكی برای امضاء پیام و دیگری برای توزیع كلید • ارسال سفارش خرید: از طرف مشتری برای فروشنده • تایید هویت فروشنده از جانب مشتری : از روی گواهی ارسال شده

38. SET مراحل انتقال مالی • تایید سفارش و ارسال مشخصات پرداخت : مشتری اطلاعات سفارش و پرداخت خود كه شامل گواهی او نیز می شود را برای فروشنده می فرستد. اطلاعات پرداخت به صورت رمزشده فرستاده می شوند و برای فروشنده قابل فهم نیستند. • تقاضای اجازه پرداخت از جانب فروشنده : فروشنده اطلاعات پرداخت را برای دروازه پرداخت می فرستد. “آیا كارت اعتباری خریدار به اندازه خرید جاری موجودی دارد؟”

39. SET مراحل انتقال مالی • تایید سفارش از جانب فروشنده : در صورتی كه پاسخ سوال فوق مثبت باشد! • ارسال اجناس یا فراهم آوردن خدمات برای مشتری • تقاضای پرداخت از جانب فروشنده: تقاضای انتقال مبلغ مورد نظر از حساب مشتری به حساب فروشنده از جانب دروازه پرداخت

40. SET امضاء دوبل(Dual Signature) مكانیسمی برای اتصال پیغامهایی كه برای گیرنده های مختلف فرستاده می شوند. مثال: • اطلاعات سفارش(OI) كه برای فروشنده و اطلاعاتپرداخت (PI) كه برای بانك فرستاده می شوند. • فروشنده نباید شماره كارت اعتباری را بداند • بانك نباید جزییات سفارش خرید را بداند • باید بتوان ثابت كرد كه پرداخت فعلی متعلق به سفارش خرید فعلی و نه احیانا سفارشهای قبلی یا بعدی است. با استفاده از مكانیسم Dual Signature می توان جلوی سوءاستفاده های احتمالی فروشنده را گرفت

41. Construction of Dual Signature Sharif Network Security Center

42. SET قرارداد SET عموما از سه تراکنش اصلی تشکیل می شود • سفارش خرید(Purchase Request) • اجازه پرداخت(Payment Authorization) • دریافت پرداخت(Payment Capture)

43. SET درخواست خرید(Purchase Request): طی آن 4 پیام رد و بدل می شود: • درخواست اولیه از طرف خریدار به فروشنده(1 از 4) • شامل نوع كارت اعتباری، شناسه یكتا(ID) مربوط به این تقاضا و nonce. • پاسخ اولیه از طرف فروشنده به خریدار(2 از 4) • شامل nonce مشتری، nonce جدید و ID مرحله قبل كه به امضای فروشنده رسیده اند، به علاوه گواهی فروشنده و گواهی دروازه پرداخت

44. SET درخواست خرید(ادامه ...) • درخواست خرید از طرف خریدار به فروشنده(3 از 4) شاملِِ : • اطلاعات مربوط به سفارش كه باید به فروشنده برسد • اطلاعات پرداخت كه باید بدست بانك برسد(از طریق فروشنده) • گواهی کلید عمومی خریدار برای امضا • پاسخ خرید از طرف فروشنده به خریدار(4 از 4) • گواهی خریدار • اطلاعات پرداخت جهت اجازه و تایید كارت به بانك ارسال می شود • پاسخ خرید جهت تایید خرید بصورت امضاشده به خریدار ارسال می شود

45. Purchase Request – Customer Sharif Network Security Center

46. Purchase Request – Merchant Sharif Network Security Center

47. SET اجازه دروازه پرداخت(Payment Gateway Authorization) این مرحله جهت اطلاع فروشنده از اعتبار خریدار و این كه پرداخت حتما صورت خواهد پذیرفت، بین فروشنده و دروازه پرداخت انجام می شود. شامل دو پیام می باشد:

48. SET • درخواست اجازه از طرف فروشنده به دروازه پرداخت: • شامل اطلاعات خریدار(PI، امضای دوگانه و OIMD)، اطلاعات مربوط به اجازه(شامل اطلاعات ID و غیره) و گواهیهای خریدار و فروشنده • پاسخ اجازه از طرف دروازه پرداخت به فروشنده • شامل اطلاعات مربوط به اجازه(رمزشده توسط دروازه پرداخت) اطلاعات مربوط به دریافت پرداختی(capture token) توسط فروشنده و گواهی امضای دروازه پرداخت. • اطلاعات capture token برای مرحله بعد مورد نیاز است.

49. SET دریافت پرداخت(payment capture) فروشندهپس از ارسال جنس و یا سرویس می تواند هزینه سرویس خود را از كارت اعتباری خریدار دریافت كند. این كار طی دو پیام انجام می شود:

50. SET • درخواست دریافت (capture request) از طرف فروشنده به دروازه پرداخت: • شامل مبلغ، ID و capture token كه رمز و امضاء شده اند و نیز گواهیهای امضاء و توزیع كلید فروشنده • در صورت تایید، از طریق شبكه خصوصی درخواست به بانك ارسال شده و مبلغ از حساب خریدار به فروشنده منتقل می شود • پاسخ دریافت (capture response) از طرف دروازه پرداخت به فروشنده • در صورت انتقال مبلغ پاسخ مناسب به فروشنده داده می شود