Tìm hiểu về thuật toán X3DH – Giải pháp thiết lập khóa bí mật chung (Shared secret key)

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). 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ã.

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. Khác biệt so với các phương pháp truyền thống, X3DH kết hợp ba phép trao đổi Diffie – Hellman để tạo ra một khóa phiên an toàn và độc đáo. Cơ chế hoạt động của thuật toán cho phép các bên xác minh danh tính và thiết lập một kênh liên lạc được mã hóa mà không cần trao đổi trực tiếp khóa công khai, qua đó tăng cường tính bảo mật của quá trình giao tiếp.

Ứng dụng thực tế của X3DH được chứng minh rõ nét trong các nền tảng nhắn tin an toàn như Signal, WhatsApp và một số ứng dụng liên lạc chuyên nghiệp khác. Thuật toán đảm bảo rằng các cuộc trò chuyện được bảo vệ hoàn toàn khỏi các mối đe dọa bảo mật, ngay cả khi kênh truyền không được coi là an toàn tuyệt đối. Tính năng quan trọng của X3DH nằm ở khả năng cung cấp tính toàn vẹn và bí mật của thông điệp, đồng thời hỗ trợ xác thực người dùng một cách hiệu quả.

X3DH được thiết kế cho môi trường không đồng bộ, nơi một người dùng (Đan Nguyên) đang ngoại tuyến nhưng đã công bố một số thông tin lên máy chủ. Một người dùng khác (Mỹ Anh) muốn sử dụng thông tin đó để gửi dữ liệu được mã hóa cho Đan Nguyên và đồng thời thiết lập một khóa bí mật chung cho các lần liên lạc trong tương lai.

Kiến thức cơ bản

Các tham số của X3DH

Một ứng dụng sử dụng X3DH phải quyết định một số tham số sau:

Ví dụ, một ứng dụng có thể chọn đường cong X25519, hàm băm SHA512 và thông tin ứng dụng là MyProtocol.

Ngoài ra, ứng dụng phải xác định một hàm mã hóa Encode(PK) để mã hóa một khóa công khai X25519 hoặc X448 thành một dãy byte. Cách mã hóa được khuyến nghị bao gồm một hằng số một byte để biểu thị loại đường cong, tiếp theo là mã hóa little endian của tọa độ u theo tiêu chuẩn trong.

Ký hiệu mật mã

X3DH sử dụng các ký hiệu sau:

– Phép nối hai dãy byte X và Y được ký hiệu là X || Y.

– DH(PK1, PK2) biểu thị một dãy byte là đầu ra của một 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 PK1 và PK2. Hàm này có thể là X25519 hoặc X448 từ, tùy thuộc vào tham số đường cong.

– Sig(PK, M) biểu thị một dãy byte là chữ ký XEdDSA trên chuỗi byte M, có thể được xác minh bằng khóa công khai PK và được tạo ra bằng cách ký M với khóa riêng tương ứng của PK. Chức năng ký và xác minh của XEdDSA được mô tả trong.

– KDF(KM) biểu thị đầu ra 32 byte từ thuật toán HKDF với các đầu vào:

– Khóa đầu vào HKDF = F || KM, trong đó KM là một dãy byte chứa dữ liệu bí mật, và F là một dãy byte chứa 32 byte 0xFF nếu đường cong là X25519, hoặc 57 byte 0xFF nếu đường cong là X448. F được sử dụng để phân tách miền mật mã với XEdDSA.

– Muối HKDF = một dãy byte có độ dài bằng độ dài đầu ra của hàm băm và chứa toàn số 0.

– Thông tin HKDF = tham số info.

Các vai trò

Giao thức X3DH bao gồm ba thực thể: Mỹ Anh, Đan Nguyên, và một máy chủ.

– Mỹ Anh muốn gửi dữ liệu ban đầu cho Đan Nguyên bằng cách sử dụng mã hóa và thiết lập một khóa bí mật chung có thể được sử dụng cho liên lạc hai chiều.

– Đan Nguyên muốn cho phép những người như Mỹ Anh thiết lập khóa chung với mình và gửi dữ liệu được mã hóa. Tuy nhiên, Đan Nguyên có thể ngoại tuyến khi Mỹ Anh thực hiện thao tác này. Để hỗ trợ điều này, Đan Nguyên có một mối quan hệ với một máy chủ.

– Máy chủ có thể lưu trữ tin nhắn từ Mỹ Anh gửi cho Đan Nguyên, để Đan Nguyên có thể truy xuất sau này. Máy chủ cũng cho phép Đan Nguyên công bố một số dữ liệu mà nó sẽ cung cấp cho những người như Mỹ Anh.

Trong một số hệ thống, vai trò của máy chủ có thể được chia cho nhiều thực thể khác nhau, nhưng để đơn giản, giả định rằng chỉ có một máy chủ cung cấp các chức năng trên cho Mỹ Anh và Đan Nguyên.

Các khóa

X3DH sử dụng các khóa công khai đường cong elliptic sau:

Tất cả các khóa công khai đều có khóa riêng tương ứng, nhưng để đơn giản hóa mô tả, chỉ tập trung vào khóa công khai.

Các khóa công khai được sử dụng trong một phiên X3DH phải tất cả ở dạng X25519 hoặc tất cả ở dạng X448, tùy thuộc vào tham số đường cong.

Mỗi bên có một khóa công khai nhận dạng dài hạn (IKA cho Mỹ Anh, IKB cho Đan Nguyên).

Đan Nguyên cũng có một khóa SPKB (khóa tiền ký), được thay đổi định kỳ, và một tập hợp khóa OPKB (khóa tiền một lần), mỗi khóa chỉ được sử dụng trong một phiên X3DH duy nhất. (Prekeys được gọi như vậy vì chúng thực chất là các thông điệp giao thức mà Đan Nguyên công bố lên máy chủ trước khi Mỹ Anh bắt đầu phiên giao thức).

Trong mỗi phiên giao thức, Mỹ Anh tạo một cặp khóa tạm thời mới với khóa công khai EKA.

Sau khi phiên giao thức hoàn tất thành công, Mỹ Anh và Đan Nguyên sẽ chia sẻ một khóa bí mật 32 byte SK. Khóa này có thể được sử dụng trong một giao thức bảo mật sau X3DH.

Giao thức X3DH

Tổng quan

X3DH có ba giai đoạn:

– Đan Nguyên công bố khóa nhận dạng và các khóa tiền (prekeys) lên máy chủ.

– Mỹ Anh lấy một gói khóa tiền (prekey bundle) từ máy chủ và sử dụng nó để gửi một tin nhắn ban đầu đến Đan Nguyên.

– Đan Nguyên nhận và xử lý tin nhắn ban đầu từ Mỹ Anh.

Các phần sau đây sẽ giải thích chi tiết từng giai đoạn.

Công bố khóa

Đan Nguyên công bố một tập hợp các khóa công khai đường cong elliptic lên máy chủ, bao gồm:

– Khóa nhận dạng của Đan Nguyên (IKB).

– Khóa tiền có chữ ký của Đan Nguyên (SPKB).

– Chữ ký khóa tiền Sig(IKB, Encode(SPKB)).

– Một tập hợp các khóa tiền một lần của Đan Nguyên (OPKB1, OPKB2, OPKB3,…).

Đan Nguyên chỉ cần tải lên khóa nhận dạng của mình một lần duy nhất. Tuy nhiên, Đan Nguyên có thể tải lên các khóa tiền một lần mới bất cứ lúc nào (Ví dụ: khi máy chủ thông báo rằng kho khóa tiền một lần trên máy chủ đang cạn dần).

Đan Nguyên cũng sẽ tải lên một khóa tiền có chữ ký mới và chữ ký khóa tiền theo một khoảng thời gian nhất định (Ví dụ: mỗi tuần hoặc mỗi tháng). Khóa tiền có chữ ký mới sẽ thay thế khóa tiền trước đó.

Sau khi tải lên một khóa tiền có chữ ký mới, Đan Nguyên có thể giữ lại khóa riêng tương ứng với khóa tiền có chữ ký trước đó trong một thời gian ngắn để xử lý các tin nhắn đã bị trì hoãn trong quá trình truyền. Tuy nhiên, cuối cùng, Đan Nguyên nên xóa khóa riêng này để đảm bảo tính bảo mật chuyển tiếp. (Các khóa riêng của khóa tiền một lần sẽ được xóa ngay khi Đan Nguyên nhận được tin nhắn sử dụng chúng).

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ệ với máy chủ và lấy một gói khóa tiền (prekey bundle) chứa các giá trị sau:

– Khóa nhận dạng của Đan Nguyên (IKB).

– Khóa tiền có chữ ký của Đan Nguyên (SPKB).

– Chữ ký khóa tiền Sig(IKB, Encode(SPKB)).

– (Tùy chọn) Khóa tiền một lần của Đan Nguyên (OPKB).

Máy chủ nên cung cấp một khóa tiền một lần của Đan Nguyên nếu còn tồn tại và sau đó xóa khóa đó. Nếu tất cả các khóa tiền một lần của Đan Nguyên trên máy chủ đã bị xóa, gói khóa tiền sẽ không chứa khóa tiền một lần.

Mỹ Anh xác minh chữ ký khóa tiền và hủy giao thức nếu xác minh thất bại. Sau đó, Mỹ Anh tạo một cặp khóa tạm thời mới với khóa công khai là EKA.

Nếu gói khóa tiền không chứa khóa tiền một lần, Mỹ Anh thực hiện các tính toán sau:

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

Nếu gói khóa tiền có chứa khóa tiền một lần, phép tính sẽ được mở rộng để bao gồm thêm một giá trị DH:

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

Sơ đồ sau đây minh họa các phép tính DH giữa các khóa. Lưu ý rằng DH1 và DH2 cung cấp xác thực lẫn nhau, trong khi DH3 và DH4 cung cấp tính bảo mật chuyển tiếp.

Sau khi tính toán SK, Mỹ Anh xóa khóa riêng tạm thời của mình và các giá trị DH đã tính toán.

Mỹ Anh sau đó tính toán một dãy byte AD (associated data) chứa thông tin nhận dạng của cả hai bên:

AD = Encode(IKA) || Encode(IKB)

Mỹ Anh có thể tùy chọn thêm thông tin bổ sung vào AD, chẳng hạn như tên người dùng của Mỹ Anh và Đan Nguyên, chứng chỉ hoặc các thông tin nhận dạng khác.

Sau đó, Mỹ Anh gửi cho Đan Nguyên một tin nhắn ban đầu chứa:

– Khóa nhận dạng của Mỹ Anh (IKA).

– Khóa tạm thời của Mỹ Anh (EKA).

– Các định danh chỉ ra khóa tiền nào của Đan Nguyên mà Mỹ Anh đã sử dụng.

– Một bản mã ban đầu được mã hóa bằng một sơ đồ mã hóa AEAD, sử dụng AD làm dữ liệu liên kết và sử dụng khóa mã hóa là SK hoặc đầu ra của một PRF mật mã được khóa bằng SK.

Bản mã ban đầu này thường là tin nhắn đầu tiên trong một giao thức liên lạc bảo mật sau X3DH. Nói cách khác, nó có hai vai trò: vừa là tin nhắn đầu tiên trong giao thức bảo mật sau X3DH, vừa là một phần của tin nhắn ban đầu trong X3DH.

Sau khi gửi tin nhắn này, Mỹ Anh có thể tiếp tục sử dụng SK hoặc các khóa dẫn xuất từ SK trong giao thức bảo mật sau X3DH để liên lạc với Đan Nguyên, với các cân nhắc bảo mật.

Nhận tin nhắn ban đầu

Sau khi nhận được tin nhắn ban đầu từ Mỹ Anh, Đan Nguyên trích xuất khóa nhận dạng và khóa tạm thời của Mỹ Anh từ tin nhắn. Đan Nguyên cũng tải khóa riêng của mình, cũng như khóa riêng tương ứng với khóa tiền có chữ ký và khóa tiền một lần (nếu có) mà Mỹ Anh đã sử dụng.

Sử dụng các khóa này, Đan Nguyên thực hiện lại các phép tính DH và KDF từ mục trước để tạo ra SK, sau đó xóa các giá trị DH.

Đan Nguyên sau đó tạo dãy byte AD bằng cách sử dụng IKA và IKB, như đã mô tả trong mục trước. Cuối cùng, Đan Nguyên cố gắng giải mã bản mã ban đầu bằng SK và AD. Nếu quá trình giải mã thất bại, Đan Nguyên hủy giao thức và xóa SK.

Nếu bản mã ban đầu được giải mã thành công, giao thức hoàn tất đối với Đan Nguyên. Đan Nguyên xóa khóa riêng của khóa tiền một lần đã được sử dụng để đảm bảo tính bảo mật chuyển tiếp. Sau đó, Đan Nguyên có thể tiếp tục sử dụng SK hoặc các khóa dẫn xuất từ SK trong giao thức bảo mật sau X3DH để liên lạc với Mỹ Anh, với các cân nhắc bảo mật.

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

Xác thực

Trước hoặc sau khi thực hiện thỏa thuận khóa X3DH, các bên có thể so sánh khóa công khai nhận dạng IKA và IKB của nhau thông qua một kênh xác thực. Ví dụ, họ có thể so sánh dấu vân tay của khóa công khai theo cách thủ công hoặc bằng cách quét mã QR. Các phương pháp để thực hiện việc này nằm ngoài phạm vi của Bài viết này.

Nếu không thực hiện xác thực, các bên sẽ không có bất kỳ đảm bảo mật mã nào về danh tính của người mà họ đang liên lạc.

Phát lại giao thức

Nếu tin nhắn ban đầu của Mỹ Anh không sử dụng khóa tiền một lần, tin nhắn đó có thể bị phát lại đến Đan Nguyên, và anh ấy vẫn sẽ chấp nhận nó. Điều này có thể khiến Đan Nguyên nghĩ rằng Mỹ Anh đã gửi cùng một tin nhắn (hoặc nhiều tin nhắn) lặp đi lặp lại.

Để giảm thiểu vấn đề này, một giao thức sau X3DH có thể nhanh chóng đàm phán một khóa mã hóa mới cho Mỹ Anh dựa trên đầu vào ngẫu nhiên mới từ Đan Nguyên. Đây là hành vi phổ biến của các giao thức Diffie – Hellman có cơ chế tăng tiến (ratcheting).

Đan Nguyên cũng có thể áp dụng các biện pháp giảm thiểu khác, chẳng hạn như duy trì một danh sách đen các tin nhắn đã quan sát được hoặc thay thế các khóa tiền có chữ ký cũ nhanh hơn. Việc phân tích các biện pháp giảm thiểu này nằm ngoài phạm vi của Bài viết này.

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

Một hệ quả khác của việc phát lại được đề cập trong phần trước là một tin nhắn ban đầu được phát lại thành công có thể khiến Đan Nguyên tạo ra cùng một SK trong các lần thực thi giao thức khác nhau.

Vì lý do này, bất kỳ giao thức sau X3DH nào CẦN 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. Ví dụ, Đan Nguyên có thể sử dụng một giao thức tăng tiến dựa trên DH để kết hợp SK với một giá trị DH mới được tạo ra để có được một khóa mã hóa ngẫu nhiên.

Việc không ngẫu nhiên hóa khóa mã hóa của Đan Nguyên có thể dẫn đến thảm họa do tái sử dụng khóa.

Khả năng chối bỏ

X3DH không cung cấp cho Mỹ Anh hoặc Đan Nguyên bằng chứng mật mã có thể công khai về nội dung cuộc giao tiếp của họ hoặc việc họ đã giao tiếp.

Giống như trong giao thức OTR, trong một số trường hợp, một bên thứ ba đã xâm phạm khóa riêng hợp lệ của Mỹ Anh hoặc Đan Nguyên có thể nhận được một bản ghi cuộc giao tiếp trông giống như giữa Mỹ Anh và Đan Nguyên. Bản ghi này chỉ có thể được tạo bởi một bên khác cũng có quyền truy cập vào các khóa riêng hợp lệ của Mỹ Anh hoặc Đan Nguyên (tức là chính Mỹ Anh hoặc Đan Nguyên, hoặc một người nào đó đã xâm phạm khóa riêng của họ).

Nếu một trong hai bên hợp tác với bên thứ ba trong khi thực thi giao thức, họ sẽ có thể cung cấp bằng chứng về cuộc giao tiếp của mình cho bên thứ ba đó. Hạn chế này đối với khả năng chối bỏ trực tuyến dường như là đặc điểm cố hữu của mô hình giao tiếp không đồng bộ.

Chữ ký

Có thể sẽ hấp dẫn khi nhận thấy rằng xác thực lẫn nhau và tính bảo mật chuyển tiếp đã được đảm bảo bởi các phép tính DH, và do đó loại bỏ chữ ký khóa tiền. Tuy nhiên, điều này sẽ dẫn đến một cuộc tấn công bảo mật chuyển tiếp yếu:

Một máy chủ độc hại có thể cung cấp cho Mỹ Anh một gói khóa tiền chứa các khóa tiền giả mạo, và sau đó xâm phạm khóa nhận dạng IKB của Đan Nguyên để tính toán SK.

Ngoài ra, cũng có thể sẽ hấp dẫn khi thay thế cơ chế xác thực lẫn nhau dựa trên DH (tức là DH1 và DH2) bằng các chữ ký từ các khóa nhận dạng. Tuy nhiên, điều này sẽ làm giảm khả năng chối bỏ, tăng kích thước của các tin nhắn ban đầu, và gia tăng thiệt hại nếu các khóa riêng tạm thời hoặc khóa riêng của khóa tiền bị xâm phạm, hoặc nếu thuật toán chữ ký bị phá vỡ.

Xâm phạm khóa

Việc xâm phạm khóa riêng của một bên có thể gây ra hậu quả nghiêm trọng đối với bảo mật, mặc dù việc sử dụng khóa tạm thời và khóa tiền có thể giúp giảm thiểu tác động phần nào.

Xâm phạm khóa riêng nhận dạng của một bên cho phép kẻ tấn công giả mạo danh tính của bên đó đối với những người khác. Xâm phạm khóa riêng của khóa tiền có thể ảnh hưởng đến bảo mật của các giá trị SK cũ hoặc mới, tùy thuộc vào nhiều yếu tố.

Phân tích đầy đủ về tất cả các kịch bản xâm phạm có thể xảy ra nằm ngoài phạm vi của Bài viết này. Tuy nhiên, dưới đây là phân tích một số tình huống khả thi:

– Nếu các khóa tiền một lần được sử dụng trong quá trình thực thi giao thức, thì việc xâm phạm khóa nhận dạng của Đan Nguyên và các khóa riêng của khóa tiền vào một thời điểm nào đó trong tương lai sẽ không ảnh hưởng đến SK cũ, miễn là khóa riêng của OPKB đã bị xóa.

– Nếu các khóa tiền một lần không được sử dụng, thì việc xâm phạm khóa riêng của IKB và SPKB trong một lần thực thi giao thức sẽ làm lộ SK đã được tính toán trước đó. Việc thay thế thường xuyên các khóa tiền có chữ ký giúp giảm thiểu rủi ro này, cũng như sử dụng một giao thức tăng tiến sau X3DH, giúp nhanh chóng thay thế SK bằng các khóa mới để đảm bảo bảo mật chuyển tiếp liên tục.

Xâm phạm khóa riêng của khóa tiền có thể tạo điều kiện cho các cuộc tấn công trong tương lai, chẳng hạn như tính toán thụ động các giá trị SK và giả mạo danh tính của bất kỳ bên nào với bên bị xâm phạm (key-compromise impersonation). Những cuộc tấn công này có thể tiếp diễn cho đến khi bên bị xâm phạm thay thế các khóa tiền bị xâm phạm trên máy chủ (trong trường hợp tấn công thụ động) hoặc xóa khóa riêng của khóa tiền có chữ ký bị xâm phạm (trong trường hợp giả mạo danh tính).

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

Một máy chủ độc hại có thể khiến cuộc giao tiếp giữa Mỹ Anh và Đan Nguyên thất bại (Ví dụ: bằng cách từ chối chuyển tiếp tin nhắn).

Nếu Mỹ Anh và Đan Nguyên xác thực lẫn nhau, thì 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 khóa tiền một lần, khiến tính bảo mật chuyển tiếp của SK phụ thuộc vào vòng đời của khóa tiền có chữ ký (như đã phân tích trong phần trước).

Việc giảm mức độ bảo mật chuyển tiếp ban đầu này cũng có thể xảy ra nếu một bên độc hại cố tình làm cạn kiệt các khóa tiền một lần của bên khác. Do đó, máy chủ nên cố gắng ngăn chặn điều này, chẳng hạn bằng cách giới hạn tần suất truy vấn gói khóa tiền.

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

Xác thực không nhất thiết ngăn chặn được một cuộc tấn công gán nhầm danh tính hoặc chia sẻ khóa không xác định.

Để làm cho cuộc tấn công này khó khăn hơn, các bên có thể đưa thêm thông tin nhận dạng vào AD hoặc mã hóa thêm thông tin nhận dạng vào dấu vân tay, chẳng hạn như tên người dùng, số điện thoại hoặc tên thật. Tuy nhiên, không có cách nào đảm bảo ngăn chặn hoàn toàn kẻ tấn công giả mạo thông tin này mà không gây ảnh hưởng đến quyền riêng tư, tính linh hoạt và giao diện người dùng.