(Tiểu luận) đề tài xây dựng ứng dụng gọi điệnbảo mật thông tin dựa trênwebrtc security

32 Chuyển chế độ gọi thoại và mở cửa sổ nhỏ Trang 7 Discover morefrom:Document continues belowThực Tập TốtNghiệpHọc viện Công ng…13 documentsGo to courseHinhThuc trinhbayTTTN-QD-922-…Th

TÌM HIỂU VỀ WEBRTC SECURITY

Tổng quan

Giao tiếp thời gian thực Web (WebRTC) là một xu hướng công nghệ mới nổi trong lĩnh vực ứng dụng web, cho phép người dùng thực hiện các cuộc gọi video, chia sẻ tệp và tương tác trực tiếp trong trình duyệt mà không cần đến sự hỗ trợ của các plug-in hoặc yêu cầu khác Tuy nhiên, bản chất nguồn mở của WebRTC cũng đặt ra những thách thức về bảo mật, khiến các nhà phát triển và người dùng phải cân nhắc kỹ lưỡng trước khi áp dụng công nghệ này.

Giới thiệu

Công nghệ WebRTC là một giải pháp mã nguồn mở dựa trên web, cho phép người dùng chia sẻ phương tiện trực tuyến một cách nhanh chóng và tiện lợi mà không cần cài đặt thêm plugin Chỉ cần sử dụng một trình duyệt hỗ trợ, người dùng có thể thực hiện cuộc gọi với người khác chỉ bằng cách truy cập vào trang web tương ứng, mang lại trải nghiệm trực tuyến mượt mà và liền mạch.

- Một số trường hợp sử dụng chính của công nghệ này bao gồm:

 Cuộc gọi âm thanh và / hoặc video thời gian thực

 Truyền dữ liệu trực tiếp

Không giống như hầu hết các hệ thống thời gian thực như SIP, WebRTC cho phép thông tin liên lạc được điều khiển trực tiếp bởi một số máy chủ Web thông qua API JavaScript, cung cấp một cách tiếp cận linh hoạt và dễ dàng tích hợp vào các ứng dụng web.

Triển vọng cho phép giao tiếp bằng âm thanh và hình ảnh được nhúng trong một trình duyệt không cần plugin là rất thú vị, mở ra khả năng mới cho việc tương tác trực tuyến Tuy nhiên, điều này cũng đặt ra những lo ngại về tính bảo mật của công nghệ này, đặc biệt là liệu nó có thể đảm bảo cung cấp thông tin liên lạc đáng tin cậy cho cả người dùng cuối và các nhà cung cấp dịch vụ trung gian hoặc bên thứ ba.

Bảo mật WebRTC

1.3.1 Cài đặt và Cập nhật

Một vấn đề phổ biến với phần mềm máy tính để bàn truyền thống là sự không chắc chắn về độ tin cậy của ứng dụng Việc cài đặt phần mềm mới hoặc plugin có thể dẫn đến việc cài đặt lén lút phần mềm độc hại hoặc phần mềm không mong muốn khác Điều này khiến người dùng cuối gặp khó khăn trong việc xác định nguồn gốc của phần mềm hoặc biết chính xác họ đang tải ứng dụng từ ai Các bên thứ ba độc hại đã lợi dụng điều này bằng cách đóng gói lại phần mềm an toàn và đáng tin cậy để bao gồm phần mềm độc hại, sau đó cung cấp gói tùy chỉnh của họ trên các trang web phần mềm miễn phí.

WebRTC không phải là một plugin và cũng không yêu cầu bất kỳ quá trình cài đặt nào cho các thành phần của nó Công nghệ WebRTC cơ bản được tích hợp sẵn trong trình duyệt tương thích như Chrome hoặc Firefox Khi người dùng đã có trình duyệt hỗ trợ WebRTC, họ có thể dễ dàng truy cập và sử dụng bất kỳ ứng dụng WebRTC nào mà không cần thiết lập hoặc chuẩn bị thêm.

Các ứng dụng WebRTC được thiết kế để đảm bảo an toàn cho người dùng, giúp ngăn chặn nguy cơ cài đặt phần mềm độc hại hoặc vi rút khi sử dụng Tuy nhiên, để đảm bảo an toàn tối đa, các ứng dụng này vẫn cần được truy cập thông qua trang web HTTPS được ký bởi trình xác thực hợp lệ, chẳng hạn như Verisign.

Một vấn đề liên quan đến bảo mật trong WebRTC là việc vá các lỗi bảo mật được phát hiện trong phần mềm Khi các lỗi hoặc lỗ hổng bảo mật được tìm thấy, việc phát triển bản vá có thể mất nhiều thời gian, đặc biệt là khi bảo mật thường được coi là yếu tố phụ sau chức năng Điều này đặt ra thách thức về việc đảm bảo an toàn cho người dùng, đặc biệt là khi so sánh với các phương pháp giao tiếp dựa trên phần cứng, chẳng hạn như điện thoại VoIP, nơi việc cập nhật bảo mật thường không được thực hiện thường xuyên và không rõ ràng ai là người chịu trách nhiệm cập nhật.

Trái ngược với các công nghệ khác, trình duyệt web đang phát triển với tốc độ nhanh chóng do mức độ rủi ro cao mà người dùng phải đối mặt và tính phổ biến của chúng Các thành phần WebRTC được tích hợp sẵn trong trình duyệt, vì vậy chúng cũng được cập nhật khi trình duyệt được cập nhật Điều này cho phép các lỗ hổng bảo mật trong tương lai được khắc phục nhanh chóng, đặc biệt là trong chu kỳ phát triển nhanh chóng của các trình duyệt như Chrome và Firefox Trong thời đại cập nhật tự động, các thành phần WebRTC có thể được cập nhật thông qua phiên bản trình duyệt mới ngay sau khi bản vá được tạo sẵn, giúp đảm bảo an toàn cho người dùng.

1.3.2 Truy cập vào các tài nguyên Phương tiện / Địa phương

Trình duyệt có thể truy cập các tài nguyên cục bộ như máy ảnh, micrô và tệp, điều này gây ra mối lo ngại về quyền riêng tư khi các ứng dụng web có thể truy cập vào micrô và máy ảnh của người dùng Việc cho phép các ứng dụng web tự do truy cập vào máy ảnh hoặc micrô có thể dẫn đến việc một ứng dụng vô đạo đức ghi lại hoặc phân phối nguồn cấp dữ liệu video hoặc âm thanh mà người dùng không hề hay biết Điều này có thể trở thành một vấn đề nghiêm trọng nếu một trang web nằm trong tab nền lạm dụng lòng tin của người dùng mà họ không hề nhận ra.

WebRTC giải quyết vấn đề này bằng cách yêu cầu người dùng cấp quyền rõ ràng cho máy ảnh hoặc micrô được sử dụng, với khả năng định cấu hình riêng lẻ cho từng thiết bị Quyền truy cập có thể được yêu cầu một lần hoặc vĩnh viễn, đảm bảo ứng dụng WebRTC không thể tự ý sử dụng các thiết bị này Khi micrô hoặc máy ảnh đang hoạt động, giao diện người dùng ứng dụng khách phải hiển thị thông báo rõ ràng cho người dùng, chẳng hạn như dấu chấm đỏ trên tab truy cập phương tiện của người dùng trong trình duyệt Chrome.

Hình 1 1 Giao diện web RTC Security

1.3.3 Mã hóa phương tiện & Bảo mật giao tiếp

Ứng dụng giao tiếp thời gian thực có thể tiềm ẩn một số rủi ro bảo mật đáng kể Một trong những rủi ro đáng chú ý nhất là việc đánh chặn phương tiện hoặc dữ liệu không được mã hóa trong quá trình truyền, có thể xảy ra giữa giao tiếp trình duyệt-trình duyệt hoặc trình duyệt-máy chủ Tuy nhiên, việc mã hóa dữ liệu giúp ngăn chặn bên thứ ba nghe trộm, chỉ cho phép các bên có quyền truy cập vào khóa mã hóa bí mật mới có thể giải mã và truy cập vào nội dung của các luồng giao tiếp.

Mã hóa là một tính năng quan trọng của WebRTC, được áp dụng trên tất cả các thành phần, bao gồm cả cơ chế báo hiệu Điều này đảm bảo rằng tất cả các luồng phương tiện được gửi qua WebRTC đều được mã hóa an toàn bằng cách sử dụng các giao thức mã hóa nổi tiếng và được tiêu chuẩn hóa Cụ thể, các luồng dữ liệu được mã hóa bằng Datagram Transport Layer Security (DTLS), trong khi các luồng media được mã hóa bằng Secure Real-time Transport Protocol (SRTP), giúp bảo vệ thông tin truyền tải qua mạng.

Một trong những tác dụng phụ bất lợi của việc sử dụng ICE là người dùng có thể bị lộ địa chỉ IP, từ đó tiết lộ thông tin vị trí của họ Điều này có thể gây ra những hậu quả tiêu cực, đặc biệt là khi người dùng muốn giữ bí mật thông tin cá nhân của mình Việc đăng ký địa chỉ IP công khai với các cơ quan có thẩm quyền toàn cầu cũng làm tăng nguy cơ lộ thông tin, gây ra những rủi ro không mong muốn cho người dùng ngang hàng.

WebRTC không được thiết kế để bảo vệ người dùng khỏi các trang web độc hại muốn thu thập thông tin của họ Thông thường, các trang web này có thể dễ dàng thu thập địa chỉ IP của người dùng từ các giao dịch HTTP thông thường Do đó, việc ẩn địa chỉ IP khỏi máy chủ sẽ đòi hỏi một cơ chế bảo vệ quyền riêng tư rõ ràng trên máy khách, nằm ngoài phạm vi của báo cáo này.

Báo cáo TTTN Đại học CHƯƠNG 1: TÌM HIỂU VỀ WEBRTC SECURITY

WebRTC cung cấp một số cơ chế để cho phép ứng dụng web hợp tác với người dùng ẩn địa chỉ IP của người dùng khỏi phía bên kia của cuộc gọi, giúp tăng cường bảo mật và riêng tư cho người dùng trong quá trình thực hiện cuộc gọi.

- Việc triển khai WebRTC được yêu cầu để cung cấp cơ chế cho phép

JS ngăn chặn thương lượng ICE cho đến khi người dùng quyết định trả lời cuộc gọi, giúp người dùng cuối bảo vệ địa chỉ IP của mình khỏi người ngang hàng nếu họ chọn không trả lời Điều này cũng có tác dụng phụ là ẩn trạng thái trực tuyến của người dùng với đồng nghiệp của họ.

Một cơ chế khác cho phép ứng dụng gọi điện định cấu hình lại cuộc gọi hiện có để thêm các ứng cử viên không phải TURN, giúp đàm phán ICE bắt đầu ngay lập tức khi có thông báo cuộc gọi đến, giảm độ trễ đồng thời giữ bí mật địa chỉ IP của người dùng cho đến khi họ quyết định trả lời, từ đó cho phép người dùng ẩn hoàn toàn địa chỉ IP của họ trong suốt thời gian cuộc gọi.

SIP là một tiêu chuẩn phổ biến được sử dụng trong giao tiếp VoIP để thiết lập và quản lý các cuộc gọi điện thoại, nhưng nó có một số hạn chế về bảo mật Là một dẫn xuất của HTTP và SMTP, SIP dễ bị khai thác bởi các bên độc hại Khi sử dụng tin nhắn văn bản thuần túy để trao đổi thông tin, SIP tạo điều kiện cho các kẻ tấn công truy cập mạng và chụp các tin nhắn SIP, từ đó có thể đọc thông tin nhạy cảm của người dùng và giả mạo danh tính Hơn nữa, nếu kẻ tấn công tiếp tục truy cập vào mạng của nhà điều hành, chúng có thể giải mã nội dung của giao tiếp WebRTC, gây ra những rủi ro nghiêm trọng về bảo mật.

TÌM HIỂU VỀ CÁC CÔNG NGHỆ TRONG WEBRTC SECURITY

Tổng quan về kiến trúc WebRTC Security

WebRTC cho phép giao tiếp trực tiếp đa phương tiện giữa hai đồng nghiệp thông qua cấu trúc liên kết ngang hàng (P2P), hoạt động trực tiếp trong trình duyệt của người dùng mà không yêu cầu phần mềm bổ sung Để bắt đầu giao tiếp, các đồng nghiệp thực hiện trao đổi siêu dữ liệu, còn gọi là "báo hiệu", quy trình này giúp bắt đầu và quảng cáo các cuộc gọi đồng thời tạo điều kiện thiết lập kết nối giữa các bên không quen thuộc.

- Như được mô tả trong Hình 1, quá trình này xảy ra thông qua một máy chủ trung gian:

Hình 1 2 Cấu trúc liên kết cuộc gọi WebRTC đơn giản

Giao thức báo hiệu không được chỉ định trong WebRTC, cho phép các nhà phát triển tự do lựa chọn giao thức phù hợp với nhu cầu của họ Điều này mang lại mức độ linh hoạt cao hơn trong việc tùy chỉnh ứng dụng WebRTC cho từng trường hợp hoặc tình huống sử dụng cụ thể, giúp các nhà phát triển có thể tạo ra giải pháp phù hợp với nhu cầu của mình.

Cách giao tiếp của WebRTC Security

WebRTC dựa trên ba API chính, mỗi API thực hiện một chức năng cụ thể để cho phép giao tiếp thời gian thực trong một ứng dụng web, bao gồm việc đặt tên và giải thích ngắn gọn về từng API Việc thực hiện và chi tiết kỹ thuật của từng giao thức và công nghệ này sẽ không được đề cập chi tiết trong bài viết này, tuy nhiên, người dùng có thể tìm kiếm tài liệu liên quan trực tuyến để có thêm thông tin.

Báo cáo TTTN Đại học CHƯƠNG 2: TÌM HIỂU VỀ CÁC CÔNG NGHỆ

Trong nhiều năm, người dùng phải dựa vào các plugin trình duyệt của bên thứ ba như Flash hoặc Silverlight để thu âm thanh hoặc video từ máy tính Tuy nhiên, với sự ra đời của kỷ nguyên HTML 5, các thiết bị hiện đại đã có thể truy cập trực tiếp phần cứng, cung cấp các API JavaScript giao diện với các khả năng phần cứng cơ bản của hệ thống, mở ra khả năng mới cho việc thu âm thanh và video trực tiếp từ máy tính.

Get User Media là một API quan trọng, cho phép trình duyệt truy cập vào máy ảnh và micrô của người dùng, cung cấp một cách thức mới để tương tác trực tuyến Mặc dù thường được sử dụng trong các ứng dụng WebRTC, API này thực sự là một phần của HTML 5, mở rộng khả năng của trình duyệt web.

RTCPeerConnection là API đầu tiên trong số hai API chính được cung cấp bởi đặc tả WebRTC, đại diện cho kết nối WebRTC thực tế và đóng vai trò quan trọng trong việc xử lý luồng dữ liệu hiệu quả giữa hai đồng nghiệp.

Khi người gọi muốn bắt đầu kết nối với một bên từ xa, trình duyệt sẽ khởi tạo đối tượng RTCPeerConnection, bao gồm mô tả SDP tự tạo để trao đổi với đồng nghiệp của họ Người nhận sau đó sẽ trả lời bằng mô tả SDP của riêng mình, và các mô tả SDP này được sử dụng như một phần của quy trình làm việc ICE đầy đủ để truyền tải qua NAT.

RTCPeerConnection cho phép gửi dữ liệu âm thanh và video theo thời gian thực giữa các trình duyệt một cách hiệu quả, giúp truyền tải thông tin đa phương tiện một cách mượt mà và liền mạch.

RTCPeerConnection API đóng vai trò quan trọng trong việc quản lý toàn bộ vòng đời của mỗi kết nối ngang hàng, đồng thời gói gọn tất cả thiết lập, quản lý và trạng thái kết nối trong một giao diện dễ sử dụng, giúp đơn giản hóa quá trình thiết lập và quản lý kết nối.

- RTC Peer Connection có hai đặc điểm cụ thể:

 Giao tiếp ngang hàng trực tiếp giữa hai trình duyệt

Sử dụng UDP/IP cho phép giảm đáng kể chi phí, mặc dù không đảm bảo gói dữ liệu đến đích Tuy nhiên, điều này cho phép tập trung vào việc cung cấp giao tiếp theo thời gian thực, bằng cách chấp nhận mất một số dữ liệu Kết quả là, UDP/IP trở thành lựa chọn phù hợp cho các ứng dụng yêu cầu truyền dữ liệu nhanh chóng và ổn định.

RTCDataChannel là API chính thứ hai được cung cấp như một phần của WebRTC, đại diện cho kênh giao tiếp chính cho phép trao đổi dữ liệu ứng dụng tùy ý giữa các đồng nghiệp Thông qua RTCDataChannel, dữ liệu có thể được truyền trực tiếp từ máy ngang hàng này sang máy ngang hàng khác, cho phép giao tiếp trực tiếp và hiệu quả giữa các thiết bị.

Mặc dù có một số tùy chọn thay thế cho các kênh liên lạc, chẳng hạn như WebSocket và Sự kiện do máy chủ gửi, nhưng những lựa chọn này được thiết kế để giao tiếp với máy chủ hơn là một máy chủ ngang hàng được kết nối trực tiếp Tuy nhiên, RTCDataChannel tương tự như WebSocket phổ biến, nhưng cung cấp khả năng giao tiếp trực tiếp giữa các máy chủ ngang hàng.

TRONG WEBRTC SECURITY đó có định dạng ngang hàng đồng thời cung cấp các thuộc tính phân phối có thể tùy chỉnh của phương tiện truyền tải cơ bản.

Một số công nghệ trong WebRTC Security

Ba API là thành phần chính dành cho nhà phát triển của WebRTC, cung cấp các giao thức quan trọng như API RTCPeerConnection và RTCDataChannel, giúp xây dựng các ứng dụng thời gian thực trên nền tảng web.

ICE, STUN và TURN đóng vai trò quan trọng trong việc thiết lập và duy trì kết nối ngang hàng qua UDP, trong khi DTLS đảm bảo bảo mật cho tất cả các chuyển dữ liệu giữa các đồng nghiệp thông qua mã hóa Ngoài ra, SCTP và SRTP là các giao thức ứng dụng được sử dụng để ghép các luồng khác nhau, cung cấp khả năng tắc nghẽn và kiểm soát luồng, cũng như phân phối đáng tin cậy một phần và các dịch vụ bổ sung khác trên UDP.

Hình 1 3 Ngăn xếp giao thức WebRTC

2.3.1 SDP: Giao thức mô tả phiên

Giao thức mô tả phiên (SDP) là một tiêu chuẩn được sử dụng để mô tả các phiên đa phương tiện, bao gồm âm thanh, video, bảng trắng, fax, modem và các luồng khác Nó cung cấp một cách thức biểu diễn tiêu chuẩn để mô tả các khía cạnh khác nhau của phiên đa phương tiện, bao gồm khả năng truyền thông, địa chỉ truyền tải và siêu dữ liệu liên quan Điều này cho phép SDP hoạt động một cách linh hoạt và hiệu quả trong việc thông báo phiên, lời mời phiên và thương lượng tham số, đồng thời đảm bảo tính truyền tải bất khả tri.

SDP hiện đang được ứng dụng rộng rãi trong nhiều lĩnh vực công nghệ, bao gồm Giao thức khởi đầu phiên, Giao thức truyền tải thời gian thực và Giao thức truyền trực tuyến thời gian thực, đóng vai trò quan trọng trong việc thiết lập và quản lý các phiên truyền thông hiệu quả.

Hình dưới đây minh họa sự phân chia cấp cao của SDP thành các thành phần mô tả ngữ nghĩa của một phiên đa phương tiện, chẳng hạn như một phiên WebRTC Điều này cung cấp cái nhìn tổng quan cơ bản về SDP, giúp người dùng hiểu rõ hơn về cấu trúc của nó, mặc dù không thể bao quát toàn bộ thông tin chi tiết về SDP.

Báo cáo TTTN Đại học CHƯƠNG 2: TÌM HIỂU VỀ CÁC CÔNG NGHỆ

WEBRTC đề xuất sử dụng JavaScript để kiểm soát hoàn toàn khía cạnh tín hiệu của một phiên đa phương tiện, như được mô tả trong đặc tả JSEP Đặc tả JSEP cung cấp các cơ chế cần thiết để tạo thông tin đặc tính phiên và định nghĩa phương tiện, cho phép tiến hành phiên dựa trên trao đổi SDP một cách hiệu quả.

- Trong bối cảnh này, SDP phục vụ hai mục đích:

 Cung cấp cấu trúc ngữ pháp theo ngữ đoạn

 Truyền đạt một cách ngữ nghĩa ý định và khả năng của partipant.

2.3.2 ICE: Thiết lập Kết nối Tương tác

ICE (Interactive Connectivity Establishment) là một khuôn khổ quan trọng giúp thiết lập kết nối giữa các đồng nghiệp qua internet một cách hiệu quả Mặc dù công nghệ WebRTC cố gắng tận dụng các kết nối P2P trực tiếp để tăng cường trải nghiệm người dùng, nhưng thực tế cho thấy sự hiện diện rộng rãi của NAT (Network Address Translation) gây ra những khó khăn đáng kể trong việc đàm phán cách thức giao tiếp giữa các đồng nghiệp.

Do sự phổ biến liên tục của các địa chỉ IPv4 với khả năng đại diện hạn chế, hầu hết các thiết bị hỗ trợ mạng không có địa chỉ IPv4 công khai duy nhất Điều này dẫn đến việc sử dụng công nghệ NAT (Network Address Translation) để dịch động các địa chỉ riêng thành địa chỉ công khai khi có yêu cầu gửi đi Tuy nhiên, việc chia sẻ một IP riêng thường không đủ thông tin để thiết lập kết nối với một mạng ngang hàng Để giải quyết vấn đề này, giao thức ICE (Interactive Connectivity Establishment) được sử dụng để giao tiếp qua NAT và tìm ra con đường tốt nhất để kết nối các đồng nghiệp, đảm bảo định tuyến chính xác trên mạng nội bộ.

ICE hoạt động bằng cách thử song song tất cả các khả năng để chọn phương án hiệu quả nhất phù hợp Quá trình này bắt đầu bằng việc cố gắng tạo kết nối bằng địa chỉ máy chủ có được từ hệ điều hành và card mạng của thiết bị Nếu không thành công, thường xảy ra đối với các thiết bị sau NAT, ICE sẽ lấy địa chỉ bên ngoài bằng máy chủ STUN Trong trường hợp cả hai phương pháp trên đều không thành công, lưu lượng truy cập sẽ được định tuyến lại thông qua máy chủ chuyển tiếp TURN để đảm bảo kết nối thành công.

Các tuyến giao tiếp ứng viên được hiển thị ở định dạng dựa trên văn bản và danh sách được sắp xếp theo mức độ ưu tiên, bao gồm giao tiếp P2P trực tiếp, sử dụng STUN với ánh xạ cổng cho truyền qua NAT và sử dụng TURN làm trung gian.

- Trong số tất cả các ứng cử viên có thể, tuyến đường có chi phí nhỏ nhất được chọn.

2.3.3 STUN: Các tiện ích truyền tải phiên cho NAT

Để thiết lập giao tiếp P2P hiệu quả, cả hai bên cần phải có kiến thức về địa chỉ IP của đối tác ngang hàng và cổng UDP được chỉ định, điều này đòi hỏi một lượng trao đổi thông tin nhất định trước khi bắt đầu giao tiếp WebRTC.

Mỗi máy chủ STUN được sử dụng bởi mỗi máy ngang hàng để xác định địa chỉ IP công cộng của họ và được tham chiếu bởi khung ICE trong quá trình thiết lập kết nối Điều này cho phép các ứng dụng WebRTC xác định địa chỉ IP công cộng của mình một cách chính xác và đáng tin cậy Máy chủ STUN thường có thể truy cập công khai và có thể được sử dụng miễn phí bởi các ứng dụng WebRTC, giúp đơn giản hóa quá trình thiết lập kết nối và tăng cường hiệu suất của các ứng dụng này.

2.3.4 TURN: Traversal Sử dụng Rơle xung quanh NAT

Trong trường hợp thiết lập giao tiếp P2P không thành công, máy chủ TURN có thể cung cấp một tùy chọn dự phòng để đảm bảo giao tiếp WebRTC Máy chủ này hoạt động bằng cách chuyển tiếp lưu lượng truy cập giữa các đồng nghiệp, giúp duy trì kết nối, mặc dù có thể dẫn đến sự suy giảm về chất lượng phương tiện và độ trễ.

Máy chủ TURN giúp đảm bảo thành công cao trong việc thiết lập cuộc gọi, bất kể môi trường của người dùng cuối Tuy nhiên, khi dữ liệu được gửi qua máy chủ trung gian, băng thông của máy chủ cũng bị tiêu tốn đáng kể Đặc biệt, nếu nhiều cuộc gọi được định tuyến đồng thời qua máy chủ, băng thông sẽ tăng lên đáng kể, ảnh hưởng đến hiệu suất của hệ thống.

- Bản thân máy chủ thường không được truy cập miễn phí và phải được cung cấp (hoặc thuê) cụ thể bởi nhà cung cấp ứng dụng.

Báo cáo TTTN Đại học CHƯƠNG 3: CÁCH TRIỂN KHAI WEBRTC

SECURITY TRONG CÁC ỨNG DỤNG GỌI ĐIỆN

CÁCH TRIỂN KHAI WEBRTC SECURITY TRONG CÁC ỨNG DỤNG GỌI ĐIỆN

Giới thiệu

WebRTC có thể được triển khai trên Android theo hai cách: thông qua trình duyệt hoặc ứng dụng bản địa, với các ứng dụng gốc có thể nhúng trình duyệt bên trong Tuy nhiên, trên các phiên bản Android lên đến 4.3, WebView không hỗ trợ WebRTC, nhưng các khuôn khổ như PhoneGap (Mozilla Cordova) cho phép giao tiếp WebRTC trên nền tảng ứng dụng kết hợp web-di động Ngoài ra, có thể tích hợp mã WebRTC từ trình duyệt nguồn như Chromium hoặc Firefox vào ứng dụng gốc, nhưng điều này thường đòi hỏi đặc quyền root để truy cập một số tính năng nhất định.

WebRTC cho phép trao đổi phương tiện theo thời gian thực, ngang hàng, giữa hai thiết bị, tạo điều kiện cho các ứng dụng thời gian thực như gọi điện video Để thiết lập kết nối, một quá trình khám phá và thương lượng được gọi là báo hiệu sẽ được thực hiện Với hướng dẫn này, bạn sẽ có thể xây dựng một cuộc gọi điện video hai chiều hiệu quả và dễ dàng tích hợp vào các ứng dụng của mình.

WebRTC là một công nghệ ngang hàng cho phép trao đổi âm thanh, video và dữ liệu trong thời gian thực mà không cần đến máy chủ trung tâm Để thực hiện điều này, hai thiết bị trên các mạng khác nhau cần phải thực hiện một quá trình khám phá và thương lượng định dạng phương tiện để xác định vị trí của nhau.

Quá trình kết nối giữa hai thiết bị được gọi là báo hiệu, trong đó cả hai thiết bị cần kết nối với một máy chủ thứ ba đã được đồng thuận bởi các bên tham gia Thông qua máy chủ này, hai thiết bị có thể xác định vị trí của nhau và trao đổi thông điệp đàm phán để thiết lập kết nối.

Báo hiệu bằng Máy chủ tín hiệu

Việc thiết lập kết nối WebRTC giữa hai thiết bị yêu cầu sử dụng máy chủ báo hiệu để giải quyết cách kết nối chúng qua internet một cách an toàn và hiệu quả Máy chủ báo hiệu đóng vai trò trung gian quan trọng, cho phép hai thiết bị tìm và thiết lập kết nối đồng thời, đồng thời giảm thiểu việc để lộ thông tin cá nhân tiềm ẩn, đảm bảo sự riêng tư và bảo mật cho người dùng.

- Đầu tiên, chúng ta cần chính máy chủ báo hiệu WebRTC không chỉ định cơ chế vận chuyển cho thông tin báo hiệu

Để trao đổi thông tin tín hiệu giữa hai đồng nghiệp, bạn có thể lựa chọn nhiều phương pháp khác nhau, bao gồm WebSocket, XMLHttpRequest hoặc thậm chí là các phương pháp độc đáo như chim bồ câu vận chuyển, tùy thuộc vào nhu cầu và mục tiêu cụ thể của dự án.

Điều quan trọng cần lưu ý là máy chủ không cần hiểu hoặc diễn giải nội dung dữ liệu báo hiệu, ngay cả khi đó là SDP, vì nội dung của thông báo đi qua máy chủ báo hiệu thực sự là một hộp đen.

Khi hệ thống con ICE yêu cầu bạn gửi dữ liệu báo hiệu đến máy ngang hàng khác, điều quan trọng là bạn phải thực hiện theo hướng dẫn đó Máy ngang hàng nhận dữ liệu sẽ tự động xử lý và chuyển thông tin đến hệ thống con ICE của chính nó Trong quá trình này, máy chủ báo hiệu không cần quan tâm đến nội dung của thông tin, mà chỉ đơn giản là chuyển thông tin qua lại giữa các hệ thống.

Giao thức mô tả phiên

Cơ chế báo hiệu là một phần quan trọng trong việc xây dựng ứng dụng WebRTC, nhưng nó không được chỉ định rõ ràng bởi WebRTC Thay vào đó, các nhà phát triển phải tự xây dựng cơ chế báo hiệu này, mặc dù điều này có vẻ phức tạp Tuy nhiên, có nhiều giải pháp thay thế có sẵn, và trong loạt bài này, chúng tôi sẽ sử dụng Socket.IO để báo hiệu.

WebRTC chỉ yêu cầu trao đổi siêu dữ liệu phương tiện giữa các đồng nghiệp dưới dạng đề nghị và câu trả lời, được thông báo trong Giao thức mô tả phiên (SDP) định dạng.

Hình 1.4 Giao thức mô tả phiên (SDP)

Nếu bạn đang tự hỏi ý nghĩa của mỗi dòng trong định dạng trên, đừng lo lắng vì WebRTC tự động tạo ra chúng dựa trên thiết bị âm thanh và video có sẵn trên máy tính xách tay hoặc PC của bạn.

Ứng viên ICE

Tương tự như việc trao đổi thông tin về phương tiện truyền thông, các đồng nghiệp phải trao đổi thông tin về kết nối mạng để thiết lập kết nối thành công Quá trình này được gọi là ứng cử viên ICE, trong đó nêu chi tiết các phương pháp khả dụng mà đồng nghiệp có thể giao tiếp với nhau, bao gồm cả việc giao tiếp trực tiếp hoặc thông qua máy chủ TURN.

Thông thường, mỗi người ngang hàng sẽ đề xuất những ứng viên tốt nhất của mình trước tiên, khiến họ ưu tiên những lựa chọn hàng đầu và sau đó mới xem xét những ứng viên kém hơn của họ.

Lý tưởng nhất, các ứng cử viên nên sử dụng giao thức UDP vì tốc độ truyền tải nhanh hơn và các luồng phương tiện có thể phục hồi sau sự gián đoạn một cách dễ dàng Tuy nhiên, tiêu chuẩn ICE cũng cho phép sử dụng các ứng cử viên giao thức TCP.

CHẠY & BẬT

A Session Traversal Utilities for NAT (STUN) server is a type of network protocol that enables devices behind a Network Address Translator (NAT) to determine their public IP address, port, and connection status.

Máy chủ STUN đóng vai trò quan trọng trong việc cung cấp một không gian họp trung gian cho các máy tính để trao đổi thông tin liên lạc cần thiết Sau khi thông tin được trao đổi thành công, một kết nối trực tiếp sẽ được thiết lập giữa các máy tính ngang hàng, giúp đảm bảo tính ổn định và bảo mật cho cuộc hội thoại Khi kết nối được thiết lập, máy chủ STUN sẽ không còn tham gia vào phần còn lại của cuộc hội thoại, giúp giảm thiểu tải và tăng hiệu suất cho hệ thống.

Các kết nối được thiết lập thông qua máy chủ STUN là giải pháp lý tưởng và tiết kiệm chi phí nhất cho giao tiếp WebRTC, giúp người dùng giảm thiểu chi phí vận hành và tận hưởng trải nghiệm mượt mà.

- Rất tiếc, kết nối có thể không thiết lập được đối với một số người dùng do loại thiết bị NAT mà mỗi người ngang hàng đang sử dụng.

- Trong trường hợp như vậy, giao thức ICE yêu cầu bạn cung cấp dự phòng, là một loại máy chủ báo hiệu khác được gọi là máy chủ TURN.

- Máy chủ TURN (Traversal using Relays quanh NAT): một giao thức cho phép các thiết bị nhận và gửi dữ liệu từ phía sau NAT hoặc tường lửa.

- Máy chủ TURN là một phần mở rộng của máy chủ STUN Điểm khác biệt so với người tiền nhiệm là nó xử lý toàn bộ phiên giao tiếp.

Về cơ bản, sau khi thiết lập kết nối giữa các đồng đẳng, nó nhận các luồng từ một đồng đẳng và chuyển tiếp nó đến một đồng đẳng khác, và ngược lại, tạo thành một quy trình trao đổi thông tin liên tục và hiệu quả.

- Loại giao tiếp này đắt hơn và máy chủ phải trả tiền cho việc xử lý và tải băng thông cần thiết để vận hành một máy chủ TURN.

Kết nối ngang hàng

- Giao diện RTCPeerConnection đại diện cho một kết nối WebRTC giữa máy tính cục bộ và một máy ngang hàng từ xa

Nó cung cấp các phương pháp để kết nối với một đồng đẳng từ xa, giúp duy trì và giám sát kết nối một cách hiệu quả Ngoài ra, nó còn cho phép đóng kết nối khi không còn cần thiết nữa, giúp tối ưu hóa tài nguyên và đảm bảo an toàn cho hệ thống.

Hình 1.5 Mô tả kết nối ngang hang

SECURITY TRONG CÁC ỨNG DỤNG GỌI ĐIỆN 3.6.1 Quy trình tích hợp

- Bước 1: Trao đổi mô tả phiên

Khi bắt đầu quá trình báo hiệu, người dùng bắt đầu cuộc gọi tạo ra một đề nghị bao gồm mô tả phiên ở định dạng SDP Đề nghị này cần được gửi đến người dùng nhận, người phụ trách, để bắt đầu quá trình thiết lập cuộc gọi Người gọi sau đó trả lời đề nghị bằng tin nhắn trả lời, cũng chứa mô tả SDP, giúp hoàn thiện quá trình báo hiệu và thiết lập kết nối giữa hai bên.

Máy chủ báo hiệu của chúng tôi được thiết kế để tận dụng WebSocket, cho phép truyền tải thông điệp một cách liền mạch và hiệu quả Cụ thể, hệ thống sẽ sử dụng WebSocket để gửi các tin nhắn chào hàng có loại "video-offer" và trả lời các tin nhắn có loại "video-answer", đảm bảo quá trình giao tiếp diễn ra nhanh chóng và chính xác.

Hình 1.6 Sơ đồ video-offer và video-answer

- Bước 2: Trao đổi ứng viên ICE

Các đồng nghiệp cần trao đổi các ứng viên ICE để thương lượng về mối liên hệ thực tế giữa họ Mỗi ứng cử viên ICE mô tả một phương pháp mà người gửi ngang hàng có thể sử dụng để giao tiếp, giúp thiết lập kết nối hiệu quả Quá trình trao đổi ứng viên diễn ra theo thứ tự mà chúng được phát hiện, và người ngang hàng tiếp tục gửi ứng viên cho đến khi hết đề xuất, ngay cả khi phương tiện đã bắt đầu phát trực tuyến.

 Sự kiện icecandidate được gửi tới RTCPeerConnection để hoàn tất quá trình thêm mô tả cục bộ bằng cách sử dụng pc.setLocalDescription (ưu đãi).

Khi hai đồng nghiệp đã đồng ý về một ứng viên tương thích lẫn nhau, họ sẽ sử dụng SDP của ứng viên đó để xây dựng và mở một kết nối, cho phép phương tiện truyền thông bắt đầu lưu chuyển Trong trường hợp họ tìm thấy một ứng cử viên tốt hơn, thường là có hiệu suất cao hơn, luồng có thể thay đổi định dạng nếu cần thiết, đảm bảo quá trình truyền thông diễn ra hiệu quả và linh hoạt.

Mặc dù hiện không được hỗ trợ, một ứng cử viên nhận được sau khi phương tiện đã được truyền về mặt lý thuyết cũng có thể được sử dụng để hạ cấp xuống kết nối băng thông thấp hơn nếu cần, giúp tăng tính linh hoạt và khả năng thích ứng trong các tình huống khác nhau.

Mỗi ứng cử viên ICE được gửi đến ứng viên ngang hàng khác bằng cách gửi một thông báo JSON thuộc loại “ứng cử viên mới” qua máy chủ báo hiệu tới ứng viên ngang hàng từ xa, cho phép thực hiện quy trình trao đổi thông tin cần thiết để thiết lập kết nối.

Hình 1.7 Sơ đồ trao đổi ICE

Hàm Constraints () có thể được gọi khi người dùng nhấp vào một người dùng khác mà họ đang cố gắng kết nối cho danh sách người dùng mà họ có Hàm này cho phép kiểm soát và quản lý các kết nối giữa người dùng, giúp đảm bảo rằng các tương tác giữa họ tuân thủ các quy tắc và giới hạn đã thiết lập.

3.6.3 Tạo kết nối ngang hàng

Hàm createPeerConnection() đóng vai trò quan trọng trong việc thiết lập kết nối WebRTC, được cả người gọi và người nhận sử dụng để xây dựng các đối tượng RTCPeerConnection tương ứng Khi người gọi muốn bắt đầu cuộc gọi, hàm này được gọi thông qua invite(), trong khi người nhận sẽ sử dụng handleVideoOfferMsg() để xử lý tin nhắn đề nghị từ người gọi, giúp thiết lập kết nối WebRTC hiệu quả.

Hình 1.9 Hàm kết nối ngang hàng

Khi người gọi đã tạo RTCPeerConnection, tạo luồng phương tiện và thêm các bản nhạc của nó vào kết nối, trình duyệt sẽ gửi một sự kiện cần thương lượng đến RTCPeerConnection, cho biết rằng nó đã sẵn sàng để bắt đầu thương lượng với người ngang hàng khác, đánh dấu bước đầu tiên trong quá trình thiết lập kết nối giữa hai điểm cuối.

Hình 1.10 Hàm xử lý sự kiện cần thương lượng

Để bắt đầu quá trình thương lượng, chúng tôi cần tạo và gửi một đề nghị SDP (Session Description Protocol) cho đồng nghiệp mà chúng tôi muốn kết nối Đề nghị SDP này bao gồm danh sách các cấu hình được hỗ trợ cho kết nối, bao gồm thông tin về luồng phương tiện mà chúng tôi đã thêm vào kết nối cục bộ, chẳng hạn như video chúng tôi muốn gửi đến đầu kia của cuộc gọi, cũng như bất kỳ ứng viên ICE nào đã thu thập được bởi lớp ICE.

Khi chúng tôi bắt đầu thương lượng với các đối tác khác và gửi một lời đề nghị, hãy cùng xem những gì xảy ra ở phía callee của kết nối Callee nhận ưu đãi và gọi hàm handleVideoOfferMsg() để xử lý nó, từ đó bắt đầu quá trình xử lý thông báo "video-offer" quan trọng trong kết nối.

Khi nhận được lời đề nghị mua hàng, hàm handleVideoOfferMsg() của người nhận cuộc gọi được kích hoạt với thông báo "video-offer" Chức năng này thực hiện hai nhiệm vụ chính: tạo RTCPeerConnection riêng và thêm các bản nhạc chứa âm thanh và video từ micrô và webcam, đồng thời xử lý lời đề nghị đã nhận, xây dựng và gửi câu trả lời tương ứng.

Hình 1.11 Hàm nhận cuộc gọi đến

Mã này tương tự như những gì chúng ta đã thực hiện trong hàm mời () trong Bắt đầu cuộc gọi Nó bắt đầu bằng cách tạo và cấu hình một RTCPeerConnection bằng cách sử dụng hàm createPeerConnection () của chúng tôi, sau đó lấy phiếu mua hàng SDP từ thông báo "video-offer" đã nhận và sử dụng nó để tạo đối tượng RTCSessionDescription mới đại diện cho mô tả phiên của người gọi.

Quá trình thương lượng ICE liên quan đến việc trao đổi ứng cử viên giữa các peer, lặp đi lặp lại, cho đến khi tìm được cách hỗ trợ nhu cầu vận chuyển phương tiện của RTCPeerConnection Vì ICE không có kiến thức về máy chủ báo hiệu, nên mã của bạn sẽ xử lý việc truyền từng ứng viên trong trình xử lý sự kiện icecandidate.

TRIỂN KHAI XÂY DỰNG ỨNG DỤNG GỌI ĐIỆN BẢO MẬT THÔNG TIN DỰA TRÊN WEBRTC SECURITY

Sơ đồ triển khai

Chạy thử chương trình

GỌI ĐIỆN BẢO MẬT DỰA TRÊN WEBRTC

Hình 2 2 Nhập tên phía client A

Báo cáo TTTN Đại học CHƯƠNG 4: TRIỂN KHAI XÂY DỰNG ỨNG DỤNG

Hình 2 3 Nhập tên phía client 2

Hình 2 4 Màn hình giao diện các user phía client 1

Hình 2 5 Tiến hành gọi thoại

Hình 2 6 Màn hình gọi thoại

Hình 2 7 Màn hình đang gọi phía client B

Hình 2 8 Khi đang nghe máy

Hình 2 9 Màn hình thu nhỏ

Hình 2 12 Nhận cuộc gọi2.3 Phân tích gói tin

- Tiến hành bắt gói tin trao đổi giữa 2 client

Hình 2 7 Phân tích gói tin bằng wireshark

- Các gói tin được gửi đi và nhận giữa 2 máy client

Hình 2 8 Hai client trao đổi với nhau

- Khi tiến hành gọi điện, 2 client trao đổi với nhau qua giao thức UDP

Hình 2 9 Tiến hành kết nối (gọi điện)

- Các thông tin được gửi đi hoặc nhận lại đều được mã hóa

Hình 2 10 Thông tin được mã hóa qua giao thức UDP 2.4 Phân tích lập trình

Hình 2 13 Thực hiện cuộc gọi

Hình 2 16 Thực hiện cuộc gọi video

Hình 2 17 Nhận được cuộc gọi video

Hình 2 20 Nhận danh sách người dùng

Hình 2 25 Chỉnh Camera trước và sau

Hình 2 26 Chuyển chế độ gọi thoại và mở cửa sổ nhỏ

DANH MỤC TÀI LIỆU THAM KHẢO

Danh mục các Website tham khảo:

1 https://www.mirrorfly.com/blog/create-audio-video-call-application-using-webrtc- javascript/

2 https://www.researchgate.net/publication/289406856_The_Security_of_WebRTC

3 https://webrtc-security.github.io/#ref.4

4 https://help.aircall.io/en/articles/4057043-the-security-of-webrtc-aircall

6 https://github.com/ddssingsong/webrtc_server_node

7 https://github.com/ddssingsong/webrtc_server_java

9 https://github.com/LingyuCoder/SkyRTC

NHẬN XÉT QUÁ TRÌNH THỰC TÂŠP CỦA SINH VIÊN

Họ và tên sinh viên : Nguyễn Nhật Thái Lớp : D19CQAT01-N Nơi thực tập : Công ty TNHH Khải Hoàn Holdings

Họ tên người nhận xét :

Xếp loại (đánh dấu vào ô được chọn)

I Tính kỷ luật và tư chất

I.5 Giao tiếp và ứng xử

II Khả năng chuyên môn

II.2 Kỹ năng thực hành

II.3 Năng lực ngoại ngữ

II.4 Kỹ năng làm việc nhóm

III Kết quả thực hiện đề tài được giao

I.1 Thực hiện yêu cầu về nội dung

I.2 Thực hiện yêu cầu về tiến độ

IV Nhận xét khác và lời khuyên cho sinh viên:

V Điểm tổng kết thực tâ Šp tốt nghiê Šp (thang điểm 10): ………

Tiêu đề	Xây Dựng Ứng Dụng Gọi Điện Bảo Mật Thông Tin Dựa Trên WebRTC Security
Tác giả	Nguyễn Nhật Thái
Người hướng dẫn	Phan Thanh Hy
Trường học	Học Viện Công Nghệ Bưu Chính Viễn Thông
Thể loại	Báo Cáo Thực Tập Tốt Nghiệp Đại Học
Năm xuất bản	2023
Thành phố	TP. HCM

Định dạng
Số trang	53
Dung lượng	8,67 MB