Mã hóa và an ninh mạng ( Chapter 17)

Cryptography and Network SecurityChapter 17Fourth Editionby William Stallings Lecture slides by Lawrie BrownChương 17: An toàn WebChapter 17 – Web SecurityUse your mentality Wake up to reality —From the song, "I've Got You under My Skin“ by Cole PorterAn toàn Web - Web SecurityWeb được sử dụng rộng rãi bởi các công ty, chính phủ và cá nhânNhưng Internet và Web có những lỗ hổng lớnCó nhiều mối đe doạ:Tính toàn vẹnBảo mậtTừ chối dịch vụXác thựcCần bổ sung cơ chế bảo mậtSecurity facilities in the TCP/IP protocol stackSSL (Secure Socket Layer)Dịch vụ an toàn tầng vận chuyểnBan đầu được phát triển bởi NetscapePhiên bản 3 thiết kế cho đầu vào công cộngSau đó trở thành chuẩn Internet được biết đến như TLS (an toàn tầng vận chuyển)Sử dụng TCP để cung cấp dịch vụ đầu cuối đến cuối tin cậySSL có 2 tầng thủ tụcSSL ArchitectureKiến trúc SSL - SSL ArchitectureKết nối SSL:Tạm thời, đầu cuối đến đầu cuối, liên kết trao đổiGắn chặt với 1 phiên SSL Phiên SSL:Liên kết giữa người sử dụng và máy chủĐược tạo bởi thủ tục HandShake ProtocolXác định một tập các tham số mã hoáCó thể chia sẻ bởi kết nối SSL lặpDịch vụ thủ tục bản ghi SSLSSL Record Protocol ServicesTính toàn vẹn của bản tin:Sử dụng MAC với khoá mật chia sẻGiống như HMAC nhưng với bộ đệm khácBảo mật:Sử dụng mã đối xứng với khoá chung xác định bởi thủ tục HandShake.IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128Bản tin được nén trước khi mãSSL Record Protocol OperationSSL Record FormatSSL Record Protocol PayloadThủ tục thay đổi đặc tả SSL SSL Change Cipher Spec ProtocolMột trong 3 giao thức chuyên biệt của SSL sử dụng thủ tục bản ghi SSL Mẩu tin đơnBuộc trạng thái treo trở thành hiện thờiNên cập nhật bộ mã đang dùngThủ tục nhắc nhở SSL SSL Alert ProtocolTruyền đi lời nhắc của SSL liên quan cho thành viênNghiêm khắc: Nhắc nhở hoặc cảnh báoNhắc nhở đặc biệt:cảnh báo: mẳu tin không chờ đợi, bản ghi MAC tồi, lỗi giải nén, lỗi Handshake, tham số không hợp lệNhắc nhở: đóng ghi chú, không chứng nhận, chứng nhận tồi, chứng nhận không được hỗ trợ, chứng nhận bị thu hồi, chứng nhận quá hạn, chứng nhận không được biết đến.Nén và mã như mọi dữ liệu SSLThủ tục bắt tay SSL Handshake ProtocolCho phép máy chủ và máy trạm:Xác thực nhauThỏa thuận thuật toán mã hoá và MACThỏa thuận khoá mã sẽ dùngBao gồm một loạt các thông tin:Thiết lập các khả năng an toànXác thực máy chủ và trao đổi khoáXác thực máy trạm và trao đổi khoáKết thúc SSL Handshake Protocol An toàn tầng vận chuyểnTLS (Transport Layer Security)số ký hiệu kích thước bản ghisử dụng HMAC thay cho MAChàm giả ngẫu nhiên tăng độ mậtcó mã ghi chú bổ sungcó một số thay đỏi hỗ trợ mãthay đổi kiểu chứng nhận và thỏa thuận thay đổi bộ đệm và tính toán mãThanh toán điện tử an toànSecure Electronic Transactions (SET)Mã mở và đặc tả an toànBảo vệ thanh toán thẻ tín dụng trên InternetPhát triển năm 1996 bởi Master, Visa CardKhông phải hệ thống trả tiềnLà tập các giao thức và định dạng an toànTrao đổi an toàn giữa các đối tácTin tưởng vì sử dụng X509v3Riêng biệt vì hạn chế thông tin cho người cầnSET ComponentsThanh toán điện tử an toànSET TransactionNgười mua mở tài khoảnNgười mua nhận được chứng nhậnNgười bán có chứng nhận của họNgười mua đặt hàngNgười bán được kiểm chứngĐơn đặt hàng và trả tiền được gửiNgười bán yêu cầu giấy phép trả tiềnNgười bán duyệt đơn đặt hàngNgười bán cung cấp hàng và dịch vụNgười bán yêu cầu trả tiền Chữ ký kép - Dual SignatureNgười mua tạo chữ ký képThông tin đơn đặt OI cho người bán Thông tin trả tiền PI cho ngân hàngKhông bên nào biết chi tiết của người khác Nhưng cần phải biết là họ được kết nốiSử dụng chữ ký kép cho mục đích nàyKý trên bản ghép của OI và PIDS=E(PRc, [H(H(PI)||H(OI))])Dual SignatureYêu cầu trả tiền SET Purchase RequestTrao đổi yêu cầu trả tiền gồm 4 mẩu tin sauKhởi tạo yêu cầu - nhận chứng nhậnKhởi tạo trả lời – ký trả lờiYêu cầu trả tiền - của OI và PITrả lời trả tiền – đơn phúc đápPayment processing Cardholder sends Purchase Request Yêu cầu trả tiền – người bánPurchase Request – MerchantKiểm tra chứng nhận người giữ thẻ bằng chữ ký của CAKiểm tra chữ ký kép bằng cách sử dụng khoá chữ ký công khai của người mua để tin tưởng rằng đơn không bị giả mạo khi truyền và được ký sử dụng chữ ký khoá riêng của người giữ thẻ. Xử lý đơn đặt và gửi tiếp thông tin trả tiền cho cổng trả tiền để xác thực (mô tả sau)Gửi phản hồi trả tiền cho người giữ thẻPayment processing Merchant Verifies Customer Purchase RequestGiấy phép cổng trả tiềnPayment Gateway AuthorizationKiểm chứng mọi chứng nhận Giải mã phong bì điện tử của khối giấy phép và nhận được khoá đối xứng, sau đó giải mã khối giấy phépKiểm tra chữ ký của người bán trên khối giấy phépGiải mã phong bì điện tử khối trả tiền, nhận được khoá đối xứng, sau đó giải mã khối trả tiềnKiểm tra chữ ký kép trên khối trả tiềnKiểm tra rằng, thanh toán ID nhận được từ người bán phù hợp với danh tính trong PI nhận được (không trực tiếp) từ người bánYêu cầu và nhận được giấy phép từ nơi phát hànhGửi trả lời giấy phép cho người bánNhận trả tiềnPayment CaptureNgười bán gửi cho cổng trả tiền yêu cầu nhận trả tiềnCổng kiểm tra yêu cầuSau đó yêu cầu chuyển tiền đến tài khoản người bánThông báo người bán bằng trả lời việc nhận Summaryhave considered:need for web securitySSL/TLS transport layer security protocolsSET secure credit card payment protocols