Trình duyệt có thể chạy mật mã mạnh; mã được phân phối đến trình duyệt vẫn phải đáng tin cậy.
Trình duyệt có thể thực hiện mã hóa đầu cuối cục bộ, kể cả thiết lập khóa hậu lượng tử, mà không cần cài ứng dụng nhắn tin gốc. Câu hỏi khó không phải là phép toán có chạy được trong một thẻ hay không. Vấn đề là ứng dụng được phân phối, cách xử lý khóa và đường cập nhật có xứng đáng với mức độ tin cậy mà cuộc trò chuyện yêu cầu hay không.
Truy cập qua web có thể thuận tiện khi không thể cài đặt. Điều đó không khiến ứng dụng miễn nhiễm với kiểm duyệt, hệ thống lưu trữ bị xâm phạm, tiện ích mở rộng độc hại hay thiết bị bị xâm phạm.
Các thành phần mật mã của trình duyệt
WebCrypto cung cấp các thao tác cấp thấp để mã hóa, dẫn xuất khóa, ký và quản lý khóa. Các triển khai phổ biến cung cấp những nguyên thủy như AES-GCM và ECDH. Đây là các thành phần cấu thành, không phải một giao thức nhắn tin có xác thực hoàn chỉnh.
Ứng dụng web có thể bổ sung một triển khai ML-KEM đã được rà soát bằng JavaScript hoặc WebAssembly ở nơi API gốc cần thiết chưa có. Khả năng hỗ trợ của trình duyệt thay đổi, nên nhà phát triển cần kiểm tra tính năng trên đúng các phiên bản mục tiêu, thay vì giả định mọi trình duyệt cung cấp cùng những thuật toán.
Luồng lai ở mức khái niệm gồm:
- Tạo các khóa phù hợp bằng nguồn ngẫu nhiên an toàn về mật mã.
- Xác thực vật liệu khóa của đối tác bằng cơ chế danh tính của giao thức.
- Thu được các phần đóng góp cổ điển và hậu lượng tử cho bí mật chung.
- Kết hợp chúng theo lịch dẫn xuất khóa được chỉ định và ngữ cảnh cuộc trò chuyện.
- Dùng các khóa đã dẫn xuất để mã hóa có xác thực, với cách xử lý nonce và trạng thái chính xác.
Đây là phác thảo giải thích, không phải công thức triển khai. FIPS 203 chuẩn hóa ML-KEM; tiêu chuẩn này không chứng nhận một ứng dụng trình duyệt cụ thể hay định nghĩa mọi bước của giao thức trò chuyện.
Phân phối qua HTTPS là một phần của mô hình tin cậy
Máy chủ thường cung cấp JavaScript và WebAssembly sẽ xử lý bản rõ. Ứng dụng bị sửa đổi ác ý có thể đọc tin nhắn trước khi mã hóa hoặc sau khi giải mã, ngay cả khi thư viện mật mã của nó sử dụng các thuật toán vững chắc.
HTTPS giúp xác thực và bảo vệ việc phân phối khỏi sự can thiệp trên mạng. Nó không chứng minh rằng đơn vị vận hành nguồn gốc, hệ thống triển khai hay các phần phụ thuộc của họ chưa bị xâm phạm. Một trang HTTPS thông thường không tự động trở thành gói ứng dụng được ký độc lập.
Các cân nhắc bảo mật WebCrypto của W3C bàn về chèn mã script và nhu cầu bảo vệ tính toàn vẹn của ứng dụng. Content Security Policy, quản lý cẩn thận các phần phụ thuộc và những biện pháp bảo mật web khác giúp giảm rủi ro, nhưng không biện pháp nào biến mã script tùy ý cùng nguồn gốc thành một bên quan sát không đáng tin không thể chạm vào dữ liệu ứng dụng.
WebAssembly cũng chia sẻ ranh giới bảo mật của ứng dụng. Hộp cát của nó giới hạn truy cập môi trường chủ qua các giao diện được định nghĩa; nó không làm cho trang gọi nó trở nên đáng tin. Biên dịch C sang Wasm không khiến ngôn ngữ nguồn trở nên an toàn về bộ nhớ.
Khóa không nhất thiết chỉ tồn tại trong RAM
Ứng dụng nhắn tin trên trình duyệt có thể lưu bền vững khóa hoặc trạng thái được mã hóa để người dùng quay lại cùng danh tính. Nó cũng có thể cung cấp liên kết thiết bị hoặc khôi phục được mã hóa. Những hành vi này phải được ghi rõ trong tài liệu, không thể mặc nhiên coi là không có.
Các câu hỏi đáng đặt ra gồm:
- Những khóa nào được lưu bền vững, và trong loại lưu trữ nào của trình duyệt?
- Điều gì xảy ra khi dữ liệu trang web bị xóa hoặc phiên duyệt riêng tư kết thúc?
- Mã độc chạy trong ngữ cảnh ứng dụng có còn dùng được khóa không thể trích xuất hay không?
- Một bản cập nhật mới được phân phối có thể truy cập trạng thái cục bộ cũ không?
- Việc khôi phục phục hồi danh tính, lịch sử tin nhắn hay cả hai?
Khóa WebCrypto không thể trích xuất hạn chế việc xuất qua API. Tự nó không ngăn mã ứng dụng thù địch yêu cầu những thao tác được phép hoặc thu thập bản rõ.
Ứng dụng web và ứng dụng gốc có những đánh đổi khác nhau
| Vấn đề | Ứng dụng trình duyệt | Ứng dụng gốc |
|---|---|---|
| Phân phối | Nguồn gốc, hệ thống lưu trữ và quy trình cập nhật web | Cửa hàng ứng dụng hoặc phân phối gói và quy trình ký |
| Lưu trữ bền vững cục bộ | Bộ lưu trữ trình duyệt và hành vi hồ sơ | Bộ lưu trữ ứng dụng của hệ điều hành và vòng đời ứng dụng |
| Phơi nhiễm | Script cùng nguồn gốc, tiện ích mở rộng và lỗ hổng trình duyệt | Các phần phụ thuộc ứng dụng và lỗ hổng hệ điều hành/ứng dụng |
| Khả dụng | Tên miền truy cập được và các dịch vụ mạng cần thiết | Ứng dụng đã cài vẫn cần các dịch vụ mạng cần thiết của nó |
Không cột nào xác định bên thắng nếu chưa xem xét triển khai. Ứng dụng web có thể vẫn truy cập được sau khi bị gỡ khỏi cửa hàng, nhưng tên miền bị chặn hoặc thiếu tuyến mạng vẫn có thể ngăn truy cập.
Đo hiệu năng thay vì hứa hẹn
Theo FIPS 203, ML-KEM-768 dùng khóa đóng gói 1.184 byte và bản mã 1.088 byte. Các kích thước này giúp giải thích vì sao giao thức có thể lên lịch cập nhật KEM thay vì đính kèm vật liệu mới vào mỗi tin nhắn ngắn. Chúng không phải phép đo băng thông hay tốc độ của toàn bộ ứng dụng.
Một phép đo chuẩn hữu ích nêu trình duyệt, thiết bị, bản dựng, phương pháp làm nóng, thao tác được đo và phân bố thời gian. Hãy tính cả khởi động trang, tải mô-đun, sử dụng bộ nhớ, thiết bị cấu hình thấp và chi phí mạng bổ sung. Những tuyên bố như “dưới hai mili giây trên mọi điện thoại hiện đại” cần có số đo được công bố; bài viết này không cung cấp chúng.
Áp dụng cho Livara
Tổng quan bảo mật của Livara ghi lại LVR1 và các giới hạn khôi phục của nó. Proof Lab minh họa một số thao tác cục bộ P-256, HKDF và AES-GCM; trang này nêu rõ rằng toàn bộ tổ hợp LVR1/LGS1 nằm ngoài phạm vi bàn thử đó. Vì thế, một minh họa thành công không chứng minh độ bảo mật của toàn bộ mã web được phân phối.
Trước cuộc trò chuyện nhạy cảm trên trình duyệt, hãy dùng ứng dụng khách chính thống được duy trì, xem mô hình đe dọa hiện tại, bảo vệ hồ sơ trình duyệt và xác minh đối tác qua quy trình kiểm tra khóa được hỗ trợ. Sự thuận tiện và mật mã hữu ích có thể cùng tồn tại, miễn là ranh giới phân phối web vẫn là một phần của đánh giá.
