Tìm hiểu chung về SSL và TLS Phần 5

ssl1

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.

ssl51

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ã.

ssl52

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 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.

ssl53

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 mục đích sinh khóa hay phê chuẩn.Đối tượng là để tạo ra cách sử dụng các giá trị shared secret nhỏ có lien hệ với nhau, nhưng để phát sinh các khối dài hơn theo cách an toàn khỏi sự tấn công dựa trên hàm băm và MACx.PRF dựa trên hàm mở rộng dữ liệu sau:

P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) || MAC_hash(secret, A(2) || seed) || HMAC_hash(secret, A(3) || seed) || …

Với A() được định nghĩa:

A(0)=seed

A(i) =HMAC_hash(secret,A(i-1))

ssl53

Hàm mở rộng dữ liệu tạo cách sử dụng giải thuật HMAC, với hoặc MD5 hoặc SHA-1 như là trên cơ sở hàm băm.Như ta có thể thấy,P_hash có thể lặp đi lặp lại nhiều lần như sự cần thiết để tạo ra số lượng dữ liệu được yêu cầu.Ví dụ, nếu P_SHA-1 được dùng để sinh ra 64 byte dữ liệu,nó sẽ được lặp đi lặp lại 4 lần tạo ra 80 byte dữ liệu,mà 16 byte cuối bị loại bỏ.Trong trường hợp này,P_MD5 cũng sẽ được lặp lại 4 lần,tạo ra chính xác 64 bytes dữ liệu.Chú ý rằng mỗi lần lặp lại sẽ gọi 2 hàm thực thi HMAC, mỗi một cái sẽ quay sang gọi 2 hàm thực thi trên cơ sở giải thuật hàm băm.

Để tạo ra PRF an toàn đến mức có thể,nó sử dụng 2 giải thuật băm theo cách mà sẽ đảm bảo sự an toàn của nó nếu giải thuật vẫn còn bảo mật.PRF được định nghĩa :

hash(ClientHello.random || ServerHello.random || ServerParams)

PRF lấy khi đầu vào một giá trị bí mật, một nhãn xác định, và một giá trị hạt giống(seed) và tạo ra một output có chiều dài tùy ý.Output được tạo bằng cách phân cắt giá trị bí mật thành hai nửa (S1 và S2 và biểu diễn P_hash ở mỗi nửa,sử dụng MD5 ở một nửa và SHA-1 ở nửa khác.Hai kết quả được thực hiện bởi phép XOR để tạo ra output, cho mục đích này,P_MD5 nhìn chung phải lặp lại nhiều lần hơn P_SHA-1 để tạo một lượng dữ liệu ngang bằng cho input bằng hàm XOR)

I.8.4 Mã cảnh báo

TLS hỗ trợ tất cả các mã alert code được định nghĩa trong SSLv3 với ngoại lệ no_certificate. Một số các code thêm vào được định nghĩa trong TLS, sau đây là một số cảnh báo mức nguy hiểm:

  • decryption_failed : một cipher text được giải mã theo cách sai, hoặc nó không phải là phép nhân của chiều dài khối hoặc giá trị đệm của nó,khi kiểm tra là không đúng.
  • record_overflow:một TLS record được nhận với một payload(ciphertext) có chiều dài 214+2048 bytes, hoặc ciphertext được giải mã với chiều dài lớn hơn 214+1024 byte.
  • unknown_ca : một chuỗi certificate hợp lệ hoặc 1 phần chuỗi được nhận,nhưng certificate không được chấp nhận bởi vì CA certificate không thể được cấp phát hoặc không thể tạo ra kết nối với 1 CA hiểu biết,tin cậy.
  • access_defined: một certificate hợp lệ được nhận, vì khi access_control được thừa nhận, sender quyết định không thực thi với thỏa thuận.
  • decord_error : một thông điệp không thể được giải mã vì 1 trường bị thiếu range đặc biệt hoặc chiều dài của message không đúng.
  •  export_restriction : một thỏa thuận không được chấp nhận với việc xuất ra các hạn chế trên chiều dài khóa bị phát hiện.
  • protocol_version: phiên bản giao thức mà client nỗ lực thỏa thuận được nhận thấy nhưng không hỗ trợ.
  • insufficient_security: trả về thay thế handshake_failure khi thỏa thuận bị thất bại 1 cách đặc biệt bởi vì server yêu cầu cipher nhiều bảo mật hơn những cái khác được hỗ trợ bởi client.
  • internal_error: một lỗi bên trong không liên hệ với cấp tương đương hoặc sự sửa lỗi của giao thức tạo ra không thể để tiếp tục.

Phần còn lại của các cảnh báo mới bao gồm:

  • decrypt_error: toán hạng mã hóa bắt tay bị hư, bao gồm không thể xác minh 1 chữ kí,mã hóa 1 trao đổi khóa hay công nhận 1 thông điệp hoàn tất.
  • user_canceled: quá trình bắt tay này bị hoãn lại vì 1 số lí do không liên quan đến sự thất bại giao thức.
  • no_renegotiation: gửi đi bởi client trong phần đáp lại client hello sau khi thiết lập bắt tay.hoặc những thông điệp này sẽ có kết quả bình thường trong việc thỏa thuận lại,nhưng cảnh báo này chỉ ra rằng sender không thể thỏa thuận.Thông điệp này luôn luôn là 1 cảnh báo(warning).

I.8.5 Cipher suite

Có nhiều sự khác nhau nhỏ giữa các cipher suite sẵn có dưới SSLv3 và dưới TLS:

  • Trao đổi khóa:TLS hỗ trợ tất cả các công nghệ trao đổi khóa của SSLv3 với ngoại lệ của Fortezza.
  • Các giải thuật mã hóa đối xứng:TLS bao gồm tất cả các giải thuật mã hóa đối xứng được tìm thấy trong SSLv3,với ngoại lệ của Fortezza.

I.8.6 Các dạng client certificate

TLS định nghĩa cá kiểu certificate sau đây được yêu cầu trong thông điệp certificate_request:rsa_sign,dss_sign,rsa_fixed_dh, và dss_fixed_dh. Tất cả những kiểu này được định nghĩa trong SSLv3. Thêm vào đó,SSLv3 bao gồm rsa_ephemeral_dh, dss_ephemeral_dh và fortezza_kea.

Ephemeral Diffie-Hellman bao gồm đánh dấu các tham số Difie-Hellman với hoặc RSA hoặc DSS, với TLS, rsa_sign và kiểu đánh dấu riêng không cần thiết để đánh dấu các tham số Diffie-Hellman.TLS không bao gồm hệ thống Fortezza.

I.8.7 Certificate Verify và Finished Message

Trong thông điệp TLS_certificate_verify, mã băm MD5 và SHA-1 được tính toán chỉ trên các thông điệp bắt tay(handshake_message).Nhớ lại rằng SSLv3 tính toán hàm băm còn bao gồm master_secret và đệm.Các trường thêm vô này thất bại trong việc cộng thêm bảo mật không được thêm vào.

Khi các thông điệp hoàn tất trong SSLv3, thông điệp kết thúc trong TLS là 1 mã băm dựa trên

shared_master_secret, thông điệp bắt tay ở trước, và một nhãn xác định client hay server, việc tính toán có đôi chút khác biệt. Đối với TLS ta có:

  • PRF(master_secret, finished_label, MD5(handshake_messages)|| SHA-1(handshake_messages))
  • Với finished_label là chuỗi “client_finished” đối với client và “server finished” đối với server.

I.8.8 Tính toán mã hóa

Pre_master_secret đối với TLS được tính toán cùng 1 cách như trong SSLv3.Như trong SSLv3, master_secret trong TLS được tính toán như 1 hàm băm của pre_master_secret và hai số ngẫu nhiên hello.Công thức của phép tính toán TLS khác với công thức tính của SSLv3,được định nghĩa như sau:

master_secret = PRF(pre_master_secret, “master secret”, ClientHello.random || ServerHello.random)

Giải thuật biểu diễn cho đến khi 48 byte của output số ngẫu nhiên được tạo ra.Phép tính toán của khối vật liệu key(MAC secret keys,khóa mã hóa phiên, và ma trận khởi tạo IVs) được định nghĩa như sau:

key_block=PRF(master_secret,”keyexpansion”,SecurityParameters.server_random || SecurityParameters.client_random)

Cho đến khi đủ output được sinh ra.Như với SSLv3,key_block là 1 hàm của master_secret và client và server random numbers, nhưng với TLS giải thuật thực tế là khác biệt.

I.8.9 Phần đệm

Trong SSL, phần đệm thêm vào trước để mã hóa dữ liệu user là số lượng nhỏ nhất được yêu cầu để mà kích thước tổng của dữ liệu được mã hóa là một phép nhân của chiều dài khối của cipher.Trong TLS, padding có thể là bất kìsố lượng nào mà có kết quả trong một tổng mà là một phép nhân của chiều dài khối của cipher lên đến 1 giá trị lớn nhất là 255 byte.Ví dụ, nếu 1 plaintext (hoặc văn bản nén được dùng) cộng với MAC+padding length byte là dài 79 byte.Sau đó chiều dài padding,tính theo byte, có thể là 1,9,17 và hơn nữa,đến 249. Chiều dài phần đệm tùy biến có thể chống lại các tấn công dựa trên một phép phân tích các chiều dài của các thông điệp trao đổi.

SSL 2.0 hoạt động như sau:

  1. Kết nối từ client đến server được thực hiện bằng giao thức HTTPS (HTTP+SSL)
  2. Server kí khóa công khai (public key) bằng khóa bí mật (private key) của mình và gửi cho client
  3. Client dùng khóa công khai của server để xác nhận đúng server đang liên lạc
  4. Client kiểm tra xem có CA nào đã kí vào khóa. Nếu không client sẽ hỏi người dùng xem có nên tin tưởng vào server không
  5. Client sinh ra một khóa bất đối xứng (asymmetric key) cho phiên giao dịch, khóa này được mã hóa bằng khóa công khai của máy chủ và gửi ngược lại. Khoá này cũng sẽ được dùng để mã hóa tất cả các thông tin sau này.

SSL 3.0 bổ sung thêm cho SSL 2.0 bằng cách hỗ trợ cho chứng thực máy khách (client certificate), giúp server có thể nhận diện ngược lại client. SSL 3.0 hoạt động như SSL 2.0 , nhưng sau khi client đã xác thực server, đến lượt server sẽ kiểm tra ngược lại client.

Hết……….

Comments

comments