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