It 045 Chung Chi So x509

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Bùi Văn Quý

CHỨNG CHỈ SỐ X.509

KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành : Tin học

Cán bộ hướng dẫn : PGS. TS Trịnh Nhật Tiến Cán bộ đồng hướng dẫn : CN. Nguyễn Đình Nam CN. Trương Thu Hiền

HÀ NỘI - 2005

Bùi Văn Quý – K46CC – Trường ĐH Công Nghệ - ĐHQGHN

TÓM TẮT KHOÁ LUẬN

Chuẩn chứng chỉ X.509 là chuẩn chứng chỉ số được công nhận bởi tổ chức quốc tế

ITU và ISO/IEC. Chứng chỉ số X.509 được sử dụng rộng rãi trong các hệ thống xác thực sử dụng mã hoá khoá công khai và công nghệ chữ ký số. Các dịch vụ xác thực sử dụng chứng chỉ số X.509 không những đảm bảo khả năng xác thực mà các thành phần bí mật sử dụng trong hệ thống còn đảm bảo các dịch vụ bảo mật khác như dịch vụ chống chối bỏ, phân quyền, bí mật…

Mỗi hệ thống sử dụng chứng chỉ bao gồm nhiều thành phần phức tạp( tuỳ thuộc vào cách xây dựng hệ thống ) như các tổ chức phát hành chứng chỉ, các tổ chức đăng ký chứng chỉ, các quy tắc phát hành và quản lý chứng chỉ, các kho chứa chứng chỉ… Tất cả tạo nên một cơ sở hạ tầng bảo mật khoá công khai.

Trong khoá luận này tôi xin đề cập đến các vấn đề về cơ sở hạ tầng bảo mật khoá công khai, chuẩn chứng chỉ X.509. Và nghiên cứu thư viện mã nguồn mở Openssl để xây dựng hệ thống quản lý chứng chỉ số trong giao thức kết nối bảo mật SSL.


MỤC LỤC

LỜI NÓI ĐẦU.....................................................................................................................1

CHƯƠNG 1 : TỔNG QUAN VỀ AN TOÀN HỆ THỐNG THÔNG TIN 1.1. Tổng quan về an toàn mạng thông tin.......................................................................3 1.2. Các mối đe doạ và giải pháp.......................................................................................5

1.2.1. Các mối đe doạ đối với hệ thống............................................................................5 1.2.2. Các giải pháp ..........................................................................................................8

1.3. Các dịch vụ an toàn thông tin.....................................................................................8 1.3.1. Dịch vụ xác thực ( Authentication ) .......................................................................8 1.3.2. Dịch vụ phân quyền ( Authorization )..................................................................11 1.3.3. Dịch vụ đảm bảo tính bí mật ( Confidentiality ) ..................................................11 1.3.4. Dịch vụ đảm bảo toàn vẹn thông tin ( integrity) ..................................................12 1.3.5. Dịch vụ đảm bảo chống chối bỏ ( Nonrepudiation) .............................................12 1.3.6. Dịch vụ đảm bảo hệ thống luôn sẵn sàng ( Availability) .....................................13

1.4. Chứng chỉ số...............................................................................................................13 1.4.1. Khái niệm chứng chỉ số ........................................................................................13 1.4.2. Phân loại chứng chỉ ..............................................................................................14 1.4.3. Ý nghĩa của chứng chỉ số .....................................................................................15

1.5. Danh sách thu hồi chứng chỉ ....................................................................................18 1.5.1. Lý do thu hồi chứng chỉ........................................................................................18 1.5.2. Khái niệm danh sách thu hồi chứng chỉ ...............................................................18 1.5.3. Phân loại danh sách thu hồi chứng chỉ .................................................................19 1.5.4. Cập nhật danh sách thu hồi chứng chỉ..................................................................20 1.5.5. Quản bá CRL........................................................................................................20

1.6. Nhà phát hành chứng chỉ..........................................................................................22 1.6.1. Các chức năng của CA .........................................................................................22 1.6.2. Cấu trúc phân cấp giữa các CA ............................................................................23 1.6.3. Chứng thực ngang (Cross Certification) ..............................................................25 1.6.4. Chính sách chứng chỉ ...........................................................................................25

1.7. Cơ sở hạ tầng bảo mật khoá công khai ...................................................................26 1.7.1. Các thành phần trong hệ thống PKI .....................................................................26 1.7.2. Chức năng của PKI...............................................................................................29

Tóm tắt chương : ..............................................................................................................32


CHƯƠNG 2 : CHUẨN CHỨNG CHỈ X.509 2.1 Cấu trúc chứng chỉ X.509 ..........................................................................................34

2.1.1. Các trường cơ sở của chứng chỉ X.509 ................................................................34 2.1.2. Các trường mở rộng của chứng chỉ X.509 ...........................................................36 2.1.3. Chữ ký của nhà phát hành chứng chỉ (Signature) ................................................43

2.2. Cấu trúc của danh sách thu hồi chứng chỉ X.509...................................................43 2.2.1. Các trường cơ bản của CRL X.509 ......................................................................44 2.2.2. Các trường mở rộng của CRL ..............................................................................47 2.2.3. Chữ ký của nhà phát hành CRL(Signature) .........................................................49

Tóm tắt chương : ..............................................................................................................49

CHƯƠNG 3 : SỬ DỤNG CÔNG NGHỆ XÁC THỰC SỐ SSL 3.1. Bảo mật tầng socket(Secure Socket Layer - SSL) ..................................................51

3.1.1. Khởi tạo phiên kết nối SSL. .................................................................................52 3.1.2. Giao thức bắt tay tuần tự ......................................................................................53 3.1.3. Truyền dữ liệu ......................................................................................................54 3.1.4. Kết nối HTTP bảo mật. ........................................................................................55

3.2. Xây dựng hệ thống quản lý chứng chỉ .....................................................................55 3.2.1. Cài đặt thư viện Openssl.......................................................................................55 3.2.2. Cấu hình Openssl..................................................................................................55 3.2.3. Tạo chứng chỉ cho CA..........................................................................................58 3.2.4. Tạo chứng chỉ cho client ......................................................................................58 3.2.6. Cấu hình server sử dụng kết nối SSL ...................................................................60

Tóm tắt chương : ..............................................................................................................61 KẾT LUẬN .......................................................................................................................62


2

BẢNG CÁC KÝ HIỆU VIẾT TẮT

Ký hiệu Từ viết tắt Ý nghĩa

CA Certification Authority Cơ quan phát hành chứng chỉ khóa công khai

CRL Certificate Revocation List Danh sách thu hồi chứng chỉ

DIT Directory Information Tree Cây thông tin thư mục

ISO International Standardization Organization Tổ chức chuẩn hóa quốc tế

ITU International Telecomunication Union

Hiệp hội truyền thông quốc tế

ITU-T ITU – Telecommunication Standardization Sector

Cơ quan chuẩn hóa truyền thông thuộc ITU

LDAP Lightweight Directory Access Protocol Dịch vụ thư mục.

PKI Public Key Infrastructure Cơ sở hạ tầng bảo mật khóa công khai.

PIN Personal Identify Number Số định danh người dùng

RA Registration Authority Nhà đăng ký chứng chỉ.

SSL Secure Socket Layer Giao thức truyền thông an toàn được phát triển bởi Nestcape.

X.500 Dịch vụ thư mục

X.509 Chuẩn chứng chỉ số phát triển bởi ITU-T


1

LỜI NÓI ĐẦU Ngay từ xa xưa ngành mật mã đã có một vị trí chiến lược trong các cuộc chiến

tranh vĩ đại. Để gửi những thông tin quan trọng cho các đội quân trong cùng một liên minh, người ta đã biết cách mã hoá những văn bản thông thường thành những văn bản mã , nhằm đảm bảo rằng nếu có bị đối phương phát hiện ra bản mã cũng không thể khôi phục được thông tin ban đầu, nếu như không biết được khóa bí mật. Qua nhiều cuộc chiến tranh, vai trò của mật mã càng quan trọng thì mật mã cũng phát triển theo và để lại những thành quả không nhỏ như các hệ mã hoá cổ điển Caesar, Playfair... Tất cả đã làm nền tảng cho ngành mật mã học ngày nay.

Ngày nay ngành mật mã đã sang trang mới. Từ áp dụng mã hoá cho các lĩnh vực quân sự đến việc áp dụng cho các mô hình bảo mật trong thương mại điện tử. Từ sử dụng hệ mã hoá cổ điển với các thao tác đơn giản đến những hệ mã hoá phi đối xứng sử dụng các thao tác toán học với những con số tương đối lớn (cỡ 21024). Việc ra đời các hệ mã hoá đối xứng không hề làm mất đi vai trò của các hệ mã hoá cổ điển mà nó còn bổ sung cho ngành mật mã nhiều phương pháp mã hoá mới và nhiều khái niệm mới ra đời ví dụ như chữ ký số, hàm băm, mã đại diện…cho đến chứng chỉ số.

Chứng chỉ số là kết quả của dự án phát triển chuẩn thư mục X.500 của ITU-T phát triển vào cuối những năm thập niên 90. Chứng chỉ số được ITU-T đặc tả trong tài liệu X.509 và dần được thay đổi qua các phiên bản cho phù hợp với thực tế. Chứng chỉ X.509 phiên bản 3 là phiên bản hiện tại được áp dụng sử dụng trong các hệ thống sử dụng chứng chỉ số.

Dịch vụ xác thực sử dụng chứng chỉ số X.509 là nền tảng để xây dựng các dịch vụ đảm bảo an toàn cho hệ thống. Toàn bộ nền tảng xây dựng dựa trên công nghệ xác thực X.509 được gọi là cơ sở hạ tầng bảo mật khoá công khai(PKI). Tuỳ từng hệ thống mà PKI có quy mô và độ phức tạp khác nhau. Tuy nhiên bất kỳ hệ thống nào cũng phải cung cấp các dịch vụ làm việc với chứng chỉ số, tạo điều kiện để phát triển các dịch vụ an toàn cho hệ thống.

Trong khuôn khổ của một khoá luận, tôi xin trình bày các vấn đề về an toàn thông tin, hệ thống sử dụng chứng chỉ X.509, chuẩn chứng chỉ X.509, dịch vụ xác thực X.509


2

và giới thiệu thư viện mã nguồn mở Openssl để xây dựng một cơ sở hạ tầng bảo mật khóa công khai sử dụng trong công nghệ kết nối bảo mật SSL.

Khoá luận bao gồm các phần cụ thể sau:

Lời mở đầu

Chương 1: Tổng quan về an toàn hệ thống thông tin

Chương 2: Chuẩn chứng chỉ X.509

Chương 3: Sử dụng công nghệ xác thực số SSL

Kết luận

Do thời gian tìm hiểu còn hạn chế nên bản khoá luận không tránh khỏi những thiếu sót. Tôi rất mong nhận được những ý kiến đóng góp quý báu từ Thầy cô, bạn bè…cũng như những ai quan tâm đến lĩnh vực này.

Cuối cùng tôi xin cảm ơn PGS.TS Trịnh Nhật Tiến, cử nhân Nguyễn Đình Nam, cử nhân Trương Thị Thu Hiền, các thầy cô, bạn bè, gia đình đã giúp đỡ cá nhân tôi trong suốt quá trình học tập để tôi hoàn thành khoá luận. Xin chân thành cảm ơn !

Hà nội, tháng 06 năm 2005

Bùi Văn Quý


3

Chương 1

TỔNG QUAN VỀ AN TOÀN HỆ THỐNG THÔNG TIN 1.1. Tổng quan về an toàn mạng thông tin Kết nối các máy tính trong mạng internet đảm bảo hai thuộc tính quan trọng là xử

lý phân tán và kết nối mở. Hình 1.1. biểu diễn một mô hình kết nối tổng quan giữa hai hệ thống thông qua mạng internet. Mỗi hệ thống có thể đơn giản chỉ là một máy tính đơn lẻ, cũng có thể là một mạng LAN với các trạm làm việc được kết nối với nhau. Quá trình xử lý một nhiệm vụ được phân phối cho cả hai hệ thống (ví dụ một hệ thống chuyên đảm nhiệm việc in ấn, hệ thống còn lại đảm nhiệm lưu trữ cơ sở dữ liệu). Mọi kết nối giữa hai hệ thống được hỗ trợ bởi mạng internet mang tính chất mở. Một cá nhân bất kỳ với những hiểu biết mạng khá, là có thể đứng giữa nghe ngóng những thông tin trao đổi giữa hai hệ thống mà không gặp bất kỳ khó khăn nào.

Như vậy kết nối internet tiềm ẩn rất nhiều mối đe dọa về an ninh. Ta xem xét đến một ví dụ trong thực tế - khi mô hình trên biểu diễn một Web brower và một Web server thì hệ thống tiềm ẩn những nguy cơ về an ninh sau:

- Nghe trộm trên đường truyền: Mọi thông tin liên lạc giữa web browser và web server đều có thể bị nghe trộm bởi kẻ thứ ba vì các thông tin không được bảo vệ trên đường truyền. Các thông tin bị mất có thể rất quan trọng (số PIN hay password) gây nguy cơ phá huỷ hệ thống.

- Thông tin bị sửa đổi: Trong quá trình truyền thông tin giữa web browser với server và ngược lại. Nếu không được giữ an toàn thì kẻ tấn công có thể chủ động thay đổi

Local Environment

Local Environment

internet

Hình 1.1. Mô hình kết nối máy tính thông qua mạng internet


4

thông tin hoặc trình tự các gói tin nhằm làm sai lạc thông tin dẫn đến những thảm họa không lường trước được.

- Server không an toàn: Cho dù đường truyền có thể được đảm bảo an toàn tuyệt đối. Thì nguy cơ server bị giả mạo cũng có thể diễn ra. Ví dụ như kẻ tấn công xây dựng một server không an toàn và thực hiện các giao dịch với khách hàng, trong quá trình giao dịch, người sử dụng có thể tiết lộ số tài khoản trong ngân hàng của họ. Và tất nhiên chẳng còn điều gì để nói khi đưa tiền cho kẻ ăn trộm.

- Chối bỏ dịch vụ: Một khả năng làm giảm độ an toàn của hệ thống là server không chịu thực thi yêu cầu từ client. Tuy nhiên lại không có bằng chứng gì để chứng minh rằng server đã thực hiện điều đó.

- Các đoạn mã nguy hiểm: Các đoạn mã có thể được download từ máy chủ về client để thực thi ví dụ như các java script. Việc download các đoạn mã không được xác thực có thể là một kẽ hở để kẻ tấn công gửi những chương trình nguy hiểm xuống máy tính client.

- Client không an toàn: Mặc dù khi nghe có vẻ không thực tế vì kết nối giữa client và server gần như một chiều. Tuy nhiên với các browser nguy hiểm vẫn có thể xâm nhập đến các thông tin nhạy cảm trên server, hoặc yêu cầu server thực hiện các thao tác không đảm bảo an toàn.

- Giả danh và giả mạo: Một người giả danh có thể có thể giả mạo là một người được phân quyền trong hệ thống và xâm nhập vào hệ thống với quyền hạn của đối tượng bị giả danh. Tương tự như thế một server cũng có thể bị giả danh bởi một server giả mạo khác. Một người kết nối tới server giả mạo nhưng lại lầm tưởng là mình đang thực hiện các dịch vụ trên một server an toàn ( trong quá trình đó người sử dụng có thể đem những thông tin nhạy cảm cho một server nguy hiểm).

Xã hội ngày nay gần như lệ thuộc vào máy tính và các tài nguyên tính toán. Việc tấn công vào các hệ thống thông tin có thể phá huỷ một hệ thống kinh tế và đồng thời cũng đem lại những thành quả không chính đáng cho những kẻ tấn công. Tiếp theo chúng ta xem qua các mối đe doạ, các giải pháp giả quyết và các nguy cơ tấn công có thể.


5

1.2. Các mối đe doạ và giải pháp 1.2.1. Các mối đe doạ đối với hệ thống Mối đe doạ là một đối tượng, là một con người cụ thể, hoặc có thể là một chương

trình máy tính hoặc một hiện tượng tự nhiên, một tai nạn hay một khái niệm của hệ thống làm nguy hại tới hệ thống. Một nguy cơ có thể là bên trong, như các thao tác cố tình phá huỷ hệ thống, hay tai nạn như đổ cà phê vào máy tình. Một nguy cơ cũng có thể đến từ bên ngoài tổ chức, hay các nhân viên có mối hận thù với công ty. Mối đe dọa có thể là chủ động ví dụ như làm ngưng dịch vụ của web server, hay thụ động như nghe trộm các tin gửi giữa các thành phần trong hệ thống. Vì lý do đó chúng ta sẽ nghiên cứu, phân tích các nguy cơ và đưa ra cách để bảo vệ các tài nguyên khỏi các nguy cơ.

1.2.1.1. Các mối đe doạ cố ý và các mối de doạ ngẫu nhiên Trong thực tế các tài nguyên máy tính bị thiệt hại phần lớn do các hỏng hóc đột ngột hay các đe dọa ngẫu nhiên nhiều hơn là các đe dọa có chủ tâm của con người. Các mối đe dọa ngẫu nhiên xảy ra hoàn toàn không có sự tính toán của con người tuy nhiên rất dễ xảy ra và hoàn toàn không biết trước được thời điểm cũng như từng mối đe dọa cụ thể tới khi nó xảy ra thực sự. Ví dụ như động đất, mất điện, lũ lụt...hay tai nạn bất thường. Để giảm thiểu các thiệt hại về tài nguyên thông tin do các đe dọa ngẫu nhiên gây ra đối với hệ thống, người ta thường lập một danh sách các phương án dự phòng cho từng mối đe dọa một nhằm có cách khắc phục rõ ràng khi nó xảy ra thực sự.

Các mối đe dọa cố ý là các mối đe dọa được tạo ra bởi con người với chủ ý phá hoại hệ thống thông tin nhằm một mục đích nào đó. Ví dụ như các gián điệp kinh tế, hay tống tiền, hoặc ăn cắp thông tin nhằm vụ lợi. Để giảm thiểu mối đe dọa cố ý, người ta xây dựng các giải pháp an ninh bao gồm các chính sách thắt chặt an ninh và xây dựng cơ chế xác thực.

1.2.1.2. Các mối đe dọa bên trong và bên ngoài. Theo thống kê, các vụ xâm nhập hệ thống từ bên trong chiếm tới 80% trong tổng

số các vụ xâm nhập trái phép. Các mối đe dọa bên trong chính là việc các nhân viên với quyền hạn của mình thực hiện các hành động với các quyền hạn cấp cao hơn mức thực tế. Mối đe dọa này có thể là một việc làm cố tình của một vài nhân viên không trung thực nhằm vụ lợi. Bởi so với những đối tượng bên ngoài thì họ đã có quyền hạn nhất định đối với hệ thống ví dụ như truy nhập trực tiếp vào hệ thống, cài đặt các chương trình không rõ


6

nguồn gốc (keylogger chẳng hạn) hoặc làm ngưng các dịch vụ của hệ thống như dịch vụ web server... Các mối đe dọa bên trong cũng có thể gây ra bởi các nhân viên do không hiểu biết về hệ thống nên vô tình gây ra những tổn hại cho hệ thống.

Các mối đe dọa bên ngoài là một cá nhân bên ngoài từ máy tính bên ngoài hệ thống, dựa vào những nhược điểm của hệ thống để truy cập trái phép vào hệ thống gây thiệt hại cho hệ thống. Việc kết hợp giữa tấn công bên ngoài và tấn công bên trong tạo nên các kịch bản tấn công đa dạng và nguy hiểm.

1.2.1.3. Các mối đe dọa thụ động và chủ động. Các mối đe dọa thụ động là các mối đe dọa gây ra do các hành động tấn công thụ

động. Các hành động tấn công thụ động là các hành động không giao tiếp trực tiếp với toàn bộ giao tác của hệ thống, hay thay đổi các trạng thái của hệ thống, mặc dù vậy họ có thể truy cập và lấy về các thông tin bí mật của hệ thống. Một ví dụ điển hình của hành động tấn công kiểu này là việc nghe trộm thông tin trên đường truyền. Kẻ tấn công có thể nghe ngóng những thông tin quan trọng trong phiên giao tiếp giữa web browser và web server nhưng nó không làm thay đổi trạng thái của hệ thống.

Trái lại với các mối đe dọa thụ động, các mối đe dọa chủ động, gây ra bởi các hành động tấn công chủ động của con người nhằm thay đổi trạng thái của hệ thống hoặc làm ngưng trệ dịch vụ trong hệ thống. Các nguy cơ chủ động được phân thành các nhóm sau:

Xâm phạm quyền hạn: Một người bên trong hệ thống sử dụng quyền hạn của mình để thực hiện các chức năng không cho phép. Đây là kiểu tấn công bên trong, nhưng một kẻ tấn công bên ngoài cũng có thể sử dụng các máy tính bị truy cập trái phép từ bên ngoài để thâm nhập và các thành phần quan trọng khác của hệ thống.

Can thiệp kết nối: Đây là nguy cơ mà kẻ tấn công can thiệp kết nối giữa một hoặc nhiều đối tượng trong hệ thống. Kẻ tấn công có thể thay đổi một phần hoặc xoá bỏ nội dung trao đổi giữa các đối tượng sau đó trả lại thông tin bị sửa đổi lên đường truyền, khi đó đối tượng nhận sẽ nhận được những thông tin giả mạo.

Chối bỏ dịch vụ: Các truy cập vào dữ liệu, tài nguyên, hay việc sử dụng dịch vụ có thể bị gây trở ngại bởi kẻ tấn công. Nguy cơ này có thể diễn ra một cách hoàn hảo bằng việc ngăn chặn đường truyền từ nơi yêu cầu dịch vụ, hoặc bằng cách làm tắc nghẽn đường truyền. Một ví dụ rất điển hình là nguy cơ kẻ tấn công làm ngập web server khi chúng liên tục gửi các gói tin cho server, khiến cho server dành tất cả tài nguyên của mình để nhận


7

những gói tin vô nghĩa, mà không thể thực hiện được các yêu cầu thực sự từ một web browser chính đáng khác.

Kẻ ở giữa: Đây là nguy cơ mà kẻ tấn công ở giữa kết nối của hai đối tượng trong hệ thống. Cả hai đối tượng kể trên hoàn toàn tin tưởng rằng mình đang kết nối trực tiếp với đối tượng còn lại mà không biết rằng thực sự là họ đang kết nối với kẻ thứ ba. Đó chính là kẻ tấn công.

Giả mạo: Một kẻ giả mạo có thể giả danh một đối tượng có quyền để truy cập vào các thông tin được bảo vệ. Một biến thể khác của nguy cơ này là khi một người được phân quyền nhưng giả danh một người có quyền khác để cố gắng truy cập vào các phần thông tin có mức phân quyền cao hơn... Nguy cơ này thường kết hợp với các kiểu tấn công khác để thâm nhập qua các rào cản của hệ thống.

Lặp lại : Việc gửi lại các thông tin nhiều lần có thể tạo ra nguy cơ bị tấn công. Ví dụ như một kẻ tấn công gửi lại các đoạn thông tin được gửi bởi một phía tin cậy có thể làm cho hệ thống tin rằng kẻ tấn công chính là đối tượng được tin cậy tạo lên việc giả mạo người dùng.

Chối bỏ: Một bên trong phiên kết nối không thừa nhận hành động của mình và nguồn gốc dữ liệu sử dụng trong phiên kết nối. Điều này rất nguy hiểm khi sảy ra tranh chấp.

Đầu độc: Đầu độc là một thủ đoạn mà kẻ tấn công xâm phạm vào quá trình xác thực dịch vụ, làm cho những người sử dụng không biết và đưa ra các thông tin nhạy cảm của mình cho kẻ lừa đảo mà cứ ngỡ là mình đang giao tiếp với một hệ thống an toàn. Các thông tin nhạy cảm có thể là password, hoặc số thẻ tín dụng…

Thâm nhập hệ thống: Kẻ tấn công cố gắng thâm nhập vào hệ thống thông qua các acount của người được phân quyền hoặc tấn công vào các điểm yếu của hệ thống. Ban đầu kẻ tấn công sẽ thâm nhập vào các máy tình không được bảo vệ hoặc được bảo vệ kém. Sau đó từ máy tính này kẻ tấn công sẽ tấn công các máy tính có phân quyền cao hơn.

Ngựa Trojan: Là một chương trình được kẻ tấn công cài đặt vào máy tính nạn nhân, khi nhận được các thông tin nhạy cảm, có thể là nội dung mail hay user, password nó liền gửi những thông tin đó cho kẻ tấn công.


8

1.2.2. Các giải pháp Các giải pháp là các phương tiện vật lý, các quy tắc và chính sách để ngăn chặn

các nguy cơ tấn công hoặc giảm thiểu các thiệt hại do cuộc tấn công gây ra. Một giải pháp trong thực tế là các thông tin được mã hóa trước khi được gửi đi thông qua một mạng không an toàn. Tuy nhiên hệ thống thường bị tấn công tại các điểm yếu ( do hacker tìm ra) do đó phải đảm bảo an toàn tại tất cả các vị trí có nguy cơ bị tấn công bao gồm an toàn máy tính, an toàn kết nối, an toàn vật lý...Chỉ một khâu trong hệ thống không được bảo vệ đều có thể dẫn đến nguy cơ bị tấn công.

Các dịch vụ an toàn thông tin cung cấp các giải pháp an toàn cho máy tính và các kết nối. Các dịch vụ an toàn thông tin ngăn cản, phát hiện các nguy cơ tấn công từ những hacker như giả mạo quyền truy cập, hoặc can thiệp vào các kết nối... Trong phần tiếp theo chúng ta sẽ đề cập đến các dịch vụ an toàn thông tin.

1.3. Các dịch vụ an toàn thông tin Trong thực tế người ta thấy rằng các dịch vụ an toàn thông tin bao gồm sáu dịch

vụ. Mỗi dịch vụ đảm nhiệm một công việc rõ ràng. Các dịch vụ đó là:

• Dịch vụ xác thực ( Authentication )

• Dịch vụ phân quyền ( Authorization )

• Dịch vụ đảm bảo tính bí mật ( Confidentiality )

• Dịch vụ đảm bảo toàn vẹn thông tin ( integrity)

• Dịch vụ đảm bảo chống chối bỏ ( Nonrepudiation)

• Dịch vụ đảm bảo hệ thống luôn sẵn sàng ( Availability)

Việc kết hợp các dịch vụ sẽ tạo nên một giải pháp tổng thể chống lại các nguy cơ an toàn thông tin.

1.3.1. Dịch vụ xác thực ( Authentication ) Dịch vụ xác thực đảm bảo các đối tượng tham gia phiên kết nối có danh tính như

được thừa nhận. Các đối tượng yêu cầu kết nối có thể là một cá nhân, chương trình máy tính, một thiết bị mà danh tính của nó đã được kiểm định. Đối tượng được yêu cầu kết nối muốn xác thực đối tượng yêu cầu kết nối, chúng sử dụng giấy uỷ nhiệm để chứng minh


9

danh tính của đối tượng yêu cầu kết nối. Các dịch vụ xác thực cung cấp các giải pháp chống lại các nguy cơ tấn công ở giữa, giả dạng, và ngụy trang.

Dịch vụ xác thực là một dịch vụ cực kỳ quan trọng trong hệ thống. Trước hết để một đối tượng tham gia vào kết nối nó phải được xác thực danh tính với hệ thống. Với mỗi danh tính đó tương ứng là quyền hạn được quy định trong hệ thống. Và dựa vào danh tính người ta còn dùng làm bằng chứng để thực hiện dịch vụ chống chối bỏ. Ngoài ra trong giao thức xác thực người ta trao đổi với nhau một thành phần bí mật mà chỉ có các bên tham gia giao tiếp mới có. Chính thành phần bí mật này sẽ đảm bảo tính bí mật và tính toàn vẹn của hệ thống.

1.3.1.1. Phân loại dịch vụ xác thực Có hai loại xác thực là xác thực danh tính và xác thực nguồn gốc thông tin.

Trong xác thực danh tính, bất kỳ đối tượng nào muốn tham gia vào kết nối đều có một danh tính cụ thể (mỗi danh tính gắn liền với một quyền hạn nhất định trong hệ thống). Dịch vụ xác thực danh tính sẽ chứng minh hoặc bác bỏ danh tính của đối tượng tham gia vào kết nối nhờ đó có thể phân quyền cụ thể cho đối tượng.

Trong dịch vụ xác thực nguồn gốc thông tin, dịch vụ sẽ đưa ra những chứng cớ để chứng minh rằng thông tin trong hệ thống là do đối tượng nào gửi đi, và chỉ có thể là đối tượng đó gửi đi chứ không phải bất kỳ một đối tượng nào khác.

Trong dịch vụ xác thực danh tính đối tượng, có hai loại là xác thực một chiều và xác thực nhiều chiều. Xác thực một chiều là việc kiểm tra danh tính của một phía tham gia kết nối (trong kết nối có thể hai hoặc nhiều đối tượng tham gia) vì các đối tượng tham gia còn lại có thể không cần xác thực. Nếu tất cả các đối tượng tham gia kết nối đều phải được xác thực thì đó là xác thực nhiều chiều. Một ví dụ là kết nối giữa một browser và một web server hỗ trợ kết nối SSL. Khi đó web server cần được xác thực để những người dùng trên các web browser được đảm bảo rằng mình đang giao tiếp với chính xác server mà mình yêu cầu, vì rất có thể trong quá trình giao tiếp người dùng cung cấp các thông tin nhạy cảm của mình cho phía còn lại, ví dụ như số tài khoản ngân hàng chẳng hạn. Ngược lại web server cũng muốn xác thực web browser để chống lại các nguy cơ tấn công nguỵ trang, giả mạo từ phía các web browser.


10

1.3.1.2. Các giao thức xác thực Trong quá trình một người truy cập vào các thiết bị như máy tính hay thẻ thông

minh, thì hệ thống phải xác thực danh tính của đối tượng truy cập thông qua những giao thức xác thực phức tạp. Để đảm bảo an toàn thì các giao thức này phải sử dụng các hàm mã hoá được thực tế chứng minh là an toàn, và sử dụng khoá mật mã có độ dài đủ lớn nhằm tránh những kiểu tấn công khóa.

Giao thức chứng minh không tiết lộ thông tin : Trong giao thức này, đối tượng sở hữu một giá trị khoá bí mật (mà chỉ có anh ta mới có). Trong quá trình xác thực, hệ thống cung cấp cho đối tượng truy cập một giá trị "khởi tạo" ngẫu nhiên. Sau đó đối tượng truy cập sẽ sử dụng khoá bí mật của mình thực hiện các thao tác mật mã trên giá trị "khởi tạo" nhằm thu được một giá trị "trả lại" và trả về cho hệ thống. Hệ thống sử dụng giá trị "trả lại" để xác thực danh tính của đối tượng cần xác thực. Vì giá trị "trả lại" còn phụ thuộc vào một giá trị ngẫu nhiên của hệ thống nên trong phiên xác thực sau giá trị "trả lại" sẽ không cùng giá trị với giá trị "trả lại" ở phiên xác thực trước, như vậy tránh được nguy cơ tấn công lặp lại.

Giao thức biến đổi mật khẩu : Trong giao thức biến đổi mật khẩu, đối tượng truy cập sẽ trả lại một giá trị băm của mật khẩu cho hệ thống. Hệ thống muốn xác thực danh tính của đối tượng truy cập, nó so sánh giá trị băm này với giá trị băm mà nó lưu trong cơ sở dữ liệu. Nếu hai giá trị giống nhau thì danh tính của đối tượng được xác thực. Giao thức này đảm bảo tránh các nguy cơ nghe trộm trên đường truyền nhưng không chống lại được nguy cơ tấn công lặp lại cũng như giả mạo người dùng.

Giao thức mật khẩu sử dụng một lần : Giao thức này đảm bảo các khả năng của cả hai giao thức trên. Trong giao thức này cả hệ thống và đối tượng cần được xác thực đều sở hữu giá trị khoá và một giá trị bí mật n. Trong mỗi phiên giao tiếp giá trị khoá được băm n lần. Và đối tượng cần xác thực cung cấp cho hệ thống giá trị băm này. Trên hệ thống xác thực cũng thực hiện băm số lần tương tự với giá trị khoá, và so sánh hai kết quả, nếu giống nhau tức là đối tượng được xác thực. Một điểm quan trọng của giao thức là giá trị bí mật n sử dụng trong phiên xác thực này cần được hai bên tính toán trong phiên giao trước. Như thế không có sự lặp lại các giá trị xác thực tránh được nguy cơ tấn công nghe trộm mật khẩu trên đường truyền và cả nguy cơ tấn công lặp lại. Thuật toán tính giá trị n cần chú ý rằng n>0. Nếu n = 0 thì phải thay đổi lại giá trị n cho phù hợp vì nếu n = 0


11

có nghĩa là ta đang truyền mật khẩu thực sự trên đường truyền mà không có sự bảo vệ nào từ việc sử dụng hàm băm.

Giao thức sử dụng chứng chỉ số : Đây là một dạng khác của chứng minh không tiết lộ thông tin. Trong giao thức này đối tượng cần xác thực sở hữu một giá trị khoá riêng . Nó sử dụng khoá riêng này để mã hoá giá trị "khởi tạo" của hệ thống xác thực, giá trị "trả lại" chính là bản mã của giá trị "khởi tạo". Hệ thống xác thực dùng khoá công khai (trong chứng chỉ số) tương ứng với khoá riêng đó để giải mã giá trị "trả lại" nếu kết quả thu được trùng với giá trị "khởi tạo" thì đối tượng được xác thực.

1.3.2. Dịch vụ phân quyền ( Authorization ) Trong một hệ thống người ta thường phân ra các quyền truy cập vào hệ thống khác

nhau ví dụ như quyền đọc dữ liệu, quyền thay đổi nội dung dữ liệu, quyền thực thi chương trình, quyền sử dụng máy in. Với mỗi hệ thống thì chính sách phân quyền không nhất thiết giống nhau do tài nguyên khác nhau, đối tượng sử dụng cũng khác nhau.

Mỗi một đối tượng trong hệ thống đều có vị trí, vai trò khác nhau; do đó quyền truy cập vào hệ thống cũng không thể giống nhau. Việc phân quyền thực hiện ngay sau khi đối tượng tham gia vào hệ thống được xác thực danh tính. Với mỗi danh tính đó người ta gắn cho một quyền nhất định, và phụ thuộc vào chính sách phân chia tài nguyên hệ thống theo quyền hạn mà đối tượng đó được sử dụng. Chính dịch vụ phân quyền này đảm bảo cho hệ thống tránh khỏi các cuộc đột nhập trái phép vào hệ thống và nguy cơ tấn công xâm phạm quyền hạn.

1.3.3. Dịch vụ đảm bảo tính bí mật ( Confidentiality ) Dịch vụ này đảm bảo rằng dữ liệu không bị tiết lộ cho bên thứ ba. Dữ liệu được

lưu trong máy tính hoặc truyền đi từ máy tính này qua máy tính khác cho nên việc tránh các nguy cơ can thiệp kết nối là nhiệm vụ quan trọng nhất của dịch vụ này.

Để thực hiện việc truyền tin bí mật giữa hai đối tượng, các kỹ thuật mà dịch vụ này sử dụng đó là kỹ thuật mã hoá đầu cuối ( end - to - end ) và kỹ thuật mã hoá liên kết ( link - to - link ).

Trong mã hoá đầu cuối các thao tác bảo mật được thực hiện ngay tại 2 hệ thống đầu cuối. Dữ liệu được mã hoá ngay tại điểm gửi đi của hệ thống. Sau khi tới điểm nhận mới được giải mã. Kỹ thuật này tỏ ra đơn giản vì chỉ phải lưu giữ một khoá bí mật cho hai


12

đầu cuối và các thao tác mã hoá, giải mã chỉ cần thao tác một lần. Tuy nhiên trong kỹ thuật này vẫn tiềm ẩn nhiều nguy cơ tấn công. Vì các gói tin gửi trên mạng vẫn có các thông tin tường minh về nơi gửi do đó không đảm bảo tính bí mật trên đường truyền.

Trong mã hoá liên kết các thao tác mã hoá được thực hiện tại các điểm liên kết trong hệ thống. Vì các gói tin truyền trên mạng thông qua các điểm liên kết tin cậy, nên nó được giải mã trở lại và được mã hoá sau đó truyền xuống mạng không tin cậy. Kỹ thuật này rất phức tạp và tốn nhiều tài nguyên của hệ thống tại vì tương ứng với mỗi điểm liên kết là một thao tác mã hoá và giải mã tương ứng. Mặc dù hạn chế được nhược điểm của kỹ thuật mã hoá đầu cuối nhưng vẫn tồn tại nguy cơ tấn công tại các điểm liên kết khi mà các gói tin đã được giải mã về nguyên bản ban đầu.

Trên thực tế người ta áp dụng linh hoạt cả hai kỹ thuật này vào trong dịch vụ đảm bảo tính bí mật để chúng bổ sung cho nhau. Trong mô hình mở OSI mã hoá liên kết được thực hiện tại tầng vật lý và mã hoá đầu cuối được thực hiện từ tầng mạng trở lên.

1.3.4. Dịch vụ đảm bảo toàn vẹn thông tin ( integrity) Đảm bảo toàn vẹn thông tin nhằm chống lại việc thay đổi thông tin từ phía kẻ tấn

công ví dụ như chỉnh sửa nội dung thông tin, nhân bản thông tin, thêm các đoạn thông tin mới, hay thay đổi trình tự các gói tin. Bên cạnh đó dịch vụ đảm bảo toàn vẹn thông tin còn đảm bảo tính chất đơn nghĩa của dữ liệu. Dịch vụ này tạo ra khả năng chống lại các nguy cơ tấn công lặp lại, can thiệp kết nối.

Dịch vụ đảm bảo toàn vẹn thông tin là một phần rất quan trọng, trong nhiều trường hợp hệ thống không cần đảm bảo tính bí mật mà việc đảm bảo tính toàn vẹn thông tin mới thực sự cần thiết. Ví dụ như trong các giao dịch điện tử việc đảm bảo rằng thông tin không bị sửa đổi và đảm bảo tính đơn nghĩa của dữ liệu là cần thiết, còn tính bí mật của thông tin thì không cần thiết.

1.3.5. Dịch vụ đảm bảo chống chối bỏ ( Nonrepudiation) Dịch vụ này ngăn cản một phía trong phiên kết nối phủ nhận sự tham gia toàn bộ

hay bộ phận của mình trong chính phiên kết nối đó. Đây là một tình huống mà trong cuộc sống thực tế cũng luôn xảy ra khi một bên nào đó phủ nhận nội dung cuộc giao kèo, thời gian giao kèo, hoặc danh tính của người đối diện. Dịch vụ đảm bảo chống chối bỏ sẽ tập hợp các chứng cớ trong phiên kết nối để làm tiêu tan sự nghi ngờ cũng như chống lại các nguy cơ chối bỏ từ một phía kết nối.


13Hình 1.2. Mô hình chứng chỉ số

Chống chối bỏ bao gồm hai phần chính là chống chối bỏ bên gửi, và chống chối bỏ bên nhận. Kỹ thuật chống chối bỏ bên gửi có nghĩa vụ chống lại các nguy cơ phủ nhận từ phía đối tượng gửi, ví dụ phủ nhận nội dung thông tin đã gửi, thời gian gửi... Tương tự như thế kỹ thuật chống chối bỏ bên nhận cũng có nghĩa vụ chống lại các nguy cơ phủ nhận từ phía đối tượng gửi, ví dụ như phủ nhận nội dung đã nhận, thời gian gửi, và đôi khi là cả danh tính của người gửi.

1.3.6. Dịch vụ đảm bảo hệ thống luôn sẵn sàng ( Availability) Trong bất kỳ hệ thống máy tính nào( bao gồm cả phần cứng, phần mềm và dữ liệu)

tính sẵn sàng hoạt động luôn được nhắc đến. Khi có một sự cố bất thường hệ thống phải được khôi phục một cách nhanh chóng và đầu đủ để tiếp tục thực hiện dịch vụ mà nó đựơc yêu cầu.

Dịch vụ đảm bảo hệ thống luôn sẵn sàng đảm bảo hệ thống luôn trong trạng thái sẵn sàng sử dụng khi có yêu cầu của một đối tượng được xác thực mà không bị ngăn cản hay bị tạm ngưng do một lý do nào khác. Để được như vậy có hai điều cần cân nhắc đó là chính sách quản trị hệ thống phải thận trọng rõ ràng, và thiết kết hệ thống phải chất lượng. Nhờ dịch vụ này mà nguy cơ tất công từ chối dịch vụ bị loại bỏ.

1.4. Chứng chỉ số 1.4.1. Khái niệm chứng chỉ số Khái niệm : Chứng chỉ số là một đối tượng bao gồm khoá công khai của thực thể

và các thông tin định danh của thực thể. Hai thành phần này gắn kết với nhau thông qua chữ ký của nhà phát hành chứng chỉ.

Thông tin định danh của thực

thể

Khóa công khai của thựcthể

Chữ ký của

nhà phát hành chứng chỉ

Thuật toán ký

Khóa bí mật của nhà phát hành chứng chỉ


14

Chứng chỉ số hay còn được gọi là chứng khóa công khai, ID số, hay đơn giản là chứng chỉ. Ở khoá luận này chúng ta sử dụng từ "chứng chỉ số" để chỉ khái niệm phía trên mà ta mới trình bày. Đối tượng được xác thực trong chứng chỉ được gọi là đối tượng của chứng chỉ.

Một chứng chỉ số tương tự như một chiếc bằng lái xe. Mỗi chiếc bằng lái gồm ảnh của người sở hữu với các thông tin định danh của người đó ( như tên, địa chỉ, chữ ký...). Hai thông tin này được xác thực có mối quan hệ với nhau thông qua con dấu của cơ quan phát hành bằng lái. Thông qua con dấu của cơ quan phát hành bằng lái mà bất kỳ ai cũng biết được đối tượng sở hữu nó có đủ khả năng để vận hành một chiếc xe. Chứng chỉ số cũng thế. Nó đảm bảo một cách chính xác đối tượng với những thông tin định danh tường minh trên nó sở hữu một khoá bí mật tương ứng. Dựa vào điều kiện trên mà đối tượng có thể truy cập vào các hệ thống xác thực, hoặc thực hiện các kết nối an toàn.

Rõ ràng chứng chỉ số chỉ có ý nghĩa khi nó đựơc ký bởi nhà phát hành chứng chỉ. Bởi nếu không có chữ ký của nhà phát hành chứng chỉ thì không có mối liên hệ giữa khoá công khai của thực thể và thông tin định danh; đồng nghĩa chứng chỉ số vô giá trị. Như vậy chứng chỉ số phải tồn tại trong một hệ thống mà ở đó nhà phát hành chứng chỉ là một nhân tố quan trọng. Mặt khác chứng chỉ cũng có thời gian sử dụng nhất định nên nó cần được thu hồi khi cần thiết và trạng thái thu hồi của chứng chỉ cũng phải được công bố rộng rãi cho toàn bộ hệ thống thông qua danh sách thu hồi chứng chỉ (CRL - Certificate Revocation List). Tóm lại để sử dụng chứng chỉ số thì hệ thống cần đảm bảo đầy đủ cơ sở hạ tầng như hệ thống các nhà cấp phát chứng chỉ, các kho chứa chứng chỉ, các chính sách áp dụng, các phần cứng hỗ trợ...Tất cả tạo nên một cơ sở hạ tầng bảo mật khoá công khai(PKI - Public Key Inftrastructure). Các khái niệm về danh sách thu hồi chứng chỉ, các nhà phát hành chứng chỉ và cơ sở hạ tầng bảo mật sẽ được đề cập trong phần tiếp theo của chương này.

1.4.2. Phân loại chứng chỉ Chứng chỉ số không mang tính chất đa năng, cũng tương tự như việc một người có

bằng lái xe máy, không đồng nghĩa với việc anh ta có thể lái được ô tô. Mỗi chứng chỉ số


15

chỉ có tác dụng trong một phạm vi xác định. Dựa vào mục đích sử dụng người ta chia chứng chỉ số ra làm các loại sau:

Cá nhân : Sử dụng bởi một con người cụ thể. Chứng chỉ loại này được sử dụng chủ yếu cho mục đích đảm bảo an toàn trong các kết nối với môi trường internet như bảo mật mail, hay các giao dịch web.

Tổ chức : Đây là loại chứng chỉ sử dụng cho mục đích xác thực là chính. Trong các tổ chức, công ty sử dụng công nghệ chứng chỉ số đảm bảo xác thực các nhân viên một cách chính xác là dựa trên yếu tố: các thông tin định danh của người sử dụng được nhà phát hành chứng chỉ xác nhận thông qua chữ ký của mình.

Máy chủ : Chứng minh quyền sở hữu một tên miền, cung cấp một phiên kêt nối https an toàn giữa server và client. Trong mô hình một mạng LAN, thì chứng chỉ số đảm bảo việc xác thực và các kết nối an toàn giữa các host.

Người phát triển :Chứng chỉ số còn cung cấp giir pháp chứng minh quyền tác giả, nguồn gốc phần mềm và đảm bảo tính toàn vẹn của chương trình phần mềm được cung cấp trên mạng internet công khai.

1.4.3. Ý nghĩa của chứng chỉ số Chứng chỉ số ra đời giải quyết rất nhiều vấn đề quan trọng trong các mô hình xác thực, đảm bảo an toàn cho hệ hệ thống. Dưới đây là các lợi ích khi sử dụng công nghệ xác thực bằng chứng chỉ số.

1.4.3.1. Xác thực Xác thực là dịch vụ quan trọng nhất trong các dịch vụ đảm bảo an toàn, các thành phần bí mật sử dụng trong dịch vụ này còn là nền tảng cho các dịch vụ còn lại. Xác thực bằng chứng chỉ có những ưu điểm mà các mô hình xác thực khác không có được.

1.4.3.1.1. Các cơ chế xác thực

Trong mô hình xác thực bằng chứng chỉ. Người sử dụng có thể xác thực anh ta bằng cách trình cho hệ thống chứng chỉ của chính mình. Thông qua chữ ký của nhà phát hành chứng chỉ trên khoá công khai và các thông tin định danh, anh ta có thể chứng minh rằng mình đang sở hữu một khoá riêng tương ứng. Khoá riêng thường là một giá trị rất lớn ( thông thường người ta sử dụng khoá riêng với giá trị vào khoảng 21024 ). Với giá trị


16

như thế, nó thường được lưu trong các file được bảo vệ bởi mật khẩu, hoặc trong các phần cứng như thẻ thông minh.

Các file hay thẻ thông minh được bảo vệ bởi mật khẩu hoặc số PIN. Để xác thực chính mình. Anh ta phải đưa ra những thông tin về mật khẩu hoặc số PIN mà chỉ có anh ta mới biết, với thông tin đó, hệ thống mới có thể có được khoá riêng. Thông qua các thao tác toán học hệ thống chứng minh sự tương ứng giữa khoá riêng và khoá công khai có trong chứng chỉ. Mặt khác khoá công khai và các thông tin định danh được gắn kết với nhau thông qua chữ ký của nhà phát hành chứng chỉ nên danh tính của anh ta được xác thực.

Cơ chế cuối cùng là sử dụng các giao thức mã hoá với thẻ thông minh để chứng minh rằng người sử dụng sở hữu khoá riêng tương ứng. Khoá riêng được lưu trong thẻ thông minh. Hệ thống xác thực cung cấp một thông tin. thẻ thông minh sử dụng khoá riêng mã hoá thông tin đó và gửi trả lại cho hệ thống. Hệ thống sử dụng khoá công khai trên chứng chỉ giải mã để lấy lại thông tin ban đầu. Nếu hai thông tin là giống nhau thì chứng tỏ một điều – thẻ thông minh có chứa một khoá riêng tương ứng. Như thế người sử dụng được xác thực.

Việc ứng dụng cơ chế nào cho hệ thống là tuỳ thuộc vào cơ sở hạ tầng vật lý và hoàn cảnh ứng dụng mà ta sử dụng.

Mặc dù xác thực bằng chứng chỉ có ba cơ chế. Nhưng tất cả đều phải được xây dựng trên sự tin tưởng vào nhà phát hành chứng chỉ. Vì nếu chứng chỉ bị giả mạo hay nhà phát hành chứng chỉ làm giả chứng chỉ, thì hệ thống của ta sụp đổ hoàn toàn. Như vậy về bản chất cơ chế xác thực có được là do chữ ký của nhà phát hành chứng chỉ, tức là nhà phát hành chứng chỉ đã chứng minh các thông tin định danh của người sử dụng thông qua chữ ký của mình.

1.4.3.2. Phân phối khoá an toàn

Làm thế nào để có được một khoá công khai của đối tượng bất kỳ? Xét một ví dụ như Alice và Bob muốn trao đổi bí mật với nhau, như thế Alice phải có được khoá công khai của Bob để thực hiện việc mã hoá thông điệp. Nếu như việc phân phối khoá công khai của Bob cho Alice không được bảo vệ thì một bên thứ ba là Eve có thể thay khoá công khai của Bob bằng khoá công khai của mình để thực hiện tấn công ở giữa.


17

Chứng chỉ số đưa ra một cách giải quyết vấn đề này. Thông qua chữ ký của mình, nhà phát hành chứng chỉ xác nhận mỗi một đối tượng ứng với một cặp khoá riêng / công khai tương ứng. Trong ví dụ của chúng ta Alice có thể thu nhận được khoá công khai của Bob bằng cách lấy chứng chỉ của Bob tại các nơi chứa chứng chỉ. Alice hoàn toàn tin tưởng vào khoá công khai này vì nó đã được nhà phát hành chứng chỉ đảm bảo.

Các chứng chỉ có thể được lưu trữ tại các vị trí không được bảo vệ. Vì bất kỳ thay đổi thông tin nào trên chứng chỉ(cả thông tin định danh và khoá công khai trên chứng chỉ) đều có thể bị phát hiện, Và bên nhận hoàn toàn có thể kiểm tra được sự thay đổi này một cách dễ dàng, bằng thuật toán kiểm tra chữ ký của nhà phát hành trên chứng chỉ. Tương tự như thế, chứng chỉ cũng không cần phân phối trên các kênh truyền được bảo vệ. Chính hai yếu tố này làm cho việc phân phối khoá trở nên đơn giản. Và quá trình phân phối khoá hoàn

toàn có thể diễn ra một cách an toàn thông qua mạng công khai như Internet.

1.4.3.3. Xử lý độc lập tại máy khách

Chứng chỉ là một cấu trúc mở, tuỳ từng ứng dụng mà ta thêm các trường thông tin cho những mục đích riêng biệt. Như vậy khi các chương trình client sử dụng chứng chỉ ngoài việc xác thực, chúng còn có thể quyết định các hành vi của mình dựa vào các trường dữ liệu có trên chứng chỉ.

Một ví dụ rất điển hình là máy rút tiền tự động ATM. Nó sử dụng chứng chỉ số để xác thực khách hàng. Ngân hàng phát hành chứng chỉ để quản lý các khách hàng, với mỗi khách hàng tương ứng với một chứng chỉ. Trên chứng chỉ có nhiều thông tin điều khiển, mà thông tin quan trọng nhất là thông tin về tổng tiền của người khách hàng. Mỗi khi khách hàng yêu cầu rút tiền từ các máy ATM, thì việc xử lý hoàn toàn không cần phải liên hệ với hệ thống chung tâm của ngân hàng. Dựa vào các trường thông tin trên chứng chỉ, hệ thống trên ATM hoàn toàn có thể giao dịch với khách hàng mà vẫn đảm bảo chính xác và an toàn.

Xử lý tại client là một yếu tố quan trọng vì nó giúp cho việc xây dựng các hệ thống đơn giản mà vẫn đảm bảo an toàn. Các giải thuật mã hoá công khai là một gánh lặng tính toán cho các hệ thống trung tâm, vì chúng phải xử lý các con số có giá trị rất lớn. Việc xử lý tại client đồng nghĩa với việc các hệ thống trung tâm được giảm bớt gánh nặng xử lý. Như thế hệ thống sẽ tránh được các nguy cơ về an ninh như nghẽn mạch hay từ chối dịch vụ.


18

1.5. Danh sách thu hồi chứng chỉ 1.5.1. Lý do thu hồi chứng chỉ Trong vòng đời của chứng chỉ, Mặc dù nó vẫn trong thời gian được tin cậy nhưng

nó vẫn có thể bị nhà phát hành chứng chỉ thu hồi bởi rất nhiều lý do. Ví dụ như việc thoả hiệp khoá riêng của các đối tượng chứng chỉ hay thoả hiệp khoá riêng của nhà phát hành chứng chỉ, hay việc thay đổi các thông tin định danh của đối tượng.

Khoá riêng của đối tượng sử dụng chứng chỉ bị thoả hiệp dẫn tới việc sử dụng cặp khoá riêng, và công khai của đối tượng là không an toàn, đối tượng cần được thay thế bộ khoá riêng, công khai khác; như vậy đồng nghĩa với việc cấp lại chứng chỉ cho đối tượng đó. Nhưng các ứng dụng sử dụng chứng chỉ phải biết rằng chứng chỉ cũ không còn hiệu lực, và như vậy chứng chỉ cũ cần được thu hồi.

Nếu khoá riêng của nhà phát hành chứng chỉ bị thoả hiệp, có nghĩa là quá trình kiểm tra chữ ký của nhà phát hành chứng chỉ là không an toàn, mọi chứng chỉ được ký bởi nhà phát hành này đều có nguy cơ bị giả mạo. Như vậy tất cả chứng chỉ đựơc ký bởi nhà phát hành cần được thu hồi lại và tiến hành cấp phát mới.

Bên cạnh đó, lý do chứng chỉ được thu hồi bởi đối tượng sử dụng chứng chỉ thay đổi các thông tin định danh cũng xảy ra thường xuyên( ví dụ như thay đổi tên miền, ip...). Vì các thông tin trên chứng chỉ được ký bởi nhà phát hành chứng chỉ nên khi thay đổi thông tin định danh của đối tượng dẫn tới chữ ký trên chứng chỉ không còn giá trị nữa, như vậy chứng chỉ cũ cần được thu hồi và phát hành chứng chỉ mới.

Hệ thống cần có một kỹ thuật để truyền tải các trạng thái thu hồi chứng chỉ cho các ứng dụng sử dụng chứng chỉ. Trên thực tế các nhà phát hành chứng chỉ tạo ra các danh sách thu hồi chứng chỉ để công bố những chứng chỉ bị thu hồi

1.5.2. Khái niệm danh sách thu hồi chứng chỉ Danh sách thu hồi chứng chỉ (Certificate Revocation List - CRL) là một kỹ thuật

mà các nhà phát hành chứng chỉ dùng để công bố thông tin về các chứng chỉ được thu hồi cho các ứng dụng sử dụng chứng chỉ. Mỗi CRL là một cấu trúc dữ liệu chứa thông tin về thời điểm phát hành CRL, thông tin định danh của nhà phát CRL, và toàn bộ số serial của các chứng chỉ bị thu hồi cho tới thời điểm phát hành CRL...Toàn bộ các thông tin trên được xác thực bằng chữ ký của nhà phát hành chứng chỉ.


19

Trong quá trình sử dụng chứng chỉ, các ứng dụng sử dụng chứng chỉ sẽ lấy về CRL ở thời điểm hiện tại và phải đảm bảo rằng số hiệu của chứng chỉ mình sử dụng không có trong danh sách thu hồi chứng chỉ. Nếu số hiệu của chứng chỉ đang sử dụng tồn tại trong CRL hiện tại đồng nghĩa với việc là chứng chỉ đó đã bị thu hồi bởi một lý do nào đó. Và việc sử dụng chứng chỉ là không đảm bảo an toàn.

1.5.3. Phân loại danh sách thu hồi chứng chỉ - CRL đầy đủ và hoàn chỉnh : Đây là loại CRL đặc trưng nhất với khái niệm

danh sách thu hồi chứng chỉ. Nó chứa thông tin về tất cả chứng chỉ bị thu hồi bởi nhà phát hành CA. Trên thực tế không phải bao giờ người ta cũng dùng loại CRL này vì kích thước của nó phụ thuộc vào lượng chứng chỉ bị thu hồi, và theo lý thuyết thì đến một lúc nào đó dung lượng của nó lại là một vấn đề cần giải quyết khi nó được lưu trữ, tải về tại nhiều vị trí khác nhau.

- CRL thực thể cuối đầy đủ và hoàn chỉnh : Để giảm tải kích thước của một file chứa CRL đầy đủ ở trên người ta sử dụng loại CRL này. Đây là loại CRL chỉ chứa những chứng chỉ bị thu hồi bởi nhà phát hành chứng chỉ cho các thực thể sử dụng( không bao gồm các chứng chỉ của nhà phát hành chứng chỉ cấp dưới nếu chúng bị thu hồi).

- CRL nhà phát hành chứng chỉ đầy đủ và hoàn chỉnh : Đây là loại CRL chỉ chứa các chứng chỉ của nhà phát hành chứng chỉ cấp dưới bị thu hồi( có ý nghĩa bổ xung cho loại CRL trên).

- CRL con : Là một danh sách chứng chỉ bị thu hồi không đầy đủ, chúng chỉ chứa thông tin về những chứng chỉ bị thu hồi theo một tiêu chí nào đó tùy nhà phát hành quy định cho mỗi loại CRL. Ví dụ như CRL chỉ chứa thông tin về những chứng chỉ bị thu hồi do thỏa hiệp khóa, hoặc CRL chỉ chứa thông tin về những chứng chỉ thu hồi do thay đổi thông tin định danh của chủ thể...

- Delta – CRL : Là loại CRL chỉ chứa thông tin về những chứng chỉ mới được thu hồi kể từ lần phát hành CRL trước. Như vậy để kiểm tra chính xác chứng chỉ đã bị thu hồi chưa thì hệ thống không những cần bản Delta – CRL này mà còn cả bản CRL toàn bộ và đầy đủ ở lần phát hành CRL trước. Tuy nhiên việc sử dụng bản Delta- CRL sẽ làm giảm tải dung lượng trên đường truyền.


20

1.5.4. Cập nhật danh sách thu hồi chứng chỉ Để giúp cho các hệ thống sử dụng chứng chỉ có được thông tin về những chứng chỉ

bị thu hồi, CRL cần được thường xuyên cập nhật, có thể theo chu kỳ hàng giờ, hàng ngày, hàng tuần hay lâu hơn. Điều này phụ thuộc vào hệ thống mà ta xây dựng. Nếu như chu kỳ cập nhật CRL quá dài sẽ dẫn đến trường hợp các chương trình sử dụng chứng chỉ sẽ sử dụng những chứng chỉ đã bị thu hồi và như thế làm cho quá trình kết nối không đảm bảo an toàn. Còn nếu chu kỳ cập nhật CRL ngắn, sẽ dẫn tới việc các chương trình sử dụng chứng chỉ, mỗi khi đến chu kỳ cập nhật CRL, lại yêu cầu hệ thống ( hoặc tự thực hiện ) kiểm tra xem chứng chỉ mà nó đang sử dụng có bị thu hồi hay không. Do chu kỳ ngắn nên mật độ các yêu cầu này đối với hệ thống là lớn, điều này có thể gây ra nhiều rắc rối bởi cơ sở hạ tầng vật lý, dung lượng đường truyền không cho phép thực hiện nhiều yêu cầu cùng một lúc.

1.5.5. Quản bá CRL Các chương trình sử dụng chứng chỉ muốn có được thông tin về trạng thái thu hồi

của chứng chỉ mà nó sử dụng. Nó hoàn toàn có thể sử dụng một trong ba phương thức quảng bá thông tin CRL mà hệ thống cấp phát chứng chỉ cung cấp. Dưới đây sẽ phân tích qua về ba phương thức đó.

1.5.5.1. Bỏ phiếu danh sách thu hồi chứng chỉ Trong phương thức bỏ phiếu chứng chỉ, chương trình sử dụng chứng chỉ chủ động

truy cập vào kho chứa CRL và lấy về bản CRL mới nhất. Các bản CRL có thể được lưu trữ và được lấy về trên các kênh truyền không an toàn, nhưng do được ký bởi nhà phát hành chứng chỉ nên mọi thay đổi thông tin trên CRL đều được phát hiện thông qua việc kiểm tra tính toàn vẹn của CRL.

Với phương thức này hệ thống sử dụng chứng chỉ cần biết được thời điểm tiếp theo mà CRL được cập nhật. Thời điểm cập nhật tiếp theo phải được xác nhận trong mỗi bản CRL hiện thời để các chương trình có thể cập nhật thông tin chính xác về trạng thái thu hồi của chứng chỉ mà nó đang sử dụng.

Phương thức bỏ phiếu CRL bộc lộ một vài nhược điểm. Đó là nếu trong chu kỳ cập nhật CRL, chứng chỉ bị thu hồi thì trạng thái thu hồi của nó chỉ được ghi nhận ở lần công bố bản CRL tiếp theo. Như thế các hệ thống sử dụng chứng chỉ hoàn toàn không biết về trạng thái bị thu hồi thực sự của chứng chỉ, làm cho hệ thống sử dụng chứng chỉ không an


21

toàn mà vẫn nhầm tưởng rằng chúng còn giá trị. Một giải pháp là giảm bớt thời gian của chu kỳ cập nhật, tuy nhiên cũng chỉ đến một mức nào đó. Bởi đến một giới hạn, thì chương trình sử dụng chứng chỉ không thể thực hiện được việc cập nhật vì chu kỳ của nó quá ngắn.

1.5.5.2. Đẩy các CRL cho ứng dụng đầu cuối CA có thể đẩy CRL xuống cho từng ứng dụng như là quá trình nó thu hồi chứng

chỉ vậy. Mỗi khi có sự thay đổi trong CRL là hệ thống CA sẽ sử dụng phương pháp broadcast gửi phiên bản CRL mới nhất đến cho tất cả các ứng dụng sử dụng chứng chỉ. Và quá trình gửi này hoàn toàn không có chu kỳ như phương pháp bỏ phiếu bởi nó phụ thuộc vào quá trình chứng chỉ bị thu hồi, do đó giải quyết được nhược điểm của phương pháp bỏ phiếu CRL.

Tuy nhiên phương pháp này cũng có rất nhiều hạn chế. Thứ nhất việc gửi tin Broadcast phải đảm bảo rằng các CRL phải đến được đúng đích, nếu một ứng dụng trong hệ thống không có được phiên bản CRL mới nhất thì nó có thể thực hiện các giao dịch không đảm bảo. Thứ hai việc gửi CRL broadcast tới nhiều đích có thể làm quá tải đường truyền. Cuối cùng và quan trọng hơn là làm thế nào để có thể broadcast tới tất cả các ứng dụng khác nhau, mà mỗi ứng dụng khác nhau chưa chắc đã có cùng giao thức kết nối. Việc quản lý các chương trình đầu cuối là cực kỳ khó khăn. Và điều này là tất yếu trong thực tế.

1.5.5.3. Kiểm tra trạng thái thu hồi trực tuyến Các ứng dụng có thể thực hiện một yêu cầu trực tuyến tới CA để kiểm tra trạng

thái thu hồi của chứng chỉ mà nó đang sử dụng. Phương thức này tỏ ra ưu điểm hơn so với hai phương thức kia. Thứ nhất chúng loại bỏ thời gian chết gây ra bởi chu kỳ cập nhật chứng chỉ. Thứ hai chúng hoàn toàn không gây quá tải đường truyền, bởi dữ liệu truyền trên mạng chỉ là các truy vấn. Và điều quan trọng hơn là không cần thêm hệ thống xác định, quản lý các ứng dụng sử dụng chứng chỉ, bởi các yêu cầu kiểm tra trạng thái chứng chỉ là theo chuẩn và hệ thống CA không cần quan tâm tới cơ chế làm việc của từng ứng dụng một.

Tuy nhiên hệ thống CA phải đảm bảo luôn sẵn sàng khi có yêu cầu từ ứng dụng bất kỳ. Hơn thế nữa hệ thống CA còn phải thực hiện rất nhiều thao tác số học phức tạp


22

với các con số lớn do đó yêu cầu về nền tảng vật lý của CA là cao hơn rất nhiều so với hai phương pháp ban đầu.

1.6. Nhà phát hành chứng chỉ Nhà phát hành chứng chỉ gọi tắt là CA (Certification Authority) là hạt nhân của hệ

thống PKI. Chỉ có CA mới có quyền phát hành chứng chỉ cho một đối tượng sau khi kiểm tra những thông tin về đối tượng đó. Trong hệ thống PKI, CA đóng vai trò là một bên thứ ba mà các ứng dụng sử dụng chứng chỉ trong hệ thống phải tin tưởng. Muốn kiểm tra chữ ký của CA trên chứng chỉ, hệ thống sử dụng khoá công khai của nhà phát hành CA được CA tự chứng thực hoặc được chứng thực bởi một CA khác mà hệ thống tin tưởng.

Mỗi chứng chỉ có một thời gian sống nhất định. Sau khoảng thời gian này chứng chỉ cần được thu hồi và cấp phát mới cho đối tượng sử dụng. Mặt khác do một điều kiện nào đó việc sử dụng chứng chỉ là không còn hợp lệ ví dụ như khoá bí mật của chủ thể chứng chỉ bị tiết lộ; chứng chỉ cần được thu hồi. Nhà phát hành chứng chỉ cần quản lý trạng thái thu hồi của chứng chỉ để chương trình sử dụng đầu cuối sử dụng chứng chỉ một cách an toàn.

Như vậy CA không những quản lý chứng chỉ khi nó được khởi tạo mà CA còn phải quản lý cả chứng chỉ trong quá trình sử dụng.

1.6.1. Các chức năng của CA 1.6.1.1. Xác thực yêu cầu cấp phát chứng chỉ Đây là quá trình kiểm tra thông tin định danh, cũng như cặp khoá mã hoá của đối

tượng yêu cầu cấp phát chứng chỉ. Quy trình diễn ra tuỳ thuộc hệ thống mà ta xây dựng. Việc xác minh này có thể được thực hiện gián tiếp thông qua một bên trung gian, như các trung tâm đăng ký địa phương, hoặc xác minh trực tiếp thông qua tiếp xúc trực tiếp.

1.6.1.2. Phát hành chứng chỉ Sau khi xác minh thông tin định danh, khoá mã hoá của đối tượng yêu cầu chứng

chỉ, hoặc nhận được yều cầu từ một LRA, CA tiến hành cấp phát chứng chỉ cho đối tượng. Tuỳ thuộc vào chính sách của CA mà chứng chỉ sau khi tạo sẽ được đưa đến một kho chứa công khai để các ứng dụng lấy chứng chỉ về sử dụng.


23

1.6.1.3. Phân phối chứng chỉ Nhà phát hành chứng chỉ còn cung cấp các dịch vụ để các hệ thống sử dụng chứng

chỉ truy cập và lấy về các chứng chỉ mà nó cần. Các dịch vụ này rất đa dạng nhưng sử dụng phổ biến nhất là dịch vụ email và dịch vụ thư mục LDAP.

1.6.1.4. Thu hồi chứng chỉ Khi một chứng chỉ được yêu cầu huỷ bỏ, hoặc do một nguyên nhân nào đó mà việc

sử dụng chứng chỉ không còn an toàn, thì CA phải thu hồi chứng chỉ đó và phải thông báo cho toàn bộ hệ thống biết danh sách các chứng chỉ bị thu hồi cho toàn hệ thống thông qua các CRL.

1.6.1.5. Treo chứng chỉ Trong trường hợp CA phát hiện ra các dấu hiệu khả nghi việc sử dụng chứng chỉ là

không còn an toàn nữa thì CA sẽ phải treo chứng chỉ, tức là chứng chỉ đó bị thu hồi tạm thời, nhưng nếu CA tìm được thông tin chứng minh rằng việc sử dụng chứng chỉ vẫn đảm bảo an toàn thì chứng chỉ sẽ được thay đổi lại trạng thái bị thu hồi.

1.6.1.6. Gia hạn chứng chỉ Trong trường hợp chứng chỉ hết thời hạn sử dụng, nhưng chứng chỉ vẫn đảm bảo

tính bí mật khi sử dụng, thì nó có thể được cấp lại( tùy thuộc vào yêu cầu của chủ thể chứng chỉ). Tức là gia hạn thêm thời gian sử dụng cho chứng chỉ. Chứng chỉ được cấp mới không có gì thay đổi, ngoại trừ trường thời gian hết hạn được thay, tất nhiên là kéo theo cả chữ ký của nhà phát hành chứng chỉ cũng thay đổi.

1.6.1.7. Quản lý trạng thái chứng chỉ Thông qua các CRL không những giúp cho các nhà phát hành chứng chỉ quảng bá

thông tin về những chứng chỉ bị thu hồi mà còn giúp cho CA quản lý trạng thái thu hồi của chứng chỉ. Việc quản lý trạng thái thu hồi này là rất quan trọng. Vì nếu các ứng dụng đầu cuối sử dụng những chứng chỉ bị thu hồi thì hệ thống không còn an toàn nữa.

1.6.2. Cấu trúc phân cấp giữa các CA Trong một PKI đơn giản có thể chỉ có một nhà phát hành chứng chỉ CA cung cấp

tất cả các dịch vụ cho đối tượng sử dụng chứng chỉ trong hệ thống. Tuy nhiên mô hình này không thích hợp trong cộng đồng lớn người sử dụng. Bởi việc quản lý quá nhiều chứng chỉ sẽ là gánh lặng về kỹ thuật cho CA, như việc kiểm tra thông tin định danh của


24

người sử dụng là rất khó khăn, bên cạnh đó sự khác biệt về cơ sở hạ tầng mạng vật lý (do điều kiện vật lý và điều kiện kinh tế quy định) của các cộng đồng nhỏ trong cộng đồng lớn làm cho việc tương thích của một hệ thống CA với tất cả hạ tầng vật lý là điều không thể. Ví dụ như cộng đồng vật lý sử dụng Linux, cộng đồng người sử dụng windows, cộng đồng sử dụng hệ thống mạng vật lý chất lượng cao và cộng đồng sử dụng mạng vật lý chất lượng kém. Trong thực tế hệ thống PKI bao gồm nhiều CA khác nhau. PKI phải cung cấp các dịch vụ để đảm bảo sự tin tưởng giữa các CA này.

Cấu trúc giữa các CA trong một mô hình PKI phụ thuộc vào cộng đồng người sử dụng, tính chất của các ứng dụng sử dụng chứng chỉ và phạm vi địa lý mà hệ thống được triển khai.

1.6.2.1. Cấu trúc cây Trong cấu trúc này tất cả các đối tượng sử dụng chứng chỉ phải tin tưởng vào một

CA gốc( Root CA). Mỗi một CA có quyền cấp phát chứng chỉ cho các CA phía dưới nó, hoặc một đối tượng sử dụng cuối, đồng thời CA này phải được xác thực từ CA cấp trên, tức là CA này phải tin tưởng CA cấp trên của nó. Kết quả tạo lên một cây phân cấp các nhà phát hành chứng chỉ.

CA1

CA2

CA5 CA7

CA3

CA8CA4 CA6

s1 s2 s3 s4 s5 s6 .......................

Hình1.3 : Cấu trúc cây phân cấp giữa các CA

Root CA


25

Khi hai đối tượng sử dụng trong hai CA khác nhau yêu cầu xác thực lẫn nhau, thì sẽ tồn tại một đường dẫn xác thực duy nhất thông qua sự tin tưởng vào các CA cấp trên.

1.6.2.2. Cấu trúc rừng CA Trong thực tế, không thể bắt buộc tất cả đối tượng sử dụng trong PKI tin tưởng vào

một root CA. Thay vào đó tuỳ theo vị trí địa lý, lĩnh vực hoạt động, yêu cầu hệ thống mà mỗi cộng đồng người sử dụng chỉ tin tưởng vào một root CA cụ thể. Vậy làm thế nào để hai đối tượng sử dụng trong hai phân cấp cây khác nhau có thể xác thực được nhau? Muốn xác thực được thì hai root CA bất kỳ phải tin tưởng lẫn nhau, tức là chúng phải xác thực lẫn nhau.

Cấu trúc này vẫn đảm bảo xác thực giữa hai đối tượng bất kỳ. Tuy nhiên đường dẫn chứng thực phức tạp và có thể dẫn tới bế tắc theo một đường xác thực nào đó.

1.6.3. Chứng thực ngang (Cross Certification) Trong mô hình của PKI, việc chứng thực giữa hai đối tượng được xác thực bởi một CA là đơn giản. Một phía bất kỳ chỉ việc kiểm tra chữ ký của CA trên chứng chỉ của đối tượng còn lại, vì CA là thành phần thứ ba mà cả hai bên đều tin cậy, nên sự xác nhận của CA trên đối tượng còn lại cũng được tin cậy.

Trong mô hình phức tạp, việc chứng thực giữa hai đối tượng được xác thực giữa hai CA khác nhau được gọi là chứng thực ngang. Cơ sở của việc chứng thực này không những phụ thuộc vào sự tin tưởng của hai đối tượng với CA cấp phát chứng chỉ mà còn phụ thuộc vào sự tin tưởng lẫn nhau giữa hai CA ấy. Tức là hai CA phải chứng thực lẫn nhau thông qua sự xác thực của CA cấp trên. Quá trình trên sẽ dừng đến khi nào tìm được một CA mà cả hai bên đều tin tưởng.

1.6.4. Chính sách chứng chỉ Chính sách chứng chỉ chính là các quy định về phạm vi mà chứng chỉ được tin

tưởng. Các chứng chỉ được sử dụng trong mục đích khác nhau thì được quy định phạm vi sử dụng khác nhau.

Khi CA cấp phát chứng chỉ nó sẽ ghi nhận luôn các chính sách sử dụng trong chứng chỉ. Các thông tin ghi nhận về chính sách trên chứng chỉ là các OID được CA định


26

nghĩa và phải được đăng ký với hệ thống PKI. Mỗi khi sử dụng chứng chỉ, tất cả các ứng dụng đều phải tuân theo những chính sách này để được sự bảo trợ từ phía CA.

1.7. Cơ sở hạ tầng bảo mật khoá công khai Khái niệm: Cơ sở hạ tầng bảo mật khoá công khai ( Public Key Infrastructure – PKI ) là một tập hợp phần cứng, phần mềm, chính sách, thủ tục cần thiết để tạo, quản lý và lưu trữ, phân phối và thu hồi các chứng chỉ số dựa trên công nghệ mã hoá khoá công khai.

Mã hoá và chữ ký số đã trở thành một phần không thể thiếu được đối với thương mại điện tử cũng như các lĩnh vực đòi hỏi an toàn và bảo mật. PKI cung cấp cơ sở hạ tầng giúp cho việc sử dụng mã hoá và chữ ký số một cách dễ dàng và trong suốt đối với người sử dụng.

PKI là một khái niệm mô tả toàn bộ nền tảng cơ sở nhằm cung cấp các dịch vụ quản lý truy cập, tính toàn vẹn, tính xác thực, tính bí mật và tính chống chối bỏ. Nền tảng này bao gồm các hệ thống phần mềm như nhà phát hành chứng chỉ, kho chứa dữ liệu, phần cứng sử dụng hỗ trợ trong quá trình trao đổi khoá, các chính sách ...

PKI đảm bảo cho các giao dịch điện tử cũng như những phiên kết nối bí mật được an toàn dựa trên công nghệ mã hoá khóa công khai.

1.7.1. Các thành phần trong hệ thống PKI

Hình1.4 Mô hình hệ thống PKI


27

1.7.1.1. Nhà phát hành chứng chỉ Nhà phát hành chứng chỉ CA là hạt nhân của hệ thống PKI. Thông qua CA hệ

thống PKI mới có thể quản lý được khóa và chứng chỉ. CA là cơ quan duy nhất có quyền phát hành và thu hồi chứng chỉ. Đồng thời áp đặt các chính sách đối với chứng chỉ mà nó phát hành. Trong một hệ thống PKI không chỉ tồn tại một nhà phát hành chứng chỉ mà có thể là một hệ thống các nhà phát hành chứng chỉ(Như đã đề cập trong phần 2.3). Các CA này quan hệ được với nhau thông qua chứng chỉ xác nhận của các CA ngang hành cho mình hoặc bởi CA cấp trên.

1.7.1.2. Cơ quan đăng ký chứng chỉ (Registration Authority - RA) Trong các hệ thống với phạm vi vật lý rộng lớn, việc CA chứng nhận thông tin

định danh của đối tượng là rất khó khăn. Một giải pháp cho vấn đề này là CA sử dụng các cơ quan đăng ký địa phương - RA làm đại diện cho CA trong một cộng đồng nhỏ. Các RA không trực tiếp phát hành chứng chỉ, hay quản lý chứng chỉ mà nó chỉ thực hiện công việc xác nhận những thông tin người dùng cho CA. Đồng thời RA cũng có thể thay mặt người sử dụng yêu cầu CA phát hành, thu hồi, thay đổi thông tin trên chứng chỉ.

Các chức năng của RA:

- Nhận các yêu cầu cấp phát chứng chỉ từ phía người dùng, chứng nhận các thông tin trên yêu cầu đó.

- Gửi yêu cầu phát hành chứng chỉ đến CA. Nhận các chứng chỉ từ CA và trao nó cho chủ thể chứng chỉ.

- Nhận yêu cầu thu hồi chứng chỉ từ phía người dùng, kiểm tra yêu cầu thu hồi và gửi những yêu cầu này cho CA.

1.7.1.3. Chủ thể chứng chỉ Là đối tượng được CA cấp phát chứng chỉ để chứng nhận những thông tin định

danh về đối tượng, đồng thời còn chứng minh rằng đối tượng sở hữu một khoá bí mật tương ứng khoá công khai trong chứng chỉ.


28

Đối tượng ở đây có thể là một CA, RA, một con người, một thiết bị phần cứng hay một đối tượng cụ thể... Trong vai trò chủ thể của chứng chỉ mỗi đối tượng có những quyền sau trong hệ thống.

- Sinh cặp khoá : Để được cấp phát chứng chỉ chủ thể có thể yêu cầu được cấp phát cặp khóa công khai/bí mật. Mặc dù nếu PKI áp dụng mô hình này sẽ đảm bảo việc quản lý khóa dễ dàng, và hệ thống sinh khóa tập trung có thể tận dụng được khả năng của hệ thống để có thể sinh ra những cặp khóa có chất lượng. Nhưng quá trình phân phối khóa an toàn lại phức tạp và khó đảm bảo an toàn. Ngoài ra việc sinh khóa bí mật ở một ví trí thứ ba có thể đánh mất đi tính riêng tư cho chủ thể chứng chỉ. Nên trong thực tế nhiều mô hình PKI còn áp dụng mô hình sinh khóa tại máy khách, tức là đối tượng sở hữu chứng chỉ có thể tự sinh và trọn lựa cặp khóa công khai/bí mật được ghi nhận trong chứng chỉ.

- Yêu cầu cấp phát chứng chỉ: Sau khi tạo được cặp khóa công khai/bí mật, đối tượng yêu cầu chứng chỉ có quyền yêu cầu một trung gian RA , hoặc yêu cầu trực tiếp với CA để được cấp phát chứng chỉ. Sau khi xác thực những thông tin mà đối tượng yêu cầu chứng chỉ cung cấp, nhà phát hành chứng chỉ CA có thể ký, cung cấp một chứng chỉ mới cho đối tượng yêu cầu chứng chỉ.

- Yêu cầu thu hồi chứng chỉ : Khi đối tượng sử dụng chứng chỉ không cần chứng chỉ nữa, hoặc khả nghi việc lộ mất khóa bí mật, chủ thể chứng chỉ hoàn toàn có quyền yêu cầu hệ thống thu hồi chứng chỉ của chính nó.

- Yêu cầu thay đổi thông tin trên chứng chỉ : Tức là thay chứng chỉ cũ bằng chứng chỉ mới nhưng giữ nguyên các trường thông tin, chỉ thay đổi những trường thông tin theo yêu cầu của chủ thể chứng chỉ.

1.7.1.4. Ứng dụng sử dụng chứng chỉ Giá trị của PKI là cung cấp cho đối tượng sử dụng đầu cuối sử dụng chữ ký số và

mã hoá số. Các chương trình sử dụng chứng chỉ cung cấp dịch vụ đảm bảo tính trong suốt cho người sử dụng. Nó thực hiện các thao tác xác thực chứng chỉ, quản lý chứng chỉ từ phía người dùng, sử dụng chứng chỉ cho những mục đích mã hoá, ký số của người sử dụng.

Các chương trình sử dụng chứng chỉ là đối tượng phục vụ chính của PKI. PKI được xây dựng để đảm bảo rằng các ứng dụng có thể tìm kiếm thông tin cần thiết một cách nhanh chóng và chính xác nhất.


29

1.7.1.5. Kho chứa chứng chỉ Các chứng chỉ, các bản CRL và các thông tin liên quan đến chúng cần được lưu trữ

công khai để các chương trình sử dụng chứng chỉ truy cập và lấy về những thông tin cần thiết. Như vậy kho chứa chứng chỉ cũng là một thành phần trong hệ thống PKI. Kho chứa chứng chỉ còn đảm bảo những thông tin được lưu trữ trên nó là hoàn toàn chính xác và tính nhất quán(ví dụ như đảm bảo CRL phát hành đúng hạn).

Trong những năm gần đây các hệ thống thư mục LDAP( Lightweight Directory Access Protocol) là một giải pháp hữu hiệu cho kho chứa chứng chỉ có cấu trúc cây thông tin thư mục(Directory Information Tree). Mỗi một nút thư mục trong cây đại diện cho một chứng chỉ trong PKI. Các thư mục con đại diện cho chứng chỉ được chứng thực bởi nhà phát hành với chứng chỉ ở thư mục gốc. Nội dung của thư mục chính là con trỏ tới chứng chỉ và CRL tương ứng được lưu trữ trong hệ thống LDAP. Các thuộc tính của thư mục chỉ ra các thông tin liên tới chứng chỉ mà nó đại diện ví dụ như các chính sách chứng chỉ, đường dẫn chứng thực.

1.7.2. Chức năng của PKI 1.7.2.1. Quản lý khoá Thông thường việc quản lý khoá được CA thực hiện thông qua việc quản lý chứng

chỉ. Chức năng này bao gồm các chức năng sinh khoá, quản lý khoá trong quá trình sử dụng, thu hồi khi khoá không còn hiệu lực và phụ hồi khoá khi xảy ra sự cố trong hệ thống.

a ) Sinh khoá

Khoá sinh ra phải đảm bảo về chất lượng (khó tấn công bằng phương pháp vét cạn), tính duy nhất trong hệ thống và tính bí mật. Việc sinh khoá phụ thuộc vào chính sách của PKI dưới đây là 3 cách mà hệ thống sử dụng để khởi tạo khoá:

- Người sử dụng tự sinh cặp khoá cho mình sau đó gửi khoá công khai cho CA quản lý. Ưu điểm của phương pháp này là khoá bí mật của người sử dụng không bao giờ bị bên thứ ba biết đến. Tuy nhiên để đảm bảo an toàn trong quá trình sinh khoá thì đòi hỏi hệ thống phía người dùng phức tạp.


30

- Cặp khoá được sinh bởi một hệ thống chuyên chịu trách nhiệm sinh khoá. Khoá công khai được gửi cho CA quản lý. Còn khoá bí mật gửi lại cho người dùng theo một kênh truyền an toàn ( ví dụ như sử dụng smart card để lưu khoá bí mật).

- Cặp khoá được sinh bởi CA: Đây là một trường hợp riêng của trường hợp trên.

b) Phân phối, thu hồi, treo, lưu trữ khoá

Các chức năng này đồng nhất với chức năng quản lý chứng chỉ của CA. Tuy nhiên chức năng quản lý khoá trong một số trường hợp có những điểm khác biệt. Ví dụ như một cặp khoá được sử dụng trong nhiều chứng chỉ khác nhau. Rõ ràng chỉ cần quản lý một cặp khoá nhưng lại phải quản lý nhiều chứng chỉ.

- Lưu trữ, phân phối khoá : Các khoá công khai được lưu trữ phân phối cho các ứng dụng thông qua các hệ thống không cần đảm bảo bí mật. Còn khoá bí mật được phân phối cho người dùng thông qua các kênh truyền an toàn như smart card, hoặc đựơc mã hoá bởi một thành phần bí mật khác.

- Thu hồi, treo khoá : Quá trình thu hồi khoá biểu hiện thông qua việc thu hồi chứng chỉ, Chứng chỉ bị thu hồi bao hàm hai ý nghĩa là thông tin định danh không còn chính xác hoặc khoá bị thoả hiệp. Khi phát hiện khoá bị thoả hiệp, hoặc do yêu cầu từ người dùng, các thành phần PKI có chức năng yêu cầu CA thu hồi các chứng chỉ tương ứng. Còn quá trình treo khoá là qúa trình thu hồi khoá tạm thời, khoá đó hoàn toàn có thể đựơc sử dụng lại, tuỳ thuộc vào kết quả kiểm tra của CA xem nó đã bị thoả hiệp hay chưa.

c) khôi phục khoá

Trong bất kỳ hệ thống nào rủi ro luôn luôn có thể xảy ra .Hệ thống PKI phải lường trước tình trạng khoá mã hoá bị mất. Đối với khoá công khai thì việc phân phối khoá là đơn giản, vì nó được lưu trữ trên server công cộng, mọi đối tượng sử đều có quyền truy cập vào lấy thông tin. Nhưng đối với khoá bí mật thì khác. Nguyên nhân mất có thể là do mất mật khẩu truy cập vào hệ thống lưu trữ, hoặc hệ thống lưu trữ bị hỏng hóc việc hệ thống sinh khoá có lưu trữ khoá bí mật này không là tuỳ thuộc vào chính sách của PKI. Nếu việc lưu trữ khoá bí mật được thực hiện thì khoá bí mật sẽ khôi phụ được, tuy nhiên lại nảy sinh vấn đề tính riêng tư bị xâm phạm vì một bên thứ 3 có thể xem toàn bộ thông tin bí mật của bạn. Nếu khoá bí mật không được lưu trữ, thì tính riêng tư của tài liệu mã


31

hoá không bị vi phạm, nhưng nếu khoá bí mật bị mất thì đồng nghĩa với việc toàn bộ dữ liệu đã mã hoá của bạn bị mất theo.

1.7.2.2. Quản lý chứng chỉ Thông qua CA, PKI cung cấp các chức năng quản lý chứng chỉ như tạo và thu hồi

chứng chỉ. Bên cạnh đó PKI phải hỗ trợ các dịch vụ trao đổi giữa các thành phần trong hệ thống với CA. Tiến hành xác nhận chứng chỉ khi có xung đột chứng chỉ. Các chức năng quản lý chứng chỉ đảm bảo cho việc sử dụng chứng chỉ được an toàn.

1.7.2.3. Đảm bảo an toàn Hệ thống PKI sử dụng công nghệ mã hoá khoá công khai để cung cấp các dịch vụ đảm bảo bí mật cho người sử dụng, bên cạnh đó nó phải đảm bảo rằng các dịch vụ mà nó sử dụng phải an toàn cho người sử dụng. Tức là phải đảm bảo tính bí mật, toàn vẹn và tính sãn sàng của các dịch vụ PKI. Bên cạnh đó các hệ thống PKI còn phải đảm bảo các chính sách giải quyết các vấn đề nảy sinh khi các rủi ro trong hệ thống sảy ra.

1.7.2.4. Quản lý thời gian Thời gian trong hệ thống PKI phải có tính nhất quán, bởi rất nhiều thành phần chỉ

có được sự tin tưởng trong một thời gian cụ thể (chứng chỉ hay CRL). Rõ ràng PKI phải quản lý cả vấn đề thời gian trong hệ thống. Nếu dịch vụ thời gian của PKI không được đảm bảo, thì bất kỳ thành phần nào trong hệ thống PKI đều có thể lạm dụng sử dụng những thành phần phụ thuộc vào thời gian, thực hiện những hành động không an toàn và chối bỏ về mặt thời gian trong các phiên kết nối.

1.7.2.5 Giao tiếp giữa các PKI Không những PKI đảm bảo các thành phần PKI có thể giao tác được với nhau, mà

các hệ thống PKI khác nhau cũng có thể giao tiếp được với nhau. Như vậy khi xây dựng các thành phần PKI, chúng phải tuân theo các chuẩn để có thể giao tác được với nhau dưới đây là các chuẩn cơ bản đã được chấp nhận rộng rãi trên thế giới.

1. Chuẩn về định dạng chứng chỉ khoá công khai X509(v3) và định dạng danh sách thu hồi chứng chỉ khoá công khai X509(v2) - rfc 2459

2. Chuẩn về các giao thức quản lý chứng chỉ trong hệ thống PKI - rfc 2510

3. Chuẩn về các giao thức thực thi trong hệ thống PKI- rfc 2559, rfc 2585, rfc 2560

4. Chuẩn về chính sách chứng chỉ X509 - rfc 2527


32

5. Mẫu thời gian và các dịch vụ xác thực - chưa có tài liệu rfc mới chỉ mới có các bản nháp trực tuyến

Tóm tắt chương : Trong các dịch vụ đảm bảo tính an toàn cho hệ thống thông tin thì dịch vụ xác thực là quan trọng nhất. Thành phần bí mật sử dụng trong dịch vụ xác thực đảm bảo cơ chế hoạt động cho các dịch vụ còn lại. Giao thức xác thực bằng chứng chỉ số là một trong các giao thức giao thức xác thực, ngày nay giao thức xác thực này được sử dụng phổ biến trong các công nghệ xác thực như SSL, bảo mật mail, bảo mật IP…

Chứng chỉ số là sự gắn kết giữa các thông tin định danh thực thể và khoá riêng của thực thể thông qua chữ ký của CA. Thông qua chữ ký của mình, CA đảm bảo rằng các đối tượng định danh trong chứng chỉ đang sử hữu một khoá riêng riêng tương ứng. Chứng chỉ được quản lý trặt chẽ bởi các dịch vụ của PKI từ giai đoạn khởi tạo đến khi chứng chỉ hết hiệu lực, các nhà phát hành chứng chỉ có quyền phát hành chứng chỉ cho chủ thể chứng chỉ và thu hồi chứng chỉ khi cần thiết. Thông qua danh sách thu hồi chứng chỉ, CA có thể công bố rộng rãi các thông tin về những chứng chỉ đã bị thu hồi.

Cơ sở hạ tầng bảo mật khoá công khai ( Public Key Infrastructure – PKI ) là một tập hợp phần cứng, phần mềm, chính sách, thủ tục…cần thiết; để tạo, quản lý và lưu trữ, phân phối và thu hồi các chứng chỉ số dựa trên công nghệ mã hoá khoá công khai. PKI cung cấp các dịch vụ an toàn cho toàn bộ hệ thống.

Trong chương tiếp theo chúng ta sẽ mô tả nội dung của chứng chỉ số theo chuẩn X.509 được sử dụng rộng rãi trong các hệ thống PKI trên thế giới.


33

Chương 2 :

CHUẨN CHỨNG CHỈ X.509 Trong chương trước chúng ta đã đề cập đến các thành phần cơ bản của một chứng

chỉ số. Trong chương này chúng ta đi sâu vào đặc tả cấu trúc chứng chỉ số theo chuẩn X.509, đựơc ban hành bởi tổ chức International Telecommunication Union - Telecommunication (ITU-T) và ISO/International Electrotechnical Commission(IEC)

ITU-T X.509 hay ISO/IEC 9594-8 định nghĩa chuẩn chứng chỉ X.509, đựơc xuất bản năm 1988 là một phần của chuẩn thư mục X.500. Chuẩn chứng chỉ đầu tiên này là phiên bản 1 (version 1). Khi chuẩn X.500 được thay đổi trong năm 1993, thì chứng chỉ số thêm hai trường mới, kết quả là tạo ra phiên bản 2 (version 2).

Các tài liệu RFC (Request For Comment) về đặc tả bảo mật mail(Internet Privacy Enhanced Mail- PEM) công bố năm 1993, bao gồm các đặc tả cơ sở hạ tầng bảo mật dựa trên nền tảng chứng chỉ X509 phiên bản 1(RFC 1422). Tuy nhiên trong quá trình xây dựng hệ thống người ta thấy rằng dù sử dụng chứng chỉ x.509 version 2 thay cho version 1 thì hệ thống vẫn bị hạn chế trong một số trường hợp cụ thể. Các trường mới đựơc thêm vào chứng chỉ trong khi xây dựng hệ thống PEM, và điều này được thực tế chứng mình là cần thiết. Kết quả , ISO/IEC/ITU và ANSI X9 đã phát triển định dạng chứng chỉ X.509 phiên bản 3 (version 3).

Sự khác biệt giữ phiên bản 3 và phiên bản 2 là việc thêm các trường dữ liệu mở rộng trong chứng chỉ. Trong số các trường thêm mới so với phiên bản 2, có một số trường được quy định và bắt buộc theo chuẩn, nhưng còn một số trường đựơc phép lựa chọn và tuỳ thuộc từng hệ thống sử dụng.

Tháng 6 năm 1996, chuẩn chứng chỉ X509 phiên bản 3 được hoàn thiện.


34

2.1 Cấu trúc chứng chỉ X.509 Hình 2.1 mô tả cấu trúc của một chứng chỉ theo chuẩn X.509 version 3

Nhìn tổng thể Chứng chỉ X.509 bao gồm phần cơ sở và mở rộng. Tất cả được xác thực bằng chữ ký của nhà phát hành chứng chỉ.

2.1.1. Các trường cơ sở của chứng chỉ X.509 2.1.1.1. Phiên bản (Version) Version ::= INTEGER { v1(0), v2(1), v3(2) }

Trường này mô tả phiên bản của chứng chỉ. Khi phần mở rộng được sử dụng thì phiên bản của chứng chỉ là 3. Nếu chứng chỉ không có phần mở rộng nhưng có hai trường Issuer Unique Identifier, Subject Unique Identifier thì phiên bản của chứng chỉ là 2. Nếu

Hình 2.1. Định dạng chứng chỉ X.509 phiên bản 3


35

chứng chỉ chỉ có các trường cơ sở thì phiên bản của chứng chỉ 1. Giá trị của trường đại diện cho ba phiên bản là 2,1,0. Giá trị mặc định của trường này là 0.

2.1.1.2. Số hiệu chứng chỉ (Certificate Serial Number) CertificateSerialNumber ::= INTEGER

Trường này mô ta số hiệu của chứng chỉ. Mỗi chứng chỉ có một số hiệu khác nhau, do CA cấp phát. Số này là một số nguyên dương phụ thuộc vào nhà phát hành chứng chỉ và chứng chỉ được cấp phát. Hai chứng chỉ khác nhau không thể có hai số hiệu trùng nhau, do đó giá trị của trường này có thể là rất lớn. Các hệ thống xử lý chứng chỉ phải có khả năng xử lý trường này với giá trị có độ lớn là 20 con chữ số trong hệ số 16. Tuy nhiên trong thực tế thì chưa có CA nào cấp phát chứng chỉ với số lượng lớn như thế cả.

2.1.1.3. Thuật toán ký (Signature Algorithm Identifine) Trường này chỉ ra tên thuật toán ký mà CA dùng để ký chứng chỉ

2.1.1.4. Tên nhà phát hành chứng chỉ ( Issure Name) Tên của nhà phát hành chứng chỉ

2.1.1.5. Thời gian sử dụng (Period of validity) Validity ::= SEQUENCE {

notBefore UTCTIME,

notAfter UTCTIME

}

Trường này chỉ ra thời gian tồn tại của chứng chỉ. Mỗi chứng chỉ đều có một thời gian sử dụng nhất định sau quãng thời gian đó chứng chỉ hoàn toàn mất tác dụng, muốn sử dụng tiếp thì CA cấp phát lại chứng chỉ để gia hạn cho chứng chỉ.

Trường này bao gồm hai trường nhỏ là trường not before và not after. not before chỉ thời điểm mà chứng chỉ bắt đầu có hiệu lực. Còn not after chỉ ra thời điểm mà chứng chỉ không còn hiệu lực.

2.1.1.6. Tên chủ t hể (Subject Name) Trường này mô tả tên của chủ thể chứng chỉ.


36

2.1.1.7. Khóa công khai cua chủ thể ( Subject'public Key Info) Trường này chứa thông tin về khoá công khai trên chứng chỉ. Bao gồm giá trị khoá

và tên thuật toán mã hoá để sử dụng khoá công khai( Khuyến nghị sử dụng RSA)

2.1.1.8. Tên duy nhất của nhà phát hành chứng chỉ (Issuer Unique Identifier) Đây là trường chỉ xuất hiện từ phiên bản thứ 2 của X.509. Trên thực tế có thể có

nhiều nhà phát hành chứng chỉ có tên đại diện trùng nhau( trường Issuer giống nhau nhưng không phải là một nhà phát hành chứng chỉ). Do đó từ phiên bản thứ 2 người ta thêm trường Issuer Unique Identifier để xác định tên duy nhất của nhà phát hành chứng chỉ.

2.1.1.9. Tên duy nhất của chủ thể chứng chỉ (Subject Unique Identifier) Tương tự như thế, trường Subject Unique Identifier sử dụng để phân biệt hai đối

tượng có thông tin định danh giống nhau (tức là trường Subject Name giống nhau nhưng không phải là một đối tượng).

2.1.2. Các trường mở rộng của chứng chỉ X.509 Các trường mở rộng của X.509 chỉ xuất hiện từ phiên bản 3. Các trường mở rộng

này bao gồm các trường mở rộng theo chuẩn (16 trường) và có những trường được thiết lập tuỳ ý trong khi xây dựng hệ thống. Ở đây chỉ đề cập đến các trường mở rộng thiếp lập cho mục đích xây dựng các hệ thống PKI được đặc tả trong RFC 3280.

Mỗi trường mở rộng bao gồm ba thành phần: Loại trường mở rộng, và giá trị cuả trường mở rộng, cờ thiết yếu.

Loại trường mở rộng : Chỉ ra ngữ nghĩa của trường mở rộng

Giá trị trường mở rộng : Là giá trị thực của trường mở rộng. Giá trị này có thể là một số nguyên tố hoặc là một xâu ký tự, hay một cấu trúc dữ liệu

Cờ thiết yếu : Là cờ giúp cho các ứng dụng xử lý chứng chỉ một cách an toàn. Nếu cờ thiết yếu có giá trị là "thiết yếu" Thì chương trình sử dụng chứng chỉ bắt buộc phải nhận dạng được trường mở rộng này, nếu không nhận dạng đựơc thì coi như chứng chỉ đó không hợp lệ. Nếu giá trị của cờ này là "Không thiết yếu" Thì ứng dụng có thể bỏ qua trường này nếu không nhận dạng được và tiếp tục sử dụng chứng chỉ một cách an toàn.


37

2.1.2.1. Các trường mở rộng chuẩn 2.1.2.1.1. Định danh khóa của nhà phát hành chứng chỉ (Authority Key

Identify)

Trường này dùng để xác định khoá công khai của CA tương ứng với khoá bí mật mà CA dùng để ký trên chứng chỉ. Ở đây có hai lựa trọn là tên định danh của khoá công khai hoặc là tên chứng chỉ chứa khoá công khai của CA. Dựa vào trường này mà hệ thống có thể lấy được khoá công khai của CA để kiểm tra chữ ký của CA trên chứng chỉ.

Trường này được đặt cờ không thiết yếu.

2.1.2.1.2. Định danh khóa của chủ thể chứng chỉ (Subject Key Identify)

Trường này dùng để nhận dạng khoá công khai của đối tượng. Với mỗi đối tượng có thể sử dụng nhiều khoá công khai, nhiều chứng chỉ khác nhau. Trường này giúp so sánh xem hai chứng chỉ của một đối tượng bất kỳ có cùng khoá công khai hay không. Giá trị của trường này là giá trị băm SHA - 1 của khoá công khai trong chứng chỉ.


2.1.2.1.3. Mục đích sử dụng khóa (Key Usage)

KeyUsage ::= BIT STRING {

digitalSignature (0),

nonRepudiation (1),

keyEncipherment (2),

dataEncipherment (3),

keyAgreement (4),

keyCertSign (5),

cRLSign (6),

encipherOnly (7),

decipherOnly (8) }

Trường Key Usage chỉ ra mục đích sử dụng của khoá công khai trên chứng chỉ. Giá trị của trường là một chuỗi bit. Mỗi bit là cờ đại diện cho một mục đích nhất định. Vị trí các bit và mục đích sử dụng đựơc xác định như sau:


38

Bit số 0 - digitalSignature : Bit này được bật chỉ ra rằng khoá công khai được sử dụng để kiểm tra chữ ký.

Bit số 1 - nonRepudition : Khoá công khai được sử dụng cho mục đích chống chối bỏ.

Bit số 2 - KeyEncipherment : Khoá công khai có mục đích dùng để mã hoá khoá.

Bit số 3 - dataEncipherment : Khoá công khai sử dụng để mã hoá dữ liệu.

Bit số 4 - keyAgreement : Khoá công khai được sử dụng với mục đích là khoá thoả thuận.

Bit số 5 - keyCertSign : Bit này chỉ đựơc bật nếu chứng chỉ này là chứng chỉ chứa khoá công khai của CA. Khoá công khai của chứng chỉ này dùng để kiểm tra chữ ký của CA trên các chứng chỉ khác.

Bit số 6 - cRLSign : Tương tự như bit số 5. Nhưng khoá công khai của chứng chỉ dùng để kiểm tra chữ của CA trên các CRL.

Bit số 7 - encipherOnly : Khoá công khai chỉ được sử dụng cho mục đích mã hoá dữ liệu trong các hệ thống bảo mật.

Bit số 8 - decipherOnly : Khoá công khai chỉ được sử dụng cho mục đích giải mã trong các hệ thống đảm bảo tính xác thực.

Mỗi khoá công khai có thể sử dụng cho nhiều mục đích khác nhau nên dãy bit này là một dãy có thể có nhiều giá trị 1 được bật.

Trường này được đặt cờ thiết yếu tuỳ thuộc vào nhà phát hành chứng chỉ CA

- Nếu trường này đặt thiết yếu, thì khoá công khai chỉ được sử dụng với mục đích được xác định trong dãy bít trên.

- Nếu trường này đặt là không thiết yếu thì khoá công khai có thể được sử dụng với mọi mục đích của hệ thống.

2.1.2.1.4. Mục đích sử dụng khóa mở rộng (Extended Key Usage)

Trường này bổ xung cho trường Key Usage trong các chứng chỉ của đối tượng sử dụng cuối. Để chỉ ra các mục đích sử dụng khác của khoá công khai trên chứng chỉ.


39

Trường này có thể được đặt cờ thiết yếu hoặc không thiết yếu với mục đích như trường trên.

Nếu cả hai trường Key Usage và Extended Key Usage đều được đặt cờ thiết yếu thì chỉ có những mục đích được quy định bởi cả hai trường mới có hiệu lực.

2.1.2.1.5. Khoản thời gian sử dụng khóa bí mật (Private Key Usage Period)

Trường này chỉ ra khoảng thời gian mà khoá bí mật tương ứng với khoá công khai trên chứng chỉ có hiệu lực. Khoản thời gian này có thể khác với khoảng thời gian mà chứng chỉ có hiệu lực. Trường này xác định khoảng thời gian bằng hai mốc là NotBefore và NotAfter. NotBefore chỉ ra thời gian mà khoá bí mật bắt đầu có hiệu lực, và NotAfter chỉ ra thời điểm mà khoá bí mật hết hiệu lực.

Trường này luôn được đặt cờ ở trạng thái không thiết yếu.

2.1.2.1.6. Chính sách chứng chỉ (Certificate Policies )

Trường này là một dãy các chính sách áp dụng cho chứng chỉ được quy định bởi nhà phát hành chứng chỉ. Mỗi chính sách được đại diện bởi một OID (Object Identify). Mỗi OID được CA quy định một tên chính sách và các quy định về chính sách tương ứng.

Trường này có thể đặt cờ ở trạng thái không thiết yếu hoặc thiết yếu tùy thuộc vào CA.

- Nếu trường này được đặt cờ thiết yếu thì chỉ hệ thống sử dụng chứng chỉ phải thực hiện theo các quy định của CA thông qua các chính sách mà CA ghi nhận trong trường này.

- Nếu trường này đặt cờ là không thiết yếu, thì có thể không áp dụng những chính sách được xác định trong trường này. Tuy nhiên hệ thống sử dụng chứng chỉ nên áp dụng những chính sách xác định bởi trường này, để đảm bảo phù hợp với các chính sách của CA.

2.1.2.1.7. Chính sách tương ứng (Policy Mappings)

Trường này chỉ được sử dụng trong các chứng chỉ CA. Trường này bao gồm một danh sách các cặp OID. Mỗi cặp OID chỉ ra rằng hai chính sách tương ứng tương đương nhau.


40

Mặc dù trường này có thể do CA quy định là thiết yếu hoặc không thiết yếu. Nhưng nó vẫn được khuyến cáo đặt cờ thiết yếu, để hệ thống có thể hiểu kỹ hơn các chính sách mà CA ban hành.

2.1.2.1.8. Tên khác của chủ thể (Subject Alternative Name)

Trường này cho phép thêm các thông tin định danh về chủ thể của chứng chỉ. bao gồm địa chỉ mail, địa chỉ IP, tên miền...

Trường này cũng do CA quy định cờ thiết yếu hay không thiết yếu. Nếu trường này đặt cờ thiết yếu, thì hệ thống sử dụng chứng chỉ phải nhận dạng được ít nhất một trong các trường dữ liệu trên, nếu không chứng chỉ bị coi như không hợp lệ.

2.1.2.1.9. Tên khác của nhà phát hành (Issuer Alternative Name)

Tương tự như trường trên, trường này dùng để thêm các thông tin giúp định danh nhà phát hành chứng chỉ.

Trường này cũng do CA quy định là thiết yếu hay không thiết yếu. Nếu trường này đặt cờ là thiết yếu, thì hệ thống sử dụng chứng chỉ phải nhận dạng được ít nhất một trong các trường dữ liệu về email, địa chỉ IP, tên miền, định danh tài nguyên URI của nhà phát hành chứng chỉ. Nếu không nhận dạng được tất cả các trường trên thì chứng chỉ coi như không hợp lệ.

2.1.2.1.10. Thuộc tính định danh chủ thể (Subject directory Atributes)

Các trường này là một danh sách các mục để chứa các thuộc tính định danh của đối tượng (ví dụ như quốc tịch của đối tượng).

Trường này luôn được đặt cờ không thiết yếu.

2.1.2.1.11. Trường xác định vai trò của chủ thể (Basic constraints )

Trường này chỉ ra rằng chủ thể của chứng chỉ có thể có vai trò là một CA, hoặc người sử dụng cuối. Với khoá công khai trên chứng chỉ dùng để kiểm tra chữ ký của CA này trên một chứng chỉ khác.

Nội dung của trường này bao gồm hai phần:


41

- CA : Cho biết chủ sở hữu chứng chỉ có phải là một CA không. Nếu giá trị là false thì chứng chỉ là của một đối tượng sử dụng cuối cùng trong hệ thống xác thực( Không phải là một nhà phát hành chứng chỉ).

- pathLenContrain : Nếu trường CA là true thì pathLenContrain chỉ ra độ sâu của cây chứng thực do CA này tạo ra. Nếu giá trị là 0 thì CA này chỉ có thể cấp phát chứng chỉ cho một tầng người sử dụng tiếp theo. Nếu giá trị không xác định thì cây chứng thực do CA này tạo ra có độ sâu vô hạn.

Trường này khuyến cáo là để cờ không thiết yếu, nhằm tránh việc các người dùng trong hệ thống phát hành chứng chỉ bất hợp pháp. Trong các chứng chỉ của CA thì bắt buộc đặt cờ thiết yếu nếu chứng chỉ dùng để kiểm tra chữ ký của nó trên chứng chỉ khác. Tuy nhiên các chứng chỉ của CA không sử dụng với mục đích trên thì khuyến cáo đặt cờ không thiết yếu.

2.1.2.1.12. Không gian tên chứng chỉ (Name Constraints)

Trường này sử dụng trong chứng chỉ của CA với mục đích chỉ ra không gian tên để đặt tên cho các chứng chỉ phía dưới nó trong cây xác thực. Nếu trường này được cờ thiết yếu thì các chứng chỉ con trong cây chứng thực phải có tên chứa phần mở rộng này.

Trường này có thể đặt thiết yếu hoặc không thiết yếu. Tuy nhiên, nó được khuyến cáo là để thiết yếu vì như thế mới có thể kiểm tra được các chứng chỉ có phải do CA phát hành hay không.

2.1.2.1.13. Hạn chế chính sách (Policy Constraints)

Trường này chỉ được sử dụng trong chứng chỉ của CA. Trường này giúp hạn chế con đường xác thực để giúp cho quá trình xác thực chứng chỉ cấp dưới diễn ra nhanh nhất có thể.

Nội dung của trường này gồm hai thành phần.

InhibitPolicyMapping : Nếu trường này được sử dụng thì giá trị của nó chính là độ sâu trong đường dẫn chứng thực mà các chứng chỉ có độ sâu kể từ chứng chỉ này được phép tham chiếu chính sách. Ngoài độ sâu trên thì việc tham chiếu chính sách là không hợp lệ.


42

requireExplicitPolicy : Trường này có giá trị là một số nguyên chỉ ra độ sâu trong đường dẫn chứng thực mà các chứng chỉ có độ sâu nhỏ hơn giá trị này đều áp dụng cùng một chính sách(Tức là các chứng chỉ có trường Certificate Policies giống nhau).

Trường này được tuỳ trọn đặt cờ thiết yếu hoặc không tuỳ thuộc vào CA. Nhưng nó được khuyến cáo là nên đặt cờ thiết yếu để hệ thống có thể dễ dàng quản lý chính sách của CA với từng chứng chỉ bên dưới.

2.1.2.1.14. Chính sách hạn chế (Inhibit any policy)

Trường này chỉ được sử dụng cho chứng chỉ CA. Trường này chứa các OID giúp cho hệ thống biết được những chính sách nào không được áp dụng cho toàn bộ các chứng chỉ trong đường dẫn xác thực mà chủ thể của chứng chỉ là CA gốc.

2.1.2.1.15. Điểm phân phối danh sách thu hồi chứng chỉ (CRL Distribution Points)

Trường CRL Distribution Points giúp cho hệ thống lấy được thông tin về CRL. Trường này bao gồm ba thành phần( có thể có một thành phần hoặc cả ba):

CRLIssuer: Trường này được sử dụng nếu CA không phải là nhà phát hành CRL. trường này giúp định danh tên nhà phát hành chứng chỉ, qua đó giúp hệ thống có thể có được thông tin về CRL. Nếu nhà CA trùng với nhà phát hành CRL thì trường này không được sử dụng, và khi đó chứng chỉ sử dụng trường DistributionPoint

DistributionPoint: Trường này chỉ ra nơi chứa CRL theo kiểu định dạng tài nguyên URI

Reson : Trường này chỉ ra lý do sử dụng CRL. Nếu trường này không được sử dụng thì CRL có thể lấy về với mọi lý do.

Trường này đặt cờ không thiết yếu.

2.1.2.1.16. Danh sách thu hồi chứng chỉ phụ (Freshest CRL)

Trường này giúp cho hệ thống truy cập đến các bản delta CRL. Vai trò của nó cũng giống như trường CRL Distribution Points. Cả hai trường sẽ được bàn kỹ hơn trong quá trình mô tả định dạng CRL ở phần tiếp theo


43


2.1.2.2. Các trường mở rộng cho Internet Trong phần này chúng ta đề cập đến hai phần mở rộng của chứng chỉ được sử dụng

khi xây dựng các PKI cho Internet. Các trường mở rộng này giúp cho quản lý các thông tin phát hành của CA và về đối tượng.

2.1.2.2.1. Truy cập thông tin nhà phát hành (Authority Information Access)

Đây là trường mở rộng xác định cách truy cập thông tin của CA và thông tin về các dịch vụ đảm bảo việc phát hành chứng chỉ. Các thông tin này bao gồm cả những thông tin về chính sách mà CA phát hành. Trường này có hai thành phần quan trọng bao gồm phương thức truy cập(accessMethod) và địa chỉ truy cập (accessLocation)


2.1.2.2.2. Truy cập thông tin chủ thể (Subject Information Access)

Tương tự như trên, trường này chỉ ra phương thức để hệ thống sử dụng chứng chỉ có thể lấy được các thông tin về chủ thể của chứng chỉ. Nếu chủ thể của chứng chỉ là CA thì các thông tin bao gồm các dịch vụ xác thực và các chính sách của CA ấy. Còn nếu chứng chỉ là của một người dùng cuối thì trường này chỉ ra cách truy cập vào các dịch vụ mô tả đối tượng của CA, và phương thức truy cập chúng.

Trường này được đặt cờ không thiết yếu

2.1.3. Chữ ký của nhà phát hành chứng chỉ (Signature) Trường này chứa chữ ký của nhà CA. Nó bao gồm thuật toán và giá trị ký. Giá trị ký là một xâu bit được xác định bằng thuật toán ký với đầu vào là phần cơ sở và phần mở rộng của chứng chỉ, khoá ký là khoá bí mật của CA

2.2. Cấu trúc của danh sách thu hồi chứng chỉ X.509 Năm 1988 cùng với định dạng của chứng chỉ X.509 . ITU và ISO/IEC còn đặc tả

danh sách thu hồi chứng chỉ CRL X.509 phiên bản 1 (version1). Phiên bản 2 của CRL X.509 được thêm các trường mở rộng, và trường mở rộng của mục CRL.

Mỗi một CRL nhìn chung bao gồm các số hiệu chứng chỉ bị thu hồi được xác thực bằng chữ ký của nhà phát hành CRL( nhà phát hành có thể là một CA hoặc là một nhà


44

phát hành CRL độc lập). Hình 2.2 mô cả cấu trúc của một danh sách thu hồi chứng chỉ theo chuẩn X.509.

Mỗi một CRL bao gồm các trường cơ bản và các trường mở rộng. Trong các trường cơ bản ngoài những thông tin về nhà phát hành chứng chỉ còn có những mục CRL(entry CRL). Mỗi mục CRL không những chứa số hiệu chứng chỉ được thu hồi mà nó còn chứa các phần mở rộng dùng để mô tả thêm những thông tin cho mục chứng chỉ bị thu hồi đó.

2.2.1. Các trường cơ bản của CRL X.509 2.2.1.1. Phiên bản (Version) Trường này mô tả phiên bản của CRL. Nếu trong CRL không có trường mở rộng

thì phiên bản của CRL là version 1(giá trị là 0). Ngược lại phiên bản của CRL là version 2(giá trị 1).

2.2.1.2.Thuật toán ký (Signature Algorithm Identifier) Mô tả tên thuật toán ký mà nhà phát hành sử dụng để ký trên CRL.

Hình 2.2 Cấu trúc của một danh sách thu hồi chứng chỉ.


45

2.2.1.3. Tên nhà phát hành (Issuer Name) Tên của nhà phát hành ký và phát hành CRL

2.2.1.4.Thời điểm phát hànhCRL (This Updatte) Trường này mô tả thời gian phát hành CRL. Nó được mã hoá theo UTCTime hay theo GeneralizedTime.

2.2.1.5. Thời điểm phát hànhCRL tiếp theo (Next Update) Trường này chỉ ra thời điểm tiếp theo mà bản CRL được phát hành thay thế cho bản CRL hiện thời. Trong một vài phương phát truy cập thông tin của CRL không cần xử lý trường này. Tuy nhiên nó vẫn được khuyến cáo là nên sử dụng. Bản CRL tiếp theo có thể xuất bản trước thời gian này, tuy nhiên chúng không bao giời được phát hành chập hơn thời điểm ghi nhận trong trường này.

2.2.1.6.Các chứng chỉ bị thu hồi (Revoked Certificates) Trường này chứa toàn bộ thông tin về những chứng chỉ bị thu hồi . Nội dụng của trường bao gồm một danh sách các mục CRL. Mỗi mục CRL tương ứng với một chứng chỉ bị thu hồi, và các thông tin về trạng thái thu hồi của chứng chỉ đó.

2.2.1.6.1. Các trường cơ sở của mục CRL

a) Chứng chỉ bị thu hồi (Certificate)

Trường này chứa mã số của chứng chỉ bị thu hồi. Giá trị này không bị trùng lặp với các giá trị trong các mục CRL khác.

b) Thời điểm thu hồi (Revocation Date)

Trường này chỉ ra thời gian mà chứng chỉ tương ứng bị thu hồi.

2.2.1.6.2. Các trường mở rộng của mục CRL

a) Lý do thu hồi (Reason Code)

Trường Reason Code chứa lý do thu hồi chứng chỉ.

Dưới đây là các mã lý do

CRLReason ::= ENUMERATED {

unspecified (0),

keyCompromise (1),


46

cACompromise (2),

affiliationChanged (3),

superseded (4),

cessationOfOperation (5),

certificateHold (6),

removeFromCRL (8),

privilegeWithdrawn (9),

aACompromise (10) }

- unspecifiend : Mã này cho biết lý do thu hồi chứng chỉ không được chỉ rõ. Lý do thu hồi không lằm trong các lý do còn lại.

- keyCompromise : Lý do chứng chỉ bị thu hồi là khoá bí mật của người sử dụng bị lộ. Việc sử dụng chứng chỉ này là không đảm bảo an toàn.

- cACompromise : Lý do thu hồi là khoá công bí mật của nhà phát hành chứng chỉ bị lộ.

- affiliationChange : Lý do thu hồi chứng chỉ là người sử dụng thay đổi các thông tin định danh của anh ta ( ví dụ như địa chỉ email ) và cấp phát mới một chứng chỉ khác cho người sử dụng này.

- superseded : Lý do thu hồi chứng chỉ là người sử dụng thay đổi cặp khoá công khai và bí mật.

- cessationOfOperation : Lý do thu hồi chứng chỉ là mục đích sử dụng khoá công khai được thay đổi.

- certificateHold : Chứng chỉ bị thu hồi do vi phạm chính sách của CA

- removeFromCRL : Sử dụng với Delta CRL, chỉ ra rằng đây là chứng chỉ được loại bỏ khỏi bản CRL gốc. Và việc sử dụng nó hoàn toàn hợp lệ.

- privilegeWithdrawn : Lý do thu hồi chứng chỉ là chính sách của CA đối với chứng chỉ này được thay đổi.

- aACompromise : Lý do thu hồi chứng chỉ là AA bị lộ khoá bí mật.



47

b) Mã chỉ dẫn (Hold Instruction Code)

Trường Hold Instruction Code chỉ dẫn các ứng dụng thực hiện các hành động khi gặp một chứng chỉ tồn tại trong CRL hợp lệ.

Dưới đây là các mã hành động được xác định bởi nhà phát hành CRL

- Instruction-callerissuer : Mã này quy định khi ứng dụng gặp chứng chỉ tồn tại trong CRL hợp lệ thì nó không được sử dụng và phải liên hệ với CA

- Instruction-reject : Mã này quy định khi ứng dụng gặp chứng chỉ tồn tại trong CRL hợp lệ thì nó không được sử dụng

- Instruction-none : Ứng dụng hoàn toàn có quyền quyết định hành động của mình.


c) Thời điểm không hợp lệ (Invalidity Date)

Trường Invalidity Date chỉ ra thời gian mà CA phát hiện chứng chỉ không còn hợp lệ. Tuy nhiên thời gian này có thể sớm hơn so với thời gian được quy định cho trong trường Revocation date bởi do độ trễ của hệ thống. Trường này được khuyến cáo sử dụng, bởi nó chứa thời điểm chính xác mà hệ thống CA không còn hỗ trợ những chính sách áp dụng cho chứng chỉ này nữa.


d) Nhà phát hành chứng chỉ (Certificate Issuer)

Trường mở rộng này chỉ ra tên của nhà phát hành chứng chỉ bị thu hồi.

Nếu CA trùng với nhà phát hành CRL thì trường này bắt buộc đặt cờ thiết yếu.

2.2.2. Các trường mở rộng của CRL Các trường mở rộng được định nghĩa bởi ANSI X9, ISO/IEC và ITU-T cho CRL

X.509 phiên bản 2 cung cấp phương thức truy cập các thuộc tính của CRL và định nghĩa các thuộc tính riêng của CRL để có những thông tin cần thiết trong quá trính sử lý chứng chỉ.


48

Tương tự như các trường của chứng chỉ, các trường của CRL cũng có cờ thiết yếu, hay không thiết yếu. Nếu là thiết yếu thì CRL sẽ bị coi là không hợp khuôn dạng CRL khi chương trình sử dụng CRL không nhận ra được trường đó.

2.2.2.1. Định danh khóa của nhà phát hành (Authority Key Identifier) Trường Authority Key Identifier giúp hệ thống sử dụng CRL có thể định danh

được khoá công khai của CRL. Mục đích của nó giúp cho hệ thống kiểm tra được chữ ký của nhà phát hành trên CRL. Trường này giống như trường Authority Key Identifier trong chứng chỉ X.509. Nó định vị một khoá công khai hoặc một chứng chỉ chứa khoá công khai của nhà phát hành CRL.

Trường này luôn được đặt cờ không thiết yếu.

2.2.2.2.Tên khác của nhà phát hành (Issuer Alternative Name) Trường này giống như trường Issuer Alternative Name trong chứng chỉ, nó mô tả thêm những thông tin giúp định danh nhà phát hành CRL.

Nếu trường này đặt cờ không thiết yếu, thì nó có thể được bỏ qua, tuy nhiên nếu nhà phát hành đặt cờ thiết yếu , thì hệ thống phải nhận dạng ra ít nhất một trong số những trường thông tin này. Nếu không CRL coi như không hợp lệ.

2.2.2.3. Số hiệu CRL (CRL Number) Trường này được đặt cờ không thiết yếu. Trường CRL Number là một số tăng dần cho từng bản CRL được ban hành bởi nhà phát hành CRL. Nó cho biết thứ tự của các CRL được phát hành, giúp cho hệ thống biết bản CRL mà nó đang xử lý có phải là bản CRL kế tiếp hay không.

2.2.2.4.Chỉ định Delta CRL (Delta CRL Indicator) Trường này sử dụng để chỉ ra rằng bản CRL này là bản Delta CRL tương ứng với một CRL trước đó. Delta CRL là bản CRL chỉ chứa những thay đổi so với CRL cơ sở. Việc sử dụng Delta CRL sẽ làm cho hiệu suất xử lý cao hơn,và do dung lượng của Delta CRL cũng nhỏ hơn bản CRL thông thường rất nhiều nên nó làm giảm nguy cơ tắc nghẽn đường khi các ứng dụng tải bản Delta CRL về.

Trường này còn chứa thông tin định danh bản CRL gốc mà bản Delta này tương ứng.

Trường này luôn được đặt cờ thiết yếu.


49

2.2.2.5. Điểm phân phối (Issuing Distributon point) Trường này chỉ ra vị trí chứa các CRL trong hệ thống, đồng thời nó còn quy định phạm vi sử dụng của CRL. Phạm vi dụng của CRL có thể chỉ dùng cho chứng chỉ của người sử dụng đầu cuối ( chỉ chứa những chứng chỉ được thu hồi của các đối tượng đầu cuối), cũng có thể CRL chỉ sử dụng cho chứng chỉ của các CA (chỉ chứa các chứng chỉ của các CA bị thu hồi) hoặc cho một lý do riêng biệt nào đó.

Mặc dù nó được đặt cờ thiết yếu, nhưng hệ thống có thể xây dựng mà không cần hỗ trợ phần mở rộng này.

2.2.2.6. CRL bổ sung (Freshest CRL ) Trường này chỉ ra vị trí của bản Delta CRL tiếp theo tương ứng với bản CRL này. Phần mở rộng này không tồn tại trong các Delta CRL.

Trường này luôn luôn đặt cờ không thiết yếu.

2.2.3. Chữ ký của nhà phát hành CRL(Signature) Tương tự như chứng chỉ X.509. Trường chữ ký của nhà phát hành CRL cũng chứa chữ ký của nhà phát hành CRL trên toàn bộ nội dung của bản CRL. Trường này bao gồm hai phần là thuật toán ký và giá trị chữ ký.

Tóm tắt chương : Chuẩn chứng chỉ X.509 được ITU/ISO khuyến nghị sử dụng trong khi xây dựng

chuẩn thư mục X.500. Ngày nay chứng chỉ số đã phát triển tới phiên bản 3.0 và được sử dụng rộng rãi trong các công nghệ xác thực. Phiên bản định dạng chứng chỉ 1.0 chỉ chứa các trường chuẩn, sau đó trong quá trình phát triển các hệ thống sử dụng công nghệ xác thực bằng chứng chỉ số, người ta đã phát triển phiên bản 2.0 và phiên bản 3.0 chứa thêm các trường mở rộng. Một số trường mở rộng được thiết kế theo chuẩn để bổ sung thông tin cho hệ thống xử lý, một số trường mở rộng do hệ thống tự định nghĩa trong quá trình sử dụng. Chính điều này làm cho chứng chỉ được áp dụng một cách mềm dẻo tùy từng hệ thống mà vấn đảm bảo tính nhất quán.

Chương này còn mô tả cấu trúc chuẩn của danh sách chứng chỉ X.509. Danh sách thu hồi chứng chỉ X.509 và chứng chỉ X.509 là hai loại tài liệu quan trọng nhất trong hệ


50

thống quản chứng chỉ,chúng được quản lý bởi nhà phát hành chứng chỉ CA và nhà phát hành danh sách thu hồi chứng chỉ.


51

Chương 3 :

SỬ DỤNG CÔNG NGHỆ XÁC THỰC SỐ SSL

3.1. Bảo mật tầng socket(Secure Socket Layer - SSL) Giao thức bảo mật tầng socket hay còn gọi là giao thức SSL là tầng giao thức nằm giữa tầng network hướng kết nối TCP/IP và tầng ứng dụng. Giao thức SSL được phát triển bởi Nestcape. SSL cung cấp kết nối bảo mật giữa browser và server bằng cách sử dụng cơ chế xác thực, sử dụng chữ ký số đảm bảo tính toàn vẹn và mã hóa bảo vệ tính bí mật.

Giao thức được hỗ trợ bởi các thuật toán mã hóa thông dụng, hàm băm, chữ ký số. Nó cho phép các server lựa chọn các thuật toán mã hóa, hàm băm, chữ ký số, đồng thời nó cũng cho phép cập nhật, áp dụng các thuật toán mã hóa mới để sử dụng.

Version Tổ chức phát triển Mô tả Browser hỗ trợ

SSL 2.0 Nestcape Giao thức căn bản Nestcape 3.0, IE 3.0

SSL 3.0 IETF Chống lại các tấn công bảo mật và mã hóa, cung cấp kênh chứng chỉ

Nestcape 3.0, IE 3.0

TLS 2.0 IETF thay thế cho SSL 3.0 None

Bảng 3.1 Các phiên bản của giao thức SSL

Bảng trên chỉ ra các phiên bản của giao thức SSL. Tuy nhiên chỉ có phiên bản 3 mới hỗ trợ kênh chứng chỉ. Tính năng này cho phép các server gửi chứng chỉ của server và chứng chỉ của nhà phát hành xuống cho browser trong phiên khởi tạo kết nối. Giao thức SSL 3.0 là nền tảng cho chuẩn giao thức bảo mật tầng giao vận (Transport Layer Security - TLS) hiện đang được phát triển bởi tổ chức quốc tế IETF( Internet Engineering Task Force)


52

3.1.1. Khởi tạo phiên kết nối SSL. Phiên kết nối SSL được khởi tạo bằng giao thức bắt tay giữa client và server. Như

hình 4.1 dưới đây. Các bước tuần tự có thể được bố trí khác đi tùy thuộc vào cấu hình của server, như cung cấp chứng chỉ của server hay đòi hỏi một chứng chỉ của client. Trong nhiều trường hợp người ta còn thêm những bước bắt tay khác để quản lý các thông tin mã hóa. Phần dưới đây chỉ đề cập đến các phần cơ bản để tạo kết nối SSL.

Kết nối SSL có thể được thiết lập lại nhiều lần. Do đó server lưu tạm thời một số định danh của phiên kết nối SSL. Điều này giúp cho client không phải thực hiện lại một số thủ tục khởi tạo khi thực hiện phiên kết nối SSL tiếp theo( Trừ khi số định danh của phiên kết nối hết thời gian sử dụng).

Các bước bắt tay tuần tự này có thể được chia làm bốn phần sau:

- Dàn xếp các giá trị ban đầu để sử dụng trong quá trình gửi dữ liệu sau này.

- Client xác thực server.

- Server xác thực client nếu cần thiết.

- Kết thúc phần bắt tay.

Hình 3.1 Các bước tuần tự bắt tay giữa server và client


53

3.1.1.1. Dàn xếp giá trị khởi tạo Trong phần khởi tạo các giá trị ban đầu, giao thức SSL 3.0 bao gồm ba phần sau :

a) Phương thức trao đổi khóa: Phần này chỉ ra phương thức mà client và server sử dụng để trao đổi khóa đối xứng sử dụng trong quá trình truyền dữ liệu. SSL 2.0 quy định sử dụng phương pháp trao đổi khóa RSA sử dụng chứng chỉ số, tuy nhiên từ SSL 3.0 hỗ trợ thêm giao thức trao đổi khóa Deffie – Hellman không sử dụng chứng chỉ số.

b) Thuật toán mã hóa: Thuật toán mã hóa có thể là mã hóa dòng(RC4 khóa 40 bit, RC4 khóa 128 bit) hoặc mã hóa khối(RC2, DES, 3 – DES,...). Giao thức SSL còn hỗ trợ việc chọn lựa không sử dụng mã hóa.

c) Hàm băm: Hàm băm sử dụng để bảo vệ tính toàn vẹn cho mỗi bản ghi. SSL sử dụng hai loại hàm băm thông dụng là MD5 128 bit và SHA-1 160 bit.

3.1.1.2. Xác thực giữa server và client Server và client sử dụng cùng cơ chế để xác thực đối tượng còn lại thông qua chứng chỉ của CA và chứng chỉ của đối tượng kia. Cơ chế rất đơn giản: server sử dụng khóa công khai trên chứng chỉ của CA, kiểm tra chữ ký của CA trên chứng chỉ client, nếu thành công thì client được xác thực. Quá trình xác thực trên client cũng tương tự như thế. Điều này sẽ rất nguy hiểm nếu server (hoặc client) tin tưởng vào một CA không đảm bảo an toàn bởi CA này có thể xác thực cho các client(hoặc server) nguy hiểm.

3.1.2. Giao thức bắt tay tuần tự Quá trình bắt tay tuần tự sử dụng 3 giao thức :

- Giao thức bắt tay SSL(SSL Handshake Protocol) : Khởi tạo phiên kết nối SSL

- Giao thức kết nối mã hóa SSL(SSL Change Cipher Spec Protocol) : Thực hiện các kết nối bảo mật dựa trên những tham số khởi tạo trong giao thức bắt tay.

- Giao thức cảnh báo SSL(SSL Alert Protocol) : Truyền các thông báo lỗi giữa client và server.


54

Ba giao thức này kết hợp lại tạo thành giao thức bản ghi SSL(SSL Record Protocol) được chỉ ra trong hình 3.2. Giao thức tổng hợp này sẽ truyền dữ liệu từ tầng dưới lên tầng trên và ngược lại.

3.1.3. Truyền dữ liệu Giao thức bản ghi SSL được sử dụng để truyền dữ liệu và các tham số điều khiển kết nối SSL giữa client và server. Dữ liệu được chia nhỏ thành từng khối nhỏ hơn, hoặc kết hợp với các giao thức tầng trên để tạo ra các khối dữ liệu đủ nhỏ. Khối dữ liệu có thể được nén và mã hóa trước khi chuyển xuống cho tầng dưới xử lý.

Hình 3.3. Giao thức bản ghi SSL

Hình 3.2. Khối giao thức SSL


55

3.1.4. Kết nối HTTP bảo mật. Một trong những thành công của SSL là áp dụng vào tạo kết nối Web HTTP bảo

mật giữa trình duyệt web và server. Việc kết hợp này không thay thế mà bổ sung và các kết nối HTTP không bảo mật. Phiên bản bảo mật của HTTP sử dụng SSL được sử dụng khi người sử dụng nhập vào “https” thay cho “http” và với cổng khác( mặc định server sử dụng cổng 443).

3.2. Xây dựng hệ thống quản lý chứng chỉ 3.2.1. Cài đặt thư viện Openssl

Openssl là thư viện mã nguồn mở được xây dựng bởi Eric A. Young và Tim J.Hudson. Thư viện hỗ trợ các kết nối SSL và các thành phần quản lý chứng chỉ, thư viện mã hóa khóa công khai và đối xứng, các chức năng khác hỗ trợ mã hóa như đổi định dạng, tạo số ngẫu nhiên, xử lý stack…

Thư viện Openssl được cài đặt với hai mục đích chính là quản lý chứng chỉ và thiết lập kết nối SSL.

Để cài đặt thư viện Openssl chúng ta có thể sử dụng phiên bản nhị phân dùng cho windows hoặc sử dụng mã nguồn trực tiếp biên dịch ra file mã máy nhị phân. Mã nguồn của Openssl được phân phối chính thức tại địa chỉ www.Openssl.org

3.2.2. Cấu hình Openssl File cấu hình cho Openssl nằm trong thư mục bin của thư mục gốc (ví dụ c:/openssl/bin/openssl.cnf). Cấu hình cho CA bao gồm 3 phần. Mỗi phần sử dụng cho một mục đích nhất định: cấu hình cho CA, cấu hình chính sách chứng chỉ, cấu hình yêu cầu chứng chỉ.

3.2.2.1. Cấu hình CA Cấu hình cho CA bao gồm nhiều thông tin, ví dụ như các thư mục sử dụng cho CA, chứng chỉ của CA, khóa riêng của CA…


56

Nội dung phần cấu hình về CA như sau :

[ ca ] default_ca = CA_default # The default ca section [ CA_default ] dir = ./demoCA # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. #unique_subject = no # Set to 'no' to allow creation of # several ctificates with same subject. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number #crlnumber = $dir/crlnumber # the current crl number must be # commented out to leave a V1 CRL crl = $dir/crl.pem # The current CRL private_key = $dir/private/cakey.pem# The private key RANDFILE = $dir/private/.rand # private random number file x509_extensions = usr_cert # The extentions to add to the cert # Comment out the following two lines for the "traditional" # (and highly broken) format. name_opt = ca_default # Subject Name options cert_opt = ca_default # Certificate field options default_days = 365 # how long to certify for default_crl_days= 30 # how long before next CRL default_md = md5 # which md to use. preserve = no # keep passed DN ordering # A few difference way of specifying how similar the request should look # For type CA, the listed attributes must be the same, and the optional # and supplied fields are just that :-) policy = policy_match

3.2.2.2. Cấu hình chính sách chứng chỉ Phần chính sách dùng để định nghĩa các trường thông tin trên chứng chỉ. Chính

sách này bao gồm phần bắt buộc “policy_match” và không bắt buộc “policy_anything” đối với nội dung các trường sử dụng trong chứng chỉ. Các chính sách này được sử dụng khi xác nhận yêu cầu chứng chỉ. Giá trị “match” nghĩa là giá trị của trường này phải giống với các giá trị trong trường tương ứng trên chứng chỉ CA, “optional” nghĩa là giá trị của trường này không bắt buộc sử dụng, “supplied” nghĩa là trường của chứng chỉ bắt buộc phải cung cấp khi yêu cầu cấp phát chứng chỉ tuy nhiên không nhất thiết phải giống với giá trị của trường tương ứng trong chứng chỉ CA.

# For the CA policy [ policy_match ] countryName = match stateOrProvinceName = match


57

localityName = match organizationName = match organizationalUnitName = match commonName = supplied emailAddress = optional # For the 'anything' policy # At this point in time, you must list all acceptable 'object' # types. [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional

3.2.2.3. Cấu hình yêu cầu tạo chứng chỉ Phần [req] được sử dụng trong quá trình trình yêu cầu chứng chỉ. Phần cấu hình này quy định cấu trúc, kích cỡ, giá trị mặc định của các trường trong tên phân biệt sử dụng để định danh đối tượng; mật khẩu sử dụng để mã hóa file khóa.

[ req ] default_bits = 512 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = DE countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = NRW localityName = Locality Name (eg, city) localityName_default = Dummsdorf organizationName = Organization Name (eg, company) organizationName_default = PSEUDONYM.ORG organizationalUnitName = Organizational Unit Name (eg, section) organizationalUnitName_default = Doku-Projekt commonName = Common Name (eg, YOUR name) commonName_default = www.pseudonym.org commonName_max = 64 emailAddress = Email Address emailAddress_max = 40 emailAddress_default = [email protected] [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20


58

3.2.3. Tạo chứng chỉ cho CA Để tạo chứng chỉ tự ký cho CA ta sử dụng lệnh “req” của Openssl với tham số “-X509”. Chứng chỉ của CA được lưu trong file CAcert.pem, và khóa bí mật lưu trong file CAkey.pem. Trong quá trình tạo chứng chỉ, Openssl đòi người sử dụng cung cấp password để bảo vệ file khóa riêng lưu trong file CAkey.pem .

3.2.4. Tạo chứng chỉ cho client Quá trình tạo chứng chỉ bao gồm 2 bước sau:

- Tạo yêu cầu chứng chỉ.

- CA kiểm tra yêu cầu chứng chỉ để tạo chứng chỉ.

Hình 3.4. Tạo chứng chỉ cho CA


59

3.2.4.1. Tạo yêu cầu chứng chỉ. Dòng lệnh “req” của Openssl được sử dụng để tạo một yêu cầu chứng chỉ theo

chuẩn PKCS#10( Public Key Cryptography Standards). Chúng còn tạo ra cặp khóa bởi tham số “-new”. Tham số “-days” chỉ ra số ngày mà chứng chỉ có giá trị. Dòng lệnh này còn bắt người sử dụng nhập vào mật khẩu để bảo vệ khóa bí mật mới tạo ra. Một yêu cầu chứng chỉ được yêu cầu như hình dưới đây.

Hình 4.4 tạo yêu cầu chứng chỉ


60

Kết quả tạo ra một yêu cầu chứng chỉ “newreq.pem”, và một khóa riêng được tạo ra trong file “newkey.pem”.

3.2.4.2. Kiểm tra yêu cầu chứng chỉ để tạo chứng chỉ. Chứng chỉ của client được tạo ra sau khi kiểm tra yêu cầu chứng chỉ từ phía client.

Để kiểm tra yêu cầu chứng chỉ ta sử dụng lệnh “ca” của Openssl. “-policy” chỉ file cấu hình cho CA. phần “-policy” quy định các trường trong tên phân biệt sử dụng trong chứng chỉ. Ví dụ, phần cấu hình được sử dụng là “policy_anything” sẽ chỉ ra các trường trong tên phân biệt là không bắt buộc. Khi dòng lệnh được thực thi. Người sử dụng cần nhập password để mở file khóa bí mật (mật khẩu được sử dụng trong quá trình tạo yêu cầu trên) của client. ca newreq.pem newkey.pem > new.pem ./openssl ca -policy policy_anything -out newcert.pem \ -config ./openssl.cnf -infiles new.pem Using configuration from /opt/www/lib/ssleay.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'DE' stateOrProvinceName :PRINTABLE:'' localityName :PRINTABLE:'Dummsdorf' organizationName :PRINTABLE:'PSEUDONYM.ORG' organizationalUnitName:PRINTABLE:'pseudonym.org' commonName :PRINTABLE:'www.pseudonym.org' emailAddress :IA5STRING:'[email protected]' Certificate is to be certified until May 12 15:39:33 1998 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated

Sau khi thực hiện Openssl tạo ra một chứng chỉ cho đối tượng sử dụng cuối.

3.2.6. Cấu hình server sử dụng kết nối SSL Sau khi khởi tạo chứng chỉ cho một đối tượng sử dụng ta có thể sử dụng nó để khởi tạo kết nối SSL trên apache-ssl.

Server cần được cài đặt chứng chỉ server, và chứng chỉ CA phải được cài đặt trên browser. Server chỉ yêu cầu chứng chỉ của browser khi nó được thiết lập cấu hình thực hiện yêu cầu đó. Phần cấu hình của apche trong file httpd.conf như sau.

# Set SSLVerifyClient to: # 0 if no certicate is required


61

# 1 if the client may present a valid certificate # 2 if the client must present a valid certificate # 3 if the client may present a valid certificate but it is not required to # have a valid CA SSLVerifyClient 2

Khi người sử dụng nhập vào đường dẫn theo kiểu “https://localhost” thì kết nối SSL thiết lập giữa server và client thành công.

Tóm tắt chương :

Chương này chúng ta đã tìm hiểu qua một trong những công nghệ xác thực sử dụng chứng chỉ X.509. Đó là giao thức SSL áp dụng trong kết nối bảo mật giữa web server và web browser. Giao thức SSL sử dụng cơ chế xác thực chứng chỉ X.509, mã hóa đối xứng và mã hóa công khai để đảm bảo tính bí mật.

Chương này còn giới thiệu thư viện mã nguồn mở Openssl, sử dụng để xây dựng một cơ quan quản lý chứng chỉ áp dụng trong giao thức xác thực SSL. Đây sẽ là nền tảng để phát triển một cơ sở hạ tầng bảo mật khóa công khai hoàn chỉnh.


62

KẾT LUẬN

1. Kết quả đạt được

Sau thời gian tìm hiểu và nghiên cứu, khóa luận đã cô đọng một khối lượng kiến thức lớn về các vấn đề sau :

Tìm hiểu các dịch vụ an toàn hệ thống thông tin. Trong các dịch vụ đảm bảo an toàn hệ thống thông tin, thì dịch vụ xác thực là dịch vụ quan trọng nhất bởi các thành phần sử dụng trong dịch vụ này đảm bảo cơ chế cho các dịch vụ an toàn khác. Tìm hiểu chứng chỉ số theo chuẩn X.509, hệ thống quản lý chứng chỉ, cơ sở

hạ tầng bảo mật khóa công khai. Đây là những khái niệm cơ bản để xây dựng một hệ thống xác thực sử dụng chứng chỉ số X.509. Tìm hiểu giao thức kết nối SSL, thư viện mã nguồn mở Openssl. Sử dụng

thư viện Openssl để quản lý chứng chỉ X.509. Bao gồm việc tạo và cấp phát chứng chỉ, quản lý chính sách chứng chỉ áp dụng vào thiết lập một kết nối bảo mật SSL.

2. Đánh giá kết quả

Giá trị lý luận:

Ngày nay các thương mại điện tử, chính phủ điện tử đang phát triển mạnh mẽ trên thế giới, tuy nhiên ở Việt Nam thì mới phát triển ở giai đoạn ban đầu. Việc nghiên cứu hệ thống xác thực sử dụng chứng chỉ điện tử là một yêu cầu cấp thiết bởi chứng chỉ X.509 là hạt nhân của hệ thống xác thực trong thương mại điện tử cũng như chính phủ điện tử. Chính hệ thống xác thực này sẽ đảm bảo tính xác thực, tính toàn vẹn, chống chối bỏ, tính bí mật… trong các phiên giao dịch thương mại điện tử, chính phủ điện tử.

Giá trị thực tiễn :

Trong quá trình xây dựng khóa luận, tôi cũng tìm hiểu giao thức SSL, thư viện mã nguồn mở Openssl để xây dựng một nhà phát hành chứng chỉ. Tuy nhiên Openssl còn cung cấp một PKI đầy đủ; với các thao tác mã hóa, các hàm băm, thực hiện ký và kiểm tra chữ ký số… Đây là cơ sở để xây dựng một PKI cho từng lĩnh vực, từng hệ thống cụ thể.


63

3. Định hướng phát triển

Dựa trên kết quả đạt được tôi hi vọng rằng mình có thể tiếp tục nghiên cứu chứng chỉ số theo hai hướng lớn sau:

Phát triển các cơ sở hạ tầng khóa công khai trong mạng LAN cục bộ. Xây dựng các hệ thống xác thực dựa trên chứng chỉ X.509 như hệ thống quản lý người dùng bằng smartcard, giải pháp an toàn mạng ARP Sercurity… Xây dựng một cơ quan phát hành chứng chỉ (CA) cho các hệ thống

thương mại điện tử. Cung cấp chứng chỉ cho người dùng, cung cấp chứng chỉ cho server sử dụng kết nối SSL, cung cấp chứng chỉ cho các thành phần khác…

Xây dựng được một cơ sở hạ tầng bảo mật khóa công khai hoàn chỉnh là một thách thức lớn đối với sinh viên Việt Nam. Tôi tin tưởng rằng trong tương lai sẽ còn nhiều đề tài nghiên cứu của trường ta về chứng chỉ điện tử và cơ sở hạ tầng bảo mật khóa công khai để cung cấp nguồn nhân lực cho lĩnh vực mới mẻ này. Đó cũng là một phần đóng góp giúp đất nước ta hội nhập với thế giới trong vấn đề thương mại điện tử và chính phủ điện tử.


1

TÀI LIỆU THAM KHẢO

Tài liệu tiếng Việt :

[1] Nguyễn Chí Công. An toàn bảo mật hệ thống thông tin , 2004,tr.116-134

Tài liệu tiếng Anh :

[2] Jalal Feghhi, Jalil Feghhi, Peter Williams. Digital certificates,1999,tr .61 - 89

[3] Network Working Group. rfc 3647 - Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. 2003,tr.9-11

[4] Network Working Group. rfc 3280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, 2003,tr.14-62

Các web site :

[5] http://www.openssl.org [6] http://www.modssl.org [7] http://www.entrust.com

Documents

It 045 Chung Chi So x509