Keyhive - การควบคุมการเข้าถึงแบบ local-first

• Keyhive เป็นโครงการวิจัยเพื่อสร้าง ระบบควบคุมการเข้าถึงแบบ local-first ที่ทำงานแบบออฟไลน์ได้โดยไม่ต้องมีเซิร์ฟเวอร์กลาง และเป็นความพยายามในการ นำความปลอดภัยระดับ Signal มาใช้กับการทำงานร่วมกันบนเอกสาร
• ทำให้การควบคุมการเข้าถึงข้อมูลระหว่างการทำงานร่วมกันมีความปลอดภัยได้ผ่าน โมเดลการมอบสิทธิ์ (Capability Model) ที่ซิงก์ได้แม้อยู่ในสภาพแวดล้อมแบบกระจาย, Group Management CRDT และ E2EE แบบอิงความเป็นเหตุเป็นผล (Causal Keys)
• โปรโตคอลเข้ารหัสหลัก BeeKEM รองรับผู้ใช้ระดับหลายพันคน พร้อมรับประกัน Forward Secrecy และ Post-Compromise Security โดยไม่ต้องพึ่งเซิร์ฟเวอร์กลาง
• เลเยอร์การซิงก์ของ Keyhive อย่าง Beelay ใช้ การซิงก์เซตแบบอิง RIBLT และ วิธีบีบอัด Sedimentree เพื่อปรับปรุงความเร็วในการซิงก์เอกสาร local-first ขนาดใหญ่
• ผ่านโครงการนี้ Ink & Switch นำเสนอ เทคโนโลยีพื้นฐานสำหรับแพลตฟอร์มการทำงานร่วมกันอย่างปลอดภัยที่ไม่ต้องพึ่งเซิร์ฟเวอร์ และมีเป้าหมายขยายระบบนิเวศซอฟต์แวร์แบบ offline-first

---

ภาพรวมของ Keyhive

• Keyhive เป็นงานวิจัยเพื่อทำให้ การควบคุมการเข้าถึงข้อมูลการทำงานร่วมกันในสภาพแวดล้อม local-first เกิดขึ้นได้โดยไม่ต้องใช้คลาวด์เซิร์ฟเวอร์
  • การยืนยันตัวตนบนคลาวด์แบบดั้งเดิม (เช่น OAuth) พึ่งพาการตรวจสอบสิทธิ์ผ่านเซิร์ฟเวอร์กลาง แต่ในโมเดล local-first ข้อมูลและสิทธิ์ต้องเคลื่อนที่ไปด้วยกัน
  • เพื่อสิ่งนี้ Keyhive จึงใช้การออกแบบแบบ การมอบสิทธิ์ (capability) และสร้าง เลเยอร์การยืนยันตัวตนและการเข้ารหัสแบบกระจายศูนย์
• เป้าหมายคือการทำให้เกิด ความปลอดภัยของการทำงานร่วมกันแบบกระจายศูนย์อย่างสมบูรณ์ โดยยังคง ประสบการณ์ใช้งานที่เป็นมิตรกับผู้ใช้ แบบ Google Docs หรือ GitHub

ปรัชญาการออกแบบและองค์ประกอบ

• Keyhive ถูกออกแบบบนหลักการว่า เลเยอร์ควบคุมการเข้าถึงต้องมีอยู่ก่อนเลเยอร์ข้อมูล
  • ส่งผลให้โครงสร้างการจัดเก็บหรือการซิงก์ต้องสอดคล้องกับวิธีการเข้ารหัสและการจัดการสิทธิ์ด้วย
• องค์ประกอบหลัก 3 ส่วน:
  1. Convergent Capabilities: โมเดลสิทธิ์แบบใหม่ที่เหมาะกับ CRDT และสามารถพิสูจน์การมอบสิทธิ์ระหว่างเอนทิตีได้ด้วยวิทยาการเข้ารหัส
  2. Group Management CRDT: จัดการการเพิ่ม/ลบกลุ่มและการเพิกถอนสิทธิ์ได้โดยไม่ต้องมีเซิร์ฟเวอร์กลาง
  3. E2EE with Causal Keys: จัดการคีย์ตามโครงสร้างเชิงเหตุเป็นผลของเอกสารเพื่อให้การเข้ารหัสมีประสิทธิภาพ

Convergent Capabilities

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

BeeKEM: โปรโตคอลตกลงกุญแจกลุ่ม

• BeeKEM เป็นโปรโตคอล Continuous Group Key Agreement (CGKA) ที่ทำงานได้โดยไม่มีเซิร์ฟเวอร์กลาง
  • สืบทอดโครงสร้างของ TreeKEM พร้อมปรับปรุงให้ทำงานได้ด้วยเพียง ลำดับเชิงเหตุเป็นผล (Causal Order)
  • ออกแบบบนพื้นฐานการเข้ารหัสมาตรฐาน โดยใช้เพียง การแลกเปลี่ยนกุญแจ Diffie-Hellman และ ฟังก์ชันแฮช BLAKE3
• คุณสมบัติหลัก:
  • จัดการทุกงานในสถานะแบบกระจายได้ ไม่ว่าจะเป็นการเพิ่ม/ลบสมาชิกกลุ่ม การแก้ความขัดแย้งของการอัปเดตพร้อมกัน หรือการกู้คืนโหนดว่าง
  • เมื่อเกิดความขัดแย้งจากการทำงานพร้อมกัน จะคงความปลอดภัยผ่านอัลกอริทึมผสาน “Conflict Key”
  • โดยทั่วไปมีประสิทธิภาพระดับลอการิทึม และในกรณีเลวร้ายที่สุดเป็นเชิงเส้น

Beelay: โปรโตคอลซิงก์แบบลดความเชื่อใจ

• Beelay เป็น โปรโตคอลแบบ RPC สำหรับซิงก์ข้อมูลและข้อมูลสิทธิ์ของ Keyhive โดยเซิร์ฟเวอร์ทำหน้าที่เพียงส่งต่อข้อมูลที่เข้ารหัสแล้ว
  • ข้อความได้รับการยืนยันด้วย ลายเซ็น Ed25519 และมีการป้องกัน replay attack กับ การโจมตีแบบคนกลาง (PITM) ในตัว
• ขั้นตอนการทำงานหลัก:
  • ใช้ RIBLT (Rateless Invertible Bloom Lookup Table) ในการคำนวณความต่างของเซต เพื่อให้ซิงก์ข้อมูลปริมาณมากได้รวดเร็ว
  • ซิงก์กราฟสมาชิกภาพ (ความสัมพันธ์ระหว่างกลุ่มและเอกสาร), สถานะคอลเลกชันเอกสาร และเนื้อหาเอกสารตามลำดับ
• ใช้โครงสร้าง Sedimentree เพื่อบีบอัดและรวมกราฟคอมมิตของ Automerge ช่วยลดแบนด์วิดท์เมื่อซิงก์เอกสารขนาดใหญ่

ลำดับการซิงก์

1. ซิงก์กราฟสมาชิกภาพ: ซิงก์ความสัมพันธ์ของกลุ่มและสิทธิ์
2. ซิงก์คอลเลกชันเอกสาร: ระบุเอกสารที่มีการเปลี่ยนแปลง
3. ซิงก์ CGKA: รวมการทำงานของ BeeKEM
4. ซิงก์เนื้อหาเอกสาร: ส่งข้อมูลแบบบีบอัดด้วย Sedimentree

• สำหรับการเปลี่ยนแปลงทั่วไป 1 รายการ สามารถซิงก์ทั้งหมดเสร็จสิ้นได้ด้วย การรับส่งแบบไป-กลับเพียง 2 ครั้ง

แผนในอนาคต

• ปัจจุบัน Keyhive เปิดเผยในสถานะ pre-alpha พร้อมอิมพลีเมนต์ด้วย Rust และมี binding สำหรับ WASM/TypeScript
  • keyhive_core: ระบบลายเซ็น การเข้ารหัส และการมอบสิทธิ์
  • beelay-core: เอนจินซิงก์ที่อิงข้อมูลเข้ารหัส
  • keyhive_wasm: แรปเปอร์สำหรับรองรับเบราว์เซอร์
• มีแผนเผยแพร่งานตรวจสอบความปลอดภัยและบทความด้านประสิทธิภาพในอนาคต โดยมุ่งสร้าง โมเดลมาตรฐานความปลอดภัย สำหรับระบบการทำงานร่วมกันแบบ local-first