Bảo mật và an toàn thông tin trong thương mại điện tử

mật trong cấu trúc của giao thức TCP/IP Một giải pháp nữa là cải tiến cơ chế bảo mật trên giao thức TCP, một trong những ý tƣởng dẫn dắt đến sự ra đời của giao thức Secure Sockets layer (SSL) và Transprot layer Security (TLS). Ở tầng này, có hai sự lựa chọn là SSL hoặc là TLS, SSL đƣợc cung cấp nhƣ là một giao thức hỗ trợ nên có hoàn toàn có thể bảo mật bất kì giao thức ứng dụng nào đƣợc xếp trên lớp TCP một cách trong suốt.Ngoài ra, SSL còn có thể đƣợc gắn vào các ứng dụng nhƣ một gói đặc biệt, ví dụ nhƣ các trình duyệt IE và Netscape đều đƣợc trang bị SSL, các Web server cũng đều đã đƣợc bổ sung giao thức này. Một đặc trƣng khác của các dịch vụ bảo mật là việc chúng đƣợc gắn bên trong các dịch vụ bảo mật , hình 3.1c là một ví dụ cho kiến trúc dạng này. Sự thay đổi mới này thể hiện ở chỗ các dịch vụ có thể thích úng với các thành phần cần thiết nhất định của úng dụng. Trong bối cảnh chung của vấn đề bảo mật úng dụng web, SET(Secure Electrolic Transaction) là một ví dụ tiêu biểu cho cách tiếp cận này. 5.2 SSL và TLS Nhƣ đã đề cập ở trên, hai giao thức bảo mật quan trọng lớp vận chuyển (Layer Transport) có tầm quan trọng rất lớn đối với sự bảo mật của các trình úng dụng trên web đó là SSL và TLS . Cho đến nay, đã có 3 phiên bản của SSL:  SSL 1.0: Đƣợc sử dụng nội bộ chỉ bởi Netcape Communications 1.0. Nó chứa một số khuyết điểm nghiêm trọng và không bao giờ đƣợc tung ra bên ngoài. HTT P FTP SMTP 00 TCP IP/IPSPec SMTP HTTP TCP IP TCP Kerbero s S/MINE PGP SET IP HTT P SMT P FPT SSL or TLS UDP Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 61 SSL Ghandshaks protocol SSl change Cipher Spec protocol SSL, Aliert protocol HTTR SSl Record Layer TCP LDAP cac  SSL 2.0: Đƣợc kết nhập vào Netscape Communications 1.0 đến 2.x. Nó có một số điểm yếu liên quan đến sự hiện thân cụ thể của cuộc tấn công của đối tƣợng trung gian.Trong một nỗ lực nhằm dùng sự không chắc chắn của công chúng về bảo mật của SSL. Microsoft cũng đã giớ thiệu giao thức PCT (Private Communication Technology) cạnh trang trong lần tung ra Internet Explorer đầu tiên của nó vào năm 1996.  SSL 3.0: Netscape Communications đã phản ứng lại sự thách thức PCT của Microsoft bằng cách giới thiệu SSL 3.0. Vốn giải quyết các vấn đề trong SSL 2.0 và thêm một số tính năng mới. Vào thời điểm này Microsoft nhƣợng bộ và đồng ý hỗ trợ trong tất cả các phiên bản phần mềm dựa vào TCP/IP của nó. 5.2.1 Kiến trúc của SSL Cấu trúc của SSL và giao thức của SSL tƣơng ứng đƣợc minh họa trong hình 1.1. Theo hình này, SSL ám chỉ một lớp ( bảo mật) trung gian giữa lớp vận chuyển (Transport Layer) và lớp ứng dụng (Applycation Layer). SSL đƣợc xếp lớp lên trên một dịch vụ vận chuyển định hƣớng nối kết và đáng tin cậy, chẳng hạn nhƣ đƣợc cung cấp bởi TCT. Về khả năng nó có thể cung cấp các dịch vụ bảo mật cho các giao thức ứng dụng tùy ý dựa vào TCP chứ không phải chỉ HTTP. Thực tế, một ƣu điểm chính của các giao thức bảo mật lớp vận chuyển (Transport Layer) nói chung và giao thức SSL nói riêng là chúng độc lập với ứng dụng theo nghĩa là chúng có thể đƣợc sử dụng để bảo vệ bất kỳ giao thức ứng dụng đƣợc xếp lớp lên trên TCP một cách trong suốt. Hình 2.2 minh họa một số giao thức ứng dụng điểm hình bao gồm NSIIOP, HTTP, FTP, Telnet, IMAP, IRC, POP3. Tất cả chúng có thể đƣợc bảo vệ bằng cách xếp lớn chúng trên SSL (mẫu tự S đƣợc thêm vào trong các kỳ ghép giao thức tƣơng ứng chỉ định việc sử dụng SSL). Tuy nhiên chú ý rằng SSL có môt định hƣớng Client- sever mạnh mẽ và thật sự không đáp ứng các yêu cầu của các giao thức ứng dụng ngang hàng. HTTP SMTP Application Layer …………………………………………………………………………………… ………… Transport Layer Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 62 IP ……………………………………………............................................................. .............. Internet Layer …………………………………………………………………………………… ………... Network Layer Hình 18: Kiến trúc của SSL Tóm lại, giao thức SSL cung cấp sự bảo mật truyền thông vốn có 3 đặc tính cơ bản 1. Các bên giao tiếp (nghĩa là Client và server) có thể xác thực nhau bằng cách sử dụng mật mã khóa chung. 2. Sự bí mật của lƣu lƣợng dữ liệu đƣợc bảo vệ vì nối kết đƣợc mã hóa trong suốt sau khi một sự thiết lập quan hệ ban đầu và sự thƣơng lƣợng khóa session đã xảy ra. 3. Tính xác thực và tính toàn vẹn của lƣu lƣợng dự liệu cũng đƣợc bảo vệ vì các thông báo đƣợc xác thực và đƣợc kiểm tra tính toán toàn vẹn một cách trong suốt bằng cách sử dụng MAC. Tuy nhiên điều quan trọng cần lƣu ý là SSL không ngăn các cuộc tấn công phân tích lƣu lƣợng.ví dụ: bằng cách xem xét các địa chỉ IP nguồn và đích không đƣợc mã hoá và các số cổng TCP, hoặc xem xét lƣợng dữ liệu đƣợc truyền, một ngƣời vẫn phân tích lƣu lƣợng vẫn có thể xác định các bên nào dang tƣơng tác, các loại dịch vụ nào đang đƣợc sử dụng, và đôi khi ngay cả khi dành đƣợc thông tin về các mối quan hệ doanh nghiệp hoặc cá nhân. Hơn nữa SSL không ngăn các cuộc tấn công có định hƣớng dựa vào phần thực thi TCP chẳng hạn nhƣ các cuộc tấn công làm tràn ngập TCP SYN hoạc cƣỡng đoạt sesion. Để sử dụng sự bảo vệ của SSL cả client lẫn server phải biết rằng phía bên kia đang sử dụng SSL. Nói chung có ba khả năng giải quyết vấn đề này : 1. Sử dụng các sổ cổng chuyên dụng đƣợc dành riêng bởi internet asigned numbers Authority (IANA) .Trong trƣờng hợp này một số cổng riêng biệt phải đƣợc gán cho mọi iao thức ứn dụng vốn sử dụng SSL. 2. Sử dụng số cổng chuẩn cho mọi giao thức ứng dụng và để thƣơng lƣợng các tuỳ chọn bảo mật nhƣ là một phần của giao thức ứng dụng . 3. sử dụng một tuỳ chọn TCP để thƣơng lƣợng việc sử dụng một giao thức bảo mật, chẳng hạn nhƣ SSL trong suốt giai đoạn thiết lập nối kểt TCP thông thƣờng. Sự thƣơng lƣợng dành riêng cho ứng dụng của các tùy chọn bảo mật (nghĩa là khả năng thứ hai) coá khuyết điểm là đòi hỏi mọi giao thức ứng dụng đƣợc chỉnh sửa để hiểu tiến trình thƣơng lƣợng. Ngoài ra, việc xác định một tuỳ chọn TCP (nghĩa là khả năng thứ 3) là một giải pháp tốt, nhƣng nó không đƣợc Network Access Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 63 thảo luận nghiêm túc cho đến bây giờ. Thực tế, các số cổng riêng biệt đã đƣợc dành riêng và đƣợc gán bởi IANA cho mọi giao thức ứng dụng vốn có thể chạy trên SSL hoặc TLS (nghĩa là khả năng thứ nhất). Tuy nhiên, háy chú ý việc sử dụng các số cổng riêng biệt cũng có khuyết điểm là đòi hỏi hai nối kết TCP nếu client không biết những gì mà server hỗ trợ. Trƣớc tiên, client phải nối kết với cổng an toàn và sau đó với cổng không an toàn và ngƣợc lại. Rất có thể các giao thức sau này sẽ huỷ bỏ phƣơng pháp này và tìm khả năng thứ hai. Ví dụ, SALS (Simple Authentication và Security Layer) xác định một phù hợp để thêm sự hỗ trợ xác thực vào các giao thức ứng dụng dựa vào kết nối. Theo thông số kỹ thuật SALS, việc sö dụng các cơ chế xác thực có thể thƣơng lƣợng giữa client và server của một giao thức ứng dụng đã cho. Sè cæng ®•îc g¸n bëi IANA cho các giao thức ứng dụng vốn vốn chạy trên SSL/TLS đƣợc tóm tẳt trong bảng 2.1. Ngày nay, ”S” chØ định việc sử dụng SSL đƣợc thêm (hậu tố) nhất quán vào các từ ghép của các giao thức ứng dụng tƣơng ứng (trong một số thuật ngữ ban đầu, S đƣợc sử dụng và đƣợc thêm tiền tố một cách không nhất quán và một số từ ghép). Bảng 2.1 : Các số cổng đƣợc gán cho các giao thức ứng dụng chạy trên TLS/SSL Từ khoá Cổng Mô tả Nsiiop 261 Dịch vụ tên IIOP trên TLS/SSL Https 443 HTTP trên TLS/SSL Smtps 465 SMTP trên TLS/SSL Nntps 563 SMTP trên TLS/SSL Ldaps 636 LDAP trên TLS/SSL Ftps-data 989 FTP (dữ liệu) trên TLS/SSL Ftps 990 FTP (Điều khiển) trên TLS/SSL Tenets 992 TELNET trên TLS/SSL Imaps 994 INC trên TLS/SSL Pop3s 995 POP3 trên TLS/SSL Nói chung, một session SSL có trạng thái và giao thức SSL phải khởi tạo và duy trì thông tin trạng thái ở một trong hai phía của sesion. Các phần tử thông tin trạng thái sesion tƣơng ứng bao gồm một session ID, một chứng nhận ngang hàng, một phƣơng pháp nén, một thông số mật mã, một khoá mật chính và một cờ vốn chỉ định việc sesion có thể tiếp tục lại hay không, đƣợc tóm tát trong bảng 2.2. Một session SSL có thể đƣợc sử dụng trong một số kết nối và cácthành phần thông tin trạng thái nối kết tƣơng ƣng đƣợc tóm tắt trong bảng 2.3 .chúng bao gồm các tham số mật mã, chẳng hạn nhƣ các chuỗi byte ngẫu nhiên server và client các khoá mật MAC ghi server và client, các khoá ghi server và client, một vector khởi tạo và một số chuỗi. Ở trong hai trƣờng hợp, điều quan träng cÇn lƣu ý là các phía giao tiếp cÇn sử dụng nhiều session SSL đồng thời và các session có nhiều nối kết đồng thời Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 64 Bảng 2.2 : Các thành phần thông tin trạng thái Session SSL Thành phần Mô tả Session ID Định dạng đƣợc chọn bởi server để nhận dạng một trạng thái session hoạt động hoặc có thể tiếp tục lại. Peer certificate Chứng nhận X.509 phiên bản 3 của thực thể ngang hàng. Compression method Thuật toán dùng để nén dữ liệu trƣớc khi mã hõa. Ciphr spec Thông số của các thuật toán mã hoá dữ liệu và MAC. Mater sercet Khoá mật 48 - byte đƣợc chia sẻ giữa client và server. Is resumable Cờ vốn biểu thị session có thể đƣợc sử dụng để bắt đầu các nối kết mới hay không. Bảng 2.3: Các thành phần thông tin trạng thái nối kết SSL. Thành phần Mô tả Ngẫu nhiên server và client Các chuỗi byte đƣợc chọn bởi server và client cho mỗi nối kết. Khoá mật Khoá mật đƣợc sử dụng cho các hoạt động MAC trên dữ liệu. MAC ghi server Đƣợc ghi bởi server. Khoá mật MAC ghi client Khoá mật đƣợc sử dụng cho các hoạt động MAC trên dữ liệu đƣợc ghi bởi client. Khoá ghi server Khoá đƣợc sử dụng cho việc mã hoá dữ liệu bởi server và giải mã bởi client. Khoá ghi client Khoá đƣợc sử dụng cho việc mã hoá dữ liệu bởi client và giải mã bởi server. Initialization vector Trạng thái khởi tạo cho một mật mã khổitong chế độ CBC.Trƣờng này đƣợc khởi tạo đầu tiên bởi SSL Handshake player. Sau đó khối đoạn văn bản mật mã sau cùng từ mỗi bản ghi đƣợc dành riêng để sử dụng với bản ghi sau đó. Sè chuçi Mỗi phía duy trì các số chuỗi riêng biệt cho các Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 65 thông báo đƣợc chuyền và đƣợc nhận cho mỗi nối kết. Giao thức con SSL quan träng nhất là SSL Handshake protocol. Lần lƣợt giao thức này là một giao thức xác thực và trao ®æi khoá vốn có thể đƣợc sử dụng để thƣơng lƣợng. Khởi tạo và đồng bộ hoá các tham số bảo mật và thông tin trạng thái tƣơng ứng đƣợc ®Æt ở trong một hai điểm cuối của một session hoặc nối kết SSL. Sau khi SSL Handshake protocol đã hoàn tất dữ liệu ứng dụng có thể đƣợc gửi và đƣợc nhận bằng cách sử dụng SSL Record protocol và các tham số bảo mật đƣợc thƣơng lƣợng và các thành phần thông tin trạng thái. 5.2.2 SSL Record protocol : Hình 19: Các bƣớc SSL Record protocol SSL Record Protocol nhận dử liệu từ các dao thức con SSL lớp cao hơn và sử lý việc phân đoạn, nén, xác thực và mã hoá dữ liệu. Chính xác, giao thức này lấy một khối dữ liệu có kích cỡ tuỳ ý làm dữ liệu nhập và toạ một loạt các đoạn dữ liệu nhập và tao một loạt các đoạn dữ liệu SSL làm dữ liệu xuất (hoặc còn đƣợc gọi là các bản ghi) nhỏ hơn hoặc bằng 16,83 byte. Các bƣớc khác nhau của SSL Record Protocol vốn đi từ một đoạn dữ liệu thô đến một bản ghi SSL Plaintext (bƣớc phân đoạn), SSL Compressed (bƣớc nén) và SSL ciphertext (bƣớc mã hoá) đƣợc minh hoạ trong hình 2.3. Sau cùng, mỗi bản SSL chứa các bản thông tin sau đây: Application layer Change Cipher Spec SSL Alert Protocol SSL Handshake Protocol SSL Record protocol TCP protocol IP protocol SSL 3.0 Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 66  Loại nội dung: xác định giao thức lớp cao hơn vốn ophải đƣợc sử dụng để sau đó xử lý độ lớn dữ liệu bản ghi SSL (sau khi giải nens và giải mã hoá thích hợp).  Số phiên bản của giao thức: xác định phiên bản SSL đang sử dụng (thƣờng là version 3.0)  Độ dài;  Độ lớn dữ liệu (đƣợc nến và đƣợc mã hoá tuỳ ý): độ lớn dữ liệu bản ghi SSL đƣợc nén và đƣợc mã hoá theo phƣơng thức nén hiện hành và thông số mật mã đƣợc xác định cho session SSL.  MAC. Lúc đầu mỗi session SSL,phƣơng pháp nén và thông số mật mã thƣờng đƣợc xác định là rỗng. Cả hai đƣợc xác lập trong xuốt quá trình thực thi ban đầu SSL Handshake Protocol.Sau cùng MAC đƣợc thêm vào các bản ghi SSL. Nó cung cấp các dich vụ xác thực nguồn gốc thông ban\ó c\và tính toàn vẹn dữ liệu. Tƣơng tự nhƣ thuật toán mã hoá, thuật toán vốn đƣợc sử dụng để tính và xác nhận MAC đƣợc xác định trong thông số mật mã của trạng thái session hiện hành. Theo mặc định,SSL Record Protocol sử dụng một cấu trúc MAC vốn tƣơng tự nhƣng vẫn khác với cấu trúc HMAC hơn. Có ba điểm khác biệt chính giữa cấu trúc SSL MAC và cấu trúc HMAC: 1. Cấu trúc SSL MAC có một số chuỗi trong thông báo trƣớc khi hash để ngăn các hình thức tấn công xem lại riêng biệt. 2. Cấu trúc SSL MAC có chiều dài bản ghi. 3. Cấu trúc SSL MAC sử dụng các toán tử ghép, trong khi cấu trúc MAC sử dụng module 2. Tất cả các điểm khác biệt này hiện hữu chủ yếu vì cấu trúc SSL MAC đựoc sử dụng trƣớc cấu trúc HMAC cũng đƣợc sử dụng cho thông số ki thuật giao thức bảo mật Internet. Cấu trúc HMAC cũng đƣợc sử dụng cho thông số kĩ thuật giao thức TSL gần đây hơn. Nhƣ đƣợc minh hoạ trong hình 2.3 một số giao thức con SSL đƣợc xếp lớp trên SSL Record Protocol. Mỗi giao thức con có thể tham chiếu có thể thông báo đến các loại thông báo cụ thể vốn đƣợc gửi bằng cách sử dụng SSL Record Protocol. Thông số kĩ thuật SSL 3.0 xác định ba giao thức SSL sau đây:  Alert Protocol;  Handshake Protocol;  ChangeCipherpec Protocol; Tóm lại, SSL Alert Protocol đƣợc sử dụng để chuyển các cảnh báo thông qua SSL Record Protocol. Mỗi cảnh báo gồm 2 phần, một bức ảnh báo và một mô tả cảnh báo. SSL Handshake Protocol là giao thức con SSl chính đƣợc sử dụng để hỗ trợ xác thực client và server và để trao đổi một khoá session. Do đó SSL Handshake Protocol trình bày tổng quan và đƣợc thảo luận trong phần tiếp theo. Sau cùng, SSL ChangeCipherpec Protocol đƣợc sử dụng để thay đổi giữa một thông số mật mã này và một thông số mật mã khác. Mặc dù thông số Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 67 mật mã thƣờng đƣợc thay đổi ở cuối một sự thiết lập quan hệ SSL, nhƣng nó cũng có thể đƣợc thay đổi vào bất kỳ thời điểm sau đó. Ngoài những giao thức con SSL này, một SSL Application Data Protocol đƣợc sử dụng đê chuyển trực tiếp dữ lệu ứng dụng đến SSL Record Protocol. 5.2.3 SSL Handshake Protocol SSL Handshake Protocol là giao thức con SSL chính đƣợc xếp lớp trên SSL Record Protocol. Kết quả, các thông báo thiết lập quan hệ SSL đƣợc cung cấp cho lớp bản ghi SSL nơi chúng đƣợc bao bọc trong một hoặc nhiều bản ghi SSL vốn đƣợc xử lý và đƣợc chuyển nhƣ đƣợc xác định bởi phƣơng pháp nén và thông số mật mã của session SSL hiện hành và các khoá mật mã của nối kết SSL tƣơng ứng. Mục đích của SSL Handshake Protocol là yêu cầu một slient và server thiết lập và duy trì thông tin trạng thái vốn đƣợc sử dụng để bảo vệ các cuộc liên lạc. Cụ thể hơn, giao thức phải yêu cầ slient và server chấp thuận một phiên bản giao thức SSL chung, chọn phƣơng thức nén và thông phức nén và thông số mật mã, tuỳ ý xác thực nhau và tạo một khoá mật chính mà từ đó các khoá ssession khác nhau dành cho viêc xác thực và mã hoá thông báo có thể đƣợc dẫn xuất từ đó. Tóm lại, việc thực thi SSL Handshake Protocol giữa một slient C và một server S có thể đƣợc tóm tắt nhƣ sau (các thông báo đƣợc đặt trong các dấu ngoặc vuông thì tuỳ ý): Client Server Client Hello Server Hello Server Certificate Server Hello Done Client Key Exchange Change Cipher specification Hình 20: Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 68 Handshake Finished Change Cipher specifications Khi Client C muốn kết nối với server S, nó thiết lập một nối kết TCP với cổng HTTPS (vốn không đƣợc đƣa vào phần mô tả giao thức) và gởi một thông báo CLIENTHELLO đến server ở bƣớc 1 của sự thực thi SSL Handshake Protocol. Client cngx có thể gởi một thông báo CLIENT HELLO nhằm phản hồi lại một thông báo HELLOREQUEST hoặc chủ động thƣơng lƣợng lại các tham số bảo mật của một nối kết hiện có. Thông báo CLIENTHELLO bao gồm các trƣờng sau đây:  Số của phiên bản SSL cao nhất đƣợc biểu hiện bởi client (thƣờng là 3.0t).  Một cấu trúc ngẫu nhiên do client tạo ra gồm một tem thời gian 32 bit có dạng UNIX chuẩn và một giá trị 28 byte đƣợc tạo ra bởi một bộ tạo số giả ngẫu nhiên.  Một định danh session mà client muốn sử dụng cho nối kết này.  Một danh sách các bộ mật mã client hỗ trợ.  Một danh sách các phƣơng pháp nén mà client hỗ trợ. Chú ý rằng trƣờng session identity (định danh session) nên rỗng nếu session SSL hiện không tồn tại hoặc nếu client muốn ạo clientáclient ham số bao mật mới. ở một trong hai trƣờng hợp, một trƣờng session identity không rỗng là xáclient định một session SSL hiệ có giữa client và server (nghĩa là một session có các tham số bảo mật mà client muốn sử dụng lại). Định danh session có thể bắt nguồn từ một nối kết trƣớc đó, nối kết này hoăc một nối kết đang hoạt động. Cũng chú ý rằng danh sách các bộ mật mã đƣợc hỗ trợ, đƣợc chuyển từ client đến server trong thông báo CLIENTHELLO, chứa các tổ hợp thuật toán mật mã đƣợc hỗ trợ bởi client theo thứ tự ƣu tiên. Mỗi bộ mật mã xác định một thuật toán trao đổi và một thuật toán trao đổi khoá và một thông báo mật mã. Server sẽ chọn một bộ mật mã hoặc nếu các lựa chọn có thể chấp nhận đƣợc không đƣợc trình bày, trả về một thông báo lỗi và đóng nối kết một cách phù hợp. Sau khi đã gởi thông báo CLIENTHELLO. Client đợi một thông báo SERVER HELLO. Bất kì thông báo khác đƣợc trả về bởi server ngoại trừ một thông báo HELLOREQUEST đƣợc xem nhƣ là một lỗi vào thời điểm này. ở bƣớc 2, server sử lí thông báo CLIENTHELLO và đáp ứng bằng một thông báo lỗi hoặc thông báo SERVER HELLO. Tƣơng tự nhƣ thông báo CLIENTHELLO, thông báo SERVER HELLO có các trƣờng sau đây:  Một số phiên bản server chứa phiên bản thấp hơn của phiên bản đƣợc đề nghị bởi client trong thông báo CLIENTHELLO và đƣợc hỗ trợ cao nhất bởi Server.  Một cấu trúc ngẫu nhiên do server tạo ra cũng gồm một tem thời gian 32 bit có dạng UNIX chuẩn và một giá trị 28 bit đƣợc tạo ra bởi một bộ tạo số ngẫu nhiên.  Một đinh danh session tƣơng ứng với kết nối này. Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 69  Một bộ mật mã đƣợc chọn bởi server từ danh sách các bộ mật mã đƣợc hỗ trợ bởi client.  Một phƣơng pháp nén đƣợc chọn bởi server từ danh sách các thật toán nén đƣợc hỗ trợ bởi client. Nếu định danh session trong thông báo CLIENTHELLO không rỗngN, server tìm trong cache session của nó nhằm tìm ra một mục tƣơng hợp. Nếu mục tƣơng hợp đƣợc tìm thấy và server muốn thiết lập nối kết bằng cách sử dụng trạng thái session tƣơng ứng, server đáp ứng bằng cùng một giá trị nhƣ đƣợc cung cấp bởi client . Chỉ định này là một session đƣợc tiếp tục lại và xác định rằng cả hai phía phải tiến hành trực tiếp với các thông báo CHANGECIPHESPEC và FINISHED đƣợc trình bày thêm bên dƣới. Nếu không, trƣờng này chứa một giá trị khác nhận biết một session mới. Server cũng có thể trả về một trƣờng đnhjdanh session rỗng đễ biểu thị rằng session sẽ không đƣợc lƣu trữ và do đó không thể đƣợc tiếp tục sau đó. Cũng chú ý rằng thông báo SERVERHELLO, server đƣợc chọn một bộ mật mã và một phƣơng pháp nén từ các danh sách đƣợc cung cấp bởi client trong thông báo CLIENTHELLO . Các thuật tón trao đổi khoá, xác thực, mã hoá và xác thực thông báo đƣợc xác định bởi bộ mã đƣợc chọn bởi server và đƣợc làm lộ ra trong thông báo SERVERHELLO. Các bộ mật mã vốn đã đựoc xác định trong giao thức SSL về cơ bản giống nhƣ bộ mật mã đã xác định cho TLS Ngoài thông báo SERVERHELLO, server cũng phải gởi các thông báo khác đến client. Ví dụ, nếu server đƣợc sử dụng sự xác thực dựa vào chứng nhân, server gởi chứng nhận site cả nó đến client trong một thông báo CERTIFICATE tƣơng ứng. Chứng nhận phải thích hợp cho thuật toán trao đôI kháo cua bộ mật mã đƣợc chọn và thƣờng là một chứng nhận X 509v3. cùng loại thông báo server đƣợc sử dụng sau đó cho sự đáp ứng của client đối với thông báo CERTIDICATERequest của server . Trong trƣờng hợp các chứng nhận X 509v3, một chứng nhận có thể thực sự tham chiếu đén toàn bộ mỗi chuỗi các chứng nhận, đƣợc sắp xếp theo thứ tự với chứng nhận ca đối tƣợng gởi trƣớc tiên theo sau là bất kỳ chứng nhận CA tiến hành theo tnhf tự hƣớng đến một CA gốc (vốn đƣợc chấ nhận bởi clientv). Tiếp theo, server có thể gửi thông báo SERVERKEYEXCHANGE đến client nế nó không có chứng nhận, vốn có đƣợc sử dụng chỉ để xác định các chữ ký kĩ thuật số hoặc sử dụng thuật toán trao đổi khoá dựa vào token FORITEZZA (KEA). Rõ ràng thông báo này không đƣợc yêu cầu nếu chứng nhân site gồm một khoá chung RSA vốn có thể đƣợc sử dụng trong việc mã hoá.Ngoài ra một server không nặc danh có thể tuỳ ý yêu cầu một chứng nhận cá nhân để xác nhận client. Do đó, nó gửi một thông báo CERTIFFICATATERequest đến client. Thông báo này chứa một danh sách các loại chứng nhận đuợc yêu cầu, đƣợc phân loại theo thứ tự ƣu tiên của server cũng nhƣ một danh sách các tên đyựơc phân biệt cho các CA có thể chấp nhận. Ở cuối bƣớc 2, server gửi một thông báo SERVERHELLODone đến client để chỉ định sự kết thúc SERVERRHLLO và các thông báo kèm. Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 70 Sau khi nhận SERVERHELLO và các thông tin đi kèm, client xác nhận rằng chứng nhận site server (nếu đƣợc cung cấp) là hợp lệ và kiểm tra nhằm bảo đảm các thông số bảo mạt đƣợc cung cấp trong thông báo SERVERHELLO có thể đƣợc chấp nhận. Nếu server yêu cầu sự xác thực client, client gửi một thông báo CERTIFICATE vốn chúa một chứn nhận cá nhân cho khoá chung của ngƣời dùng đến server ở bƣớc 3. Tiếp theo, client gửi một thông báo CLIENTKEYEXCHANGE có dạng phụ thuộc vào thuật toán cho mỗi khoá chọn bởi server. Nếu RSA đƣợc sử dụng cho việc xác thực server và trao đổi khoá, client tạo một khoá mật tiềnchính 48 byte, mã hoá nó bằng mã chung đƣợc tìm thấy trong chứng nhận site hoặc khoá RSA tạm thời từ thông báo SERVERKEYEXCHSNGE và gửi kết quả troqr về trong thông báo CLIENTKEYEXCHANGE. lần lƣợt server sử dụng khoá đơn để giả mã khoá mật chính. Nếu các token FORTEZZA đƣợc sử dụng để trao đổi khoá, client dẫn xuất một khoá mã hoá token (TEK) bằng cách sử dụng KEA. Cách tìm KEA của client sử dụng khoá chung từ chứng nhận server cùng với một số tham số riêng trong token của client. Client gửi các tham số chung cần thiết cho server để cũng tạo TEK, sử dụng các tham số riêng của nó. Nó tạo một khoá mật chính, bao bọc nó bằng cách sử dụng TEK và gửi kết quả cùng với một số vector khởi tạo đến server nhƣ là một phần của thông báo CLIENTKEYEXCHANGE. Lần lƣợt server có thể giải mã khoá mật chính một cách thích hợp. Thuật toán trao đổi khoá này không đƣợc sử dụng rộng rãi. Nêu s sự xác thực client đƣợc yêu cầu, client cũng gửi một thông báo CERTIFICATEVERIFY đến server. Thông báo này đƣợc sử dụng đẻ cung cấp sự xác thực rõ ràng định danh cua ngƣời dựa vào chứng nhận các nhân. Nó chỉ đƣợc gửi theo sau một chứng chỉ client vốn có khả năng tạo chữ kí (tất cả các chứng nhận ngoại trừ các chứng nhận chứa các tham số Diffehallman cố định). Sau cùng, client hoàn tất bƣớc 3 bằng cách guỉ 1 thông báo CHAGECIPHERSPEC và một thông báo FINIHED tƣơng ứng tới server. Thông báo FINIHED luôn đƣợc guỉƣ ngay lập tức sau thông báo CHANGERCIPERSPEC để xác nhận rằng các tiến trình trao đổi khoá và xác thực đã thành công. Thực tế thông báo FINISHED là thong báo đầu tiên vốn đƣợc bảo vệ bằng các thuật toán mới đuợc thƣơng lƣợng và các khoá session. Nó chỉ có thể đƣợc tạo và đƣợc xác nhận nếu nhƣng khoá này đƣợc cài đặt một cách phù hợp ở cả hai phía. Không đòi hỏi sự báo nhận thông báo FINISHED; các phía có thể bắt đầu gửi dữ liệu đƣợc mã hoá ngay lập tức sau khi đã gởi thông báo FINISHED. Việc thực thi SSL Handshake Protocol hàn tất bằng việc cũng yêu câỳu server gơI một thông báo SERVERKEYEXCHANGE và một thông váo FINISHED tƣơng ứng đến client ở bƣớc 4. Sau khi thiết lập SSL hoàn tất, một nối kết an toàn đƣợc thiết lập giữa các client và server . nối kết này bây giờ có thể đƣợc sử dụng để gởi dữ liệu ứng dụng vốn đƣợc bao bọc bởi SSL Record Protocol. Chính xác hơn, dữ liệu ứng Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 71 dụng có thể đƣợc phân đoạn, đƣợc nén, hoặc đợc mã hoá và đƣợc xác thực theo SSL Record Protocol cũng nhƣ thông tin trạng tháI session và nối kết vốn bây giờ đƣợc thiết lập (tuỳ thuộc việc thực thi SSL Handshake Protocolt) SSL Handshake Protocol có thể đƣợc rút ngắn nếu client và server quyết định tiếp tục lại một session SSL đƣợc thiết lập trƣớc đó (và vẫn đƣợc lƣ trữv) hoặc lặp lại một session SSL hiện có. Trong trƣờng hợp này, chỉ ba dòng thông báo và tông cộng sáu thông báo đƣợc yêu cầu, Các dòng thông báo tƣơng ƣng có thể tóm tắt nhƣ sau: 1: C -> S: CLIENTHELLO 2: S-> C: SERVERHELLO CHANECIPHERSPEC FINISHES 3: S-> CHANECIPHERSPEC INISHES ở bƣớc một, client gởi một thông báo CLIENTHELLO đến server vốn có mặc định danh session cần đƣợc tiếp tục lại. Lần lƣợt các server kiểm tra cache session của nó để tìm một mục tƣơng hợp. Nếu một mục tƣơng hợp đƣợc tìm thấy, server muốn tiếp tục lại nối kết bên dƣới trạng tháI session đã xác định, nó trả về một thông báo SERVERHELLO với cùng một định danh session ở bƣớc 2. Vào thời điểm này, cả client lẫn server phảogởi các thông báo CHANECIPHERSPEC và FINISHES đến nhau ở bƣớc 2 và 3. Một khi việc tái thiết lập session hoàn tất, client và server có thể bắt đầu dữ liệu ứng dụng. 5.3. Bảo mật giao dịch điện tử ( Secure Electronic Transaction – SET) SET là một phƣơng pháp bảo mật đƣợc xây dựng nhằm bảo đảm an toàn các giao dịch trên internet bằng thể tín dụng. Phiên bản hiện tại, SET v1, đƣợc chọn làm tiêu chuân bảo mật cho các thẻ tín dụng nhƣ Matercard và Visa vào tháng 1 năm 1996. Rất nhiều công ty đã tập chung phát triển và xây dựng tong đó có IBM, Microsoft, Netscape, RSA, Tesia và Versign. Từ năm 1998 các sản phẩm đầu tiên sử dụng SET đã đƣợc triển khai. Bản thân SET không phải là một hệ thống thanh toán, mà thực chất nó là tập hợp các giao thức bảo mật và định dạng cho phép ngƣời dùng sử dụng các thiết bị làm việc với thẻ tín dụng trên hệ thống mạng nhƣ internet theo nguyên tắc bảo mật. Về cơ bản, SET cung cấp ba dịch vụ:  Cung cấp một kênh truyền thông an toàn tuyệt đối với tất cả các thành viền trong quá trình giao dịch. Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 72  Sử dụng tiêu chuẩn chứng thực số X.509v3 để đảm bảo an toàn.  Giữ gìn sự riêng tƣ bởi các thông tin chỉ cung cấp cho các thành viên trong giao dịch diễn ra vào thời điểm hay địa điểm cần thiết. 5.3.1.Tổng quan về SET Các yêu cầu: Trƣớc tiên ta xem xét các yêu cầu trong thƣơng mại mà SET cần có cũng nhƣ các thành phần khác tham gia trong các giao dịch sử dụng SET, các yêu cầu thƣơng mại đảm bảo an toàn cho các chi trả với thẻ tín dụng trên Internet cũng nhƣ các mạng khác bao gồm:  Cung cấp sự tin cậy cho các thông tin chi trả và thanh toán: Điều này cần thiết để đảm bảo ngƣời dùng thể giữ gìn an toàn các thông tin của mình cũng nhƣ các thông tin đến đƣợc với ngƣời nhận đƣợc mong đợi. Sự tin cậy này cũng sẽ giảm bớt các rủi ro đôI với các gian lận trong giao dịch với đối tác cũng nhƣ các thành viên thứ ba không mong muốn. SET sử dụng mã hoá các cung cấp tin cậy này.  Đảm bảo tính toán toàn vẹn đối với mọi dữ liệu đƣợc truyền đ: Nghĩa là đảm bảo không có nội dung nào bị thay đổi trong suốt quá trình giao dịch sử dụng SET. Chữ ký số đƣợc sử dụng để cung cấp các toàn vẹn này.  Cung cấp chứng thực đối với ngƣời sử dụng thẻ là ngƣời sử dụng tài khoản thẻ tín dụng hợp pháp: Một cơ chế liên kết ngƣời dùng thể tới số tài khoản xác định nhằm giảm thiểu các gian lận đối với một quá trình mua bán chi trả. Chữ ký số và cơ chế chứng nhận đƣợc sử dụng để xác nhận ngƣời dùng thẻ là ngƣời sở hữu tài khoản hợp lệ.  Cung cấp các chứng thực cho phép các nhà knh doanh có thế chấp nhận các giao dịch sử dụng thể tín dụng thông qua mối quan hệ với một tổ chức tài chính: Đây là sự bổ sung cho các yêu cầu có trƣớc. Ngƣời sử dụng thể cần nhận biết đƣợc đâu là các nhà kinh doanh có đủ tƣ cách đảm bảo an toàn cho các giao dịch. Một lần nữa, chữ ký số và các cơ chế chứng nhận đƣợc sử dụng.  Đảm bảo việc sử dụng một cách tốt nhất các kỹ thuật xây dựng hệ thống và độ an toàn thực tế để bảo vệ tất cả các thành viên hợp pháp trong toàn bộ quá trình giao dịch: SET là một sự kiểm nghiệm tốt dựa trên các thuật toán và các giao thức mã hoá an toàn cao.  Xây dựng một giao thức mà không phụ thuộc vào các cơ chế bảo mật giao dịch cũng nhƣ các cơ chế ngăn chặn khác đã dùng: SET có thể thực thi an toàn trên stack của TCP /IP “thô”. Tuy nhiên, SET không gây trở ngại khi sử dụng các cơ chế bảo mật khác chẳng hạn nhƣ IPSec và SSL /TLS. Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 73  Tạo điều kiện và khuyến khích khả năng giữa phần mềm và các nhà cung cấp dịch vụ mạnh: Các giao thức và định dạng SET độc lập với hạ tầng thiết bị phần cứng, hệ điều hành và phần mềm Wed. Các đặc trƣng cơ bản của SET: Sau khi để cập tới yêu cầu cần có ta thấy SET bao gồm các đặc trƣng cơ bản sau:  Thông tin cậy: Thông tin tài khoản và các thông tin cho việc chi trả đƣợc bảo vệ khi nó đƣợc truyền đI trong mạng. Một điều thú vị và quan trọng nhất ở đặc trƣng này của SET là nó ngăn không cho nhà kinh doanh bết đƣợc số thẻ tín dụng của ngƣời sử dụng, mà điều này chỉ đƣợc cung cấp cho các ngân hàng phát hành. Quy ƣớc mã hoá này đƣợc DES dùng để cung cấp các tin cậy.  Toàn vẹn dữ liệu: Thông tin chi trả từ ngƣời sử dụng thể tới các nhà kinh doanh bao gồm các thông tin thanh toán, dữ liệu cá nhân và các liệu cho việc chi trả. SET đảm bảo việc các nội dung của thông điệp không bị biến đổi trong khi gửi đi. Chữ ký số RSA, sử dụng mã băm SHA -1, sẽ đảm bảo tính toàn vẹn các thông điệp này. Các thông điệp này cũng có thể đƣợc đảm bảo bởi HMAC sử dụng SHA -1.  Chứng thực các nhà kinh doanh: SET cho phép ngƣời sử dụng thẻ xác nhận một nhà kinh doanh có quan hệ với một tôt choc tài chính có khả năng chấp nhận các thẻ chi trả. Trong trƣờng hợp này SET có sử dụng chứng nhận số X.509v3 và chữ ký số RAS. Chú ý rằng SET không giống nhƣ IPSec và SSL /TLS, nó chỉ cung cấp một chọn lựa ứng với mỗi thuật toán mã hoá. Đây là một sự khôn ngoan bởi SET là một ứng dụng đơn độc lập với mộ tập hợp các yêu cầu riêng, mà ở đó có IPSec và SSL /TLS đóng vai trò hỗ trợ ở một phạm vi nào đó của các ứng dụng. 5.3.2.Các thành phần tham gia sử dụng SET. Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 74  Ngƣời dùng thẻ (cardholder): trong môi trƣờng điện tử, khách hàng hay một nhóm khách hàng có ảnh hƣởng tới các nhà kinh doanh từ những chiếc máy tính cá nhân thông qua internet. Một ngƣời sử dụng thẻ là ngƣời có quyền nắm giữ thẻ thanh toán đƣợc cung cấp bởi những nhà phát hành.  Nhà kinh doanh(Merchant): Một nhà kinh doanh có thể là một cá nhân hay một tổ chức có các dịch vụ bán hàng cho ngƣời dùng thẻ. Các dịch vụ này đƣợc tiến hành thông qua các website hoặc thƣ điện tử. Một nhà kinh doanh chấp nhận đƣợc các thẻ thanh toán thì buộc phải có quan hệ với một nhà trung gian(Acquirer).  Nhà phát hành(issuer): Đây là một tổ chức tài chính, chẳng hạn nhƣ ngân hàng, cung cấp tài khoản ngƣời dùng cùng với thẻ thanh toán. Các tài khoản đƣợc sử dụng thông qua các imail cá nhân. Về cơ bản, các nhà phát hành chịu trách nhiệm chi trả các khoản tiền chƣa trả của ngƣời dùng thẻ.  Nhà trung gian – Ngân hàng của doanh nghiệp (Acquirer): Đây là tổ chức tài chính thực hiện việc thiết lập một tài khoản đối với nhà kinh doanh và chứng thực các quá trình chi trả bằng thẻ. Các nhà kinh doanh thƣờng chấp nhận nhiều hơn một loại thẻ nhƣng lại không muốn quan tâm đến nhiều tổ chức cũng nhƣ nhiều cá nhân cung cấp thẻ nào. Trng khi đó nhà trung gian sẽ cung cấp việc chứng thực nhà kinh doanh bằng cách đƣa ra cho họ một thẻ tài khoản tiện lợi và giới hạn quyền đối với các loại thẻ này. Nhà trung gian cũng cung cấp các luân chuyển điện tử cho việc chi trả đối với các tài khoản của các nhà kinh doanh. Sau cùng, nhà kinh doanh sẽ đƣợc hoàn lại số tiền mà các nhà phát hành có đƣợc từ quỹ luân chuyển điện tử trên mạng chi trả.  Cổng chi trả (payment gateway): Đây là một chức năng thực hiện bởi Nhà trung gian hoặc đƣơc xây dựng một thành viên thứ ba nhằm xử lí các thông tin chi trả của nhà kinh doanh. Nhà trung gian trao đổi các thông điệp SET với cổng chi trả thông qua internet, trong khi đó cổng chi trả hƣớng vào hay kết nối mạng tới hệ thống sử lí tài chính của nhà trung gian.  Quyền chứng nhận (Certification Authority- CA): Đây là một thực thể đƣợc tin cậy để cung cấp các chức nhận khoá công khai X.509V3 cho ngƣời sử dụng thẻ, các nhà kinh doanh và các công chi trả. Thành công của SET sẽ phụ thuộc vào sự tồn tại của một hạ tầng CA có giá trị. Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 75 Dƣới đây là mô tả lƣợc đồ bao gồm cho các sự kiện đƣơc diễn ra trong một giao dịch thƣơng mại điện tử: 1. Khách hàng mở một tài khoản: khách hàng có đƣợc ở thẻ tín dụng nhƣ MasteerCard hay Visa với một ngân hàng có khả năng hỗ trợ chi trả điện tử và STE. 2. Khách hàng nhận một chứng nhận: Sau khi nhận dạng hoàn tất, khách hàng nhận đƣợc một chứng nhận số X.509V3, Đƣợc kí bởi ngân hàng.chứng nhận này xác minh công khai RSA của khách hàng và hạn sử dụng của nó. Nó sẽ thiết lập một quan hệ, đƣợc bảo đảm bởi ngân hang, chiếc cặp khoả của khách hàng và thẻ tín dụng của anh ta. 3. Nhà kinh doanh có riêng các chứng nhận của họ: Một nhà kinh doanh muốn chấp nhận nhiều loại thẻ thì buộc phải sở hữu hai chứng nhận đối với hai khoá công khai riêng của họ: Một cho kí nhận thông điêp và một cho trao đổi khoá. Nhà kinh doanh cùng cần có một bả sao chứng nhận khoá công khai của cổng chi trả. 4. Khách hàng đặt một thanh toán: Đây là một quá trình bao gồm việc lựa chọn mặt hàng trên webside của nhà kinh doanh và xác định giá cả. Khách hàng gửi tới nhà kinh doanh một danh sách các mặt hàng muốn mua, họ nhận đƣợc một mẫu thanh toán bao gồm danh sách mặt hàng, giá cả, tổng tiền và số hoá đơn. 5. Nhà kinh doanh được xác nhận: Thêm vào mỗi thanh toán, nhà kinh doanh gửi một bản sao chứng nhận nó, vì vậy khách hàng có thể tin tƣởng rằng anh ta có quan hệ với một nhà kinh doanh hợp pháp. 6. Việc thanh toán và chi trả được gửi đi: Khách hàng gửi tới nhà kinh doanh các thông tin thanh toán và chi trả cùng với chứng nhận khách hàng: Thông tin thanh toán bao gồm các mặt hàng đã đặt trong mẫu hoá đơn; thông tin chi trả chứa nội dung chi tiết của thẻ tín dụng. Nó đã đƣợc mã hoá do vậy nhà kinh doanh không thể biết đƣợc; chứng nhận khách hàng cho phép nhà kinh doanh xác nhận khách hàng. 7. Nhà kinh doanh yêu cầu chứng thực các chi trả: nhà kinh doanh chuyển các thông tin tới cổng chi trả, yêu cầu xác thực thông tin thẻ tín dụng của khách hàng có phù hợp với việc mua các sản phẩm đã đặt hay không. 8. Nhà kinh doanh xác nhận thanh toán: nhà kinh doanh gửi xác nhận thanh toán tới khách hàng. 9. Nhà kinh doanh cung cấp các mặt hàng dịch vụ: nhà kinh doanh chuyển hàng hoặc cung cấp dịch vụ tới khách hàng. 10. Nhà kinh doanh yêu cầu chi trả: yêu cầu này đƣợc gửi tới cổng chi trả (Quả lý tất cả quá trình chi trả). Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 76 CHƢƠNG IV cµi ®Æt b¶o mËt vµ an toµn th«ng tin trªn website mua b¸n c¸c linh kiÖn m¸y tÝnh trªn m¹ng internet I. C¸c chøc n¨ng c¬ b¶n vµ ho¹t ®éng cña hÖ thèng website Nhƣ đã trình bày trong chƣơng 1, chƣơng 2 và chƣơng 3 của luận văn khi nghiên cứu về các hệ mật mã khoá đới xứng và khoá công khai căn bản cũng nhƣ việc nghiên cứu các giao thức và cơ chế bảo mật thƣơng mại điện tử sử dụng SSL/TLS, SET, tác giả đã quyết định lựa chọn hệ mật mã cơ bản nhất là DES và giải thuật chữ ký số DSA cho phần cài đặt ứng dụng của mình. Trong luận văn này, em không đi sâu vào việc trình bày về quá trình phân tích hệ thống cho việc xây dựng website bán hàng trực tuyến mà chỉ trình bày ý nghĩa của các phần hệ thống đã đƣợc xây dựng bao gồm các chức năng thông thƣờng cũng nhƣ các chức năng bảo mật đƣợc cài đặt. Các mô tả quá trình chứng thực, bảo mật lớp cơ sở dữ liệu cũng nhƣ quá trình tƣơng tác giữa các đối tƣợng trong quá trình chứng thực khách hàng đƣợc mô tả trong sơ đồ sau: 1. Tổ chức dữ liệu - Website bao gồm có các trang:  Trang chủ  Trang thông tin nhóm hàng: ví dụ Máy tính sách tay, thiết bị văn phòng…  Trang thông tin chi tiết sản phẩm: hiển thị các thông tin chi tiết về một sản phẩm, qua đó khách hàng thực hiện các thao tác khác nhƣ: chọn mua hàng  Trang thông tin đơn hàng: sau khi khách hàng lựa chọn một hoặc nhiều sản phẩm cần mua, gồm các thông tin nhƣ: mã sản phẩm, tên sản phẩm, số lƣợng cần mua… sẽ lập thành một đơn hàng. Trên trang đơn hàng này, khách hàng thực hiện các chức năng khác nhƣ : o Tiếp tục mua hàng: tiếp tục chọn thêm các sản phẩm khác muốn mua Đặt hàng Chứng thực khách hàng Khách hàng Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 77 o Chấp nhận mua hàng: gửi thông tin về đơn hàng lên hệ thống, xác nhận nhu cầu mua hàng o Hủy đơn hàng: xóa bỏ tất cả các sản phẩm đã lựa chọn, từ đó chọn lại các sản phẩm mới o Cập nhật đơn hàng: lựa chọn lại số lƣợng mỗi sản phẩm trong đơn hàng, từ đó hệ thống tính lại giá tiền cho tổng cộng các sản phẩm đã chọn 2. Quản trị thông tin - Ngƣời quản trị hệ thống cập nhật các thông tin về sản phẩm lên website, từ đó khác hàng có thể lựa chọn xem, mua - Mỗi sản phẩm gồm các thông tin quan trọng là: Mã sản phẩm, giá bán. Các thông tin khác chỉ có ý nghĩa cung cấp hiểu biết cho khách hàng 3. Mã hóa RSA và áp dụng trong hệ thống Đăng ký thành viên  Mỗi ngƣời truy cập vào hệ thống, muốn thực hiện việc mua hàng, đăng ký mua hàng đều phải đăng ký trở thành thành viên của website. Quá trình này chính là việc cấp cho khách hàng một “tên đăng nhập”, “mật khẩu đăng nhập” và “cặp khóa công khai – khóa bí mật theo thuật toán RSA”. Với đầy đủ các thông tin này, khách hàng có thể thực hiện đƣợc giao dịch mua hàng trên website  Chi tiết các bƣớc đăng ký thành viên gồm các bƣớc nhƣ sau: o Đăng ký thành viên: cung cấp các thông tin nhƣ: tên đăng nhập, địa chỉ hòm thƣ, mật khẩu… o Hệ thống kiểm tra tính duy nhất của Tên đăng nhập & địa chỉ thƣ. Nếu đã đƣợc sử dụng trong hệ thống, khách hàng phải lựa chọn một tên khác o Nếu quá trình cung cấp thông tin hoàn tất và không gặp lỗi nào, hệ thống thực hiện “tạo” cặp khóa bí mật – công khai theo thuật toán RSA, sau đó gửi khóa bí mật dƣới dạng file đính kèm về địa chỉ thƣ mà khách hàng đã cung cấp. Khóa công khai đƣợc lƣu trữ trong CSDL o Cặp khóa bí mật – công khai này bảo đảm tính duy nhất, không trùng lặp giữa tất cả các thành viên của hệ thống o Khách hàng sau khi kiểm tra địa chỉ thƣ, nhận đƣợc đầy đủ các thông tin cần phải thực hiện thao tác “xác nhận” trƣớc khi thực hiện đƣợc bất kỳ giao dịch nào. Thao tác này là cần thiết, để tránh trƣờng hợp mạo danh, sử dụng email của ngƣời khác một cách không hợp lệ. o Sau khi thao tác này hoàn thành, khách hàng đƣợc quyền thực hiện các giao dịch của mình, theo những chức năng mà hệ thống đã cung cấp. Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 78 4. Thực hiện mua hàng  Khách hàng thực hiện việc mua hàng, cũng hoàn toàn giống các bƣớc chọn hàng trong siêu thị, nhƣng khác là trên một hệ thống điện tử, siêu thị trực tuyến Thao tác 1: Xem hàng và chọn hàng. Khách hàng lƣớt web, xem hệ thống cung cấp những mặt hàng nào, chủng loại nào, nếu tìm đƣợc hàng phù hợp thì thực hiện thao tác chọn mua hàng. Sau thao tác này, mặt hàng đƣợc chọn sẽ nằm trong một “đơn hàng”, và khách hàng có thể thay đổi lại đơn hàng theo các thao tác nhƣ: không chọn sản phẩm nào đó, thay đổi số lƣợng cần mua của mỗi sản phẩm, hủy toàn bộ đơn hàng Thao tác 2: Chấp nhận mua hàng. Sau khi chọn xong các sản phẩm, khách hàng thực hiện thao tác “Chấp nhận mua hàng”. Chức năng này thực hiện cập nhập dữ liệu về hàng hóa của khách hàng vào hệ thống các đơn hàng chờ đƣợc xử lý. Nếu khách hàng chƣa thực hiện đăng nhập, hệ thống không xác định đƣợc định danh ngƣời dùng đang truy cập là ai, từ đó website sẽ chuyển hƣớng đến trang đăng nhập. Trong trang này, khách hàng cần cung cấp các thông tin gồm: Tên đăng nhập và Mật khẩu, nếu các thông tin này đúng hoặc đã đăng nhập thành công trƣớc đó, hệ thống sẽ tự động chuyển đến trang xử lý đặt mua hàng và thông báo cho khách hàng. Sau thao tác này, khách hàng nhận đƣợc email thông báo tình trạng đơn hàng, và đƣờng dẫn duy nhất để thực hiện kích hoạt đơn hàng. Thao tác 3: Kích hoạt đơn hàng. Khi đơn hàng chƣa đƣợc kích hoạt, dữ liệu về các sản phẩm, hàng hóa đặt mua đã đƣợc mã hóa theo thuật toán RSA, sử dụng khóa chung để mã hóa các thông tin đơn hàng, bảo đảm thông tin đƣợc bảo mật và không bị tiết lộ nếu không có khóa bí mật hợp lệ để giải mã. Khách hàng thực hiện kích hoạt theo đƣờng dẫn đã cung cấp trong email, tiếp đó hệ thống sẽ yêu cầu cung cấp khóa bí mật bằng cách khách hàng browse để chọn file chứa khóa bí mật, file này đã đƣợc hệ thống cung cấp khi thực hiện đăng ký. Hệ thống sẽ sử dụng khóa bí mật này (chỉ lƣu trong bộ nhớ RAM máy tính) để giải mã các thông tin mã hóa ở trên, để tìm ra số sản phẩm đã mua, số lƣợng tƣơng ứng với mỗi sản phẩm, để từ đó, tính giá trị đơn hàng và chuyển dữ liệu cho module xử lý khấu trừ tiền trong tài khoản. Nếu một ngƣời nào đó nhận đƣợc đƣờng dẫn này và cũng thực hiện kích hoạt đơn hàng, nhƣng không có khóa bí mật hợp lệ, thì sẽ không thể thực hiện đƣợc việc giải mã và mua hàng. 5, Các thức thực hiện mã hóa và giải mã 5.1 Mã hóa đơn hàng  Các sản phẩm trong một đơn hàng đƣợc đặc trƣng bởi: Mã sản phẩm, số lƣợng cần mua. Các thông tin khác nhƣ: giá bán, tên hàng… đều đƣợc lƣu trữ trong CSDL của website, không cần thiết phải đƣa vào xâu ký tự cần mã hóa. Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 79  Từ đó plain text cần mã hóa gồm: PT = {Mã-hàng-hóa}/{Số-lƣợng-cần- mua}[^]. Từ đó, khi khách hàng chọn mua 5 sản phẩm thì xâu ký tự cần thực hiện mã hóa sẽ là: PT = sp01/3^sp12/9^sp32/1^sp45/8^sp983/2, diễn giải ra sẽ là: mua Sản phẩm có mã là sp01 số lƣợng 3 chiếc (cái), sản phẩm có mã sp12 số lƣợng 9, sản phẩm có mã là sp32 số lƣợng 1, sản phẩm có mã sp45 số lƣợng 8, sản phẩm có mã 983 số lƣợng 2. Hàm thực hiện mã hóa sẽ mã hóa PT thành ET (encoded text), sử dụng khóa công khai của ngƣời đã đặt mua hàng. Xâu ET này sẽ không thể có ý nghĩa nếu không đƣợc giải mã, việc giải mã đòi hỏi phải có khóa riêng của khách hàng 5.2 Giải mã đơn hàng  Xâu ký tự đã mã hóa ET đƣợc hàm giải mã thực hiện decode (giải mã) sau khi khách hàng cung cấp một khóa riêng hợp lệ. Nếu quá trình giải mã thành công, hệ thống sẽ nhận đƣợc xâu PT nhƣ trƣớc khi thực hiện mã hóa, từ đó chứng tỏ ngƣời kích hoạt đơn hàng là hợp lệ, và tiến hành thanh toán, trừ tiền trong tài khoản bình thƣờng Ví dụ khi thực hiện mã hóa/giải mã Khóa bí mật và công khai Thành viên của hệ thống là anhtuan, sau khi đăng ký sẽ đƣợc hệ thống cung cấp các khóa công khai, khóa bí mật nhƣ sau: PrivateKey: YTozOntpOjA7czozMjoiEwUyThq8gAfqCKXW2F/gjMYjOPo6J34rmP6b8 vY+TMoiO2k6MTtzOjMyOiIBv4wLNs8ExGUG+mvRNP2p+2cjRKAH0Dt mFTE0lebYQyI7aToyO3M6NzoicHJpdmF0ZSI7fQ== PublicKey: YTozOntpOjA7czozMjoiEwUyThq8gAfqCKXW2F/gjMYjOPo6J34rmP6b8 vY+TMoiO2k6MTtzOjM6IgEAASI7aToyO3M6NjoicHVibGljIjt9 Nhìn vào hai khóa này, chắc chắn mỗi chúng ta đều không biết ý nghĩa của nó, nhƣng nó đƣợc sinh ra khi ta sử dụng mã hóa theo thuật toán RSA II. cµi ®Æt c¸c chøc n¨ng b¶o mËt vµ an toµn th«ng tin trªn web site mua b¸n linh kiÖn m¸y tÝnh 1. Thủ tục đăng kí thành viên Thủ tục này đƣợc xây dựng cùng với chức năng đăng ký thành viên, sau khi khách hàng điều đầy đủ các thông tin cá nhân cần thiết nhƣ email, mật khẩu, tên đầy đủ, địa chỉ…và form này đƣợc đệ trình, khi đó Server sẽ tiến hành việc cập nhật các thông tin này vào cơ sở dữ liệu, trƣớc khi cập nhật, mật khẩu khách hàng sẽ đƣợc mã hoá bằng phƣơng pháp mã hoá DES (hoặc có thể là Triple – Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 80 DES, AES hay bất kỳ hệ mật mã khoá đối xứng nào khác để đảm bảo rằng mật khẩu của khách hàng đƣợc giữ kín). Nếu khách hàng đăng kí thành công thì hệ thống website sẽ gửi cho khách hàng một thông báo vào địa chỉ email mà khách hàng đã đăng kí kèm theo một khoá riêng private key dƣới dạng một file văn bản tex khách hàng phải lƣu giữ khoá riêng này nhƣ chữ kí số của riêng mình thông báo nhƣ sau: Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 81 2. Khách hàng lựa chọn mua hàng trên website Sau khi đã đăng kí là thành viên của website khách hàng mới có quyền chọn hàng và mua hàng trên trang giới thiệu các mặt hàng của website. Khách hàng lƣớt web, xem hệ thống cung cấp những mặt hàng nào, chủng loại nào, nếu tìm đƣợc hàng phù hợp thì thực hiện thao tác chọn mua hàng. Sau thao tác này, mặt hàng đƣợc chọn sẽ nằm trong một “đơn hàng”, và khách hàng có thể thay đổi lại đơn hàng theo các thao tác nhƣ: không chọn sản phẩm nào đó, thay đổi số lƣợng cần mua của mỗi sản phẩm, hủy toàn bộ đơn hàng Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 82 Sau khi chọn xong các sản phẩm, khách hàng thực hiện thao tác “Chấp nhận mua hàng”. Chức năng này thực hiện cập nhập dữ liệu về hàng hóa của khách hàng vào hệ thống các đơn hàng chờ đƣợc xử lý. Hệ thống website sẽ gửi cho khách hàng một thông báo về hoá đơn các mặt hàng mà khách hàng vừa chọn kèm theo các thông tin về giá cả và địa chỉ nhận hàng nhƣ sau: Khách hàng thực hiện kích hoạt theo đƣờng dẫn đã cung cấp trong email, tiếp đó hệ thống sẽ yêu cầu cung cấp khóa bí mật bằng cách khách hàng browse để chọn file chứa khóa bí mật, file private key này đã đƣợc hệ thống cung cấp khi thực hiện đăng ký. Hệ thống website sẽ xác thực khách hàng bằng khoá private key Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 83 và gửi lại cho khách hàng một thông báo có chứa đầy đủ hoá đơn mua hàng của khách hàng và tổng số tiền mà khách hàng phải trả từ tài khoản của mình. Kết thúc quá trình giao dịch mua bán máy tính thông qua dịch vụ INTERNET và tài khoản của cá nhân tại các ngân hàng Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên 84 kÕt luËn Với sự phát triển mang tính toàn cầu của mạng Internet và TMĐT, con ngƣời có thể giao tiếp dễ dàng trong một cộng đồng rộng lớn. Tuy nhiên đối với các giao dịch mang tính nhạy cảm, cần phải có cơ chế đảm bảo an toàn trong phiên giao dịch đó. Cần thiết hơn cả đó là mỗi bên cần xác định chính xác ngƣời mình đang giao tiếp có đúng là đối tác mong đợi hay không. Trong luận văn này, em đã đề cập đến hai kỹ thuật chính trong an toàn thông tin đó là mã hoá và ký số cùng với những vấn đề liên quan đến bảo mật ứng dụng Web. Hai kỹ thuật này cũng đƣợc áp dụng phần nào trong việc xác thực đối tác trong mỗi phiên giao dịch. Về kỹ thuật mã hoá, có hai phƣơng pháp: Mã hoá đối xứng và mã hoá khoá khoá công khai. Mã hoá đảm bảo an toàn về thông tin giao tiếp nhƣng không đảm bảo liệu thông tin có bị giả mạo hoặc có bị mạo danh hay không. Vấn đề chủ yếu nằm ở việc quản lý khoá mã hoá và giải mã ở cả hai phƣơng pháp mã hoá. Đối với phƣơng pháp ký số, dựa vào chữ ký cùng cặp khoá riêng và công khai, chúng ta có thể xác định chính xác đối tác trong giao dịch. Em cũng đã tìm hiểu hai loại chữ ký: Chữ ký kèm thông điệp và chữ ký sinh thông điệp cùng hai sơ đồ ký đƣợc chấp nhận và sử dụng rộng rãi: RSA, DSS. Có một vấn đề đặt ra đối với chữ ký số, liệu chúng ta có đảm bảo chính xác chữ ký hoặc khoá khoá công khai là thuộc đối tác hay không. Có rất nhiều cách tấn công vào chữ ký số, trong đó phổ biến là phƣơng pháp mạo danh chữ ký. Giải pháp khắc phục đƣa ra là sử dụng chứng chỉ số cho khoá khoá công khai nhằm đảm xác thực tính đúng đắn của đối tác trong giao dịch. Tuy nhiên, do điều kiện về mặt thời gian còn hạn chế, em không thể nghiên cứu kỹ lƣỡng về chứng chỉ số cho khoá công khai mà tập trung vào việc tìm hiểu một số các giao thức bảo mật ứng dụng web, cụ thể là cài đặt một số quy trình giao dịch sử dụng tới các phƣơng pháp mã hoá thông tin cũng nhƣ ký số. Em cũng đã cố gắng hết sức để phát triển ứng dụng theo mô hình thƣơng mại điện tử sử dụng SET, nhƣng do thực tế ở Việt Nam hiện nay không tồn tại một cách đầy đủ các thành phần tham gia SET, vì vậy ứng dụng sẽ gặp khó khăn khi triển khai trong thực tiễn. Trong thời gian tới, em sẽ tiếp tục phát triển đề tài với phƣơng hƣớng cụ thể nhƣ sau: Tiếp tục tìm hiểu hơn và thực nghiệm với một số phƣơng pháp mã hoá khoá đối xứng nhƣ Triple – DES, RC4, IDEA; các phƣơng pháp mã hoá khoá công khai nhƣ Elgamal, Rabin, Knapsack, Eliptic Curve. Cải tiến và nâng cao hiệu quả của các module đã cài đặt trên webssite cũng nhƣ các kỹ thuật cài đặt khác.