Khóa riêng cho một tệp không có nghĩa là chỉ xem một lần hay thu hồi được bản sao của người nhận.
Để bảo vệ một tệp đính kèm, ứng dụng nhắn tin có thể mã hóa tệp trên thiết bị người gửi bằng khóa ngẫu nhiên, tải bản mã hóa lên và chuyển khóa tệp cho người nhận trong một tin nhắn được mã hóa đầu cuối. Mô hình này đôi khi được gọi là mã hóa phong bì: tệp lớn và lượng thông tin nhỏ cần để mở tệp đi theo những đường khác nhau nhưng có liên quan.
Giải thích này áp dụng cho tệp đính kèm trong cuộc trò chuyện có E2EE; gửi tệp trong bất kỳ ứng dụng hay loại kênh nào không nhất thiết có cùng sự bảo vệ.
Đường đi của một bức ảnh riêng tư từ thiết bị tới người nhận
- Thiết bị người gửi tạo khóa nội dung cho tệp.
- Tệp được mã hóa bằng cơ chế mã hóa có xác thực; người nhận phải phát hiện được thay đổi trái phép đối với dữ liệu.
- Bản mã hóa được đưa lên dịch vụ lưu trữ tệp.
- Địa chỉ hoặc mã định danh của tệp cùng khóa cần thiết được gửi cho người nhận trong một tin nhắn được bảo vệ.
- Thiết bị người nhận tải tệp về, kiểm tra tính hợp lệ rồi mở tệp.
Tài liệu bảo mật Livara mô tả khóa ngẫu nhiên riêng cho từng tệp đính kèm và việc chuyển khóa trong phiên nhắn tin. Bài viết này giải thích kiến trúc được công bố đó, không phải kết quả kiểm toán việc triển khai.
“Khóa riêng cho tệp” khác với “tệp chỉ mở được một lần”
Khóa được tạo cho một tệp có thể cần để đọc chính tệp đó nhiều lần. Khóa riêng không có nghĩa là lập tức loại bỏ khóa sau lần xem đầu tiên, tự động xóa tệp hay ngăn người nhận lưu tệp.
Tương tự, khóa tin nhắn dùng một lần và việc dùng khóa nội dung cho tệp đính kèm là hai khái niệm khác nhau. Không nên suy ra các tính năng như View Once hay tin nhắn tự biến mất chỉ từ tên thuật toán.
Vì sao cả khóa và nonce đều quan trọng?
Ngoài tính bí mật, AES-GCM còn cung cấp khả năng kiểm tra tính xác thực của dữ liệu; nhưng việc sử dụng đúng là thiết yếu. Tiêu chuẩn NIST SP 800-38D giải thích các quy tắc của GCM. Lặp lại cùng tổ hợp khóa và nonce cho những dữ liệu khác nhau có thể gây nguy hiểm cho bảo mật.
Với người dùng, kết luận thực tế là: chỉ cụm từ “AES-256” là chưa đủ. Cũng phải xem xét đặc tả quản lý khóa, tạo số ngẫu nhiên, kiểm tra tính hợp lệ của tệp và xử lý lỗi. Việc thay đổi một byte phải dẫn tới từ chối tệp không hợp lệ, chứ không phải hiển thị nội dung đã bị sửa như một tệp nguyên vẹn.
Người nhận, máy chủ và ứng dụng thư viện ảnh nhìn thấy gì?
| Vị trí | Câu hỏi bảo mật |
|---|---|
| Dịch vụ lưu trữ tệp | Chỉ có các byte đã mã hóa hay cũng truy cập được khóa? |
| Tin nhắn chứa khóa | Khóa, tên tệp và chú thích có được bảo vệ trong cuộc trò chuyện E2EE không? |
| Thiết bị người nhận | Sau khi mở, tệp nằm ở đâu trong bộ nhớ, bộ nhớ đệm hoặc thư viện ảnh? |
| Bản sao lưu đám mây | Bản đã lưu có đi vào bản sao lưu ảnh không và bản sao lưu đó được bảo vệ thế nào? |
Mã hóa khi truyền không kiểm soát bản sao mà người nhận lưu trong thư viện ảnh. Trước khi gửi tài liệu nhạy cảm, hãy xem lại cả những phần không cần thiết của hình ảnh, chữ ở nền và thông tin vị trí của tệp.
Tệp trong nhóm riêng tư khác thế nào?
Số người được phép giữ khóa tăng lên. Livara mô tả việc bảo vệ tệp đính kèm của nhóm riêng tư tương thích ở chế độ E2EE trong LGS1; không được mở rộng tuyên bố này sang kênh công khai. Bất kỳ thành viên nào đã nhận tệp đều có thể giữ một bản sao. Xóa thành viên hoặc xoay vòng khóa cho tương lai không thu hồi được bản sao trước đó của họ.
Danh sách kiểm tra khi gửi tệp nhạy cảm
- Kiểm tra lại không gian trò chuyện và những người nhận.
- Nếu danh tính của người liên hệ quan trọng, hãy xác minh dấu vân tay khóa qua một kênh đáng tin cậy.
- Chỉ gửi thông tin cần thiết; không phải lúc nào cũng cần ảnh chụp toàn bộ tài liệu.
- Thống nhất với người nhận về việc lưu vào thư viện ảnh, tải xuống tự động và sao lưu đám mây.
- Không để tệp đã giải mã trên thiết bị dùng chung hoặc không khóa.
Câu hỏi thường gặp
Khóa riêng cho tệp có bảo đảm gửi tệp an toàn không?
Không. Tình trạng an toàn của các thiết bị, xác thực người nhận và triển khai đúng cũng là những điều cần thiết. Hãy đọc mô hình đe dọa của Livara cùng với các đặc tả mã hóa.
Hình ảnh trên kênh công khai có cùng sự bảo vệ không?
Theo ranh giới mà Livara công bố, các kênh là công khai và có thể đọc được; không có lời hứa về tính bí mật như tệp đính kèm riêng tư dành cho chúng.
Chỉ liên kết tới tệp đã đủ chưa?
Điều này phụ thuộc vào thiết kế dịch vụ. Hãy kiểm tra riêng liên kết, khóa và quyền truy cập; chỉ vì URL dài hay ngẫu nhiên không chứng minh có E2EE.
