CHƯƠNG 2 BẢO MẬT H
2.2.3.4.Thủ tục mã hóa luồng dữ liệu kênh truyền thông
Luồng dữ liệu truyền thông sẽ được mã hóa bởi thuật toán và khóa được đưa ra trên kênh H.245. Chú ý rằng các header chỉ được gắn vào các SDU (Service Data Unit) sau khi các SDU này đã được mã hóa.
Hình 2.10 Mã hóa luồng dữ liệu
Hình 2.11 Giải mã luồng dữ liệu
Khóa của phiên truyền thông :
Bất cứ lúc nào trong hội nghị, bên nhận hoặc bên truyền có thể yêu cầu 1 khóa mới (sử dụng encrytionUpdateRequest). Chủ cuộc gọi (master) sẽ sinh ra
1 khóa mới đáp ứng cho yêu cầu này. Tuy nhiên, chủ cuộc gọi hoàn toàn có thể đơn phương lựa chọn khóa mới và phân phối nó đến các đầu cuối khác sử dụng bản tin MiscellaneousCommand với trường encryptionUpdate.
Sau khi nhận bản tin MiscellaneousCommand với trường
encryptionUpdateRequest, master sẽ gửi đi bản tin encrytionUpdate. Nếu đây là hội nghị đa điểm, MC (cũng là chủ cuộc gọi) sẽ phân phối khóa mới đến tất cả các
đầu cuối trước khi đưa nó đến người phát tín hiệu (transmitter). Người phát tín hiệu của dữ liệu trên kênh truyền thông sẽ sử dụng khóa mới vào thời điểm sớm nhất có thể sau khi nhận được bản tin.
Transmitter cũng có thể yêu cầu khóa mới. Nếu Transmitter là 1 phần của hội nghị đa điểm, các thủ tục sẽ diễn ra như sau :
o Transmitter sẽ gửi bản tin MiscellaneousCommand với trường
encryptionUpdateRequest đến MC (master).
o MC sẽ sinh ra khóa mới và gửi nó thông qua trường
encrytionUpdate đến tất cả các thành viên trong hội nghị ngoại trừ
transmitter.
o Sau khi gửi khóa mới cho tất cả các thành viên khác, MC sẽ gửi
encryptionUpdate đến cho transmitter. Transmitter sau đó sẽ bắt đầu sử dụng khóa mới.
Hình 2.12 Cập nhật khóa
Các kĩ thuật cần thiết khi sử dụng RTP :
Khi sử dụng các thuật toán mã hóa khối đễ mã hóa dữ liệu truyền, có 2 vấn đề cần quan tâm ( trong tài liệu này chỉ đề cập đến mã hóa khối kiểu CBC ).
Hình 2.13 Mã hóa CBC
Hình 2.14 Giải mã CBC
Initialization vector :
Initialization vector (IV) được yêu cầu khi sử dụng chế độ mã hóa khối CBC đễ mã hóa thông tin trong RTP. Kích thước của IV bằng kích thước của 1 khối dữ liệu được đưa vào mã hóa ứng với mỗi thuật toán. Cụ thể, kích thước IV đối với DES và 3- DES là 64-bit trong khi đối với AES là 128-bit.
Một IV sẽ được tạo thành bởi B byte (B là độ dài khối ) với cấu trúc : Sequence kết hợp với timestamp. Nó sẽ được biểu diễn như sau : SSTTTT, với SS là 2 byte chứa Sequence còn TTTT là 4 byte chứa timestamp và cứ tiếp tục cho đến khi đủ B bytes. Ví dụ, đối với 64 và 128-bit IV sẽ tương ứng với SSTTTTSS và SSTTTTSSTTTTSSTT.
Padding :
Khi mà dữ liệu sẽ được đưa vào gói RTP không đủ độ dài khối (multiple of block) để đưa vào mã hóa thì một số lượng byte nhất định sẽ được thêm vào cho phù hợp. Giá trị của byte cuối cùng sẽ chỉ ra số lượng byte được thêm vào (gồm cả chính nó) và bit P trong phần đầu của RTP sẽ được thiết lập. Giá trị của byte thêm vào được quyết định bởi thuật toán mã hóa (Đối với AES là 0).
Ngoài ra, khi nhận được gói RTP mà phần thông tin đã được mã hóa, bit P trong phần đầu RTP không được thiết lập nhưng dữ liệu trong RTP không đủ độ dài khối (multiple of block), khi đó chế độ Ciphertext Stealing đã được áp dụng.
Hình 2.15 Kĩ thuật Ciphertext Stealing
Chống Spam trên kênh truyền thông :
Người nhận dữ liệu RTP trên kênh truyền thông luôn muốn chống lại các kiểu tấn công từ chối dịch vụ (DoS) hay tấn công flooding trên các cổng RTP/UDP. Đối với người nhận có khả năng anti-spam có thể nhanh chóng quyết định nhận ra gói RTP từ 1 nguồn gửi trái phép và loại bỏ nó. (adsbygoogle = window.adsbygoogle || []).push({});
Khả năng anti-spamming khi được thiết lập sẽ được sử dụng cho trường hợp :
o Cho luồng dữ liệu thông thường không được mã hóa. o Kết hợp với luồng truyền thông đã được mã hóa .
Cả 2 tùy chọn này cung cấp xác thực gói RTP thông qua mã thông điệp xác thực (MAC- Message authentication code). MAC được tính toán dựa trên việc sử dụng thuật toán mã hóa (DES -MAC) hay hàm mã hóa 1 chiều (SHA).
Thuật toán tính MAC được chỉ ra trong trường OID của antiSpamAlgorithm, nó
Hình 2.16 Định dạng gói RTP dành cho anti spamming.
Bit P trong RTP header sẽ được gán là 1. Những byte được gán thêm sẽ được nối vào phần cuối của của phần payload như định dạng trong hình trên.
Trường hợp chỉ sử dụng anti – spamming :
Trường hợp này được áp dụng khi dữ liệu truyền thông không được mã hóa và trường gán thêm dữ liệu (padding) bị bỏ trống. Byte cuối cùng của RTP padding sẽ chỉ ra bao nhiêu byte sẽ được bỏ qua trong gói RTP. Còn những padding khác sẽ chỉ ra MAC. MAC được tính toán dựa trên khối đầu tiên của RTP header bao gồm nhãn thời gian và số thứ tự sử dụng thuật toán MAC(được chỉ ra trong antiSpamAlgorithm) với khóa là khóa chung(share secret) đã được trao đổi trước đó.
Đối với việc tính toán MAC, nên sử dụng khóa phiên H.235 mặc dù nó không được sử dụng cho việc mã hóa payload. Người gửi tính toán MAC theo mô tả ở phần trên và đưa kết quả vào trong phần RTP padding AUTH. Cả bên gửi và nhận đều biết được kích thước của MAC thông qua antiSpamAlgorithm.
Đối với việc kiểm tra MAC bên phía nhận, đầu tiên người nhận tính toán lại MAC đúng theo cách mà bên gửi đã làm sau đó so sánh giá trị tính được với giá trị MAC trong RTP padding. Nếu hai giá trị này không giống nhau, RTP header đã bị thay đổi trong quá trình truyền hoặc được gửi bởi 1 đầu cuối không được xác nhận và không sở hữu khóa. Vì vậy gói RTP này sẽ bị loại bỏ và sự việc này sẽ được lưu lại; nó chỉ ra khả năng bị tấn công từ chối dịch vụ (DoS). Nếu không thì gói RTP này được xác thực và tiếp tục được xử lý, RTP padding được loại bỏ và payload được đưa vào codec.
Trường hợp dữ liệu được mã hóa :
Trường hợp này được áp dụng khi dữ liệu truyền thông được mã hóa và phương pháp chống spam được sử dụng. Nếu độ dài của payload không khớp với độ dài block (dành cho mã hóa ), 1 vài byte sẽ được thêm vào sau phần payload và trước phần
MAC.
EncrytionAlgorithm xác định thuật toán mã hóa payload trong khi
hóa truyền thông và MAC sẽ sử dụng những khóa khác nhau. Khóa dành cho MAC được tính toán dựa trên thông qua hàm mã hóa 1 chiều SHA.
Sau khi bên nhận thành công trong việc xác nhận gói RTP, payload sẽ được giải mã và padding sẽ được bỏ đi.
Bảng 2.1 OID anti-spamming
Phục hồi lỗi bảo mật :
Nếu đầu cuối phát hiện lỗ hổng bảo mật của kênh báo hiệu cuộc gọi (H.225.0 ), kênh điều khiển cuộc gọi (H.245) hay kênh truyền thông, nó nên đóng kết nối ngay lập tức theo những thủ tục thích hợp.
Nếu 1 đầu cuối phát hiện lỗ hổng bảo mật của 1 trong số các kênh logic, ngay lập tức nó sẽ yêu cầu 1 khóa mới (encrytionUpdateRequest) hoặc đóng kênh logic đó lại. Đối với MC(U) nó sẽ đóng kênh logic này lại và tạo khóa mới.