- DM mã hóa mới của Twitter(X) (XChat) về mặt kỹ thuật tuyên bố là mã hóa end-to-end, nhưng vẫn tồn tại các lỗ hổng bảo mật nghiêm trọng như đánh cắp khóa riêng tư, MITM và lộ metadata
- Đã áp dụng Libsodium Box (mã hóa dựa trên khóa bí mật), nhưng do không hỗ trợ forward secrecy và cơ chế bảo vệ khóa yếu dựa trên mã PIN 4 chữ số, nên việc trích xuất khóa riêng tư tương đối dễ dàng
- Dùng giao thức Juicebox để sao lưu/khôi phục khóa, nhưng độ an toàn thực tế phụ thuộc hoàn toàn vào việc tin cậy backend, và vì Twitter tự vận hành toàn bộ backend nên sharding gần như không có nhiều ý nghĩa
- Không có quy trình out-of-band để xác thực/kiểm chứng khóa công khai, nên Twitter có thể tráo khóa để thực hiện MITM (tấn công trung gian), đồng thời metadata người dùng vẫn bị lộ nguyên trạng
- Khác với Signal, hiện tại khả năng bảo vệ quyền riêng tư thực chất vẫn còn thiếu, vì vậy khuyến nghị dùng Signal như một trình nhắn tin mã hóa đáng tin cậy
Phân tích DM mã hóa mới của Twitter
Bối cảnh và tóm tắt
- Twitter(X) đã công bố nền tảng nhắn tin mã hóa mới XChat, được quảng bá là phát triển bằng Rust và áp dụng cấu trúc mã hóa kiểu Bitcoin
- Tuy nhiên khi nhìn vào cách triển khai thực tế, đây vẫn là một kiến trúc cho phép Twitter truy cập khóa riêng tư, thực hiện MITM và thu thập metadata
- Kết luận: nên dùng Signal, DM của Twitter(X) không an toàn do những giới hạn mang tính nền tảng
Cấu trúc mã hóa và các giới hạn
1. Phương thức mã hóa
- Sử dụng box của Libsodium (mã hóa khóa công khai)
- Không hỗ trợ forward secrecy: nếu khóa riêng tư bị lộ, toàn bộ tin nhắn trước đó đều có thể bị giải mã (tức là yếu hơn các trình nhắn tin hiện đại như Signal)
- Triển khai thực tế không dùng Rust mà dùng thư viện C (ràng buộc qua jni)
2. Lưu trữ và khôi phục khóa (giao thức Juicebox)
- Khóa riêng tư được tạo trên thiết bị sẽ được lưu bằng giao thức Juicebox
- Khóa được lưu sau khi mã hóa bằng PIN 4 chữ số, và khi khôi phục cần nhập PIN
- Máy chủ không biết PIN, nhưng vì PIN chỉ có 4 chữ số (10.000 khả năng), nên có thể bị bẻ rất nhanh bằng brute-force song song
- Dù áp dụng Argon2id với bộ nhớ 16MB và 32 vòng lặp, đây vẫn không phải trở ngại lớn với kẻ tấn công thực tế (ngay cả laptop cấu hình thấp cũng dưới 0,2 giây)
3. Giới hạn của cấu trúc phân mảnh khóa (sharding)
- Juicebox hỗ trợ phân tán qua nhiều backend (sharding), nhưng Twitter trực tiếp vận hành cả 3 backend
- Kết quả là quá trình khôi phục khóa cuối cùng vẫn phụ thuộc hoàn toàn vào việc tin cậy Twitter, nên không có lợi ích bảo mật cốt lõi nào từ sharding
- Cũng không có quy trình xác thực phần cứng như HSM hay SGX để giao tiếp an toàn với backend
4. Điểm yếu trong xác thực/trao đổi khóa công khai
- Khóa công khai của đối phương chỉ được nhận qua máy chủ Twitter, không có phương thức kiểm chứng riêng (out-of-band)
- Twitter có thể cung cấp khóa công khai tùy ý để thực hiện tấn công trung gian (MITM) bất cứ lúc nào
- Trang hỗ trợ chính thức cũng thừa nhận điểm yếu này và chỉ hứa sẽ cải thiện về sau, nhưng hiện chưa có biện pháp thực chất nào
5. Metadata và các vấn đề khác
- Twitter vẫn có thể biết đầy đủ ai nhắn cho ai, nhắn khi nào và các metadata tương tự
- Ngay cả khi khóa riêng tư không bị lộ, mô hình giao tiếp của người dùng vẫn bị phơi bày trước công ty
Kết luận và khuyến nghị
- Do những giới hạn trong thiết kế của DM mã hóa, hệ thống này không thể sánh với các trình nhắn tin đã được kiểm chứng như Signal về mặt bảo mật và quyền riêng tư
- Chừng nào Twitter còn kiểm soát cả khóa công khai, kho khóa và đường truyền liên lạc thì không thể xem đây là end-to-end encryption đúng nghĩa
- Rất khuyến nghị sử dụng các ứng dụng nhắn tin với giao thức công khai và minh bạch như Signal
1 bình luận
Ý kiến Hacker News
Tôi vốn là người hâm mộ và thích mọi bài viết của Matthew Garrett, nhưng cũng muốn nhấn mạnh một cách khá ám ảnh rằng Signal từ lâu đã luôn hỗ trợ tính năng forward secrecy. Khái niệm trình nhắn tin an toàn hiện đại gần như được khai sinh khi OTR (Borisov và Goldberg) lần đầu giới thiệu các khái niệm về "perfect forward secrecy" và khả năng chối bỏ. Theo tôi, Signal là kết quả của việc phát triển cả những ý tưởng đó lẫn khía cạnh kỹ thuật để hiện thực hóa chúng (mã hóa tốt hơn, mã nguồn tốt hơn, đóng gói tốt hơn). Điều gây bực bội là các trình nhắn tin mới đang không lùi về mức "tiền-Signal", mà lùi hẳn về mức bảo mật trước năm 2001, tức là trước thời kỳ hiện đại
Có ba điều cần nhớ từ nhiều vụ rò rỉ trước đây. (1) FBI từng "ép buộc" các công ty âm thầm cài backdoor. Cũng từng có đề cập rằng tòa FISA có thể áp các khoản phạt mang tính hủy diệt lên doanh nghiệp. (2) Họ trả cho các tập đoàn lớn những khoản từ hàng chục triệu đến hàng trăm triệu để bù chi phí backdoor. Ngoài ra còn gây sức ép bằng nhiều cách như hợp đồng chính phủ hoặc giấy phép xuất khẩu. Rốt cuộc có thể hiểu đây là kiểu chính sách "tiền hoặc súng". (3) Trong vụ Lavabit, FBI vừa yêu cầu giao nộp khóa vừa gần như ép công ty nói dối khách hàng. Khi nhớ lại những trường hợp như vậy, rất dễ nghi ngờ rằng mã hóa bên trong các nền tảng lớn thường xuyên bị cố ý làm yếu đi theo yêu cầu của chính phủ, hoặc được triển khai hời hợt vì đơn giản là không quan tâm. Chừng nào Patriot Act, FISC, các diễn giải bí mật và những luật lệ, thông lệ liên quan chưa biến mất và người vi phạm chưa bị trừng phạt, tôi mặc định rằng mã hóa trong nhà nước cảnh sát này đã bị Five Eyes phá hỏng từ lâu
Chừng nào mọi người còn cài ứng dụng trên PC thông qua App Store, tình trạng lạc hậu này sẽ còn tiếp diễn
Nếu dùng ephemeral key mà lại không có forward secrecy hay thậm chí không có lịch sử tương tác, thì khó hiểu điểm nào mới thật sự là kiểu 'bitcoin style'
Có dùng kỹ thuật mật mã thật, nhưng nhìn chung giống một nhánh phái sinh nhàm chán và gần như vô dụng
Ý là hầu như không có giá trị ứng dụng thực tế
Bản thân Bitcoin cũng không phải là kênh liên lạc an toàn
Có chỗ dùng cơ chế dẫn xuất khóa dựa trên PIN. Nhưng cách này giống với triển khai sao lưu hơn là bản thân việc nhắn tin, nên cũng khó xem đó là đặc trưng cốt lõi
Có nhắc đến việc dùng hàm băm
Chia sẻ liên kết thảo luận trước đó:
XChat "mã hóa" mới của X cũng chẳng an toàn hơn bao nhiêu
Xem bình luận liên quan
Nếu đã muốn mã hóa thì có lẽ tốt hơn nên dùng phần mềm riêng, và trao đổi khóa công khai trực tiếp khi gặp mặt
Câu hỏi: Tôi sắp đến Bắc Kinh, không biết có thể dùng Twitter mà không cần VPN không
Có người thắc mắc về cụm từ "Bitcoin style encryption". Trên thực tế, Bitcoin theo hiểu biết thông thường không dựa vào "encryption" như ta hay nói, mà phụ thuộc nhiều hơn vào kỹ thuật chữ ký mật mã
Thuật ngữ này thật ra chẳng có ý nghĩa gì, chỉ là từ marketing để nghe có vẻ thuyết phục với những người không rành kỹ thuật
Cũng nên lưu ý rằng nguồn gốc của phát biểu đó vốn không phải từ một người quá sâu về kỹ thuật
Họ dùng cụm từ này vì biết trước nó sẽ gây tranh cãi. Có thể xem đây là lựa chọn mang tính chiến lược để thu hút thêm chú ý
Chia sẻ liên kết video giải thích
https://www.youtube.com/watch?v=sJNK4VKeoBM
Chỉ là kiểu từ ngữ thời thượng để làm nó trông ngầu hơn, như thể là thứ “có giá trị”
Không biết XChat thật sự (trình khách IRC) có thể kiện X-Twitter vì vi phạm nhãn hiệu hay không
http://xchat.org/
Tôi từng là người dùng IRC vào thời XChat chuyển sang HexChat, nên khá hoài niệm. Nhưng cũng ngạc nhiên khi biết HexChat đã ngừng phát triển
Tin ngừng phát triển HexChat
Có lẽ là được, nhưng phía XChat sẽ phải chứng minh khá rõ giá trị thương mại ở từng lĩnh vực mà X bị cho là xâm phạm, đồng thời phải có đăng ký nhãn hiệu tại từng khu vực thì mới dễ được công nhận hơn. Nếu không thì sẽ khó hơn
Điều thú vị về thư viện mà Twitter dùng (theo bài nguồn) là chính tác giả thư viện đã tự viết trong phần mô tả rằng
“Cảnh báo: thư viện thử nghiệm! Đừng dùng nó cho production cho đến khi được rà soát. Rủi ro và khả năng có lỗi rất lớn”
https://github.com/ionspin/kotlin-multiplatform-libsodium
Thật đáng kinh ngạc là sức mạnh thương hiệu Twitter quá lớn nên sau khi đổi thương hiệu, nó vẫn chưa hề mất đi sức sống