Giao thức này cung cấp hai dịch vụ cho kết nối SSL:
− bí mật: Giao thức Handshake xác định khóa bí mật dùng chung để sử dụng mã hóa đối xứng cho payload SSL.
− toàn vẹn dữ liệu: Giao thức Handshake cũng xác định khóa bí mật dùng chung sử dụng để hình thành mã xác thực văn bản (MAC).
Hình vẽ dưới đây sẽ chỉ rõ hơn toàn bộ hoạt động của giao thức SSL Record:
Hình 4.2 Hoạt động giao thức SSL Record
Đầu tiên là phân mảnh dữ liệu thành các khối có kích thước nhỏ hơn hoặc bằng 214 byte. Sau đó, có thể thực hiện nén dữ liệu, tuy nhiên trong phiên bản SSLv3, không áp dụng thuật toán nén nào nên trường này có giá trị null. Bước tiếp theo trong quá trình xử lý là tính mã xác thực văn bản trên dữ liệu đã nén. Để làm được điều này, phải có một khóa bí mật dùng chung. Tính toán này được xác định như sau:
Thêm MAC Phân mảnh Dữ liệu ứng dụng Nén Thêm header của SSL record Mã hóa
hash(MAC_write_secret || pad_2 || hash(MAC_write_secret || pad_1 || seq_num || SSLCompress.type || SSLCompress.length || SSLCompressed.fragment)) trong đó
MAC_write_secret : khóa bí mật dùng chung
hash : thuật toán băm (MD5 hạơc SHA-1)
pad_1 : byte 0x36 lặp lại 48 lần với MD5, 40 lần với SHA-1 pad_2 : byte 0x5C lặp lại 48 lần với MD5, 40 lần với SHA-1 seq_num : số tuần tự của văn bản
SSLCompress.type : giao thức tầng trên được dùng xử lý phân mảnh này SSLCompress.length : độ lớn của phân mảnh đã nén
SSLCompressed.fragment : phân mảnh nén
Sau đó, văn bản nén cùng với MAC được mã hóa bằng thuật toán mã hóa đối xứng, có thể là IDEA, RC2-40, DES-40, DES, 3DES, …Bước cuối cùng của giao thức là thêm header gồm các trường sau:
− Content Type (8 bit): giao thức tầng cao hơn được dùng để xử lý các phân đoạn đã đóng gói.
− Major Version (8 bit): phiên bản chính của SSL đang dùng. Với SSLv3 thì giá trị này bằng 3.
− Minor Version (8 bit): phiên bản phụđang dùng. Với SSLv3 thì giá trị này bằng 0.
− Compressed length (16 bit): độ lớn tính theo byte của phân đoạn bản rõ.
4.2.3Giao thức Change Cipher Spec
Một trong những giao thức đặc tả SSL dùng trong SSL Record và là giao thức đơn giản nhất, gói tin của nó chỉ có một byte với giá trị bằng 1, chỉ ra trạng thái treo để chờ sao chép vào trạng thái hiện thời, đang cập nhật bộ mã hóa sử dụng để kết nối.
4.2.4Giao thức Alert
Giao thức dùng để chuyển cảnh báo có liên quan đến SSL cho thực thể ngang hàng. Gói tin của giao thức gồm hai byte, byte thứ nhất có giá trị cảnh báo hoặc rất có hại để chuyển tính nghiêm trọng của vấn đề: nếu là rất có hại, SSL ngay lập tức kết thúc kết nối, kết nối khác của phiên làm việc sẽđược tiếp tục, không thiết lập kết nối mới. Byte thứ hai là mã đặc tả cảnh báo: gói tin nhận được không thích hợp, MAC nhận được không đúng, không giải nén được, handshake thất bại (tương ứng với giá trị thứ nhất là rất có hại).
4.2.5Giao thức Handshake
Phần phức tạp nhất của SSL. Giao thức cho phép server và client xác thực với nhau và thỏa thuận thuật toán mã hóa, MAC và khóa để bảo vệ dữ liệu SSL. Giao thức được gọi trước khi chuyển dữ liệu của ứng dụng. Giao thức bao gồm một dãy các các gói tin trao đổi giữa client và server như trong hình vẽ dưới đây:
Hình 4.3Hoạt động giao thức Handshake
Pha 1 Thiết lập năng lực an ninh gồm phiên bản giao thức, định danh phiên làm việc, bộ mã hóa, phương pháp nén, số ngẫu nhiên khởi tạo.
Pha 2 Server gửi chứng chỉ, trao
đổi khóa, và yêu cầu chứng chỉ. Tín hiệu server kết thúc pha chào hỏi.
Pha 3 Client gửi chứng chỉ nếu
được yêu cầu, trao đổi khóa, và gửi kiểm thử chứng chỉ (có thể).
Pha 4 Thay đổi bộ mã hóa và kết thúc giao thức bắt tay. (adsbygoogle = window.adsbygoogle || []).push({});
Mỗi gói tin đều gồm có ba trường:
− Type (1 byte): chỉ rõ gói tin này là loại nào trong số 10 gói tin. − Length(3 byte): độ lớn của gói tin tính theo byte.
− Content (≥ 1 byte): tham số kết hợp với gói tin.
Quá trình thiết lập kết nối logic giữa client và server có thể chia làm bốn pha như dưới đây:
Pha 1: Thiết lập năng lực an ninh
Thiết lập kết nối logic và thiết lập khả năng an ninh sẽ có. Quá trình trao đổi sẽ xuất phát từ client thông qua việc gửi client_hello_massage với các tham số dưới đây:
− Version: Phiên bản SSL mà client có thể hiểu được.
− Random: Cấu trúc ngẫu nhiên do client sinh ra chứa 32 bit − Session ID: Định danh phiên làm việc có độ dài thay đổi
− CipherSuite: Danh sách tổ hợp các thuật toán mã hóa client được hỗ trợ. − Compression Method: Danh sách các phương pháp nén client hỗ trợ. Sau khi nhận được gói tin client_hello, client chờđể nhận gói tin server_hello cũng có các tham số tương tự như gói tin client_hello.
Thành phần đầu tiên của Cipher Suite là phương thức trao đổi khóa: RSA, Diffie- Hellman có dùng chứng chỉ, Diffie-Hellman có xác thực khóa, Diffie-Hellman không có xác thực, Fortezza.
Pha 2: Xác thực server và trao đổi khóa
Server bắt đầu pha này bằng cách gửi chứng chỉ của nó, nếu thực sự cần thiết, gói tin sẽ chứa một hoặc dãy các chứng chỉ X.509. Gói tin certificate là bắt buộc với bất kỳ phương pháp thỏa thuận trao đổi khóa nào ngoại trừ Diffie-Hellman không có xác thực. Sau đó server sẽ gửi gói tin server_key_exchange đi nếu có yêu cầu. Với
hai tình huống: Server đã gửi chứng chỉ với các tham số Fixed Diffie-Hellman hay sử dụng trao đổi khóa RSA thì không cần gói tin này. Nếu server không sử dụng Diffie-Hellman nặc danh thì nó sẽ yêu cầu chứng chỉ từ client bằng cách gửi
certificate_request gồm hai tham số: certificate_type, certificate_authorities. Gói tin cuối cùng cần phải có trong mọi trường hợp là server_done kết thúc quá trình chào hỏi từ server. Sau đó server sẽđợi client trả lời.
Pha 3: Client xác thực và trao đổi khóa
Sau khi nhận được gói tin server_done từ server, client nên kiểm thử rằng server đã cung cấp chứng chỉ hợp lệ nếu cần và kiểm tra xem các tham số server_hello có chấp nhận được hay không. Nếu thỏa mãn, client sẽ gửi một vài gói tin cho server. Nếu server yêu cầu chứng chỉ, client bắt đầu pha này bằng cách gửi certificate. Nếu không có chứng chỉ client sẽ gửi no_certificate. Sau đó gửi gói tin
client_key_exchange, gói này là bắt buộc. Nội dung thì tùy thuộc phương pháp trao đổi khóa:
− RSA: client sinh giá trị 48 byte rồi mã hóa bằng khóa công khai của lấy được từ chứng chỉ của server hoặc từ gói tin server_key_change.
− Diffie-Hellman nặc danh hay thay đổi: gửi tham số Diffie-Hellman công khai của client.
− Diffie-Hellman cốđịnh: phần này sẽ là null nếu tham số Diffie-Hellman công khai của client đã gửi trong gói tin certificate.
− Fortezza: tham số Fortezza của client.
Kết thúc pha này client gửi gói tin certificate_verify để cung cấp sự kiểm thử tường minh chứng chỉ client. Gói tin này chỉ gửi đi nếu chứng chỉ client có khả năng ký.
Pha 4. Kết thúc
Pha này sẽ hoàn thành quá trình khởi động một kết nối an toàn. Client gửi gói tin change_cipher_spec và sao chép CipherSpec đang chờ vào CipherSpec hiện tại. Sau đó client ngay lập tức gửi gói tin finished bằng các thuật toán, khóa, bí mật mới.
Gói tin này sẽ kiểm thử tiến trình trao đổi khóa và xác thực có thành công hay không. Đểđáp lại server gửi gói tin chage_cipher_spec, chuyển CipherSpec chờ vào CipherSpec hiện thời, rồi gửi finished. Đến thời điểm này quá trình bắt tay đã hoàn thành từđây client và server có thể bắt đầu trao đổi dữ liệu tầng ứng dụng.
4.3.PKI
PKI (Public Key Infrastructure) cho phép các bên khi tham gia vào một giao dịch có thể nhận ra bên kia bằng cách cung cấp thông tin xác thực thông qua chứng chỉ, và tin tưởng vào truyền thông bằng cách cung cấp bí mật thông qua việc sử dụng mã hóa, xác thực, toàn vẹn dữ liệu, và không thể thoái thác thông qua chữ ký điện tử. PKI là sự hợp thành của chứng chỉđiện tử, mã hóa khóa công khai, các CA. Trong môi trường Internet mở như hiện nay thì sử dụng PKI cấp quyền cho các bên là giải pháp hợp lý nhất.
4.3.1Các dịch vụ PKI
PKI chủ yếu cung cấp dịch vụ xuất bản chứng chỉ và làm sao để có thể truy nhập và sử dụng chúng. Giống như danh bạđiện thoại vậy, thư mục PKI liệt kê khóa công khai của tổ chức hay cá nhân. Các PKI giải quyết các bài toán quản lý khóa: tạo sinh, phân phối, xác thực, và lưu giữ. Một cơ sở hạ tầng khóa công khai PKI gồm:
− Một uỷ quyền chứng chỉ (CA) sinh và kiểm thử các chứng chỉ (adsbygoogle = window.adsbygoogle || []).push({});
− Một uỷ quyền đăng ký (RA) thực hiện kiểm thửủy quyền chứng chỉ trước khi xuất bản chứng chỉ cho bên yêu cầu.
ký băm mã hóa bằng khóa đối xứng hỗ trợ hỗ trợ hỗ trợ Bản mã Bản rõ Văn bản tóm lược
Bản mã + khóa đối xứng được mã hóa Chữ ký điện tử
Chứng chỉđiện tử
Cơ sở hạ tầng khóa công khai PKI
Thành phần phần mềm PKI Chức năng PKI Cấu trúc uỷ quyền: Mô hình uỷ quyền Chứng chỉ giao chéo Sản phẩm thương mại Khả năng thông dịch Chuẩn khóa đối xứng được mã
hóa bằng khóa công khai của người nhận
− Dịch vụ thư mục (DS) trong đó các chứng chỉ (cùng với khóa công khai của chúng) được lưu giữ và có sẵn dùng (thường là trong thư mục chuẩn ITU X.500)
− Thực thể cuối (EE) giữ chứng chỉ: người dùng, tổ chức, ứng dụng, .v.v. − Các client dùng PKI để nhận chứng chỉ, hợp lệ chứng chỉ và chữ ký; − Một hệ thống quản lý chứng chỉ.
Hệ thống quản lý chứng chỉ thường có các dịch vụ sau:
− Hủy bỏ chứng chỉ: hủy chứng chỉđã xuất bản, tạo và công khai danh sách chứng chỉ thu hồi, lưu lại và ..
− Hết hạn chứng chỉ và cập nhật
− Dịch vụ bảo đảm có thể giải mã được các văn bản đã mã hóa trước đó − Sao lưu và phục hồi chứng chỉ: Bảo đảm không bị mất thông tin
− Dịch vụ hỗ trợ không thể thoái thác: việc sao lưu và phục hồi khóa gây ra một kẽ hở cho hệ thống. Ai đó có thể lợi dụng điều này cho rằng đã có người khác truy nhập tới khóa đang ký của họ, vì thế họ không hoàn toàn chịu trách nhiệm cho những giao dịch kiểu như thế, mặc dù những giao dịch này rõ ràng là do họ ký. Do đó cần thiết phải duy trì hai cặp khóa cho mỗi người dùng. Cặp khóa mã hóa có thể sao lưu và phục hồi, ngược lại thì cặp khóa ký không nên để cho người dùng sở hữu hoàn toàn.
− Dịch vụ tem thời gian
NHẬN XÉT VÀ KẾT LUẬN Ý nghĩa của việc nghiên cứu vấn đề
Vấn đềđặt ra trong luận văn rất cần thiết trong nghiên cứu về mật mã, và sử dụng chúng trong các ứng dụng, đặc biệt là ngày nay khi mà hầu hết các hoạt động trao đổi thông tin của con người đều được thực hiện thông qua mạng truyền thông công cộng như Internet. Trong bối cảnh đó kể cả khi hệ thống sử dụng phương pháp mã hóa công khai thì việc quản lý và điều phối việc sử dụng khóa vẫn cực kỳ cần thiết. Còn nếu hệ thống sử dụng thuật toán mã hóa đối xứng thì việc trao đổi, phân phối, chuyển vận giá trị bí mật một cách an toàn cho hai bên là yêu cầu tất yếu. Trên cơ sởđó luận văn đã cố gắng tìm hiểu các giao thức tạo lập khóa bí mật và các kỹ thuật quản trị khóa và đạt được một vài kết quả nhất định.
1. Các kết quảđạt được
- Nghiên cứu tìm hiểu và phân tích các giao thức tạo lập khóa: trao đổi, phân phối, chuyển vận khóa .
- Tìm hiểu các kỹ thuật quản trị và kiểm tra việc sử dụng khóa.
- Tìm hiểu giao thức socket an toàn – công nghệứng dụng sử dụng các giao thức tạo lập khóa đã nghiên cứu, cơ sở hạ tầng khóa công khai PKI trong môi trường mạng toàn cầu.
2. Hướng phát triển của luận văn
- Nghiên cứu thay đổi các giao thức trao đổi khi đưa vào thực tế nhằm làm tăng thêm độ an toàn và tin cậy cho các bên tham gia truyền thông.
- Nghiên cứu các khả năng tránh được các tấn công dùng lại, an toàn tiếp theo, tránh tấn công từ chối dịch vụ và bảo vệ danh tính của khóa phiên trong các giao thức trao đổi khóa.
- Nghiên cứu và đề xuất một vài giải pháp cho các hệ thống ứng dụng mã hóa đòi hỏi sự tin cậy nhiều nhất hiện nay.
TÀI LIỆU THAM KHẢO Tiếng Việt
[1] Phan Đình Diệu (2002), Lý thuyết mật mã & an toàn thông tin, Nhà xuất bản Đại học Quốc gia Hà nội.
[2] Phạm Huy Điển – Hà Huy Khoái (2003), Mã hóa thông tin - Cơ sở Toán học & ứng dụng, Nhà xuất bản Đại học Quốc gia Hà nội.
[3] Hà Huy Khoái (1997), Nhập môn số học thuật toán, Nhà xuất bản Khoa học.
Tiếng Anh (adsbygoogle = window.adsbygoogle || []).push({});
[4] A.J. Menezes, P.C. Van Oorschot, S.A. Vanstone (1997), Handbook of Applied Cryptography, CRC Press.
[5] Bruce Schneier (1996), Applied Cryptography – Protocols, Algorithms and Source Code in C, John Wiley & Sons, Inc.
[6] Douglas R.Stinson (1995), Cryptography – Theory and Practice, CRC Press
[7]. Jan Li (2000), Public key infrastructure technology introduction, Intel Semiconductor Ltd.
[8] S. Goldwasser, M.Bellare (2001), Lecture notes on Cryptography, MIT Laboratory of Computer Science.
[9] Steven M. Bellovin & Michael Merritt (1992), Encrypted Key Exchange: Password Based Protocols Secure Against Dictionary Attacks. The IEEE
Symposium on Research in Security and Privacy Oakland May 1992
[10] William Stalling (1998), Cryptography and network security – Principles and Practice, 2nd ed., Prentice Hall, Inc.