Để đánh giá bảo mật cuộc gọi, đừng chỉ hỏi “có mã hóa không?”; hãy hỏi mã hóa kết thúc ở đâu và việc ghi cuộc gọi thay đổi điều gì.
Việc mã hóa nội dung trò chuyện không tự nó chứng minh rằng âm thanh, hình ảnh, tính năng chia sẻ màn hình hay bản ghi cuộc gọi cũng được bảo vệ tương tự. Để đánh giá một cuộc gọi, cần hỏi dữ liệu âm thanh và hình ảnh được giữ ở dạng mã hóa đến đâu, ai nắm giữ khóa, và việc bật các tính năng như ghi cuộc gọi sẽ thay đổi điều gì.
Hướng dẫn này chia các tuyên bố về bảo mật thành những lớp có thể kiểm tra; tên giao thức hay biểu tượng ổ khóa không thay thế được câu trả lời cho những câu hỏi đó.
Ba luồng khác nhau trong cùng một ứng dụng
| Luồng | Ví dụ về dữ liệu | Câu hỏi về bảo mật |
|---|---|---|
| Tin nhắn được lưu trữ | Văn bản, ảnh, tệp và tin nhắn thoại | Ai có thể đọc các bản sao trên thiết bị, máy chủ và trong bản sao lưu? |
| Dữ liệu âm thanh, hình ảnh trực tiếp | Âm thanh từ micrô, video và nội dung chia sẻ màn hình | Mã hóa kết thúc trên thiết bị của người đối thoại hay tại một máy chủ trung gian? |
| Báo hiệu | Lời mời tham gia cuộc gọi, phản hồi và thông tin điều phối kết nối | Ai có thể thay đổi thông điệp điều khiển hoặc danh tính bên nhận? |
Tin nhắn thoại gửi trong cuộc trò chuyện là một tệp; cuộc gọi thoại là một luồng dữ liệu trực tiếp. Một sản phẩm có thể dùng các khóa và cơ chế khác nhau cho hai loại này. Chất lượng âm thanh tốt hay việc tin nhắn văn bản không đến nơi cũng không tự nó cho biết điều gì về mức độ bảo mật của luồng còn lại.
DTLS-SRTP cho biết điều gì?
Trong WebRTC, SRTP bảo vệ luồng dữ liệu âm thanh, hình ảnh, còn DTLS-SRTP là một cách thiết lập vật liệu khóa cần thiết. RFC 5764 giải thích cơ chế DTLS-SRTP, còn RFC 3711 giải thích cách bảo vệ các gói dữ liệu âm thanh, hình ảnh.
Tuy nhiên, chỉ nói “chúng tôi sử dụng WebRTC” không trả lời được câu hỏi liệu máy chủ hội nghị có giải mã dữ liệu âm thanh, hình ảnh hay không. Cần xác định rõ các điểm kết thúc mã hóa và cách xác thực chúng. Kết nối giữa người dùng và máy chủ có thể được mã hóa, nhưng máy chủ vẫn có quyền truy cập nội dung đã giải mã để xử lý hoặc ghi lại. Điều này không giống với E2EE giữa những người tham gia.
Kiến trúc bảo mật WebRTC trong RFC 8827 cũng cho thấy rằng, bên cạnh việc bảo vệ dữ liệu âm thanh và hình ảnh, sự tin cậy đối với ứng dụng web, luồng báo hiệu và danh tính người đối thoại đều quan trọng. Các gói dữ liệu được mã hóa không có nghĩa là mọi thành phần của sản phẩm đều đáng tin cậy.
Vì sao cần đánh giá riêng luồng báo hiệu?
Báo hiệu điều phối việc ai gọi cho ai và kết nối được thiết lập như thế nào. Nếu một ứng dụng bảo vệ các thông điệp điều khiển, vẫn cần kiểm tra cách sự bảo vệ đó gắn với danh tính thực của người tham gia và các khóa mã hóa dữ liệu âm thanh, hình ảnh.
Ba câu hỏi là đủ để định hướng việc đọc tài liệu:
- Lời mời, phản hồi và thông tin khóa có được bảo vệ khỏi việc sửa đổi không?
- Người dùng làm sao biết khóa thuộc về đúng người mình muốn liên lạc?
- Cảnh báo nào được hiển thị khi khóa hoặc thiết bị thay đổi?
Thông tin định tuyến, thời gian và những người tham gia cuộc gọi vẫn có thể được dịch vụ biết đến, ngay cả khi cuộc gọi sử dụng E2EE. Phần giải thích về siêu dữ liệu của ứng dụng nhắn tin đề cập đến sự khác biệt này.
Ghi cuộc gọi tạo ra một ranh giới bảo mật mới
“Cuộc gọi được mã hóa” không cung cấp câu trả lời đầy đủ về bản ghi. Một người tham gia có thể ghi âm hoặc ghi hình bằng thiết bị của mình. Việc ghi trên máy chủ cũng cần được mô tả riêng trong tài liệu: máy chủ có truy cập dữ liệu âm thanh, hình ảnh ở dạng rõ để ghi lại không? Ai lưu giữ tệp? Khi nào tệp được xóa?
Nếu bật tính năng ghi làm thay đổi chế độ bảo mật, người tham gia phải được thấy rõ sự thay đổi đó. Trước một cuộc trao đổi nhạy cảm, hãy kiểm tra trạng thái ghi và sự đồng ý của mọi người; việc chỉ báo ghi tích hợp đang tắt không bảo đảm rằng không ai ghi lại bằng thiết bị khác.
Nên đọc tài liệu hiện hành của Livara như thế nào?
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à E2EE, nhưng coi tính năng ghi tùy chọn trên máy chủ là một ngoại lệ: trong chế độ REC có hiển thị rõ, cơ chế bảo vệ cuộc gọi chuyển sang mã hóa truyền tải. Đây là tuyên bố trong tài liệu sản phẩm, không phải kết quả kiểm thử hay kiểm toán độc lập của bài viết này.
Việc giới hạn tất cả cuộc gọi nhóm ở “2 đến 6 người trên Android” trong văn bản cũ không phù hợp với tài liệu hiện hành và không được dùng làm cơ sở cho hướng dẫn này. Với số lượng người tham gia được hỗ trợ, nền tảng và phiên bản cần dùng, phải xem hướng dẫn hiện hành và hành vi thực tế của ứng dụng; bài viết này không cung cấp kết quả kiểm thử sức chứa cuộc gọi.
Tương tự, tên các thuật toán dùng cho trò chuyện như ML-KEM không tự nó chứng minh rằng cùng thuật toán đó cũng được dùng cho dữ liệu âm thanh, hình ảnh của cuộc gọi. Tuyên bố về khả năng bảo vệ hậu lượng tử của cuộc gọi đòi hỏi bằng chứng riêng cho luồng dữ liệu âm thanh, hình ảnh và cơ chế xác thực. Hãy đọc mô hình mối đe dọa của Livara cùng với trang tính năng, thay vì coi đó là sự thay thế cho kiểm thử độc lập.
Danh sách kiểm tra ngắn trước khi so sánh hai dịch vụ
Với mỗi câu trả lời “có”, hãy ghi cả phiên bản và nguồn:
- Cuộc gọi hai người, cuộc gọi nhóm và chia sẻ màn hình có được mô tả riêng không?
- Có nêu rõ máy chủ chỉ chuyển tiếp gói dữ liệu hay còn có thể giải mã dữ liệu âm thanh, hình ảnh không?
- Có thể xác minh danh tính và khóa của người tham gia không?
- Việc đổi thiết bị, thêm người tham gia và bật tính năng ghi có được thể hiện rõ không?
- Luồng cuộc gọi trên web và trong ứng dụng có giống nhau hay có điểm khác biệt?
- Việc lưu giữ tệp ghi và siêu dữ liệu có được giải thích không?
- Bằng chứng kiểm thử hoặc kiểm toán có áp dụng cho đúng phiên bản và tính năng đó không?
Nếu tài liệu không có câu trả lời, hãy ghi “chưa rõ”; việc thiếu câu trả lời không chứng minh tính an toàn, cũng không chứng minh có hành vi nghe lén.
Câu hỏi thường gặp
Cuộc gọi E2EE có ngăn người đối thoại ghi lại không?
Không. Người nhận được phép có quyền truy cập nội dung ở dạng rõ và có thể ghi lại bằng phần mềm hoặc một thiết bị khác.
Mã hóa truyền tải có phải là không tốt không?
Mã hóa truyền tải cung cấp sự bảo vệ quan trọng trước việc nghe lén trên đường truyền. Điểm khác biệt là dịch vụ đóng vai trò điểm cuối có thể truy cập nội dung đã giải mã; không nên gọi điều đó là E2EE giữa những người dùng.
Sử dụng mã hóa hậu lượng tử trong trò chuyện có khiến cuộc gọi cũng được bảo vệ hậu lượng tử không?
Không. Tuyên bố phải áp dụng cho đúng lớp, thuật toán và phiên bản triển khai. Hãy đánh giá trò chuyện và cuộc gọi riêng biệt.
