Chƣơng 2 CƠ SỞ HẠ TẦNG BẢO ĐẢM ATTT TRONG GDĐT
2.3. MỘT SỐ CÔNG CỤ, PHƢƠNG TIỆN VÀ GIAO THỨC CỦA PKI
2.3.1. Công nghệ SSL
2.3.1.1. Giới thiệu về SSL
SSL (Secure Socket Layer) là giao thức đa mục đích, đƣợc thiết kế để tạo ra các giao tiếp giữa hai chƣơng trình ứng dụng trên một cổng định trƣớc (socket 443), nhằm mã hoá toàn bộ thông tin gửi/ nhận. Giao thức SSL đƣợc hình thành và phát triển đầu tiên năm 1994 bởi nhóm nghiên cứu Netscape dẫn dắt bởi Elgamal, và nay đã trở thành chuẩn bảo mật cài đặt trên Internet.
SSL đƣợc thiết kế độc lập với tầng ứng dụng để đảm bảo tính bí mật, an toàn và chống giả mạo luồng thông tin qua Internet giữa hai ứng dụng bất kỳ, thí dụ giữa webserver và các trình duyệt khách (browsers), do đó đƣợc sử dụng rộng rãi trong nhiều ứng dụng khác nhau trên môi trƣờng Internet. Toàn bộ cơ chế và hệ thống mã hoá dùng trong SSL đƣợc phổ biến công khai. Khoá phiên (session key) đƣợc sinh ra tại thời điểm trao đổi giữa hai ứng dụng là ngẫu nhiên và bí mật đối với ngƣời quan sát trên mạng máy tính.
Giao thức SSL đòi hỏi ứng dụng chủ phải đƣợc chứng thực bởi đối tƣợng thứ ba (CA) thông qua chứng chỉ số (digital certificate) dựa trên mật mã công khai.
Hình 2.1: Vị trí SSL trong mô hình OSI
SSL đƣợc thiết kế nhƣ là một giao thức riêng cho vấn đề bảo mật có thể hỗ trợ cho nhiều ứng dụng. Giao thức SSL hoạt động bên trên TCP/IP và bên dƣới các ứng dụng nhƣ là HTTP (HyperText Transfer Protocol), LDAP (Lightweight Directory Access Protocol) hoặc IMAP (Internet Messaging Access Protocol). Hiện nay SSL đƣợc sử dụng chính cho các giao dịch trên Web.
SSL cho phép server có hỗ trợ SSL tự xác thực với Client cũng hỗ trợ SSL, cho phép client tự xác thực với server, và cho phép cả hai máy thiết lập một kết nối đƣợc mã hoá.
Giao thức SSL gồm hai tầng: Tầng thấp nhất là tầng SSL Record Protocol, nó đƣợc dùng để đóng gói một vài giao thức ở mức cao hơn. Một trong những giao thức đƣợc đóng gói là SSL Handshake Protocol, giao thức này cho phép server và client thực hiện việc xác thực lẫn nhau, thoả thuận thuật toán mã hoá và các khoá mật mã, trƣớc khi giao thức ứng dụng gửi hoặc nhận dữ liệu.
1) Các phiên bản
SSLv2: phiên bản đầu tiên của SSL do Netscape Corporation thiết kế.
SSLv3: phiên bản SSL 3.0 do Netscape Corporation thiết kế, đã có trợ giúp chứng chỉ nhóm (chain certificate), hỗ trợ cho tất cả các trình duyệt phổ thông.
TLSv1: giao thức Transport Layer Security version 1.0 dựa trên cơ sở của SSLv3, đƣợc thiết kế bởi IETF, nhƣng hiện chƣa hỗ trợ cho tất cả các trình duyệt thông dụng.
2) Các khả năng của SSL
Kết nối an toàn:
Quá trình mã hóa dữ liệu đƣợc thực hiện sau khi quá trình bắt tay (handshake) đầu tiên xác định đƣợc khoá bí mật. Mật mã đối xứng đƣợc sử dụng cho quá trình mã hoá dữ liệu (ví dụ DES, RC4…). Đảm bảo thông tin không thể bị lộ bởi đối tƣợng thứ ba.
Danh tính của đối tác có thể đƣợc xác thực bằng mật mã khoá công khai (ví dụ RSA, DSS…).
Kết nối tin cậy:
Việc vận chuyển thông điệp bao gồm quá trình kiểm tra tính toàn vẹn của thông điệp, sử dụng hàm kiểm tra MAC có khoá. Các hàm băm an toàn (ví dụ SHA, MD5…) đƣợc dùng cho quá trình thực hiện hàm MAC, nhằm đảm bảo thông tin không bị sai lệch và thể hiện chính xác thông tin gốc gửi đến.
Khả năng tƣơng tác giữa các phần tử:
Ngƣời lập trình độc lập có thể phát triển các ứng dụng sử dụng SSL 3.0 sau khi trao đổi các tham số mật mã, mà không phải biết mã chƣơng trình của các ứng dụng khác.
Khả năng mở rộng:
SSL cung cấp một framework mà trong đó các phƣơng pháp mã hoá và khóa công khai kết hợp lại chặt chẽ với nhau.
2.3.1.2. Các giao thức trong SSL
1) Giao thức bản ghi (Record Protocol)
SSL sử dụng giao thức bản ghi (Record Protocol) để đóng gói tất cả các thông điệp. Hình 2.2 mô tả vị trí của Record Layer trong kiến trúc SSL. Nó cung cấp một định dạng chung cho các thông điệp Alert, ChangeCipherSpec, Handshake hay thông điệp của các giao thức ứng dụng nhƣ HTTP, Telnet….
Hình 2.2: Vị trí giao thức bản ghi trong giao thức SSL
Giao thức bản ghi là một tầng giao thức. Đối với mỗi tầng giao thức nói chung, một gói dữ liệu bao gồm các trƣờng độ dài, mô tả và nội dung dữ liệu.
Giao thức bản ghi nhận dữ liệu cần gửi từ tầng trên, phân nhỏ thành từng block (khối), nén dữ liệu, bổ sung dữ liệu kiểm tra, mã hoá và gửi.
Khi nhận dữ liệu về, tiến trình đƣợc thực hiện ngƣợc lại: giải mã, kiểm tra, giải nén và sắp xếp lại rồi gửi lên tầng trên. Các giai đoạn trong giao thức này đƣợc minh hoạ trong hình 2.3.
Dữ liệu tầng ứng dụng có thể là dữ liệu của giao thức SSL handshake, giao thức SSL ChangeCipherSpec, giao thức SSL Alert hoặc dữ liệu của các ứng dụng khác nhƣ HTTP, Telnet…
Để phân biệt đƣợc từng loại dữ liệu đó, trong mỗi frame dữ liệu của SSL record, đều có phần header (phần nội dung thêm vào đầu thông điệp) để phân biệt.
Hình 2.3: Các giai đoạn thi hành của giao thức bản ghi
Bước 1. Fragmentation (phân mảnh):
Mỗi thông điệp tầng trên đƣợc phân nhỏ thành các khối 214
byte (16384) hoặc nhỏ hơn.
Bước 2. Compression (nén):
Điều này là tuỳ chọn. Nén phải không làm mất dữ liệu và không thể gia tăng kích thƣớc dữ liệu hơn 1024 byte. Trong SSLv3, không có thuật toán nén nào đƣợc chỉ định, thì thuật toán nén mặc định là null.
Bước 3. Tính toán mã xác thực thông điệp MAC (Message Authentication
Code) qua dữ liệu đã đƣợc nén:
Biến đổi cấu trúc SSLCompressed thành cấu trúc SSLCiphertext. Bước 4. Thêm vào phần đầu một header gồm các trƣờng:
Protocol (1 byte): Thể hiện giao thức tầng cao hơn đƣợc sử dụng trong thông điệp SSL Record Layer.
Version (2 byte): Phiên bản chính và phụ của đặc tả SSL mà thông điệp tuân theo. Phiên bản hiện tại của SSL là 3.0.
Length (2 byte): Số 16 bít thể hiện độ dài của giao thức tầng cao hơn. Đặc tả SSL quy định số này không đƣợc vƣợt quá 214
Protocol Message (n byte): Thông điệp của giao thức tầng cao hơn, có thể dài đến 214
(16384) byte kể cả mã xác thực. SSL Record Layer có thể nối nhiều thông điệp tầng cao hơn trong một thông điệp SSL Record Layer đơn (phải có cùng giao thức tầng cao hơn).
Hình 2.4:. Cấu trúc một thông điệp SSL Record
SSL định nghĩa bốn giao thức tầng cao khác nhau mà Record Layer có thể hỗ trợ là: ChangeCipherSpec protocol (20), Alert protocol (21), Handshake protocol (22), Application protocol data (23).
2) Giao thức ChangeCipherSpec
Giao thức ChangeCipherSpec gồm các quá trình chuyển tiếp các tín hiệu trong chiến lƣợc mật mã. Giao thức này có một thông điệp, đƣợc mã hoá và đƣợc nén theo CipherSpec hiện tại.
Hình 2.5: Thông điệp ChangeCipherSpec
Phần sẫm màu là Record Layer header, với giá trị protocol là 20, version 3.0, và chiều dài 1. Bản thân thông điệp ChangeCipherSpec chỉ gồm 1 byte, giá trị 1.
Client và server sẽ gửi thông điệp ChangeCipherSpec để báo tin cho bên kia biết đƣợc các bản ghi, sau này sẽ đƣợc bảo vệ dƣới CipherSpec với các khoá mà hai bên đã thoả thuận.
Khi nhận đƣợc thông điệp này, bên nhận sẽ chuyển trạng thái chuẩn bị đọc thành trạng thái đọc hiện tại. Sau khi trao đổi khoá (Key Exchange) và chứng chỉ để xác thực thông điệp (CertificateVerify), client sẽ gửi thông điệp này, server sẽ gửi lại cho client thông điệp tƣơng tự, sau khi server xử lý xong thông điệp mà client gửi cho.
Khi thông điệp ChangeCipherSpec bất thƣờng xuất hiện, thì một
unexpected_message sẽ đƣợc tạo ra. Khi sử dụng lại các phiên trƣớc đây, thông
điệp ChangeCipherSpec sẽ đƣợc gửi sau các thông điệp hello.
3) Giao thức cảnh báo (Alert Protocol)
Các hệ thống dùng giao thức Alert để báo hiệu một lỗi hoặc một cảnh báo xảy ra trong quá trình truyền thông giữa hai bên, và SSL gán cho kiểu giao thức của Alert là 21. Alert Protocol cũng giống nhƣ các giao thức SSL khác, sử dụng Record Layer định dạng thông điệp của nó.
Các thông điệp alert truyền tải các thông báo lỗi, hay cảnh báo trong quá trình thiết lập, cũng nhƣ trao đổi dữ liệu của phiên liên lạc. Cũng nhƣ các loại thông điệp khác, thông điệp alert cũng đƣợc mã hoá và nén. Mỗi thông điệp trong giao thức này bao gồm hai byte.
Byte đầu tiên lƣu giá trị cảnh báo (1) hay lỗi (2). Nếu là lỗi, SSL sẽ ngay lập tức đóng kết nối. Các kết nối khác trên cùng phiên có thể vẫn tiếp tục, nhƣng không kết nối mới nào trong phiên này có thể đƣợc thiết lập. Byte thứ hai bao gồm một mã thể hiện kiểu cảnh báo cụ thể.
Tiếp theo đây là các đặc tả lỗi và cảnh báo cụ thể cùng với giá trị của nó.
a) Kiểu Closure Alert
Client và server phải biết đƣợc khi nào kết nối đang kết thúc, để tránh cách tấn công cắt cụt (truncation attack). Hoặc mỗi bên tham gia có đƣa ra các thông điệp thông báo đóng kết nối.
close_notify (0) : thông báo cho bên nhận biết rằng: bên gửi sẽ không gửi tiếp thông điệp trên kết nối. Sau khi nhận đƣợc thông báo này, thì bất kỳ dữ liệu nào nhận đƣợc đều bị loại bỏ.
b) Kiểu Error Alert
Quá trình xử lý lỗi trong SSL Hanshake Protocol rất đơn giản. Khi một lỗi đƣợc phát hiện, thì bên phát hiện ra lỗi sẽ gửi thông điệp cho bên kia, sau đó cả hai bên đóng kết nối ngay lập tức. Các servers và clients phải bỏ qua định danh phiên, khoá, các bí mật của kết nối bị hỏng này. Sau đây là một số thông báo lỗi:
unexpected_message (10): một thông điệp không phù hợp đã đƣợc nhận.
bad_record_mac (20): thông báo này đƣợc trả lại, nếu một bản ghi nhận đƣợc có MAC không đúng.
decompression_failure (30): hàm giải mã nhận đầu vào không phù hợp (ví dụ dữ liệu mở rộng vƣợt quá kích thƣớc cho phép).
handshake_failure (40): thông báo cho biết bên gửi không thể thoả thuận một tập các tham số an toàn, đƣợc đƣa vào trong các tuỳ chọn.
no_certificate (41): thông báo này có thể gửi đi để đáp lại yêu cầu cần xác thực, nếu việc xác thực không phù hợp.
bad_certificate (42): việc xác thực bị ngắt, ví dụ chữ ký dùng cho xác thực không phù hợp.
unsupported_certificate (43): việc xác thực là kiểu không đƣợc hỗ trợ.
certificate_revoked (44): bên tham gia huỷ bỏ việc xác thực.
certificate_expired (45): xác thực đã hết hạn, hay hiện tại không có giá trị.
certificate_unknown (46): xuất hiện vấn đề khác trong quá trình xác thực.
4) Giao thức bắt tay (Handshake Protocol)
SSL Handshake Protocol là phần quan trọng của SSL, nó cung cấp ba dịch vụ cho kết nối SSL giữa client và server. Handshake Protocol cho phép client/server thống nhất về phiên bản giao thức, xác thực mỗi bên bằng cách thi hành MAC, thoả thuận về thuật toán mã hoá và khoá lập mã để bảo vệ dữ liệu gửi đi trong một SSL record, trƣớc khi giao thức ứng dụng truyền đi hay nhận đƣợc byte dữ liệu đầu tiên.
Giao thức bắt tay (Handshake Protocol) bao gồm một dãy các thông điệp đƣợc trao đổi bởi client và server. Hình 2.8 minh hoạ sự trao đổi các thông điệp
handshake cần thiết để thiết lập một kết nối logic giữa client và server. Nội dung và ý nghĩa mỗi thông điệp đƣợc mô tả chi tiết trong các phần sau:
Tiến trình hoạt động của giao thức bắt tay có thể mô tả tóm tắt nhƣ sau:
Client gửi tới server số hiệu phiên bản SSL của client, các tham số của thuật toán mã hoá, sinh dữ liệu ngẫu nhiên và các thông tin khác mà server cần, để thiết lập kết nối với client.
Server gửi tới client số hiệu phiên bản SSL của server đang dùng, các tham số của thuật toán mã hoá, sinh dữ liệu ngẫu nhiên và các thông tin khác mà client cần để thiết lập kết nối với server có sử dụng SSL.
Server cũng gửi chứng chỉ của mình tới client: Nếu client yêu cầu tài nguyên của server mà cần sự xác thực client, thì server sẽ yêu cầu chứng chỉ của client.
Client dùng một số thông tin mà server gửi đến, để xác thực server. Nếu nhƣ server không đƣợc xác thực, thì ngƣời dùng sẽ đƣợc cảnh báo và kết nối không đƣợc thiết lập. Nếu nhƣ xác thực đƣợc server, thì phía client sẽ thực hiện tiếp pha 4. Sử dụng các thông tin đƣợc tạo ra trong giai đoạn “bắt tay” ở trên, client (với sự cộng tác của server và thuật toán đƣợc dùng) tạo ra premaster secret cho phiên
làm việc. Client mã hoá dữ liệu bằng khoá công khai (public key) mà server gửi đến trong chứng chỉ (ở pha 2) và gửi đến server.
Nếu server có yêu cầu xác thực client (tuỳ chọn trong quá trình bắt tay), client sẽ ký vào dữ liệu. Đó là dữ liệu duy nhất đối với quá trình “bắt tay” và đều đƣợc lƣu trữ bởi client và server.
Client sẽ gửi cả dữ liệu đƣợc ký, chứng chỉ số của mình cùng với premaster secret đã đƣợc mã hoá tới server.
Server cố gắng xác thực client. Nếu client không đƣợc xác thực, phiên làm việc sẽ bị ngắt.
Nếu client đƣợc xác thực, server dùng khoá riêng để giải mã premaster secret, sau đó tạo ra master secret.
Client và server dùng master secret để tạo ra session key (khoá phiên). Đó là khoá đối xứng dùng để mã hoá và giải mã thông tin trong phiên làm việc và kiểm tra tính toàn vẹn dữ liệu (xác định sự thay đổi dữ liệu giữa thời điểm gửi và nhận).
Client gửi thông điệp tới server thông báo rằng các thông điệp tiếp theo sẽ đƣợc mã hoá bằng session key. Sau đó gửi kèm theo thông điệp riêng biệt, xác định quá trình “bắt tay” phía server đã kết thúc.
Đến đây, giai đoạn “bắt tay” đã hoàn thành, phiên làm việc SSL bắt đầu. Cả hai phía client và server sẽ dùng các session key để mã hoá và giải mã thông tin trao đổi giữa hai bên, và kiểm tra tính toàn vẹn dữ liệu.
Khi client và server quyết định sử dụng lại phiên trƣớc, hoặc tạo một bản sao của phiên đang tồn tại (thay vì phải thoả thuận các tham số an toàn mới), thì luồng thông điệp hoạt động nhƣ sau:
Client gửi ClientHello có sử dụng Session ID của phiên đƣợc dùng lại, server kiểm tra nơi lƣu trữ phiên (session cache) tƣơng ứng.
Nếu có, server thiết lập lại kết nối dƣới trạng thái phiên đƣợc chỉ định, server gửi thông điệp ServerHello có giá trị Session ID giống hệt.
Mỗi khi quá trình thiết lập lại đƣợc hoàn thành, thì client và server có thể trao đổi dữ liệu lớp ứng dụng.
Ngƣợc lại nếu Session ID không tìm thấy, thì server tạo ra Session ID mới, SSL client và server thực hiện quá trình “bắt tay” nhƣ trên.
Mô tả từng giai đoạn cụ thể nhƣ sau:
Pha 1: Các thông điệp Hello cho kết nối logic
Client gửi thông điệp ClientHello tới server, nó đáp ứng lại bằng thông điệp ServerHello, hoặc ngƣợc lại nếu một lỗi xảy ra và kết nối thất bại.
ClientHello và ServerHello đƣợc dùng để tăng tính an toàn giữa client và server. ClientHello và ServerHello thiết lập các thuộc tính: Protocol Version, Session ID, Cipher Suite và Compression Method. Ngoài ra hai giá trị ngẫu nhiên đƣợc tạo ra và đƣợc trao đổi là: ClientHello.random và ServerHello.random.
Các thông điệp giai đoạn “chào hỏi” đƣợc sử dụng để trao đổi các thuộc tính thừa kế bảo mật giữa client và server.
Pha 2: Xác thực Server và trao đổi khoá
Sau các thông điệp hello, server bắt đầu pha 2 bằng cách gửi chứng chỉ của nó nếu nó cần đƣợc xác thực. Thêm vào đó, một thông điệp ServerKey Exchange có thể đƣợc gửi nếu nó đƣợc yêu cầu. Nếu server đã đƣợc xác thực, nó có thể yêu cầu một chứng chỉ từ client, nếu nó thích hợp với bộ mã đƣợc chọn. Sau đó, server sẽ gửi thông điệp ServerHelloDone, thể hiện rằng giai đoạn thông điệp hello của handshake đã hoàn thành. Server sẽ đợi đáp ứng của client. Nếu server đã gửi một thông điệp yêu cầu chứng chỉ (Certificate request message), client phải gửi lại thông điệp chứng chỉ (certificate message).
Pha 3: Xác thực Client và trao đổi khoá
Nếu server đã gửi thông điệp CertificateRequest, client phải gửi thông điệp chứng chỉ của mình, sau đó là thông điệp ClientKeyExchange. Nội dung của thông