امنیت وب

امنیت وب

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

اسلاید 2: 2فهرست مطالبخطرات تهدیدكننده وبروشهای مختلف تامین امنیت وبSSLTLSSET

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

اسلاید 4: Sharif Network Security Center4Threats on the Web

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

اسلاید 6: Sharif Network Security Center6Web Security Approaches

اسلاید 7: Sharif Network Security Center7Netscape Support for SSL

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

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

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

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

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

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

اسلاید 14: Sharif Network Security Center14Netscape’s Ciphersuites

اسلاید 15: Sharif Network Security Center15Record Protocol Operation

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

اسلاید 17: Sharif Network Security Center17SSL Record Format

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

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

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

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

اسلاید 22: Sharif Network Security Center22SSL Handshake Protocol

اسلاید 23: Sharif Network Security Center23

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

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

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

اسلاید 27: Sharif Network Security Center27Handshake Payload and Types

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

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

اسلاید 30: 30SET: Secure Electronic Transactions

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

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

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

اسلاید 34: Sharif Network Security Center34SET Components

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

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

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

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

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

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

اسلاید 41: Sharif Network Security Center41Construction of Dual Signature

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

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

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

اسلاید 45: Sharif Network Security Center45Purchase Request – Customer

اسلاید 46: Sharif Network Security Center46Purchase Request – Merchant

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

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

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

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

اسلاید 51: 51 پایان؟