Một cuộc gọi an toàn có nhiều hơn một đường dữ liệu. Báo hiệu phối hợp ai đang gọi và cách các điểm cuối kết nối; đường truyền đa phương tiện mang âm thanh và video. Bảo vệ một đường không tự động bảo vệ đường kia, và không đường nào riêng lẻ che giấu mọi mẫu liên lạc.
WebRTC cung cấp các cơ chế bảo mật quan trọng, nhưng việc kiểm tra danh tính của ứng dụng, vai trò máy chủ và chế độ ghi âm vẫn quyết định toàn bộ ranh giới riêng tư.
Báo hiệu và đa phương tiện có nhiệm vụ khác nhau
| Lớp | Mục đích điển hình | Câu hỏi bảo mật |
|---|---|---|
| Báo hiệu | Lời mời, mô tả phiên và các ứng viên kết nối | Ai có thể đọc hoặc sửa thông tin thiết lập, và đối tác mong muốn được xác thực như thế nào? |
| Đa phương tiện | Âm thanh, video và các luồng thời gian thực liên quan | Mã hóa kết thúc ở đâu, và điểm cuối nào có thể truy cập nội dung đa phương tiện? |
| Bản ghi vận hành | Định tuyến, thời điểm kết nối và trạng thái chuyển phát | Dịch vụ hoặc mạng có thể quan sát siêu dữ liệu nào? |
| Ghi âm, ghi hình | Tạo bản sao được lưu giữ | Ai nhận bản rõ hoặc khóa bản ghi có thể sử dụng, và bản sao được lưu ở đâu? |
Giao thức nhắn tin có thể mang báo hiệu mã hóa, nhưng WebRTC không bắt buộc mọi triển khai dùng định dạng phong bì của một ứng dụng nhắn tin cụ thể. Những thiết kế có xác thực khác cũng khả thi.
DTLS-SRTP cung cấp điều gì
Kiến trúc bảo mật WebRTC, RFC 8827, yêu cầu bảo vệ các kênh đa phương tiện và mô tả việc thiết lập khóa DTLS-SRTP. Nói đơn giản, DTLS giúp thiết lập ngữ cảnh mật mã, còn SRTP bảo vệ các gói đa phương tiện thời gian thực.
Các điểm cuối của sự bảo vệ đó rất quan trọng. Kết nối mã hóa trực tiếp giữa những người tham gia khác với kết nối kết thúc tại máy chủ xử lý đa phương tiện. Một số hệ thống nhiều người bổ sung một lớp đầu cuối riêng bên trên mã hóa truyền tải hướng tới máy chủ. Chỉ từ “WebRTC” không cho biết sản phẩm dùng kiến trúc nào.
Vì sao xác thực báo hiệu quan trọng
Quá trình thiết lập cuộc gọi có thể chứa thông tin dùng để ràng buộc kết nối đa phương tiện với bên mong muốn. Nếu kẻ tấn công có thể thay thế thông tin đó mà không bị phát hiện, mã hóa có thể thiết lập một kết nối được bảo vệ tới sai điểm cuối.
RFC 8827 thảo luận mối quan hệ này giữa báo hiệu, danh tính và dấu vân tay DTLS. HTTPS bảo vệ kết nối tới dịch vụ báo hiệu; tự nó không loại bỏ nhu cầu xem xét dịch vụ độc hại hoặc bị xâm phạm. Báo hiệu được xác thực đầu cuối hoặc cơ chế xác minh đối tác độc lập thích hợp có thể củng cố ranh giới đó.
Tính bí mật của báo hiệu là mục tiêu liên quan nhưng khác biệt: nó giới hạn ai có thể đọc chi tiết thiết lập. Thiết kế cần giải thích cả tính bí mật lẫn xác thực thay vì xem một khối dữ liệu mã hóa là bằng chứng đủ cho cả hai.
Báo hiệu mã hóa không khiến cuộc gọi trở nên vô hình
Bộ chuyển tiếp vẫn có thể biết nó định tuyến giữa những tài khoản hay thiết bị nào. Người quan sát mạng có thể thấy thời điểm kết nối, lượng lưu lượng và địa chỉ máy chủ. Tùy thiết kế kết nối, đối tác hoặc hạ tầng chuyển tiếp cũng có thể biết thông tin mạng.
Vì vậy, mã hóa lời mời cuộc gọi không chứng minh rằng dịch vụ không thể suy ra có cuộc gọi, lập bản đồ quan hệ hoặc lưu giữ bản ghi liên quan đến cuộc gọi. Che giấu nội dung và che giấu mẫu lưu lượng là hai vấn đề riêng.
Ranh giới Livara công bố
Trang bảo mật của Livara mô tả cuộc gọi trực tiếp và cuộc gọi nhóm là được mã hóa đầu cuối, nhưng nêu ngoại lệ rõ ràng cho tính năng ghi âm, ghi hình tùy chọn trên máy chủ: khi trạng thái REC hiển thị đang hoạt động, cuộc gọi dùng mã hóa truyền tải thay vì E2EE.
Mô hình mối đe dọa của dịch vụ cũng bác bỏ các tuyên bố về ẩn danh siêu dữ liệu và bảo vệ trước thiết bị bị xâm phạm. Đây là tuyên bố của sản phẩm, không phải sự xác minh độc lập mọi đường cuộc gọi. Hướng dẫn này không khẳng định giới hạn người tham gia chưa được xác minh, định dạng báo hiệu hay triển khai đa phương tiện hậu lượng tử.
Cụ thể, trao đổi khóa hậu lượng tử trong ứng dụng nhắn tin không tự động nâng cấp một quá trình bắt tay đa phương tiện WebRTC riêng. Cần đánh giá độc lập thuật toán và sự ràng buộc khóa trên đường đa phương tiện.
Trước một cuộc gọi nhạy cảm
- Xác nhận người tham gia và xem xét những thay đổi danh tính bất ngờ.
- Kiểm tra tính năng ghi âm, ghi hình có được bật không và ứng dụng cho biết điều đó thay đổi những gì.
- Hiểu liệu dịch vụ xử lý nội dung đa phương tiện hay chỉ chuyển tiếp các gói được bảo vệ.
- Cân nhắc thiết bị và không gian quanh người tham gia: phần mềm độc hại, chụp hoặc quay màn hình hay người nghe ở gần có thể làm lộ nội dung sau giải mã.
- Yêu cầu kiến trúc và bằng chứng thử nghiệm cho đúng chế độ bạn dùng, thay vì dựa vào nhãn “cuộc gọi mã hóa” chung chung.
Tuyên bố bảo mật hữu ích chỉ rõ riêng ai có thể truy cập báo hiệu, nội dung đa phương tiện, siêu dữ liệu và bản ghi.
