Bảo mật dịch vụ họp trực tuyến theo mô hình SFU trên nền WebRTC (Phần 2)

20:00 | 29/01/2022 | MẬT MÃ DÂN SỰ

Trong Phần 1, bài báo đã giới thiệu về các công nghệ lõi được sử dụng trong mô hình họp trực tuyến SFU, trong đó đã trình bày nhiều công nghệ lõi, thuật toán được áp dụng để tối ưu hóa băng thông và xử lý dữ liệu trong mô hình SFU. Trong Phần 2 này, nhóm tác giả tiếp tục trình bày thêm thuật toán GCC (Google Congestion Control) để tối ưu hóa băng thông và kiểm soát tắc nghẽn dữ liệu trong mô hình SFU. Phần còn lại của bài báo, tập trung trình bày các giải pháp bảo mật dữ liệu trong mô hình SFU.

THUẬT TOÁN GCC CHO MÔ HÌNH SỬ DỤNG CHUYỂN TIẾP CHỌN LỌC SFU

Trên thực tế, SFU phải triển khai lại quá trình kiểm soát tắc nghẽn để có thể phù hợp với yêu cầu thực tế là một đầu cuối có thể chuyển tiếp cho nhiều đầu cuối khác khi tham gia hội nghị truyền hình. Ngoài ra, SFU còn là thành phần trung tâm nhận gửi, chỉnh sửa các gói RTP để chuyển tiếp và thực hiện trao đổi với các đầu cuối dựa trên gói RTCP [3].

Bảo mật dịch vụ họp trực tuyến theo mô hình SFU trên nền WebRTC (Phần 2)

Hình 1. Mô hình truyền các gói trên SFU

Đối với các gói RTP

Bên cạnh việc chuyển tiếp các gói RTP, SFU tiến hành chỉnh sửa một số các trường phần đầu gói, như payload type (PT), Synchronization Source (SSRC), Chuẩn hóa lại thành Contributing Source (CSRC), và sequence number (SN); sử dụng dấu thời gian mở rộng (abs-send-time) [2]; sử dụng phần đầu mở rộng gói, TCC (Transport-wide Congestion Control hay Transport-wide Sequence Number) [4].

Đối với các gói RTCP

SFU yêu cầu quyền truy cập nội dung rõ các thông điệp RTCP. Các bản tin RTCP thường được các SFU sử dụng bao gồm Báo cáo người gửi (SR), Báo cáo người nhận (RR), các thông điệp SDES, BYE, APP, cũng như các thông điệp phản hồi (Feedback Messages). Mặc dù SFU cần giải mã các thông báo RTCP, tuy nhiên các thiết kế SFU không sửa đổi SSRC vẫn có thể chuyển tiếp các thông báo RTCP như SDES mà không cần sửa đổi (hoặc thậm chí phân tích cú pháp). Điều này mang đến lợi thế cho SFU, vì có thể chuyển tiếp các thông điệp RTCP mà nó không hiểu.

Các thông báo phản hồi (RTCP Feedback Messages) được hỗ trợ rộng rãi bởi các triển khai SFU hiện có bao gồm: NACK, PLI và FIR. NACK sửa chữa các tổn thất trong dòng bit SVC để kịp thời để cho phép giải mã khung phụ thuộc kế tiếp. FIR thường được sử dụng trong các SFU khi chuyển đổi giữa các luồng video hoặc bắt đầu chuyển tiếp một luồng simulcast khi người dùng được kích hoạt. Khi đó, FIR được SFU gửi tới người gửi luồng RTP đã chuyển mạch. Người gửi phản hồi bằng I-frame sau đó được chuyển tiếp đến người nhận, đảm bảo rằng họ có thể giải mã các khung tiếp theo trong luồng RTP được chuyển mạch. PLI tương tự như FIR, thông điệp được gửi khi bên nhận không nhận đầy đủ các khung để giải mã.

Các gói RTCP, chủ yếu được sử dụng để điều khiển các luồng và ước lượng băng thông có sẵn. Bất cứ khi nào nhận một gói RTCP (SR, RR), RTT được tính và cập nhật cho quá trình ước tính băng thông dựa trên độ trễ (delay-based). Nếu SFU nhận các gói REMB (RTCP Feedback), băng thông ước tính này sẽ được cập nhật cho quá trình ước tính băng thông. Cuối cùng, nếu nhận được các gói RTCP TCC Feedback [3], các gói này cho phép phát hiện mất gói sớm, ước lượng băng thông dựa trên mất gói (Loss-based) sẽ được tính toán. Như vậy, SFU tính toán băng thông cuối cùng dựa trên ba thông số: ước lượng băng thông dựa trên mất gói, ước lượng băng thông dựa trên độ trễ và ước tính băng thông từ xa. Cuối cùng, SFU gửi băng thông cuối cùng này cho đầu cuối gửi dữ liệu thông qua RTCP để đầu cuối này tăng hoặc giảm băng thông.

BẢO MẬT DỊCH VỤ HỘI NGHỊ TRUYỀN HÌNH THEO MÔ HÌNH SFU

Hai phương pháp mã hóa trong công nghệ WebRTC là mã hóa Hop-by-Hop (HBH) và mã hóa điểm đầu cuối (E2E). Mã hóa đầu cuối (E2E) để bảo vệ dữ liệu đa phương tiện giữa bên gửi và bên nhận. Trong trường hợp này SFU không thể truy cập đến dữ liệu đa phương tiện của người dùng đầu cuối. Trái lại, với kiểu mã hóa HBH thì SFU có quyền truy cập dữ liệu của người dùng đầu cuối.

Hình 2. Mã hóa HBH và E2E trong WebRTC

Hình 2 thể hiện hai lớp mã hóa và thứ tự các lớp mã hóa từ ngoài vào trong là:

- Mã hóa Hop-by-hop (HBH) mã hóa dữ liệu đa phương tiện, dữ liệu phụ và thông báo phản hồi giữa các điểm cuối và SFU, sử dụng DTLS-SRTP.

- Mã hóa end-to-end (E2E) mã hóa dữ liệu đa phương tiện giữa các điểm cuối, nơi đầu cuối sử dụng khóa riêng để mã hóa/giải mã.

Mã hóa E2E (Sframe)

Sframe là một cơ mã hóa mức khung, cung cấp khả năng mã hóa end-to-end hiệu quả, dễ triển khai, không phụ thuộc vào RTP và giảm thiểu chi phí băng thông mã hóa. Bởi vì Sframe mã hóa toàn bộ khung hình, thay vì các gói RTP riêng lẻ nên chi phí băng thông được giảm xuống bằng cách chỉ sử dụng một IV (Initialization Vector) và thẻ xác thực MAC cho mỗi khung phương tiện.

Hình 3. Mô hình mã hóa đầu cuối Sframe với SFU

Hình 3, thể hiện quá trình mã hóa đầu cuối. Trong đó, khóa giữa các bên tham ra được trao đổi qua kênh riêng, tại các gói Sframe chỉ lưu ID khóa để giải mã, trước khi gói Sframe được gửi đi thông qua bộ tạo gói RTP (Packetizer) và được tập hợp lại thông qua bộ tập hợp gói RTP (Depacketizer) (Hình 3).

Trong đó, phần đầu của mỗi khung (Sframe header) có một bộ đếm khung duy nhất (Frame counter) sẽ được sử dụng để lấy IV (Vector). Vì mỗi đầu cuối gửi sẽ sử dụng khóa riêng để mã hóa, do đó, phần đầu gói Sframe sẽ bao gồm ID khóa (KID) để cho phép đầu cuối nhận xác định khóa được sử dụng để giải mã [9] (Hình 4).

Hình 4. Mô tả định dạng gói Sframe

Với phiên bản hiện tại, nhóm phát triển Jitsi Meet sử dụng một cấu trúc tương tự như Sframe, nhưng có sự thay đổi về cấu trúc và thêm một số thành phần; được gọi là Jframe (Hình 5).

Hình 5. Minh họa cấu trúc gói Jframe

Trong đó, phần đầu tiên được thêm (Unencrypted payload header) là phần không được mã hóa, sử dụng để sao chép các byte đầu tiên của dữ liệu VP8 không được mã hóa (10 byte cho khung hình chính hoặc 3 byte cho khung hình không chính hoặc 1 byte cho audio). Các dữ liệu thông tin này cho phép các đầu cuối không bật tính năng mã hóa nhưng vẫn nhận và giải nénđược các hình ảnh, âm thanh (mặc dù dữ liệu này là không có nghĩa). Phần cuối của cấu trúc Jframe tương tự như phần đầu của gói Sframe, gồm IV, IV_LEN, KID.

KẾT LUẬN

Công nghệ hội nghị truyền hình dựa truyên SFU đang được phát triển mạnh so với công nghệ truyền thống sử dụng MCU (chỉ có ở các sản phẩm thương mại). Để có thể tận dụng hạ tầng về thiết bị và đường truyền phục vụ cho mục đích hội nghị, các công nghệ được áp dụng vào SFU như: Việc encode/decode được thực hiện ở các đầu cuối, SFU không tham gia vào quá trình encode/decode; sử dụng các công nghệ Last-N, simulcast, thuật toán điều chỉnh băng thông để giảm thiểu băng thông khi sử dụng. Ngoài ra, để đảm bảo an toàn thì chuẩn bảo mật mới cho WebRTC đang được phát triển như E2E, HBH cùng với các giải pháp truyền thống như sử dụng VPN.

Trong bài báo tiếp theo, nhóm tác giả sẽ trình bày phương pháp phân phối khóa nhóm được sử dụng trong E2E để bảo mật dữ liệu hội nghị truyền hình. Khóa nhóm cần đảm bảo tính chất an toàn phía trước (tức là khi một người dùng mới tham gia hội nghị thì không thể giải mã được dữ liệu trước đó) và an toàn phía sau (khi một người dùng rời hội nghị thì không thể giải mã được dữ liệu tiếp theo).

TÀI LIỆU THAM KHẢO

1. Emad Omara, Justin Uberti, Alex Gouaillard, Sergio Garcia Murillo. Secure Frame (SFrame). https://datatracker.ietf.org/doc/draft-omara-sframe/, 2021

2. H Alvestrand. RTCP message for Receiver Estimated Maximum Bitrate. https://tools.ietf.org/html/draftalvestrand-rmcat-remb-03, October 2013.

3. https://github.com/jitsi/jitsi-videobridge

4. S. Holmer, M. Flodman, and E. Sprang. RTP Extensions for Transportwide Congestion Control. https://tools.ietf.org/html/ draft-holmer-rmcat-transport-wide-ccextensions-01, October 2015

Phạm Văn Lực, Phạm Đức Hùng, Trần Đức Long, Viện KHCN mật mã

‹ › ×

Tin liên quan

Hội thảo khoa học quốc tế “Mô hình hóa, tính toán và tối ưu hóa trong hệ thống thông tin”

18:00 | 14/12/2021

Trong hai ngày 13 - 14/12, Học viện Kỹ thuật mật mã, Ban Cơ yếu Chính phủ phối hợp cùng Đại học Lorraine (Pháp) và Đại học Quốc gia Hà Nội đồng tổ chức Hội thảo khoa học quốc tế lần thứ tư với chủ đề “Mô hình hóa, tính toán và tối ưu hóa trong hệ thống thông tin - MCO 2021”. Hội thảo diễn ra theo hình thức trực tuyến.

Đề xuất mô hình triển khai mạng SD-WAN chống lại tấn công DDoS (Phần 2)

10:00 | 21/12/2021

Phần I của bài báo đã giới thiệu về hệ thống SD-WAN và các ưu, nhược điểm của hệ thống này (Tạp chí An toàn thông tin, số 3 (061)2021). Trong Phần II, một mô hình triển khai mạng SD-WAN sẽ được đề xuất nhằm chống lại tấn công DDoS.

Bảo mật dịch vụ họp trực tuyến theo mô hình SFU trên nền WEBRTC (Phần 1)

09:00 | 28/12/2021

Hội nghị truyền hình đang được ứng dụng phổ biến trong nhiều lĩnh vực và càng được ứng dụng nhiều hơn nhờ sự phát triển mạnh của môi trường truyền dẫn thông qua mạng Internet. Song song tồn tại với công nghệ hội nghị truyền hình sử dụng MCU, thì công nghệ hội nghị truyền hình dựa trên SFU đã và đang được ứng dụng nhiều trong các phần mềm thương mại như Vydio, Google Hangouts và Google Meet và Facebook Messenger. Bài viết sẽ giới thiệu về những công nghệ lõi trong SFU, cũng như các giải pháp bảo mật dữ liệu truyền thông cho mô hình SFU. Qua đó, chúng ta có thể xây dựng riêng một hệ thống hội nghị truyền hình có bảo mật dựa trên mô hình SFU. Bài viết được tổ chức thành hai phần: Phần I sẽ giới thiệu những công nghệ lõi sử dụng trong mô hình họp trực tuyến SFU. Phần II sẽ trình bày về thuật toán kiểm soát tắc nghẽn GCC và vấn đề bảo mật dữ liệu trong mô hình họp trực tuyến SFU.

Tin cùng chuyên mục

Giới thiệu tiêu chuẩn TCVN 13178-2:2020

15:00 | 04/10/2023

Xác thực thực thể ẩn danh là một kiểu xác thực thực thể đặc biệt. Trong một cơ chế xác thực thực thể ẩn danh, với một thông báo được tạo ra trong giao thức xác thực, một thực thể trái phép không thể khám phá ra định danh của thực thể đang được xác thực (bên được xác thực). Cùng lúc đó, một bên xác thực được ủy quyền có thể không được phép biết định danh của thực thể đang được xác thực. Trong nội dung bài viết trước đã giới thiệu tổng quan về Xác thực thực thể ẩn danh tại TCVN 13178-1. Bài viết này sẽ tiếp tục giới thiệu tới độc giả các cơ chế xác thực thực thể ẩn danh dựa trên chữ ký sử dụng khóa công khai nhóm được quy định tại TCVN 13178-2.

Tính toán nhiều bên an toàn MPC và xu thế phát triển của mật mã phi tập trung

09:00 | 08/06/2023

Tính toán nhiều bên an toàn MPC (Multi-Party Computation) là một giao thức mật mã cho phép thực hiện tính toán một giá trị chung bởi nhiều bên tham gia mà không phải chia sẻ bất kỳ thông tin cá nhân giữa các thành viên. MPC được phát triển như một giải pháp khả thi để giải quyết những thách thức nổi bật đối với bảo mật khóa cá nhân trong thời điểm hiện tại và có nhiều tiềm năng ứng dụng trong tương lai.

Một số công cụ kiểm thử xâm nhập tiêu biểu năm 2022

15:00 | 14/12/2022

Kiểm thử xâm nhập còn được gọi là ethical hacking, là hành động xâm nhập hệ thống thông tin một cách hợp pháp. Kiểm thử xâm nhập giúp phát hiện ra các lỗ hổng và điểm yếu trong hệ thống phòng thủ bảo mật của tổ chức trước khi để kẻ xấu phát hiện ra. Đây là hành động hỗ trợ đắc lực cho tổ chức trong việc đưa ra các giải pháp để khắc phục các lỗ hổng bảo mật đã được phát hiện trước đó.

Khởi sắc hoạt động cấp phép mật mã dân sự 6 tháng đầu năm 2022

14:00 | 25/07/2022

Trước nhu cầu về bảo mật an toàn thông tin trong hệ thống các cơ quan nhà nước, các tổ chức, doanh nghiệp và cá nhân ngày càng gia tăng, hoạt động kinh doanh sản phẩm, dịch vụ mật mã dân sự (MMDS) và xuất khẩu, nhập khẩu sản phẩm MMDS tăng lên nhanh chóng với quy mô rộng trên phạm vi cả nước.