E2EE giới hạn những gì nhà cung cấp có thể đọc; nó không mô tả mọi nơi một cuộc trò chuyện có thể tồn tại.
Yêu cầu pháp lý gửi đến nhà cung cấp dịch vụ nhắn tin có thể tiếp cận các hồ sơ mà nhà cung cấp nắm giữ hoặc có thể truy cập. Mã hóa đầu cuối có thể giúp nội dung tin nhắn riêng tư không nằm trong tay nhà cung cấp ở dạng đọc được, nhưng không làm tài khoản trở nên ẩn danh hay ngăn cơ quan điều tra lấy thông tin từ nơi khác.
Kết quả phụ thuộc vào việc lưu giữ dữ liệu thực tế của dịch vụ, tính năng liên lạc được dùng, nguồn chứng cứ và thủ tục pháp lý áp dụng. Trát yêu cầu cung cấp dữ liệu, lệnh khám xét và việc kiểm tra thiết bị không phải các khái niệm có thể thay thế cho nhau. Bài viết giải thích ranh giới kỹ thuật, không giải thích cách một tòa án hay khu vực pháp lý cụ thể xử lý vụ việc; hãy tìm tư vấn pháp lý có chuyên môn khi có yêu cầu thực tế.
Bắt đầu từ nguồn dữ liệu
Câu hỏi như “Cảnh sát có thể đọc tin nhắn mã hóa không?” quá rộng. Hãy hỏi bản sao sẽ đến từ đâu:
| Nguồn | Những gì có thể có sẵn | E2EE thay đổi điều gì |
|---|---|---|
| Nhà cung cấp nhắn tin | Hồ sơ tài khoản, siêu dữ liệu được lưu, bài đăng công khai và dữ liệu chuyển phát mã hóa | E2EE triển khai đúng giới hạn quyền truy cập bản rõ riêng tư khi nhà cung cấp không có khóa |
| Thiết bị của người tham gia | Cuộc trò chuyện hiển thị, cơ sở dữ liệu cục bộ, tệp đã tải xuống hoặc thông báo | Mã hóa khi truyền không che giấu dữ liệu đã có trên thiết bị đầu cuối có thể truy cập |
| Dịch vụ sao lưu | Mọi nội dung trong bản sao lưu, theo chính sách mã hóa và khóa riêng của bản sao đó | E2EE trò chuyện không tự động xác lập E2EE cho bản sao lưu |
| Người nhận hoặc thành viên nhóm | Bản sao, ảnh chụp màn hình, bản xuất hoặc lời khai của họ | Người nhận có thể tiết lộ thông tin đã nhận |
Các nhóm này có thể chồng lấp. Máy chủ không có lịch sử riêng tư đọc được vẫn có thể giữ hồ sơ hữu ích; nhà cung cấp có hồ sơ phong phú có thể đã xóa một mục cụ thể theo chính sách lưu giữ. Không thể suy ra kết quả nào chỉ từ biểu tượng mã hóa.
Ví dụ được ghi nhận: phản hồi Signal đã công bố
Trong công bố tháng 10 năm 2021 về đại bồi thẩm đoàn California, Signal mô tả việc cung cấp dấu thời gian tạo tài khoản và ngày kết nối gần nhất, thay vì thông tin tin nhắn, liên hệ và nhóm được yêu cầu. Đó là bằng chứng về những hồ sơ Signal có sẵn cho phản hồi cụ thể đã được công bố đó.
Điều đó không chứng minh mọi ứng dụng nhắn tin mã hóa đều giữ hai trường giống nhau. Giảm thiểu dữ liệu là một lựa chọn kiến trúc riêng. Ví dụ cũng không cho biết điều tra viên có thể lấy gì từ thiết bị người dùng, người tham gia khác hoặc dịch vụ khác.
Livara ghi rõ điều gì về khả năng quan sát của máy chủ
Tổng quan bảo mật của Livara, được ghi cho phiên bản 0.1.68, mô tả tin nhắn trực tiếp được LVR1 bảo vệ và nhóm riêng tư tương thích được LGS1 bảo vệ; các nhóm cũ không tương thích vẫn được hiển thị rõ là nằm ngoài E2EE. Thiết kế tệp đính kèm được ghi trong tài liệu mã hóa tệp trước khi tải lên và mang khóa của chúng trong các phong bì cuộc trò chuyện được mã hóa.
Cũng tổng quan đó nêu các siêu dữ liệu liên lạc được giữ lại, gồm thông tin người gửi và đích đến, dấu thời gian, kích thước và tư cách thành viên nhóm. Máy chủ có thể đọc các kênh công khai. Cuộc gọi tùy chọn được ghi trên máy chủ, có dấu REC rõ ràng, dùng mã hóa truyền tải thay vì E2EE trong chế độ ghi đó. Hãy đọc ranh giới riêng của từng tính năng thay vì xem mọi nội dung trong một ứng dụng là như nhau.
Tài liệu cũng nói bảo vệ siêu dữ liệu LSS1 chưa được kết nối với việc gửi thông thường. Vì vậy, mô tả nhắn tin bình thường là che giấu đồ thị liên lạc khỏi dịch vụ sẽ gây hiểu lầm.
Đây là tuyên bố trong tài liệu sản phẩm, không phải phản hồi đã công bố cho yêu cầu pháp lý hay kiểm toán độc lập mọi hồ sơ máy chủ. Mô hình đe dọa là điểm khởi đầu phù hợp để hiểu các giới hạn dự kiến.
Mã hóa và lưu giữ trả lời những câu hỏi khác nhau
Mã hóa hỏi ai có khóa để diễn giải các byte được lưu. Lưu giữ hỏi những byte và hồ sơ nào còn tồn tại. Tệp mã hóa có thể được lưu lâu; nhật ký đọc được có thể chỉ tồn tại ngắn hạn. Tuyên bố “chúng tôi không thể giải mã tin nhắn” không chứng minh rằng không có địa chỉ IP, cuộc trao đổi hỗ trợ, báo cáo lạm dụng hoặc hồ sơ chuyển phát.
Báo cáo minh bạch hữu ích nên xác định kỳ báo cáo, loại yêu cầu, hồ sơ được yêu cầu, hồ sơ đã cung cấp và giới hạn công bố. Chính sách quyền riêng tư nên phân biệt thu thập với lưu giữ và giải thích ngoại lệ. Tránh suy ra “không có nhật ký” từ lời hứa chung về quyền riêng tư.
Xác thực cũng có hồ sơ riêng. SRP có thể tránh gửi mật khẩu trong trao đổi giao thức trung thực, nhưng máy chủ vẫn giữ giá trị kiểm chứng. RFC 5054 mục 3.3 giải thích rủi ro khi giá trị kiểm chứng bị đánh cắp, gồm việc đoán mật khẩu. “Không có mật khẩu bản rõ” không có nghĩa “không có gì nhạy cảm có thể bị tiết lộ hoặc đánh cắp”.
Câu hỏi trước khi dựa vào ứng dụng nhắn tin
- E2EE có bao phủ đúng cuộc trò chuyện, bản sao lưu, cuộc gọi và chế độ tệp đính kèm này không?
- Nhà cung cấp ghi rõ siêu dữ liệu nào, và lưu trong bao lâu?
- Thiết bị bổ sung hoặc các đường khôi phục tài khoản có thể làm lộ bản sao cục bộ không?
- Bài đăng công khai, nội dung gửi hỗ trợ và tin nhắn bị báo cáo có được xử lý riêng không?
- Có báo cáo minh bạch ghi ngày hoặc yêu cầu thực tế đã công bố, thay vì tuyên bố miễn trừ pháp lý không có cơ sở không?
Với vấn đề pháp lý đang diễn ra, đừng xem bài blog là chỉ dẫn xóa hồ sơ, thay đổi thời gian lưu giữ hoặc phớt lờ lệnh. Hãy tìm tư vấn phù hợp với khu vực pháp lý và bảo toàn tài liệu liên quan theo hướng dẫn.
Mã hóa hậu lượng tử có thay đổi câu trả lời không?
Nó có thể củng cố giao thức thiết lập khóa được thiết kế phù hợp trước các cuộc tấn công lượng tử tương lai vào bản mã đã thu thập. Nó không xóa siêu dữ liệu hiện có, nội dung công khai, bản sao trên thiết bị đầu cuối hay nghĩa vụ pháp lý. Phân biệt thực tiễn vẫn là: xác định dữ liệu, vị trí, khóa và thủ tục đang yêu cầu truy cập.
