SHARE THE PERSPECTIVE
Tính toàn vẹn của gói, độ mới của tin nhắn và lịch sử chỉnh sửa là ba thuộc tính riêng; đừng lấy thuộc tính này làm bằng chứng cho thuộc tính kia.

Ứng dụng nhắn tin có thể có chức năng chỉnh sửa hoặc xóa; nhưng trong hệ thống mã hóa có xác thực, máy chủ không được có khả năng âm thầm thay đổi bản mã rồi vẫn chuyển đến một tin nhắn hợp lệ. Tính toàn vẹn của tin nhắn trong ứng dụng nhắn tin nghĩa là người nhận có thể phát hiện dữ liệu đã thay đổi sau khi mã hóa; thuộc tính này không giống việc lưu toàn bộ lịch sử hoặc chứng minh cuộc trò chuyện về mặt pháp lý.

Những điểm chính

  • Mã hóa có xác thực phát hiện việc sửa đổi bản mã, nhưng không nhất thiết lưu lịch sử chỉnh sửa và xóa.
  • Theo tài liệu kỹ thuật của Livara, AES-256-GCM bảo vệ tin nhắn riêng tư kèm thẻ xác thực; gói bị sửa đổi không được giải mã như một gói hợp lệ.
  • Chỉnh sửa được phép phải là một sự kiện mới được mã hóa đầu cuối, không phải việc máy chủ bí mật ghi đè gói cũ.
  • Số an toàn giúp kiểm tra khóa của đối phương, không đánh giá sự trung thực của họ hoặc giá trị pháp lý của ảnh chụp màn hình.
  • Với tranh chấp nhạy cảm, hãy giữ tệp gốc, thời điểm, trạng thái chỉnh sửa và bằng chứng độc lập cả ở bên ngoài luồng trò chuyện.

Tính toàn vẹn của tin nhắn chính xác là gì?

Tính toàn vẹn của tin nhắn nghĩa là người nhận có thể phát hiện thay đổi trái phép trong dữ liệu mã hóa. Tính bí mật hỏi “Ai có thể đọc nội dung?”, còn tính toàn vẹn hỏi “Dữ liệu nhận được có đúng là dữ liệu người gửi đã mã hóa không?”. Phần giải thích về mã hóa đầu cuối và các giới hạn trình bày rõ hơn sự khác biệt này.

Minh họa điện thoại với hai khung màu và biểu tượng ổ khóa trên màn hình.

Đây là hình minh họa khái niệm với nhãn mang tính trình diễn, không phải giao diện Livara thật hoặc kết quả kiểm thử từ chối tin nhắn bị sửa đổi.

Theo tài liệu kỹ thuật của Livara, tin nhắn trực tiếp dùng LVR1 và nhóm riêng tư tương thích dùng LGS1 được mã hóa đầu cuối. Theo trang bảo mật Livara, nhóm cũ không tương thích được thể hiện rõ là nằm ngoài E2EE, và nhóm mới không được tạo với nhãn mã hóa cho đến khi mọi thành viên sẵn sàng. Hãy kiểm tra trạng thái của chính cuộc trò chuyện đó. Tài liệu cho biết LVR1 dùng ECDH P-256 và ML-KEM-768 để dẫn xuất khóa tin nhắn. Một thành phần được tiêu chuẩn hóa không có nghĩa toàn bộ tổ hợp hoặc sản phẩm đã được phê chuẩn độc lập. Sau đó Livara dùng AES-256-GCM để bảo vệ nội dung.

Theo tài liệu sản phẩm, sự bảo vệ này bao gồm văn bản, chỉnh sửa và tệp đính kèm trong trò chuyện riêng tư. Tuy nhiên, các kênh Livara không được mã hóa đầu cuối: máy chủ được chủ động cho phép đọc nội dung để, trong số các mục đích khác, xóa nội dung lạm dụng. Tư cách thành viên nhóm cũng do máy chủ kiểm soát. Bảo mật cuộc gọi và chế độ ghi âm cần được đánh giá riêng với tin nhắn văn bản.

Phát hiện sửa đổi tin nhắn mã hóa và AES-256-GCM trong ứng dụng nhắn tin

Ngoài mã hóa nội dung, AES-GCM tạo thẻ xác thực. Nếu bản mã hoặc dữ liệu được xác thực thay đổi, việc kiểm tra thẻ phải thất bại. NIST SP 800-38D định nghĩa chế độ GCM và cảnh báo rằng lặp lại nonce với cùng một khóa có thể làm suy yếu nghiêm trọng tính bảo mật.

Theo thông số kỹ thuật của Livara, tin nhắn riêng tư dùng AES-256-GCM. Nếu máy chủ thay đổi một phần của gói được bảo vệ, nó không thể tạo thẻ xác thực mới khi không có khóa tin nhắn; vì vậy người nhận không được chấp nhận gói là nguyên vẹn. Câu trả lời ngắn cho “Máy chủ có thể thay đổi tin nhắn không?” là: máy chủ có thể xóa, giữ lại, chặn hoặc chuyển dữ liệu chậm, nhưng không được có khả năng làm cho nội dung bị sửa đổi trông như hợp lệ.

Bảo đảm này không vô hạn. Mật mã không thể vô hiệu hóa mã độc trên thiết bị, việc kẻ tấn công tiếp cận màn hình đang mở hoặc chỉnh sửa được phép của người dùng. Tính toàn vẹn nội dung cũng không nhất thiết che giấu siêu dữ liệu. Hướng dẫn về siêu dữ liệu nhắn tin và những gì nó tiết lộ giải thích ranh giới này.

Máy chủ có thể sửa tin nhắn hay chỉnh sửa là việc khác?

Máy chủ không được có khả năng bí mật ghi đè gói mã hóa trước đó, nhưng có thể chuyển một sự kiện chỉnh sửa do người gửi tạo. Tính an toàn của chỉnh sửa tin nhắn phụ thuộc vào việc chỉnh sửa cũng được xác thực và mã hóa đầu cuối như tin nhắn gốc, thay vì máy chủ trực tiếp đổi văn bản đã lưu.

Theo tài liệu Livara, chỉnh sửa trong chat trực tiếp được bảo vệ bởi LVR1 và trong nhóm riêng tư tương thích bởi LGS1. Khi đánh giá giao diện, hãy kiểm tra ứng dụng có hiển thị trạng thái “đã chỉnh sửa” hay không; tuy nhiên, riêng mật mã không lưu phiên bản trước vĩnh viễn trên mọi thiết bị.

“Xóa cho mọi người” cũng là yêu cầu loại bỏ nội dung, không phải bằng chứng mọi bản sao đã bị hủy. Người nhận có thể đã xem tin nhắn, đọc thông báo, lưu tệp hoặc chụp màn hình. Tin nhắn tự biến mất giảm thời gian lưu tồn, nhưng không bảo đảm mọi bản sao bị xóa.

Xác thực tin nhắn trò chuyện chứng minh điều gì?

Xác thực tin nhắn trò chuyện cho thấy tin nhắn được tạo bằng khóa phiên và không bị sửa đổi trên đường truyền. Điều này không chứng minh chủ tài khoản trực tiếp cầm thiết bị, nội dung là sự thật hoặc người nhận sau này có thể chứng minh dứt khoát điều đó cho bên thứ ba.

Trong tài liệu kỹ thuật, Livara giới thiệu số an toàn như một cách phát hiện thay đổi khóa. Hai người có thể so sánh dấu vân tay khóa qua một kênh độc lập; hướng dẫn kiểm tra chat bằng số an toàn mô tả các bước thực tế. Việc này giảm rủi ro khóa của người liên hệ bị thay bằng khóa của kẻ tấn công, nhưng không làm thiết bị nhiễm mã độc trở nên an toàn.

Xác thực tài khoản cũng là vấn đề riêng. Bất kỳ cơ chế đăng nhập nào, dù mạnh đến đâu, cũng không thay thế tính toàn vẹn tin nhắn, việc kiểm tra khóa người liên hệ hoặc bảo mật thiết bị.

Tính toàn vẹn nội dung không phải thứ tự và độ mới của tin nhắn

Một gói cũ có thể có thẻ xác thực hợp lệ. Để ngăn nó được chấp nhận lần nữa cần thiết kế giao thức, bộ đếm, mã định danh phiên và việc người nhận duy trì trạng thái; riêng AES-GCM không phải sổ ghi thứ tự của toàn bộ cuộc trò chuyện. Sự khác biệt này quan trọng khi đánh giá phát lại, tin nhắn đến muộn và đồng bộ nhiều thiết bị.

Cũng cần làm rõ dữ liệu nào thực sự nằm dưới thẻ xác thực. Nếu mã định danh cuộc trò chuyện hoặc loại sự kiện nằm ngoài ngữ cảnh được xác thực, chỉ bảo vệ phần nội dung không giải quyết toàn bộ vấn đề. Việc xem xét mã và kiểm thử đúng phiên bản đó cần làm rõ mối liên hệ này.

Nếu nội dung hoặc trạng thái tin nhắn bất ngờ

Ghi lại phiên bản ứng dụng, thời điểm quan sát, các thiết bị liên quan và sự hiện diện của nhãn chỉnh sửa. Hỏi người liên hệ qua kênh độc lập xem họ có thực hiện chỉnh sửa được phép hay không. Đừng quy chênh lệch đồng bộ cho việc máy chủ can thiệp khi chưa có bằng chứng; nhưng cũng đừng vô cớ bỏ qua lỗi xác thực hoặc thay đổi khóa.

Với báo cáo kỹ thuật, hãy dùng tin nhắn thử không nhạy cảm và không đưa dữ liệu riêng tư của người liên hệ vào báo cáo công khai. Nếu cuộc trò chuyện sẽ được dùng trong vấn đề pháp lý, riêng mật mã hoặc ảnh chụp màn hình không quyết định giá trị pháp lý; hãy nhờ chuyên gia đủ năng lực trước khi thay đổi chứng cứ.

Đánh giá tuyên bố toàn vẹn của ứng dụng nhắn tin như thế nào?

Đừng chỉ chấp nhận cụm từ “được mã hóa”. Hãy hỏi:

  • Những cuộc trò chuyện và tệp nào được mã hóa đầu cuối?
  • Dịch vụ dùng thuật toán AEAD nào?
  • Chỉnh sửa và xóa được ghi nhận, hiển thị ra sao?
  • Người dùng phát hiện thay đổi khóa người liên hệ bằng cách nào?
  • Máy chủ kiểm soát siêu dữ liệu, nội dung hoặc tư cách thành viên nào?
  • Cuộc gọi có cùng bảo đảm như tin nhắn không?
  • Giao thức đã được kiểm toán độc lập chưa?

Livara công bố thông số và công cụ để kiểm tra một số tuyên bố của mình, và người dùng Android có thể so sánh checksum của tệp APK bằng SHA-256 trong Proof Lab để kiểm tra ứng dụng ngoại tuyến. Tuy nhiên, bài viết này không đưa ra bằng chứng về kiểm toán độc lập của phiên bản hiện tại. Công bố thông số và vectơ kiểm thử hỗ trợ việc kiểm tra, nhưng không thay thế kiểm toán độc lập.

Với trò chuyện riêng tư, tuyên bố chính của Livara có giới hạn và rõ ràng: AES-256-GCM phải phát hiện việc sửa đổi gói và các chỉnh sửa cũng phải được mã hóa. Điều này không có nghĩa là một sổ ghi bất biến, xóa chắc chắn mọi bản sao hoặc tự động tạo bằng chứng pháp lý.

Câu hỏi thường gặp

Quản trị viên máy chủ có thể sửa nội dung tin nhắn mã hóa không?

Trong thiết kế đúng với AES-256-GCM, khi không có khóa tin nhắn, quản trị viên không thể thay đổi bản mã rồi tạo thẻ xác thực hợp lệ. Họ vẫn có thể xóa, chặn hoặc chuyển gói chậm. Bảo đảm này không bao gồm thiết bị nhiễm mã độc hoặc chỉnh sửa được phép của người gửi.

Nhãn “đã chỉnh sửa” có chứng minh phiên bản trước là gì không?

Không. Nhãn chỉ nói nội dung đang hiển thị đã thay đổi sau khi gửi, trừ khi ứng dụng còn giữ lịch sử phiên bản. Mã hóa có thể kiểm tra tính xác thực của sự kiện chỉnh sửa, nhưng không tự động lưu văn bản trước đó.

Số an toàn có bảo đảm tính xác thực của mọi tin nhắn không?

Không. Số an toàn giúp kiểm tra khóa mật mã có thuộc người liên hệ hay không và phát hiện thay đổi. Việc này không cho biết ai cầm thiết bị lúc gửi, tin nhắn có đúng sự thật hay thiết bị có sạch mã độc không.

Xóa cho mọi người có xóa tin nhắn ở mọi nơi không?

Không. Chức năng này có thể loại bỏ bản sao trong ứng dụng, nhưng không thu hồi tệp đã lưu, thông báo, ảnh chụp màn hình hoặc bản ghi trước đó. Xóa cho mọi người giảm thời gian lưu tồn; không bảo đảm xóa khỏi thiết bị người nhận hoặc các hệ thống khác.

Xem các giới hạn bảo mật của Livara
CONTINUE THE THREADPrivate messaging ↗
YOU’VE REACHED THE ENDBack to the reading room ↗