3.4.1. Giải pháp kỹ thuật cơ bản
Mã hoá: Dùng các hệ mã hoá RSA, Elgamal, DES. Ký số: Dùng các sơ đồ ký DSA, RSA, Elgamal. Chứng chỉ số: X.509
Giao thức truyền tin an toàn tầng DataLink:
Bảo vệ ARP bằng việc ký số, đƣa chứng chỉ vào việc xác thực các IP cho các máy với địa chỉ MAC.
Giao thức truyền tin tầng ứng dụng:
Trao đổi hồ sơ, văn bản dựa trên giao thức S/MIME. Công cụ phát triển: Dựa trên phần mềm mã nguồn mở.
3.4.2. Mô hình kiến trúc kỹ thuật cho CA
Trong đó, chính sách chứng chỉ tuân theo các quy định sau:
Bảng I: Giao diện CA-CA
Bảng II: Giao diện CA-EE
Bảng III: Giao diện hồi đáp EE và giao diện hồi đáp VA
Nội dung Giao diện
Giao thức truy nhập EE-VA Tuỳ chọn. Vai trò của VA
Certificate Validation Server (Path Construction, Path Validation)
Bảng IV: Giao diện EE-VA
Nội dung Giao diện
Chính sách chứng chỉ X.509(97) v3[x509], RFC3280[3280] Định dạng mã hoá chứng chỉ DER[x690]
Chính sách CRL X.509(97) v3, RFC3280
Định dạng mã hoá CRL DER
Định dạng yêu cầu chứng chỉ chéo PKCS#10[p10] Định dạng hồi đáp chứng chỉ. X.509/DER Phƣơng pháp gửi che dấu thông tin E-Mail
POP (proof of possession) Xác minh chữ ký trên chứng chỉ
Nội dung Giao diện
Định dạng chứng chỉ EE PKCS#12[p12]
(Bao gồm cả khoá bí mật)
Nội dung Giao diện
Giao thức truy nhập
Nội dung Giao diện
Phƣơng thức hợp lệ hoá đƣờng dẫn
chứng chỉ RFC3280
Thực thể xác minh chứng chỉ VA, EE
Bảng V: Giao diện EE-EE
Ghi chú:
+ Giao diện CA-CA: Giao diện trao đổi giữa hai cơ quan chứng thực.
+ Giao diện CA-EE: Giao diện giữa cơ quan chứng thực và ngƣời dùng cuối. + Giao diện hồi đáp EE: Giao diện các thông tin phản hồi lại ngƣời dùng cuối. + Giao diện hồi đáp VA: Giao diện các thông tin phản hồi lại các hệ thống chứng thực mở rộng.
+ Giao diện EE-VA: Giao diện giữa ngƣời dùng cuối và hệ thống chứng thực mở rộng.
+ Giao diện EE-EE: Giao diện giữa các đối tƣợng dùng cuối với nhau (có thể giữa các modun phần mềm với nhau hoặc giữa ngƣời dùng cuối với các đối tƣợng/ thiết bị dùng cuối).
3.4.3. Giới thiệu công nghệ OpenCA
OpenCA là dự án nhằm xây dựng PKI hoàn chỉnh, chuyên nghiệp cho các đơn vị cỡ vừa và lớn. OpenCA đƣợc phát triển liên tục từ năm 1999 đến nay, từ năm 2001, OpenCA đã bắt đầu đƣợc sử dụng trong thực tế.
OpenCA dùng giao diện web, hỗ trợ hầu hết các web browser chính, khác với sản phẩm thƣơng mại, không hỗ trợ sản phẩm mã nguồn mở, vì sợ bị cạnh tranh.
OpenCA bao gồm các module:
Giao tiếp công cộng: Giao diện web để ngƣời dùng truy cập qua internet.
Ngƣời dùng có thể đăng kí xin cấp chứng chỉ trực tiếp qua module này. Giao tiếp LDAP: Danh bạ công bố khoá công khai, ngƣời dùng thƣờng lấy
khoá công khai từ module này để thực hiện việc mã hoá trƣớc khi gửi thƣ đến đơn vị dùng OpenCA.
Giao tiếp RA: Đơn vị điều hành RA dùng module này để nhập các thông tin
xác thực cá nhân của ngƣời xin cấp chứng chỉ.
Giao tiếp OCSP: Module hỗ trợ kiểm tra chứng chỉ còn hiệu lực hay không.
Công nghệ OCSP có tác dụng nhƣ việc công bố CRL, nhƣng tính năng ƣu việt hơn hẳn CRL.
Giao tiếp CA: Module kí số riêng rẽ cho phép CA làm theo nguyên tắc an
ninh - tách biệt khỏi mạng công cộng để bảo vệ tối đa khoá bí mật. Điều này khiến cho OpenCA trở nên an toàn hơn hầu hết các phần mềm CA hiện nay trên thị trƣờng.
Ngoài những tính năng thiết yếu của một PKI, OpenCA có nhiều tính năng ƣu việt nhƣ:
Đăng nhập bằng chứng chỉ.
Hệ thống quản lý quyền mềm dẻo.
Sử dụng đƣợc hết các tính năng của X.509 mở rộng.
OpenCA là phần mềm mã nguồn mở miễn phí, có sẵn tài liệu chi tiết đầy đủ, giúp cho việc tìm hiểu và ứng dụng OpenCA một cách dễ dàng.
Hình 3.11: Mô hình kiến trúc tổng quát của OpenCA
Hình 3.12: Mô hình quan hệ phân cấp giữa CA, RA và người dùng
OpenCA Hệ điều hành Linux OpenLDAP Dịch vụ thư mục cho chứng chỉ số OpenSSL
Thư viện tầng Socket an toàn (hoặc thư
viện khác) Apache secure web server CA RA RA User User
3.5. MÔ HÌNH QUẢN LÝ CƠ CHẾ AN TOÀN 3.5.1. Quản lý khoá 3.5.1. Quản lý khoá
Tạo khoá (Creating Keys):
Một cặp khoá mới đƣợc tạo, bao gồm Secret Key và Public Key. Việc tạo ra các khoá này dựa trên một thuật toán mã hoá nào đó (thông thƣờng sử dụng RSA). Để tạo ra cặp khoá, cần thực hiện các thao tác sau:
- Lựa chọn độ dài của khoá: Nếu độ dài của khoá lớn thì khả năng bảo mật
thông điệp càng cao. Do vậy cần cân nhắc giữa mức độ bảo mật và thời gian xử lý của hệ thống. Độ dài của khoá thông thƣờng trong khoảng 768 bits đến 2048 bits.
- Khai báo các thông tin cá nhân: Các thông tin nhƣ họ tên, ngày sinh, địa
chỉ,… Các thông tin này có thể thay đổi về sau.
- Nhập Password: Nó đƣợc dùng để điều khiển Secret Key. Phải ghi nhớ
password này, nếu không sẽ không thể phục hồi lại nó, cũng nhƣ kiểm soát Secret Key đã tạo ra.
Thực hiện đủ các bƣớc trên, sẽ tạo đƣợc cặp khoá (Secret Key, Public Key).
Xuất khoá (Exporting Key):
Khi xuất khoá công khai, sẽ có khả năng trao đổi dữ liệu một cách an toàn với nhiều ngƣời dùng khác trên Internet.
Nhập khoá (Import Keys):
Khi đã có public key của ai đó, cần đƣa nó vào cơ sở dữ liệu khoá, để sau này sử dụng nó.
Huỷ bỏ khoá (Revoke Keys):
Các tình huống dẫn đến việc huỷ bỏ khoá công khai (public key) bao gồm: Secret key bị mất, ID ngƣời dùng bị thay đổi, hoặc đơn giản là không muốn dùng Key đó nữa.
Để huỷ bỏ khoá, cần có Secret Key để đảm bảo rằng chỉ có chủ sở hữu thực sự mới có quyền huỷ bỏ public key đó.
Quản lý khoá (Administration Keys):
Việc quản lý khoá bao gồm: Thống kê thông tin về các khoá, xoá public key, Secret key, chỉnh sửa thông tin về key (chẳng hạn thời hạn của key).
Để đảm bảo quản lý khoá đƣợc an toàn, ngƣời ta còn tổ chức quản lý khoá theo trật tự cấp bậc: Một hạ tầng cơ sở chứng thực (certificate infrastructure) tích hợp và có trật tự cấp bậc sẽ đối phó với vấn đề mạo xƣng và đảm bảo thông tin đƣợc sao lƣu hoặc khôi phục đƣợc gửi tới từ máy tính tin cậy. Một cơ chế nhƣ vậy có thể đƣợc dùng để đảm bảo rằng chỉ ngƣời dùng có thẩm quyền mới khôi phục đƣợc dữ liệu mà họ đƣợc phép truy cập.
Ngoài ra, việc quản lý khoá trong mô hình hệ thống xây dựng cần tuân theo nghị định đã đƣợc Chính phủ ban hành [7], cụ thể một số điểm nhƣ sau:
- Chữ ký số đƣợc tạo ra trong thời gian chứng thƣ số có hiệu lực, và kiểm tra đƣợc bằng khoá công khai, ghi trên chứng thƣ số có hiệu lực đó.
- Chữ ký số đƣợc tạo ra bằng việc sử dụng khoá bí mật tƣơng ứng với khoá công khai ghi trên chứng thƣ số, do tổ chức cung cấp dịch vụ chứng thực chữ ký số quốc gia, tổ chức cung cấp dịch vụ chứng thực chữ ký số công cộng, tổ chức cung cấp dịch vụ chứng thực chữ ký số chuyên dùng, đƣợc cấp giấy chứng nhận đủ điều kiện đảm bảo an toàn cho chữ ký số, hoặc tổ chức cung cấp dịch vụ chứng thực chữ ký số nƣớc ngoài đƣợc công nhận tại Việt Nam cấp.
- Khóa bí mật chỉ thuộc sự kiểm soát của ngƣời ký tại thời điểm ký.
- Khóa bí mật và nội dung thông điệp chỉ gắn duy nhất với ngƣời ký, khi họ ký số vào thông điệp.
3.5.2. Quản lý mã hoá
Trong quá trình mã hoá và giải mã, không chỉ cần public key và secret key của ta, mà phải cần đến public key của ngƣời cần trao đổi dữ liệu an toàn. Khi mã hoá dữ liệu gửi cho ngƣời khác, thì phải chọn chính public key của ngƣời đó để mã hoá dữ liệu. Khi nhận đƣợc dữ liệu, họ sẽ dùng chính secret key của mình để giải mã dữ liệu đã đƣợc ta mã hoá bằng chính public key của họ.
Thông tin trao đổi giữa client và server đƣợc mã hoá trên đƣờng truyền, nhằm nâng cao khả năng bảo mật. Điều này rất quan trọng đối với cả hai bên khi có các giao dịch mang tính riêng tƣ. Ngoài ra tất cả các dữ liệu đƣợc gửi đi trên một kết nối SSL đã đƣợc mã hoá.
3.5.3. Quản lý kiểm soát truy nhập
Đây là nội dung rất quan trọng đối với việc đảm bảo an toàn của hệ thống, kiểm soát truy cập có thể phân thành các nội dung cơ bản sau:
3.5.3.1. Kiểm tra tính hợp lệ của dữ liệu đầu vào:
Các ứng dụng Web dùng dữ liệu đầu vào trong các truy cập HTTP (hoặc trong các tập tin) nhằm xác định kết quả phản hồi. Tin tặc có thể sửa đổi bất kỳ phần nào của một truy xuất HTTP, bao gồm URL, querystring, headers, cookies, form fields, và thậm chí field ẩn (hidden fields), nhằm vƣợt qua các cơ chế bảo mật. Các tấn công phổ biến dạng này bao gồm:
Chạy lệnh hệ thống tùy chọn. Cross site scripting.
Lỗi tràn bộ đệm.
Tấn công Format string. SQL injection.
Cookie poisoning. Sửa đổi field ẩn.
Một số Website bảo vệ chống lại loại tấn công này bằng cách thiết lập bộ lọc dữ liệu đầu vào. Có rất nhiều cách để mã hóa (encode) dữ liệu, và những phƣơng cách mã hóa này không giống nhƣ các cách mã hóa thông thƣờng khác ở chỗ là nó dễ dàng đƣợc giải mã. Tuy vậy, những nhà lập trình viên thƣờng quên giải mã tất cả các tham số trƣớc khi sử dụng chúng. Tham số cần phải đƣợc chuyển đổi đến dạng đơn giản nhất trƣớc khi đƣợc kiểm tra, nếu không, dữ liệu xấu đầu vào có thể đƣợc mã hóa ẩn và vƣợt qua tầng bảo vệ của các module kiểm tra dữ liệu.
Một số lƣợng lớn ứng dụng chỉ sử dụng các cơ chế lọc phía trình duyệt để kiểm tra dữ liệu đầu vào. Các cơ chế kiểm tra phía trình duyệt rất dễ dàng đƣợc vƣợt qua, và ứng dụng web xem nhƣ không đƣợc bảo vệ bởi cơ chế này.
Tin tặc có thể tạo ra các truy xuất HTTP không thông qua trình duyệt bằng cách sử dụng các công cụ nhƣ telnet, truy xuất thẳng đến cổng 80 của máy chủ web. Kiểm tra dữ liệu ở phía máy trình duyệt có lợi điểm về hiệu suất và tính dễ sử dụng, tuy nhiên cơ chế này không cung cấp bất cứ lợi điểm gì về bảo mật. Kiểm tra dữ liệu ở phía server đóng vai trò thiết yếu trong việc ngăn cản những cuộc tấn công dạng sửa đổi tham số đầu vào. Khi các cơ chế bảo vệ ở server đã đƣợc thiết lập, cơ chế bảo vệ phía trình duyệt có thể đƣợc sử dụng nhằm giảm bớt dung lƣợng các dữ liệu không hợp lệ đến máy chủ.
Hình 3.15 mô tả phƣơng cách phổ biến của hacker hiện nay sử dụng để tấn công
ứng dụng web. Trƣớc tiên, hacker thiết lập một proxy đứng giữa trình duyệt và máy chủ ứng dụng web. Proxy này có khả năng chặn các gói dữ liệu trƣớc khi chuyển đến máy chủ, do đó cho phép hacker sửa đổi dữ liệu truy cập và chèn các mã tấn công trƣớc khi gửi đến ứng dụng web.
Những tấn công dạng này đang có xu hƣớng ngày càng phổ biến hơn do số lƣợng các công cụ hỗ trợ các chức năng tạo tham số bất kỳ, tạo mã tấn công, tấn công brute force đang ngày càng tăng. Hậu quả cuộc việc sử dụng các tham số không đƣợc kiểm tra không nên đƣợc xem nhẹ. Một số lƣợng lớn các cuộc tấn công sẽ gây khó khăn cho nhà lập trình web, nếu họ không có một hệ thống tập trung kiểm tra tính hợp lệ của tất cả các truy xuất HTTP.
Hình 3.13: Sử dụng local proxy để thay đổi tham số
Trình duyệt Chƣơng trình local Proxy Máy chủ Web
3.5.3.2. Kiểm soát truy cập nguồn tài nguyên:
Kiểm soát truy cập tài nguyên, là cơ chế mà ứng dụng cho phép truy cập đến nội dung, tính năng ứng dụng cho một số ngƣời dùng, và từ chối truy cập cho một số ngƣời dùng khác. Những kiểm tra này đƣợc thực hiện sau quá trình xác thực, và quản lý các quyền truy cập mà ngƣời dùng đƣợc phép.
Kiểm soát truy cập bề ngoài tƣởng chừng là đơn giản, nhƣng thực tế là vấn đề rất khó đƣợc thi hành đầy đủ. Một mô hình quản lý truy cập tài nguyên cho ứng dụng cần đƣợc thiết kế theo sát nội dung và hàm chức năng của hệ thống cung cấp.
Hình 3.14: Mô hình quản lý kiểm soát truy cập nguồn tài nguyên trung tâm
Lập trình viên thƣờng không đánh giá đƣợc mức độ khó khăn trong việc xây dựng một cơ chế quản lý kiểm soát truy cập dữ liệu. Đa số những chức năng này không đƣợc thiết kế từ lúc đầu, mà đƣợc xây dựng kèm theo tùy tính năng của ứng dụng. Vì vậy, các chức năng kiểm soát đƣợc xây dựng ở khắp các module khác nhau trong mã nguồn. Khi ứng dụng đƣợc phát triển xong và đƣa và triển khai, các mã kiểm soát này sẽ trở nên không thống nhất và gây ra nhiều lỗ hổng nghiêm trọng khó phát hiện đƣợc.
3.5.3.3. Kiểm soát phiên truy cập:
Quản lý xác thực và phiên truy cập bao gồm tất cả các yếu tố quản lý xác thực ngƣời sử dụng và các phiên truy cập. Xác thực ngƣời dùng là một yếu tố quan trọng trong quy trình này, nhƣng ngay cả những cơ chế xác thực mạnh nhất vẫn có thể bị mắc những lỗi liên quan đến các chức năng quản lý xác thực, bao gồm thay đổi password, quên password, nhớ password ở trình duyệt, cập nhật tài khoản, và những hàm chức năng khác.
Xác thực ngƣời dùng trên một ứng dụng thƣờng bao gồm sử dụng một username và password. Những phƣơng pháp xác thực khác mạnh hơn bao gồm các giải pháp phần cứng hoặc mềm dựa trên các token mã hóa hoặc dùng phƣơng pháp sinh trắc học (biometrics). Tuy nhiên những phƣơng pháp này có phần hạn chế do giá thành cao. Một số lƣợng lớn lỗi ứng dụng trong các hàm quản lý tài khoản và phiên truy cập có thể dẫn đến mối nguy cơ lộ tài khoản ngƣời sử dụng và thậm chí tài khoản của ngƣời quản trị.
Các ứng dụng thƣờng phải theo dõi và duy trì phiên truy cập của ngƣời dùng, nhằm phân biệt các truy cập từ ngƣời dùng khác nhau. Giao thức HTTP không cung cấp khả năng này và do đó các ứng dụng phải tự tạo cơ chế này. Thƣờng thì, môi trƣờng phát triển ứng dụng cung cấp cơ chế quản lý phiên truy cập (thƣờng dƣới hình thức cookie token), tuy nhiên, đa số các nhà lập trình nghiêng về phát triển cơ chế riêng. Trong cả hai trƣờng hợp, nếu token quản lý phiên truy cập không đƣợc bảo vệ, tin tặc có thể ăn cắp token truy cập tài khoản của ngƣời khác.
3.5.4. Quản lý toàn vẹn dữ liệu
Cơ chế để kiểm tra tính toàn vẹn của dữ liệu, ngƣời nhận trƣớc tiên dùng khóa công khai của ngƣời ký để giải mã đại diện văn bản (message disgest), đã đƣợc mã hóa bằng khóa bí mật của ngƣời ký. Dựa vào thông tin về thuật toán băm trong chữ ký số, ngƣời nhận sẽ tạo ra đại diện văn bản từ dữ liệu gốc và mới.
Nếu các đại diện này giống nhau, tức là dữ liệu không bị thay đổi từ lúc đƣợc ký. Nếu chúng không giống nhau có nghĩa là dữ liệu đã bị giả mạo, điều này cũng có thể xảy ra khi sử dụng hai khóa công khai và khóa bí mật không tƣơng ứng.
Hình 3.15: Sử dụng chữ ký số để kiểm tra tính toàn vẹn của dữ liệu
Trong hình trên có hai phần đƣợc gửi cho ngƣời nhận: dữ liệu gốc và chữ ký số. Nếu nhƣ hai đại diện văn bản giống nhau, ngƣời nhận có thể chắc chắn rằng