Thủ tục thiết lập kết nố

Một phần của tài liệu LUẬN VĂN:GIAO THỨC BẢO MẬT H.235 SỬ DỤNG TRONG HỆ THỐNG VOIP pdf (Trang 39 - 42)

CHƯƠNG 2 BẢO MẬT H

2.2.3.1.Thủ tục thiết lập kết nố

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

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. (adsbygoogle = window.adsbygoogle || []).push({});

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

Một phần của tài liệu LUẬN VĂN:GIAO THỨC BẢO MẬT H.235 SỬ DỤNG TRONG HỆ THỐNG VOIP pdf (Trang 39 - 42)