Một mô hình đe dọa tốt gắn rủi ro cụ thể với biện pháp có thể kiểm chứng, chứ không phải danh sách tính năng dài nhất.
Lập mô hình đe dọa cho ứng dụng nhắn tin nghĩa là xác định thông tin nào quan trọng với bạn, ai có thể truy cập thông tin đó và biện pháp nào phù hợp với rủi ro cũng như hoàn cảnh của bạn. Một gia đình, một nhà báo và một nhân viên dùng điện thoại công ty không nhất thiết đối mặt với những mối đe dọa giống nhau. Hướng dẫn này cung cấp một khuôn khổ đơn giản để bạn viết kế hoạch riêng, chứ không phải bảng xếp hạng cuối cùng về các ứng dụng nhắn tin.
Những điểm chính
- Mô hình đe dọa là ba hoặc bốn câu, không phải một sản phẩm. Hãy viết rõ bạn muốn bảo vệ điều gì, trước ai và sẵn sàng bỏ ra bao nhiêu công sức. Nếu thiếu những câu này, việc chọn ứng dụng nhắn tin chỉ là gom một danh sách tính năng.
- Cuộc trò chuyện của bạn có bốn mắt xích: thiết bị của bạn, mạng, máy chủ ứng dụng nhắn tin và thiết bị của người bên kia. Bốn lớp này là điểm khởi đầu; bạn cũng cần xem xét riêng các bản sao lưu, tài khoản và dịch vụ được kết nối.
- Mã hóa đầu cuối bảo vệ nội dung trước các bên trung gian; bảo mật thiết bị, khóa, bản sao lưu và hành vi của người nhận vẫn rất quan trọng.
- Đánh giá mối đe dọa theo hoàn cảnh của chính bạn: truy cập vật lý, nội dung xem trước trong thông báo, lừa đảo, bản sao lưu và thiết bị liên kết là những ví dụ cần xem xét, không phải bảng xếp hạng thống kê.
- Siêu dữ liệu khác với nội dung văn bản. Thông tin về việc bạn đã nói chuyện với ai và vào lúc nào vẫn có thể tồn tại ngay cả khi văn bản được mã hóa hoàn toàn, nên cần được cân nhắc riêng.
Mô hình đe dọa là gì và vì sao nó quan trọng khi chọn ứng dụng nhắn tin?
Mô hình đe dọa là phần mô tả ngắn gọn về việc bạn muốn bảo vệ điều gì, trước ai và với bao nhiêu công sức. Khi ba yếu tố này chưa rõ, việc so sánh ứng dụng nhắn tin chỉ tạo ra một danh sách tính năng dài hơn, mà không giúp bạn biết tính năng nào hữu ích với mình.
Electronic Frontier Foundation (EFF) cũng giải thích điều này trong hướng dẫn Security Planning (Threat Modeling): cố gắng bảo vệ mình trước mọi mối đe dọa có thể xảy ra, vào mọi lúc, sẽ dẫn đến nản lòng, vì bảo mật là một quá trình chứ không phải một món hàng. Với các nhóm kỹ thuật, dự án mô hình hóa đe dọa của OWASP cung cấp khuôn khổ tương tự, còn thư viện mô hình đe dọa trong hướng dẫn dành cho nhà phát triển của OWASP có nhiều ví dụ sẵn có để tham khảo.
Một lưu ý thực tế: mô hình đe dọa không phải tài liệu bất biến. Đổi việc, đi công tác hoặc thêm một người vào nhóm gia đình có thể làm nó thay đổi hoàn toàn. Mỗi khi có thay đổi như vậy, hãy viết lại bốn câu đó.
Ai đọc tin nhắn của tôi? Chia chuỗi thành bốn mắt xích
Câu trả lời ngắn gọn: mỗi tin nhắn đi qua bốn mắt xích — thiết bị của bạn, mạng, máy chủ ứng dụng nhắn tin và thiết bị của người liên hệ — còn các bản sao hoặc tài khoản liên kết cũng có thể tạo thêm đường truy cập. Vì vậy, câu hỏi đúng không phải là “ứng dụng nhắn tin nào an toàn hơn?”, mà là “trong hoàn cảnh của tôi, mắt xích nào yếu nhất?”.
Mắt xích thứ nhất: thiết bị của bạn
Mọi thứ hiển thị trên màn hình điện thoại đều đã được giải mã. Nếu điện thoại không khóa, phần xem trước thông báo trên màn hình khóa được bật hoặc ai đó biết mã bốn chữ số của bạn, thì mã hóa trên đường truyền không ngăn được việc đọc nội dung có thể truy cập ngay trên thiết bị đó.
Mắt xích thứ hai: mạng
Bên quan sát mạng có thể thấy đích kết nối, thời điểm và lưu lượng dữ liệu. Một dịch vụ DNS không nhất thiết nhìn thấy toàn bộ tuyến đường hay tất cả các gói tin nhắn. Khi có mã hóa đầu cuối, những bên quan sát này thấy dữ liệu được mã hóa chứ không phải văn bản, nhưng việc trao đổi tin nhắn và lượng dữ liệu thường không được che giấu.
Mắt xích thứ ba: máy chủ ứng dụng nhắn tin
Máy chủ là điểm đồng bộ các thiết bị. Với mã hóa đầu cuối, máy chủ không đọc được văn bản nhưng vẫn thấy siêu dữ liệu định tuyến và có thể lưu giữ chúng. Đây là nơi sự khác biệt giữa “được mã hóa” và “riêng tư” trở nên rõ ràng.
Mắt xích thứ tư: thiết bị của người bên kia
Mắt xích cuối cùng nằm ngoài quyền kiểm soát của bạn. Người liên hệ có thể chụp màn hình, chuyển tiếp tin nhắn hoặc dùng một chiếc điện thoại đã nhiễm mã độc. Mã hóa đầu cuối chỉ đưa mắt xích này về bài toán “tin tưởng người liên hệ”, không hơn.
Tóm lại, mã hóa đầu cuối giới hạn phạm vi truy cập nội dung, nhưng thiết bị, việc quản lý khóa và những người nhận được phép vẫn là một phần của mô hình đe dọa.
Cần xem xét những mối đe dọa nào trong hoàn cảnh của bạn?
Điện thoại không khóa, quyền truy cập tài khoản, nội dung xem trước thông báo và bản sao lưu là những ví dụ cần kiểm tra. Với người bị nhắm mục tiêu bởi những kẻ tấn công chuyên nghiệp, mã độc tinh vi hoặc cưỡng ép về thể chất cũng có thể là vấn đề đáng quan tâm. Đừng xem nhẹ rủi ro khi chưa hiểu hoàn cảnh.
Sao lưu là một đường truy cập riêng. Nếu ứng dụng nhắn tin lưu bản sao trên đám mây và bản sao đó không được mã hóa đầu cuối, thì lớp mã hóa trên điện thoại chỉ bảo vệ đến ranh giới đám mây. Điều đó giống như khóa đúng cánh cửa nhưng lại để chìa khóa ngay bên cạnh. Hướng dẫn sao lưu an toàn các cuộc trò chuyện được mã hóa giúp bạn xem xét đường truy cập này.
Mối đe dọa thứ hai là những người ở gần: đồng nghiệp, người ở cùng nhà hoặc người mượn điện thoại “chỉ một lát”. Mối đe dọa thứ ba là tài khoản đăng nhập. Nếu bạn đăng nhập bằng email và email đó được bảo vệ yếu, toàn bộ chuỗi có thể bị mở từ mắt xích yếu nhất. Mã hóa mạnh hơn không giải quyết được bất kỳ vấn đề nào trong số này.
Bảo vệ cuộc trò chuyện trước tin tặc: những kiểu tấn công nào thực sự xảy ra?
Câu trả lời ngắn gọn: các cuộc tấn công phổ biến vào trò chuyện không nhằm phá vỡ nền tảng toán học của mã hóa. Chúng dùng lừa đảo, mã độc, đánh cắp mã đăng nhập và tấn công chính thiết bị. Trên thực tế, thay vì phá khóa, kẻ tấn công đi tìm chìa khóa.
Vì vậy, cách bạn đăng nhập cũng quan trọng như độ dài khóa. Livara dùng SRP để xác thực — chứng minh biết mật khẩu mà không tiết lộ mật khẩu: thiết bị chứng minh rằng nó biết mật khẩu mà không gửi chính mật khẩu qua mạng. Kết quả thực tế là việc ghi lại lưu lượng đăng nhập không làm lộ mật khẩu. Tuy nhiên, cũng cần nói rõ giới hạn: SRP không ngăn được một trang giả mạo mà người dùng tự nhập mật khẩu vào. Lúc đó, vấn đề không còn nằm ở toán học mà ở sự cẩn trọng của người dùng.
Bề mặt tấn công thứ hai là chính ứng dụng. Một tệp APK bị chỉnh sửa có thể vượt qua mọi lớp mã hóa. Livara công bố mã kiểm tra SHA-256 cho mỗi bản phát hành để bạn so sánh tệp đã tải với một giá trị tham chiếu đáng tin cậy. Phòng kiểm chứng thực hiện việc này trong trình duyệt. Nếu muốn biết nên hỏi gì về bất kỳ ứng dụng nhắn tin nào khác, danh sách câu hỏi cần đặt ra trước khi chọn ứng dụng nhắn tin an toàn là một điểm khởi đầu hữu ích.
Mã hóa đầu cuối bảo vệ những gì và không bảo vệ những gì?
Câu trả lời ngắn gọn: mã hóa đầu cuối bảo vệ nội dung tin nhắn từ thiết bị của bạn đến thiết bị của người nhận, để máy chủ chỉ thấy dữ liệu được mã hóa. Nhưng tên gọi của tính năng này không cho phép suy ra điều gì về toàn bộ siêu dữ liệu, bản sao lưu, ảnh chụp màn hình hay kênh công khai. Mỗi phần đều cần biện pháp kiểm soát riêng.
Với một sản phẩm cụ thể, hãy đọc bảng phạm vi bảo vệ của các tính năng thay vì suy luận từ tên thuật toán. Trang bảo mật của Livara và mô hình đe dọa của ứng dụng giải thích về trò chuyện, kênh, cuộc gọi, siêu dữ liệu và khôi phục. Đây là những tuyên bố do nhà phát triển công bố, không thay thế được kiểm thử độc lập. Đặc biệt, hãy xem xét riêng các điều kiện liên quan đến ghi âm cuộc gọi và sự khác biệt giữa khôi phục danh tính với khôi phục lịch sử trò chuyện.
Siêu dữ liệu tiết lộ gì ngay cả khi văn bản đã được mã hóa?
Câu trả lời ngắn gọn: siêu dữ liệu cho biết ai đã nói chuyện với ai, vào lúc nào và với lượng dữ liệu bao nhiêu. Mã hóa văn bản không làm những thông tin này biến mất.
Trong Livara, siêu dữ liệu định tuyến tiêu chuẩn — người gửi, đích đến và thời điểm giao tin — được lưu giữ để đồng bộ thiết bị liền mạch. Đây là một giới hạn được nêu rõ, không phải chi tiết có thể bỏ qua. Ngay cả khi không đọc văn bản, sơ đồ “ai nói chuyện với ai” vẫn có thể nhạy cảm: bác sĩ và bệnh nhân, luật sư và khách hàng hoặc hai bên trong một cuộc đàm phán kinh doanh. Bạn có thể tìm phần giải thích đầy đủ hơn trong bài viết về những gì siêu dữ liệu nhắn tin tiết lộ.
Nếu mô hình đe dọa của bạn có “người quan sát được mô thức liên lạc của tôi”, thì không ứng dụng nhắn tin mã hóa đầu cuối nào tự nó giải quyết được phần này. Bạn còn phải cân nhắc mình nói chuyện với ai và từ đâu.
Viết mô hình đe dọa của bạn trong năm phút
Câu trả lời ngắn gọn: trả lời bốn câu hỏi — tôi lo ngại ai, người đó muốn gì, họ có khả năng đến đâu và điều gì xảy ra nếu tin nhắn bị lộ — rồi chọn biện pháp hiệu quả ít tốn kém nhất, chứ không làm ngược lại.
- Ai là bên gây ra mối đe dọa? Hãy gọi tên: đồng nghiệp, người yêu hoặc bạn đời cũ, kẻ trộm, công ty, chính phủ.
- Điều gì đáng được bảo vệ? Nội dung trò chuyện, tệp hay chính mô thức liên lạc.
- Người đó có khả năng đến đâu? Có thể tiếp cận trực tiếp điện thoại? Truy cập tài khoản? Có nguồn lực lớn?
- Điều gì xảy ra nếu thông tin bị lộ? Ảnh hưởng đến danh tiếng, công việc, an toàn thể chất hay chỉ gây ngượng ngùng?
- Dựa trên các câu trả lời này, hãy chọn biện pháp hiệu quả ít tốn kém nhất.
Nếu mối đe dọa là người quan sát cùng mạng Wi-Fi, kết nối TLS được xác minh hợp lệ và mã hóa đầu cuối có xác thực là những yếu tố quan trọng. Với truy cập vật lý, khóa thiết bị lại có mức ưu tiên khác. Hướng dẫn xác minh cuộc trò chuyện bằng mã số bảo mật cho biết cách thực hiện việc xác minh đó. Còn nếu muốn biết ai thấy được gì trong một ứng dụng cụ thể, mô hình đe dọa do Livara công bố giải thích điều này mà không dùng khẩu hiệu.
Ví dụ ngắn về một mô hình đe dọa
“Các tệp công việc trên điện thoại của tôi có tính nhạy cảm. Rủi ro chính hiện tại là đồng nghiệp truy cập điện thoại đang mở khóa và các bản sao đã lưu trong thư viện ảnh. Tuần này, tôi sẽ rút ngắn thời gian tự khóa, hạn chế nội dung xem trước thông báo và kiểm tra các thư mục sao lưu. Sau đó, tôi sẽ đánh giá kết quả bằng một tệp thử nghiệm.”
Đây chỉ là ví dụ. Nếu một người có hành vi kiểm soát bạn có quyền truy cập thiết bị, việc đột ngột thay đổi cài đặt có thể khiến họ chú ý. Hãy lập kế hoạch bằng một thiết bị an toàn, nhờ người đáng tin cậy hỗ trợ và đặt an toàn thể chất lên hàng đầu.
Câu hỏi thường gặp
Định nghĩa “mô hình đe dọa” trong một câu như thế nào?
Đó là làm rõ bạn muốn bảo vệ điều gì, trước ai và với bao nhiêu công sức. Chính câu này quyết định tính năng bảo mật nào đáng để đầu tư và tính năng nào chỉ làm mọi thứ phức tạp hơn.
Có mã hóa đầu cuối rồi, tôi vẫn cần lo về tin tặc sao?
Có, nhưng không hẳn theo cách bạn nghĩ: thay vì phá khóa, kẻ tấn công nhắm vào thiết bị, dùng lừa đảo và tìm cách lấy mã đăng nhập. Vì vậy, câu hỏi đúng là: điện thoại của tôi có khóa không, bản sao lưu đám mây có được mã hóa không và tài khoản email có được bảo vệ không?
Các kênh công khai cũng được mã hóa đầu cuối phải không?
Không. Kênh là không gian phát nội dung công khai có thể đọc được, để có thể xử lý báo cáo và gỡ bỏ nội dung lạm dụng. Theo tài liệu của Livara, trò chuyện trực tiếp và các nhóm riêng tư tương thích được mã hóa đầu cuối khi trạng thái E2EE đang bật. Một nhóm cũ không tương thích có thể vẫn nằm ngoài E2EE, với trạng thái này được hiển thị rõ. Hãy kiểm tra trạng thái của chính cuộc trò chuyện đó. Máy chủ vẫn kiểm soát việc tham gia nhóm.
Làm sao biết phiên bản Android tôi đã cài không bị chỉnh sửa?
So sánh giá trị băm của tệp APK đã tải với mã kiểm tra của đúng phiên bản đó từ một nguồn đáng tin cậy. Phòng kiểm chứng được thiết kế để kiểm tra tệp trong trình duyệt. Giá trị băm trùng khớp chỉ cho biết tệp giống với bản tham chiếu. Nếu kẻ tấn công thay cả tệp lẫn giá trị băm tham chiếu, sự trùng khớp là chưa đủ. Một APK bị chỉnh sửa có thể vượt qua mã hóa, nên kiểm tra tính toàn vẹn của ứng dụng cũng quan trọng như chính việc mã hóa.
