Phiên kín từ đầu đến cuối (phiên kín)

Android Console mở mã hóa hai đầu từ Cài đặt, với lựa chọn thiết bị bên trong trang. Cài đặt tài khoản Android và Web Console hỗ trợ cài đặt hoặc thay đổi mật khẩu và ràng buộc hoặc thay thế email; email hiện tại vẫn hoạt động cho đến khi địa chỉ mới được xác minh. Console sao lưu khóa riêng gốc thành Exchange với cụm mật khẩu trống theo mặc định, duy trì các bản sao lưu cụm mật khẩu hiện có. Việc xóa bản sao lưu sẽ vô hiệu hóa tính năng lưu tự động trên máy khách đó. Cụm mật khẩu trống cho phép Exchange hoặc chủ sở hữu cơ sở dữ liệu giải mã thư mục gốc. Khôi phục thủ công sẽ xác minh thư mục gốc của không gian làm việc trước khi duy trì nó và đồng bộ hóa các khoản trợ cấp.

Mục tiêu: Ngay cả khi máy chủ Exchange bị xâm phạm hoặc người điều hành nó tò mò, nó không thể đọc các lệnh, đầu ra, byte PTY, nội dung tập tin, ảnh chụp màn hình, hoặc dữ liệu ubus, và không thể quyết định hoặc giả mạo ai có thể xem hoặc quản lý thiết bị. Exchange chỉ đóng vai trò chuyển tiếp cho siêu dữ liệu định tuyến và văn bản mã hóa.

Định nghĩa: crates/proto/src/seal.rs (loại dây, quy tắc ủy quyền cục bộ), crates/proto/src/seal/crypto.rs (mật mã phiên, chỉ đổ chuông), crates/proto/src/seal/backup.rs (sao lưu mật khẩu: Argon2id + ChaCha20-Poly1305, không được liên kết với agent), crates/agent/src/seal.rs (phía thiết bị), crates/cli/src/seal.rs (phía CLI), shared/seal-session.js (triển khai phiên được chia sẻ bởi Web Console và Android Console, @noble/curves · @noble/hashes · @noble/ciphers), shared/seal-backup.js (trên cùng một bộ thư viện sao lưu mật khẩu Argon2id). Vectơ kiểm tra đa ngôn ngữ: shared/seal-vectors.json (JS được tạo, Rust javascript_vectors_interoperate xác minh chữ ký/HKDF/văn bản mã hóa byte nhất quán theo byte), shared/seal-rust-vectors.json (Phản hồi của thiết bị Rust, JS shared/seal-session.test.js hoàn tất bắt tay và giải mã).

seal approve vẫn tự động công bố quyền. Lệnh seal grant --publish tiếp theo (hoặc việc công bố mặc định khi đã đăng nhập) bỏ qua quyền đã công bố còn hiệu lực nếu khóa bên cấp, khóa bên nhận, thiết bị và mức quyền đều trùng nhau, thông báo đã công bố và không tạo mã thông báo mới. Dùng --renew-before DAYS để gia hạn quyền sắp hết hạn; --no-publish vẫn ký mã thông báo ngoại tuyến. Kiểm tra này ngăn bản trùng do thử lại tuần tự; nó không tạo giao dịch giữa các máy khách chạy đồng thời và không xóa bản trùng cũ. seal show tạo danh tính cục bộ và đăng ký khóa khi đã đăng nhập; hãy dùng hồ sơ riêng cho danh tính thử nghiệm.

Mô hình mối đe dọa

Ngoài phạm vi bảo vệ: thiết bị hoặc máy tính của nhà điều hành bị xâm nhập hoặc Exchange đã mạo danh một thiết bị trên kết nối đầu tiên (TOFU). So sánh dấu vân tay ngoài dải để tránh trường hợp cuối cùng. Tất cả các hoạt động của thiết bị đều yêu cầu phiên kín. Thư mục lệnh đặt trước và ranh giới ủy quyền chuỗi gốc của trình duyệt được mô tả bên dưới.

Phạm vi và thiết kế đường dẫn

Các lệnh HTTP và đặt trước

Hoạt động niêm phong gốc hiện hỗ trợ người gọi chỉ HTTP. Sử dụng remote-cli --transport http hoặc REMOTE_TRANSPORT=http. POST /api/sealed/connections tạo hộp thư; POST /input gửi các bản bắt tay hoặc văn bản mã hóa đã ký, kết quả thăm dò GET /events và DELETE đóng kết nối. Khách hàng giữ lại mật mã đầu cuối và ủy quyền thiết bị hiện có. Điểm cuối hành động của thiết bị ban đầu vẫn trả về 409. Kết nối thiết bị không thay đổi.

https://remote.ivjn.us/sealed-http.md

Việc tạo, chỉnh sửa và liệt kê các lệnh đặt trước vẫn là bề mặt quản lý cơ sở dữ liệu Exchange và văn bản mẫu, tên và mô tả trong thư mục không phải là dữ liệu kín cũng như các lệnh không được ký bởi danh sách cho phép gốc. Bảng điều khiển và CLI thực thi mẫu được tìm nạp như một trình thực thi được niêm phong thông thường (không giữ) trong khi giữ phím; thiết bị chỉ tin cậy vào chính sách gốc và sự cấp phép của nhà điều hành chứ không phải ID thư mục, vai trò máy chủ hoặc đối số "đây là lệnh đặt trước". Các thành viên chỉ nắm giữ cấp view không thể chạy các lệnh đặt trước; Cần có quyền root manage. Không thể mở rộng cấp quyền nếu thư mục bị giả mạo, nhưng manage cho phép thực thi tùy ý, vì vậy vui lòng kiểm tra mẫu và không ghi mật khẩu/mã thông báo vào thư mục máy chủ. Đầu ra chỉ được giải mã và hiển thị cục bộ trên toán tử; kiểm tra đường dẫn chạy chỉ ghi lại siêu dữ liệu được niêm phong và không ghi lại các lệnh và đầu ra.

Lựa chọn mạng LAN và máy khách

Các phiên thiết bị CLI chỉ sử dụng tính năng niêm phong từ đầu đến cuối, độc lập với seal_key, khả năng hoặc gợi ý chính sách do Exchange báo cáo. Thông tin về khả năng bị thiếu hoặc bị xóa không bao giờ gây ra việc hạ cấp bản rõ. Việc không đọc được cơ sở dữ liệu mã pin cục bộ là một lỗi; hồ sơ tin cậy bị hỏng không được bỏ qua.

Các tác vụ tệp và tệp thực thi được giữ/không được giữ được đánh dấu kín trước khi được xuất bản vào thư mục tác vụ chung và không thể dựa vào điều kiện thực thi là "đóng phiên trước khi xử lý sự kiện gửi đi đầu tiên" để đọc bản xem trước văn bản rõ ràng. Nhật ký thiết bị không ghi lại mục tiêu hoặc phương thức thăm dò HTTP, đối tượng hoặc phương thức ubus.

LAN tái sử dụng các phong bì gốc, bản ghi chữ ký, bộ đếm, AEAD, quy tắc cố định và thu hồi thiết bị mà không tạo ra các thuật toán mã hóa mới. Mạng LAN gửi đi đi qua Tunnels::seal_outbound và được dịch sang OperatorDown; việc đưa văn bản gốc của số phiên đã được niêm phong sẽ bị bộ điều phối thiết bị loại bỏ. Kết nối bị đóng trong khi vẫn tách lệnh thực thi bị giữ, hủy các hoạt động khác và đầu ra trễ bị id có rào chắn loại bỏ. Không có mã thông báo LAN: máy khách đặt chuỗi chứng chỉ và cấp phép được lưu trong bộ nhớ đệm ngoại tuyến vào hello và thiết bị xác định chế độ xem/quản lý theo cùng một authorize như Exchange. Lớp bên ngoài chỉ kiểm tra địa chỉ mạng riêng và Origin. Các phiên văn bản rõ ràng luôn bị từ chối trên mạng LAN, bất kể giá trị chính sách lịch sử. Bảng điều khiển web được lưu trữ vẫn được kết nối với Exchange.

Thông tin thiết bị tùy chọn info.seal_mode (allow / require), seal_key và khả năng sealed vẫn tương thích. Chúng không phải là khóa công khai được ủy quyền cũng như không phải của thiết bị đáng tin cậy; thiết bị cuối cùng sẽ thực thi chính sách. Các lệnh, thiết bị đầu cuối, tệp, ubus, cảm biến, công việc, thăm dò mạng, hoạt động trên máy tính để bàn, cập nhật thiết bị, lệnh cài sẵn và hoạt động của trình duyệt trong CLI, Web Console và Android Console đều sử dụng phiên kín gốc. Không có đường dẫn bản rõ có sẵn. Giá trị chính sách allow cũng từ chối các hoạt động văn bản gốc. Các lỗi bắt tay, ghim thiết bị, cấp phép hoặc giải mã sẽ dừng hoạt động mà không cần thử lại bản rõ. Thay đổi chính sách trực tuyến làm mới thông tin mạng LAN ngay lập tức; thông tin đám mây làm mới khi kết nối lại và đăng ký.

Xác thực chuỗi gốc không gian làm việc của trình duyệt Agent

Tiện ích mở rộng quảng cáo sealed, Ed25519 seal_key và seal_mode: require. Sau khi ghép nối hoặc cấu hình thiết bị, nó gọi POST /api/seal/device với thông tin xác thực thiết bị và bằng chứng sở hữu có chữ ký. Exchange lấy không gian làm việc từ thiết bị và liên kết khóa chung của thiết bị. Một khách hàng nắm giữ khóa riêng tư gốc của không gian làm việc đáng tin cậy sẽ ký cấp quyền xem cho thiết bị trình duyệt chính xác đó. Người đăng ký và người mang thiết bị cung cấp quyền truy cập chuyển tiếp và truy xuất thông tin xác thực; phiên trình duyệt yêu cầu xác thực chứng chỉ.

Tiện ích mở rộng xác minh chữ ký đến, chuỗi gốc, phạm vi thiết bị, cấp độ, thời hạn sử dụng và thu hồi cục bộ, sau đó ký SealAccept bằng SealHello có chữ ký của chính nó trong peer. CLI finish_workspace_operator và finishBrowser được chia sẻ xác minh bằng chứng đó, yêu cầu peer.operator_key == accept.device_key và xác minh chữ ký chấp nhận. Bằng chứng bị thiếu hoặc không hợp lệ sẽ đóng phiên. Các phiên hợp lệ sẽ tự động bắt đầu. Ngoài ra, CDP thô còn yêu cầu sự đồng ý cục bộ theo yêu cầu hoặc phê duyệt không giám sát trong phạm vi khóa của nhà điều hành, máy chủ và thiết bị; trợ cấp xem không thể sử dụng CDP.

Tiện ích mở rộng phạm vi các bản ghi ủy quyền theo nguồn gốc máy chủ, không gian làm việc và thiết bị. Hạt giống nhận dạng cục bộ của nó chỉ có thể truy cập được đối với các bối cảnh tiện ích mở rộng đáng tin cậy. Nó ghim gốc không gian làm việc đầu tiên cục bộ và từ chối các thay đổi. CLI và Console sử dụng danh tính con dấu thông thường và chuỗi gốc không gian làm việc mà không cần trình chỉnh sửa mã pin trình duyệt riêng. Ký khóa gốc, cơ quan cấp chứng chỉ và thông tin đăng ký thiết bị là các bước kiểm tra riêng biệt; Khóa thiết bị gốc TOFU vẫn riêng biệt.

Ranh giới bảo mật: TOFU gốc đầu tiên không thể phân biệt được root giả do rơle độc hại cung cấp; xác minh nó ra khỏi băng tần. PoP chứng minh quyền sở hữu quan trọng chứ không phải sự chấp thuận của thành viên. Tự động phê duyệt máy khách gốc phụ thuộc vào danh sách; triển khai nhạy cảm nên xem xét các khóa mới. Bảo vệ chuỗi xuất bản hồ sơ tiện ích mở rộng, hạt giống và bảng điều khiển web. Các điểm cuối bị xâm phạm hoặc quyền truy cập CDP đầy đủ được cấp cho các nhà khai thác độc hại nằm ngoài phạm vi bảo vệ niêm phong. Việc xóa các bản ghi thư mục không thu hồi thông tin xác thực đã ký được lưu trong bộ nhớ đệm; quy tắc thu hồi và hết hạn trên thiết bị cục bộ vẫn còn quan trọng. Exchange vẫn có thể quan sát siêu dữ liệu định tuyến, giữ lại thông tin xác thực và từ chối dịch vụ.

Khi không có danh tính: Nếu không thể tải hoặc ghi danh tính thiết bị, các phiên kín sẽ không khả dụng và tất cả các hoạt động văn bản gốc vẫn bị từ chối (đóng không thành công). Các tệp chính sách bị thiếu hoặc bị hỏng và các giá trị chính sách lịch sử không bao giờ kích hoạt bản rõ. Sửa chữa lưu trữ khóa cục bộ trên thiết bị.

Hộp thư HTTP yêu cầu có mối quan hệ giống với phiên bản Exchange đang tạo và hết hạn sau 90 giây mà không hoạt động. Tuần tự hóa các đầu vào, chỉ thử lại cùng một chuỗi và văn bản mã hóa, đồng thời xác nhận các sự kiện đã xử lý bằng after. Web Console, thiết bị di động và mạng LAN vẫn giữ nguyên phương tiện truyền tải hiện có của chúng. Việc thực thi cài sẵn vẫn yêu cầu manage.

Xác minh hồi quy

Các thử nghiệm Rust bao gồm bắt tay cấp thiết bị thực, kết quả thực thi/đính kèm/đuôi/cat/cảm biến/net/cập nhật được niêm phong, từ chối văn bản gốc theo mọi giá trị chính sách, bắt tay/khung/cập nhật chính sách được niêm phong LAN WebSocket, hướng dẫn HTTP 409, đóng tuyến chế độ yêu cầu của trình duyệt và các bất biến niêm phong bắt buộc đối với thông tin máy khách và thiết bị. Các thử nghiệm JavaScript bao gồm các vectơ Rust/JS hai chiều hiện có, các đường bao hoạt động, đầu ra lệnh đặt trước được niêm phong mà không có dự phòng sau khi bị từ chối, cấu hình trình duyệt/đăng ký/từ chối thiết bị/thay đổi chính sách cục bộ và lỗi ghim ứng dụng khách. Các gói con dấu trên toàn quy trình được khởi tạo trong các quy trình con riêng biệt trong quá trình thử nghiệm để các thử nghiệm đồng thời không thể sửa đổi chính sách thiết bị của nhau.

CARGO_PROFILE_DEV_DEBUG=0 CARGO_PROFILE_TEST_DEBUG=0 cargo test --workspace
cargo fmt --all --check
CARGO_PROFILE_DEV_DEBUG=0 CARGO_PROFILE_TEST_DEBUG=0 cargo clippy --workspace --all-targets -- -D warnings
npm test --prefix shared
npm test --prefix website/console
npm test --prefix browser-agent
node --test scripts/test-pages-worker.mjs

JavaScript sử dụng Nút 24+. Đã thêm hồi quy mạng LAN kín để nâng cấp HTTP thực / WebSocket thông qua truyền phát song công trong bộ nhớ, với khả năng xác minh bắt tay, khung và niêm phong bắt buộc theo mọi giá trị chính sách trong hộp cát vô hiệu hóa ổ cắm mạng. Thử nghiệm WS/TLS/HTTP vòng lặp hiện tại vẫn cần phải ở trong môi trường cho phép liên kết cổng, nếu không nó sẽ thất bại với Operation not permitted và không thể dùng làm bằng chứng cho thấy toàn bộ các thử nghiệm đã vượt qua. Kiểm tra đường dẫn cập nhật và thăm dò mạng xác minh kết quả thành công/lỗi, các bản cập nhật không được tải xuống hoặc cài đặt.

Rủi ro đặc biệt của Web Console: Bản thân mã trang web được cung cấp bởi trang Trang. Trang web/CDN bị xâm nhập có thể phát hành các tập lệnh độc hại để đọc văn bản thuần túy của trang này hoặc ký tên bằng khóa của trình duyệt (nhưng nó không thể lấy đi khóa riêng tư không thể xuất được). Điều kiện tiên quyết để bảo mật từ nhà điều hành Exchange là bạn tin tưởng vào chuỗi xuất bản của trang tĩnh; nếu bạn không chắc chắn về điều này, vui lòng sử dụng CLI hoặc Android Console.

Danh tính và chìa khóa

Khóa riêng của người vận hành được lưu trữ cục bộ. Console tải lên bản sao lưu gốc với cụm mật khẩu trống theo mặc định; Exchange hoặc chủ sở hữu cơ sở dữ liệu có thể giải mã nó. Đặt cụm mật khẩu sao lưu theo cách thủ công hoặc xóa bản sao lưu để tắt tính năng lưu tự động trên máy khách này.

Ủy quyền (Exchange không có thẩm quyền)

Thiết bị chỉ tin cậy một khóa chung gốc của không gian làm việc. Chính sách địa phương agent.seal.json:

{"mode":"require","root_key":"<base64 Ed25519>","revoked_keys":[]}

agent tự xác định cấp độ cho từng sealed_open:

1. Không có gốc không gian làm việc nào được ghim trên thiết bị → từ chối (no workspace root pinned on this device).
2. Khóa công khai của nhà điều hành tại revoked_keys → Bị từ chối.
3. Khóa chung của nhà điều hành là root_key → owner (có thể quản lý + sửa đổi chính sách cục bộ).
4. grant được cung cấp: chữ ký của nó hợp lệ, operator_key khớp với bắt tay, device_id nhận dạng thiết bị này hoặc * và cấp phép nằm trong khoảng thời gian hiệu lực của nó (±5 phút so với độ lệch đồng hồ). Người ký của nó phải là gốc được ghim hoặc xin chào phải mang chuỗi chứng chỉ rsc1. (hello.chain, không được bao phủ bởi chữ ký bắt tay), được sắp xếp từ chứng chỉ do gốc cấp cho người ký cấp. Mỗi chứng chỉ phải cho phép cấp thêm và độ dài đường dẫn, cấp độ, phạm vi thiết bị và thời hạn sử dụng phải nằm trong chứng chỉ trước đó. Mức cấp là view hoặc manage, không bao giờ là owner.
5. Khác → Từ chối.

Ràng buộc chuỗi chứng chỉ

Các thiết bị chấp nhận chuỗi rsc1. xác minh trở lại thư mục gốc của không gian làm việc được ghim chứ không phải chứng chỉ trung gian riêng biệt (hello.chain, được đặt hàng từ chứng chỉ do thư mục gốc cấp cho người ký cấp). Có không có giới hạn độ sâu tổ chức: tổ chức có thể có nhiều hơn 10 cấp độ. Một lan can bảo vệ DoS rộng rãi giới hạn chuỗi ở các chứng chỉ MAX_CERT_CHAIN = 64 và kích thước được mã hóa của nó (tổng độ dài mã thông báo rsc1. chuẩn) đến MAX_CERT_CHAIN_BYTES ≤ 64 KiB (check_chain_limits / checkChainLimits trong crates/proto/src/seal.rs / shared/seal-cert.js; quy tắc giống hệt nhau trên các thiết bị, Exchange, CLI, Web và Android). Vượt quá một trong hai giới hạn sẽ gây ra sự từ chối ngay lập tức.

Mỗi chứng chỉ cũng có max_path_len (0–255), ràng buộc nhà phát hành Option về số lượng chứng chỉ có thể tuân theo nó. Không có --max-path, seal cert issue mặc định ở tất cả độ sâu còn lại của nhà phát hành (255 thực tế là không giới hạn). Việc xác minh yêu cầu số lượng chứng chỉ tiếp theo không lớn hơn max_path_len. Chứng chỉ trung gian do root cấp cho quản trị viên có max_path_len 0: quản trị viên có thể ký cấp phép nhưng không thể cấp chứng chỉ khác. can_issue sai cũng ngăn cản việc cấp thêm chứng chỉ.

Chứng chỉ con phải nằm trong chứng chỉ gốc (cert_within_parent / verify_chain trên thiết bị):

• level không vượt quá cấp độ gốc. Gốc là owner; cấp độ được cấp chỉ có thể là view hoặc manage và không được cao hơn chứng chỉ gốc. owner không thể xuất hiện trong chứng chỉ hoặc cấp.
• DPhạm vi thiết bị là tập hợp con của cấp độ gốc. Một thiết bị con chỉ có thể bao phủ tất cả các thiết bị nếu thiết bị gốc chứa *; nếu không thì mỗi thiết bị của trẻ phải nằm trong danh sách của phụ huynh. Con chỉ được viết * nếu cha mẹ cũng là *.
• Thời gian hết hạn không được muộn hơn chứng chỉ gốc. Rễ không có giới hạn hết hạn. Cấp cũng không thể muộn hơn chứng chỉ đã cấp nó và thiết bị cũng không được vượt quá phạm vi của chứng chỉ đó.

Việc thu hồi chứng chỉ trung gian sẽ chuyển sang mọi thứ bên dưới nó. Thiết bị kiểm tra mọi subject_key và serial trên chuỗi so với revoked_keys trong chính sách. Sau khi cái ở giữa bị thu hồi, bất kỳ chuỗi nào còn mang nó đều không thành công, do đó, các chứng chỉ cấp dưới mà nó cấp, cũng như thẩm quyền do các chứng chỉ đó cấp, trở nên không hợp lệ. Việc xóa chứng chỉ khỏi Exchange chỉ dừng việc phân phối thêm và bản sao đã được lưu trên thiết bị vẫn còn hiệu lực trước khi hết hạn; để làm cho toàn bộ chuỗi bên dưới không hợp lệ ngay lập tức, hãy ghi khóa công khai chủ đề (hoặc số sê-ri) của chứng chỉ vào chính sách thiết bị revoked_keys.

Ánh xạ các cấp độ thành hành động (proto::seal::required_level): view (chỉ xem) cho phép cảm biến, giữ danh sách công việc, Android hành động chỉ đọc (trạng thái/cây/ảnh chụp màn hình/find_text); mọi thứ khác (exec, PTY, tệp, ubus, phát hiện mạng, tự cập nhật, đầu vào Android) đều yêu cầu manage.

Ủy quyền là JSON có chữ ký gốc. Bất kỳ trường nào bị giả mạo bởi Exchange (chẳng hạn như xem→quản lý, thay đổi thiết bị, kéo dài thời hạn hiệu lực, thay đổi người được ủy quyền) sẽ làm mất hiệu lực chữ ký; chữ ký bắt tay cũng ràng buộc ủy quyền cho phiên này. Vai trò tài khoản ở phía Exchange chỉ xác định "liệu tin nhắn có thể được định tuyến đến thiết bị này hay không" (khả năng hiển thị của đối tượng thuê) và không mở rộng hoặc giảm quyền của các phiên kín. Không có xác nhận quyền sở hữu, chủ sở hữu hoặc người đồng sở hữu ở cấp thiết bị: owner duy nhất là root.

Cách thiết bị ghim root:

• TOFU: Khi một thiết bị có khả năng niêm phong kết nối với Exchange, Exchange sẽ gửi seal_root {token, rotation?} (bản ghi gốc rsr1. tự ký). Thiết bị xác minh chữ ký tự; nếu không có root nào được ghim cục bộ, nó sẽ ghim root này và ghi nó vào agent.seal.json.
• Rotation: Sau khi root được sửa, root được Exchange thông báo sẽ thay đổi. Thiết bị chỉ thay đổi sang root mới khi đồng thời nhận được bản ghi xoay rsx1. được ký bởi root cố định (old_root = root cố định, new_root = root mới, cùng không gian làm việc); nếu không, nó sẽ bị bỏ qua và ghi lại. Root cũng có thể được thay đổi trong phiên kín với seal_policy_set {root_key} (chỉ root hiện tại mới có cấp độ owner).
• Cài đặt cục bộ: remote-agent seal root <key> được ghi trực tiếp vào thư mục gốc; remote-agent seal forget-root bị xóa và TOFU được lặp lại vào lần tiếp theo Exchange được kết nối (khởi động lại agent sẽ có hiệu lực).

Risk: Nếu Exchange đã bị xâm phạm trong kết nối đầu tiên của thiết bị, TOFU sẽ cho phép nó cung cấp root giả. Nếu đây là vấn đề đáng lo ngại, hãy ghim khóa chung gốc bằng remote-agent seal root <key> trước khi đưa thiết bị lên mạng (xem remote-cli seal root để biết dấu vân tay của thiết bị). Sau khi được ghim, Exchange không thể thay thế root đó.

Thu hồi: Root remote-cli seal policy <设备> --revoke <key> hoặc trên thiết bị remote-agent seal revoke <key>. Bản thân root không thể bị thu hồi. Việc ủy ​​quyền đi kèm với thời hạn hiệu lực (90 ngày theo mặc định). Việc xóa một khoản trợ cấp đã xuất bản khỏi Exchange đơn giản là không còn phân phối nó nữa; bản sao đã được nhập cục bộ vẫn có hiệu lực cho đến khi hết hạn và phải được chính sách thiết bị thu hồi.

Exchange như một chuyển tiếp cấp không đáng tin cậy

Các đồng nghiệp không còn phải sao chép mã thông báo rsg1. hoặc khóa chung vào cửa sổ trò chuyện: Exchange cung cấp Operator Public Key Directory và grant rơle ở cấp độ không gian làm việc. Điều này không thay đổi mô hình mối đe dọa - Exchange vẫn không thể nhìn thấy văn bản rõ ràng và không thể cấp, gia hạn hoặc giả mạo ủy quyền. Nó chỉ lưu:

1. Nhà điều hành sử dụng khóa riêng cục bộ để chứng minh khóa chung Ed25519 (POST /api/seal/keys) mà anh ta nắm giữ
2. Văn bản gốc của mã thông báo rsg1. đã ký (POST /api/seal/grants)
3. Văn bản gốc của chứng chỉ trung gian rsc1. đã ký (POST /api/seal/certs). Exchange xác minh chữ ký Ed25519 của nhà phát hành nhưng không thể giả mạo chứng chỉ. GET /api/seal/certs/chain?subject_key= Truy xuất mã thông báo dọc theo mối quan hệ phát hành (bị giới hạn bởi cùng 64 mã thông báo / 64 lan can KiB), được phát hành gốc trước

Ủy quyền thiết bị vẫn chỉ nhận dạng root cố định hoặc chuỗi chứng chỉ rsc1. có thể xác minh root. Exchange chỉ phân tích mã thông báo để xây dựng chỉ mục theo owner_key / operator_key / thời gian hết hạn và không bao giờ coi việc tải lên là ủy quyền. Trường hợp xấu nhất là nhà điều hành giữ lại mã thông báo (bên kia không thể nhận được khoản trợ cấp, xuất hiện dưới dạng no grant) và không thể thay đổi view thành manage, cũng như không thể giả vờ là root.

Bất kỳ thành viên không gian làm việc nào cũng có thể tải lên một khoản trợ cấp: mã thông báo có chữ ký riêng và việc tải lên không phải là hành động ủy quyền; chỉ các khoản trợ cấp có chữ ký gốc mới hợp lệ cho thiết bị. CLI mặc định là --publish khi đăng nhập; bảng điều khiển Web/Android sử dụng cùng giao diện khi "ký và xuất bản".

Bằng chứng sở hữu ràng buộc để đăng ký chìa khóa:

remote-seal-key-register:v1:<workspace_id>:<operator_id>:<public_key>:<issued_at_ms>

Bằng chứng là chữ ký Ed25519 được tạo bằng khóa riêng tương ứng với khóa chung này; issued_at_ms phải cách thời gian của máy chủ trong khoảng ±10 phút. CLI thử đăng ký trên login và seal show; bảng điều khiển đăng ký sau khi đăng nhập.

Nếu không có khoản trợ cấp phù hợp tại địa phương trước hoạt động niêm phong, nhà điều hành sẽ cố gắng hết sức để seal sync; khi quá trình bắt tay bị từ chối do no grant, nó sẽ đồng bộ hóa lại và thử lại.

Khi khách hàng của tổ chức phát hành trực tuyến, nó sẽ tự động gia hạn ủy quyền đã cấp mà nó đã cấp và sắp hết hạn. Chữ ký vẫn được hoàn thành cục bộ; Exchange chỉ lưu mã thông báo rsg1. mới và xóa bản ghi cũ và không thể thay đổi cấp độ hoặc thay đổi người được ủy quyền.

• Thời điểm chạy: CLI sau khi đăng nhập thành công và khi bất kỳ lệnh đăng nhập nào bắt đầu (seal renew thực hiện theo lộ trình thủ công và không áp dụng lớp gia hạn tự động). Web Console cũng sẽ vào không gian làm việc khi đăng nhập và vào không gian làm việc (nếu phiên đã tồn tại sau khi tải trang). Android Console sau khi đăng nhập và khi ứng dụng quay lại nền trước. Nếu bạn chưa đăng nhập hoặc nếu khóa công khai này không được công bố thì nó sẽ không được gia hạn.
• Quy tắc gia hạn: GET /api/seal/grants?owner_key=<本机公钥>. Các khoản tài trợ hết hạn trong vòng 30 ngày sẽ được cấp lại với device_id, operator_key và level ban đầu trong 90 ngày. Sau khi phát hành thành công, khoản trợ cấp cũ sẽ là DELETE. Nếu GET /api/seal/keys thành công, operator_key không còn trong thư mục khóa chung sẽ bị bỏ qua; nếu yêu cầu thư mục không thành công, nó sẽ không được lọc theo thư mục.
• Throttling: Web/Android: Khóa công khai phát hành tương tự sẽ được thử tối đa 12 giờ một lần. CLI được ghi trong thư mục cấu hình dưới dạng seal-renew-state.json, Web Console sử dụng localStorage và Android Console sử dụng SecureStore. Lỗi không ảnh hưởng đến hoạt động hiện tại: CLI chỉ in dòng cảnh báo trên stderr và bảng điều khiển sử dụng console.warn. Khi gia hạn thành công, CLI sẽ in phần giải thích ngắn gọn về stderr. Web Console giữ quyền root sẽ phát hành một vòng đầu tiên khi vào không gian làm việc và Android cũng sẽ phát hành một vòng đầu tiên khi bật "mã hóa đầu cuối"; hai thời điểm này không bị điều tiết 12 giờ. Chỉ những lần làm mới sau cùng thời gian lưu trú sẽ bị hạn chế.
• Gia hạn CLI: Ghi nhận thành công theo từng máy chủ và khóa phát hành. Bỏ qua yêu cầu gia hạn trong 12 giờ sau khi thành công; lỗi hoặc gián đoạn chỉ chờ 5 phút trước khi thử lại. Toàn bộ quá trình có giới hạn 30 giây. Lỗi hiển thị giai đoạn và thời gian đã dùng; lệnh chính thất bại sẽ hủy gia hạn ngay. Việc thu hồi trên thiết bị còn chờ không chịu giới hạn sau thành công và có thời hạn riêng 4 giây. Chạy remote-cli seal renew để gia hạn trực tiếp. Đăng nhập thành công sẽ buộc làm mới một lần.
• Máy khách Root: Máy khách quản trị cấp cao nắm giữ thư mục gốc của không gian làm việc sử dụng cấp phát dựa trên vai trò trong phần tiếp theo để thay thế gia hạn chung này nhằm tránh phải đăng nhập lại ủy quyền mới bị xóa.
• Manual: Vẫn có sẵn remote-cli seal renew (--before 30 --days 90 mặc định), các quy tắc tương tự như tự động gia hạn.

# 按工作区用户名授权对方每一把已登记的钥匙，并发布到 Exchange（默认 90 天）
remote-cli seal grant --device lab-router --to alice --level view
# 只打印 token，不上传
remote-cli seal grant --device lab-router --operator-key <KEY> --no-publish
remote-cli seal keys          # 工作区公钥目录
remote-cli seal sync          # 拉取签给自己钥匙的 grant 并导入本地
remote-cli seal renew         # 手动续签，默认 --before 30 --days 90

Quản trị viên cấp cao của không gian làm việc là gốc rễ của niềm tin

Thư mục gốc của không gian làm việc là khóa Ed25519 trên máy khách superadmin. Thiết bị chỉ tin cậy khóa chung gốc này và có thể xác minh ủy quyền rsg1. của gốc dọc theo chuỗi chứng chỉ rsc1.; máy khách gốc tự động cấp và gia hạn ủy quyền thành viên dựa trên vai trò tài khoản. Exchange vẫn không đáng tin cậy: nó chỉ lưu các bản ghi gốc rsr1. tự ký, bản ghi xoay rsx1. và lời mời rsi1., đồng thời kiểm tra định dạng dựa trên chữ ký Ed25519 mà không quyết định ai được phê duyệt. Exchange độc hại có thể giữ lại các bản ghi hoặc điền vào danh sách các thành viên giả mạo; nó không thể giả mạo chữ ký gốc. Theo mặc định, phê duyệt tự động được bật trong CLI, Web và Android, đồng thời các khóa công khai mới trong danh sách sẽ được các máy khách gốc này ký trực tiếp. Chỉ khi quá trình phê duyệt tự động bị tắt một cách rõ ràng, các khóa công khai mới chưa bao giờ được phê duyệt và chưa được gốc này xuất bản sẽ vẫn nằm trong danh sách đang chờ xử lý.

Mô hình niềm tin và sự đánh đổi

• Khóa chung gốc được cố định trong lần sử dụng đầu tiên (TOFU). Khi khách hàng nhìn thấy bản ghi gốc đã được xác minh lần đầu tiên, nó sẽ sửa khóa chung cục bộ. CLI ghi seal-root.json (0600) bên cạnh config.toml và khóa là 服务器|工作区 id. Web Console sử dụng localStorage (remote.seal.root.<工作区 id>). Android Console sử dụng SecureStore (remote.seal.rootstate, được đặt trong cùng một JSON theo máy chủ và không gian làm việc). Sau đó kiểm tra chữ ký và dấu vân tay mỗi lần. Nếu khóa công khai gốc cố định thay đổi, một cảnh báo lớn sẽ được phát ra.Máy khách sẽ không tự động thay đổi mật khẩu (thiết bị sẽ tự động thay đổi mật khẩu theo bản ghi xoay vòng rsx1., xem ở trên). Sau khi kiểm tra dấu vân tay, hãy thực thi remote-cli seal root --trust <key> một cách rõ ràng hoặc nhấp vào "Tin cậy khóa công khai gốc mới" trong bảng điều khiển.
• Lời mời chỉ mở để đăng ký. Khóa công khai gốc được phát hành rsi1. (id không gian làm việc, khóa chung gốc, nonce 16 byte, thời gian hết hạn). Quản trị viên, nhà điều hành và khách hàng có tài khoản chỉ đọc sẽ nhận được lời mời khi đăng nhập, làm theo lệnh, tải trang hoặc khi ứng dụng quay lại nền trước, xác minh chữ ký bằng khóa chung gốc cố định, sau đó sử dụng POST /api/seal/keys ban đầu để đăng ký khóa chung của nhà điều hành của họ. Lời mời không phải là sự cho phép.
• Phát hành theo vai trò, phê duyệt khóa mới cục bộ. Ứng dụng quản trị viên cấp cao nơi đặt khóa công khai gốc sẽ đọc GET /api/seal/roster (chỉ dành cho quản trị viên cấp cao; bao gồm các thành viên, vai trò bị khuyết tật, operator_device_grants, khóa công khai đã đăng ký) và cấp phép được xuất bản của chính nó, đồng thời tính toán ủy quyền dự kiến. Khóa công khai đã đăng ký giống nhau chia sẻ tập hợp phạm vi này:
  • Quản trị viên cấp cao và quản trị viên không hạn chế: manage *
  • Quản trị viên bị hạn chế: Được ủy quyền bởi thiết bị, can_manage là manage, nếu không thì view
  • Toán tử không hạn chế: view *, cộng với manage cho mỗi thiết bị can_manage
  • Nhà điều hành bị hạn chế: Ủy quyền cho mỗi thiết bị manage hoặc view
  • Chỉ đọc không hạn chế: view *
  • Chỉ đọc bị hạn chế: view trên mỗi thiết bị được ủy quyền. Tài khoản chỉ đọc không thể vận hành thiết bị nên ngay cả can_manage cũng sẽ không được gửi manage
  • Thành viên khuyết tật: không đăng bài
  • Mặc định là 90 ngày, gia hạn nếu còn ít hơn 30 ngày
• ** Chứng chỉ trung gian dành cho quản trị viên.** Máy khách gốc cấp phát rsc1. cho các quản trị viên đã bật (manage, can_issue, max_path_len là 0, 90 ngày). Phạm vi thiết bị của quản trị viên không hạn chế là *; quản trị viên bị hạn chế là thiết bị được gán can_manage. Gia hạn chỉ còn 30 ngày. Sẽ không có chứng chỉ nào được cấp cho các khóa công khai mới chưa được phê duyệt. Khi máy khách quản trị viên giữ chứng chỉ trung gian vẫn còn hiệu lực, nó sẽ sử dụng khóa riêng và chuỗi này để cấp quyền cho các thành viên mà nó quản lý và phạm vi là sự giao thoa giữa chứng chỉ và ủy quyền thiết bị; nếu root đã có cấp phép mới bao gồm cùng một nhà điều hành, thiết bị và cấp độ (* của root bao gồm thiết bị cụ thể, manage bao gồm view), nó sẽ không ký nữa. Việc thu hồi chứng chỉ từ Exchange chỉ dừng việc phân phối thêm; các bản sao đã có trên thiết bị vẫn có hiệu lực cho đến khi hết hạn. Việc thu hồi cứng dựa trên revoked_keys trong chính sách thiết bị.
• Tự động phê duyệt được bật theo mặc định. Trong Web Console (localStorage) và Android Console (SecureStore), khi bản ghi không có trường này, nó được coi là bật (vắng mặt = bật). Chỉ có false rõ ràng vẫn đóng. Những cái đã bị đóng sẽ không được mở lại theo logic mặc định. Sau khi mở, máy khách root ký trực tiếp theo danh sách, weaker: Exchange bị xâm nhập có thể chèn thành viên giả mạo và lấy chữ ký ngay lập tức. Bản sao công tắc là "Tự động phê duyệt khóa công khai mới". CLI mặc định bật giống Web/Android Console: thiếu tệp seal-approved.json hoặc trường auto_approve có nghĩa là bật; giá trị "auto_approve": false được đặt rõ ràng vẫn giữ trạng thái tắt. Chạy remote-cli seal approve --no-auto-approve để tắt hoặc remote-cli seal approve --auto-approve để bật lại; lựa chọn được lưu. Sau khi đóng, các khóa chưa bao giờ được phê duyệt hoặc xuất bản bởi khóa công khai gốc này sẽ vào danh sách chờ xử lý cục bộ (CLI seal-approved.json, Web localStorage, Android SecureStore). remote-cli seal pending hiển thị tên người dùng và dấu vân tay; seal approve --all hoặc seal approve <key>… được cấp ngay sau khi được phê duyệt. Đối với các khóa đã được phê duyệt, cũng như các khóa được cấp bởi khóa công khai gốc này, việc gia hạn và thay đổi vai trò sẽ tự động được hoàn tất. Việc cấp khóa công khai của chính khách hàng không cần phải được phê duyệt lại.
• Sign ngay khi bạn mở nó. Máy khách gốc được ký ngay lập tức khi Web Console đi vào không gian làm việc và Android bật "Mã hóa đầu cuối". Vòng này không bị hạn chế 12 giờ. Tự động làm mới sau cùng thời gian lưu trú vẫn được điều chỉnh. Việc thay đổi nút chuyển hoặc nhấp vào "Phê duyệt" sẽ buộc bạn phải đăng nhập lại.
• Hộp thoại Atài khoản, huy hiệu và dòng lỗi. Công tắc Web Console và danh sách đang chờ xử lý nằm trong hộp thoại "Tài khoản" trên trang thiết bị ("Tài khoản" trên thanh công cụ). Khi có khóa đang chờ phê duyệt, biểu tượng "N khóa công khai đang chờ phê duyệt" sẽ hiển thị trên cùng một thanh công cụ. Nhấp vào huy hiệu để mở hộp thoại này. Khi ký không thành công, trên thanh công cụ có dòng trạng thái: "Việc ký gốc Workspace không thành công:...". Mã thông báo niêm phong và vật liệu khóa dài sẽ bị xóa khỏi dòng này. Công tắc Android, huy hiệu cùng câu và hướng dẫn lỗi cùng dòng có trên trang Mã hóa đầu cuối.
• Downgrade không thu hồi các ủy quyền cũ trên thiết bị. Khi một thành viên bị xóa, bị vô hiệu hóa hoặc khóa chung biến mất khỏi thư mục: xóa quyền cấp phép khỏi Exchange, ngừng gia hạn và thử ghi revoked_keys trên thiết bị trực tuyến và hỗ trợ các phiên kín. Khi vai trò bị hạ cấp, chỉ một khoản trợ cấp mới sẽ được trao đổi và khóa sẽ không được đưa vào revoked_keys. Các khoản trợ cấp cũ đã được nhập vào thiết bị vẫn còn hiệu lực trước khi hết hạn. Bản thân khóa công khai gốc không bao giờ được đưa vào danh sách thu hồi. Việc thu hồi không được hoàn thành trong ngân sách 4 giây sẽ được ghi lại cục bộ và sẽ được tiếp tục bằng lệnh tiếp theo mà không phải tuân theo giới hạn điều chỉnh phát hành trong 12 giờ. Khi khóa trở thành ủy quyền mong muốn một lần nữa, việc thu hồi sẽ chỉ bị thu hồi trên thiết bị đã được thu hồi thành công.
• Bản ghi Root được tạo tự động. Khi tài khoản quản trị viên cấp cao được tạo (register/tài khoản đầu tiên trong không gian làm việc) hoặc bất kỳ thông tin đăng nhập quản trị viên cấp cao nào tiếp theo, nếu không có bản ghi gốc trên Exchange, ứng dụng khách của quản trị viên cấp cao (CLI / Web / Android) sẽ xuất bản khóa riêng của nó làm gốc cục bộ và ngay lập tức gửi lời mời 90 ngày. Sau đó, khi lời mời bị thiếu hoặc sẽ hết hạn trong vòng 30 ngày, nó sẽ được làm mới bằng cách hạn chế phát hành. remote-cli seal root --publish vẫn có thể được thực thi thủ công.

Cài đặt một lần

1. Quản trị viên cấp cao đăng ký hoặc đăng nhập vào bất kỳ máy khách nào: thư mục gốc được tạo và thông báo tự động (CLI in lời nhắc trên stderr; bảng điều khiển bật lên lời nhắc).
2. Giữ khóa riêng gốc (chọn một hoặc cả hai):
   • Chỉ cần giữ nó cho riêng mình và không tải lên gì: remote-cli seal root --export root.rsk (tệp 0600; - được xuất ra thiết bị xuất chuẩn) hoặc "Xuất khóa riêng gốc" trong bảng điều khiển.
   • Cài đặt sao lưu đám mây thủ công: remote-cli seal backup hoặc bảng điều khiển "Root Private Key Cloud Backup". Mật khẩu có thể để trống, nhưng nếu mật khẩu trống hoặc quá yếu, Exchange có thể mở khóa khóa riêng gốc và chiếm quyền kiểm soát tất cả các thiết bị.
3. Chỉ cần thiết bị hỗ trợ phiên kín và được kết nối với Exchange, nó sẽ tự động sửa root (TOFU); một cách tiếp cận đáng tin cậy hơn là đặt remote-agent seal root <根公钥> trên thiết bị trước khi trực tuyến.
4. Các thành viên mới sẽ đăng ký khóa chung của họ sau khi đăng nhập. Phê duyệt tự động được bật theo mặc định trong CLI, Web và Android và máy khách gốc sẽ ký trực tiếp. Nếu tắt phê duyệt tự động: remote-cli seal pending View, remote-cli seal approve --all (hoặc bảng điều khiển "Phê duyệt") sẽ phát hành ngay sau khi phê duyệt.

remote-cli seal root                       # 显示已固定的根公钥和指纹
remote-cli seal root --export root.rsk     # 导出根私钥（rsk1. 文本）
remote-cli seal root --import root.rsk     # 在另一台机器装上根私钥（或 seal restore）
remote-cli seal root --rotate              # 生成新根，旧根签 rsx1. 轮换，自动按新根重签成员授权
remote-cli seal invite                     # 单独刷新邀请（默认 90 天，--days N）
remote-cli seal pending
remote-cli seal approve --all              # 或 seal approve <key>…；--no-auto-approve 关闭自动批准（保持开启较弱）

Đổi máy khác/đổi root

• Sử dụng root trên các thiết bị khác: Sau khi quản trị viên cấp cao đăng nhập, nếu máy không có root đã được công bố và có bản sao lưu đám mây rsb1. trên Exchange, CLI / Web / Android sẽ tự động thử khôi phục (xem phần "Tự động khôi phục khi đăng nhập"). Nếu không, máy khách sẽ nhắc nhập thủ công: seal root --import <文件|->, dán rsk1. vào bảng điều khiển rồi "Nhập khóa riêng gốc" hoặc khôi phục bản sao lưu được mã hóa từ Exchange (seal restore / bảng điều khiển "Khôi phục từ Exchange"). Những gì được nhập là root hiện tại và chỉ được cài đặt trên máy cục bộ mà không thay đổi bất kỳ bản ghi nào.
• Rotation: seal root --rotate (Console "Tạo gốc mới và xoay") hoặc nhập khóa rsk1. khác với gốc hiện tại. Khi máy cục bộ giữ root hiện tại, máy khách sử dụng root cũ để ký bản ghi xoay rsx1., cùng với rsr1. PUT /api/seal/root mới; Exchange đẩy nó đến thiết bị trực tuyến và thiết bị xác minh rằng vòng quay được ký bởi gốc cố định rồi thay đổi sang gốc mới và thiết bị ngoại tuyến sẽ nhận được nó vào lần kết nối tiếp theo. Các thành viên được root cũ phê duyệt sẽ tiếp tục được coi là đã được phê duyệt trên máy này và sau đó tất cả ủy quyền của thành viên sẽ được ký lại với root mới (90 ngày). Khóa cục bộ cũ vẫn là seal-identity.<毫秒>.previous.pk8. Vui lòng xuất lại hoặc sao lưu root mới sau khi xoay.
• Z Root cũ đã bị mất: Không thể ký bản ghi xoay vòng. Khách hàng vẫn sẽ quảng cáo root mới, nhưng các thiết bị đã ghim root cũ sẽ không chấp nhận; remote-agent seal root <新根公钥> cần được thực thi trên mỗi thiết bị và agent được khởi động lại.
• Chuyển giao quản trị viên cấp cao: Xem "Chuyển giao quản trị viên cấp cao = Chuyển giao chứng chỉ gốc". Chỉ thay đổi vai trò tài khoản là chưa đủ, thiết bị tin tưởng vào khóa riêng gốc.

Tự động khôi phục khóa riêng gốc khi đăng nhập

Sau khi quản trị viên cấp cao đăng nhập thành công, ** trước khi tạo danh tính kín cục bộ**, CLI / Web Console / Android Console sử dụng cùng một bảng quyết định thuần túy (Rust decide_auto_restore, JS decideAutoRestore) để thử khôi phục gốc không gian làm việc đã xuất bản từ bản sao lưu Exchange rsb1.:

1.Skip: Không phải là quản trị viên cấp cao; máy đã giữ cùng khóa với root đã xuất bản; sao lưu đám mây bị tắt (CLI: REMOTE_SEAL_CLOUD_BACKUP=0; Web: localStorage.seal.cloudBackup=off; Android: SecureStore remote.seal.cloudBackup=off); không có root nào được công bố trên Exchange. 2.Kéo bản sao lưu: GET /api/seal/backup (giới hạn bởi số lần mỗi giờ). Khi không có bản sao lưu, nó sẽ nhắc rằng root ở nơi khác và không chặn đăng nhập. 3.Thử im lặng với mật khẩu trống: Giải mã bằng chuỗi trống trước tiên. Khi thành công và khóa chung được giải mã bằng với gốc đã xuất bản và máy không có khóa khác khác, nó sẽ được tải vào máy và cố định là gốc của không gian làm việc. 4. Nếu không, mật khẩu sẽ được nhắc: CLI thử lại REMOTE_SEAL_BACKUP_PASSPHRASE, đầu vào bị ẩn trên TTY; Web/Android chỉ gửi lời nhắc non-blocking, vui lòng nhập mật khẩu trên trang con dấu và nhấp vào "Khôi phục từ Exchange". Hộp thoại chặn không hiện lên và việc đăng nhập hoàn tất như bình thường. 5.Ranh giới bảo mật: Không bao giờ âm thầm ghi đè lên một khóa kín khác đã tồn tại trên máy này (việc khôi phục yêu cầu seal restore --force hoặc bảng điều khiển để xác nhận); khóa công khai được giải mã phải bằng khóa gốc đã được công bố; chỉ có cảnh báo sẽ được đưa ra khi thất bại và sẽ không xảy ra lỗi đăng nhập; mật khẩu, hạt giống hoặc bản mã rsb1. sẽ không bao giờ được in. 6.Cảnh báo rủi ro (không chặn): Sau khi cài đặt root, nó sẽ nhắc "Nhiều máy giữ root sẽ tăng nguy cơ rò rỉ"; nếu mật khẩu trống được mở khóa thành công, nó sẽ nhắc Exchange có thể mở khóa khóa riêng gốc.

Chuyển giao quản trị viên cấp cao = chuyển giao khóa gốc

Vai trò của tài khoản quản trị viên cấp cao và thư mục gốc của không gian làm việc được các thiết bị tin cậy là riêng biệt. Chỉ chuyển vai trò không cung cấp cho quản trị viên cấp cao mới khóa riêng gốc hoặc độ tin cậy của thiết bị. Chuyển giao chuyển khóa riêng root, ngay sau đó bằng cách xoay để vô hiệu hóa khóa được chuyển.

1. Quản trị viên cấp cao hiện tại bắt đầu chuyển trong khi máy khách cục bộ giữ gốc đã xuất bản: POST /api/superadmin/transfer, với nội dung {operator_id, root_handover?}. root_handover là gói rsb1. được mã hóa cụm mật khẩu bằng thuật toán sao lưu đám mây (Argon2id, 64 MiB, t=3, p=1 và ChaCha20-Poly1305). Cụm mật khẩu có thể trống. CLI: remote-cli seal handover <账号>. Khi chuyển vai trò quản trị viên cấp cao trong Web/Android Console, máy khách giữ khóa riêng gốc sẽ nhắc nhập cụm mật khẩu tùy chọn và bao gồm gói này.
2. Exchange chỉ lưu, không giải mã. Nó kiểm tra xem tiền tố là rsb1. hay rsk1., không dài hơn 16384 và chỉ chứa các ký tự an toàn cho URL ASCII. Khi không có root_handover trong yêu cầu, hãy xóa gói chuyển giao còn lại của không gian làm việc.
3. Siêu quản trị viên mới GET /api/superadmin/handover truy xuất {blob, from_operator, created_at} (nếu không, 404), mở khóa bằng mật khẩu, cài đặt nó vào máy cục bộ, sau đó thực hiện thao tác xoay vòng tương tự như "tạo gốc mới và xoay": gốc cũ phát hành rsx1. và xuất bản gốc mới. Cuối cùng là DELETE /api/superadmin/handover. CLI: remote-cli seal accept-handover. Trang seal của console hiển thị "Nhận chuyển giao khóa riêng gốc" khi có gói chuyển giao.
4. Rotation làm cho các bản sao cũ không hợp lệ. Những gì được bàn giao là root trước khi xoay. Các thiết bị trực tuyến chỉ chuyển sang root mới nếu bản ghi luân chuyển được ký bởi root cũ mà chúng đã tin tưởng. Khóa riêng cũ trong tay người tiền nhiệm không thể ký ủy quyền cho root mới, cũng như không thể thay đổi root của thiết bị đã được chuyển đổi. Trước khi hoàn tất quá trình quay, mật khẩu trống hoặc mật khẩu yếu rsb1. vẫn có thể được mở khóa; vui lòng chuyển mật khẩu riêng.

Out-of-band: Khi bạn không muốn đưa văn bản mã hóa vào Exchange, hãy sử dụng remote-cli seal handover <账号> --out-of-band cho CLI. Đầu ra tiêu chuẩn chỉ có một dòng rsb1. và yêu cầu truyền không có root_handover. Đưa dòng này và mật khẩu cho bên kia thông qua các kênh khác, bên kia sẽ thực thi remote-cli seal accept-handover <那一行>. Nhấp vào Hủy trên lời nhắc mật khẩu trong bảng điều khiển (Android chỉ chuyển tài khoản). Nó cũng chỉ chuyển vai trò và không tải lên khóa riêng gốc; khóa riêng gốc vẫn cần được bàn giao riêng (xuất rsk1. hoặc rsb1. ngoài băng tần).

Định dạng bắt tay và dòng

CLI                         Exchange                       agent
 │ open_sealed{session_id,    │                               │
 │   device_id, hello}        │──sealed_open{session_id,hello}▶│ 验证 hello 签名、授权 → 级别
 │                            │◀─sealed_accept{session_id,     │
 │◀─sealed_accept (原样转发) ──│        accept}                │
 │ 验证设备签名 + pin          │                               │
 │ sealed_input{packet} ─────▶│──sealed_input────────────────▶│ 解密、校验级别、执行
 │ 二进制帧 kind=4 (PTY 键入)─▶│── 只改写帧头编号 ─────────────▶│
 │◀── sealed_event{packet,last}│◀── sealed_event ──────────────│ 所有输出在出站队列加密
 │◀── 二进制帧 kind=4 ─────────│◀── 二进制帧 kind=4 ───────────│

• hello = {v, operator_key, operator_ephemeral, nonce, grant?, sig}, chữ ký bao gồm ["remote-seal-v1/hello", v, device_id, operator_key, operator_ephemeral, nonce, grant.sig|""] (mảng JSON, tức là byte chuẩn).
• Bản ghi gốc chữ ký rsr1. bao gồm ["remote-seal-v1/workspace-root", v, workspace_id, root_key, issued_at_ms]; vòng quay rsx1. = {v, workspace_id, old_root, new_root, issued_at_ms, sig}, được ký bởi old_root trên ["remote-seal-v1/root-rotation", v, workspace_id, old_root, new_root, issued_at_ms]. Exchange → agent: {"type":"seal_root","token":"rsr1.…","rotation":"rsx1.…"?} (chỉ chấp nhận tin nhắn điều khiển văn bản rõ ràng từ Exchange, không hợp lệ trong đường hầm).
• accept = {v, device_key, device_ephemeral, nonce, level, sig}, chữ ký bao gồm ["remote-seal-v1/accept", v, device_id, operator_key, operator_ephemeral, hello.nonce, hello.sig, device_key, device_ephemeral, nonce, level]. Exchange thay đổi thành level sẽ làm mất hiệu lực chữ ký.
• Khóa phiên: salt = SHA256(accept 签名字节), PRK = HKDF-Extract(salt, X25519(o, b)), K_od = Expand("remote-seal-v1/operator_to_device"), K_do = Expand("remote-seal-v1/device_to_operator").
• AEAD: ChaCha20-Poly1305, AAD = remote-seal-v1, nonce = byte kênh (0 văn bản / 1 nhị phân) ‖ ba byte 0 ‖ Bộ đếm u64 (cuối lớn). Bộ đếm theo mỗi hướng và mỗi kênh được tăng nghiêm ngặt thêm một từ 0; bất kỳ sự khác biệt nào sẽ trực tiếp đóng phiên.
• Văn bản: {"counter":n,"ciphertext":"<base64>"}. Văn bản rõ ràng là JSON: toán tử → thiết bị là SealedRequest (thông báo DeviceDown hiện có hoặc thông báo quản lý gốc seal_policy_get / seal_policy_set {mode?, root_key?, revoke?, unrevoke?}); thiết bị → nhà điều hành là SealedResponse (tin nhắn DeviceUp hiện có hoặc seal_policy). Lớp bên trong session_id được agent viết lại thành số đường hầm.
• Khung nhị phân: StreamKind::Sealed = 4, tải trọng = counter(u64 BE) ‖ AEAD(inner_kind ‖ bytes), inner_kind là 1/2/3 (stdout/stderr/PTY).
• Mỗi phiên kín thực hiện thao tác one (một thực thi, một PTY, một truyền tệp...), theo mô hình phiên 1:1. Thông báo chấm dứt được mã hóa bởi agent và được đánh dấu last:true ở lớp ngoài. Exchange phát hành kiểm tra định tuyến và chèn lấp phù hợp mà không cần phải hiểu nội dung.
• close_session → sealed_close{detach:false} (chấm dứt); ngắt kết nối vận hành và bảo trì → sealed_close{detach:true} (được agent đánh giá: chỉ giữ lệnh thực hiện tách ra, chấm dứt khác).
• Kích thước tối đa: khoảng 2,8 MiB cho bản mã base64 (chứa được 2 ảnh chụp màn hình MiB Android), bao bì bên ngoài MAX_SEALED_WIRE.

Đường bảo vệ phía Agent: Bản rõ thuộc số phiên được niêm phong trong hàng đợi gửi đi sẽ chỉ được mã hóa hoặc loại bỏ và số này sẽ bị cô lập vĩnh viễn sau khi phiên kết thúc (đầu ra muộn của quá trình giữ sẽ bị loại bỏ thay vì được gửi ở dạng bản rõ); công việc giữ bắt đầu/được đính kèm thông qua phiên kín không xuất hiện trong danh sách đường dẫn cũ và cũng không thể được đính kèm/đuôi/mèo/bị giết bởi đường dẫn cũ.

Xuất và sao lưu khóa riêng gốc

Khóa riêng gốc có thể kiểm soát tất cả các thiết bị trong không gian làm việc. Phương thức lưu trữ do quản trị viên cấp cao xác định, Console tải lên bản sao lưu cụm mật khẩu trống theo mặc định; xóa nó để tắt tính năng lưu tự động:

• Export (không tải lên): rsk1. + base64url (không có phần đệm) hạt giống 32 byte. CLI seal root --export FILE|- (tệp 0600), bảng điều khiển "Xuất khóa riêng gốc" (Web được hiển thị trong hộp nhập, Android được sao chép vào bảng tạm). Bất cứ ai có được nó đều có thể điều khiển toàn bộ thiết bị.
• ESao lưu được mã hóa vào Exchange (tự động trong Console, thủ công trong CLI): Chỉ quản trị viên cấp cao mới có thể tải lên nếu khóa cục bộ là gốc đã xuất bản. Văn bản mã hóa là mã thông báo rsb1. được phiên bản (JSON được mã hóa base64url, tối đa 4096 ký tự). Khóa được Argon2id lấy từ mật khẩu và các tham số sản xuất được cố định ở 64 MiB của bộ nhớ, lần lặp 3 và tính song song 1, được ghi bằng mã thông báo. Salt là 16 byte, nonce của ChaCha20-Poly1305 là 12 byte và được tạo ngẫu nhiên cho mỗi bản sao lưu. Dữ liệu xác thực bổ sung là remote-seal-v1/key-backup:{version}:{public_key}. Nếu phiên bản, khóa công khai hoặc bản mã bị thay đổi, quá trình xác minh sẽ không thành công; sau khi mở khóa phải kiểm tra xem khóa chung được lấy từ hạt giống có bằng khóa chung trong mã thông báo hay không. Bộ giải mã từ chối các tham số quá yếu hoặc quá lớn trước khi chạy Argon2 (bộ nhớ 8 KiB–256 MiB, giải mã sản xuất ít nhất 64 MiB; số lần lặp 1–8, sản xuất ít nhất 3; độ song song chỉ có thể là 1).
• Mật khẩu là tùy chọn, độ mạnh không bắt buộc. Mật khẩu trống cũng sử dụng Argon2id (mật khẩu là một chuỗi trống) và định dạng giống nhau. Máy khách chỉ nhắc: Khi mật khẩu trống hoặc yếu (dưới 12 ký tự, quá ít danh mục ký tự, lặp lại, mật khẩu phổ biến), CLI / Web / Android sẽ cảnh báo rõ ràng: Exchange (hoặc ai đó có thể đọc cơ sở dữ liệu) có thể mở khóa khóa riêng gốc và kiểm soát tất cả các thiết bị. Rust và sử dụng JavaScript cùng một bộ quy tắc nhắc và cùng một bộ vectơ kiểm tra (bao gồm cả vectơ mật khẩu trống).

PUT / GET / DELETE /api/seal/backup chỉ phục vụ tài khoản đăng nhập hiện tại; PUT và GET chỉ cho phép quản trị viên cấp cao. Nội dung yêu cầu là {blob}. Exchange kiểm tra tiền tố và độ dài rsb1. và không bao giờ giải mã nó. GET Mỗi tài khoản, mỗi quy trình, tối đa 5 lần mỗi giờ, nếu vượt quá, sẽ trả về 429; điều này chỉ làm chậm quá trình đoán trực tuyến và mật khẩu yếu có thể bị sử dụng ngoại tuyến sau khi sao chép thư viện. Việc đọc, viết và xóa sẽ được kiểm tra và chi tiết chỉ là số byte.

• CLI: remote-cli seal backup (ẩn nhập mật khẩu hai lần, bạn có thể nhập trực tiếp và để trống; hoặc --passphrase-stdin); remote-cli seal restore (thêm --force khi có key khác và giữ key cũ là seal-identity.<毫秒>.previous.pk8). Sau khi khôi phục, hãy sửa nó thành root không gian làm việc của máy. Việc khôi phục cũng được tự động thử khi đăng nhập (xem phần trước). Không in khóa riêng, mật khẩu hoặc văn bản mã hóa.
• Web Console: Khóa riêng gốc phải có khả năng xuất được. Khi quản trị viên cấp cao tạo root, trình duyệt chứa khóa WebCrypto không thể xuất thay vào đó sẽ sử dụng hạt giống cục bộ trong IndexedDB làm gốc. Đăng nhập bootstrap tự động tiếp tục trước khi tạo danh tính; localStorage.seal.cloudBackup=off có thể được tắt.
• Android Console: Hạt giống nằm trong kho bảo mật triển lãm. bootstrapSeal cũng tự động khôi phục trước; remote.seal.cloudBackup=off có thể được tắt.

sử dụng

remote-cli seal show                       # 生成/显示本机操作员公钥与指纹
remote-cli exec lab-router -- uname -a
remote-cli shell lab-router
remote-cli seal policy lab-router          # 根：查看设备授权与吊销策略

# 根给同事手动授权（通常不需要：根客户端按角色自动签发）（默认 90 天；对方已登录的客户端会自动登记公钥）
remote-cli seal grant --device lab-router --to alice --level view
# 或仍用公钥；--no-publish 只打印 token
remote-cli seal grant --device lab-router --operator-key <KEY> --level view --no-publish
# 手动续签即将到期的已发布授权（默认 --before 30 --days 90；上线时也会自动续签）
remote-cli seal renew
# 同事：拉取 Exchange 上签给自己的授权（登录后也会自动 sync）
remote-cli seal sync
# 仍可手动导入
remote-cli seal import-grant rsg1.xxxxx

# 根私钥：导出（不上传）或可选的加密云端备份
remote-cli seal root --export root.rsk
remote-cli seal backup
remote-cli seal restore                    # 已有不同钥匙时加 --force

# 带外固定设备指纹（在设备上 `remote-agent seal show`）
remote-cli seal trust-device lab-router <DEVICE_KEY>

Web Console / Android Console: Tất cả các hoạt động của thiết bị đều sử dụng phiên kín gốc: lệnh, giữ Danh sách/kill/tail/cat, thiết bị đầu cuối, tệp, ảnh chụp màn hình và đầu vào (Android/máy tính để bàn), cây giao diện, cảm biến, ubus, nhật ký hệ thống và tự cập nhật tất cả đi qua đường hầm kín; "🔒 Mã hóa đầu cuối" được hiển thị trên trang. Chi tiết thiết bị web hoặc Cài đặt Android → Bảng "Mã hóa đầu cuối" tương đương với CLI: hiển thị khóa chung/vân tay cục bộ, gốc không gian làm việc (quản trị viên cấp cao: xuất/nhập/xoay khóa riêng gốc, nhận chuyển giao khóa riêng gốc, phê duyệt khóa chung mới), xem/sửa đổi khóa thiết bị và chính sách thu hồi (yêu cầu root), cấp quyền (đầu ra mã thông báo rsg1., CLI có thể trực tiếp seal import-grant), nhập ủy quyền, khóa chung của thiết bị đáng tin cậy và sao lưu đám mây tự động của khóa riêng gốc (mật khẩu có thể trống và Exchange được cảnh báo rõ ràng nếu mật khẩu yếu và có thể được mở khóa). Khi kết nối với dấu vân tay của thiết bị cố định (TOFU) lần đầu tiên, những thay đổi về dấu vân tay tiếp theo sẽ bị từ chối trực tiếp và được nhắc xác minh. Các thành viên thông thường có ba khóa khác nhau trên CLI, trình duyệt và điện thoại di động. Sau mỗi lần đăng ký, máy khách gốc sẽ cấp chúng theo vai trò của chúng. Nếu quản trị viên cấp cao muốn root trên nhiều thiết bị, họ có thể tải lên bản sao lưu mật khẩu và tự động khôi phục nó khi đăng nhập vào thiết bị mới hoặc nhập khóa riêng gốc vào từng thiết bị.

Trên thiết bị: remote-agent seal show | root <key> | forget-root | revoke <key> (khởi động lại agent sau các thay đổi cục bộ; các thay đổi thông qua các phiên seal policy kín sẽ được áp dụng ngay lập tức).

Hành vi mặc định

• Một thiết bị mới ghim gốc không gian làm việc khi kết nối với Exchange (TOFU); gốc và các khoản cấp phép đã ký của nó cho phép hoạt động. Nếu Exchange có thể không đáng tin cậy trong kết nối đầu tiên, hãy chạy remote-agent seal root <key> cục bộ trước khi đưa thiết bị trực tuyến.
• Khóa nhận dạng không có sẵn hoặc chính sách bị hỏng không đóng được. Sửa chữa khóa và chính sách cục bộ trước khi kết nối lại.