CHƯƠNG III : BẢO MẬT THÔNG TIN TRONG THƯƠNG MẠI ĐIỆN TỬ
3.2. Chứng chỉ số và cơ chế mã hóa
3.2.4. Một số ứng dụng bảo mật trong thương mại điện tử
3.2.4.1. Cơ chế bảo mật SSL(Secure Socket Layer):
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:
- 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.
- 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. - Tính xác thực và tính tồ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 tốn tồ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ã hố 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 :
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 giao thức ứng dụng vốn sử dụng SSL.
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.
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) có 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. Ngồ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 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 tồn và sau đó với cổng khơng an tồ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.
Hình 3.1: Các bước SSL Record protocol
SSL Record Protocol nhận dử liệu từ các giao 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ã hố 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á). Sau cùng, mỗi bản SSL chứa các bản thông tin sau đây:
- Loại nội dung: xác định giao thức lớp cao hơn vốn phải được sử dụng để sau đó xử lý độ lớn dữ liệu bản ghi SSL (sau khi giải nén và giải mã hố 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 và tính tồn vẹn dữ liệu. Tương tự như thuật tốn mã hố, thuật tố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
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 đựơc 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.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
- Change Cipherpec 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 khố 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 rotocol đượ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ố 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 đó. Ngồ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.
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ầu 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 khố mật chính mà từ đó các khố session khác nhau dành cho viêc xác thực và mã hố thơng báo có thể được dẫn xuất từ đó.
3.2.4.2. Cơ chế bảo mật SET (Secure Electronic Transaction):
SET là một phương pháp bảo mật được xây dựng nhằm bảo đảm an tồ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 trong đó 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 tố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 tồn tuyệt đối với tất cả các thành viên trong quá trình giao dịch.
- 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.
Các yêu cầu thương mại đảm bảo an tồ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 tốn: Điều này cần thiết để đảm bảo người dùng thể giữ gìn an tồ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ã hố các cung cấp tin cậy này. - Đảm bảo tính tốn tồn vẹn đối với mọi dữ liệu được truyền đi: 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à kinh 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ó đủ cách đảm bảo an tồ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ã hố an tồ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 tồ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.
- 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 biế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.
- Tồ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 tố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 tồ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 nhà 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ã hố. Đâ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 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.
Hình 3.2: Các thành phần tham gia sử dụng SET
- 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 tố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 email 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.