เซสชันที่ปิดผนึกจากต้นทางถึงปลายทาง (เซสชันที่ปิดผนึก)

Android Console เปิดการเข้ารหัสจากต้นทางถึงปลายทางจากการตั้งค่า พร้อมด้วยการเลือกอุปกรณ์ภายในหน้า การตั้งค่าบัญชี Android และ Web Console รองรับการตั้งค่าหรือการเปลี่ยนรหัสผ่าน และการผูกหรือเปลี่ยนอีเมล อีเมลที่มีอยู่ยังคงใช้งานได้จนกว่าที่อยู่ใหม่จะได้รับการยืนยัน Console สำรองข้อมูลคีย์ส่วนตัว root ไปที่ Exchange ด้วยข้อความรหัสผ่านว่างตามค่าเริ่มต้น โดยคงการสำรองข้อมูลข้อความรหัสผ่านที่มีอยู่ การลบข้อมูลสำรองจะปิดใช้การบันทึกอัตโนมัติบนไคลเอนต์นั้น ข้อความรหัสผ่านที่ว่างเปล่าช่วยให้ Exchange หรือผู้ถือฐานข้อมูลสามารถถอดรหัสรูทได้ การกู้คืนด้วยตนเองจะตรวจสอบรากของพื้นที่ทำงานก่อนที่จะคงอยู่และซิงโครไนซ์เงินช่วยเหลือ

เป้าหมาย: แม้ว่าโฮสต์ Exchange จะถูกบุกรุกหรือผู้ปฏิบัติงานสงสัย แต่ ** ไม่สามารถอ่านคำสั่ง , เอาต์พุต, ไบต์ PTY, เนื้อหาไฟล์, ภาพหน้าจอ หรือข้อมูล ubus และ ** ไม่สามารถตัดสินใจหรือปลอมแปลง ว่าใครอาจดูหรือจัดการอุปกรณ์ได้ Exchange ทำหน้าที่เป็นรีเลย์สำหรับไซเฟอร์เท็กซ์และข้อมูลเมตาการกำหนดเส้นทางเท่านั้น

คำจำกัดความ: crates/proto/src/seal.rs (ประเภทสาย, กฎการอนุญาตในพื้นที่), crates/proto/src/seal/crypto.rs (การเข้ารหัสเซสชัน, แหวนเท่านั้น), crates/proto/src/seal/backup.rs (สำรองรหัสผ่าน: Argon2id + ChaCha20-Poly1305, ไม่ได้เชื่อมโยงกับ agent), crates/agent/src/seal.rs (ฝั่งอุปกรณ์), crates/cli/src/seal.rs (CLI ด้านข้าง), shared/seal-session.js (การใช้งานเซสชันที่แชร์โดย Web Console และ Android Console, @noble/curves · @noble/hashes · @noble/ciphers), shared/seal-backup.js (บนชุดเดียวกันของไลบรารีการสำรองข้อมูลรหัสผ่าน Argon2id) เวกเตอร์ทดสอบข้ามภาษา: shared/seal-vectors.json (สร้าง JS, Rust javascript_vectors_interoperate ตรวจสอบลายเซ็น/HKDF/ไซเฟอร์เท็กซ์ไบต์ที่สอดคล้องกันทีละไบต์), shared/seal-rust-vectors.json (การตอบสนองของอุปกรณ์ Rust, JS shared/seal-session.test.js จับมือและถอดรหัสเสร็จสมบูรณ์)

seal approve ยังคงเผยแพร่สิทธิ์โดยอัตโนมัติ การเรียก seal grant --publish ภายหลัง (หรือการเผยแพร่ตามค่าเริ่มต้นเมื่อเข้าสู่ระบบแล้ว) จะข้ามสิทธิ์ที่เผยแพร่แล้วและยังไม่หมดอายุ หากคีย์ผู้ออก คีย์ผู้รับ อุปกรณ์ และระดับสิทธิ์ตรงกัน โดยแจ้งว่าเผยแพร่แล้วและไม่สร้างโทเค็นใหม่ ใช้ --renew-before DAYS เพื่อต่ออายุสิทธิ์ที่ใกล้หมดอายุ ส่วน --no-publish ยังคงลงนามโทเค็นออฟไลน์ การตรวจสอบนี้ป้องกันรายการซ้ำจากการเรียกซ้ำตามลำดับ แต่ไม่ใช่ธุรกรรมระหว่างไคลเอนต์ที่ทำงานพร้อมกันและไม่ลบรายการซ้ำเดิม seal show จะสร้างตัวตนในเครื่องและลงทะเบียนคีย์เมื่อเข้าสู่ระบบแล้ว ควรใช้โปรไฟล์แยกสำหรับตัวตนทดลอง

โมเดลภัยคุกคาม

อยู่นอกขอบเขตการป้องกัน: อุปกรณ์ที่ถูกบุกรุกหรือคอมพิวเตอร์ของผู้ปฏิบัติงาน หรือ Exchange ปลอมตัวเป็นอุปกรณ์ในการเชื่อมต่อครั้งแรก (TOFU) แล้ว เปรียบเทียบลายนิ้วมือนอกแบนด์เพื่อหลีกเลี่ยงกรณีสุดท้าย การทำงานของอุปกรณ์ทั้งหมดต้องมีเซสชันที่ปิดสนิท ไดเร็กทอรีคำสั่งที่ตั้งไว้ล่วงหน้าและขอบเขตการอนุญาตรูทเชนของเบราว์เซอร์มีอธิบายไว้ด้านล่างนี้

ความครอบคลุมและการออกแบบเส้นทาง

HTTP และคำสั่งที่ตั้งไว้ล่วงหน้า

ขณะนี้การดำเนินการที่ปิดผนึกแบบเนทีฟรองรับผู้เรียก HTTP เท่านั้น ใช้ remote-cli --transport http หรือ REMOTE_TRANSPORT=http POST /api/sealed/connections สร้างกล่องจดหมาย POST /input ส่งการจับมือหรือไซเฟอร์เท็กซ์ที่ลงนามแล้ว ผลการสำรวจความคิดเห็น GET /events และ DELETE ปิดการเชื่อมต่อ ลูกค้ายังคงรักษาการเข้ารหัสแบบ end-to-end และการอนุญาตอุปกรณ์ที่มีอยู่ จุดสิ้นสุดการดำเนินการของอุปกรณ์เดิมยังคงส่งคืน 409 การเชื่อมต่ออุปกรณ์ยังคงไม่เปลี่ยนแปลง

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

การสร้าง การแก้ไข และการแสดงรายการคำสั่งที่ตั้งไว้ล่วงหน้ายังคงเป็นพื้นที่การจัดการฐานข้อมูล Exchange และข้อความเทมเพลต ชื่อ และคำอธิบายในไดเร็กทอรีจะไม่ถูกปิดผนึกข้อมูล และคำสั่งที่ลงนามโดยรายการอนุญาตรูท คอนโซลและ CLI เรียกใช้งานเทมเพลตที่ดึงข้อมูลมาในฐานะผู้บริหารที่ปิดผนึกตามปกติ (ไม่ระงับ) ในขณะที่กดปุ่มค้างไว้ อุปกรณ์เชื่อถือเฉพาะนโยบายดั้งเดิมและการอนุญาตของผู้ปฏิบัติงาน ไม่ใช่รหัสไดเรกทอรี บทบาทของเซิร์ฟเวอร์ หรืออาร์กิวเมนต์ "นี่คือคำสั่งที่กำหนดไว้ล่วงหน้า" สมาชิกที่ถือเฉพาะการให้สิทธิ์ view ไม่สามารถรันคำสั่งที่กำหนดไว้ล่วงหน้าได้ จำเป็นต้องมีการให้สิทธิ์ root manage Grant ไม่สามารถขยายได้หากไดเร็กทอรีถูกดัดแปลง แต่ manage อนุญาตให้ดำเนินการได้ตามต้องการ ดังนั้นโปรดตรวจสอบเทมเพลตและอย่าเขียนรหัสผ่าน/โทเค็นลงในไดเร็กทอรีเซิร์ฟเวอร์ เอาต์พุตจะถูกถอดรหัสและแสดงเฉพาะบนเครื่องเท่านั้น การตรวจสอบรันพาธจะบันทึกเฉพาะเมตาดาต้าที่ปิดผนึกเท่านั้น และไม่บันทึกคำสั่งและเอาต์พุต

การเลือก LAN และไคลเอนต์

เซสชันอุปกรณ์ CLI ใช้เฉพาะการปิดผนึกแบบ end-to-end เท่านั้น โดยไม่ขึ้นกับ seal_key ความสามารถ หรือคำแนะนำนโยบายที่รายงานโดย Exchange ข้อมูลความสามารถที่ขาดหายไปหรือถูกลบจะไม่ทำให้มีการปรับลดรุ่นข้อความธรรมดา ความล้มเหลวในการอ่านฐานข้อมูลพินในเครื่องถือเป็นข้อผิดพลาด บันทึกความน่าเชื่อถือที่เสียหายจะไม่ถูกละเลย

งาน exec และไฟล์ที่ปิดผนึกไว้ / ไม่ถือไว้จะถูกทำเครื่องหมายว่าปิดผนึกก่อนที่จะเผยแพร่ไปยังไดเร็กทอรีงานส่วนกลาง และไม่สามารถพึ่งพาสภาวะการแข่งขันของ "การปิดเซสชันก่อนที่จะประมวลผลเหตุการณ์ขาออกครั้งแรก" เพื่ออ่านตัวอย่างข้อความที่ชัดเจน บันทึกของอุปกรณ์จะไม่บันทึกเป้าหมายหรือเมธอดโพรบ HTTP อ็อบเจ็กต์ ubus หรือเมธอด

LAN นำซองจดหมายดั้งเดิม การถอดเสียงลายเซ็น ตัวนับ AEAD การแก้ไขอุปกรณ์ และกฎการเพิกถอนมาใช้ซ้ำ โดยไม่ต้องสร้างอัลกอริธึมการเข้ารหัสใหม่ LAN ขาออกต้องผ่าน Tunnels::seal_outbound และแปลเป็น OperatorDown; การแทรกข้อความธรรมดาของหมายเลขเซสชันที่ปิดผนึกจะถูกยกเลิกโดยผู้จ่ายงานอุปกรณ์ การเชื่อมต่อถูกปิดในขณะที่ยังคงปลดผู้บริหารที่ถือไว้ ยกเลิกการดำเนินการอื่นๆ และเอาต์พุตล่าช้าจะถูกละทิ้งโดย ID ที่ไม่พอใจ ไม่มีโทเค็น LAN: ไคลเอ็นต์ใส่การอนุญาตแคชแบบออฟไลน์และห่วงโซ่ใบรับรองลงในสวัสดี และอุปกรณ์จะกำหนดมุมมอง/จัดการตาม authorize เดียวกันกับ Exchange เลเยอร์ชั้นนอกจะตรวจสอบเฉพาะที่อยู่เครือข่ายส่วนตัวและแหล่งกำเนิดเท่านั้น เซสชันข้อความที่ชัดเจนจะถูกปฏิเสธบน LAN เสมอ โดยไม่คำนึงถึงค่านโยบายในอดีต เว็บคอนโซลที่โฮสต์ยังคงเชื่อมต่อกับ Exchange

ข้อมูลอุปกรณ์เสริม info.seal_mode (allow / require), seal_key และความสามารถของ sealed ยังคงเข้ากันได้ ไม่ใช่ทั้งการอนุญาตหรือกุญแจสาธารณะของอุปกรณ์ที่เชื่อถือได้ ในที่สุดอุปกรณ์ก็บังคับใช้นโยบาย คำสั่ง เทอร์มินัล ไฟล์ ubus เซ็นเซอร์ งาน โพรบเครือข่าย การทำงานของเดสก์ท็อป การอัปเดตอุปกรณ์ คำสั่งที่กำหนดไว้ล่วงหน้า และการทำงานของเบราว์เซอร์ใน CLI, เว็บ Console และ Android Console ล้วนใช้เซสชันที่ปิดผนึกแบบเนทีฟ ไม่มีเส้นทางข้อความธรรมดา ค่านโยบาย allow ยังปฏิเสธการดำเนินการกับข้อความธรรมดาอีกด้วย ความล้มเหลวของการจับมือ การปักหมุดอุปกรณ์ การให้สิทธิ์ หรือการถอดรหัสจะหยุดการดำเนินการโดยไม่ต้องลองข้อความธรรมดาอีกครั้ง การเปลี่ยนแปลงนโยบายออนไลน์รีเฟรชข้อมูล LAN ทันที ข้อมูลคลาวด์จะรีเฟรชเมื่อเชื่อมต่อใหม่และลงทะเบียน

การตรวจสอบสิทธิ์รูทเชนพื้นที่ทำงานของเบราว์เซอร์ Agent

ส่วนขยายโฆษณา sealed, Ed25519 seal_key และ seal_mode: require หลังจากจับคู่หรือกำหนดค่าอุปกรณ์แล้ว ระบบจะเรียก POST /api/seal/device พร้อมข้อมูลรับรองอุปกรณ์และหลักฐานการครอบครองที่ลงนาม Exchange รับพื้นที่ทำงานจากอุปกรณ์และผูกพับลิกคีย์ของอุปกรณ์ ไคลเอนต์ที่ถือคีย์ส่วนตัวรูทของพื้นที่ทำงานที่เชื่อถือได้ลงนามในสิทธิ์การดูสำหรับอุปกรณ์เบราว์เซอร์นั้น ๆ การลงทะเบียนและผู้ถืออุปกรณ์ให้การเข้าถึงรีเลย์และการดึงข้อมูลรับรอง เซสชันเบราว์เซอร์ต้องมีการรับรองความถูกต้องของใบรับรอง

ส่วนขยายจะตรวจสอบลายเซ็นขาเข้า ห่วงโซ่รูท ขอบเขตอุปกรณ์ ระดับ การหมดอายุ และการเพิกถอนในเครื่อง จากนั้นลงนาม SealAccept ด้วย SealHello ที่ลงนามของตนเองใน peer CLI finish_workspace_operator และ finishBrowser ที่แชร์จะตรวจสอบการพิสูจน์นั้น ต้องใช้ peer.operator_key == accept.device_key และตรวจสอบลายเซ็นที่ยอมรับ การพิสูจน์ที่ขาดหายไปหรือไม่ถูกต้องจะปิดเซสชัน เซสชันที่ถูกต้องจะเริ่มต้นโดยอัตโนมัติ Raw CDP ยังต้องการความยินยอมในท้องถิ่นตามคำขอหรือการอนุมัติแบบอัตโนมัติซึ่งกำหนดขอบเขตไว้ที่คีย์ผู้ปฏิบัติงาน เซิร์ฟเวอร์ และอุปกรณ์ สิทธิ์การดูไม่สามารถใช้ CDP ได้

บันทึกการอนุญาตขอบเขตส่วนขยายตามแหล่งกำเนิดเซิร์ฟเวอร์ พื้นที่ทำงาน และอุปกรณ์ ข้อมูลประจำตัวเฉพาะท้องถิ่นสามารถเข้าถึงได้เฉพาะกับบริบทส่วนขยายที่เชื่อถือได้เท่านั้น โดยปักหมุดรูทเวิร์กสเปซแรกในเครื่องและปฏิเสธการเปลี่ยนแปลง CLI และ Console ใช้เอกลักษณ์การปิดผนึกปกติและห่วงโซ่รูทของพื้นที่ทำงานโดยไม่มีตัวแก้ไขพินของเบราว์เซอร์แยกต่างหาก การลงนามรูทคีย์ ผู้ออกใบรับรอง และข้อมูลรับรองการลงทะเบียนอุปกรณ์เป็นการตรวจสอบที่แตกต่างกัน รหัสอุปกรณ์ดั้งเดิม TOFU ยังคงแยกจากกัน

ขอบเขตความปลอดภัย: TOFU รูทแรกไม่สามารถแยกแยะรูทปลอมที่มาจากรีเลย์ที่เป็นอันตราย ตรวจสอบมันออกจากวง PoP พิสูจน์การครอบครองคีย์ ไม่ใช่การอนุมัติจากสมาชิก การอนุมัติอัตโนมัติของไคลเอนต์รูทขึ้นอยู่กับบัญชีรายชื่อ การใช้งานที่มีความละเอียดอ่อนควรตรวจสอบคีย์ใหม่ ปกป้องโปรไฟล์ส่วนขยาย เมล็ดพันธุ์ และห่วงโซ่การเผยแพร่คอนโซลเว็บ จุดสิ้นสุดที่ถูกบุกรุกหรือการเข้าถึง CDP เต็มรูปแบบที่มอบให้แก่ผู้ปฏิบัติงานที่เป็นอันตรายนั้นอยู่นอกเหนือการป้องกันของการปิดผนึก การลบบันทึกไดเรกทอรีไม่เพิกถอนข้อมูลรับรองที่ลงนามในแคช กฎการเพิกถอนภายในอุปกรณ์และการหมดอายุยังคงมีความสำคัญ Exchange ยังสามารถสังเกตข้อมูลเมตาการกำหนดเส้นทาง ระงับข้อมูลรับรอง และปฏิเสธบริการ

เมื่อข้อมูลประจำตัวไม่พร้อมใช้งาน: หากไม่สามารถโหลดหรือเขียนข้อมูลประจำตัวของอุปกรณ์ได้ เซสชันที่ปิดผนึกจะไม่พร้อมใช้งาน และการดำเนินการข้อความธรรมดาทั้งหมดยังคงถูกปฏิเสธ (ปิดล้มเหลว) ไฟล์นโยบายที่สูญหายหรือเสียหายและค่านโยบายในอดีตจะไม่เปิดใช้งานข้อความธรรมดา ซ่อมแซมที่เก็บข้อมูลคีย์ภายในอุปกรณ์

กล่องจดหมาย HTTP จำเป็นต้องมีความสัมพันธ์กับการสร้างอินสแตนซ์ Exchange และหมดอายุหลังจาก 90 วินาทีโดยไม่มีกิจกรรม ทำให้อินพุตเป็นอนุกรม ลองเฉพาะลำดับและข้อความไซเฟอร์เดียวกันอีกครั้ง และรับทราบเหตุการณ์ที่ประมวลผลด้วย after เว็บ Console, อุปกรณ์เคลื่อนที่ และ LAN ยังคงรักษาการขนส่งที่มีอยู่ การดำเนินการที่กำหนดไว้ล่วงหน้ายังคงต้องใช้ manage

การตรวจสอบการถดถอย

การทดสอบ Rust ครอบคลุมการจับมือที่อนุญาตโดยอุปกรณ์จริง, ผลลัพธ์ของ exec/attach/tail/cat/sensors/net/update ที่ปิดผนึก, การปฏิเสธข้อความธรรมดาภายใต้ทุกค่านโยบาย, LAN WebSocket การจับมือ/เฟรม/การอัปเดตนโยบายที่ปิดผนึก, คำแนะนำ HTTP 409, การปิดเส้นทางโหมดต้องใช้เบราว์เซอร์ และค่าคงที่การปิดผนึกที่บังคับสำหรับไคลเอนต์และข้อมูลอุปกรณ์ การทดสอบ JavaScript ครอบคลุมเวกเตอร์ Rust/JS แบบสองทิศทางที่มีอยู่ ซองจดหมายการดำเนินการ เอาต์พุตคำสั่งที่กำหนดไว้ล่วงหน้าแบบปิดผนึกโดยไม่มีทางเลือกอื่นหลังจากการปฏิเสธ การกำหนดค่าเบราว์เซอร์/การลงทะเบียน/การปฏิเสธอุปกรณ์/การเปลี่ยนแปลงนโยบายท้องถิ่น และข้อผิดพลาดในการปักหมุดไคลเอ็นต์ ซิงเกิลตันการปิดผนึกทั้งกระบวนการจะเริ่มต้นในกระบวนการย่อยที่แยกได้ในระหว่างการทดสอบ ดังนั้นการทดสอบที่เกิดขึ้นพร้อมกันจึงไม่สามารถแก้ไขนโยบายด้านอุปกรณ์ของกันและกันได้

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

จาวาสคริปต์ใช้โหนด 24+ เพิ่มการถดถอย LAN แบบปิดผนึกสำหรับการอัปเกรด HTTP จริง / WebSocket ผ่านการสตรีมดูเพล็กซ์ในหน่วยความจำ พร้อมความสามารถในการตรวจสอบการจับมือกัน เฟรม และการปิดผนึกบังคับภายใต้ทุกค่านโยบายในแซนด์บ็อกซ์ที่ปิดใช้งานซ็อกเก็ตเครือข่าย การทดสอบ WS/TLS/HTTP แบบวนกลับที่มีอยู่ยังคงต้องอยู่ในสภาพแวดล้อมที่อนุญาตให้รวมพอร์ตได้ มิฉะนั้นจะล้มเหลวด้วย Operation not permitted และไม่สามารถใช้เป็นหลักฐานว่าชุดการทดสอบทั้งหมดผ่านการทดสอบ การตรวจสอบเครือข่ายและการทดสอบเส้นทางการอัปเดตจะตรวจสอบผลลัพธ์ความสำเร็จ/ข้อผิดพลาดของการปิดผนึก การอัปเดตจะไม่ถูกดาวน์โหลดหรือติดตั้ง

** ความเสี่ยงพิเศษของเว็บ Console:** รหัสของหน้าเว็บนั้นถูกส่งโดยไซต์ Pages ไซต์/CDN ที่ถูกบุกรุกสามารถออกสคริปต์ที่เป็นอันตรายเพื่ออ่านข้อความธรรมดาของหน้านี้หรือเซ็นชื่อด้วยคีย์ของเบราว์เซอร์ (แต่ไม่สามารถนำคีย์ส่วนตัวที่ไม่สามารถส่งออกออกไปได้) ข้อกำหนดเบื้องต้นสำหรับการรักษาความลับจากตัวดำเนินการ Exchange คือคุณเชื่อถือห่วงโซ่การเผยแพร่ของไซต์แบบคงที่ หากคุณไม่แน่ใจเกี่ยวกับเรื่องนี้ โปรดใช้ CLI หรือ Android Console

ตัวตนและกุญแจ

คีย์ส่วนตัวของตัวดำเนินการจะถูกจัดเก็บไว้ในเครื่อง Console อัปโหลดการสำรองข้อมูลรูทด้วยข้อความรหัสผ่านว่างเปล่าตามค่าเริ่มต้น Exchange หรือผู้ถือฐานข้อมูลสามารถถอดรหัสได้ ตั้งค่าข้อความรหัสผ่านสำรองด้วยตนเอง หรือลบข้อมูลสำรองเพื่อปิดใช้งานการบันทึกอัตโนมัติบนไคลเอนต์นี้

การอนุญาต (Exchange ไม่ใช่การอนุญาต)

อุปกรณ์จะเชื่อถือคีย์สาธารณะรูทของพื้นที่ทำงานเพียงคีย์เดียวเท่านั้น นโยบายท้องถิ่น agent.seal.json:

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

agent กำหนดระดับสำหรับ sealed_open แต่ละตัวด้วยตัวมันเอง:

1. ไม่มีการปักหมุดรูทพื้นที่ทำงานบนอุปกรณ์ → ปฏิเสธ (no workspace root pinned on this device)
2. รหัสสาธารณะของผู้ดำเนินการที่ revoked_keys → ถูกปฏิเสธ
3. รหัสสาธารณะของผู้ดำเนินการคือ root_key → owner (จัดการได้ + แก้ไขนโยบายท้องถิ่น)
4. มีการจัดหา grant มาให้: ลายเซ็นถูกต้อง, operator_key ตรงกับการจับมือ, device_id ระบุอุปกรณ์นี้หรือ * และสิทธิ์นั้นอยู่ภายในระยะเวลาที่มีผลใช้ได้ (±5 นาทีของการเอียงของนาฬิกา) ผู้ลงนามจะต้องเป็นรูทที่ปักหมุดไว้ หรือสวัสดีต้องมีห่วงโซ่ใบรับรอง rsc1. (hello.chain ซึ่งไม่ครอบคลุมอยู่ในลายเซ็นแฮนด์เชค) โดยเรียงลำดับจากใบรับรองที่ออกโดยรูทไปยังผู้ลงนามการให้สิทธิ์ ใบรับรองแต่ละใบจะต้องอนุญาตให้ออกเพิ่มเติมได้ และความยาวเส้นทาง ระดับ ขอบเขตอุปกรณ์ และการหมดอายุจะต้องอยู่ภายในใบรับรองก่อนหน้า ระดับสิทธิ์คือ view หรือ manage ไม่ใช่ owner
5. อื่นๆ → ปฏิเสธ

ข้อจำกัดของห่วงโซ่ใบรับรอง

อุปกรณ์ยอมรับสายโซ่ rsc1. ที่ยืนยันกลับไปยังรูทพื้นที่ทำงานที่ปักหมุดไว้ ไม่ใช่ใบรับรองระดับกลางที่แยกออกมา (hello.chain สั่งจากใบรับรองที่ออกรูทไปยังผู้ลงนามการให้สิทธิ์) มี ไม่มีการจำกัดความลึกขององค์กร: องค์กรอาจมีมากกว่า 10 ระดับ ราวกั้น DoS ขนาดใหญ่จะจำกัดเชนไว้ที่ใบรับรอง MAX_CERT_CHAIN = 64 และขนาดที่เข้ารหัส (ผลรวมของความยาวโทเค็น Canonical rsc1.) ถึง MAX_CERT_CHAIN_BYTES ≤ 64 KiB (check_chain_limits / checkChainLimits ใน crates/proto/src/seal.rs / shared/seal-cert.js; กฎที่เหมือนกันบนอุปกรณ์, Exchange, CLI, เว็บ และ Android) เกินขีดจำกัดอย่างใดอย่างหนึ่งทำให้เกิดการปฏิเสธทันที

ใบรับรองแต่ละใบยังมี max_path_len (0–255) ซึ่งเป็นข้อจำกัดของผู้ออก เป็นทางเลือก เกี่ยวกับจำนวนใบรับรองที่อาจตามมา หากไม่มี --max-path, seal cert issue จะใช้ค่าเริ่มต้นเป็นความลึกของผู้ออกที่เหลือทั้งหมด (255 ไม่จำกัดอย่างมีประสิทธิภาพ) การยืนยันกำหนดให้จำนวนใบรับรองที่ตามมาต้องไม่มากกว่า max_path_len ใบรับรองระดับกลางที่ออกโดยรูทให้กับผู้ดูแลระบบมี max_path_len 0: ผู้ดูแลระบบอาจลงนามในการอนุญาต แต่ไม่สามารถออกใบรับรองอื่นได้ can_issue ที่เป็นเท็จยังป้องกันการออกใบรับรองเพิ่มเติมอีกด้วย

ใบรับรองย่อยจะต้องอยู่ในใบรับรองหลัก (cert_within_parent / verify_chain บนอุปกรณ์):

• level ไม่เกินระดับพาเรนต์ รูตคือ owner; ระดับที่ได้รับต้องเป็น view หรือ manage เท่านั้น และต้องไม่สูงกว่าใบรับรองหลัก owner ไม่สามารถปรากฏในใบรับรองหรือสิทธิ์ได้
• Device scope เป็นเซ็ตย่อยของพาเรนต์ ลูกสามารถครอบคลุมอุปกรณ์ทั้งหมดได้ก็ต่อเมื่อพาเรนต์มี *; ไม่เช่นนั้นอุปกรณ์แต่ละชิ้นของเด็กจะต้องอยู่ในรายการของผู้ปกครอง รายการย่อยจะถูกเขียนว่า * เฉพาะในกรณีที่รายการหลักเป็น * ด้วย
• Eexpiration time ไม่สามารถอยู่หลังใบรับรองหลักได้ รากไม่มีขีดจำกัดการหมดอายุ นอกจากนี้ Grant ยังต้องไม่ช้ากว่าใบรับรองที่ออก และอุปกรณ์ก็ไม่สามารถเกินขอบเขตของใบรับรองนั้นได้

**การเพิกถอนใบรับรองระดับกลางจะเรียงซ้อนกับทุกสิ่งที่อยู่ด้านล่าง ** อุปกรณ์จะตรวจสอบทุก subject_key และ serial บนเชนกับ revoked_keys ในนโยบาย หลังจากที่อันกลางถูกเพิกถอน เชนอีกต่อไปที่ยังคงแบกมันไว้จะล้มเหลว ดังนั้นใบรับรองรองที่ออกให้ เช่นเดียวกับหน่วยงานที่ออกโดยใบรับรองเหล่านั้น จะกลายเป็นโมฆะ การลบใบรับรองจาก Exchange จะหยุดการแจกจ่ายเพิ่มเติมเท่านั้น และสำเนาที่เก็บไว้ในอุปกรณ์นั้นยังคงใช้ได้ก่อนหมดอายุ หากต้องการทำให้เชนด้านล่างทั้งหมดไม่ถูกต้องทันที ให้เขียนคีย์สาธารณะของหัวเรื่อง (หรือหมายเลขซีเรียล) ของใบรับรองลงในนโยบายด้านอุปกรณ์ revoked_keys

การแมประดับกับการดำเนินการ (proto::seal::required_level): view (ดูอย่างเดียว) อนุญาตให้เซ็นเซอร์ เก็บรายการงานไว้ การดำเนินการอ่านอย่างเดียว Android (สถานะ/ต้นไม้/ภาพหน้าจอ/find_text); สิ่งอื่นๆ ทั้งหมด (exec, PTY, ไฟล์, ubus, การตรวจจับเครือข่าย, การอัปเดตตัวเอง, อินพุต Android) ต้องใช้ manage

การให้สิทธิ์เป็น JSON ที่ลงนามโดยรูท การดัดแปลงฟิลด์ใดๆ โดย Exchange (เช่น ดู → จัดการ การเปลี่ยนอุปกรณ์ การขยายระยะเวลาที่มีผล การเปลี่ยนบุคคลที่ได้รับอนุญาต) จะทำให้ลายเซ็นเป็นโมฆะ ลายเซ็นการจับมือยังผูกการอนุญาตในเซสชันนี้ด้วย บทบาทของบัญชีในฝั่ง Exchange จะกำหนดว่า "สามารถกำหนดเส้นทางข้อความไปยังอุปกรณ์นี้ได้หรือไม่" (การเปิดเผยผู้เช่า) และจะไม่ขยายหรือลดสิทธิ์ของเซสชันที่ปิดผนึก ไม่มีการอ้างสิทธิ์ในระดับอุปกรณ์ เจ้าของ หรือเจ้าของร่วม: owner เดียวเท่านั้นที่เป็นรูท

อุปกรณ์ต่างๆ ปักหมุดรูทอย่างไร:

• TOFU: เมื่ออุปกรณ์ที่สามารถปิดผนึกเชื่อมต่อกับ Exchange, Exchange จะส่ง seal_root {token, rotation?} (บันทึก root ของ rsr1. ที่ลงนามด้วยตนเอง) อุปกรณ์จะตรวจสอบลายเซ็นตนเอง ถ้าไม่มีการปักหมุดรูทในเครื่อง มันจะปักหมุดรูทนี้และเขียนไปที่ agent.seal.json
• Rotation: หลังจาก root ได้รับการแก้ไขแล้ว root ที่ประกาศโดย Exchange จะเปลี่ยนไป อุปกรณ์จะเปลี่ยนเป็นรูทใหม่เมื่อได้รับบันทึกการหมุน rsx1. พร้อมกันซึ่งลงนามโดยรูทคงที่ (old_root = รูทคงที่, new_root = รูทใหม่ พื้นที่ทำงานเดียวกัน); มิฉะนั้นจะถูกละเว้นและบันทึกไว้ รากยังสามารถเปลี่ยนแปลงได้ในเซสชันที่ปิดผนึกด้วย seal_policy_set {root_key} (เฉพาะรากปัจจุบันเท่านั้นที่มีระดับ owner)
• การตั้งค่าท้องถิ่น: remote-agent seal root <key> ถูกเขียนโดยตรงไปยังรูท; remote-agent seal forget-root ถูกล้าง และ TOFU จะถูกทำซ้ำในครั้งถัดไปที่เชื่อมต่อ Exchange (การรีสตาร์ท agent จะมีผล)

Risk: หาก Exchange ถูกโจมตีในการเชื่อมต่อครั้งแรกของอุปกรณ์ TOFU จะปล่อยให้อุปกรณ์ทำการรูทปลอม หากเป็นข้อกังวล ให้ปักหมุดคีย์สาธารณะรูทด้วย remote-agent seal root <key> ก่อนที่จะนำอุปกรณ์ออนไลน์ (ดู remote-cli seal root สำหรับลายนิ้วมือของอุปกรณ์) เมื่อปักหมุดแล้ว Exchange จะไม่สามารถแทนที่รูทนั้นได้

Revocation: Root remote-cli seal policy <设备> --revoke <key> หรือบนอุปกรณ์ remote-agent seal revoke <key> ไม่สามารถเพิกถอนรากได้ การอนุญาตมีระยะเวลาที่ถูกต้อง (90 วันตามค่าเริ่มต้น) การลบทุนที่เผยแพร่ออกจาก Exchange จะไม่เป็นการแจกจ่ายอีกต่อไป สำเนาที่นำเข้าในเครื่องยังคงใช้ได้จนกว่าจะหมดอายุและต้องถูกเพิกถอนตามนโยบายด้านอุปกรณ์

Exchange เป็นรีเลย์การให้สิทธิ์ที่ไม่น่าเชื่อถือ

เพื่อนร่วมงานไม่จำเป็นต้องคัดลอกโทเค็น rsg1. หรือคีย์สาธารณะลงในหน้าต่างแชทอีกต่อไป: Exchange มี Operator Public Key Directory และ grant Relay ระดับพื้นที่ทำงาน สิ่งนี้ไม่เปลี่ยนรูปแบบภัยคุกคาม - Exchange ยังคงไม่สามารถมองเห็นข้อความที่ชัดเจน และไม่สามารถออก ขยาย หรือปลอมแปลงการอนุญาตได้ มันจะช่วยประหยัด:

1. ผู้ดำเนินการใช้รหัสส่วนตัวในเครื่องเพื่อพิสูจน์รหัสสาธารณะ Ed25519 (POST /api/seal/keys) ที่เขาถืออยู่
2. ข้อความต้นฉบับของโทเค็น rsg1. ที่ลงนามแล้ว (POST /api/seal/grants)
3. ข้อความต้นฉบับของใบรับรองระดับกลาง rsc1. ที่ลงนามแล้ว (POST /api/seal/certs) Exchange ตรวจสอบลายเซ็น Ed25519 ของผู้ออก แต่ไม่สามารถปลอมแปลงใบรับรองได้ GET /api/seal/certs/chain?subject_key= ดึงโทเค็นตามความสัมพันธ์การออก (จำกัดด้วยโทเค็น 64 เดียวกัน / รั้ว 64 KiB) ออกรูตก่อน

การให้สิทธิ์อุปกรณ์ยังคงรับรู้เฉพาะรูทแบบคงที่ หรือสายใบรับรอง rsc1. ที่สามารถตรวจสอบรูทได้ Exchange แยกวิเคราะห์โทเค็นเพื่อสร้างดัชนีตามเวลา owner_key / operator_key / เวลาหมดอายุเท่านั้น และไม่ถือว่าการอัปโหลดเป็นการอนุญาต กรณีที่แย่ที่สุดคือผู้ดำเนินการระงับโทเค็น (อีกฝ่ายไม่สามารถรับสิทธิ์ได้ ซึ่งปรากฏเป็น no grant) และไม่สามารถเปลี่ยน view เป็น manage ได้ และไม่สามารถหลอกว่าเป็น root ได้

สมาชิกพื้นที่ทำงานทุกคนสามารถอัปโหลดทุนได้: โทเค็นมาพร้อมกับลายเซ็นของตัวเอง และการอัปโหลดไม่ใช่การดำเนินการอนุญาต เฉพาะสิทธิ์ที่ลงนามโดยรูทเท่านั้นที่ถูกต้องสำหรับอุปกรณ์ CLI มีค่าเริ่มต้นเป็น --publish เมื่อเข้าสู่ระบบ คอนโซล Web/Android ใช้อินเทอร์เฟซเดียวกันเมื่อ "ลงนามและเผยแพร่"

การผูกมัดหลักฐานการครอบครองสำหรับการลงทะเบียนกุญแจ:

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

หลักฐานเป็นลายเซ็น Ed25519 ที่สร้างด้วยคีย์ส่วนตัวที่สอดคล้องกับคีย์สาธารณะนี้ issued_at_ms ต้องอยู่ภายใน ±10 นาทีของเวลาเซิร์ฟเวอร์ CLI พยายามลงทะเบียนบน login และ seal show คอนโซลลงทะเบียนหลังจากเข้าสู่ระบบ

หากไม่มีเงินอุดหนุนที่ตรงกันในพื้นที่ก่อนการดำเนินการปิดผนึก ผู้ปฏิบัติงานจะพยายามอย่างดีที่สุดกับ seal sync เมื่อการจับมือถูกปฏิเสธเนื่องจาก no grant มันจะซิงโครไนซ์อีกครั้งและลองอีกครั้ง

เมื่อลูกค้าของผู้ออกออนไลน์ ลูกค้าจะต่ออายุการอนุญาตที่ออกให้โดยอัตโนมัติและกำลังจะหมดอายุ ลายเซ็นยังคงเสร็จสิ้นภายในเครื่อง Exchange บันทึกเฉพาะโทเค็น rsg1. ใหม่และลบบันทึกเก่า และไม่สามารถเปลี่ยนระดับหรือเปลี่ยนบุคคลที่ได้รับอนุญาต

• ** เมื่อรัน: ** CLI หลังจากการเข้าสู่ระบบสำเร็จ และเมื่อคำสั่งการเข้าสู่ระบบใด ๆ เริ่มทำงาน (seal renew ใช้เส้นทางแบบแมนนวลและไม่ใช้เลเยอร์ของการต่ออายุอัตโนมัติ) เว็บ Console จะเข้าสู่พื้นที่ทำงานเมื่อเข้าสู่ระบบและเข้าสู่พื้นที่ทำงาน (หากมีเซสชันอยู่แล้วหลังจากโหลดเพจแล้ว) Android Console หลังจากเข้าสู่ระบบ และเมื่อแอปกลับมาทำงานเบื้องหน้า หากคุณไม่ได้เข้าสู่ระบบ หรือหากคีย์สาธารณะนี้ไม่มีการอนุญาตที่เผยแพร่ ก็จะไม่มีการต่ออายุ
• กฎการต่ออายุ: GET /api/seal/grants?owner_key=<本机公钥> เงินช่วยเหลือที่หมดอายุภายใน 30 วันจะถูกออกใหม่ด้วย device_id, operator_key และ level ดั้งเดิมเป็นเวลา 90 วัน หลังจากรีลีสสำเร็จ สิทธิ์เก่าจะเป็น DELETE หาก GET /api/seal/keys สำเร็จ operator_key ที่ไม่ได้อยู่ในไดเร็กทอรีคีย์สาธารณะอีกต่อไปจะถูกข้ามไป หากการร้องขอไดเร็กทอรีล้มเหลว มันจะไม่ถูกกรองตามไดเร็กทอรี
• Throttling: Web/Android: รหัสสาธารณะที่ออกเดียวกันนี้จะถูกลองใช้มากที่สุดทุกๆ 12 ชั่วโมง CLI ถูกบันทึกในไดเร็กทอรีการกำหนดค่าเป็น seal-renew-state.json, Web Console ใช้ localStorage และ Android Console ใช้ SecureStore ความล้มเหลวไม่ส่งผลต่อการดำเนินการปัจจุบัน: CLI พิมพ์เฉพาะบรรทัดคำเตือนบน stderr และคอนโซลใช้ console.warn เมื่อการต่ออายุสำเร็จ CLI จะพิมพ์คำอธิบายสั้น ๆ เกี่ยวกับ stderr เว็บ Console ที่เก็บรูทจะออกหนึ่งรอบก่อนเมื่อเข้าสู่พื้นที่ทำงาน และ Android จะออกหนึ่งรอบก่อนเมื่อเปิดใช้งาน "การเข้ารหัสจากต้นทางถึงปลายทาง" สองครั้งนี้ไม่อยู่ภายใต้การควบคุมปริมาณ 12 ชั่วโมง การรีเฟรชหลังจากการเข้าพักครั้งเดียวกันเท่านั้นที่จะถูกควบคุมปริมาณ
• การต่ออายุ CLI: บันทึกความสำเร็จแยกตามเซิร์ฟเวอร์และกุญแจผู้ออก หลังสำเร็จจะข้ามคำขอต่ออายุเป็นเวลา 12 ชั่วโมง หากล้มเหลวหรือถูกขัดจังหวะจะรอเพียง 5 นาทีก่อนลองใหม่ กระบวนการทั้งหมดมีเวลาสูงสุด 30 วินาที ข้อผิดพลาดระบุขั้นตอนและเวลาที่ใช้ หากคำสั่งหลักล้มเหลวจะยกเลิกการต่ออายุทันที การเพิกถอนอุปกรณ์ที่ยังค้างอยู่ไม่ถูกจำกัดด้วยช่วงเวลาหลังสำเร็จ และมีเวลาของตัวเอง 4 วินาที ใช้ remote-cli seal renew เพื่อต่ออายุโดยตรง หลังเข้าสู่ระบบสำเร็จจะบังคับรีเฟรชหนึ่งครั้ง
• Root client: ไคลเอ็นต์ผู้ดูแลระบบขั้นสูงที่เก็บเวิร์กสเปซรูทใช้การออกตามบทบาทในส่วนถัดไปเพื่อแทนที่การต่ออายุทั่วไปนี้เพื่อหลีกเลี่ยงการลงนามกลับการอนุญาตที่ถูกลบใหม่
• Manual: ยังคงใช้งานได้ remote-cli seal renew (ค่าเริ่มต้น --before 30 --days 90) กฎเดียวกันกับการต่ออายุอัตโนมัติ

# 按工作区用户名授权对方每一把已登记的钥匙，并发布到 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

ผู้ดูแลระบบขั้นสูงของพื้นที่ทำงานคือรากฐานของความไว้วางใจ

รากของพื้นที่ทำงานคือคีย์ Ed25519 บนไคลเอ็นต์ผู้ดูแลระบบระดับพิเศษ อุปกรณ์จะเชื่อถือเฉพาะคีย์สาธารณะรูทนี้เท่านั้น และสามารถตรวจสอบการอนุญาต rsg1. ของรูทได้ตลอดสายใบรับรอง rsc1. ไคลเอนต์รูทจะออกและต่ออายุการอนุญาตสมาชิกโดยอัตโนมัติตามบทบาทของบัญชี Exchange ยังคงไม่น่าเชื่อถือ: จะบันทึกเฉพาะบันทึก root ของ rsr1. ที่ลงนามด้วยตนเอง, บันทึกการหมุนเวียน rsx1. และคำเชิญ rsi1. และตรวจสอบรูปแบบกับลายเซ็น Ed25519 โดยไม่ต้องตัดสินใจว่าใครเป็นผู้อนุมัติ Exchange ที่เป็นอันตรายสามารถระงับบันทึกหรือกรอกบัญชีรายชื่อด้วยสมาชิกปลอม มันไม่สามารถปลอมแปลงลายเซ็นรูตได้ การอนุมัติอัตโนมัติจะถูกเปิดใช้งานตามค่าเริ่มต้นใน CLI, Web และ Android และคีย์สาธารณะใหม่ในบัญชีรายชื่อจะถูกลงนามโดยตรงจากไคลเอ็นต์รูทเหล่านี้ เฉพาะเมื่อมีการปิดการอนุมัติอัตโนมัติอย่างชัดเจนเท่านั้น กุญแจสาธารณะใหม่ที่ไม่เคยได้รับการอนุมัติและไม่ได้รับการเผยแพร่โดยรูทนี้จะยังคงอยู่ในรายการที่รอดำเนินการ

รูปแบบความน่าเชื่อถือและการแลกเปลี่ยน

• กุญแจสาธารณะรูทได้รับการแก้ไขในการใช้งานครั้งแรก (TOFU) ** เมื่อไคลเอนต์เห็นบันทึกรูทที่ตรวจสอบแล้วเป็นครั้งแรก จะทำการแก้ไขกุญแจสาธารณะในเครื่อง CLI เขียน seal-root.json (0600) ถัดจาก config.toml และคีย์คือ 服务器|工作区 id เว็บ Console ใช้ localStorage (remote.seal.root.<工作区 id>) Android Console ใช้ SecureStore (remote.seal.rootstate วางใน JSON เดียวกันโดยเซิร์ฟเวอร์และพื้นที่ทำงาน) จากนั้นตรวจสอบลายเซ็นตนเองและลายนิ้วมือทุกครั้ง หากคีย์สาธารณะรูทคงที่มีการเปลี่ยนแปลง จะมีการออกคำเตือนเสียงดัง ** ไคลเอนต์จะไม่เปลี่ยนรหัสผ่านโดยอัตโนมัติ (อุปกรณ์จะเปลี่ยนรหัสผ่านโดยอัตโนมัติตามบันทึกการหมุน rsx1. ดูด้านบน) หลังจากตรวจสอบลายนิ้วมือแล้ว ให้ดำเนินการ remote-cli seal root --trust <key> อย่างชัดเจน หรือคลิก "เชื่อถือคีย์สาธารณะรูทใหม่" ในคอนโซล
• **Invitation เปิดให้ลงทะเบียนเท่านั้น ** Root public key ออก rsi1. (รหัสพื้นที่ทำงาน, root public key, nonce 16 ไบต์, เวลาหมดอายุ) ผู้ดูแลระบบ ผู้ปฏิบัติงาน และไคลเอนต์ที่มีบัญชีแบบอ่านอย่างเดียวจะดึงคำเชิญเมื่อเข้าสู่ระบบ ปฏิบัติตามคำสั่ง โหลดเพจ หรือเมื่อแอปพลิเคชันกลับสู่เบื้องหน้า ตรวจสอบลายเซ็นด้วยรหัสสาธารณะรูทคงที่ จากนั้นใช้ POST /api/seal/keys ดั้งเดิมเพื่อลงทะเบียนรหัสสาธารณะของผู้ปฏิบัติงาน คำเชิญไม่ใช่การอนุญาต
• **ออกตามบทบาท อนุมัติคีย์ใหม่ภายในเครื่อง ** ไคลเอ็นต์ผู้ดูแลระบบระดับสูงซึ่งมีคีย์สาธารณะรูทอยู่ อ่าน GET /api/seal/roster (ผู้ดูแลระบบระดับสูงเท่านั้น รวมถึงสมาชิกที่ปิดใช้งาน บทบาท operator_device_grants คีย์สาธารณะที่ลงทะเบียน) และสิทธิ์ที่เผยแพร่ของตนเอง และคำนวณการอนุญาตที่คาดหวัง กุญแจสาธารณะที่ลงทะเบียนเดียวกันจะใช้ช่วงชุดนี้ร่วมกัน:
  • ผู้ดูแลระบบขั้นสูงและผู้ดูแลระบบที่ไม่จำกัด: manage *
  • ผู้ดูแลระบบที่ถูกจำกัด: ได้รับอนุญาตจากอุปกรณ์ can_manage คือ manage มิฉะนั้น view
  • ตัวดำเนินการที่ไม่จำกัด: view * รวมถึง manage สำหรับอุปกรณ์ can_manage แต่ละตัว
  • ผู้ดำเนินการที่ถูกจำกัด: ต่อการตรวจสอบอุปกรณ์ manage หรือ view
  • อ่านอย่างเดียวไม่จำกัด: view *
  • จำกัดการอ่านอย่างเดียว: view ต่ออุปกรณ์ที่ได้รับอนุญาต บัญชีแบบอ่านอย่างเดียวไม่สามารถใช้งานอุปกรณ์ได้ ดังนั้นแม้แต่ can_manage ก็จะไม่ถูกส่ง manage
  • สมาชิกผู้พิการ: ห้ามโพสต์
  • ค่าเริ่มต้น 90 วัน ต่ออายุโดยเหลือเวลาน้อยกว่า 30 วัน
• **Aใบรับรองระดับกลางของผู้ดูแลระบบ ** Root ไคลเอ็นต์ออก rsc1. ให้กับผู้ดูแลระบบที่เปิดใช้งาน (manage, can_issue, max_path_len คือ 0, 90 วัน) ขอบเขตอุปกรณ์ของผู้ดูแลระบบที่ไม่จำกัดคือ * ผู้ดูแลระบบแบบจำกัดคืออุปกรณ์ที่ได้รับการกำหนดให้ can_manage ต่ออายุเหลือเพียง 30 วันเท่านั้น จะไม่มีการออกใบรับรองสำหรับกุญแจสาธารณะใหม่ที่ยังไม่ได้รับการอนุมัติ เมื่อไคลเอ็นต์ของผู้ดูแลระบบถือใบรับรองระดับกลางที่ยังคงใช้ได้อยู่ ไคลเอ็นต์จะใช้คีย์ของตัวเองและสายโซ่นี้เพื่อออกการอนุญาตให้กับสมาชิกที่จัดการ และขอบเขตคือจุดตัดของใบรับรองและการมอบหมายอุปกรณ์ หากรูทยังมีสิทธิ์ใหม่ซึ่งครอบคลุมโอเปอเรเตอร์ อุปกรณ์ และระดับเดียวกันอยู่แล้ว (* ของรูทครอบคลุมอุปกรณ์เฉพาะ manage ครอบคลุม view) ก็จะไม่เซ็นชื่ออีกต่อไป การเพิกถอนใบรับรองจาก Exchange จะหยุดการแจกจ่ายเพิ่มเติมเท่านั้น สำเนาที่มีอยู่แล้วในอุปกรณ์ยังคงใช้ได้จนกว่าจะหมดอายุ การเพิกถอนแบบถาวรอาศัย revoked_keys ในนโยบายด้านอุปกรณ์
• การอนุมัติอัตโนมัติเปิดอยู่ตามค่าเริ่มต้น ในเว็บ Console (localStorage) และ Android Console (SecureStore) เมื่อบันทึกไม่มีฟิลด์นี้ จะถือว่าเปิดอยู่ (ขาด = เปิด) เฉพาะ false ที่ชัดเจนเท่านั้นที่ยังคงปิดอยู่ รายการที่ปิดไปแล้วจะไม่ถูกเปิดอีกครั้งตามตรรกะเริ่มต้น หลังจากเปิดแล้ว ไคลเอ็นต์รูทจะลงชื่อโดยตรงตามบัญชีรายชื่อ weaker: Exchange ที่ถูกบุกรุกสามารถแทรกสมาชิกปลอมและรับลายเซ็นได้ทันที สำเนาสวิตช์คือ "อนุมัติคีย์สาธารณะใหม่โดยอัตโนมัติ" CLI เปิดใช้งานตามค่าเริ่มต้นเช่นเดียวกับ Web/Android Console หากไม่มีไฟล์ seal-approved.json หรือฟิลด์ auto_approve จะถือว่าเปิดอยู่ ส่วน "auto_approve": false ที่ระบุไว้อย่างชัดเจนจะยังคงปิด ใช้ remote-cli seal approve --no-auto-approve เพื่อปิด หรือ remote-cli seal approve --auto-approve เพื่อเปิดอีกครั้ง โดยระบบจะบันทึกตัวเลือกนี้ หลังจากปิด คีย์ที่ไม่เคยได้รับการอนุมัติหรือเผยแพร่โดยคีย์สาธารณะรูทนี้จะเข้าสู่รายการที่รอดำเนินการในเครื่อง (CLI seal-approved.json, Web localStorage, Android SecureStore) remote-cli seal pending แสดงชื่อผู้ใช้และลายนิ้วมือ seal approve --all หรือ seal approve <key>… จะออกทันทีเมื่อได้รับอนุมัติ สำหรับคีย์ที่ได้รับการอนุมัติ เช่นเดียวกับคีย์ที่ออกโดยคีย์สาธารณะรูทนี้ การต่ออายุและการเปลี่ยนแปลงบทบาทจะเสร็จสมบูรณ์โดยอัตโนมัติ การออกคีย์สาธารณะของลูกค้าไม่จำเป็นต้องได้รับการอนุมัติอีกครั้ง
• **ลงชื่อเข้าใช้ทันทีที่คุณเปิดขึ้นมา ** ไคลเอ็นต์รูทจะถูกเซ็นชื่อทันทีเมื่อเว็บ Console เข้าสู่พื้นที่ทำงาน และ Android เปิด "End-to-End Encryption" รอบนี้ไม่ต้องควบคุมปริมาณ 12 ชั่วโมง การรีเฟรชอัตโนมัติหลังจากการเข้าพักเดิมยังคงถูกควบคุมปริมาณ การเปลี่ยนสวิตช์หรือการคลิก "อนุมัติ" จะบังคับให้คุณลงชื่อเข้าใช้อีกครั้ง
• **กล่องโต้ตอบบัญชี ป้ายสถานะ และบรรทัดความล้มเหลว ** สวิตช์เว็บ Console และรายการที่รอดำเนินการอยู่ในกล่องโต้ตอบ "บัญชี" บนหน้าอุปกรณ์ ("บัญชี" บนแถบเครื่องมือ) เมื่อมีคีย์ที่รอการอนุมัติ ป้าย "คีย์สาธารณะ N ที่รอการอนุมัติ" จะแสดงบนแถบเครื่องมือเดียวกัน คลิกป้ายเพื่อเปิดกล่องโต้ตอบนี้ เมื่อการเซ็นชื่อล้มเหลว จะมีบรรทัดสถานะในแถบเครื่องมือ: "การเซ็นชื่อรูทของพื้นที่ทำงานล้มเหลว:..." โทเค็นการปิดผนึกและวัสดุกุญแจแบบยาวจะถูกลบออกจากบรรทัดนี้ สวิตช์ Android ป้ายสถานะประโยคเดียวกัน และคำแนะนำความล้มเหลวในบรรทัดเดียวกันอยู่ที่หน้าการเข้ารหัสจากต้นทางถึงปลายทาง
• **Downgrade จะไม่เพิกถอนการอนุญาตเก่าบนอุปกรณ์ ** เมื่อสมาชิกถูกลบ ปิดใช้งาน หรือคีย์สาธารณะหายไปจากไดเร็กทอรี ให้ลบสิทธิ์ออกจาก Exchange หยุดการต่ออายุ และลองเขียน revoked_keys บนอุปกรณ์ที่ออนไลน์และรองรับเซสชันที่ปิดผนึก เมื่อบทบาทถูกดาวน์เกรด จะมีการแลกเปลี่ยนเฉพาะสิทธิ์ใหม่เท่านั้น และคีย์จะไม่ถูกใส่ลงใน revoked_keys ทุนเก่าที่นำเข้าบนอุปกรณ์ยังคงใช้ได้ก่อนหมดอายุ คีย์สาธารณะรูทจะไม่ถูกใส่ไว้ในรายการเพิกถอน การเพิกถอนที่ไม่เสร็จสิ้นภายในงบประมาณ 4 วินาทีจะถูกบันทึกไว้ในเครื่องและจะดำเนินการต่อด้วยคำสั่งถัดไป โดยไม่ต้องอยู่ภายใต้ขีดจำกัดการควบคุมปริมาณการออก 12 ชั่วโมง เมื่อคีย์กลายเป็นการอนุญาตที่ต้องการอีกครั้ง การเพิกถอนจะถูกเพิกถอนบนอุปกรณ์ที่ถูกเพิกถอนสำเร็จเท่านั้น
• **Root บันทึกจะถูกสร้างขึ้นโดยอัตโนมัติ ** เมื่อบัญชีผู้ดูแลระบบขั้นสูงถูกสร้างขึ้น (register/บัญชีแรกในพื้นที่ทำงาน) หรือการเข้าสู่ระบบผู้ดูแลระบบขั้นสูงในภายหลัง หากไม่มีบันทึกรากบน Exchange ไคลเอนต์ของผู้ดูแลระบบขั้นสูง (CLI / Web / Android) จะเผยแพร่คีย์ของตัวเองเป็นรูทในเครื่อง และส่งคำเชิญ 90 วันทันที หลังจากนั้น เมื่อคำเชิญหายไปหรือจะหมดอายุภายใน 30 วัน คำเชิญจะถูกรีเฟรชพร้อมกับการควบคุมการออก remote-cli seal root --publish ยังคงสามารถดำเนินการได้ด้วยตนเอง

การตั้งค่าครั้งเดียว

1. ผู้ดูแลระบบระดับสูงลงทะเบียนหรือล็อกอินเข้าสู่ไคลเอนต์ใดๆ: รูทจะถูกสร้างขึ้นและประกาศโดยอัตโนมัติ (CLI พิมพ์พรอมต์บน stderr; คอนโซลจะแสดงพรอมต์ขึ้นมา)
2. เก็บคีย์ส่วนตัวของรูทไว้ (เลือกอย่างใดอย่างหนึ่งหรือทั้งสองอย่าง):
   • เพียงเก็บไว้เองและไม่อัปโหลดอะไรเลย: remote-cli seal root --export root.rsk (ไฟล์ 0600; - ส่งออกไปยัง stdout) หรือ "ส่งออกคีย์ส่วนตัวรูท" ในคอนโซล
   • การตั้งค่าการสำรองข้อมูลบนคลาวด์ด้วยตนเอง: remote-cli seal backup หรือคอนโซล "Root Private Key Cloud Backup" รหัสผ่านสามารถเว้นว่างไว้ได้ แต่หากรหัสผ่านว่างเปล่าหรือคาดเดาง่ายเกินไป Exchange จะสามารถปลดล็อกคีย์ส่วนตัวรูทและควบคุมอุปกรณ์ทั้งหมดได้
3. ตราบใดที่อุปกรณ์รองรับเซสชันที่ปิดผนึกและเชื่อมต่อกับ Exchange อุปกรณ์จะแก้ไขรูท (TOFU) โดยอัตโนมัติ แนวทางที่เชื่อถือได้มากขึ้นคือตั้งค่า remote-agent seal root <根公钥> บนอุปกรณ์ก่อนออนไลน์
4. สมาชิกใหม่จะลงทะเบียนคีย์สาธารณะของตนหลังจากเข้าสู่ระบบ การอนุมัติอัตโนมัติจะถูกเปิดใช้งานตามค่าเริ่มต้นใน CLI, Web และ Android และไคลเอนต์รูทจะลงนามโดยตรง หากการอนุมัติอัตโนมัติปิดอยู่: มุมมอง remote-cli seal pending, remote-cli seal approve --all (หรือคอนโซล "อนุมัติ") จะออกทันทีหลังจากการอนุมัติ

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 关闭自动批准（保持开启较弱）

เปลี่ยนเป็นเครื่องอื่น/เปลี่ยนรูท

• ใช้รูทบนอุปกรณ์อื่น: หลังจากที่ผู้ดูแลระบบระดับสูงเข้าสู่ระบบแล้ว หากเครื่องไม่มีรูทที่เผยแพร่และมีการสำรองข้อมูลบนคลาวด์ rsb1. บน Exchange, CLI / Web / Android จะทำให้ ** พยายามกู้คืนโดยอัตโนมัติ** (ดู "การกู้คืนอัตโนมัติเมื่อเข้าสู่ระบบ") มิฉะนั้น ไคลเอนต์จะแจ้งให้นำเข้าด้วยตนเอง: seal root --import <文件|-> วาง rsk1. ในคอนโซล จากนั้น "นำเข้าคีย์ส่วนตัวรูท" หรือกู้คืนข้อมูลสำรองที่เข้ารหัสจาก Exchange (seal restore / คอนโซล "กู้คืนจาก Exchange") สิ่งที่นำเข้าคือรูทปัจจุบัน และติดตั้งบนเครื่องท้องถิ่นเท่านั้นโดยไม่มีการเปลี่ยนแปลงบันทึกใดๆ
• Rotation: seal root --rotate (Console "สร้างรูทใหม่และหมุน") หรือนำเข้าคีย์ rsk1. ที่เป็น ** แตกต่างจากรูทปัจจุบัน** เมื่อเครื่องโลคัลเก็บรูทปัจจุบันไว้ ไคลเอ็นต์จะใช้รูทเก่าเพื่อลงนามบันทึกการหมุน rsx1. ร่วมกับ rsr1. PUT /api/seal/root ใหม่ Exchange จะพุชไปที่อุปกรณ์ออนไลน์ และอุปกรณ์จะตรวจสอบว่าการหมุนได้รับการลงนามโดยรูทคงที่ จากนั้นจึงเปลี่ยนเป็นรูทใหม่ และอุปกรณ์ออฟไลน์จะได้รับในครั้งถัดไปที่เชื่อมต่อ สมาชิกที่ได้รับอนุมัติโดยรูทเก่าจะถือว่าได้รับการอนุมัติบนเครื่องนี้ต่อไป จากนั้นการอนุญาตของสมาชิกทั้งหมดจะถูกลงนามอีกครั้งด้วยรูทใหม่ (90 วัน) โลคัลคีย์เก่ายังคงอยู่ seal-identity.<毫秒>.previous.pk8 โปรดส่งออกใหม่หรือสำรองข้อมูลรูทใหม่หลังจากการหมุนเวียน
• ** รูทเก่าหายไป:** ไม่สามารถลงนามบันทึกการหมุนเวียนได้ ลูกค้าจะยังคงโฆษณารูทใหม่ แต่อุปกรณ์ที่มีการปักหมุดรูทเก่าจะไม่ยอมรับมัน ต้องดำเนินการ remote-agent seal root <新根公钥> ในแต่ละอุปกรณ์ และ agent จะรีสตาร์ท
• การส่งมอบผู้ดูแลระบบระดับสูง: โปรดดู "การส่งมอบผู้ดูแลระบบขั้นสูง = การส่งมอบใบรับรองหลัก" เพียงเปลี่ยนบทบาทของบัญชีไม่เพียงพอ อุปกรณ์จะเชื่อถือคีย์ส่วนตัวของรูท

กู้คืนคีย์ส่วนตัวรูทโดยอัตโนมัติเมื่อเข้าสู่ระบบ

หลังจากที่ผู้ดูแลระบบขั้นสูงเข้าสู่ระบบสำเร็จแล้ว ** ก่อนที่จะสร้างข้อมูลประจำตัวที่ปิดผนึกในเครื่อง**, CLI / Web Console / Android Console จะใช้ตารางการตัดสินใจเดียวกัน (Rust decide_auto_restore, JS decideAutoRestore) เพื่อพยายามกู้คืนรูทของเวิร์กสเปซที่เผยแพร่จากการสำรองข้อมูล Exchange rsb1.:

1.Skip: ไม่ใช่ผู้ดูแลระบบระดับสูง เครื่องมีคีย์เดียวกันกับรูทที่เผยแพร่อยู่แล้ว การสำรองข้อมูลบนคลาวด์ถูกปิด (CLI: REMOTE_SEAL_CLOUD_BACKUP=0; เว็บ: localStorage.seal.cloudBackup=off; Android: SecureStore remote.seal.cloudBackup=off); ไม่มีการเผยแพร่รูทบน Exchange 2.ดึงข้อมูลสำรอง: GET /api/seal/backup (จำกัดด้วยจำนวนครั้งต่อชั่วโมง) เมื่อไม่มีการสำรองข้อมูล ระบบจะแจ้งว่ารูทอยู่ที่อื่นและไม่บล็อกการเข้าสู่ระบบ 3.** พยายามเงียบด้วยรหัสผ่านว่างเปล่า:** ถอดรหัสด้วยสตริงว่างก่อน เมื่อดำเนินการสำเร็จและคีย์สาธารณะที่ถอดรหัสแล้วเท่ากับรูทที่เผยแพร่ และเครื่องไม่มีคีย์อื่น คีย์ดังกล่าวจะถูกโหลดลงในเครื่องและแก้ไขเป็นรูทของพื้นที่ทำงาน 4. Oมิฉะนั้นรหัสผ่านจะได้รับแจ้ง: CLI พยายามอีกครั้ง REMOTE_SEAL_BACKUP_PASSPHRASE อินพุตจะถูกซ่อนอยู่ใน TTY; Web/Android จะส่งเฉพาะคำแนะนำ non-blocking เท่านั้น โปรดป้อนรหัสผ่านบนหน้าซีลแล้วคลิก "กู้คืนจาก Exchange" กล่องโต้ตอบการบล็อกไม่ปรากฏขึ้นและการเข้าสู่ระบบจะเสร็จสมบูรณ์ตามปกติ 5.Security Boundary: ห้ามเขียนทับคีย์ที่ปิดผนึกอื่นที่มีอยู่แล้วในเครื่องนี้โดยไม่แจ้งให้ทราบ (การกู้คืนต้องใช้ seal restore --force หรือคอนโซลเพื่อยืนยัน) กุญแจสาธารณะที่ถอดรหัสจะต้องเท่ากับรูทที่เผยแพร่ จะมีการเตือนเฉพาะความล้มเหลวและการเข้าสู่ระบบจะไม่เกิดขึ้น รหัสผ่าน เมล็ดพืช หรือข้อความเข้ารหัส rsb1. จะไม่ถูกพิมพ์ 6.คำเตือนความเสี่ยง (ไม่ปิดกั้น): หลังจากติดตั้งรูทแล้ว ระบบจะแจ้ง "เครื่องหลายเครื่องที่ยึดรูทไว้จะเพิ่มความเสี่ยงของการรั่วไหล"; หากปลดล็อครหัสผ่านที่ว่างเปล่าสำเร็จ ระบบจะแจ้งว่า Exchange สามารถปลดล็อคคีย์ส่วนตัวรูทได้

การส่งมอบผู้ดูแลระบบระดับสูง = การส่งมอบรูทคีย์

บทบาทของบัญชีผู้ดูแลระบบขั้นสูงและรูทพื้นที่ทำงานที่อุปกรณ์ไว้วางใจจะแยกจากกัน การโอนบทบาทเพียงอย่างเดียวไม่ได้ทำให้ผู้ดูแลระบบระดับสูงคนใหม่ได้รับคีย์ส่วนตัวรูทหรือความน่าเชื่อถือของอุปกรณ์ การโอนย้ายจะถ่ายโอนคีย์ส่วนตัว root ตามด้วยการหมุนเวียนทันทีเพื่อทำให้คีย์ที่ถ่ายโอนเป็นโมฆะ

1. ผู้ดูแลระบบขั้นสูงปัจจุบันเริ่มต้นการถ่ายโอนในขณะที่ไคลเอ็นต์ภายในเครื่องเก็บ root ที่เผยแพร่: POST /api/superadmin/transfer โดยมีเนื้อความ {operator_id, root_handover?} root_handover เป็นแพ็คเกจ rsb1. ที่เข้ารหัสด้วยข้อความรหัสผ่าน โดยใช้อัลกอริธึมการสำรองข้อมูลบนคลาวด์ (Argon2id, 64 MiB, t=3, p=1 และ ChaCha20-Poly1305) ข้อความรหัสผ่านอาจว่างเปล่า CLI: remote-cli seal handover <账号>. เมื่อถ่ายโอนบทบาทผู้ดูแลระบบขั้นสูงใน Web/Android Console ไคลเอ็นต์ที่ถือคีย์ส่วนตัว root จะพร้อมท์ให้ใส่ข้อความรหัสผ่านเผื่อเลือกและรวมแพ็คเกจนี้ด้วย
2. Exchange ** บันทึกเท่านั้น ไม่ใช่ถอดรหัส** จะตรวจสอบว่าคำนำหน้าคือ rsb1. หรือ rsk1. ยาวไม่เกิน 16384 และประกอบด้วยอักขระที่ปลอดภัยต่อ URL แบบ ASCII เท่านั้น เมื่อไม่มี root_handover ในคำขอ ให้ลบแพ็คเกจการส่งมอบที่เหลือของเวิร์กสเปซ
3. ผู้ดูแลระบบขั้นสูงคนใหม่ GET /api/superadmin/handover ดึงข้อมูล {blob, from_operator, created_at} (หากไม่ใช่ 404) ปลดล็อกด้วยรหัสผ่าน ติดตั้งลงในเครื่องภายในเครื่อง จากนั้นดำเนินการหมุนเวียนแบบเดียวกับ "สร้างรูทใหม่และหมุน": รูทเก่าออกปัญหา rsx1. และเผยแพร่รูทใหม่ ในที่สุด DELETE /api/superadmin/handover CLI: remote-cli seal accept-handover. หน้าประทับตราของคอนโซลจะแสดง "รับการส่งมอบคีย์ส่วนตัวของรูท" เมื่อมีแพ็คเกจการส่งมอบ
4. **Rotation ทำให้สำเนาเก่าไม่ถูกต้อง ** สิ่งที่ส่งมอบคือรูทก่อนการหมุน อุปกรณ์ออนไลน์จะสลับไปใช้รูทใหม่ก็ต่อเมื่อมีการลงนามบันทึกการหมุนโดยรูทเก่าที่พวกเขาเชื่อถืออยู่แล้ว คีย์ส่วนตัวเก่าที่อยู่ในมือของรุ่นก่อนไม่สามารถลงนามในการอนุญาตรูทใหม่ได้ และไม่สามารถเปลี่ยนรูทของอุปกรณ์ที่ถูกแปลงได้ ก่อนที่การหมุนจะเสร็จสิ้น รหัสผ่านว่างหรือรหัสผ่านที่ไม่รัดกุม rsb1. ยังสามารถปลดล็อคได้ กรุณาส่งรหัสผ่านแยกต่างหาก

นอกแบนด์: เมื่อคุณไม่ต้องการใส่ไซเฟอร์เท็กซ์ลงใน Exchange ให้ใช้ remote-cli seal handover <账号> --out-of-band สำหรับ CLI เอาต์พุตมาตรฐานมี rsb1. เพียงบรรทัดเดียว และคำขอถ่ายโอนไม่มี root_handover ให้บรรทัดและรหัสผ่านนี้แก่อีกฝ่ายผ่านช่องทางอื่น และอีกฝ่ายจะดำเนินการ remote-cli seal accept-handover <那一行> คลิกยกเลิกบนพร้อมท์รหัสผ่านในคอนโซล (Android จะโอนบัญชีเท่านั้น) นอกจากนี้ยังถ่ายโอนบทบาทเท่านั้นและไม่ได้อัปโหลดคีย์ส่วนตัวของรูท ยังคงต้องส่งมอบคีย์ส่วนตัวรูทแยกต่างหาก (ส่งออก rsk1. หรือ rsb1. นอกแบนด์)

การจับมือและรูปแบบเส้น

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} ลายเซ็นครอบคลุม ["remote-seal-v1/hello", v, device_id, operator_key, operator_ephemeral, nonce, grant.sig|""] (อาร์เรย์ JSON เช่น ไบต์แบบบัญญัติ)
• ลายเซ็นรากบันทึก rsr1. ครอบคลุม ["remote-seal-v1/workspace-root", v, workspace_id, root_key, issued_at_ms]; การหมุน rsx1. = {v, workspace_id, old_root, new_root, issued_at_ms, sig} ลงนามโดย old_root บน ["remote-seal-v1/root-rotation", v, workspace_id, old_root, new_root, issued_at_ms] Exchange → agent: {"type":"seal_root","token":"rsr1.…","rotation":"rsx1.…"?} (ยอมรับเฉพาะข้อความควบคุมข้อความที่ชัดเจนจาก Exchange ซึ่งไม่ถูกต้องในช่องสัญญาณ)
• accept = {v, device_key, device_ephemeral, nonce, level, sig} ลายเซ็นครอบคลุม ["remote-seal-v1/accept", v, device_id, operator_key, operator_ephemeral, hello.nonce, hello.sig, device_key, device_ephemeral, nonce, level] Exchange ที่เปลี่ยนเป็น level จะทำให้ลายเซ็นใช้ไม่ได้
• คีย์เซสชัน: 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 = ไบต์ของช่องสัญญาณ (0 ข้อความ / 1 ไบนารี่) ‖ สามศูนย์ไบต์ ‖ ตัวนับ u64 (ปลายใหญ่) ตัวนับในแต่ละทิศทางและแต่ละช่องจะเพิ่มขึ้นอย่างเข้มงวดหนึ่งจาก 0; ความคลาดเคลื่อนใดๆ จะปิดเซสชันโดยตรง
• ข้อความ: {"counter":n,"ciphertext":"<base64>"}. ข้อความที่ชัดเจนคือ JSON: โอเปอเรเตอร์ → อุปกรณ์คือ SealedRequest (ข้อความ DeviceDown ที่มีอยู่ หรือข้อความการจัดการรูท seal_policy_get / seal_policy_set {mode?, root_key?, revoke?, unrevoke?}) อุปกรณ์ → โอเปอเรเตอร์คือ SealedResponse (ข้อความ DeviceUp ที่มีอยู่หรือ seal_policy) เลเยอร์ด้านใน session_id ถูกเขียนใหม่เป็นหมายเลขช่องสัญญาณโดย agent
• เฟรมไบนารี่: StreamKind::Sealed = 4, เพย์โหลด = counter(u64 BE) ‖ AEAD(inner_kind ‖ bytes), inner_kind คือ 1/2/3 (stdout/stderr/PTY)
• แต่ละเซสชันที่ปิดผนึกมีการดำเนินการ one (หนึ่ง exec, หนึ่ง PTY, หนึ่งการถ่ายโอนไฟล์...) ตามโมเดลเซสชัน 1:1 ข้อความการยุติถูกเข้ารหัสโดย agent และทำเครื่องหมาย last:true ในเลเยอร์ด้านนอก Exchange เผยแพร่การตรวจสอบการกำหนดเส้นทางและทดแทนข้อมูลตามลำดับ โดยไม่จำเป็นต้องเข้าใจเนื้อหา
• close_session → sealed_close{detach:false} (สิ้นสุด); การตัดการเชื่อมต่อการทำงานและการบำรุงรักษา → sealed_close{detach:true} (ตัดสินโดย agent: ให้กด exec ค้างไว้เท่านั้น ถอดออก, ยุติอื่นๆ)
• ขนาดสูงสุด: ประมาณ 2.8 MiB สำหรับ ciphertext base64 (รองรับภาพหน้าจอ 2 MiB Android) บรรจุภัณฑ์ด้านนอก MAX_SEALED_WIRE

บรรทัดการป้องกันฝั่ง Agent: ข้อความธรรมดาที่เป็นของหมายเลขเซสชันที่ปิดผนึกในคิวขาออกจะถูกเข้ารหัสหรือละทิ้งเท่านั้น และหมายเลขจะถูกแยกออกอย่างถาวรหลังจากเซสชันสิ้นสุด (เอาต์พุตล่าช้าของกระบวนการระงับจะถูกยกเลิก แทนที่จะถูกส่งในรูปแบบข้อความธรรมดา) งานการระงับที่เริ่มต้น/แนบผ่านเซสชันที่ปิดผนึกจะไม่ปรากฏในรายการของเส้นทางเก่า และไม่สามารถแนบ/หาง/แมว/ฆ่าโดยเส้นทางเก่าได้

ส่งออกและสำรองข้อมูลคีย์ส่วนตัวรูท

คีย์ส่วนตัวรูทสามารถควบคุมอุปกรณ์ทั้งหมดในพื้นที่ทำงาน วิธีการจัดเก็บข้อมูลถูกกำหนดโดยผู้ดูแลระบบขั้นสูง Console จะอัปโหลดการสำรองข้อมูลข้อความรหัสผ่านว่างตามค่าเริ่มต้น ลบออกเพื่อปิดการใช้งานการบันทึกอัตโนมัติ:

• **Export (ไม่มีการอัปโหลด): ** rsk1. + base64url (ไม่มีช่องว่างภายใน) เมล็ด 32 ไบต์ CLI seal root --export FILE|- (ไฟล์ 0600), คอนโซล "ส่งออกคีย์ส่วนตัวของรูท" (เว็บจะแสดงในกล่องอินพุต Android จะถูกคัดลอกไปยังคลิปบอร์ด) ใครก็ตามที่ได้รับมันสามารถควบคุมอุปกรณ์ทั้งหมดได้
• **Eเข้ารหัสการสำรองข้อมูลไปยัง Exchange (อัตโนมัติใน Console, คู่มือใน CLI): ** เฉพาะผู้ดูแลระบบระดับสูงเท่านั้นที่สามารถอัปโหลดได้หากโลคัลคีย์เป็นรูทที่เผยแพร่ ไซเฟอร์เท็กซ์เป็นโทเค็น rsb1. เวอร์ชัน (JSON ที่เข้ารหัส base64url สูงสุด 4,096 อักขระ) คีย์ได้มาจากรหัสผ่านโดย Argon2id และพารามิเตอร์การผลิตได้รับการแก้ไขที่หน่วยความจำ 64 MiB การวนซ้ำ 3 และความขนาน 1 ซึ่งเขียนในโทเค็น Salt คือ 16 ไบต์ nonce ของ ChaCha20-Poly1305 คือ 12 ไบต์ และสร้างขึ้นแบบสุ่มสำหรับการสำรองข้อมูลแต่ละครั้ง ข้อมูลการรับรองความถูกต้องเพิ่มเติมคือ remote-seal-v1/key-backup:{version}:{public_key} หากเวอร์ชัน คีย์สาธารณะ หรือข้อความเข้ารหัสมีการเปลี่ยนแปลง การตรวจสอบจะล้มเหลว หลังจากปลดล็อคแล้ว จะต้องตรวจสอบว่ากุญแจสาธารณะที่ได้มาจาก Seed นั้นเท่ากับกุญแจสาธารณะในโทเค็น ตัวถอดรหัสจะปฏิเสธพารามิเตอร์ที่อ่อนแอเกินไปหรือใหญ่เกินไปก่อนที่จะรัน Argon2 (หน่วยความจำ 8 KiB–256 MiB, การถอดรหัสการผลิตอย่างน้อย 64 MiB; การวนซ้ำ 1–8, การผลิตอย่างน้อย 3; ความขนานสามารถมีได้เพียง 1 เท่านั้น)
• **รหัสผ่านเป็นทางเลือก ไม่บังคับความเข้มงวด ** รหัสผ่านที่ว่างเปล่ายังใช้ Argon2id (รหัสผ่านเป็นสตริงว่าง) และรูปแบบก็เหมือนกัน ลูกค้าแจ้งเท่านั้น: เมื่อรหัสผ่านว่างเปล่าหรืออ่อนแอ (น้อยกว่า 12 ตัวอักษร, หมวดหมู่อักขระน้อยเกินไป, ซ้ำ, รหัสผ่านทั่วไป), CLI / เว็บ / Android จะเตือนอย่างชัดเจน: **Exchange (หรือบุคคลที่สามารถอ่านฐานข้อมูลได้) สามารถปลดล็อคคีย์ส่วนตัวรูทและควบคุมอุปกรณ์ทั้งหมด ** Rust และ JavaScript ใช้ ชุดกฎพร้อมท์เดียวกันและเวกเตอร์ทดสอบชุดเดียวกัน (รวมถึงเวกเตอร์รหัสผ่านว่างเปล่า)

PUT / GET / DELETE /api/seal/backup ให้บริการเฉพาะบัญชีเข้าสู่ระบบปัจจุบันเท่านั้น PUT และ GET อนุญาตเฉพาะผู้ดูแลระบบระดับสูงเท่านั้น เนื้อหาคำขอคือ {blob} Exchange ตรวจสอบคำนำหน้าและความยาว rsb1. และไม่เคยถอดรหัส GET แต่ละบัญชี แต่ละกระบวนการ สูงสุด 5 ครั้งต่อชั่วโมง หากเกิน จะส่งกลับ 429; สิ่งนี้จะทำให้การคาดเดาออนไลน์ช้าลงเท่านั้น และรหัสผ่านที่ไม่รัดกุมสามารถหมดลงแบบออฟไลน์ได้หลังจากที่คัดลอกไลบรารีแล้ว การอ่าน การเขียน และการลบจะถูกตรวจสอบ และรายละเอียดเป็นเพียงจำนวนไบต์เท่านั้น

• CLI: remote-cli seal backup (ซ่อนการป้อนรหัสผ่านสองครั้ง คุณสามารถป้อนและปล่อยว่างไว้ได้โดยตรง หรือ --passphrase-stdin) remote-cli seal restore (เพิ่ม --force เมื่อมีคีย์อื่น และเก็บคีย์เก่าไว้เป็น seal-identity.<毫秒>.previous.pk8) หลังจากการกู้คืน ให้แก้ไขเป็นรูทเวิร์กสเปซของเครื่อง นอกจากนี้ จะมีการพยายามกู้คืนโดยอัตโนมัติเมื่อเข้าสู่ระบบ (ดูหัวข้อก่อนหน้า) อย่าพิมพ์คีย์ส่วนตัว รหัสผ่าน หรือข้อความเข้ารหัส
• เว็บ Console: คีย์ส่วนตัวรูทจะต้องสามารถส่งออกได้ เมื่อผู้ดูแลระบบระดับสูงสร้างรูท เบราว์เซอร์ที่เก็บคีย์ WebCrypto ที่ไม่สามารถส่งออกได้จะใช้เมล็ดพันธุ์ในเครื่องใน IndexedDB เป็นรูทแทน บูตสแตรปเข้าสู่ระบบจะดำเนินการต่อโดยอัตโนมัติก่อนที่จะสร้างข้อมูลประจำตัว localStorage.seal.cloudBackup=off สามารถปิดได้
• Android Console: เมล็ดอยู่ในร้านค้าที่ปลอดภัยสำหรับงานแสดงสินค้า bootstrapSeal จะกู้คืนโดยอัตโนมัติก่อนเช่นกัน remote.seal.cloudBackup=off สามารถปิดได้

ใช้

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: การทำงานของอุปกรณ์ทั้งหมดใช้เซสชันที่ปิดผนึกดั้งเดิม: คำสั่ง, Hold List/kill/tail/cat, เทอร์มินัล, ไฟล์, ภาพหน้าจอและอินพุต (Android/เดสก์ท็อป), โครงสร้างอินเทอร์เฟซ, เซ็นเซอร์, ubus, บันทึกระบบ และ การอัปเดตตัวเองทั้งหมดต้องผ่านอุโมงค์ที่ปิดสนิท "🔒 การเข้ารหัสจากต้นทางถึงปลายทาง" ปรากฏบนหน้า รายละเอียดอุปกรณ์เว็บหรือการตั้งค่า Android → แผง "การเข้ารหัสจากต้นทางถึงปลายทาง" เทียบเท่ากับ CLI: แสดงคีย์สาธารณะ/ลายนิ้วมือในเครื่อง, รูทพื้นที่ทำงาน (ผู้ดูแลระบบขั้นสูง: ส่งออก/นำเข้า/หมุนคีย์ส่วนตัวรูท, รับการส่งมอบคีย์ส่วนตัวรูท, อนุมัติคีย์สาธารณะใหม่), ดู/แก้ไขคีย์อุปกรณ์และนโยบายการเพิกถอน (ต้องใช้รูท), การอนุญาตปัญหา (โทเค็นเอาท์พุต rsg1., CLI สามารถทำได้โดยตรง seal import-grant) การอนุญาตการนำเข้า รหัสสาธารณะของอุปกรณ์ที่เชื่อถือได้ และการสำรองข้อมูลบนคลาวด์อัตโนมัติของคีย์ส่วนตัวรูท (รหัสผ่านสามารถเว้นว่างได้ และ Exchange จะได้รับคำเตือนอย่างชัดเจนหากรหัสผ่านไม่รัดกุมและสามารถปลดล็อคได้) เมื่อเชื่อมต่อกับลายนิ้วมือของอุปกรณ์แบบคงที่ (TOFU) เป็นครั้งแรก การเปลี่ยนแปลงลายนิ้วมือในภายหลังจะถูกปฏิเสธโดยตรงและขอให้ตรวจสอบ สมาชิกสามัญจะมีปุ่มที่แตกต่างกันสามปุ่มบน CLI เบราว์เซอร์ และโทรศัพท์มือถือ หลังจากการลงทะเบียนแต่ละครั้ง ไคลเอนต์รูทจะออกให้ตามบทบาทของพวกเขา หากผู้ดูแลระบบขั้นสูงต้องการรูทบนอุปกรณ์หลายเครื่อง เขาหรือเธอสามารถอัปโหลดการสำรองรหัสผ่านและกู้คืนข้อมูลโดยอัตโนมัติเมื่อเข้าสู่ระบบในอุปกรณ์ใหม่ หรือนำเข้าคีย์ส่วนตัวรูทลงในแต่ละอุปกรณ์

บนอุปกรณ์: remote-agent seal show | root <key> | forget-root | revoke <key> (รีสตาร์ท agent หลังจากการเปลี่ยนแปลงในเครื่อง การเปลี่ยนแปลงผ่านเซสชัน seal policy ที่ปิดผนึกจะมีผลทันที)

พฤติกรรมเริ่มต้น

• อุปกรณ์ใหม่ปักหมุดรูทพื้นที่ทำงานในการเชื่อมต่อกับ Exchange (TOFU) รูทและสิทธิ์ที่ลงนามแล้วอนุญาตการดำเนินการ หาก Exchange อาจไม่น่าเชื่อถือในการเชื่อมต่อครั้งแรก ให้เรียกใช้ remote-agent seal root <key> ในเครื่องก่อนที่จะนำอุปกรณ์ออนไลน์
• คีย์ข้อมูลประจำตัวที่ไม่พร้อมใช้งานหรือนโยบายที่เสียหายล้มเหลวในการปิด ซ่อมแซมคีย์และนโยบายในเครื่องก่อนเชื่อมต่อใหม่