Câu hỏi bảo mật hữu ích không phải là mã hóa nghe có mạnh hay không, mà là nó bảo vệ gì, ai giữ khóa và bằng chứng nào hỗ trợ tuyên bố đó.
“Mã hóa cấp quân sự” không cung cấp đủ thông tin để đánh giá một ứng dụng nhắn tin. Cụm từ này không cho biết ai nắm giữ khóa, những cuộc trò chuyện nào được bảo vệ, bản sao lưu có làm lộ bản rõ hay không, hoặc điều gì xảy ra khi thiết bị bị xâm nhập.
Cách phản hồi hữu ích không phải là phủ nhận mã hóa. Đó là thay một nhãn gọi ấn tượng bằng những tuyên bố cụ thể có thể kiểm chứng.
AES-256 là lựa chọn thuật toán, không phải mô hình bảo mật hoàn chỉnh
AES là tiêu chuẩn công khai, không phải công nghệ quân sự bí mật. FIPS 197 của NIST quy định AES-128, AES-192 và AES-256; phần số phía sau biểu thị độ dài khóa. Tiêu chuẩn được cập nhật về mặt biên tập vào năm 2023 mà không thay đổi thuật toán.
Một thuật toán mã hóa mạnh vẫn có thể được dùng trong hệ thống cho phép dịch vụ truy cập bản rõ. Hãy hỏi ai có thể giải mã, chứ không chỉ hỏi khóa dài bao nhiêu. Cũng cần hỏi khóa được tạo và lưu trữ như thế nào, danh tính được xác thực ra sao, và những tình huống lỗi nào khiến ứng dụng dừng lại thay vì tiếp tục hoạt động không an toàn.
Khi nhà cung cấp nêu AES-GCM, thông tin đó cụ thể hơn việc chỉ nêu AES: GCM kết hợp mã hóa với xác thực. Việc xử lý nonce đúng cách, xác minh thẻ xác thực và các yêu cầu triển khai khác vẫn rất quan trọng. Đặc tả GCM của NIST là tài liệu tham chiếu kỹ thuật; một logo không chứng minh ứng dụng triển khai đúng.
Bốn tuyên bố khác nhau mà tiếp thị thường gộp lại
| Tuyên bố | Vấn đề được giải quyết | Điều không được chứng minh |
|---|---|---|
| Mã hóa đường truyền | Bảo vệ trên một kết nối, chẳng hạn từ ứng dụng đến máy chủ | Máy chủ không thể đọc nội dung |
| Mã hóa dữ liệu lưu trữ | Bảo vệ dữ liệu đã lưu theo một mô hình khóa và quyền truy cập cụ thể | Đơn vị vận hành không có khóa giải mã |
| Mã hóa đầu cuối | Bảo vệ nội dung giữa những đầu cuối được chỉ định | Sự an toàn của đầu cuối đã bị xâm nhập hoặc sự trung thực của người nhận |
| Thiết lập khóa hậu lượng tử | Khả năng chống các mối đe dọa lượng tử được xác định trong quá trình thiết lập khóa | Kiểm toán toàn bộ ứng dụng, tính ẩn danh hay bảo đảm an toàn trong tương lai |
Mã hóa đường truyền không có nghĩa là mọi cơ sở dữ liệu của nhà cung cấp đều lưu bản rõ không được bảo vệ. Dịch vụ cũng có thể mã hóa dữ liệu lưu trữ. Điểm phân biệt quan trọng là nhà cung cấp có kiểm soát khóa hoặc bằng cách khác có quyền truy cập nội dung đọc được hay không. Hãy diễn đạt chính xác thay vì thay khẩu hiệu này bằng khẩu hiệu khác.
Để có phần giới thiệu rộng hơn, hãy xem nội dung giải thích mã hóa đầu cuối bảo vệ những gì.
“Sử dụng tiêu chuẩn NIST” không phải là “đã được xác nhận theo FIPS”
FIPS 203 định nghĩa ML-KEM, một cơ chế đóng gói khóa. Một ứng dụng nhắn tin có thể mô tả việc sử dụng thuật toán đó mà không có chứng nhận hoặc đánh giá độc lập cho toàn bộ ứng dụng. Tiêu chuẩn, kiểm thử thuật toán, xác nhận mô-đun mật mã và kiểm toán bảo mật sản phẩm là những loại bằng chứng khác nhau.
Chương trình xác nhận mô-đun mật mã của NIST nêu rõ rằng triển khai các chức năng được phê duyệt chưa đủ để xác lập việc mô-đun đã được xác nhận theo FIPS 140. Nếu sản phẩm quảng bá việc được xác nhận, hãy yêu cầu chứng thư, mô-đun và phiên bản chính xác, môi trường vận hành và cấu hình được phê duyệt. Sau đó xác định chứng thư thực sự bao phủ phần nào của sản phẩm.
Đây cũng là lý do không nên dùng “bảo mật 256 bit” như điểm đánh giá chung cho cả ứng dụng nhắn tin. Cách kết hợp giao thức, quản lý khóa và triển khai có thể đặt ra các giới hạn khác nhau.
Xác thực bằng mật khẩu không phải là mã hóa tin nhắn
Cơ chế đăng nhập trả lời câu hỏi người dùng có được truy cập tài khoản hay không. E2EE trả lời ai có thể đọc nội dung tin nhắn được bảo vệ. Không cơ chế nào tự động cung cấp các thuộc tính của cơ chế kia.
Ví dụ, SRP được thiết kế để xác thực mà không truyền chính mật khẩu. Điều đó không có nghĩa là cơ sở dữ liệu xác thực bị đánh cắp sẽ vô hại. Phần thảo luận về bảo mật SRP trong RFC 5054 giải thích rằng giá trị xác minh bị đánh cắp cho phép thực hiện các cuộc tấn công đoán mật khẩu và gây ra những rủi ro khác. Tránh kết luận rằng “không có mật khẩu để đánh cắp, vì vậy việc máy chủ bị xâm nhập không thể gây ảnh hưởng”.
Với người đọc, bước tiếp theo thiết thực là hỏi về khôi phục tài khoản, các phiên đang hoạt động và mối quan hệ giữa quyền truy cập tài khoản với khóa mã hóa. Câu trả lời chỉ lặp lại “zero knowledge” vẫn bỏ ngỏ những câu hỏi quan trọng.
Năm câu hỏi để đánh giá trang bảo mật của ứng dụng nhắn tin
- Những phạm vi nào được bảo vệ? Trò chuyện trực tiếp, nhóm, tệp, cuộc gọi, bài đăng công khai và bản sao lưu có thể có các ranh giới bảo vệ khác nhau.
- Ai giữ các khóa có thể sử dụng? Hãy tính cả khóa khôi phục, thiết bị được liên kết và các chế độ xử lý phía máy chủ.
- Đầu cuối bên kia được xác thực như thế nào? Hãy tìm cơ chế xác minh khóa, cảnh báo thay đổi có ý nghĩa và mô hình tin cậy được lập thành tài liệu.
- Có những bằng chứng nào? Đặc tả, bản dựng có thể tái tạo, véc-tơ kiểm thử và kiểm toán độc lập trả lời các câu hỏi khác nhau. Hãy hỏi phiên bản và phạm vi của từng loại.
- Những gì vẫn hiển thị hoặc dễ bị tổn hại? Siêu dữ liệu, thiết bị bị xâm nhập, tin nhắn bị sao chép và nội dung công khai không nên bị bỏ qua trong phần giải thích.
Áp dụng cùng bài kiểm tra đó cho Livara. Tài liệu bảo mật của Livara nêu tên LVR1 và LGS1, đồng thời công bố các ranh giới vận hành. Hãy coi đó là những tuyên bố về sản phẩm cần được đánh giá, không phải chứng nhận độc lập. Proof Lab cung cấp các minh họa và kiểm tra hiện vật phần mềm có giới hạn, chứ không chứng minh rằng mọi tính năng hoặc bản phát hành đều an toàn.
Cách đọc một báo cáo kiểm toán độc lập
Kiểm tra ngày, đơn vị kiểm toán, bản sửa đổi mã nguồn, các nền tảng được đưa vào và những thành phần bị loại trừ. Đọc các phát hiện và trạng thái khắc phục, không chỉ huy hiệu tóm tắt. Kiểm toán một thư viện mật mã không tự động bao phủ khôi phục tài khoản, ứng dụng web, thông báo hay bảo mật vận hành.
Không có kiểm toán là một khoảng trống trong cơ sở bảo đảm, chứ không phải bằng chứng về một lỗ hổng cụ thể. Ngược lại, kiểm toán cũng không phải bảo đảm trọn đời. So sánh hữu ích ghi lại bằng chứng và giới hạn của chúng thay vì tuyên bố một ứng dụng là bên thắng “an toàn nhất” trong mọi trường hợp.
Câu hỏi thường gặp
“Cấp quân sự” có phải lúc nào cũng là tên gọi khác của AES-256 không?
Không. Đừng suy ra một thuật toán hay chứng nhận cụ thể từ cụm từ đó. Hãy yêu cầu nhà cung cấp nói rõ nó có nghĩa chính xác là gì.
Mã hóa mạnh hơn có ngăn được ảnh chụp màn hình hoặc phần mềm độc hại không?
Nó không ngăn người nhận sao chép nội dung hay ngăn thiết bị bị xâm nhập làm lộ dữ liệu mà thiết bị có thể truy cập. Đó là những mối đe dọa khác.
Dấu hiệu nào tốt hơn một khẩu hiệu bảo mật?
Phạm vi rõ ràng, giao thức được nêu tên, giới hạn được trình bày cụ thể và bằng chứng có thể xem xét về bản triển khai đã phân phối. Phần giải thích nên giúp bạn quyết định nên tin điều gì — và điều gì vẫn cần kiểm chứng.
