Thuật toán Sesame – Quản lý mã hóa đa thiết bị không đồng bộ

SESAME là kiến trúc bảo mật tiên tiến được phát triển nhằm cung cấp giải pháp xác thực và quản lý khóa toàn diện trong môi trường phân tán.

Giới thiệu

Bài viết này mô tả thuật toán Sesame để quản lý phiên mã hóa tin nhắn trong môi trường không đồng bộ và đa thiết bị. Sesame được thiết kế để quản lý các phiên Double Ratchet được tạo bằng thỏa thuận khóa X3DH, nhưng về bản chất là một thuật toán tổng quát – Sesame có thể hoạt động với bất kỳ thuật toán mã hóa tin nhắn dựa trên phiên nào đáp ứng một số điều kiện nhất định về cách tạo phiên và xử lý tin nhắn khởi tạo.

Bài toán mà Sesame giải quyết xuất phát từ khoảng cách giữa thế giới lý tưởng của các đặc tả mật mã và thế giới thực của ứng dụng nhắn tin hiện đại. X3DH và Double Ratchet, xét riêng lẻ, giả định hai bên giao tiếp với nhau qua một kênh duy nhất. Thực tế phức tạp hơn nhiều: Mỹ Anh có thể đang dùng điện thoại và máy tính bảng cùng lúc; Đan Nguyên có thể thêm hoặc xóa thiết bị; cả hai có thể đồng thời khởi tạo phiên với nhau tạo ra hai phiên song song; thiết bị có thể bị khôi phục về bản sao lưu cũ làm mất đồng bộ trạng thái mã hóa. Mỗi tình huống này có thể dẫn đến phiên bị mồ côi, trùng lặp hoặc không khớp – những vấn đề mà bản thân X3DH và Double Ratchet không tự xử lý được.

Sesame giải quyết toàn bộ lớp vấn đề này thông qua một mô hình quản lý phiên nhất quán: mỗi thiết bị theo dõi một phiên hoạt động với mỗi thiết bị từ xa mà nó giao tiếp, và sử dụng phiên hoạt động đó khi gửi tin nhắn. Khi một tin nhắn được nhận qua phiên không hoạt động, phiên đó trở thành phiên hoạt động mới và phiên cũ bị đẩy vào danh sách dự phòng. Cơ chế đơn giản này đảm bảo rằng qua thời gian, dù có bao nhiêu phiên song song được tạo ra, các thiết bị sẽ dần hội tụ về việc dùng chung một phiên duy nhất – mà không cần đồng bộ hóa thời gian hay bất kỳ thỏa thuận rõ ràng nào giữa các bên.

Kiến thức cơ bản

Trước khi đi vào chi tiết thuật toán, cần nắm rõ bức tranh tổng quan về những gì Sesame được xây dựng trên, những vấn đề thực tế mà nó phải giải quyết, và hệ thống giả định mô hình hóa môi trường vận hành. Phần này cung cấp nền tảng để hiểu lý do tại sao từng quyết định thiết kế trong Sesame lại như vậy.

Giả định

Thuật toán Sesame dựa trên một bộ giả định mô hình hóa chính xác môi trường vận hành thực tế – không giả định điều kiện lý tưởng mà thừa nhận sự không đáng tin cậy, thiếu đồng bộ và khả năng bị tấn công là những đặc điểm cố hữu của hệ thống.

Về máy chủ: có một máy chủ lưu trữ thông tin hiện tại của tất cả người dùng và thiết bị, đồng thời lưu trữ tạm thời các tin nhắn cho đến khi chúng được truy xuất. Máy chủ không nhất thiết phải trung thực – một kẻ tấn công bao gồm cả máy chủ có thể làm hỏng, xóa, sắp xếp lại, trùng lặp hoặc giả mạo tin nhắn trước khi chúng đến hộp thư. Đây là điểm khác biệt quan trọng: Sesame không đặt tin tưởng tuyệt đối vào máy chủ về tính toàn vẹn và bảo mật nội dung, mà chỉ tin tưởng máy chủ ở mức tối thiểu cần thiết để hệ thống vận hành (lưu trữ và chuyển tiếp tin nhắn mã hóa).

Về người dùng và thiết bị: mỗi người dùng có một UserID (tên người dùng hoặc số điện thoại) và một tập hợp thiết bị không rỗng tại bất kỳ thời điểm nào. Người dùng và thiết bị có thể được thêm hoặc xóa bất cứ lúc nào. Khi một người dùng bị xóa, UserID của họ có thể sau đó được gán cho người dùng mới – điều này có hàm ý bảo mật quan trọng mà Sesame phải xử lý. Mỗi thiết bị có một DeviceID duy nhất trong phạm vi UserID của người dùng đó, và có thể lưu trữ trạng thái. Tuy nhiên, trạng thái thiết bị có thể bị xóa toàn bộ hoặc một phần bất kỳ lúc nào – do lỗi phần cứng, do hành động của người dùng hay do khôi phục từ bản sao lưu cũ. Các thiết bị có đồng hồ đo thời gian trôi qua nhưng không được đồng bộ hóa với nhau, nghĩa là không thể dựa vào đồng hồ để xác định thứ tự sự kiện giữa các thiết bị khác nhau.

Về hộp thư và phiên: mỗi thiết bị có một hộp thư trên máy chủ. Tin nhắn gửi đến hộp thư không đáng tin cậy trong hoạt động bình thường – chúng có thể bị hỏng, bị xóa, bị sắp xếp lại, bị trì hoãn hoặc bị trùng lặp. Một tin nhắn không đến hộp thư trong khoảng thời gian MAXLATENCY được coi là đã bị mất vĩnh viễn. Về phiên, mỗi phiên có một SessionID duy nhất; tin nhắn chỉ có thể giải mã bằng phiên khớp; và một phiên có thể thay đổi trạng thái sau khi mã hóa hoặc giải mã – ví dụ, khóa bị xóa để đảm bảo bảo mật chuyển tiếp. Việc giải mã có thể thất bại nếu bản mã bị giả mạo hay bị thay đổi. Những giả định này, xét tổng thể, vẽ nên bức tranh của một hệ thống phân tán trong điều kiện thực tế với đầy đủ mọi điểm yếu tiềm năng.

Tạo phiên cho thiết bị gửi

Khả năng tạo phiên là nền tảng để bắt đầu liên lạc mã hóa. Mỗi thiết bị giữ một cặp khóa nhận dạng gồm khóa công khai và khóa riêng tư, được dùng để xác thực mật mã trong quá trình tạo phiên. Cặp khóa này gắn với DeviceID của thiết bị và không thay đổi trong suốt vòng đời logic của thiết bị đó – để thay đổi cặp khóa trên một thiết bị vật lý, thiết bị phải bị xóa logic khỏi hệ thống và đăng ký lại với các giá trị mới.

Một thiết bị có thể tạo một phiên khởi tạo mới bất cứ lúc nào. Khác với phiên thông thường được thiết lập sau khi đã có giao tiếp qua lại, phiên khởi tạo là phiên cho phép thiết bị gửi tin nhắn đầu tiên đến thiết bị nhận mà chưa cần bất kỳ sự phối hợp nào trước đó – đây chính là tính chất bất đồng bộ quan trọng mà X3DH cung cấp khi được dùng kết hợp với Sesame. Để tạo phiên khởi tạo, thiết bị gửi cần biết khóa công khai nhận dạng của thiết bị nhận – thông tin này được chỉ định khi tạo phiên và dùng để thiết bị nhận có thể tạo phiên khớp về sau.

Việc tạo phiên khởi tạo có thể thất bại vì nhiều lý do thực tế: thiết bị gửi có thể cần truy xuất và xác thực mật mã các tham số từ máy chủ (như gói khóa tiền trong X3DH) trước khi tạo phiên; máy chủ có thể không phản hồi hoặc trả về dữ liệu không hợp lệ; quá trình xác thực mật mã có thể thất bại nếu chữ ký trên khóa tiền không hợp lệ. Khi tạo phiên thất bại, thiết bị gửi không nên rơi vào trạng thái không nhất quán – mọi thay đổi trạng thái cục bộ phải được hủy bỏ. Điều quan trọng là việc tạo phiên thất bại không nhất thiết chỉ ra sự cố bảo mật: đây có thể là lỗi mạng thông thường hay dữ liệu tạm thời không hợp lệ. Thiết bị nên phân biệt các loại lỗi và xử lý phù hợp thay vì coi tất cả thất bại tạo phiên là dấu hiệu tấn công.

Tạo phiên cho thiết bị nhận

Phía nhận của quá trình tạo phiên hoạt động theo nguyên tắc phản ứng: thiết bị nhận không chủ động tạo phiên mà chỉ tạo phiên khớp khi nhận được tin nhắn khởi tạo hợp lệ. Tất cả tin nhắn được mã hóa bởi một phiên khởi tạo đều được gọi là tin nhắn khởi tạo, và chúng mang theo thông tin đặc biệt trong phần tiêu đề không mã hóa cho phép thiết bị nhận nhận dạng chúng là tin nhắn khởi tạo.

Cụ thể, tất cả tin nhắn khởi tạo đều chứa khóa công khai nhận dạng của thiết bị gửi trong tiêu đề. Thông tin này là điều kiện cần để thiết bị nhận tạo phiên khớp: nó cần biết đang nhận từ ai để xác thực và thiết lập trạng thái phiên phù hợp. Khi nhận được tin nhắn khởi tạo, thiết bị nhận cố gắng tạo phiên khớp bằng cách sử dụng thông tin trong tiêu đề và các tham số mật mã nội bộ của mình (ví dụ, khóa tiền tương ứng đã được tham chiếu trong tin nhắn X3DH). Phiên khớp được dùng ngay để giải mã tin nhắn khởi tạo đó.

Việc tạo phiên khớp cũng có thể thất bại, ví dụ nếu quá trình xác thực mật mã của tin nhắn khởi tạo thất bại – điều này có thể xảy ra nếu tin nhắn bị giả mạo, bị hỏng trên đường truyền, hoặc nếu thiết bị nhận không còn lưu trữ khóa riêng của khóa tiền được tham chiếu (do đã dùng và xóa hoặc do khôi phục từ bản sao lưu cũ). Khi tạo phiên khớp thất bại, thiết bị nhận phải loại bỏ tin nhắn và hủy tất cả thay đổi trạng thái. Đây là hành vi quan trọng để đảm bảo thiết bị không rơi vào trạng thái nhận biết một phần về phiên nhưng không thể hoàn thiện – loại trạng thái không nhất quán đó sẽ gây ra các lỗi khó chẩn đoán về sau.

Khi giải mã tin nhắn lần đầu tiên thành công, phiên khởi tạo trở thành phiên thông thường và ngừng tạo tin nhắn khởi tạo. Sự chuyển đổi này là một chiều và không thể đảo ngược: sau khi phiên đã bước qua giai đoạn khởi tạo, nó hoạt động theo cơ chế Double Ratchet thông thường và không còn mang theo thông tin khởi tạo X3DH trong các tin nhắn tiếp theo.

Thuật toán Sesame

Thuật toán Sesame định nghĩa cấu trúc dữ liệu mà mỗi thiết bị duy trì và các quy trình sử dụng cấu trúc đó để gửi, nhận tin nhắn mã hóa trong môi trường đa thiết bị. Phần này trình bày đặc tả đầy đủ bao gồm mô hình trạng thái, các phép cập nhật trạng thái và luồng xử lý tin nhắn.

Trạng thái thiết bị

Mỗi thiết bị lưu trữ một cấu trúc dữ liệu phân cấp ba tầng phản ánh đúng mô hình tổ chức người dùng – thiết bị của hệ thống. Tầng cao nhất là tập hợp các UserRecord (bản ghi người dùng) được lập chỉ mục theo UserID, đại diện cho từng đối tác liên lạc. Mỗi UserRecord chứa tập hợp các DeviceRecord (bản ghi thiết bị) được lập chỉ mục theo DeviceID, đại diện cho từng thiết bị vật lý của người dùng đó. Mỗi DeviceRecord chứa ít nhất một phiên – một phiên hoạt động và tùy chọn một danh sách có thứ tự các phiên không hoạt động.

Thiết bị cũng lưu trữ một UserRecord cho chính UserID của mình (nhưng không có DeviceRecord cho DeviceID của nó). Đây là điều kiện để thiết bị có thể gửi bản sao của mỗi tin nhắn gửi đi đến các thiết bị khác của cùng người dùng – cơ chế đảm bảo đồng bộ hóa lịch sử tin nhắn giữa nhiều thiết bị của một tài khoản. Không có thiết kế khác nhau giữa thiết bị gửi và thiết bị nhận ở cấp độ lưu trữ: mỗi thiết bị đơn giản là duy trì bản ghi đầy đủ về tất cả các mối quan hệ phiên của mình với mọi thiết bị khác mà nó đã liên lạc.

Khái niệm stale (cũ) là công cụ quan trọng để Sesame xử lý vòng đời của bản ghi. Một UserRecord hay DeviceRecord được đánh dấu là cũ khi người dùng hay thiết bị tương ứng đã bị xóa khỏi hệ thống, nhưng bản ghi vẫn được giữ lại để có thể giải mã các tin nhắn bị trễ đang trên đường đến. Bản ghi cũ nên mang một dấu thời gian ghi lại thời điểm nó được đánh dấu; khi dấu thời gian cũ hơn MAXLATENCY và thiết bị đã xử lý toàn bộ hộp thư, bản ghi cũ có thể bị xóa an toàn. Chính sách xóa dựa trên thời gian kết hợp với điều kiện đã xử lý xong hộp thư này là điều kiện đủ để đảm bảo không bao giờ xóa bản ghi khi vẫn còn tin nhắn cần đến nó.

Sesame hỗ trợ hai mô hình quản lý khóa nhận dạng: khóa theo người dùng (per-user identity keys) – mọi thiết bị của cùng người dùng chia sẻ một cặp khóa, lưu trong UserRecord – hoặc khóa theo thiết bị (per-device identity keys) – mỗi thiết bị có cặp khóa riêng, lưu trong DeviceRecord. Mô hình đầu đơn giản hơn cho người dùng nhưng yêu cầu phân phối khóa riêng an toàn giữa các thiết bị; mô hình sau cách ly bảo mật tốt hơn nhưng đòi hỏi người dùng xác minh từng thiết bị riêng lẻ.

Cập nhật trạng thái thiết bị

Thiết bị thực hiện các phép cập nhật trên cấu trúc trạng thái theo một tập quy tắc xác định nhằm đảm bảo tính nhất quán của cấu trúc phân cấp. Hiểu các phép cập nhật này là điều kiện để phân tích đúng hành vi của Sesame trong các tình huống phức tạp như thêm thiết bị, xóa thiết bị hay khôi phục bản sao lưu.

Về xóa bản ghi: thiết bị có thể xóa UserRecord, DeviceRecord và các phiên bất cứ lúc nào, nhưng các phép xóa có tính chất thác (cascading). Nếu phiên cuối cùng trong một DeviceRecord bị xóa, DeviceRecord đó cũng tự động bị xóa; nếu DeviceRecord cuối cùng trong một UserRecord bị xóa, UserRecord đó cũng bị xóa. Điều này đảm bảo không tồn tại bản ghi rỗng trong cấu trúc phân cấp – một bất biến quan trọng giúp đơn giản hóa logic xử lý.

Về chèn phiên: khi thiết bị chèn một phiên mới vào DeviceRecord, phiên mới đó luôn trở thành phiên hoạt động; phiên hoạt động trước đó (nếu có) được đẩy lên đầu danh sách phiên không hoạt động. Quy tắc này phản ánh triết lý thiết kế cốt lõi: phiên mới nhất luôn được ưu tiên. Nếu danh sách phiên không hoạt động trở nên quá lớn vượt ngưỡng được định nghĩa, các phiên cũ nhất ở cuối danh sách bị xóa – đây là biện pháp kiểm soát tài nguyên quan trọng chống lại việc máy chủ độc hại hay lỗi triển khai làm phình to danh sách không giới hạn.

Về kích hoạt phiên không hoạt động: khi thiết bị nhận được tin nhắn qua phiên không hoạt động, phiên đó được kích hoạt – trở thành phiên hoạt động mới và phiên hoạt động cũ được đẩy vào đầu danh sách không hoạt động. Cơ chế này là trái tim của quá trình hội tụ phiên: khi Đan Nguyên gửi phản hồi qua phiên mà anh đang hoạt động, thiết bị của Mỹ Anh kích hoạt phiên đó, đảm bảo cả hai bên dần dùng chung một phiên. Cuối cùng, thiết bị có thể thực hiện cập nhật có điều kiện dựa trên bộ ba (UserID, DeviceID, khóa công khai) – một thao tác kiểm tra xem khóa công khai có khớp với bản ghi hiện tại không trước khi cập nhật, cho phép phát hiện sự thay đổi khóa định danh.

Gửi tin nhắn

Quá trình gửi tin nhắn trong Sesame nhận đầu vào là một đoạn văn bản thuần túy và một tập hợp UserID người nhận. Tập hợp này bao gồm cả UserID của chính thiết bị gửi, vì tin nhắn cũng cần được gửi đến các thiết bị khác của người dùng đó để đồng bộ hóa lịch sử.

Với mỗi UserID người nhận, quy trình gửi thực hiện một vòng lặp thích nghi (adaptive loop) nhằm đảm bảo tin nhắn đến đúng hộp thư. Nếu tồn tại UserRecord không cũ cho UserID đó, thiết bị mã hóa văn bản thuần túy bằng phiên hoạt động của mỗi DeviceRecord không cũ trong UserRecord đó. Tập hợp tin nhắn đã mã hóa cùng với danh sách DeviceID tương ứng được gửi lên máy chủ. Đây là điểm khởi đầu của vòng thương lượng với máy chủ: nếu danh sách DeviceID phía gửi nhìn nhận là hiện tại khớp với bản ghi máy chủ, tin nhắn được chấp nhận và gửi đến các hộp thư. Nếu không khớp, máy chủ từ chối và trả về thông tin về các DeviceID cũ (đã bị xóa) và mới (chưa có trong bản ghi của thiết bị gửi).

Khi nhận được thông tin này, thiết bị gửi cập nhật bản ghi của mình: đánh dấu bản ghi của DeviceID cũ là stale; với DeviceID mới, thiết bị chuẩn bị tạo phiên khởi tạo mới. Sau khi cập nhật, vòng lặp bắt đầu lại từ đầu. Đây là quá trình tự khám phá (autodiscovery) và hội tụ: sau vài vòng lặp, bản ghi cục bộ của thiết bị gửi sẽ khớp với bản ghi máy chủ và tin nhắn được chấp nhận. Để ngăn vòng lặp vô hạn do máy chủ độc hại hay lỗi triển khai, thiết bị cần đặt giới hạn số lần lặp và kích hoạt lỗi nếu vượt quá. Nếu xảy ra lỗi trong bất kỳ bước nào của quá trình mã hóa hay gửi, mọi thay đổi đối với UserRecord liên quan phải được hủy bỏ để tránh trạng thái không nhất quán.

Nhận tin nhắn

Quá trình nhận tin nhắn trong Sesame nhận đầu vào là một tin nhắn mã hóa cùng với UserID và DeviceID của người gửi – toàn bộ thông tin này được truy xuất từ máy chủ. Cách thức thiết bị polling (truy vấn định kỳ) hay nhận thông báo push nằm ngoài phạm vi đặc tả Sesame và tùy thuộc vào triển khai cụ thể.

Luồng giải mã phân nhánh sớm dựa trên đặc điểm của tin nhắn. Nếu đây là tin nhắn khởi tạo và thiết bị nhận chưa có DeviceRecord tương ứng chứa phiên có thể giải mã nó, thiết bị tiến hành tạo phiên khớp: trích xuất khóa công khai từ tiêu đề, thực hiện cập nhật có điều kiện bản ghi dựa trên (UserID người gửi, DeviceID người gửi, khóa công khai), rồi tạo phiên khớp từ tin nhắn khởi tạo và chèn phiên mới vào DeviceRecord tương ứng. Bước cập nhật có điều kiện là cơ hội để phát hiện sự thay đổi khóa: nếu khóa công khai trong tiêu đề khác với khóa đã biết từ trước, thiết bị có thể cảnh báo người dùng và tạm dừng quy trình chờ xác nhận.

Sau khi có phiên – dù là phiên vừa tạo hay phiên đã tồn tại – thiết bị cố gắng giải mã tin nhắn bằng phiên tương ứng. Nếu giải mã thành công và phiên đó không ở trạng thái hoạt động, nó sẽ được kích hoạt – đây là bước hội tụ phiên. Nếu không có phiên nào trong DeviceRecord liên quan có thể giải mã tin nhắn (bao gồm trường hợp tạo phiên khớp thất bại), tin nhắn bị loại bỏ và tất cả thay đổi trạng thái bị hủy bỏ. Nếu xảy ra bất kỳ lỗi nào trong quá trình phân tích hay xử lý – bao gồm lỗi mật mã trong tạo phiên hay giải mã – thiết bị hủy tất cả thay đổi và kết thúc quy trình. Hành vi hủy toàn bộ khi có lỗi (all-or-nothing) là bất biến thiết yếu đảm bảo không bao giờ có trạng thái cục bộ bị tổn hại một phần.

Các tính năng tùy chọn

Phần này mô tả các tính năng bổ sung mà triển khai Sesame có thể tùy chọn hỗ trợ để cải thiện độ tin cậy (reliability) và bảo mật trong các tình huống đặc biệt. Không giống các cơ chế cốt lõi ở phần trước, các tính năng này không bắt buộc nhưng được khuyến nghị cho hầu hết triển khai thực tế.

Yêu cầu gửi lại và biên nhận giao hàng (delivery receipts)

Tình huống xảy ra khi trạng thái thiết bị gửi hoặc nhận bị khôi phục về trạng thái cũ – do khôi phục từ bản sao lưu hay do lỗi lưu trữ – có thể dẫn đến trường hợp thiết bị nhận nhận được tin nhắn hợp lệ về mặt cấu trúc nhưng không thể giải mã vì phiên mã hóa tương ứng không còn tồn tại hay đã bị tách rời. Đây là tình huống thực tế quan trọng mà cơ chế cốt lõi của Sesame không tự xử lý được – và cơ chế gửi lại (retransmission) ra đời để giải quyết chính xác vấn đề này.

Thiết bị gửi có thể lưu trữ một tập hợp MessageRecord, được lập chỉ mục bằng MessageID duy nhất cho mỗi bản mã đã gửi. Khi một tin nhắn được gửi đến nhiều thiết bị, thiết bị gửi tạo một MessageRecord riêng biệt cho từng thiết bị nhận. Mỗi MessageRecord lưu trữ nội dung văn bản gốc, UserID của thiết bị nhận và SessionID của phiên đã dùng để mã hóa. Khi thiết bị nhận không thể giải mã một tin nhắn, nó gửi yêu cầu gửi lại không mã hóa đến hộp thư thiết bị gửi, chứa MessageID của tin nhắn không giải mã được.

Khi thiết bị gửi nhận yêu cầu gửi lại, nó thực hiện chuỗi kiểm tra: nếu MessageID không khớp bất kỳ MessageRecord nào, yêu cầu bị bỏ qua; nếu UserID trong yêu cầu không khớp UserID trong MessageRecord, yêu cầu bị bỏ qua (kiểm tra này ngăn thiết bị của người dùng A yêu cầu gửi lại tin nhắn cho người dùng B). Nếu không có phiên hoạt động hợp lệ cho cặp (UserID, DeviceID) yêu cầu gửi lại, hay nếu phiên hoạt động có cùng SessionID với phiên trong MessageRecord (chứng tỏ phiên này đã lỗi thời), thiết bị tạo phiên mới. Tin nhắn được mã hóa lại bằng phiên mới và gửi lại. MessageRecord cũ bị xóa và một MessageRecord mới được tạo cho bản mã vừa gửi. Ngoài ra, các thiết bị có thể gửi biên nhận giao hàng sau khi giải mã thành công, cho phép thiết bị gửi xóa MessageRecord ngay khi không còn cần thiết thay vì chờ đến khi hết hạn. Để tránh lạm dụng cơ chế này, thiết bị nên đặt giới hạn số lần gửi lại cho mỗi tin nhắn.

Hết hạn phiên

Ngay cả khi không có sự cố nào, việc duy trì phiên vô thời hạn là rủi ro bảo mật: khóa phiên tích lũy thêm giá trị theo thời gian (một kẻ tấn công ghi lại đủ bản mã có thể tập trung nỗ lực vào một phiên duy nhất), và thời gian tồn tại dài của phiên làm tăng cửa sổ thiệt hại nếu phiên bị xâm phạm. Cơ chế hết hạn phiên giải quyết bài toán này bằng cách buộc các phiên cũ phải được thay thế định kỳ.

Mỗi phiên được gán một dấu thời gian khi được tạo, được đặt bằng thời gian hiện tại của thiết bị. Vì đồng hồ giữa các thiết bị không được đồng bộ, có thể phát sinh sai lệch: khi tin nhắn khởi tạo được truy xuất từ hộp thư, máy chủ có thể thông báo cho thiết bị nhận về khoảng thời gian trôi qua giữa lúc tin nhắn đến hộp thư và thời điểm hiện tại; thiết bị nhận hiệu chỉnh dấu thời gian của phiên bằng cách trừ đi khoảng này. Hai hằng số thời gian điều chỉnh vòng đời phiên: MAXSEND xác định khoảng thời gian sau đó phiên không còn được dùng để mã hóa (phiên hoạt động bị đẩy vào danh sách không hoạt động và mọi nỗ lực kích hoạt lại sẽ không có hiệu quả); MAXRECV xác định khoảng thời gian sau đó phiên có thể bị xóa hoàn toàn sau khi đã xử lý hết hộp thư. Điều kiện MAXRECV > MAXSEND + 2×MAXLATENCY đảm bảo rằng bất kỳ tin nhắn nào được gửi trong thời hạn MAXSEND đều có đủ thời gian đến hộp thư và được giải mã trước khi phiên bị xóa – đây là bất biến bảo đảm không xóa phiên khi còn tin nhắn đang trên đường.

Quản lý vòng đời MessageRecord

Cơ chế MessageRecord, dù hữu ích để xử lý yêu cầu gửi lại, cũng tạo ra bề mặt tấn công mới nếu không được quản lý đúng vòng đời. Hiểu rõ khi nào và tại sao cần xóa MessageRecord là điều kiện để triển khai tính năng gửi lại một cách an toàn.

MessageRecord chứa văn bản gốc của tin nhắn – thông tin nhạy cảm nhất trong hệ thống. Việc lưu giữ MessageRecord lâu hơn cần thiết đồng nghĩa với việc mở rộng cửa sổ thiệt hại nếu thiết bị bị xâm phạm: kẻ tấn công không chỉ đọc được tin nhắn hiện tại mà còn đọc được tất cả tin nhắn chưa xác nhận trong MessageRecord. Ba điều kiện kích hoạt xóa MessageRecord: thứ nhất, nhận được biên nhận giao hàng từ thiết bị nhận xác nhận đã giải mã thành công; thứ hai, người dùng chủ động xóa nội dung tin nhắn khỏi giao diện – khi đó tất cả MessageRecord chứa bản sao văn bản đó cũng phải bị xóa ngay lập tức; thứ ba, MessageRecord hết hạn sau một khoảng thời gian tối đa nhất định, đảm bảo không có MessageRecord nào tồn tại vô thời hạn ngay cả khi không nhận được biên nhận.

Để ngăn cơ chế gửi lại bị lạm dụng, thiết bị nên đặt giới hạn số lần gửi lại mỗi MessageRecord (lưu trong chính MessageRecord để bền vững qua khởi động lại). Khi vượt giới hạn, thiết bị xóa MessageRecord và kết thúc quy trình gửi lại cho tin nhắn đó – đây là hành vi an toàn hơn là tiếp tục cố gắng vô hạn. Ngoài ra, số lượng tổng MessageRecord được lưu trữ cũng nên có giới hạn trên, tránh trường hợp thiết bị tích lũy quá nhiều văn bản gốc chưa xác nhận do lỗi hay do thiết bị nhận mất liên lạc trong thời gian dài.

Cân nhắc triển khai

Để đơn giản hóa đặc tả, bài viết này thảo luận về một máy chủ duy nhất xử lý tất cả bản ghi người dùng, thiết bị và tin nhắn. Trong các hệ thống thực tế, mô hình này được mở rộng và phân tách theo nhiều cách khác nhau tùy theo yêu cầu quy mô, độ tin cậy và bảo mật.

Kiến trúc phân tán và phân tách máy chủ

Trong triển khai thực tế ở quy mô lớn, các chức năng của máy chủ thường được phân tách và phân phối giữa nhiều thực thể để đạt khả năng mở rộng và cô lập lỗi tốt hơn. Hai mô hình phân tách phổ biến nhất là phân tách theo nhóm người dùng và phân tách theo chức năng.

Phân tách theo nhóm người dùng có nghĩa là các máy chủ khác nhau xử lý các nhóm người dùng khác nhau dựa trên một tiêu chí nào đó – thường là dựa vào UserID hoặc theo khu vực địa lý. Trong mô hình này, khi Mỹ Anh muốn gửi tin nhắn cho Đan Nguyên, thiết bị của Mỹ Anh liên hệ với máy chủ quản lý Đan Nguyên để gửi tin nhắn vào hộp thư của anh; khi Đan Nguyên muốn gửi ngược lại, thiết bị của anh liên hệ với máy chủ quản lý Mỹ Anh. Phân tách theo chức năng có nghĩa là các máy chủ quản lý bản ghi người dùng và thiết bị được tách biệt hoàn toàn khỏi các máy chủ xử lý hộp thư. Điều này cho phép tối ưu hóa riêng biệt: máy chủ bản ghi cần đọc/ghi nhanh và nhất quán cao; máy chủ hộp thư cần thông lượng cao và khả năng chịu lỗi tốt.

Cả hai mô hình phân tách đều tương thích với đặc tả Sesame vì Sesame không giả định bất kỳ kiến trúc cụ thể nào của máy chủ – nó chỉ định nghĩa giao diện logic giữa thiết bị và máy chủ (gửi tin nhắn vào hộp thư, truy xuất bản ghi người dùng/thiết bị, nhận thông báo về DeviceID cũ/mới). Bất kỳ triển khai nào thực hiện đúng giao diện logic đó đều tương thích với Sesame ở phía thiết bị, bất kể hạ tầng bên dưới phức tạp đến mức nào. Điều này là thiết kế có chủ ý: bằng cách trừu tượng hóa máy chủ như một thực thể đơn, đặc tả giữ được tính độc lập với hạ tầng và cho phép các triển khai khác nhau có thể thay thế nhau.

Tích hợp X3DH và Double Ratchet

Sesame được thiết kế để sử dụng kết hợp với các phiên Double Ratchet được thiết lập qua X3DH – đây là cấu hình tham chiếu được Signal Protocol sử dụng và là bối cảnh cụ thể nhất mà đặc tả Sesame hướng đến.

Trong cấu hình này, các thiết bị công bố gói khóa tiền lên máy chủ gồm khóa nhận dạng, khóa tiền ký có chữ ký và một tập khóa tiền một lần. Khi một thiết bị cần tạo phiên khởi tạo với thiết bị khác, nó truy xuất gói khóa tiền từ máy chủ và chạy thuật toán X3DH để tạo ra SK và tin nhắn khởi tạo X3DH. SK được dùng làm khóa gốc ban đầu cho phiên Double Ratchet; tin nhắn khởi tạo X3DH được đính kèm vào mọi tin nhắn khởi tạo Sesame để thiết bị nhận có đủ thông tin tạo phiên Double Ratchet tương ứng.

Điểm quan trọng là tin nhắn khởi tạo X3DH chỉ được gửi kèm cho đến khi nhận được phản hồi Double Ratchet đầu tiên từ thiết bị đích. Khi phản hồi đó đến – qua phiên Sesame, được giải mã thành công bằng phiên Double Ratchet – thiết bị gửi biết rằng phiên đã được thiết lập thành công ở cả hai phía và ngừng đính kèm thông tin X3DH. Từ thời điểm đó, hai thiết bị chỉ giao tiếp thuần túy bằng Double Ratchet mà không cần mang theo overhead của tin nhắn khởi tạo. Cơ chế này giải quyết vấn đề tin nhắn đầu tiên bị mất hoặc đến trễ: Sesame đảm bảo thiết bị gửi liên tục gửi thông tin X3DH cho đến khi xác nhận phiên đã được thiết lập, thay vì coi phiên là thành công sau tin nhắn đầu tiên được gửi đi.

Giới hạn vòng lặp và lưu trữ

Hai loại tài nguyên cần được kiểm soát chặt trong Sesame là số lần lặp của các vòng lặp thích nghi và dung lượng lưu trữ cục bộ. Thiếu kiểm soát ở cả hai điểm này có thể bị khai thác để thực hiện tấn công từ chối dịch vụ (DoS) hay làm cạn kiệt tài nguyên thiết bị.

Vòng lặp gửi tin nhắn thích nghi – liên tục điều chỉnh bản ghi cục bộ để khớp với máy chủ rồi gửi lại – là vector tấn công tiềm năng nếu máy chủ độc hại liên tục thông báo danh sách DeviceID mới. Mỗi vòng lặp yêu cầu thiết bị tạo phiên mới, tiêu tốn tài nguyên tính toán và mạng. Biện pháp đối phó là sử dụng bộ đếm lần lặp lưu trong bộ nhớ trong quá trình gửi; nếu vượt ngưỡng cố định (ví dụ 5 lần), thiết bị kích hoạt lỗi và hủy bỏ toàn bộ thao tác gửi. Tương tự, vòng lặp gửi lại theo MessageRecord cũng cần bộ đếm – lần này lưu bền vững trong chính MessageRecord để bền vững qua khởi động lại.

Về kiểm soát lưu trữ, thiết bị cần đặt giới hạn trên cho ba đại lượng: số lượng DeviceRecord trong một UserRecord (ngăn máy chủ độc hại báo cáo hàng nghìn thiết bị giả); số lượng phiên không hoạt động trong một DeviceRecord (kiểm soát bộ nhớ); và số lượng MessageRecord tổng cộng (kiểm soát dung lượng lưu trữ văn bản gốc nhạy cảm). Khi vượt giới hạn, chiến lược loại bỏ nên ưu tiên giữ lại các bản ghi mới nhất và loại bỏ các bản ghi cũ nhất – đây là heuristic hợp lý vì các bản ghi mới hơn có nhiều khả năng còn cần thiết hơn. Các ngưỡng cụ thể nên được xác định ở cấp độ ứng dụng dựa trên tài nguyên điển hình của thiết bị mục tiêu, không phải ở cấp độ đặc tả Sesame – sự linh hoạt này cho phép cùng một đặc tả áp dụng cho cả điện thoại phổ thông lẫn máy tính để bàn mạnh.

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

Sesame kế thừa phần lớn tính chất bảo mật từ X3DH và Double Ratchet mà nó quản lý, nhưng cũng tự mình đưa ra các cân nhắc bảo mật riêng ở tầng quản lý phiên và thiết bị. Hiểu các cân nhắc này giúp người triển khai đưa ra quyết định đúng đắn và người dùng biết được giới hạn bảo vệ thực sự của hệ thống.

Xác thực

Sesame dựa vào người dùng để thực hiện xác thực khóa công khai nhận dạng của đối tác liên lạc qua kênh ngoài băng. Giao thức không tự mình thực hiện bước xác thực này – đây là quyết định thiết kế có chủ ý, phản ánh thực tế rằng không có phương pháp xác thực nào phù hợp cho tất cả ngữ cảnh. Hai người dùng có thể so sánh dấu vân tay khóa công khai của tất cả thiết bị theo cách thủ công, quét mã QR khi gặp trực tiếp, hay xác nhận qua kênh liên lạc đã được tin cậy trước đó. Chi tiết của các phương thức xác thực nằm ngoài phạm vi bài viết này.

Nếu xác thực không được thực hiện, người dùng sẽ không nhận được bất kỳ đảm bảo mật mã nào về danh tính thực sự của đối tác liên lạc. Bảo mật nội dung tin nhắn vẫn hoàn toàn hoạt động, nhưng người dùng không thể biết mình đang giao tiếp với ai. Đây là điểm yếu không phải của mật mã mà của việc triển khai không đầy đủ.

Một thách thức đặc biệt của Sesame là thiết bị có thể gặp phải sự thay đổi khóa công khai nhận dạng của người dùng từ xa khi gửi, nhận hoặc gửi lại tin nhắn. Thay đổi này có thể có nhiều nguyên nhân hợp lệ: người dùng mới đang dùng UserID cũ; người dùng cài đặt lại ứng dụng; người dùng thêm thiết bị mới với khóa riêng (nếu dùng mô hình khóa theo thiết bị). Tuy nhiên, cũng có thể là dấu hiệu tấn công: máy chủ độc hại giả mạo thiết bị mới, hay kẻ tấn công đã chiếm đoạt UserID. Sesame không thể phân biệt các trường hợp này về mặt mật mã. Khi phát hiện thay đổi khóa, thiết bị nên tạm dừng hoạt động và thông báo người dùng để xác nhận, chứ không tiếp tục tự động. Người dùng xác nhận sự thay đổi hợp lệ mới cho phép thiết bị tiếp tục; nếu không, thiết bị nên giả định đây là tấn công và không gửi thêm tin nhắn đến đối tác đó cho đến khi được xác minh.

Thiết bị bị xâm nhập

Khi thiết bị bị xâm nhập – kẻ tấn công có quyền truy cập vào khóa riêng định danh và trạng thái phiên – bảo mật bị phá vỡ ở nhiều cấp độ đồng thời. Hiểu rõ từng loại thiệt hại giúp người dùng và quản trị viên phản ứng đúng mức.

Nếu kẻ tấn công có khóa riêng định danh, họ có thể giả mạo thiết bị đó trong giao tiếp với các thiết bị khác: gửi tin nhắn dưới tên người dùng, tạo phiên mới X3DH, và duy trì mạo danh lâu dài. Nếu kẻ tấn công duy trì quyền truy cập liên tục, họ có thể cài cửa hậu, làm suy yếu trình tạo số ngẫu nhiên để các khóa tương lai trở nên dự đoán được, hay đọc văn bản thuần của tin nhắn trong bộ nhớ. Kẻ tấn công cũng có thể đánh cắp văn bản thuần từ MessageRecord đang lưu trữ hay từ cơ sở dữ liệu tin nhắn cục bộ.

Sesame kế thừa khả năng chống giải mã thụ động từ Double Ratchet và X3DH: các tin nhắn trước khi xâm phạm được bảo vệ bởi bảo mật chuyển tiếp (khóa đã xóa), và các tin nhắn sau khi xâm phạm dần được bảo vệ trở lại nhờ cơ chế phục hồi sau xâm nhập của Double Ratchet. Tuy nhiên, bảo vệ này chỉ chống lại kẻ nghe lén thụ động, không phải kẻ tấn công duy trì quyền truy cập. Khi thiết bị bị xâm nhập, biện pháp duy nhất có hiệu quả là thay thế hoàn toàn thiết bị, thu hồi và thay thế toàn bộ khóa bị xâm phạm, và thông báo cho tất cả đối tác liên lạc để họ xác minh lại khóa định danh mới.

Bảo vệ giao tiếp với máy chủ

Giao tiếp giữa thiết bị và máy chủ – gửi tin nhắn vào hộp thư, truy xuất bản ghi thiết bị, nhận thông báo – nên được mã hóa và xác thực bằng giao thức tầng vận chuyển (như TLS với certificate pinning). Thiếu bảo vệ này tạo ra nhiều vector tấn công nghiêm trọng.

Kẻ nghe trộm trên kênh thiết bị–máy chủ có thể thu thập siêu dữ liệu: ai liên lạc với ai, tần suất, thời điểm, kích thước tin nhắn – ngay cả khi không thể giải mã nội dung. Trong nhiều ngữ cảnh, siêu dữ liệu này nhạy cảm không kém nội dung. Kẻ tấn công thực hiện tấn công người đứng giữa (man-in-the-middle) trên kênh thiết bị–máy chủ có thể giả mạo phản hồi của máy chủ để chèn DeviceID giả vào danh sách thiết bị, hay thay đổi gói khóa tiền. Các biện pháp đối phó bao gồm: TLS với certificate pinning để ngăn giả mạo chứng chỉ; xác thực thiết bị với máy chủ bằng cách ký một nonce bằng khóa riêng định danh trong quá trình đăng ký – điều này ngăn kẻ tấn công giả mạo thiết bị nạn nhân để lấy tin nhắn của họ; và gán DeviceID ngẫu nhiên thay vì DeviceID dự đoán được để làm khó các cuộc tấn công liệt kê. Ngay cả khi kẻ tấn công giả mạo thành công thiết bị nạn nhân và lấy được các bản mã gửi đến hộp thư đó, họ vẫn không thể giải mã vì không có khóa phiên tương ứng – đây là lớp bảo vệ cuối cùng.

Xóa dữ liệu và quản lý vòng đời phiên

Hai vấn đề liên quan chặt chẽ cần được xử lý đồng thời: khi nào xóa MessageRecord (chứa văn bản nhạy cảm) và khi nào xóa phiên cũ (để giải phóng tài nguyên và giảm thiểu rủi ro). Cả hai đều được điều chỉnh bởi cùng nguyên tắc cơ bản: không giữ dữ liệu nhạy cảm lâu hơn thực sự cần thiết, nhưng cũng không xóa trước khi chắc chắn không còn cần đến.

Về MessageRecord: khi người dùng chủ động xóa một tin nhắn khỏi giao diện, tất cả MessageRecord chứa bản sao văn bản của tin nhắn đó phải bị xóa ngay lập tức và đồng thời. Điều này đảm bảo hành động xóa của người dùng có hiệu lực thực sự, không chỉ ở tầng giao diện. MessageRecord cũng có thể được xóa khi nhận biên nhận giao hàng, hay khi hết thời gian tối đa lưu trữ.

Về phiên cũ: Sesame dùng hằng số MAXLATENCY như ngưỡng an toàn. Sau khi đánh dấu một bản ghi là stale, thiết bị đợi ít nhất MAXLATENCY trước khi xóa nó – đủ thời gian để bất kỳ tin nhắn nào đang trên đường (và cần phiên cũ để giải mã) đến hộp thư và được xử lý. Điều kiện đủ để xóa là: dấu thời gian stale đã qua MAXLATENCY và thiết bị đã xử lý xong toàn bộ hộp thư. Kết hợp hai điều kiện này đảm bảo không bao giờ xóa phiên khi còn tin nhắn cần đến nó.

Lỗi đồng hồ là rủi ro thực tế: nếu đồng hồ thiết bị chạy nhanh, bản ghi có thể bị xóa quá sớm khiến tin nhắn bị trễ không thể giải mã; nếu chạy chậm hay bị thao túng, các bản ghi stale không bao giờ bị xóa làm tích lũy dữ liệu nhạy cảm. Biện pháp giảm thiểu là kết hợp kiểm tra thời gian với kiểm tra dựa trên sự kiện – ví dụ đếm số vòng trao đổi tin nhắn hay số bước tăng DH – để tránh phụ thuộc hoàn toàn vào đồng hồ thiết bị.

Vòng lặp giới hạn và lưu trữ giới hạn (Bounded loops and bounded storage)

Thiếu kiểm soát giới hạn ở tầng Sesame mở ra hai loại tấn công: tấn công tiêu hao tài nguyên tính toán (thông qua vòng lặp không giới hạn) và tấn công tiêu hao tài nguyên lưu trữ (thông qua tích lũy bản ghi không giới hạn). Cả hai đều có thể bị kẻ tấn công khai thác mà không cần phá vỡ bất kỳ cơ chế mật mã nào.

Vòng lặp gửi tin nhắn thích nghi liên tục cố gắng điều chỉnh bản ghi thiết bị khớp với bản ghi máy chủ. Nếu máy chủ độc hại liên tục thông báo DeviceID mới hết lần này đến lần khác, vòng lặp sẽ không bao giờ kết thúc, tiêu tốn tài nguyên tính toán và mạng của thiết bị. Biện pháp đối phó là bộ đếm lần lặp trong bộ nhớ với ngưỡng cứng; khi vượt ngưỡng, thiết bị kích hoạt lỗi và hủy toàn bộ thao tác. Quá trình gửi lại theo MessageRecord cũng cần bộ đếm, lần này lưu bền vững trong MessageRecord để chống lại các vòng lặp kéo dài qua nhiều lần khởi động lại thiết bị.

Về lưu trữ, ba giới hạn quan trọng: số lượng DeviceRecord mỗi UserRecord, số lượng phiên không hoạt động mỗi DeviceRecord, và tổng số MessageRecord. Khi bất kỳ giới hạn nào bị vượt, chiến lược loại bỏ ưu tiên giữ bản ghi mới nhất và xóa cũ nhất. Các giới hạn cụ thể nên được căn chỉnh theo tài nguyên điển hình của thiết bị mục tiêu và hành vi bình thường của ứng dụng: giới hạn quá thấp gây mất tin nhắn hợp lệ, giới hạn quá cao để lộ bề mặt tấn công. Thực nghiệm với dữ liệu người dùng thực tế là cách tốt nhất để căn chỉnh các ngưỡng này.

Xử lý lỗi

Xử lý lỗi đúng đắn trong Sesame là yêu cầu bắt buộc về bảo mật, không chỉ là thực hành lập trình tốt. Một lỗi được xử lý sai – đặc biệt là lỗi để lại trạng thái thiết bị ở trạng thái thay đổi một phần – có thể gây mất tin nhắn, không thể giao tiếp, hay tạo ra lỗ hổng bảo mật tinh vi. Phần này xác định các nguyên tắc và chiến lược xử lý lỗi cho Sesame.

Nguyên tắc xử lý lỗi

Nguyên tắc cốt lõi của xử lý lỗi trong Sesame là tất cả hoặc không có gì (all-or-nothing): bất kỳ lỗi nào trong quá trình gửi, nhận hay gửi lại tin nhắn phải kết thúc toàn bộ quá trình và hủy bỏ mọi thay đổi trạng thái đã thực hiện trong quá trình đó, đưa thiết bị trở về trạng thái nhất quán trước khi thao tác bắt đầu. Trạng thái không nhất quán – ví dụ đã gửi tin nhắn đến một số hộp thư nhưng chưa đến tất cả, hay đã cập nhật bản ghi cục bộ nhưng chưa lưu xuống đĩa – là nguyên nhân của hầu hết các lỗi bí ẩn trong hệ thống nhắn tin phân tán.

Thực hiện nguyên tắc all-or-nothing đòi hỏi cơ chế giao dịch (transactional semantics) trong quá trình cập nhật trạng thái: các thay đổi cục bộ được tích lũy trong bộ nhớ và chỉ được cam kết (committed) xuống lưu trữ bền vững khi toàn bộ thao tác thành công. Nếu xảy ra lỗi trước khi cam kết, không có thay đổi nào được ghi xuống. Kết hợp với ghi nguyên tử (atomic write) – ghi vào tệp tạm rồi thay thế tệp cũ – đảm bảo không bao giờ có trạng thái không nhất quán trên đĩa ngay cả khi thiết bị tắt đột ngột giữa chừng.

Phân loại lỗi giúp xác định phản ứng phù hợp. Lỗi tạm thời – lỗi mạng, máy chủ quá tải, timeout – thường có thể thử lại sau một khoảng chờ ngắn. Lỗi mật mã – xác thực AEAD thất bại, chữ ký không hợp lệ – chỉ ra dữ liệu bị giả mạo hay phiên không khớp, không nên thử lại mà phải hủy tin nhắn và ghi log để phân tích. Lỗi trạng thái – bản ghi không tồn tại, phiên hỏng, dữ liệu không nhất quán – thường chỉ ra vấn đề trong logic triển khai và cần điều tra kỹ hơn. Phân loại đúng và xử lý riêng biệt từng loại lỗi là điều kiện để hệ thống vừa đáng tin cậy vừa an toàn.

Lỗi trong quá trình gửi và gửi lại

Lỗi trong quá trình gửi tin nhắn có thể xảy ra ở nhiều điểm khác nhau của quy trình. Lỗi tạo phiên (khi cần tạo phiên mới cho DeviceID vừa được khám phá) là lỗi sớm nhất và sạch nhất để xử lý: vì chưa có tin nhắn nào được gửi đến bất kỳ hộp thư nào, thiết bị chỉ cần hủy tất cả thay đổi bản ghi cục bộ và kết thúc. Lỗi tại bước gửi lên máy chủ – sau khi đã mã hóa tin nhắn nhưng máy chủ từ chối hay kết nối thất bại – phức tạp hơn: một số hộp thư có thể đã nhận được tin nhắn trong khi các hộp thư khác chưa. Đây là trường hợp gửi một phần (partial delivery) mà tầng cao hơn phải sẵn sàng xử lý.

Lỗi gửi một phần là không thể tránh khỏi hoàn toàn trong hệ thống phân tán, vì ngay cả với giao dịch nguyên tử ở phía thiết bị, mạng vẫn có thể thất bại sau khi một số hộp thư đã nhận tin nhắn. Sesame không cố gắng giải quyết hoàn toàn vấn đề này ở tầng giao thức cơ sở – đây là thiết kế đúng đắn vì giải pháp hoàn chỉnh đòi hỏi phối hợp phân tán phức tạp hơn. Thay vào đó, Sesame giao trách nhiệm xử lý gửi một phần cho tầng giao thức cao hơn xây dựng trên nó. Cơ chế MessageRecord và gửi lại chính là công cụ mà tầng cao hơn có thể sử dụng để đảm bảo cuối cùng tất cả người nhận đều nhận được tin nhắn.

Lỗi trong quá trình gửi lại có thể xảy ra ở nhiều bước: khi truy vấn khóa công khai từ máy chủ, khi tạo phiên mới, khi mã hóa lại hay khi gửi lên máy chủ. Ở mỗi bước, nếu xảy ra lỗi, toàn bộ thao tác gửi lại phải bị hủy và bộ đếm lần thử gửi lại trong MessageRecord được tăng lên. Sau khi bộ đếm vượt ngưỡng, MessageRecord bị xóa và không có thêm lần gửi lại nào. Đây là hành vi an toàn hơn là tiếp tục thử vô hạn.

Chiến lược phục hồi ở tầng giao thức cao hơn

Sesame xác định các nguyên thủy (primitives) cần thiết để xây dựng giao tiếp mã hóa đa thiết bị đáng tin cậy, nhưng không tự mình đảm bảo toàn bộ tính nhất quán đầu cuối. Các giao thức xây dựng trên Sesame cần tự mình thực hiện các chiến lược bổ sung để đảm bảo trải nghiệm người dùng tốt ngay cả khi có lỗi.

Cơ chế giao dịch ở tầng giao thức cao hơn có thể yêu cầu máy chủ chỉ xác nhận tin nhắn vào hộp thư sau khi tất cả hộp thư dự kiến đều nhận thành công. Nếu bất kỳ hộp thư nào thất bại, toàn bộ thao tác bị rollback. Đây là giải pháp mạnh nhất cho bài toán gửi một phần nhưng đặt ra yêu cầu đồng nhất trạng thái (distributed consensus) trên máy chủ – một bài toán có độ phức tạp và chi phí vận hành đáng kể. Thực tế, hầu hết triển khai lớn chọn cách tiếp cận cuối cùng nhất quán (eventual consistency) thay vì đồng nhất tức thì: chấp nhận rằng gửi một phần có thể xảy ra, nhưng đảm bảo rằng thông qua cơ chế gửi lại và MessageRecord, cuối cùng tất cả người nhận đều nhận được tin nhắn trong một khoảng thời gian chấp nhận được.

Giao thức cũng nên định nghĩa hành vi rõ ràng khi người dùng trải nghiệm tình trạng tin nhắn chỉ xuất hiện trên một số thiết bị của mình: thông báo người dùng, cho phép thử gửi lại thủ công, hay tự động đồng bộ hóa lịch sử tin nhắn giữa các thiết bị. Sự kết hợp đúng đắn của các chiến lược này phụ thuộc vào yêu cầu cụ thể của ứng dụng và mức độ chấp nhận sự không nhất quán tạm thời.

Kết luận

Sesame giải quyết bài toán phức tạp hơn đáng kể so với Double Ratchet đơn lẻ: quản lý đồng thời nhiều phiên Double Ratchet cho nhiều thiết bị của cùng người dùng, đảm bảo rằng tin nhắn đến được tất cả thiết bị mà không phá vỡ các tính chất bảo mật của từng phiên. Cơ chế MessageRecord và hai pha gửi – kiểm tra trước rồi gửi thực sự – là giải pháp thực tiễn cân bằng giữa nhất quán dữ liệu và hiệu suất, trong khi các chiến lược xử lý lỗi nhiều lớp đảm bảo hệ thống phục hồi được từ các lỗi phổ biến mà không cần trạng thái phức tạp phía người dùng.

Sự tách biệt giữa máy chủ lưu trữ phiên và máy chủ truyền tải tin nhắn là lựa chọn kiến trúc quan trọng: không cho phép bất kỳ máy chủ đơn lẻ nào thấy được đủ thông tin để suy ra mẫu giao tiếp đầy đủ, trong khi vẫn cung cấp dịch vụ nhắn tin hoạt động được. Hiểu Sesame là hiểu tại sao Signal Protocol có thể đồng thời bảo mật và đa thiết bị – hai tính chất tưởng chừng mâu thuẫn nhưng được thiết kế để cùng tồn tại qua cơ chế quản lý phiên chuyên biệt này.