Các định dạng file của chứng chỉ X.509

Một phần của tài liệu bài giảng an toàn và bảo mật (Trang 116 - 120)

1) Dạng DER (.cer): nội dung của chứng chỉ X.509 được lưu dưới format DER, một định dạng dữ liệu binary chuẩn cho các môi trường máy tính.

Base64. Một file text PEM bắt đầu bằng dòng ---BEGIN CERTIFICATE--- và kết thúc bằng dòng ---END CERTIFICATE---

3) Dạng PKCS#7 (.p7c hay .p7b): là một định dạng dữ liệu được mã hóa hay ký. Do đó có đi kèm cả chứng chỉ.

4) Dạng PKCS#10 (.p10 hay .p10): là một định dạng dùng để gửi yêu cầu cấp chứng chỉ X509 đến trung tâm chứng thực. Định dạng này có ID và public key của người yêu cầụ

5) Dạng PKCS#12 (.p12): lưu trữ chứng chỉ X509 và private key tương ứng (có password bảo vệ) trong cùng 1 filẹ

6) Dạng PFX (.pfx): cũng lưu chứng chỉ X509 và private key theo định dạng của Microsoft.

Hình bên dưới là một chứng chỉ của Verisign được cung cấp dưới dạng PEM

109

7.3 GiaothứcbảomậtwebSecureSocketLayerversion3-SSLv3

Dữ liệu Web được trao đổi giữa trình duyệt và web server được thực hiện qua giao thức HTTP. Client kết nối với server qua socket của giao thức TCP/IP.

HTTP HTTP

HTTP Data

TCP/IP TCP/IP

Socket

Hình sau minh họa dữ liệu của giao thức HTTP khi thực hiện tìm kiếm từ “Nha Trang” trong website vn.search.yahoọcom.

GET /search?p=Nha+Trang&fcss=on&fr=yfp-t-101&toggle=1&cop=&ei=UTF-8 HTTP/1.1 Host: vn.search.yahoọcom

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.13) Gecko/2009073022 Firefox/3.0.13 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://vn.yahoọcom/?p=us

và hình dưới là dữ liệu phản hồi của server yahoọ Dữ liệu này gồm hai phần, phần đầu theo quy định của giao thức HTTP, phần sau là dữ liệu HTML.

110

HTTP/1.1 200 OK

Date: Fri, 14 Aug 2009 10:25:49 GMT Cache-Control: private

Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked

Connection: Keep-Alive Content-Encoding: gzip

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<html lang="vi"><head> … </head> ….

</html>

Giao thức SSL bảo mật dữ liệu trao đổi qua socket. Vì vậy nên có tên gọi là Secure Socket Layer (URL bắt đầu bằnghttps://). Đây là giao thức bảo mật kết hợp mã hóa khóa công khai và khóa đối xứng như đã trình bày trong phần 4.6.2 trong đó mã hóa RSA được dùng để trao đổi khóa phiên của mã hóa đối xứng.

1. CA

2. CB||NB

3. E(E(S,KRA), KUB)

A 4. H(KS) B

A 5. E(P||KS)

Mô hình này yêu cầu mỗi người duyệt web (A) và mỗi website (B) đều phải có cặp khóa riêng và khóa công khaị Hay nói cách khác website và người duyệt phải có chứng thực. Điều này sẽ gây khó khăn cho người duyệt web vì phải có chứng chỉ. Đây là yêu cầu cần thiết để đảm bảo tuyệt đối tính chứng thực cho cả hai phía website và người duyệt. Nghĩa là khóaKS phải xuất phát từ một người duyệt A cụ thể nào đó mà website biết, đồng thời khóaKS đến đúng website B chứ không phải là website khác.

111 Tuy nhiên trong thực tế không phải lúc nào cũng cần chứng thực từ phía người sử

dụng. Ví dụ, khi bạn mua hàng tại cửa hàng sách Amazon. Amazon không cần biết bạn là ai, chỉ cần bạn có tài khoản để mua hàng (việc bảo mật tài khoản người mua là trách nhiệm của mã hóa đối xứng). Do đó Amazon không cần chứng thực người duyệt web. Vì vậy trong trường hợp này, người duyệt không cần có chứng chỉ. Lúc này mô hình trao đổi khóa là: 1. IDA 2. CB||NB 3. E(S,KUB) A 4. H(KS) B A 5. E(P||KS)

Hình7-5.Sơđồtraođổikhóaphiênchỉcầnchứngthực1phía

Mô hình trên đảm bảo ngoài người duyệt A chỉ có website B là biết được khóa phiên

KS, còn A là ai thì website không cần biết. Để chứng thực người sử dụng, website có thể đơn giản lưu password của người sử dụng và chứng thực qua cơ chế login. Cách thức này hiện nay đang được sử dụng phổ biến hơn là phải yêu cầu người sử dụng cung cấp chứng chỉ chứng thực.

Giao thức SSL cho phép thực hiện cả hai khả năng trao đổi khóa nói trên.

Một phương pháp khác mà SSL cũng sử dụng để trao đổi khóa là phương pháp Diffie-Hellman. SSL có ba dạng Diffie-Hellman.

- Fixed Diffie-Hellman: là phương pháp trao đổi khóa Diffie-Hellman mà trong đó các yếu tố công khai (g,t) được chứng thực giống như chứng thực khóa công khai của RSẠ Điều này giúp ngăn chặn hình thức tấn công kẻ-đứng-giữạ

bảo vệ bằng mã hóa khóa công khai RSẠ Đây là hình thức Diffie-Hellman an toàn nhất.

- Anonymous Diffie-Hellman: Diffie-Hellman thường, do đó có thể bị tấn công theo hình thức kẻ-đứng-giữạ

Các phương pháp mã hóa đối xứng mà SSL có thể thực hiện là RC4, RC2, DES, 3DES, IDEA, AES. Hình sau đây minh họa mô hình đơn giản của giao thức SSL.

112

client

Pha 1: Chọn thuật toán mã hóa Pha 2: Server cung cấp chứng chỉ

Pha 3: Trao đổi khóa phiên

Pha 4: Hoàn tất bắt tay server

Truyền dữ liệu của giao thức HTTP

Do có thể áp dụng nhiều phương pháp mã hóa khác nhau nên đặc tả của giao thức SSL khá phức tạp. Phần tiếp theo sẽ chủ yếu trình bày giao thức SSL version 3 trong trường hợp sử dụng RSẠ SSL gồm có hai phần cơ bản là giao thức bắt tay và giao thức truyền dữ liệụ

Một phần của tài liệu bài giảng an toàn và bảo mật (Trang 116 - 120)

Tải bản đầy đủ (DOCX)

(194 trang)
w