Văn hay trong hiện tại, chữ tốt ở tương lai

Giao thức X3DH – Thiết lập khóa bí mật bất đồng bộ đầu cuối

Extended Triple Diffie–Hellman là giao thức thiết lập khóa bí mật chung trong môi trường không đồng bộ với xác thực lẫn nhau, bảo mật chuyển tiếp.

31 phút đọc.

0 lượt xem.

Thuật toán X3DH là giao thức trao đổi khóa được thiết kế đặc biệt cho các ứng dụng nhắn tin mã hóa đầu cuối, với mục tiêu tối cao là đảm bảo tính bảo mật và chống lại các cuộc tấn công nghe trộm.

Giới thiệu

Bài viết này mô tả giao thức thỏa thuận khóa X3DH (hoặc Extended Triple Diffie–Hellman – Trao đổi Diffie–Hellman ba chiều mở rộng). X3DH thiết lập một khóa bí mật chung giữa hai bên, những người xác thực lẫn nhau dựa trên khóa công khai. X3DH cung cấp tính bảo mật chuyển tiếp và khả năng từ chối mật mã – hai tính chất cốt lõi của mọi hệ thống nhắn tin bảo mật hiện đại.

Khác biệt căn bản so với các phương pháp trao đổi khóa truyền thống, X3DH kết hợp ba hoặc bốn phép tính Diffie–Hellman song song để tạo ra một khóa phiên vừa có tính xác thực lẫn nhau vừa có tính bảo mật chuyển tiếp. Không một phép DH đơn lẻ nào có thể đảm bảo đồng thời cả hai tính chất đó: DH thông thường cung cấp tính bí mật nhưng không xác thực danh tính; chữ ký xác thực danh tính nhưng để lại bằng chứng mật mã có thể công bố. X3DH kết hợp thông minh cả hai để đạt được xác thực lẫn nhau mà không hi sinh khả năng phủ nhận.

X3DH được thiết kế cho môi trường không đồng bộ, nơi người nhận (Đan Nguyên) có thể đang ngoại tuyến khi người gửi (Mỹ Anh) muốn khởi tạo liên lạc. Đây là bài toán đặc trưng của nhắn tin di động hiện đại: không giống giao tiếp thời gian thực, các bên không cần đồng thời trực tuyến để thiết lập phiên mã hóa. Đan Nguyên giải quyết vấn đề này bằng cách tải trước một tập khóa tiền (prekeys) lên máy chủ; Mỹ Anh sử dụng chúng để tính toán khóa phiên SK và gửi tin nhắn đầu tiên mà không cần Đan Nguyên phải trực tuyến tại thời điểm đó. Ứng dụng thực tế của X3DH được chứng minh qua Signal, WhatsApp và nhiều nền tảng nhắn tin bảo mật khác – nơi hàng tỷ phiên mã hóa được thiết lập mỗi ngày theo đúng cơ chế này.

Kiến thức cơ bản

Để hiểu đầy đủ hoạt động của X3DH, cần nắm rõ bốn nền tảng kỹ thuật: các tham số cấu hình quyết định đường cong và hàm băm được dùng; ký hiệu mật mã định nghĩa ngôn ngữ toán học của giao thức; mô hình vai trò xác định quan hệ giữa các bên tham gia; và hệ thống khóa mô tả từng loại khóa cùng vòng đời của chúng.

Các tham số của X3DH

Một ứng dụng sử dụng X3DH phải thống nhất trước một bộ tham số cấu hình, vì các tham số này ảnh hưởng trực tiếp đến mức độ bảo mật, kích thước khóa và khả năng tương tác giữa các triển khai. Lựa chọn tham số không nhất quán giữa hai bên sẽ dẫn đến thất bại giao thức ngay cả khi cả hai triển khai đều đúng về mặt kỹ thuật. Vì vậy, các tham số này thường được quy định cố định ở cấp độ giao thức ứng dụng, không phải do người dùng tự chọn.

TênĐịnh nghĩa
CurveX25519 hoặc X448.
Hàm băm (hash)Một hàm băm 256 hoặc 512 bit (Ví dụ: SHA256 hoặc SHA512).
Mô tả (info)Một chuỗi ASCII xác định ứng dụng, có độ dài tối thiểu 8 byte.

Tham số curve xác định đường cong elliptic nền tảng. X25519 (Curve25519) cung cấp khoảng 128 bit bảo mật với khóa công khai 32 byte – phù hợp cho hầu hết ứng dụng nhắn tin thời gian thực, nơi hiệu suất và kích thước dữ liệu quan trọng. X448 (Curve448) cung cấp khoảng 224 bit bảo mật với khóa công khai 57 byte – phù hợp khi cần biên an toàn lớn hơn, chẳng hạn để bảo vệ dữ liệu trong nhiều thập kỷ hoặc trước các đối thủ có tài nguyên đặc biệt mạnh. Tham số hash xác định hàm băm dùng trong HKDF để dẫn xuất khóa. Với X25519, SHA256 là đủ và hiệu quả hơn; với X448, SHA512 cung cấp biên bảo mật phù hợp hơn với độ mạnh của đường cong. Tham số info là một chuỗi định danh ứng dụng được đưa vào quá trình dẫn xuất khóa HKDF nhằm đảm bảo phân tách miền: khóa SK do X3DH tạo ra cho ứng dụng MyProtocol không thể bị nhầm lẫn hay tái sử dụng cho ứng dụng khác, ngay cả khi cùng cặp khóa được dùng.

Ngoài ra, ứng dụng phải xác định hàm mã hóa Encode(PK) để chuyển đổi khóa công khai X25519 hoặc X448 thành chuỗi byte. Cách mã hóa được khuyến nghị gồm một byte hằng số biểu thị loại đường cong, tiếp theo là mã hóa little-endian của tọa độ u. Việc bao gồm byte định danh đường cong trong quá trình mã hóa ngăn chặn các cuộc tấn công nhầm lẫn đường cong, trong đó kẻ tấn công cố gắng sử dụng khóa của một đường cong như thể nó thuộc đường cong khác.

Ký hiệu mật mã

X3DH sử dụng một hệ thống ký hiệu nhất quán để mô tả các phép toán mật mã, giúp đặc tả trở nên chính xác và không mơ hồ.

Phép nối hai chuỗi byte XY được ký hiệu là X || Y. Khi nối nhiều giá trị, thứ tự nối có ý nghĩa mật mã quan trọng và phải được tuân thủ chính xác. DH(PK1, PK2) biểu thị chuỗi byte là đầu ra của hàm Elliptic Curve Diffie–Hellman, được tính dựa trên cặp khóa liên quan đến các khóa công khai PK1PK2. Hàm này là X25519 hoặc X448 tùy theo tham số đường cong. Lưu ý rằng DH là đối xứng – DH(PK1, PK2)DH(PK2, PK1) cho cùng kết quả – nhưng ký hiệu trong X3DH quy ước rõ bên nào giữ khóa riêng của cặp khóa nào để tránh nhầm lẫn triển khai.

Sig(PK, M) biểu thị chữ ký XEdDSA trên chuỗi byte M, có thể xác minh bằng khóa công khai PK và được tạo bằng cách ký M với khóa riêng tương ứng. Việc dùng XEdDSA thay vì EdDSA thông thường cho phép cùng định dạng khóa Montgomery được dùng cho cả Diffie–Hellman lẫn ký số – đây là lý do cốt lõi tại sao X3DH có thể hoạt động chỉ với một bộ khóa duy nhất cho mỗi người dùng.

KDF(KM) biểu thị đầu ra 32 byte từ thuật toán HKDF với các đầu vào cụ thể: khóa đầu vào HKDF là F || KM, trong đó KM là chuỗi byte chứa vật liệu khóa bí mật và F là chuỗi 32 byte 0xFF (với X25519) hoặc 57 byte 0xFF (với X448). Chuỗi F phục vụ mục đích phân tách miền với XEdDSA: nó đảm bảo rằng các bit đầu vào HKDF đầu tiên không bao giờ là mã hóa hợp lệ của một số vô hướng hay điểm đường cong, ngăn chặn các cuộc tấn công chéo miền. Muối HKDF là chuỗi byte toàn số 0 có độ dài bằng đầu ra hàm băm. Thông tin HKDF là tham số info của ứng dụng, hoàn thành việc phân tách miền ở cấp độ ứng dụng.

Các vai trò

Giao thức X3DH bao gồm ba thực thể với vai trò và mức độ tin cậy khác nhau. Sự phân tách vai trò này không chỉ là quy ước đặt tên mà phản ánh mô hình đối thủ thực tế: giao thức được thiết kế để bảo mật ngay cả khi máy chủ hoạt động không trung thực.

Mỹ Anh là bên chủ động (initiator): muốn gửi dữ liệu ban đầu cho Đan Nguyên bằng mã hóa và thiết lập khóa bí mật chung SK phục vụ liên lạc hai chiều về sau. Mỹ Anh thực hiện toàn bộ quá trình tính toán phía gửi mà không cần Đan Nguyên trực tuyến, dựa hoàn toàn vào thông tin Đan Nguyên đã công bố trước lên máy chủ. Điều này đặt Mỹ Anh vào vị thế phải tin tưởng rằng thông tin nhận được từ máy chủ là chính xác – một giả định được giảm thiểu rủi ro thông qua cơ chế chữ ký trên các khóa tiền.

Đan Nguyên là bên bị động (responder): muốn cho phép những người như Mỹ Anh thiết lập khóa chung và gửi dữ liệu mã hóa, trong khi bản thân có thể đang ngoại tuyến. Để hỗ trợ điều này, Đan Nguyên duy trì mối quan hệ với máy chủ và tải lên trước một tập khóa tiền. Vòng đời khóa của Đan Nguyên phức tạp hơn Mỹ Anh vì phải quản lý đồng thời khóa định danh dài hạn, khóa tiền ký định kỳ và tập khóa tiền một lần.

Máy chủ đóng vai trò lưu trữ và chuyển tiếp tin nhắn từ Mỹ Anh đến Đan Nguyên, đồng thời cung cấp khóa tiền của Đan Nguyên cho Mỹ Anh khi có yêu cầu. Mức độ tin cậy đặt vào máy chủ được thiết kế để tối thiểu: một máy chủ trung thực chỉ cần thiết để việc liên lạc diễn ra thành công, nhưng ngay cả khi máy chủ hoạt động không trung thực, nó không thể đọc nội dung tin nhắn hay giả mạo danh tính của các bên (miễn là các bên đã xác minh khóa định danh của nhau qua kênh ngoài băng). Trong các hệ thống thực tế, vai trò của máy chủ có thể được phân tách giữa nhiều thực thể, nhưng đặc tả X3DH giả định một máy chủ duy nhất để đơn giản hóa mô tả.

Các khóa

X3DH sử dụng năm loại khóa công khai đường cong elliptic với vai trò và vòng đời khác nhau. Hiểu rõ từng loại khóa là điều kiện để nắm bắt tại sao X3DH cung cấp đồng thời xác thực lẫn nhau và bảo mật chuyển tiếp mà không cần hai bên đồng thời trực tuyến.

TênĐịnh nghĩa
IKAKhóa nhận dạng của Mỹ Anh.
EKAKhóa tạm thời của Mỹ Anh.
IKBKhóa nhận dạng của Đan Nguyên.
SPKBKhóa tiền ký (signed prekey) có chữ ký của Đan Nguyên.
OPKBKhóa tiền một lần (one-time prekey) của Đan Nguyên.

Tất cả các khóa công khai được sử dụng trong một phiên X3DH phải đồng nhất về loại đường cong: hoặc tất cả là X25519, hoặc tất cả là X448.

Khóa nhận dạng IKAIKB là các khóa dài hạn, ổn định trong suốt vòng đời tài khoản. Chúng là nền tảng của xác thực: khi Mỹ Anh và Đan Nguyên xác minh dấu vân tay khóa nhận dạng của nhau qua kênh ngoài băng, mọi giao tiếp sau đó được ràng buộc với danh tính đã xác minh. IKA tham gia vào DH1 để cung cấp tính xác thực phía gửi; IKB tham gia vào DH2 để cung cấp tính xác thực phía nhận.

Khóa tạm thời EKA do Mỹ Anh tạo mới cho mỗi phiên X3DH và bị xóa ngay sau khi hoàn tất tính toán. Tính ngắn hạn của khóa này là nguồn gốc của bảo mật chuyển tiếp: DH3 và DH4 phụ thuộc vào EKA, và khi EKA bị xóa, toàn bộ phiên không thể tái tạo ngay cả khi kẻ tấn công sau này có được các khóa dài hạn.

Khóa tiền ký SPKB được thay thế định kỳ và mỗi phiên đều được ký bằng IKB trước khi tải lên. Chữ ký này cho phép Mỹ Anh xác minh rằng SPKB thực sự do Đan Nguyên tạo ra, ngăn máy chủ độc hại thay thế bằng khóa giả mạo. Khóa tiền một lần OPKB chỉ được sử dụng trong một phiên duy nhất: máy chủ cung cấp một OPKB và xóa nó ngay sau đó; Đan Nguyên xóa khóa riêng OPKB khi xử lý tin nhắn tương ứng. DH4 sử dụng OPKB cung cấp bảo mật chuyển tiếp mạnh nhất vì cả hai phía đều xóa dữ liệu liên quan, đảm bảo không ai có thể tái tạo đầu ra DH đó về sau.

Giao thức X3DH

X3DH triển khai qua ba giai đoạn tuần tự: Đan Nguyên công bố khóa tiền lên máy chủ; Mỹ Anh truy xuất gói khóa tiền và gửi tin nhắn ban đầu; Đan Nguyên nhận và xử lý tin nhắn đó. Ba giai đoạn này có thể diễn ra không đồng bộ theo thời gian – giai đoạn một có thể xảy ra nhiều ngày trước giai đoạn hai, và giai đoạn ba có thể xảy ra khi Đan Nguyên trực tuyến trở lại sau nhiều giờ.

Công bố khóa

Đan Nguyên công bố một tập hợp khóa công khai elliptic lên máy chủ, bao gồm: khóa nhận dạng IKB; khóa tiền ký SPKB cùng chữ ký Sig(IKB, Encode(SPKB)); và tập hợp các khóa tiền một lần (OPKB1, OPKB2, OPKB3…).

Cấu trúc này giải quyết bài toán bảo mật cốt lõi của giao thức bất đồng bộ: làm thế nào để Mỹ Anh có thể tính toán khóa phiên với Đan Nguyên mà không cần Đan Nguyên trực tuyến, trong khi vẫn đảm bảo không có bên thứ ba nào – kể cả máy chủ – có thể tính toán khóa đó. Câu trả lời là Đan Nguyên công bố trước toàn bộ vật liệu cần thiết cho Diffie–Hellman, nhưng giữ bí mật tuyệt đối các khóa riêng tương ứng. Máy chủ chỉ có khóa công khai, không đủ để thực hiện phép DH. Chữ ký của IKB trên SPKB ràng buộc khóa tiền ký với danh tính dài hạn của Đan Nguyên, ngăn máy chủ thay thế SPKB bằng khóa của chính mình mà không bị phát hiện.

Chính sách vòng đời khóa của Đan Nguyên gồm ba lớp. IKB chỉ cần tải lên một lần duy nhất và không thay đổi trong suốt vòng đời tài khoản. SPKB được thay thế định kỳ – thường mỗi tuần hoặc mỗi tháng – và mỗi lần thay thế, khóa SPKB mới được tải lên cùng chữ ký mới. Sau khi tải SPKB mới, Đan Nguyên nên giữ lại khóa riêng của SPKB cũ trong thời gian ngắn để xử lý các tin nhắn đã gửi trước khi chuyển đổi nhưng chưa đến tay Đan Nguyên. Cuối cùng, Đan Nguyên xóa khóa riêng SPKB cũ để đảm bảo bảo mật chuyển tiếp. Các khóa OPKB được tiêu thụ một lần: khi máy chủ cấp một OPKB cho Mỹ Anh, OPKB đó bị xóa khỏi kho và không bao giờ được cấp lại. Đan Nguyên cần thường xuyên tải thêm OPKB mới để duy trì kho không bị cạn – nhiều triển khai tự động thực hiện điều này khi máy chủ thông báo kho sắp hết.

Việc vắng mặt của OPKB trong gói khóa tiền – khi kho đã cạn – không phá vỡ giao thức mà chỉ làm giảm mức độ bảo mật chuyển tiếp của phiên đó: SK vẫn được tính đúng nhưng sẽ phụ thuộc vào SPKB thay vì OPKB, và khả năng phục hồi sau xâm phạm SPKB kém hơn. Đây là sự đánh đổi có chủ ý: khả năng giao tiếp (availability) được ưu tiên hơn mức độ bảo mật tối đa khi tài nguyên hạn chế.

Gửi tin nhắn ban đầu

Để thực hiện thỏa thuận khóa X3DH với Đan Nguyên, Mỹ Anh liên hệ máy chủ và truy xuất một gói khóa tiền (prekey bundle) gồm: IKB, SPKB cùng chữ ký Sig(IKB, Encode(SPKB)), và tùy chọn một OPKB.

Bước đầu tiên và quan trọng nhất của Mỹ Anh là xác minh chữ ký trên SPKB. Nếu xác minh thất bại, Mỹ Anh hủy giao thức ngay lập tức vì điều đó chứng tỏ máy chủ đã can thiệp vào gói khóa tiền. Đây là rào cản chống lại cuộc tấn công mạnh nhất mà máy chủ có thể thực hiện: thay thế SPKB bằng khóa mà máy chủ biết khóa riêng, rồi sau này dùng khóa đó để tính SK. Chữ ký của IKB trên SPKB làm cho cuộc tấn công này bất khả thi miễn là IKB chưa bị xâm phạm.

Sau khi xác minh thành công, Mỹ Anh tạo cặp khóa tạm thời mới với khóa công khai EKA, rồi thực hiện các phép tính DH. Nếu gói khóa tiền không có OPKB:

DH1 = DH(IKA, SPKB)
DH2 = DH(EKA, IKB)
DH3 = DH(EKA, SPKB)
SK = KDF(DH1 || DH2 || DH3)

Nếu có OPKB, thêm một phép tính DH nữa:

DH4 = DH(EKA, OPKB)
SK = KDF(DH1 || DH2 || DH3 || DH4)

Ý nghĩa của từng phép DH là cụ thể và không thể hoán đổi. DH1 = DH(IKA, SPKB) kết hợp khóa định danh dài hạn của Mỹ Anh với khóa tiền định kỳ của Đan Nguyên, cung cấp tính xác thực phía gửi và một phần bảo mật chuyển tiếp. DH2 = DH(EKA, IKB) kết hợp khóa tạm thời của Mỹ Anh với khóa định danh dài hạn của Đan Nguyên, cung cấp tính xác thực phía nhận. DH3 = DH(EKA, SPKB) kết hợp khóa tạm thời của Mỹ Anh với khóa tiền định kỳ của Đan Nguyên, tăng cường bảo mật chuyển tiếp. DH4 = DH(EKA, OPKB) bổ sung tính bảo mật chuyển tiếp mạnh nhất nhờ OPKB chỉ dùng một lần. Toàn bộ bốn giá trị DH được nối lại và đưa qua KDF để tạo SK – không ai có thể tính SK nếu không biết đồng thời ít nhất một trong các khóa riêng tương ứng.

Sau khi tính SK, Mỹ Anh xóa ngay khóa riêng tạm thời và tất cả giá trị DH trung gian. Mỹ Anh tính chuỗi byte AD = Encode(IKA) || Encode(IKB) (có thể bổ sung thêm thông tin nhận dạng như tên người dùng hay chứng chỉ), rồi gửi tin nhắn ban đầu cho Đan Nguyên gồm: IKA, EKA, định danh các khóa tiền đã dùng và bản mã ban đầu được mã hóa bằng AEAD với AD là dữ liệu liên kết và SK là khóa mã hóa.

Nhận tin nhắn ban đầu

Sau khi nhận tin nhắn ban đầu từ Mỹ Anh, Đan Nguyên trích xuất IKA và EKA từ phần tiêu đề, tải khóa riêng nhận dạng của mình và dùng các định danh khóa tiền trong tin nhắn để xác định và tải khóa riêng SPKB cùng OPKB (nếu có) đã được Mỹ Anh sử dụng. Đây là bước quan trọng: Đan Nguyên phải dùng đúng khóa riêng tương ứng với khóa công khai mà Mỹ Anh đã dùng để tính DH, nếu không SK sẽ không khớp và giải mã sẽ thất bại.

Với các khóa riêng đã có, Đan Nguyên thực hiện lại đúng trình tự các phép tính DH và KDF giống như Mỹ Anh đã làm, thu được cùng giá trị SK. Tính đúng đắn của bước này dựa trên tính chất đối xứng của Diffie–Hellman: DH(IKA, SPKB) – tính từ phía Mỹ Anh với khóa riêng IKA và khóa công khai SPKB – cho kết quả bằng DH(SPKB, IKA) – tính từ phía Đan Nguyên với khóa riêng SPKB và khóa công khai IKA. Nguyên lý tương tự áp dụng cho tất cả các phép DH còn lại.

Đan Nguyên tính AD theo cách giống Mỹ Anh rồi thử giải mã bản mã ban đầu bằng SK và AD. Nếu giải mã thất bại – do xác thực AEAD không thành công – Đan Nguyên hủy giao thức, xóa SK và loại bỏ toàn bộ trạng thái của phiên này. Giải mã thất bại có thể do dữ liệu bị hỏng trên đường truyền, do Mỹ Anh dùng sai tham số, hoặc do máy chủ đã can thiệp vào tin nhắn. AEAD đảm bảo bất kỳ thay đổi nào đối với bản mã hay AD đều bị phát hiện, nên Đan Nguyên có thể tin tưởng rằng nếu giải mã thành công, nội dung tin nhắn là nguyên vẹn và SK thực sự là khóa được Mỹ Anh tính.

Nếu giải mã thành công, giao thức hoàn tất cho Đan Nguyên. Anh xóa ngay khóa riêng OPKB đã dùng để đảm bảo bảo mật chuyển tiếp – sau thời điểm này, không ai có thể tái tạo DH4, và do đó không thể tái tạo SK ngay cả khi có toàn bộ dữ liệu trên đường truyền. Cả hai bên lúc này đều có SK và có thể chuyển sang giao thức liên lạc sau X3DH – thường là Double Ratchet – sử dụng SK làm khóa gốc ban đầu.

Cân nhắc về bảo mật

X3DH được thiết kế dựa trên mô hình đối thủ mạnh: kẻ tấn công có thể kiểm soát hoàn toàn kênh truyền, có thể vận hành máy chủ độc hại, và có thể thu thập khóa bị xâm phạm về sau. Phần này phân tích từng góc độ bảo mật và giới hạn của giao thức trong từng tình huống.

Xác thực

Cơ chế xác thực mật mã trong X3DH dựa hoàn toàn vào khóa định danh dài hạn IKA và IKB. Tuy nhiên, bản thân giao thức không thể đảm bảo rằng IKB thực sự thuộc về người mà Mỹ Anh tin là Đan Nguyên – đây là bài toán ràng buộc danh tính (identity binding) nằm ngoài phạm vi X3DH. Giao thức chỉ đảm bảo rằng nếu IKB đã được xác thực trước đó, thì SK do X3DH tạo ra thực sự được chia sẻ với chủ nhân của IKB – không ai khác.

Phương pháp xác thực phổ biến nhất là so sánh dấu vân tay khóa công khai qua kênh ngoài băng: hai người dùng có thể quét mã QR từ màn hình của nhau, đọc to chuỗi số an toàn qua điện thoại, hay xác nhận qua một kênh đã được tin cậy trước đó. Các nền tảng như Signal hiển thị số an toàn (Safety Number) – một chuỗi số ngắn tính từ cặp IKA và IKB – giúp việc xác nhận bằng lời nói hoặc thị giác trở nên thực tiễn với người dùng phổ thông. Nếu xác thực không được thực hiện, các bên không có bất kỳ đảm bảo mật mã nào về danh tính thực sự của người mình đang liên lạc: toàn bộ bảo mật nội dung vẫn hoạt động, nhưng không ai có thể chắc chắn nội dung đó được gửi đến đúng người.

Xác thực trong X3DH không bền vững vô hạn. Nếu khóa định danh của một bên thay đổi – do cài đặt lại ứng dụng, thay điện thoại hay bị xâm phạm – bước xác thực cần được lặp lại. Các ứng dụng cần thông báo rõ cho người dùng khi khóa định danh của liên lạc thay đổi, để tránh tình huống người dùng nghĩ mình đang liên lạc với người đã xác thực trong khi thực tế đang liên lạc với thiết bị hoặc danh tính chưa được xác minh.

Phát lại giao thức

Nếu tin nhắn ban đầu của Mỹ Anh không dùng OPKB, tin nhắn đó có thể bị phát lại nhiều lần đến Đan Nguyên và anh sẽ chấp nhận mỗi lần. Điều này xảy ra vì tin nhắn ban đầu không chứa yếu tố nào ràng buộc nó với một phiên duy nhất: SPKB vẫn còn hợp lệ, IKA vẫn là khóa nhận dạng của Mỹ Anh, và EKA là khóa tạm thời do Mỹ Anh đã tạo. Kẻ tấn công có được bản sao tin nhắn ban đầu – ngay cả khi không thể giải mã nội dung – có thể gửi lại nhiều lần, khiến Đan Nguyên tạo ra nhiều phiên riêng biệt với cùng SK và xử lý cùng bản mã ban đầu nhiều lần.

Hậu quả thực tế là Đan Nguyên có thể nghĩ rằng Mỹ Anh đã gửi cùng một tin nhắn lặp đi lặp lại, hoặc tệ hơn là cùng một phiên bị tái sử dụng với SK đồng nhất – một vi phạm bảo mật nghiêm trọng nếu giao thức sau X3DH không xử lý trường hợp tái sử dụng khóa đúng cách. Biện pháp giảm thiểu phổ biến nhất là sử dụng OPKB khi có thể: vì OPKB bị xóa ngay sau lần dùng đầu tiên, tin nhắn ban đầu dùng OPKB không thể phát lại thành công vì Đan Nguyên không còn khóa riêng OPKB để tính DH4. Khi không có OPKB, giao thức sau X3DH – thường là Double Ratchet – cần nhanh chóng đàm phán khóa mã hóa mới dựa trên đầu vào ngẫu nhiên mới từ Đan Nguyên, thay thế SK bằng khóa phiên không thể tái sử dụng. Cơ chế ratcheting của Double Ratchet thực hiện điều này một cách tự nhiên ngay trong tin nhắn đầu tiên Đan Nguyên gửi phản hồi.

Phát lại và tái sử dụng khóa

Hệ quả trực tiếp từ vấn đề phát lại: nếu tin nhắn ban đầu được phát lại thành công, Đan Nguyên có thể tạo ra cùng một SK trong các lần thực thi giao thức khác nhau. Hai phiên khác nhau dùng cùng SK là thảm họa bảo mật nếu giao thức sau X3DH dùng SK trực tiếp để mã hóa: cùng khóa mã hóa hai bản mã khác nhau cho phép kẻ tấn công khôi phục nội dung qua phân tích XOR trong nhiều sơ đồ mã hóa.

Vì lý do này, bất kỳ giao thức sau X3DH nào cũng phải ngẫu nhiên hóa khóa mã hóa trước khi Đan Nguyên gửi dữ liệu mã hóa. Cách đúng đắn là Đan Nguyên sử dụng giao thức dựa trên DH có cơ chế ratcheting để kết hợp SK với một đầu ra DH mới được tạo ngẫu nhiên, tạo ra khóa mã hóa thực sự ngẫu nhiên và không thể tái sử dụng giữa các phiên. Double Ratchet thực hiện chính xác điều này: tin nhắn đầu tiên Đan Nguyên gửi cho Mỹ Anh mang theo khóa công khai Ratchet mới của anh, và phép tính DH giữa khóa Ratchet mới này với khóa Ratchet của Mỹ Anh tạo ra chuỗi gốc mới hoàn toàn độc lập với SK ban đầu. Việc không thực hiện bước ngẫu nhiên hóa này – dùng SK trực tiếp làm khóa mã hóa mà không có bất kỳ biện pháp nào chống tái sử dụng – là lỗi triển khai nghiêm trọng dẫn đến hậu quả mật mã thảm khốc.

Khả năng chối bỏ

X3DH không cung cấp cho Mỹ Anh hay Đan Nguyên bằng chứng mật mã có thể công bố về nội dung cuộc giao tiếp hay thực tế rằng họ đã giao tiếp. Tính chất này – được gọi là khả năng phủ nhận ngoại tuyến (offline deniability) – là đặc điểm thiết kế có chủ đích, quan trọng đặc biệt trong các ngữ cảnh pháp lý hay chính trị nhạy cảm.

Cơ sở toán học của khả năng phủ nhận trong X3DH giống với giao thức OTR (Off-the-Record Messaging): xác thực lẫn nhau được thực hiện thông qua các phép tính DH, không phải qua chữ ký trực tiếp lên thông điệp. Điều này có hệ quả quan trọng: bất kỳ bên nào cũng có thể tạo ra một bản ghi cuộc trò chuyện trông hợp lệ về mặt mật mã mà không cần sự tham gia của bên kia, chỉ cần dùng khóa riêng của chính mình và khóa công khai của bên kia. Vì không ai có thể chứng minh rằng họ không tự tạo ra bản ghi đó, bản ghi không có giá trị pháp lý như bằng chứng về nội dung giao tiếp thực tế. Tuy nhiên, nếu một trong hai bên hợp tác với bên thứ ba trong khi đang thực thi giao thức – ví dụ, cung cấp khóa riêng và ghi lại toàn bộ phiên làm việc – họ có thể cung cấp bằng chứng thuyết phục. Hạn chế này đối với khả năng phủ nhận trực tuyến (online deniability) là đặc điểm cố hữu của mô hình giao tiếp không đồng bộ và không thể tránh khỏi trong thiết kế hiện tại.

Chữ ký

Có thể nảy sinh suy nghĩ rằng chữ ký trên SPKB là không cần thiết, vì xác thực lẫn nhau đã được đảm bảo bởi DH1 và DH2. Tuy nhiên, bỏ qua chữ ký trên SPKB sẽ mở ra một cuộc tấn công bảo mật chuyển tiếp yếu: máy chủ độc hại có thể thay thế SPKB bằng khóa của chính mình – gọi là SPKB’ – và cung cấp gói khóa tiền giả mạo cho Mỹ Anh. Mỹ Anh sẽ tính SK sử dụng SPKB’, và máy chủ biết khóa riêng của SPKB’ có thể tính đúng SK đó. Khi IKB của Đan Nguyên sau này bị xâm phạm, kẻ tấn công (cũng là máy chủ) có thể giải mã toàn bộ lịch sử phiên. Chữ ký Sig(IKB, Encode(SPKB)) ràng buộc SPKB với IKB: để giả mạo, máy chủ phải ký SPKB’ bằng khóa riêng của IKB – điều đó đòi hỏi phải xâm phạm IKB, không phải chỉ thay thế SPKB.

Tương tự, có thể muốn thay thế xác thực lẫn nhau dựa trên DH (DH1 và DH2) bằng chữ ký từ các khóa nhận dạng trực tiếp trên nội dung thông điệp. Điều này sẽ làm giảm khả năng phủ nhận (vì chữ ký trực tiếp tạo ra bằng chứng mật mã không thể chối bỏ), tăng kích thước tin nhắn ban đầu, và gia tăng thiệt hại nếu khóa riêng tạm thời hay khóa riêng tiền ký bị xâm phạm. Thiết kế hiện tại cân bằng giữa các yêu cầu xác thực, khả năng phủ nhận và bảo mật chuyển tiếp một cách hài hòa.

Xâm phạm khóa

Việc xâm phạm khóa riêng của một bên gây ra hậu quả có mức độ nghiêm trọng khác nhau tùy thuộc vào loại khóa bị xâm phạm và thời điểm xảy ra. Hiểu rõ sự khác biệt này giúp người thiết kế hệ thống đưa ra các quyết định đánh đổi phù hợp.

Xâm phạm khóa riêng nhận dạng IKB cho phép kẻ tấn công mạo danh Đan Nguyên với bất kỳ ai: tạo ra tất cả các phép tính DH liên quan đến IKB, ký SPKB giả mạo, và thiết lập phiên mà Mỹ Anh tin là với Đan Nguyên. Đây là kịch bản nghiêm trọng nhất và không có biện pháp khắc phục trong phạm vi giao thức – đây là lý do tại sao khóa nhận dạng phải được bảo vệ đặc biệt và thường được lưu trong bộ nhớ bảo mật phần cứng trên thiết bị.

Nếu khóa tiền một lần OPKB được dùng trong phiên và đã bị xóa đúng quy định, việc sau này xâm phạm cả IKB lẫn tất cả khóa tiền định kỳ của Đan Nguyên vẫn không đủ để khôi phục SK của phiên đó – vì DH4 phụ thuộc vào khóa riêng OPKB đã bị xóa vĩnh viễn. Đây là tính chất bảo mật chuyển tiếp mạnh nhất mà X3DH cung cấp. Ngược lại, nếu không có OPKB trong phiên, xâm phạm đồng thời IKB và khóa riêng SPKB từ phiên đó đủ để tính lại toàn bộ SK, vì chỉ có DH1, DH2, DH3 và tất cả đều có thể tính từ hai khóa riêng đó cùng IKA và EKA đã biết. Việc thay thế thường xuyên SPKB giúp giới hạn cửa sổ phơi bày: chỉ các phiên trong thời gian SPKB còn hiệu lực mới bị ảnh hưởng nếu SPKB bị xâm phạm.

Tin tưởng vào máy chủ

Máy chủ trong X3DH là bên không tin cậy hoàn toàn nhưng cũng không bị coi là đối thủ mạnh nhất. Phân tích này xác định chính xác những gì máy chủ có thể và không thể làm.

Một máy chủ đơn thuần không trung thực (từ chối chuyển tiếp tin nhắn, làm chậm giao tiếp) chỉ gây gián đoạn tính khả dụng (availability) mà không phá vỡ bảo mật nội dung. Nếu Mỹ Anh và Đan Nguyên đã xác thực lẫn nhau, cuộc tấn công bổ sung duy nhất mà máy chủ có thể thực hiện là từ chối cung cấp OPKB, khiến tất cả phiên phải dùng SPKB – giảm mức bảo mật chuyển tiếp nhưng không phá vỡ bảo mật tức thì. Kẻ tấn công cũng có thể cố tình làm cạn kiệt kho OPKB bằng cách gửi ồ ạt yêu cầu truy xuất gói khóa tiền; do đó, máy chủ nên giới hạn tần suất truy xuất gói khóa tiền từ cùng một nguồn.

Một máy chủ tích cực độc hại (thay thế SPKB, can thiệp vào khóa tiền) bị chặn bởi cơ chế chữ ký: bất kỳ thay thế nào đối với SPKB mà không có chữ ký IKB hợp lệ sẽ bị Mỹ Anh phát hiện và giao thức bị hủy. Biện pháp bảo vệ duy nhất chống lại một máy chủ hoàn toàn độc hại – có khả năng giả mạo chữ ký hay xâm phạm IKB – là xác thực khóa định danh qua kênh ngoài băng, điều mà X3DH không tự mình thực hiện được.

Ràng buộc nhận dạng

Xác thực khóa định danh không tự động ngăn chặn được cuộc tấn công gán nhầm danh tính (identity misbinding attack). Trong cuộc tấn công này, kẻ tấn công Kỳ Lân có thể trình bày dấu vân tay khóa nhận dạng của Đan Nguyên cho Mỹ Anh như thể đó là khóa của chính Kỳ Lân. Kết quả là Mỹ Anh tin rằng mình đang liên lạc với Kỳ Lân trong khi thực tế đang gửi tin nhắn cho Đan Nguyên – hoặc ngược lại. Kỳ Lân không cần phá vỡ bất kỳ cơ chế mật mã nào mà chỉ cần nói dối về việc khóa nào thuộc về ai.

Biện pháp giảm thiểu là bổ sung thêm thông tin nhận dạng vào AD hoặc vào quá trình tính dấu vân tay: tên người dùng, số điện thoại, tên thật hay bất kỳ thuộc tính nhận dạng nào khác có thể được người dùng xác minh độc lập. Kỳ Lân sẽ phải nói dối về các giá trị bổ sung này – điều này khó hơn khi thông tin nhận dạng là số điện thoại hay địa chỉ email có thể kiểm tra dễ dàng qua kênh khác. Tuy nhiên, không có cơ chế nào có thể ngăn hoàn toàn kẻ tấn công nói dối về thông tin nhận dạng tùy ý. Đây là giới hạn cơ bản của mọi hệ thống xác thực dựa trên khóa công khai mà không có cơ sở hạ tầng khóa công khai (PKI) tập trung – một sự đánh đổi giữa phi tập trung và khả năng ràng buộc danh tính chặt chẽ mà các nhà thiết kế hệ thống phải cân nhắc dựa trên nhu cầu cụ thể của ứng dụng.

Kết luận

X3DH giải quyết một trong những bài toán khó nhất trong thiết kế giao thức liên lạc bảo mật: làm thế nào để hai bên thiết lập khóa phiên có xác thực lẫn nhau và bảo mật chuyển tiếp trong môi trường hoàn toàn không đồng bộ, khi một bên có thể ngoại tuyến hoàn toàn trong suốt quá trình. Giải pháp qua ba hoặc bốn phép DH song song – mỗi phép đóng góp một tính chất bảo mật khác nhau vào khóa phiên SK – là thiết kế thanh lịch cho phép phân tích tính chất bảo mật từng phần độc lập trước khi tổng hợp thành đảm bảo toàn diện.

Các cân nhắc bảo mật trong đặc tả X3DH – từ ràng buộc nhận dạng, khả năng phủ nhận, xâm phạm khóa đến độ tin cậy máy chủ – minh họa rằng thiết kế giao thức mật mã không chỉ là bài toán kỹ thuật mà còn là bài toán mô hình hóa đối thủ: mỗi tính chất bảo mật được đảm bảo trước một lớp tấn công cụ thể, và hiểu rõ ranh giới của từng lớp là điều kiện để triển khai đúng đắn. X3DH là nền tảng trên đó PQXDH xây dựng bảo vệ hậu lượng tử và Double Ratchet xây dựng bảo mật từng tin nhắn – sự kết hợp tạo nên kiến trúc bảo mật toàn diện của Signal Protocol.

Thuật toán X3DH thiết lập khóa bí mật chung – developer, bao mat, mat ma hoc, signal protocol, ma hoa thong tin, bao mat thong tin, double ratchet, kdf, x3dh, forward secrecy, future secrecy, key agreement, key agreement protocol, shared secret key, khoa bi mat chung, giao thuc bao mat, giao thuc nhan tin, ma hoa dau cuoi, tin nhan ma hoa dau cuoi.
Thuật toán X3DH thiết lập khóa bí mật chung.
  • bao-mat (17)
  • mat-ma-hoc (17)
  • signal-protocol (15)
  • ma-hoa-thong-tin (8)

  • bao-mat-thong-tin (8)

  • x3dh (5)

  • extended-triple-diffie-hellman (1)

  • key-agreement (2)

  • key-agreement-protocol (2)

  • shared-secret-key (2)

  • khoa-bi-mat-chung (2)

  • forward-secrecy (10)

  • prekey (1)

  • one-time-prekey (1)

  • signed-prekey (1)

  • identity-key (2)

  • giao-thuc-bao-mat (2)

  • ma-hoa-dau-cuoi (7)

  • bat-dong-bo (2)

Chuyên mục x3dh

Theo dõi hành trình

Hãy để lại thông tin, khi có gì mới thì Nhà văn sẽ gửi thư đến bạn để cập nhật. Cam kết không gửi email rác.

Họ và tên

Email liên lạc

Đôi dòng chia sẻ