Khuyến nghị này mô tả bảo mật truyền thông cho luồng dữ liệu đa phương tiện truyền trên mạng chuyển mạnh gói.
Bước đầu tiên trong việc đạt được bảo mật truyền thông là sự cung cấp có đảm bảo của 1 kênh điều khiển, dựa trên đó để đặt 1 khóa mã hóa và thiết lập những kênh logic sẽ mang những luồng dữ liệu truyền thông đã được mã hóa. Vì vậy, khi hoạt động trong 1 hội nghị có đảm bảo, các đầu cuối tham gia có thể sử dụng 1 kênh H.245 đã được mã hóa. Theo cách đó, thuật toán mã hóa được lựa chọn và khóa mã hóa đưa vào trong bản tin H.245 OpenLogicalChannel được bảo vệ.
Dữ liệu đã được mã hóa được truyền trong các kênh logic phải nằm trong kiểu được đặc tả bởi OpenLogicalChannel. Thông tin trong phần header gửi đi không được mã hóa. Sự bảo mật của dữ liệu dựa trên cơ sở mã hóa end-to-end.
2.2.2.5. Trusted elements ( Thành phần tin tƣởng )
Cơ sở của việc xác thực và bảo mật được định nghĩa bởi các đầu cuối của kênh liên lạc. Đối với 1 kênh thiết lập cuộc gọi, đó có thể là giữa người gọi và một thành phần máy chủ. Ví dụ, một máy điện thoại tin tưởng rằng chuyển mạng sẽ kết nối nó tới đúng chiếc điện thoại có số mà nó đã gọi. Vì vậy, thực thể nào giới hạn kênh điều khiển mã hóa H.245 và hay kiểu mã hóa dữ liệu của kênh logic sẽ được coi như là trusted element của kết nối, nó có thể gồm các MC(U) hay gateway. Kết quả của việc tin tưởng 1 thành phần là sự tin cậy để chia sẻ các kĩ thuật bảo mật (thuật toán hay khóa) cho thành phần này. Điều đó được thực hiện theo cách thông thường là trao đổi chứng nhận điện tử.
Sự đảm bảo cuộc gọi giữa 2 điểm đầu cuối là chắc chắn nếu những kết nối giữa các trusted element được chứng minh là bảo vệ khỏi tấn công man-in-the- midle.
2.2.3 Các thủ tục bảo mật trong cuộc gọi sử dụng H.235
Hình 2.7 Thủ tục H.235
2.2.3.1. Thủ tục thiết lập kết nối
Kênh báo hiệu cuộc gọi H.225 và kênh điều khiển cuộc gọi H.245 sẽ hoạt động trong chế độ bảo mật hoặc không bảo mật. Đối với kênh báo hiệu, cổng bảo mật TLS (port 1300 ) sẽ được sử dụng. Đối với kênh điều khiển cuộc gọi, chế độ bảo mật được quyết định bởi thông tin được truyền tải trong giao thức khởi tạo kết nối.
Trong trường hợp không có khả năng bảo mật nào thích hợp, đầu cuối bị gọi có thể từ chối kết nối. Thông tin phản hồi không mang thông tin về sự không trùng khớp chế độ bảo mật, vì vậy đầu cuối gọi phải xử lý vấn đề theo nhiều cách khác nhau.
Trong nhiều trường hợp, đầu cuối gọi nhận được bản tin không kèm theo khả năng bảo mật, nó sẽ kết thúc cuộc gọi.
Nếu đầu cuối gọi và bị gọi có cùng khả năng bảo mật thích hợp, nó sẽ được thừa nhận bởi tất cả các bên rằng kênh H.245 sẽ hoạt động trong chế độ bảo mật. Thất bại trong việc thiết lập kênh H.245 trong chế độ bảo mật nên được xem như
là 1 lỗi giao thức và cuộc gọi được kết thúc.
Diffie – Hellman :
Phụ thuộc vào từng hoàn cảnh mà khóa sinh ra bởi trao đổi Diffie-Hellman có thể đóng vai trò như khóa bảo vệ(mã hóa khóa phiên) hay dùng như khóa phiên.
Diffie-Hellman được mô tả bởi các tham số g và p với : p là 1 số nguyên lớn còn g là 1 số khởi tạo. (g^x)mod p chỉ ra khóa công khai Diffie-Hellman của bên gọi và (g^y)mod p chỉ ra khóa công khai Diffie-Hellman của bên bị gọi. Cách lựa chọn tham số cho Diffie-Hellman được chỉ dẫn trong RFC 2412.
Thông số Diffie-Hellman (g, p, g^x) được đưa vào trong trường
ClearToken (trong các bản tin H.225) trong đó dhkey sẽ nắm giữ khóa công khai (g^x)mod p ( trong bản tin trả lời là g^ymodp), với x(y) là số bí mật (khóa bí mật), p nằm trong trường modesize và g trong trường generator. Với những trường hợp đặc biệt như thông số Diffie-Hellman là (0, 0, 0) hay trường dhkey
được bỏ trống báo hiệu rằng chế độ mã hóa không được sử dụng.
Thông thường, các tham số g và p đã được quy định sẵn với những giá trị hợp lý, do đó các đầu cuối có thể chọn tham số phù hợp với nó. Người được gọi cần chú ý rằng, thực tế các tham số DH không không chuẩn có thể cung cấp sự bảo mật kém hơn so với các tham số được định nghĩa theo chuẩn.
Khi thông số DH được sử dụng theo chuẩn, giá trị nhận biết DH-OID sẽ được đưa vào trường tokenOID. Trong trường hợp thông số DH không theo chuẩn được sử dụng, DH-OID ―DH-dummy‖ sẽ được sủ dụng và đưa vào
ClearToken.
Bên gọi có thể sử dụng 1 hay nhiều ClearToken, trong đó sẽ mang những thông số DH khác nhau và điều đó được khuyến khích. Vì việc cung cấp nhiều thông số DH sẽ cho phép bên bị gọi lựa chọn được thông số phù hợp, sau đó bên gọi sẽ gửi lại thông số này cho bên gọi.
Hình 2.8 Thành phần ClearToken.
Nếu bên bị gọi không chấp nhận những đề xuất đó, nó sẽ không đưa trường
dhkey vào trong bản tin trả lời.
Đôi khi Gatekeeper có thể không phân phối được toàn bộ các bản tin báo hiệu đến bên gọi, bao gồm cả thông tin DH. Vì vậy bên gọi không thể tính được khóa bảo vệ và khóa mã hóa. Để tránh trường hợp này, bên được gọi nên đưa thông số DH vào tất cả các bản tin trả lời.
Trong trường hợp DH-OID chỉ ra 1 thông số DH khác với thực tế được mang trong dhkey và modsize, giá trị thực tế trong dhkey và modsize sẽ được ưu tiên so với DH-OID. Đối với việc trả lời, bên được gọi nên thay thế DH-OID mâu thuẫn với DH-OID phù hợp.
Lỗi trong quá trình báo hiệu:
Lỗi trong quá trình báo hiệu chỉ ra rằng đầu cuối không thể xử lý bản tin nhận được 1 cách phù hợp. Và khi xảy ra trường hợp đó, những mã lỗi sau sẽ cung cấp chi tiết thông tin :
securityWrongSyncTime : chỉ ra rằng bên gửi nhận thấy có lỗi trong tem thời gian (timestamp), có thể là do sự không đồng bộ từ phía máy
chủ hay trễ qua mạng.
securityReplay : chỉ ra khả năng bị tấn công kiểu ―replay‖( bị chặn gói tin ở giữa và sửa đổi ). Trường hợp này thường xảy ra khi cùng 1 số thứ tự gói ( sequence number) gán với 1 timestamp trong nhiều lần.
securityWrongGeneralID : Gán sai địa chỉ nhận trong token.
securityWrongSendersID : Gán sai địa chỉ của chính bên gửi trong
token.
securityIntegrityFailed : Có lỗi trong quá trình kiểm tra tính toàn vẹn hay chữ ký điện tử của bản tin.
securityCertificateExpired : Chứng chỉ điện tử đã hết hạn.
securityCertificateDateInvalid : Chứng chỉ điện tử không hợp lệ.
securityCertificateNotReadable : Chứng chỉ điện tử không ở dạng ASN.1.
securityCertificateSignatureInvalid : Chữ ký điện tử trong chứng chỉ điện tử không chính xác.
securityCertificateMissing : Bên nhận chờ chứng chỉ số từ bên gửi, nhưng trong bản tin nhận được thiếu hoặc nó không được đặt đúng vị trí.
securityCertificateIncomplete : Không có sự hiện diện của 1 số thành phần mở rộng trong chứng chỉ số.
securityUnsupportedCertificateAlgOID : Một vài kĩ thuật như hàm băm hay chữ kí điện tử sử dụng trong chứng chỉ điện tử không được nhận biết hay không được hỗ trợ. Như là 1 phần của bản tin trả lời, bên gửi có thể cung cấp danh sách các chứng chỉ điện tử có thể được chấp nhận trong 1 token riêng, thuận tiện cho bên nhận trong việc lựa chọn chứng chỉ thích hợp.
securityUnknownCA : Không trùng khớp về cơ quan cấp chứng chỉ điện tử.
2.2.3.2. Thủ tục và báo hiệu H.245
Nhìn chung, khía cạnh bảo mật của kênh truyền thông cũng được điều khiển giống như những thành phần khác; mỗi đầu cuối chỉ ra khả năng của nó, định dạng dữ liệu và bên nhận có thể chấp nhận hay từ chối chế độ đó. Các đặc tả truyền vận như khóa thuật toán mã hóa đồng bộ được đặt trong các cấu trúc đặc tả truyền vận.
Hoạt động của kênh bảo mật H.245:
Việc áp dụng thủ tục báo hiệu như đã đề cập ở trên giúp chỉ ra chế độ hoạt động bảo mật, sự dàn xếp và xác thực sẽ xảy ra trên kênh điều khiển H.245 trước khi bất cứ bản tin H.245 nào được trao đổi. Nếu đã dàn xếp, việc trao đổi chứng nhận điện tử sẽ sử dụng những kĩ thuật thích hợp với đầu cuối H-series. Sau khi
hoàn thành việc bảo mật cho kênh H.245, các đầu cuối sử dụng giao thức H.245 giống như cách mà nó sử dụng ở chế độ không bảo mật.
Trao đổi khả năng :
Các đầu cuối trao đổi khả năng thông qua các bản tin H.245. Nó bao gồm các định nghĩa về chỉ định bảo mật và tham số cho việc mã hóa dữ liệu. Ví dụ, 1 đầu cuối có thể cung cấp khả năng truyền và nhận video H.261 và nó cũng báo hiệu khả năng gửi và nhận video H.261 đã được mã hóa.
Mỗi thuật toán mã hóa được sử dụng kết hợp với một media codec (bộ nén media) cụ thể để đưa ra định nghĩa mới về khả năng (capability). Với những capability khác, các đầu cuối có thể cung cấp khả năng mã hóa hay không cho bộ nén trong quá trình trao đổi. Điều đó cho phép những đầu cuối cân bằng các khả năng của nó dựa trên các hoạt động và tài nguyên sẵn có.
Sau khi trao đổi khả năng hoàn tất, các đầu cuối mở các kênh media bảo mật giống như với kênh media không bảo mật.
Vai trò của master :
Bản tin H.245 MasterSlaveDetermination được sử dụng để xác định điểm cuối làm chủ cuộc gọi, áp dụng cho kênh thoại 2 chiều và tránh bị xung đột. Về phương pháp bảo mật thì master có nhiệm vụ sinh ra khóa mã hóa, cho dù nó có là người nhận hay nguồn của luồng dữ liệu. Để cho phép kênh multicast hoạt động với khóa chia sẻ, MC (là master) sẽ sinh khóa.
Báo hiệu kênh truyền thông :
Mỗi kênh truyền thông hoạt động hoàn toàn độc lập với những kênh khác (cụ thể là liên quan đến vấn đề bảo mật). Thông thường, các chế độ sẽ được xác định trong trường dataType của bản tin OpenLogicalChannel. Khóa mã hóa sẽ được truyền đi thông qua trường EcryptionSync trong bản tin OpenLogicalChannel
hay OpenLogicalChannelAck phụ thuộc vào mối quan hệ chủ/ tớ.
OpenLogicalChannelAck đóng vai trò xác nhận chế độ mã hóa. Nếu
OpenLogicalChannel không được chấp nhận bởi bên bị gọi, trường
dataTypeNotSupport hay dataTypeNotAvailable trong bản tin
OpenLogicalChannelReject sẽ được gửi lại.
Trong suốt quá trình trao đổi thiết lập kênh media, khóa mã hóa sẽ được chuyển từ master đến slave (không phụ thuộc vào người gửi bản tin
OpenLogicalChannel). Đối với trường hợp đầu cuối mở kênh truyền thông không phải là master, master sẽ gửi khóa mã hóa trong bản tin OpenLogicalChannelAck
(trường EcryptionSync ). Ngược lại thì OpenLogicalChannel sẽ mang theo khóa mã.
Hình 2.9 Trường EncytionSync
2.2.3.3. Thủ tục kết nối đa điểm Xác thực: Xác thực:
Việc xác thực xảy ra giữa 1 đầu cuối và MC(U) giống với khi nó xảy ra trong hội nghị điểm-điểm. Ban đầu MC(U) sẽ được tin tưởng (trusted) ; những đầu cuối có mặt trong hội nghị có thể được giới hạn bởi mức độ xác thực được tận dụng bởi MC(U). Việc gửi các bản tin ConferenceRequest/ConferenceResponse
cho phép các đầu cuối thu được các chứng nhận điện tử của các bên tham gia từ MC(U).
Bảo mật:
MC(U) sẽ là master đối với tất cả những lần trao đổi khả năng, và nó sẽ cung cấp khóa mã hóa cho các bên tham gia của hội nghị đa điểm. Khóa này có thể được sử dụng đối với tất cả các kênh truyền thông hay từng kênh riêng biệt.
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ó.
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ó cũng chỉ ra kích thước của MAC. VD : 1 khối = 64bit đối với DES MAC.
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