Mã hóa đầu cuối bằng Signal Protocol và AES-256 trên toàn hệ thống
Sanket (Sanket.Chat) của Tosh Defence mã hóa đầu cuối mọi tin nhắn, lượt bày tỏ cảm xúc và thông điệp gửi rộng được mã hóa bằng Signal Protocol thông qua libsignal chính thức của Signal đã được kiểm toán độc lập, sử dụng cơ chế thỏa thuận khóa PQXDH và Double Ratchet kết hợp SPQR. Tệp, khung hình cuộc gọi, đường truyền cuộc gọi, dữ liệu lưu trữ cục bộ và mọi phiên TLS mà hệ thống cài đặt kết thúc đều sử dụng AES-256, không chuyển dự phòng sang AES-128 và không có chế độ tương thích.
Chỉ dùng AES-256, nếu không thì từ chối thực hiện: đó là chính sách kỹ thuật của SANKET, được thực thi trong mã nguồn. Nếu không thể mã hóa đúng như thiết kế, thao tác sẽ bị từ chối thay vì hạ thấp mức bảo vệ.
Tin nhắn: Signal Protocol, không sửa đổi
Sanket sử dụng thư viện libsignal chính thức của Signal để mã hóa mọi tin nhắn, với cùng một bản phát hành trên iOS, Android, máy tính để bàn và máy chủ. Sanket không tự triển khai lại Signal Protocol và không sử dụng thuật toán mã hóa tin nhắn thay thế.
Phiên được thiết lập bằng PQXDH, phần mở rộng hậu lượng tử của X3DH, kết hợp các thỏa thuận khóa X25519 với cơ chế đóng gói khóa Kyber. Sau đó, các thông điệp được mã hóa bằng Double Ratchet: mỗi khóa thông điệp được mở rộng thành một khóa AES-256, một khóa HMAC-SHA256 và một véc-tơ khởi tạo; thông điệp được mã hóa bằng AES-256 và xác thực bằng HMAC-SHA256; khóa bị xóa sau khi sử dụng. Cơ chế ratchet hậu lượng tử thưa của Signal cũng chạy song song trong mọi phiên.
Theo thiết kế, không có cơ chế dự phòng
Ứng dụng khách từ chối gửi nếu không thể mã hóa bằng libsignal. Những thiết bị không công bố khóa định danh libsignal sẽ bị bỏ qua thay vì được gửi bản rõ, các dấu hiệu bản rõ từ phiên bản cũ bị từ chối, và máy chủ từ chối các bộ khóa không tuân theo định dạng libsignal. Nội dung tin nhắn không có đường xử lý nào sử dụng bản rõ hoặc thuật toán mã hóa thay thế.
Nhóm không dùng khóa chung
Tin nhắn nhóm được mã hóa bằng cách phân phối riêng theo từng cặp: thiết bị gửi mã hóa tin nhắn riêng cho từng thiết bị đáng tin cậy của mỗi thành viên, mỗi thiết bị qua một phiên libsignal riêng. Khi thành viên thay đổi, không cần tạo lại khóa; thành viên bị xóa đơn giản là không còn trong danh sách phân phối.
Trước khi mã hóa, bên gửi kiểm tra danh sách thiết bị của từng tài khoản người nhận, được ký bằng khóa riêng của chính tài khoản đó, và không gửi gì đến thiết bị không có trong danh sách.
Tệp và cuộc gọi
Nội dung, tên và loại tệp đính kèm được mã hóa trên thiết bị bằng AES-256-GCM với một khóa 256 bit ngẫu nhiên riêng cho mỗi tệp, và khóa đó được truyền bên trong thông điệp libsignal.
Cuộc gọi thoại và video được bảo vệ bằng 2 lớp. Các khung dữ liệu của từng người tham gia được mã hóa đầu cuối bằng AES-256-GCM với khóa riêng cho từng người gửi, được cập nhật theo cơ chế ratchet mỗi 200 mili giây, tạo ra 5 khóa khung dữ liệu mới mỗi giây cho mỗi người gửi, đồng thời tạo khóa ngẫu nhiên mới mỗi khi có người tham gia hoặc rời cuộc gọi. Trên đường truyền giữa từng thiết bị và máy chủ truyền thông, SRTP chỉ chấp nhận AEAD_AES_256_GCM. Máy chủ truyền thông chuyển tiếp các khung dữ liệu đã mã hóa mà máy chủ không thể giải mã; thiết kế này không cho phép ghi âm, ghi hình cuộc gọi ở phía máy chủ.
- AES-256-GCM cho từng tệp
- Khóa cuộc gọi riêng cho từng người gửi, không dùng chung khóa cho cả phòng
- 5 khóa khung hình mỗi giây cho mỗi người gửi
- Chỉ sử dụng SRTP AES-256-GCM
Truyền tải và lưu trữ
Mỗi kết nối từ ứng dụng khách sử dụng TLS 1.3 với TLS_AES_256_GCM_SHA384, hoặc TLS 1.2 với ECDHE và AES-256-GCM đối với các bộ giao thức mạng của nền tảng cần cấu hình đó. AES-128, ChaCha20, các bộ mã ở chế độ CBC và RSA tĩnh đều bị loại trừ; nhóm lai có khả năng bảo vệ trước điện toán lượng tử X25519MLKEM768 được ưu tiên đề xuất. Mỗi thiết bị được phê duyệt cũng có thể xác thực bằng chứng chỉ máy khách riêng thông qua TLS hai chiều.
Trên thiết bị, cơ sở dữ liệu cục bộ được mã hóa bằng AES-256 và xác thực bằng HMAC-SHA256; trên điện thoại, kho lưu trữ giao thức và các bí mật của thiết bị được mã hóa bằng khóa có phần cứng bảo vệ trong vùng bảo mật Secure Enclave, StrongBox hoặc môi trường thực thi tin cậy.
Bằng chứng kỹ thuật
Đọc thông tin chi tiết trong sách trắng của Sanket
Mọi nội dung trình bày trên trang này đều được nêu đầy đủ trong tài liệu chuyên khảo công khai về kiến trúc và bảo mật kỹ thuật của SANKET, có thể đọc miễn phí mà không cần đăng ký.
Sanket có sử dụng Signal Protocol không?
Có. Sanket mã hóa mọi tin nhắn trên mọi nền tảng bằng thư viện libsignal chính thức của Signal, sử dụng cơ chế thỏa thuận khóa PQXDH và Double Ratchet cùng SPQR. Nền tảng không có phần triển khai lại giao thức.
Tin nhắn trên SANKET có được mã hóa bằng AES-256 không?
Có. Tin nhắn sử dụng AES-256-CBC cùng HMAC-SHA256 trong libsignal; tệp, khung hình cuộc gọi, luồng truyền cuộc gọi, bộ lưu trữ cục bộ và TLS sử dụng AES-256-GCM. Không có cơ chế chuyển về AES-128.
Các cuộc gọi thoại và video có được mã hóa đầu cuối không?
Có. Các khung dữ liệu cuộc gọi được mã hóa đầu cuối bằng AES-256-GCM với khóa riêng cho từng bên gửi được chuyển qua libsignal, mỗi bên gửi có 5 khóa khung dữ liệu mới mỗi giây, bên trong SRTP chỉ chấp nhận AES-256-GCM.
Biểu cảm và tin quảng bá có được mã hóa không?
Có. Lượt bày tỏ cảm xúc và bản tin phát được mã hóa đều là tin nhắn libsignal, được mã hóa đầu cuối như mọi tin nhắn khác. Mức ưu tiên, hạn chót và thời điểm hết hiệu lực của bản tin phát cũng nằm trong nội dung được mã hóa.
Sanket có sử dụng khóa của người gửi cho nhóm không?
Không. SANKET mã hóa riêng tin nhắn nhóm cho từng thiết bị đáng tin cậy của từng thành viên, mỗi thiết bị qua một phiên libsignal riêng, nên không có khóa chung cho cả nhóm.
Sanket chấp nhận những phiên bản TLS nào?
Ưu tiên TLS 1.3, chỉ với TLS_AES_256_GCM_SHA384. TLS 1.2 chỉ được chấp nhận khi sử dụng ECDHE và AES-256-GCM. Không chấp nhận phiên bản nào thấp hơn TLS 1.2, và cơ chế trao đổi khóa hậu lượng tử lai X25519MLKEM768 được đề xuất đầu tiên.
libsignal đã được kiểm toán chưa?
Có. SANKET được xây dựng trên thư viện libsignal của Signal, đã được kiểm toán độc lập, và giao thức PQXDH đã được phân tích chính thức.
Trao đổi về kỹ thuật mật mã của Sanket với các kỹ sư của chúng tôi
Tosh Defence trình bày từng lớp thiết kế mật mã cho các kiến trúc sư bảo mật và hội đồng đánh giá, đồng thời cung cấp bản tài liệu kỹ thuật lưu hành có kiểm soát theo thỏa thuận bảo mật.