Luận văn Giao thức bảo mật h.235 sử dụng trong hệ thống VOIP

khối dữ liệu 4×4 byte. Hình 1.14 mô tả quá trình mã hóa và giải mã của thuật toán AES. 20 Hình 1.14 Quá trình mã hóa và giải mã AES Quá trình mã hóa AES trải qua bốn bước cơ bản, số vòng lặp của thuật toán có thể là 10, 12,14 ( phụ thuộc vào chiều dài của khóa). 21 Bảng 1.2 Các tham số của AES 1. SubBytes — đây là phép thế (phi tuyến) trong đó mỗi byte sẽ được thế bằng một byte khác theo bảng tra (Rijndael S-box). Hình 1.15 SubBytes Trong bước SubBytes, mỗi byte được thay thế bằng một byte theo bảng tra S; bij = S(aij). 22 Bảng 1.3 S-Box Một ví dụ về Subbytes EA 04 65 85 83 45 5D 96 5C 33 98 B0 E0 3D AD C5 87 F2 4D 97 EC 6E 4C 90 4A C3 46 C7 8C D8 95 A6 2. ShiftRows — đổi chỗ, các hàng trong khối được dịch vòng. Mỗi hàng được chuyển tuần tự với một số lượng bước là cố định. Đặc biệt, các phần tử của hàng đầu tiên sẽ không thay đổi vị trí, hàng thứ hai dịch sang trái một cột, hàng thứ ba dịch sang trái hai cột, hàng cuối cùng sẽ dịch sang trái ba cột. Thao tác này nhằm đảm bảo mỗi cột của bảng đầu ra đều được tạo thành từ các cột của bảng trạng thái đầu vào. Hình 1.16 ShiftRows. 23 Một ví dụ về ShiftRows: 87 F2 4D 97 EC 6E 4C 90 4A C3 46 C7 8C D8 95 A6 87 F2 4D 97 6E 4C 90 EC 46 C7 4A C3 A6 8C D8 95 3. MixColumns Hình 1.17 MixColumns. Trong bước MixColumns, mỗi cột được nhân với một hệ số cố định c(x). Ví dụ: 87 F2 4D 97 EC 6E 4C 90 4A C3 46 C7 8C D8 95 A6 47 40 A3 4C 37 D4 70 9F 94 E4 3A 42 ED A5 A6 BC Trong đó với cột đầu tiên: {02} · {87} = (0000 1110) (0001 1011) = (0001 0101) {03} · {6E} = {6E} ({02} · {6E}) = (01101110) (1101 1100) = (1011 0010). 24 {02} · {87} = 00010101 {03} · {6E} = 10110010 {46} = 01000110 {A6} = 10100110 01000111 = {47} 4. AddRoundKey Với hàm AddRoundKey, mỗi byte trong bảng trạng thái được thực hiện phép XOR với một khoá vòng, quá trình xử lý AES thu được 11 khoá vòng từ các key mã hoá được phân phát cho kỹ thuật mã hoá. Việc phân phát các key mã hoá là kết quả của sự biến đổi các con số, chẳng hạn như hashing, và được thực hiện dựa trên dãy key bí mật ban đầu. 11 khoá vòng được tìm được từ key mã hoá bằng cách sử dụng giải thuật tính toán đơn giản. Hình 1.18 AddRoundKey. Ví dụ: Trong đó ma trận thứ 2 là khóa vòng. 1.7.4.2 Thuật toán mã hóa bất đối xứng Diffie – Hellman (DH) Như đã trình bày ở trên, với phương pháp mã hóa bất đối xứng, khóa dùng để giải mã không được truyền đi mà chỉ truyền cho bên nhận khóa công khai. Chính vì vậy phương pháp mã hóa này tương đối an toàn. Với phương pháp mã hóa với khóa đối xứng, cả hai bên mã hóa (bên gửi) và giải mã (bên nhận) phải sử dụng chung một khóa để mã hóa và giải mã. Do đó, việc đảm bảo an toàn và bí mật cho khóa có vai trò cực kỳ quan trọng. Chính vì lý do này, Whitfield Diffie và Martin Hellman đã đề xuất ra thuật toán trao đổi khóa này vào năm 1976, thuật toán được lấy tên ghép từ tên của 2 nhà phát minh là Diffie-Hellman key exchange. Thuật toán được sử dụng để trao đổi khóa bí mật một cách an toàn trên các kênh thông tin không an toàn, khóa riêng được tính toán 25 bởi cả bên mã hóa và bên giải mã. Hình 1.19 Mô hình Diffie Hellman K = Ab mod p = (ga mod p)b mod p = gab mod p = (gb mod p)a mod p = Ba mod p Giải thuật: 1. Bên gửi và bên nhận muốn dùng phương pháp mã hóa sử dụng khóa đối xứng để liên lạc với nhau. Khi đó bên gửi và bên nhận thống nhất sử dụng một cặp số nguyên tố dùng chung gọi là n và g. Trong đó n là một số nguyên tố đủ lớn, g là một nguyên căn của n. Ví dụ ở đây ta chọn n = 353 và g = 3. 2. Bên gửi chọn ngẫu nhiên một số cho mình gọi là x (x<n)và tính giá trị A theo công thức: A = gx mod n Giả sử bên gửi chọn x = 97 ==> A = 397 mod 353 = 40 Vậy A = 40 3. Bên nhận cũng chọn cho mình một số nào đó gọi là y(y<n) và tính B theo công thức: B = gy mod n Giả sử bên nhận chọn y = 233 ==> B = 3233 mod 353 = 248 Vậy B = 248 4. Bên gửi gửi A = 40 cho bên nhận. Bên nhận gửi B = 248 cho bên gửi 5. Bên gửi tính giá trị khóa mật K1 theo công thức: K1 = Bx mod n ==> K1 = 24897 mod 353 = 160 Bên nhận tính khóa mật K2 theo công thức: 26 K2 = Ay mod n ==> K2 = 40233 mod 353 = 160 Vậy lúc này K1 == K2 == 160 Bên gửi và bên nhận sẽ sử dụng khóa bí mật K = 160 để sử dụng trong quá trình mã hóa và giải mã. 1.7.5 Hàm hash Hàm hash (hash function) là hàm một chiều nó sẽ tạo ra một giá trị băm có kích thước cố định từ dữ liệu đầu vào. Ví dụ, khi sử dụng hàm SHA-1 để băm cụm từ “Illuminati” ta sẽ có kết quả A766F44DDEA5CACC3323CE3E7D73AE82. Khi ta chỉ cần thay đổi “Illuminati” thành “Illuminatus” và sử dụng SHA-1 làm hàm băm sẽ cho kết quả như sau E783A3AE2ACDD7DBA5E1FA0269CBC58D. Tuy nhiên kích thước của kết quả vẫn cố định là 160 bit. Hình 1.20 Hoạt động của 1 hàm băm. Các tính chất quan trọng của hàm băm: • Tính một chiều: rất khó để tìm ra dữ liệu ban đầu từ kết quả. • Tính chống xung đột mạnh: xác suất để hai thông điệp khác nhau có cùng kết quả hash là cực kỳ nhỏ. Các ứng dụng của hàm băm • Chống và phát hiện xâm nhập: chương trình chống xâm nhập sử dụng giá trị hash của một dữ liệu ban đầu với giá trị trước để so sánh, từ đó kiểm tra xem dữ liệu đó có bị thay đổi hay không. • Bảo vệ tính toàn vẹn của thông điệp: kiểm tra giá trị hash của thông điệp trước và sau khi gửi xem có bị thay đổi hay không. • Tạo chìa khóa từ mật khẩu. • Tạo chữ kí điện tử. 27 SHA-1 và MD5 là hai hàm hash thông dụng nhất và được sử dụng trong rất nhiều hệ thống bảo mật. Trong bảo mật H.235 còn sử dụng 2 hàm băm HMAC-SHA1 và HMAC- MD5 Hình 1.21 Hàm băm HMAC-SHA1 28 CHƯƠNG 2 BẢO MẬT H.235 2.1. Giao thức báo hiệu cuộc gọi H.323 [3], [5], [10], [11], [15], [17] 2.1.1. Giới thiệu H.323 là chuẩn quốc tế về hội thoại trên mạng được đưa ra bởi hiệp hội viễn thông quốc tế ITU (International Telecommunication Union). Nó qui định các thành phần, các giao thức sử dụng, các thủ tục cho phép truyền các dữ liệu đa phương tiện (âm thanh, hình ảnh) và số liệu thời gian thực thông qua mạng IP mà không quan tâm tới chất lượng dịch vụ (QoS). Các đầu cuối của các hãng khác nhau có thể giao tiếp được với nhau nếu các đầu cuối này tuân theo chuẩn H.323. 2.1.2. Các thành phần của một hệ thống H.323 Một hệ thống H.323 bao gồm có 4 thành phần chính cho việc truyền tin trên mạng đó là : Terminal, Gateway, Gatekeeper, MCU(Multipoint control unit) Hình 2.1 Các thành phần H.323.  Terminal: Một ví dụ của đầu cuối H.323 được diễn tả trong Hình 2.2. Sơ đồ này chỉ ra các phần tử người dùng, giao diện, video codec, audio codec, H.225.0 layer, hệ thống các phương thức điều khiển. Tất cả các đầu cuối H.323 sẽ bao gồm một hệ thống điều khiển, H.225.0 layer, giao diện mạng và một Audio Codec. Trong đó, Video Codec và các ứng dụng dữ liệu người dùng là tùy chọn. 29 Hình 2.2 Cấu trúc của một đầu cuối H.323 H.323 terminal là một thiết bị đầu cuối trong mạng LAN có khả năng trao đổi thông tin 2 chiều thời gian thực, các terminal có thể là các thiết bị độc lập hoặc các PC. Yêu cầu đối với các thiết bị đầu cuối H.323 để có khả năng trao đổi và giao tiếp được với nhau là phải hỗ trợ chuẩn H245 được dùng để điều tiết các kênh truyền dữ liệu và trao đổi khả năng của thiết bị, H225 được dùng để thiết lập, báo hiệu và huỷ bỏ cuộc gọi và RTP/RTCP được dùng để truyền các gói tin audio, video.  Gateway: Cung cấp sự chuyển dịch thích hợp giữa các định dạng truyền dẫn (Ví dụ: H.225.0 sang H.221 và ngược lại), giữa các thủ tục truyền thông (Ví dụ: H.245 sang H.242 và ngược lại). Gateway cũng có thể thực hiện việc thiết lập cuộc gọi. Việc thay đổi định dạng của video, audio và dữ liệu có thể cũng được thực hiện bên trong Gateway. Gateway được dùng để kết nối giữa hai mạng không giống nhau. Ví dụ, một GW có thể kết nối và cung cấp liên lạc giữa đầu cuối H323 và các mạng SCN (bao gồm các mạng điện thoại PSTN). Cung cấp giao thức biên dịch và chuyển mã giữa một điểm cuối H.323 và một điểm cuối không phải H.323. 30 Hình 2.3 Kết nối giữa một điểm cuối H.323 và một điểm cuối không phải H.323. Tuy nhiên, Một đầu cuối H.323 có thể kết nối một đầu cuối H.323 khác trên cùng một mạng LAN mà không cần sự tham gia của Gateway.  Gatekeeper : là thành phần tùy chọn của một hệ thống H.323, điều khiển việc giải quyết địa chỉ và cho vào mạng H.323. Chức năng quan trọng nhất của nó là biên dịch địa chỉ giữa địa chỉ ký danh tượng trưng và địa chỉ IP. Ví dụ, với sự có mặt của gatekeeper nó có khả năng gọi tới địa chỉ có tên là “Tom” thay vì phải gọi tới địa chỉ IP 192.168.10.10. Khi có mặt trong hệ thống, gatekeeper cung cấp những dịnh vụ chính sau: o Address Translation (Biên dịch địa chỉ): Gatekeeper biên dịch các địa chỉ ký danh tượng trưng sang địa chỉ truyền dẫn thực trong mạng (địa chỉ IP). Điều này được thực hiện bằng cách sử dụng một bảng biên dịch được cập nhật thường xuyên qua các thông báo đăng ký của các đầu cuối. o Admissions Control (Điều khiển truy cập): Gatekeeper cho phép thiết bị đầu cuối truy cập mạng LAN sử dụng thông báo ARQ/ACF/ARJ H.225.0 o Bandwidth Control (Điều khiển băng thông): Gatekeeper hỗ trợ các thông báo BRQ/BRJ/BCF để quản lý và giám sát việc sử dụng dịch vụ và cung cấp băng thông có giới hạn.  MCU (Multipoint Control Unit) : Là một đầu cuối, nó hỗ trợ đàm thoại hội nghị giữa nhiều thiết bị đầu cuối. MCU bao gồm 1 MC (multipoint controller), tùy chọn có hoặc không có các MP (multipoint processor). MC có nhiệm vụ điều khiển tài nguyên của hội thoại bằng cách xác định tài nguyên nào cần được gửi tới các thiết bị đầu cuối, MP có nhiệm vụ trộn, chuyển mạch các chuỗi tín hiệu dữ liệu, âm thanh, hình ảnh do MC điều khiển. MCU sử dụng thông báo H.245. Bên cạnh mạng LAN của một Gateway có thể là một MCU. Một Gatekeeper có thể cũng bao gồm một MCU. 31 2.1.3. Các thành phần của giao thức H.323  Giao thức báo hiệu cuộc gọi H.225: H.225 RAS, H.225.0 Call Signalling.  Giao thức điều khiển cuộc gọi H.245.  Giao thức truyền tải thông tin đa phương tiện RTP/RTCP.  Các chuẩn mã hóa audio: G.711, G.722, G.728, G.729.  Các chuẩn mã hóa video : H.261, H.263. Nhiệm vụ của các giao thức sử dụng trong mạng H.323  H.225.0 bao gồm H.225.0 RAS và H.225.0 Call Signalling. Phiên bản đầu tiên của giao thức báo hiệu cuộc gọi H.225.0 được công bố vào ngày 11/11/1996, cho tới nay phiên bản thứ 7 được công bố chính thức vào ngày 14/12/2009. o H.225.0 RAS là giao thức giữa H.323 Endpoints (Terminal, Gateway) và Gatekeeper. RAS thực thi quá trình đăng ký, thu nhận, thay đổi băng thông, giám sát trạng thái giữa H.323 Endpoints và Gatekeeper. o H.225.0 Call Signalling (Báo hiệu cuộc gọi) dùng để thiết lập kết nối giữa các H.323 Endpoints.  H.245 là giao thức điều khiển cuộc gọi. Phiên bản đầu tiên công bố vào ngày 20/03/1996 cho tới nay phiên bản thứ 15 đã được công bố vào ngày 14/12/2009. Nó mang thông báo điều khiển hoạt động của các thành phần H.323 (H.323 host, H.323 gateway, H.323 gatekeeper). Chức năng quan trọng nhất của H.245 là khả năng trao đổi. Các chức năng khác của H.245 bao gồm đóng mở các kênh logic, các thông báo điều khiển luồng, chế độ ưu tiên cho các yêu cầu, các chỉ dẫn và các lệnh thông thường. Điểm cuối khi tham gia nó sẽ thiết lập H.245 cho mỗi cuộc gọi. Để phù hợp với H.245, các điểm cuối H.323 phải hỗ trợ cú pháp, ngữ nghĩa và các thủ tục sau: o Khả năng trao đổi. O Xác định chủ/tớ. o Đóng mở các kênh logic. o Các điều khiển cuộc gọi. O Chế độ yêu cầu.  RTP/RCTP: Có chức năng truyền và kết hợp tín hiệu media (Audio, Video).  Audio/Video CODEC: dùng để mã hóa và giải mã tín hiệu Audio và Video. 32 Data Control and Signalling Audio/Video Registration T.120 H225.0 Call Signalling H245 Conference Control RTP/RTCP H225.0 RAS TCP UDP Network Layer Data link Layer Physical Layer Hình 2.4 Kiến trúc phân tầng H.323. 33 2.1.4. Các thủ tục báo hiệu trong mạng H323 Hình 2.5 Cuộc gọi trong H.323. 34 Người ta chia một cuộc gọi làm 5 giai đoạn gồm : - Giai đoạn 1: Thiết lập cuộc gọi - Giai đoạn 2: Thiết lập kênh điều khiển - Giai đoạn 3: Thiết lập kênh truyền thông - Giai đoạn 4: Dịch vụ - Giai đoan 5: Kết thúc cuộc gọi Giai đoạn 1: Thiết lập cuộc gọi : Giao thức sử dụng : H.225 . Hai đầu cuối gọi gửi bản tin H.225 RAS đến GK để đăng ký và lấy địa chỉ của đầu cuối bị gọi. Sau đó, đầu cuối này trao đổi các bản tin H.225 (SETUP, CALL PROCEEDING, ALERTING, CONNECT) với đầu cuối bị gọi; trong lúc trao đổi những bản tin này, đầu cuối bị gọi cũng sử dụng bản tin H.225 RAS để đăng ký với GK. Hình 2.6 Thiết lập cuộc gọi H.323. Giai đoạn 2: Thiết lập kênh điều khiển: Giao thức sử dụng : H.245 . Các thông số của cuộc gọi sẽ được thống nhất trong giai đoạn này khi các đầu cuối gửi các bản tin H.245 cho nhau, bao gồm :  Khả năng trao đổi của đầu cuối (Terminal Capability Exchange) : là khả năng truyền, nhận cũng như xử lý các dòng thông tin của các đầu cuối. Việc trao đổi thông tin giữa 2 điểm cuối là cần thiết để cả 2 có cùng phương thức CODEC trong quá trình tham gia một kết 35 nối. Các thông báo H.245 sử dụng trong quá trình này : TerminalCapabilitySet, TerminalCapabilitySetAck.  Quyết định chủ tớ (Master-Slave Determination) : Mẫu thuẫn có thể nảy sinh khi 2 đầu cuối đều có khả năng MC tham gia vào một cuộc gọi hội nghị. Để giải quyết vấn đề này một đầu cuối sẽ đóng vai trò chủ, các đầu cuối khác đóng vai trò tớ. Khi xảy ra mâu thuẫn các đầu cuối phải thông báo vai trò của mình. Thủ tục này cho phép các đầu cuối tham gia trong một cuộc gọi xác định đâu là đầu cuối chủ, đâu là đầu cuối tớ. Vai trò của các đầu cuối có thể được xác định lại trong suốt tiến trình hội nghị. Các bản tin được sử dụng để xác định chủ tớ : masterSlaveDetermination, masterSlaveDeterminationAck.  Đóng mở các kênh logic (Logical Chanel Signalling) : Một kênh logic là kênh mang thông tin từ điểm cuối này đến điểm cuối khác hoặc đến nhiều điểm cuối khác. Một điểm cuối có thể yêu cầu thiết lập kênh logic bằng cách gửi bản tin openLogicalChannel. Điểm cuối có thể chấp nhận yêu cầu này hoặc từ chối. Nếu đồng ý nó sẽ đáp ứng bằng bản tin openLogicalChannelAck ngược lại nó sẽ gửi bản tin phản hồi. Giai đoạn 3 : Thiết lập kênh truyền thông Sau khi trao đổi khả năng (tốc độ nhận tối đa, phương thức mã hoá…) và xác định quan hệ master-slave trong giao tiếp ở giai đoạn 2, thủ tục điều khiển kênh H.245 sẽ thực hiện việc mở kênh logic để truyền dữ liệu. Các kênh này là kênh H.225. Sau khi mở kênh logic để truyền tín hiệu là âm thanh và hình ảnh thì mỗi đầu cuối truyền tín hiệu sẽ truyền đi một bản tin h2250MaximumSkewIndication để xác định thông số truyền. Giai đoạn 4: Dịch vụ cuộc gọi Có một số dịch vụ cuộc gọi được thực hiện trên mạng H.323 như: thay đổi độ rộng băng tần, giám sát trạng thái hoạt động, hội nghị đặc biệt, các dịch vụ bổ sung. Hai loại dịch vụ điển hình: thay đổi độ rộng băng tần và giám sát trạng thái hoạt động. Giai đoạn 5 : Kết thúc cuộc gọi Cuộc gọi được kết thúc 1 cách tuần tự: từ kênh truyền thông, kênh điều khiển, kênh báo hiệu đến đăng ký của các đầu cuối với GK. Đầu tiên hai đầu cuối kết thúc kênh truyền thông và kênh điều khiển H.245 bằng các bản tin CloseLogicalChannel và EndSessionComand. Sau đó đầu cuối bị gọi gửi đi bản tin H.225 RELEASE COMPLETE để kết thúc kênh báo hiệu cuộc gọi. Cuối cùng, đăng ký giữa GK và đầu cuối kết thúc bằng các bản tin RAS. 36 Trường hợp cuộc gọi không có GK : hai đầu cuối vẫn thực hiện các bước như trên và không sử dụng các bản tin RAS. 2.2 Bảo mật H.235 [6], [7], [8], [9], [15], [17] 2.2.1. Giới thiệu H.235 là chuẩn về bảo mật dành cho hội thoại qua mạng sử dụng giao thức báo hiệu H.323 được đưa ra bởi hiệp hội liên minh viễn thông quốc tế ITU(International Telecommunication Union). Ví dụ, những hệ thống H.323 hoạt động dựa trên mạng chuyển mạch gói (không cung cấp sự bảo đảm về chất lượng dịch vụ QoS). Vì vậy truyền thông thời gian thực cần quan tâm tới 2 điều : xác thực và bảo mật. H.235 mô tả những cơ sở và kĩ thuật bảo mật được tận dụng cho những thiết bị đầu cuối đa phương tiện H.3xx. Nó cũng bao gồm những phạm vi cần quan tâm của việc tương tác trong hội nghị truyền thông (những giao thức và thuật toán cần thiết giữa những thực thể H.323 ). H.235 cung cấp khả năng dàn xếp dịch vụ, nó liên quan đến khả năng hệ thống, yêu cầu của ứng dụng và đặc tả về ràng buộc của cách thức bảo mật. Nó hỗ trợ những thuật toán mã hóa khác nhau, với những tùy chọn thích hợp với những mục đích khác nhau (Ví dụ như độ dài khóa). 2.2.2. Giới thiệu về hệ thống sử dụng H.235 Một hệ thống khi sử dụng bảo mật H.235 sẽ bao gồm các tính năng sau: 2.2.2.1. Authentication (xác thực) Quá trình xác thực nhằm mục đích kiểm tra đối tượng đang trao đổi thông tin là ai. Quá trình này có thể được hoàn thành bằng cách trao đổi khóa công khai (public- key) dựa trên chứng nhận điện tử (certificate), hoặc là trao đổi 1 khóa chung (share secret) giữa các bên tham gia. Nó có thể là mật khẩu (password) hoặc là 1 phần thông tin nào đó đã được trao đổi. H.235 mô tả giao thức trao đổi chứng nhận điện tử (certificate), nhưng không chỉ rõ cách thức mà các bên tham gia xác nhận và chấp nhận nó. Nhìn chung, chứng nhận điện tử đưa ra 1 sự bảo đảm cho người kiểm tra rằng : người gửi chứng nhận điện tử là ai. Mục đích đằng sau chứng nhận điện tử là xác thực người sử dụng thiết bị đầu cuối chứ không đơn thuần là xác thực thiết bị đầu cuối về mặt vật lý. Sử dụng chứng nhận điện tử, giao thức xác thực(authentication) này chứng tỏ được rằng người nhận sở hữu khóa bí mật (private key) tương ứng với khóa công khai(public key) chứa trong chứng nhận điện tử. Cách xác thực này giúp chống lại kiểu tấn công man-in-the-midle, chứ không tự động xác định được người trả lời là ai. Để làm được điều này đòi hỏi phải có 1 vài thông tin khác trong chứng nhận điện tử. Ví dụ, chứng nhận điện tử thông thường bao gồm ID của nhà cung cấp dịch vụ cùng với biểu mẫu thông tin tài khoản người sử dụng quy định bởi nhà cung cấp dịch vụ. Đối với xác thực không sử dụng chứng nhận điện tử, khuyến nghị H.235 37 cung cấp báo hiệu để hoàn thành những kịch bản khác nhau. Phương pháp này phụ thuộc vào thứ tự liên lạc của các bên tham gia để thu được khóa chung (share secret). Như là 1 lựa chọn thứ 3, việc xác thực có thể hoàn thành cùng với việc sử dụng những giao thức bảo mật riêng biệt khác như TLS hay IPSEC. Xác nhận 1 chiều hay 2 chiều đều có thể được hỗ trợ bởi các điểm đầu cuối ngang hàng. Việc xác thực này có thể diễn ra trên 1 vài hoặc tất cả các kênh truyền thông. Certificate (Chứng chỉ điện tử): Sự chuẩn hóa của chứng nhận điện tử, bao gồm quá trình tạo ra chúng, quản lý, phân phối không nằm trong phạm vi của khuyến nghị này. Chứng nhận điện tử sử dụng để thiết lập kênh bảo mật (Báo hiệu cuộc gọi, điều khiển cuộc gọi) phải thích hợp với những điều đã quy định bởi giao thức được thống nhất bảo mật kênh truyền. Chú ý khi sử dụng khóa công khai trong chứng nhận điện tử, các đầu cuối được yêu cầu cung cấp chữ kí điện tử sử dụng khóa bí mật. Việc chỉ trao đổi khóa công khai trong chứng nhận điện tử không chống lai khả năng bị tấn công man-in- the-midle. Giao thức H.235 thích hợp với yêu cầu này. 2.2.2.2. Call establishment security (Bảo mật báo hiệu cuộc gọi - H.225 ) Có 2 lý do thúc đẩy việc thiết lập kênh bảo mật. Thứ nhất là xác thực đơn giản trước khi chấp nhận cuộc gọi. Thứ 2 là để cấp phép cuộc gọi. Nhiệm vụ của kênh H.225 trong trường hợp này là cung cấp các kĩ thuật bảo mật mà đầu cuối có thể đáp ứng, xác nhận các kĩ thuật bảo mật đó và trao đổi chứng chỉ điện tử. 2.2.2.3. Call control security (Bảo mật kênh điều khiển cuộc gọi H.245 ) Kênh điều khiển cuộc gọi cũng nên được bảo mật để cung cấp bảo đảm cho kênh truyền thông sau đó. Kênh H.245 được bảo vệ sử dụng những kĩ thuật bảo mật đã được trao đổi trước đó. Bản tin H.245 được sử dụng để báo hiệu thuật toán mã hóa và khóa đã được mã hóa sử dụng trong kênh chia sẻ, kênh media. Trong hội nghị đa điểm, nhiều khóa khác nhau được sử dụng cho nhiều luồng với mỗi điểm đầu cuối. Nó đảm bảo an toàn đối với mỗi điểm đầu cuối trong hội nghị. Kĩ thuật bảo vệ H.245 phụ thuộc vào đầu cuối H-series liên quan. Yêu cầu duy nhất cho tất cả các hệ thống tận dụng cấu trúc bảo mật này là mỗi bên phải có 1 vài cách thức dàn xếp hay báo hiệu rằng kênh H.245 được hoạt động theo cách thức bảo mật trước khi nó được khởi tạo. Ví dụ, H.323 sẽ sử dụng bản tin báo hiệu H.255.0 để hoàn thành việc này. 38 2.2.2.4. Media stream privacy (Bảo mật kênh truyền thông ) 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. 39 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ư 40 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. 41 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 42 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 43 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ã. 44 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: 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. 45 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 46 đầ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 ). Initialization vector (Giá trị khởi tạo). Padding (Gán thêm dữ liệu). 47 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). 48 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. 49 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 antiSpamAlgorithm xác định phương pháp chống spam. Vì lý do bảo mật, mã 50 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. 51 2.2.4. Các thủ tục xác thực trong cuộc gọi sử dụng H.235 2.2.4.1. Cơ chế xác thực Baseline security profile Bảng 2.2 Baseline security profile Đối với cơ chế xác thực này, người sử dụng sẽ dùng mật khẩu chung hay khóa bí mật, nó sẽ được sử dụng trong hàm băm để áp dụng băm tất cả các trường trong bản tin H.225 RAS và báo hiệu nhằm mục đích đảm bảo sự toàn vẹn cho bản tin. Đối với tùy chọn bảo mật thoại, lược đồ trên đề xuất sử dụng các thuật toán AES-128, RC2-compatible , DES hay triple-DES dựa trên sự trao đổi về chế độ và yêu cầu diễn ra trước đó. Các cách thức điều khiển truy cập được áp dụng dựa trên thông tin truyền tải nhận được trong các trường báo hiệu H.235 ( ClearToken, CrytoToken ). Các thực thể truyền thông liên quan có thể quyết định chế độ xác thực thông qua thông qua các trường tokenOID và algorithmOID trong các bản tin. Có 2 dịch vụ được cung cấp trong Baseline security profile : o Authentication and integriy : Nó kết hợp sự hỗ trợ về toàn vẹn thông tin với xác thực người sử dụng. Có thể chắc chắn về sự xác thực này bằng cách áp dụng đúng thủ tục trao đổi khóa chung (share secret). o Authenticaton-only : Đây là 1 tùy chọn cung cấp sự xác thực cho 1 vài trường được lựa chọn chứ không phải toàn bộ bản tin. Nó được áp dụng cho các bản tin báo hiệu đi qua các thiết bị NAT hay tường lửa. 52 Người sử dụng có thể chắc chắn về sự xác thực này bằng cách áp dụng đúng thủ tục trao đổi share secret. Thủ tục xác thực : Bên gửi bản tin xác thực sẽ tính toán như sau : - Thiết lập giá trị băm có độ dài là 96 bit. - ASN.1- mã hóa toàn bộ bản tin. - Xác định và ghi lên trường chứa giá trị băm 96 bit 0 trong bản tin đã được mã hóa bằng ASN.1. - Tính giá trị băm dựa trên bản tin được mã hóa bởi ASN.1 sử dụng HMAC-SHA1- 96. - Thay thế giá trị trường hash bằng giá trị vừa tính được. 53 Hình 2.17 Quá trình tính toán xác thực ở bên gửi. Bên nhận bản tin sẽ xử lý như sau : - ASN.1 – giải mã bản tin. - Tách giá trị băm nhận được và lưu nó vào biến cục bộ RV. 54 - Tìm và xác định vị trị trí của giá trị RV trong bản tin chưa được giải mã. Ghi chồng lên giá trị đó 96 bit 0. - Tính lại giá trị băm đối với bản tin chưa được giải mã đó sử dụng HMAC- SHA1-96. - So sánh RV với giá trị băm vừa tính được. Bản tin được xem như là toàn vẹn nếu 2 giá trị này bằng nhau, khi đó việc xác nhận thành công và thủ tục được kết thúc. - Nếu 2 giá trị không bằng nhau thì việc xác thực thất bại và bản tin đã bị sửa đổi (do lỗi đường truyền hay cố ý) trong quá trình truyền. 55 Hình 2.18 Quá trình xác thực bên nhận Tóm lại: Sử dụng cơ chế xác thực này có thể chống lại các nguy cơ tấn công sau : 56 Denial-of-service attacks : Kiểm tra nhanh các giá trị băm có thể tránh được dạng tấn công này. Man-in-the-middle attacks : sử dụng authentication and integrity. Replay attacks : Sử dụng sequence và timestamp. Spoofing(Giả mạo) : Sử dụng cơ chế xác nhận. Connection hijacking : sử dụng authentication and integrity. 2.2.4.2. Cơ chế xác thực Signature security profile Signature security profile được đề xuất như là 1 tùy chọn, thường được áp dụng trong trường hợp có nhiểu điểm cuối mà việc sử dụng mật khẩu/khóa chung là không khả thi. Nó cung cấp thêm dịch vụ bảo mật không thể chối bỏ với chữ ký điện tử và chứng chỉ điện tử. Chữ ký điện tử sử dụng hàm băm SHA1 hoặc MD5 cho việc xác thực và toàn vẹn bản tin. Bảng 2.3 Signature security profile Bên gửi bản tin sẽ tính toán chữ ký điện tử như sau : - Giá trị của trường chứa chữ ký điện tử sẽ được thiết lập thành 1 giá trị cố định (có thể là 1024 bit). Bước này nhằm dành ra 1 khoảng trống cho độ dài tối đa của chữ ký điện tử. - ASN.1 mã hóa toàn bộ bản tin. - Xác định đoạn đã được dành ra trong bản tin mã hóa và chồng lên những bit 0. - Tính toán chữ ký điện tử trên bản tin được mã hóa ASN.1 - Thay thế các bit 0 bằng chữ ký điện tử. 57 Hình 2.19 Quá trình tính toán giá trị xác thực bên gửi, sử dụng chữ ký điện tử 58 Bên nhận sẽ xác thực như sau : - ASN.1 giải mã bản tin. - Tách chữ ký điện tử nhận được và lưu nó vào trong biến cục bộ SV. - Tìm và xác định vị trí của giá trị RV trong bản tin mã hóa. - Ghi đè lên vị trí đó các bit 0. - Tính toán lại chữ ký điện tử trên bản tin mã hóa dựa và phương thức chỉ ra bởi algorithmOID. - So sánh SV với giá trị vừa tính được. Bản tin được coi là không bị sửa đổi nếu 2 giá trị này bằng nhau, khi đó việc xác thực thành công và thủ tục dừng lại. 59 Hình 2.20 Quá trình xác thực ở bên nhận. Tóm lại: Sử dụng cơ chế xác thực này, đầu cuối không chỉ chống lại được các nguy cơ tấn công được trình bày trong Baseline security profile mà còn cung cấp khả năng xác thực người dùng bên kia nhờ các thông tin chỉ ra trong chứng chỉ điện tử. 60 CHƯƠNG 3 THỰC NGHIỆM 3.1 Giới thiệu phần mềm Xcall 3.1.1 Tổng quan hệ thống Hình 3.1 Tổng quan hệ thống  XCall Application: Là một ứng dụng H.323 client đơn giản được xây dựng dựa trên bộ thư viện mã nguồn mở Open H.323, cho phép thực hiện các cuộc gọi bảo mật giữa 2 điểm đầu cuối.  Open H.323: bộ thư viện mã nguồn mở được viết bằng ngôn ngữ lập trình C++, cung cấp các giao diện cần thiết cho việc thiết lập một hệ thống VOIP sử dụng giao thức H.323 làm giao thức báo hiệu.  Codecs: bộ mã hóa và giải mã tín hiệu audio. Tín hiệu audio trước khi truyền đi phải được mã hóa, bên nhận sau khi nhận được tín hiệu phải tiến hành giải mã trước khi phát ra loa.  RTP: thư viện được tích hợp sẵn trong bộ thư viện mã nguồn mở OpenH.323, làm nhiệm vụ vận chuyển tín hiệu audio giữa các điểm đầu cuối. Các chức năng chính của XCall: - Gọi điểm – điểm giữa 2 client - Bảo mật cuộc gọi sử dụng giao thức H.235 3.1.2 Thiết kế chương trình RecorderPlayer XCall PSoundChannel PSoundChannelOpenH.323 H323Endpoint Codecs H323Codec RTP H323Channel Hình 3.2 Tương tác giữa các module 61 Chương trình bao gồm 6 module chính tương tác với nhau: - XCall: đây là module ứng dụng bao gồm giao diện của phần mềm và xử lý nghiệp vụ của phần mềm, XCall giao tiếp với OpenH.323 thông qua đối tượng H323Endpoint. - OpenH.323: đây là module lõi của hệ thống thực hiện các chức năng như: Quản lý các cuộc gọi H.323, trao đổi các khóa bảo mật sử dụng giao thức H.235, thu, phát, mã hóa và giải mã tín hiệu âm thanh. Module này bao gồm các module con như: Module thu tín hiệu âm thanh (Recorder), module phát tín hiệu âm thanh (Player), module mã hóa giải mã (Codecs) và module thực hiện chức năng vận chuyển tín hiệu giữa các đầu cuối (RTP). - Recorder: Giao tiếp với thiết bị microphone để thu tín hiệu âm thanh và chuyển cho khối mã hóa. - Codecs: Thực hiện chức năng mã hóa tín hiệu âm thanh trước khi truyền đi và giải mã sau khi nhận được. - Player: Phát âm thanh ra loa. 3.1.3 Class diagram Hình 3.3 Class Diagram 62 Hình 3.4 Biểu đồ sequence huỷ cuộc gọi 3.1.4 Giao diện chương trình Hình 3.5 Giao diện chương trình Xcall 63 3.2 Giới thiệu chương trình Wireshark Wireshark là một chương trình bắt gói tin trên mạng. Nó sẽ cố gắng bắt tất cả các gói tin và hiển thị thông tin chi tiết nhất có thể. Mục đích của việc sử dụng Wireshark có thể là: - Quản trị mạng: kiểm tra các lỗi trên mạng - Bảo mật hệ thống: kiểm tra các lỗi về bảo mật - Phát triển hệ thống: gỡ rối hoạt động của giao thức - Các đối tượng khác: học về các giao thức nội tại của mạng Hình 3.6 Chương trình Wireshark Wireshark có một số ưu điểm như sau: - Có thể chạy trên cả hệ thống UNIX và Windows - Bắt các bản tin trực tuyến trên card mạng - Hiện gói tin với thông tin về giao thức - Có thể mở và lưu lại các dữ liệu đã bắt được - Import and Export các gói tin từ rất nhiều chương trình khác - Lọc gói tin với nhiều tiêu chí khác nhau - Tìm kiếm gói tin với nhiều tiêu chí - Hiển thị gói tin với màu nổi bật dựa trên bộ lọc - Tạo rất nhiều thống kê 64 3.3 Khảo sát cuộc gọi VoIP thực tế Cuộc gọi được tiến hành trong thực tế là cuộc gọi trong mạng LAN giữa 2 PC sử dụng phần mềm Xcall hỗ trợ G711 gọi trực tiếp cho nhau. Phần mềm wireshark chạy trên máy bị gọi bắt được các bản tin trao đổi giữa 2 máy 3.3.1 Đối với cuộc gọi khi không sử dụng giao thức bảo mật H.235 Hai máy trao đổi các bản tin H.225 mà không kèm theo trường Token chứa khóa Hình 3.7 Bản tin Setup Sau khi trao đổi xong các bản tin điều khiển và mở kênh truyền thông, các gói tin RTP mang thông tin thoại sẽ được truyền đi giữa 2 PC. Wireshark cũng bắt được các gói tin này và có khả năng giải nén cũng như nghe lại. Như vậy, khi không sử dụng H.235, thông tin truyền đi không được mã hóa và có thể bị nghe lén 65 Hình 3.8 Giải nén gói tin RTP 3.3.2 Trường hợp sử dụng H.235 1. Máy gọi gửi cho máy nhận bản tin Setup có thông số DH trong trường token. Hình 3.9 Bản tin Setup H.235 66 2. Máy bị gọi nhận được bản tin Setup sẽ chọn thông số DH phù hợp nhất và gửi lại nó cho bên gọi. Hình 3.10 Bản tin Connect H.235 3.Hai bên sau đó sẽ trao đổi các bản tin H.245 về các thông số như audio, video CODEC, master/slave. Sau đó, điểm cuối là master sẽ gửi đi bản tin mở kênh có kèm theo khóa phiên ( đã được mã hóa bởi khóa chung DH) trong trường encrytionSync. Hình 3.11 Bản OpenLogicalChannel H.235 4. Sau khi mở kênh thoại, các gói tin sau đó sẽ được mã hóa bằng khóa và thuật toán trao đổi trước đó. Khi này Wireshark cũng bắt được các bản tin trao đổi giữa 2 PC. Tuy nhiên khi giải nén các gói tin RTP chỉ nhận được các tín hiệu vô nghĩa. 67 Hình 3.12 Giải nén gói tin RTP H.235 68 KẾT LUẬN Những kết quả luận văn đã đạt được Luận văn đã tìm hiểu tổng quan về VoIP. Kiến trúc, cấu trúc kết nối, các ưu nhược điểm của hệ thống VoIP. Tìm hiểu một số nguy cơ tấn công vào mạng VoIP, các công nghệ và thuật toán bảo mật sử dụng trong mạng VoIP. Tìm hiểu giao thức báo hiệu H.323, các bước thiết lập cuộc gọi cơ bản sử dụng giao thức báo hiệu H.323. Đặc biệt nghiên cứu kỹ giao thức bảo mật H.235 sử dụng giao thức báo hiệu H.323 cho hệ thống VoIP. Xây dựng phần mềm VoIP Xcall dựa trên mã nguồn mở OpenH323. Phần mềm Xcall có hỗ trợ giao thức bảo mật H.235 sử dụng giao thức báo hiệu H.323. Phương hướng nghiên cứu tiếp theo Nghiên cứu cải tiến phần mềm Xcall để có chất lượng cuộc thoại tốt hơn. Có thể cài đặt trong môi trường Internet, hội nghị đa điểm... Nghiên cứu về giao thức báo hiệu khác trong VoIP như SIP... cũng như các hỗ trợ bảo mật áp dụng cho các giao thức báo hiệu này. Tuy đã cố gắng hết sức trong quá trình nghiên cứu và thực hiện đề tài nhưng do thời gian và kiến thức hạn chế, luận văn của tôi không tránh khỏi những sai xót. Một lần nữa cho phép tôi xin gửi lời cảm ơn chân thành nhất tới PGS.TS Nguyễn Văn Tam, thầy cô giáo khoa Công nghệ thông tin trường Đại học Công nghệ - Đại học Quốc gia Hà Nội, bạn bè đồng nghiệp đã tận tình giúp đỡ và động viên tôi để tôi có thể hoàn thành luận văn này.