Đồ án Nghiên cứu về SSL và ứng dụng của SSL trong bảo mật Web

động của SSL Record Protocol.SSL Record Protocol nhận 1 message ứng dụng sắp được truyền đi,phân mảnh dữ liệu thành nhiều block,nén dữ liệu 1 cách tùy chọn,áp dụng vào 1 MAC,mã hóa,thêm vào header,và truyền khối kết quả thu được trong 1 segment TCP.Dữ liệu nhận được được giải mã,kiểm tra ,giải nén,sắp xếp lại và phân phối đến người sử dụng ở lớp cao hơn. Hình I.2 : Hoạt động của SSL Record Protocol Bước đầu tiên là phân mảnh.Mỗi message của lớp bên trên được phân mảnh thành các block ,mỗi block là 214 byte (16384 byte) hoặc ít hơn. Tiếp theo,nén đƣợc áp dụng 1 cách tùy chọn.Nén phải là không mất mát thông tin và có thể không làm tăng chiều dài nội dung nhiều hơn 1024 byte (Dĩ nhiên,người ta mong muốn nén làm co lại dữ liệu hơn là nới rộng dữ liệu.Tuy nhiên ,với những block ngắn,có thể ,do định dạng quy ước,thuật toán nén thực sự làm cho output dài hơn input).Trong SSLv3 (cũng như phiên bản hiện tại của TLS),không có thuật toán nén nào được chỉ rõ,vì vậy thuật toán nén mặc định là null. Bƣớc xử lí kế tiếp là tính toán MAC (mã xác thực message) trên dữ liệu đã được nén.Để thực hiện cần dùng đến1 khóa bí mật được chia sẻ.Phép tính được định nghĩa như sau: hash(MAC_write_secret || pad_2 || hash(MAC_write_secret || pad_1 ||seq_num ||SSLCompressed.type || SSLCompressed.length || SSLCompressed.fragment)) trong đó: Ø || : phép nối/hoặc. Ø MAC_write_secret: khóa bí mật được chia sẻ. Ø hash: thuật toán băm mã hóa, MD5 hoặc SHA-1. Ø pad_1: byte 0x36 (0011 0110) được lặp lại 48 lần (384 bit) cho MD5 và 40 lần (320 bit) cho SHA-1. Ø pad_2: byte 0x5c (0101 1100) được lặp lại 48 lần cho MD5 và 40 lần cho SHA-1. Ø seq_num: sequence number cho message này. Ø SSLCompressed.type: giao thức ở lớp trên được dùng để xử lí phân mảnh này. Ø SSLCompressed.length: chiều dài của phân mảnh đã được nén. Ø SSLCompressed.fragment: phân mảnh đã được nén (nếu nén không được dùng, phân mảnh ở dạng plaintext). Chú ý rằng,cái này tương tự như thuật toán HMAC.Điểm khác biệt là 2 phần đệm (pad) được || trong SSLv3 và được XOR trong HMAC.Thuật toán MAC trong SSLv3 được dựa trên bản phác thảo Internet ban đầu cho HMAC.Phiên bản gần nhất của HMAC được định nghĩa trong RFC 2104,sử dụng XOR. Kế tiếp, message đã nén cộng thêm MAC được mã hóa theo phƣơng pháp mã hóa đối xứng.Mã hóa có thể không làm tăng chiều dài nội dung hơn 1024 byte,vì vậy chiều dài tổng cộng không vượt quá 214+2048. Các thuật toán mã hóa sau được cho phép: Block cipher (Mã hóa khối) Stream cipher (Mã hóa luồng) Thuật toán Kích thước khóa Thuật toán Kích thước khóa AES 128,256 RC4-40 40 IDEA 128 RC4-128 128 RC2-40 40 DES-40 40 DES 56 3DES 168 Fortezza 80 DES (Data Encryption Standard) là một thuật toán mã hoá có chiều dài khoá là 56 bit. 3-DES (Triple-DES): là thuật toán mã hoá có độ dài khoá gấp 3 lần độ dài khoá trong mã hoá DES DSA (Digital Signature Algorithm): là một phần trong chuẩn về xác thực số đang được được chính phủ Mỹ sử dụng. KEA (Key Exchange Algorithm) là một thuật toán trao đổi khoá đang được chính phủ Mỹ sử dụng. MD5 (Message Digest algorithm) được phát thiển bởi Rivest. RSA: là thuật toán mã hoá công khai dùng cho cả quá trình xác thực và mã hoá dữ liệu được Rivest, Shamir, and Adleman phát triển. RSA key exchange: là thuật toán trao đổi khoá dùng trong SSL dựa trên thuật toán RSA. RC2 and RC4: là các thuật toán mã hoá được phát triển bởi Rivest dùng cho RSA Data Security. SHA-1 (Secure Hash Algorithm): là một thuật toán băm đang được chính phủ Mỹ sử dụng. Các thuật toán trao đổi khoá như KEA, RSA key exchange được sử dụng để 2 bên client và server xác lập khoá đối xứng mà họ sẽ sử dụng trong suốt phiên giao dịch SSL. Và thuật toán được sử dụng phổ biến là RSA key exchange.Các phiên bản SSL 2.0 và SSL 3.0 hỗ trợ cho hầu hết các bộ mã hoá. Người quản trị có thể tuỳ chọn bộ mã hoá sẽ dùng cho cả client và server. Khi một client và server trao đổi thông tin trong giai đoạn bắt tay (handshake), họ sẽ xác định bộ mã hoá mạnh nhất có thể và sử dụng chúng trong phiên giao dịch SSL. Fortezza có thể được sử dụng trong mục tiêu mã hóa smart card. Với mã hóa stream (luồng),message đã nén cộng thêm MAC được mã hóa.Chú ý rằng MAC được tính toán trước khi mã hóa xảy ra và MAC được mã hóa cùng với plaintext hoặc là plaintext đã nén. Với mã hóa block (khối),MAC có thể được đệm thêm trước khi mã hóa.Phần đệm thêm (padding) có dạng gồm nhiều byte đệm được theo sau bởi 1 byte chỉ rõ chiều dài của phần đệm.Tổng số lượng đệm vào là lượng nhỏ nhất sao cho tổng kích thước dữ liệu được mã hóa (plaintext +MAC + padding) là 1 bội số của chiều dài khối mã hóa.Ví dụ, plaintext (hoặc text đã nén nếu nén được dùng) là 58 byte, với MAC là 20 byte (dùng SHA-1), được mã hóa với chiều dài block là 8 byte (như DES..).Cùng với byte padding.length ,nó sinh ra tổng cộng 79 byte.Để tạo ra 1 số nguyên là bội của 8,1 byte đệm được thêm vào. Bước cuối cùng của xử lí SSL Record Protocol là gắn thêm vào1 header ,bao gồm các mục sau: Content Type (8 bit): giao thức lớp trên được dùng để xử lí phân mảnh đi kèm. Major Version (8 bit): chỉ ra phiên bản SSL tối đa được dùng. Ví dụ, SSLv3, giá trị này là 3. Minor Version (8 bit) : chỉ ra phiên bản tối thiểu được dùng.Ví dụ, SSLv3 ,giá trị này là 0. Compressed Length (16 bit) : chiều dài theo byte của phân mảnh plaintext (hoặc chiều dài theo byte của phân mảnh đã nén nếu nén được dùng).Gía trị lớn nhất là 214+2048. Các loại nội dung được định nghĩa là change_cipher_spec,alert,handshake, và application_data. Ba cái đầu tiên là các giao thức đặc trưng-SSL,được bàn đến trong phần kế tiếp.Chú ý rằng không có sự khác biệt nào được tạo ra giữa các ứng dụng (như HTTP..) có thể dùng SSL,nội dung dữ liệu được tạo ra bởi các ứng dụng đó thì không trong suốt đối với SSL. Hình sau minh họa định dạng SSL record. I.4 Giao thức SSL Change Cipher Spec : Giao thức SSL Change Cipher Spec là giao thức đơn giản nhất trong ba giao thức đặc trưng của SSL mà sử dụng giao thức SSL Record . Giao thức này bao gồm một message đơn 1 byte giá trị là 1. Mục đích chính của message này là sinh ra trạng thái tiếp theo để gán vào trạng thái hiện tại,và trạng thái hiện tại cập nhật lại bộ mã hóa để sử dụng trên kết nối này. I.5 Giao thức SSL Alert : Giao thức SSL Alert được dùng để truyền cảnh báo liên kết SSL với đầu cuối bên kia.Như với những ứng dụng khác sử dụng SSL, alert messages được nén và mã hóa, được chỉ định bởi trạng thái hiện tại. Mỗi message trong giao thức này gồm 2 bytes .Byte đầu tiên giữ giá trị cảnh báo(1) hoặc nguy hiểm(2) để thông báo độ nghiêm ngặt của message.Nếu mức độ là nguy hiểm,SSL lập tức chấp dứt kết nối.Những kết nối cùng phiên khác vẫn có thể tiếp tục nhưng sẽ không kết nối nào khác trên phiên này được khởi tạo thêm.Byte thứ hai chứa một mã chỉ ra cảnh báo đặc trưng. Đầu tiên , chúng ta liệt kê những cảnh báo đó mà luôn ở mức nguy hiểm ( được định nghĩa từ những thông số SSL): unexpected_message: message không thích hợp. bad_record_mac: MAC không chính xác. decompression_failure: việc giải nén nhận input không thích hợp(ví dụ như không thể giải nén hoặc giải nén lớn hơn độ dài tối đa cho phép). handshake_failure: bên gửi không thể thương lượng một bộ chấp nhận được của các thông số bảo mật được đưa ra từ những lựa chọn có sẵn. illegal_parameter: một trường trong một handshake message thì vượt khỏi dãy hoặc trái với những trường khác Phần còn lại của cảnh báo thì như sau: close_notify: thông báo cho bên nhận rằng bên gửi sẽ không gửi thêm message nào nữa trong kết nối này.Mỗi nhóm thì được yêu cầu gửi một close_notify cảnh báo trước khi kết thúc phần ghi của một kết nối. no_certificate: có thể được gửi để trả lời cho một yêu cầu certificate nếu không certificate thích hợp nào có sẵn. bad_certificate: certificate nhận được thì không hợp lệ(ví dụ như chứa một chữ ký không xác minh). unsupported_certificate: dạng certificate nhận được thì không hỗ trợ. certificate_revoked: certificate đã bị thu hồi bởi nhà cung cấp. certificate_expired: certificate đã hết hạn đăng ký. certificate_unknown: một số phát sinh không nói rõ xuất hiện trong quá trình xử ký certificate làm cho nó không thể chấp nhận. I.6 GIAO THỨC SSL HANDSHAKE Phần „khó hiểu‟ nhất của SSL là giao thức Handshake. Giao thức này cho phép server và client chứng thực với nhau và thương lượng cơ chế mã hóa , thuật toán MAC và khóa mật mã được sử dụng để bảo vệ dữ liệu được gửi trong SSL record.Giao thức SSL Handshake thường được sử dụng trước khi dữ liệu của ứng dụng được truyền đi. Giao thức SSL Handshake bao gồm một loạt những message trao đổi giữa client và server. Mỗi message có ba trường: Type (1 byte): chỉ ra một trong mười dạng message . Length (3 bytes): độ dài của message theo bytes. Content (>=0 bytes): tham số đi kèm với message này, được liệt kê trong Hình I.5a Hình I.5a Các kiểu message giao thức SSL handshake Kiểu message Thông số Hello_request Null Client_hello version, random, session id, cipher suite, compression method Server_hello version, random, session id, cipher suite, compression method Certificate chain of X.509v3 certificates Server_key_exchange parameters, signature Certificate_request type, authorities Server_done Null Certificate_verify signature Client_key_exchange parameters, signature Finished hash value Hình I.5b thể hiện trao đổi lúc ban đầu cần được thiết lập một kết nối logic giữa client và server.Việc trao đổi có thể xem như có 4 giai đoạn. Hình I.5b Cơ chế giao thức SSL Handshake I.6.1 Giai đoạn 1 – Thiết lập khả năng bảo mật : Giai đoạn này được dung để bắt đầu một kết nối logic và thiết lập khả năng bảo mật mà sẽ liên kết với nó.Việc trao đổi thì được khởi tạo bởi client bằng việc gửi một client_hello message với những thông số sau đây: Version: version SSL mới nhất mà client biết. Random: một cấu trúc sinh ra ngẫu nhiên từ client, bao gồm một nhãn thời gian 32 bit và 28 bytes sinh bởi một bộ sinh số ngẫu nhiên an toàn. Những giá trị này phục vụ cho lần này vsử dụng suốt quá trình trao đổikhóa để ngăn tấn công lập lại. Session ID: một ID của phiên có chiều dài thay đổi được.SessionID khác 0 nghĩa là client muốn cập nhật tham số của một kết nối đang tồn tại hay tạo một kết nối mới trên phiên này.SessionID = 0 chỉ ra rằng client muốn thiết lập một kết nối mới trên một phiên mới. CipherSuite: đây là 1 danh sách mà chứa những bộ biên dịch của những thuật toán mã hóa được hỗ trợ bởi client, tham khảo theo thứ tự giảm dần. Mỗi thành phần trong danh sách (mỗi bộ mã hóa) định nghĩa cả một khóa trao đổi và một CipherSpec, những thông số này sẽ được bàn đến sau. Compression Method: đây là danh sách của những phương thức nén mà client hỗ trợ. Sau khi gửi client_hello message, client chờ nhận server_hello message mà chứa cùng thông số với client_hello message.Với server_hello message, những thỏa thuận kèm theo được áp dụng. Trường Version chứa version thấp hơn được đề nghị bởi client và cao nhất được hổ trợ bởi sever.Trường Random được sinh ra bởi server và độc lập với trường Random của client. Nếu trường SessionID của client khác 0, thì giá trị tương tự được dùng bởi server,ngược lại thì trường SessionID của server chứa giá trị của một phiên mới. Trường CipherSuite chứa bộ mã hóa chọn bởi server từ những đề xuất của client. Trường Compression chứa phương thức nén chọn bởi server từ những đề xuất của client. Thành phần đầu tiên của thông số Cipher Suite là phương thức trao đổi khóa (ví dụ như bằng cách nào những khóa mã hóa cho việc mã hóa thông thường và MAC được trao đổi ). Những phương thức trao đổi khóa sau được hỗ trợ: RSA: khóa bí mật được mã hóa với khóa công khai RSA của bên nhận. Một public-key certificate cho khóa bên nhận phải được tạo sẵn. Fixed Diffie-Hellman: đây là sự trao đổi khóa Diffie-Hellman trong certificate của server chứa các thông số công khai Diffie-Hellman được ký bởi Certificate Authority (CA) .Nghĩa là certificate khóa công khai chứa các thông số khóa công khai Diffie-Hellman. Client chứa sẵn các thông số khóa công khai Diffie- Hellman đó trong certificate nếu chứng thực client được yêu cầu hoặc trong một message trao đổi khóa.Phương thức này mang lại kết quả một khóa bí mật cố định giữa hai đầu, dựa trên tính toán Diffie- Hellman sử dụng khóa công khai cố định. Ephemeral Diffie-Hellman: Phương pháp được sử dụng để tạo khóa „ephemeral‟(tạm thời,1 lần)– khóa tạm thời. Trong trường hợp này, khóa công khai Diffie-Hellman được trao đổi,được ký sử dụng khóa bí mật RSA hoặc DSS của bên gửi.Bên nhận có thể sử dụng khóa công khai tương ứng để xác minh chữ ký. Certificate được sử dụng để xác thực khóa công khai. Điều này như là sự bảo đảm nhất của ba lựa chọn Diffie-Hellman bởi vì nó là kết quả của sự tạm thời và khóa xác thực. Anonymous Diffie-Hellman: thuật toán Diffie-Hellman cơ bản được sử dụng, không chứng thực.Nghĩa là mỗi lần một bên gửi thông số Diffie-Hellman công khai của nó cho bên kia thì không xác thực.Điều này gần như là có thể bị tấn công bởi tấn công Man-in-the-middle ,trong đó kẻ tấn công điều khiển cả nhóm anonymous Diffie-Hellman. Fortezza: phương pháp định nghĩa cho lược đồ Fortezza. Định nghĩa kèm theo cho một phương pháp trao đổi khóa là CipherSpec , bao gồm những trường sau : CipherAlgorithm: một vài thuật toán kể đến : RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza. MACAlgorithm: MD5 hoặc SHA-1. CipherType: luồng hoặc khối. IsExportable: True hoặc False. HashSize: 0, 16 (cho MD5), hay 20 (cho SHA-1) bytes. Key Material: thứ tự của các bytes mà chứa dữ liệu được dùng trong sinh khóa . IV Size: kích thước của giá trị khởi tạo cho mã hóa Cipher Block Chaining (CBC). I.6.2 Giai đoạn 2 – Xác thực server và trao đổi khóa : Server bắt đầu giai đoạn này bằng cách gửi certificate của nó nếu nó cần được xác thực; thông điệp chứa một hoặc một chuỗi certificate(chứng thực) X.509. Thông điệp chứng thực được yêu cầu cho bất kì một phương pháp trao đổi khóa nào được thỏa thuận, ngoại trừ anonymous Diffie-Hellman.Chú ý rằng nếu fixed Diffie-Hellman được dùng,thì thông điệp chứng thực có chức năng như là thông điệp trao đổi khóa của server vì nó chứa các tham số Diffie-Hellman công khai của server. Sau đó một thông điệp server_key_exchange được gửi đi nếu nó được yêu cầu.Nó không được yêu cầu trong 2 trường hợp sau: Ø (1) Server đã gửi một certificate với các tham số fixed Diffie-Hellman. Ø (2) Trao đổi khoá RSA được dùng. Thông điệp server_key_exchange cần cho các trường hợp sau: - Anonymous Diffie-Hellman : Nội dung thông điệp bao gồm hai giá trị Diffie-Hellman toàn cục(một số nguyên tố và một số nguyên tố cùng nhau với số đó) cùng với khóa Diffie- Hellman của server. - Ephemeral Diffie-Hellman : nội dung thông điệp bao gồm 3 tham số Diffie-Hellman cung cấp cho anonymous Diffie-Hellman,cùng với một chữ kí của các tham số này. - Trao đổi khóa RSA,mà theo đó server sử dụng RSA nhưng có một khóa chữ kí chỉ của RSA. Theo đó,client không thể gửi đi cách đơn giản một khóa bí mật được mã hóa với khóa công khai/bí mật RSA phụ và sử dụng thông điệp server_key_exchanged để gửi khóa công khai.Nội dung thông điệp bao gồm hai tham số của khóa công khai RSA phụ(số mũ và số dư) cùng với một chữ ký của các tham số này. - Fortezza: một vài chi tiết thêm về chữ kí được đảm bảo. Như thường lệ,một chữ kí được tạora bởi việc lấy mã băm của một thông điệp và mã hóa nó với khóa bí mật của bên gửi. Trong trường hợp này mã băm được định nghĩa: Hash (ClientHello.random||ServerHello.random||ServerParams) Vì vậy mã băm bao gồm không chỉ các thông số Diffie-Hellman hay RSA,mà còn có hai số ngẫu nhiên từ thông điệp hello khởi tạo.Điều này đảm bảo chống lại tấn công replay và misrepresentation(giả dạng).Trong trường hợp chữ kí DSS,mã băm được biểu diễn sử dụng giải thuật SHA-1. Trong trường hợp chữ kí RSA,cả mã băm MD5 và SHA-1 đều được tính toán, và sự nối nhau của hai mã băm(36 byte) được mã hoá với khóa bí mật của server. Kế đến, một nonanonymous server(server không dùng anonymous Diffie-Hellman) có thể yêu cầu một certificate từ client.Một thông điệp certificate_request bao gồm hai thông số certificate_type và certificate_authorities. Kiểu certificate chỉ ra giải thuật khóa công khai,và nó dùng: - RSA,chỉ dùng chữ kí - DSS,chỉ dùng chữ kí - RSA cho Diffie-Hellman thích hợp, trong trường hợp này chữ kí được dùng chỉ để xác thực,bằng cách gửi dùng certificate được kí với RSA. - DSS cho fixed Diffie-Hellman, một lần nữa,chỉ dùng để xác thực. - RSA cho ephemeral Diffie-Hellman. - DSS cho ephemeral Diffie-Hellman. - Fortezza. Thông số thứ 2 của thông điệp certificate_request là một danh sách các tên của những CA đặc biệt được chấp nhận. Thông điệp cuối cùng trong giai đoạn 2, và là một phần luôn được yêu cầu,là thông điệp Server_done,mà được gửi cho server để chỉ ra điểm cuối của thông điệp cuối của server_hello và các message đi kèm.Sau khi gửi thông điệp,server sẽ chờ hồi đáp của client.Thông điệp này không có tham số. I.6.3 Giai đoạn 3 – Xác thực client và trao đổi khóa : Ø Trong khi nhận thông điệp server_done, client sẽ xác nhận xem server cung cấp một chứng chỉ hợp lệ hay chưa nếu được yêu cầu và kiểm tra xem các thông số của server_hello được chấp nhận hay không.Nếu tất cả đều thoả mãn, client gửi một hay nhiều message trở lại cho server. Nếu server yêu cầu một certificate,client bắt đầu giai đoạn này bằng cách gửi 1 thông điệp certificate.Nếu khống có certificate phù hợp nào hợp lệ, client gửi một cảnh báo no_certificate thay thế. Ø Kế đến là thông điệp client_key_exchange phải được gửi đi trong giai đoạn này.Nội dung của thông điệp phụ thuộc vào kiểu trao đổi khóa. Như sau: - RSA: client sinh một trường 48 byte pre-master secret và mã hóa với khóa công khai từ chứng thực của server hoặc khóa RSA phụ từ thông điệp server_key_exchange. Nó dùng để tính toán một master secret(sẽ được nói sau). - Ephemeral hoặc Anonymous Diffie-Hellman: các tham số Diffie-hellman công khai của client được gửi đi. - Fixed Diffie-Hellman: các tham số Diffie-Hellman công khai của client được gửi đi trong một thông điệp certificate,vì vậy nội dung của thông điệp là null. - Fortezza: các tham số Fortezza của client được gửi đi. Ø Cuối cùng,trong giai đoạn này,client sẽ gửi 1 message certificate_verify để cung cấp xác thực tường minh của một chứng chỉ client.Thông điệp này chỉ được gửi theo sau bất kì một client certificate nào đã đánh dấu là có khả năng(nghĩa là tất cả certificate ngoại trừ những cái chứa tham số fixed Diffie-Hellman). Thông điệp này đánh dấu một mã băm dựa trên các thông điệp có trước,được định nghĩa như sau: CertificateVerify.signature.md5_hash MD5(master_secret || pad_2 || D5(handshake_messages || master_secret || pad_1)); Certificate.signature.sha_hash SHA(master_secret || pad_2 || SHA(handshake_messages || master_secret || pad_1)); Ø Với pad_1 và pad_2 là các giá trị được định nghĩa sớm hơn cho MAC, handshake_messages xem xét đến tất cả các thông điệp giao thức bắt tay được gửi đi hay được nhận bắt đầu từ client_hello nhưng không bao gồm thông điệp này,và master_secret là khóa bí mật được tính toán mà quá trình xây dựng sẽ được tìm hiểu sau. Nếu khóa bí mật của user là DSS, thì nó được dùng để mã hóa mã băm SHA-1. Nếu khóa bí mật của user là RSA, nó được dùng để mã hóa chuỗi mã băm MD5 và SHA-1. Ø Trong trường hợp khác, mục đích là để xác minh quyền sở hữu của client với khóa bí mật cho chứng thực client.Cho dù là bất cứ ai đang lạm dụng certificate của client thì cũng sẽ không thể gửi message này. I.6.4 Giai đoạn 4 – Kết thúc: Ø Giai đoạn này hoàn thành thiết lập của một kết nối an toàn,Client gửi một thông điệp change_cipher_spec và chép CipherSpec đệm vào CipherSpec hiện tại.Chú ý rằng thông điệp này không được xem là một phần của giao thức bắt tay nhưng được gửi đi sử dụng giao thức Change Cipher Spec. Client sau đó ngay lập tức gửi thông điệp kết thúc theo giải thuật mới, với các khóa và các bí mật.Thông điệp kết thúc xác minh xem quá trình trao đổi khóa và xác thực có thành công hay không.nội dung của thông điệp hoàn tất là một chuỗi của hai giá trị băm: MD5(master_secret || pad2 || MD5(handshake_messages || Sender || master_secret || pad1)) SHA(master_secret || pad2 || SHA(handshake_messages || Sender || master_secret || pad1)) Ø Tại đó bên gửi là một mã mà xác định rằng bên gửi là client , và handshake_messages là tất cả dữ liệu từ tất cả thông điệp bắt tay trở lên nhưng không bao gồm thông điệp này. Ø Khi đáp lại hai thông điệp này,server gửi thông điệp change_cipher_spec của chính nó, chuyển đổi trạng thái treo cho cipherSpec hiện tại và gửi thông điệp kết thúc của nó đi.Ở điểm này quá trình bắt tay hoàn thành và client và server có thể bắt đầu trao đổi dữ liệu lớp ứng dụng. I.7 TÍNH TOÁN MÃ HÓA Gồm việc tạo ra 1 shared master secret bằng cách trao đổi khóa, và sự sinh ra các tham số mật mã từ master secret. I.7.1 Việc tạo Master Secret : Shared master secret là 1 giá trị one-time 48 byte (384 bits) được sinh ra cho phiên này bằng cách trao đổi khóa an toàn.Việc tạo ra gồm hai bước: -Đầu tiên, một pre-master-secret được trao đổi -Thứ hai, master_secret được tính toán bằng cả ai nhóm. Đối với trao đổi pre_master_secret, có hai khả năng xảy ra: Ø RSA: 48 byte pre_master_secret được sinh ra bởi client, mã hóa với khóa RSA công khai của server, và gửi cho server.Server giải mã ciphertext sử dụng khóa bí mật của nó để phục hồi lại pre_master_secret. Ø Diffie-Hellman: cả client và server sinh ra khóa công khai Diffie-Hellman. Sau đó, những khóa này được trao đổi, mỗi bên biểu diễn việc tính toán Diffie-Hellman để tạo ra shared_pre_master_secret. Cả 2 bên tính toán master_secret như sau: master_secret = MD5 (pre_master_secret || SHA ('A' || pre_master_secret ||ClientHello.random || ServerHello.random)) || MD5 (pre_master_secret || SHA ('BB' || pre_master_secret || ClientHello.random || ServerHello.random)) || MD5 (pre_master_secret || SHA ('CCC' || pre_master_secret || ClientHello.random || ServerHello.random)) Với ClientHello.random và ServerHello.random là 2 giá trị số ngẫu nhiên được trao đổi trong thông điệp hello khởi tạo ban đầu. I.7.2 Việc sinh các tham số mã hóa : CipherSpec yêu cầu một khóa xác thực của client, một khóa xác thực của server, và một khóa mật mã của client, một khóa mật mã của server, một vector khởi tạo IV của client, một vector khởi tạo IV của server, mà được sinh ra từ master_secret theo thứ tự đó.Những tham số này được sinh ra từ master_secret bằng cách băm master_secret thành chuỗi liên tục các byte bảo mật với chiều dài vừa đủ của những tất cả các tham số cần thiết . Việc sinh nguyên liệu khóa từ master_secret sử dụng cùng định dạng cho việc sinh ra master_secret từ pre_master_secret: key_block = MD5(master_secret || SHA('A' || master_secret || ServerHello.random || ClientHello.random)) || MD5(master_secret || SHA('BB' || master_secret || ServerHello.random || ClientHello.random)) || MD5(master_secret || SHA('CCC' || master_secret || ServerHello.random || ClientHello.random)) || . . Cho đến khi đủ số output được phát sinh.Kết quả của cấu trúc giải thuật này là hàm sinh số ngẫu nhiên. Ta có thể xem master_secret như giá trị ngẫu nhiên đưa hạt giống sinh số ngẫu nhiên vào trong hàm sinh số ngẫu nhiên.Các số ngẫu nhiên client và server có thể được nhìn như là các giá trị không đáng tin cậy(salt value) làm phứctạp sự giải mã các mật mã. I.8 TRANSPORT LAYER SECURITY: I.8.1 Version Number : Định dạng của một record TLS giống định dạng của record SSL, và các trường trong phần header cũng có ý nghĩa giống nhau.Một sự khác biệt là trong các giá trị phiên bản TLS hiện tại,bản chính là 3 và bản phụ là 1. I.8.2 Message Authentication Code : Có 2 điểm khác biệt giữa SSLv3 và TLS MAC schemes: giải thuật thực tế và phạm vi của phép tính MAC. TLS tạo ra việc sử dụng giải thuật HMAC được định nghĩa trong RFC 2104.Nhớ lại,HMAC được định nghĩa như sau: HMACK(M) = H[(K+ opad)||H[(K+ ipad)||M]] Với : H: hàm băm nhúng(dành cho TLS, hoặc MD5 hoặc SHA-1) M: thông điệp đầu ra đối với HMAC K+ : khóa bí mật đệm các số 0 vào phía bên trái để kết quả bằng với chiều dài khối mã băm (đối với MD5, và SHA-1, chiều dài khối bằng 512 bits) Ipad =00110110(36H) lặp lại 64 lần (512 bits) Opad =01011100(5CH) lặp lại 64 lần (512 bits) SSLv3 dùng cùng giải thuật, ngoại trừ các byte đệm được nối vào vào khóa bí mật hơn là được XOR với khóa bí mật được đệm vào chiều dài khối.Mức độ an toàn cùng giống trong cả 2 trường hợp. Đối với TLS, phép tính toán MAC hoàn thành các trường hợp được chỉ ra trong đẳng thức sau: HMAC_hash(MAC_write_secret, seq_num || TLSCompressed.type || TLSCompressed.version || TLSCompressed.length || TLSCompressed.fragment) Phép toán MAC bao gồm tất cả các trường được hàm chứa bởi phép tính toán SSLv3, cộng với trường TLSCompresses.version, mà là version của giao thức đang được dùng. I.8.3 Hàm tính số nhẫu nhiên : TLS tạo cách sử dụng hàm tạo số ngẫu nhiên dùng cho PRF để mở rộng các secret(phần bí mật) thành các khối dữ liệu cho