Apple Private Cloud Compute: พรมแดนใหม่ของความเป็นส่วนตัวสำหรับ AI บนคลาวด์

 (security.apple.com)
1 คะแนน โดย GN⁺ 2024-06-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Apple Intelligence ได้นำ Private Cloud Compute(PCC) มาใช้เพื่อส่งคำขอที่ประมวลผลบนอุปกรณ์ได้ยากไปยัง foundation model ขนาดใหญ่ พร้อมชูการออกแบบที่ลดการเข้าถึงข้อมูลส่วนบุคคลให้น้อยที่สุดแม้อยู่บนคลาวด์
  • PCC ผสาน เซิร์ฟเวอร์ Apple silicon แบบปรับแต่งเฉพาะ, Secure Enclave, Secure Boot, Code Signing และ sandboxing เพื่อนำโมเดลความปลอดภัยระดับอุปกรณ์เข้าสู่ดาต้าเซ็นเตอร์
  • คำขอของผู้ใช้จะถูกเข้ารหัสโดยตรงด้วย public key ของโหนด PCC ที่ผ่านการตรวจสอบแล้ว และ load balancer หรือ privacy gateway จะไม่มีกุญแจสำหรับถอดรหัสคำขอ
  • เพื่อความสะดวกในการปฏิบัติการ ระบบตัด remote shell, interactive debugging และ logging อเนกประสงค์ที่ใช้กันทั่วไปออกไป และออกแบบให้มีเพียง log ที่ผ่านการตรวจสอบแล้วกับ metrics ที่จำกัดเท่านั้นที่ออกนอกโหนดได้
  • Apple วางแผนสร้าง AI บนคลาวด์ที่ตรวจสอบจากภายนอกได้ ผ่าน production software image, transparency log, research environment และ Apple Security Bounty

ปัญหาความเป็นส่วนตัวเมื่อ Apple Intelligence ย้ายขึ้นคลาวด์

  • Apple Intelligence คือระบบที่มอบความสามารถด้านปัญญาส่วนบุคคลบนพื้นฐาน generative model ให้กับ iPhone, iPad และ Mac
  • ความสามารถขั้นสูงที่ต้องใช้การอนุมานกับข้อมูลที่ซับซ้อนขึ้นจำเป็นต้องใช้ foundation model ที่ใหญ่กว่า และเพื่อการนี้ Apple จึงสร้าง Private Cloud Compute(PCC) ขึ้นมา
  • PCC คือระบบ cloud intelligence ที่ออกแบบมาสำหรับการประมวลผล AI ส่วนบุคคล โดยมีเป้าหมายไม่ให้ข้อมูลส่วนบุคคลของผู้ใช้ถูกเปิดเผยต่อใครก็ตาม รวมถึง Apple เอง
  • การประมวลผลบนอุปกรณ์ให้ข้อได้เปรียบด้านความปลอดภัยและความเป็นส่วนตัวของข้อมูลผู้ใช้
    • ข้อมูลที่มีอยู่เฉพาะบนอุปกรณ์ของผู้ใช้จะไม่ตกอยู่ในจุดโจมตีแบบรวมศูนย์
    • สำหรับข้อมูลบนคลาวด์ที่ละเอียดอ่อนที่สุด การเข้ารหัสแบบ end-to-end เป็นแนวป้องกันที่แข็งแกร่ง
    • ในบริการคลาวด์ที่การเข้ารหัสแบบ end-to-end ไม่เหมาะสม สามารถใช้การประมวลผลชั่วคราวหรือ identifier แบบสุ่มที่ไม่เกี่ยวข้องกันเพื่อพรางตัวตนของผู้ใช้ได้

ข้อจำกัดของโมเดลความปลอดภัย AI บนคลาวด์แบบเดิม

  • AI บนคลาวด์สามารถใช้ฮาร์ดแวร์ดาต้าเซ็นเตอร์ที่ทรงพลังและโมเดล machine learning ขนาดใหญ่ได้ แต่ต้องมี การเข้าถึงแบบไม่เข้ารหัส ต่อคำขอและข้อมูลส่วนบุคคลที่เกี่ยวข้อง
  • ด้วยเหตุนี้จึงไม่สามารถประมวลผลได้ด้วยการเข้ารหัสแบบ end-to-end อย่างสมบูรณ์เพียงอย่างเดียว และบริการ AI บนคลาวด์แบบเดิมจึงพึ่งพาวิธีรักษาความปลอดภัยคลาวด์แบบดั้งเดิม
  • แนวทางดั้งเดิมมีจุดอ่อนสามประการ
    • ตรวจสอบการรับประกันด้านความปลอดภัยและความเป็นส่วนตัวได้ยาก
      • แม้บริการจะระบุว่าไม่บันทึกข้อมูลผู้ใช้บางประเภท นักวิจัยก็ตรวจสอบได้ยาก
      • เวอร์ชันใหม่อาจเผลอบันทึกข้อมูลละเอียดอ่อนลง log หรือ load balancer ที่ terminate TLS อาจบันทึกคำขอของผู้ใช้จำนวนมากระหว่างการแก้ปัญหา
    • ให้ความโปร่งใสขณะรันไทม์ได้ยาก
      • บริการ AI บนคลาวด์โดยทั่วไปไม่เปิดเผย software stack ที่กำลังรันจริง
      • แม้จะใช้เฉพาะซอฟต์แวร์โอเพนซอร์ส ก็ยังไม่มีวิธีที่เผยแพร่ใช้งานอย่างแพร่หลายให้เครื่องผู้ใช้หรือเบราว์เซอร์ตรวจสอบได้ว่าซอฟต์แวร์ของบริการไม่ถูกแก้ไข
    • จำกัดการเข้าถึงด้วยสิทธิ์สูงอย่างเข้มงวดได้ยาก
      • SRE และผู้ดูแลระบบอาจใช้การเข้าถึงสิทธิ์สูงอย่าง SSH ได้ในกรณีระบบล่มหรือเหตุการณ์ร้ายแรง
      • ผู้ดูแลระบบอาจคัดลอกข้อมูลผู้ใช้ที่ละเอียดอ่อนขณะสำรองข้อมูลเซิร์ฟเวอร์ที่กำลังใช้งานอยู่ หรืออาชญากรอาจขโมย credential ของผู้ดูแลระบบเพื่อดึงข้อมูลผู้ใช้ไป

ข้อกำหนดการออกแบบ 5 ประการของ PCC

  • การคำนวณแบบไร้สถานะสำหรับข้อมูลผู้ใช้ส่วนบุคคล

    • PCC ต้องใช้ข้อมูลส่วนบุคคลที่ได้รับมาเพื่อวัตถุประสงค์ในการประมวลผลคำขอของผู้ใช้เท่านั้น
    • ข้อมูลต้องไม่ถูกส่งให้ใครนอกจากผู้ใช้ รวมถึงพนักงาน Apple
    • หลังส่งคำตอบกลับแล้ว ข้อมูลต้องไม่ถูกเก็บรักษาไว้ในรูปแบบใด ๆ รวมถึงเพื่อ log หรือ debugging

  • การรับประกันที่บังคับใช้ได้ทางเทคนิค

    • การรับประกันด้านความปลอดภัยและความเป็นส่วนตัวจะแข็งแกร่งที่สุดเมื่อสามารถจำกัดและวิเคราะห์องค์ประกอบสำคัญของทั้งระบบได้
    • การรับประกันหลักของ PCC ต้องไม่พึ่งพาองค์ประกอบภายนอก เช่น load balancer ที่ terminate TLS
    • ความต้องการด้านปฏิบัติการ เช่น การเก็บ server metrics และ error log ก็ต้องรองรับด้วยวิธีที่ไม่ลดทอนการคุ้มครองความเป็นส่วนตัว

  • ไม่มี privileged runtime access

    • PCC ต้องไม่มี interface สิทธิ์สูงที่ทำให้ Apple SRE เลี่ยงการรับประกันความเป็นส่วนตัวได้ แม้ระหว่างรับมือเหตุขัดข้อง
    • ต้องไม่รองรับวิธีโหลดซอฟต์แวร์เพิ่มเติมขณะรันไทม์เพื่อขยายขอบเขตการเข้าถึงสิทธิ์สูง

  • ไม่เจาะจงเป้าหมาย

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

  • ความโปร่งใสที่ตรวจสอบได้

    • นักวิจัยด้านความปลอดภัยต้องสามารถตรวจสอบด้วยความเชื่อมั่นสูงได้ว่าการรับประกันด้านความปลอดภัยและความเป็นส่วนตัวของ PCC สอดคล้องกับคำมั่นสาธารณะของ Apple
    • ต้องสามารถยืนยันได้ด้วยว่าซอฟต์แวร์ที่นักวิจัยตรวจสอบเป็นตัวเดียวกับที่กำลังรันอยู่ในสภาพแวดล้อม production ของ PCC

โหนด PCC และรากฐานความปลอดภัย

  • root of trust ของ PCC คือ PCC compute node ซึ่งเป็นฮาร์ดแวร์เซิร์ฟเวอร์ที่ผลิตแบบปรับแต่งเฉพาะ
  • โหนด PCC นำเทคโนโลยีความปลอดภัยฮาร์ดแวร์ที่ใช้ใน iPhone เข้าสู่ดาต้าเซ็นเตอร์
  • ระบบปฏิบัติการเป็นชุดย่อยที่ harden แล้วบนพื้นฐาน iOS และ macOS ซึ่งปรับให้เหมาะกับ workload การอนุมาน LLM
    • ออกแบบมาให้ attack surface แคบ
    • ใช้เทคโนโลยีความปลอดภัยของ iOS เช่น Code Signing และ sandboxing
  • Apple ตัดองค์ประกอบที่โดยทั่วไปสำคัญต่อการจัดการดาต้าเซ็นเตอร์ออกจากโหนด PCC
    • remote shell
    • เครื่องมือสังเกตภายในระบบและเครื่องมือ observability อเนกประสงค์
  • แทนที่ด้วยองค์ประกอบเฉพาะวัตถุประสงค์ที่ส่ง metrics ด้านปฏิบัติการขนาดเล็กและจำกัดให้พนักงาน SRE อย่างกำหนดตายตัว
  • Apple สร้าง machine learning stack ใหม่ด้วย Swift on Server เพื่อโฮสต์ foundation model บนคลาวด์

การประมวลผลคำขอผู้ใช้และการป้องกันการเก็บรักษาข้อมูล

  • PCC ต้องใช้ข้อมูลในคำขอของผู้ใช้เพื่อการอนุมานของโมเดล จึงไม่สามารถออกแบบด้วยการเข้ารหัสแบบ end-to-end อย่างสมบูรณ์เพียงอย่างเดียว
  • PCC จึงให้ compute node บังคับใช้ความเป็นส่วนตัวของข้อมูลผู้ใช้ทางเทคนิคระหว่างประมวลผล และทำให้ไม่สามารถเก็บรักษาข้อมูลได้เมื่อวงจรงานสิ้นสุดลง
  • การรับประกันด้านการประมวลผลข้อมูลผู้ใช้ของ PCC มีสามข้อ
    • อุปกรณ์ของผู้ใช้ส่งข้อมูลไปยัง PCC เพื่อวัตถุประสงค์เดียวคือประมวลผลคำขออนุมาน
    • ข้อมูลผู้ใช้อยู่ในโหนด PCC ที่ประมวลผลคำขอเท่านั้นจนกว่าจะส่งคำตอบกลับ
    • ข้อมูลผู้ใช้จะไม่ถูกส่งให้พนักงาน Apple แม้เป็นผู้ที่มีสิทธิ์เข้าถึงระดับผู้ดูแลต่อบริการ production หรือฮาร์ดแวร์
  • เมื่อ Apple Intelligence ใช้ PCC อุปกรณ์จะประกอบคำขอจาก prompt, โมเดลที่ต้องการ และพารามิเตอร์การอนุมาน
  • PCC client บนอุปกรณ์จะเข้ารหัสคำขอโดยตรงด้วย public key ของโหนด PCC ที่ผ่านการตรวจสอบและยืนยันทาง cryptography แล้วก่อน
    • มีการเข้ารหัสแบบ end-to-end จากอุปกรณ์ผู้ใช้ไปยังโหนด PCC ที่ผ่านการตรวจสอบแล้ว
    • บริการดาต้าเซ็นเตอร์เสริม เช่น load balancer และ privacy gateway อยู่นอก trust boundary และไม่มีกุญแจสำหรับถอดรหัสคำขอ
  • โหนด PCC สามารถรันได้เฉพาะโค้ดที่ได้รับอนุมัติและวัดค่าเชิง cryptography แล้วผ่าน Secure Boot และ Code Signing
    • โค้ดที่ executable ทั้งหมดต้องลงนามโดย Apple และอยู่ใน trust cache ที่อนุมัติสำหรับโหนด PCC เฉพาะนั้น
    • trust cache ถูกโหลดโดย Secure Enclave และไม่สามารถเปลี่ยนหรือเพิ่มได้ขณะรันไทม์
    • ไม่สามารถสร้าง JIT mapping ได้ จึงป้องกันการ compile หรือ inject โค้ดขณะรันไทม์
  • โค้ดและ model asset ใช้การคุ้มครองความถูกต้องสมบูรณ์แบบเดียวกับที่ใช้ใน Signed System Volume
  • Secure Enclave บังคับไม่ให้กุญแจถอดรหัสคำขอถูกทำซ้ำหรือดึงออกไปได้
  • เพื่อป้องกันการเก็บรักษาข้อมูล Secure Enclave จะสุ่มกุญแจเข้ารหัส data volume ใหม่ทุกครั้งที่รีบูต และไม่เก็บกุญแจนี้ไว้ถาวร
    • ทุกครั้งที่ Secure Enclave Processor ของโหนด PCC รีบูต data volume จะถูกลบเชิง cryptography
    • inference process จะลบข้อมูลที่เกี่ยวข้องเมื่อคำขอเสร็จสิ้น
    • address space ที่ประมวลผลข้อมูลผู้ใช้จะถูก recycle เป็นระยะ เพื่อลดผลกระทบจากข้อมูลที่อาจหลงเหลือในหน่วยความจำโดยไม่คาดคิด
  • Pointer Authentication Codes และ sandboxing ทำให้ exploit ที่พยายามเลี่ยงการรับประกันทำได้ยากขึ้น และจำกัด lateral movement ภายในโหนด PCC
  • ชั้น inference control และ dispatch เขียนด้วย Swift เพื่อให้ได้ memory safety และแยกการประมวลผลเบื้องต้นของคำขอออกเป็น address space แยกต่างหาก

การนำ privileged runtime access ออก

  • โหนด PCC ไม่มี remote shell หรือกลไก interactive debugging
  • แม้ Code Signing จะป้องกันการโหลดโค้ดเพิ่มเติม แต่ Apple มองว่าการเข้าถึงแบบเปิดกว้างเช่นนี้เองเป็น attack surface ขนาดใหญ่ที่อาจเลี่ยงความปลอดภัยและความเป็นส่วนตัวของระบบได้
  • โหนด PCC ไม่สามารถเปิดใช้งาน Developer Mode และไม่มีเครื่องมือที่จำเป็นสำหรับ debugging workflow
  • เครื่องมือ observability และการจัดการมี privacy safeguard เพื่อป้องกันการเปิดเผยข้อมูลผู้ใช้
    • ไม่มีกลไก logging อเนกประสงค์
    • เฉพาะ log และ metrics ที่กำหนดไว้ล่วงหน้า มีโครงสร้าง และผ่านการ audit แล้วเท่านั้นที่ออกนอกโหนดได้
    • ใช้การตรวจสอบหลายชั้นที่เป็นอิสระจากกันเพื่อป้องกันการเปิดเผยข้อมูลผู้ใช้โดยไม่ตั้งใจผ่านกลไกดังกล่าว
  • การออกแบบนี้ให้การรับประกันที่บังคับใช้ได้ว่าเฉพาะโค้ดที่กำหนดเท่านั้นเข้าถึงข้อมูลผู้ใช้ และข้อมูลผู้ใช้จะไม่รั่วออกจากโหนด PCC ระหว่างการจัดการระบบ

การไม่เจาะจงเป้าหมายและการรับมือการโจมตีฮาร์ดแวร์

  • threat model ของ PCC รวมถึงผู้โจมตีขั้นสูงที่เข้าถึง compute node ทางกายภาพ และสามารถเลี่ยงคุณสมบัติความปลอดภัยฮาร์ดแวร์บางส่วนของระบบเพื่อดึงข้อมูลที่กำลังประมวลผลอยู่ได้
  • Apple ป้องกันด้วยสองวิธี
    • ใช้ supply chain ที่ harden แล้วกับฮาร์ดแวร์ PCC ทำให้การโจมตีฮาร์ดแวร์ขนาดใหญ่มีต้นทุนสูงมากและตรวจพบได้
    • ทำให้การโจมตีขนาดเล็กไม่สามารถนำไปใช้เจาะจงข้อมูลผู้ใช้รายใดรายหนึ่งได้
  • ความปลอดภัยฮาร์ดแวร์ของ PCC เริ่มตั้งแต่ขั้นตอนการผลิต
    • ก่อนเซิร์ฟเวอร์ถูกปิดผนึกและเปิดใช้งาน tamper switch จะมีการทำ inventory องค์ประกอบของโหนด PCC และถ่ายภาพความละเอียดสูง
    • หลังถึงดาต้าเซ็นเตอร์และก่อน provisioning PCC จะมีการตรวจสอบซ้ำอย่างกว้างขวาง
    • ทีม Apple หลายทีม cross-check ข้อมูลจากแหล่งอิสระ และผู้สังเกตการณ์บุคคลที่สามที่ไม่เกี่ยวข้องกับ Apple จะติดตามกระบวนการเพิ่มเติม
    • โหนด PCC แต่ละตัวได้รับ key certificate ที่มีรากมาจาก Secure Enclave UID
    • อุปกรณ์ผู้ใช้จะไม่ส่งข้อมูลไปยังโหนด PCC ที่ตรวจสอบ certificate ไม่ได้
  • เพื่อป้องกันการโจมตีที่เล็กกว่าและซับซ้อนกว่า PCC ใช้แนวทาง target diffusion
  • metadata ของคำขอไม่มีข้อมูลระบุตัวบุคคลเกี่ยวกับอุปกรณ์ต้นทางหรือผู้ใช้
    • มีเพียงข้อมูลบริบทของคำขอที่จำกัดและจำเป็นต่อการ route ไปยังโมเดลที่เหมาะสม
    • metadata นี้เท่านั้นที่ถูกส่งให้ load balancer และองค์ประกอบดาต้าเซ็นเตอร์นอก trust boundary ของ PCC
  • metadata มี credential แบบใช้ครั้งเดียวบนพื้นฐาน RSA Blind Signatures เพื่ออนุมัติคำขอที่ถูกต้องโดยไม่ผูกคำขอกับผู้ใช้รายใดรายหนึ่ง
  • คำขอ PCC ผ่าน OHTTP relay ที่ดำเนินการโดยบุคคลที่สาม
    • ซ่อนที่อยู่ IP ต้นทางของอุปกรณ์ก่อนที่คำขอจะไปถึงโครงสร้างพื้นฐาน PCC
    • ป้องกันไม่ให้ผู้โจมตีระบุคำขอด้วยที่อยู่ IP หรือเชื่อมโยงกับบุคคล
    • หากต้องการชี้นำทราฟฟิกตาม IP ต้นทาง ต้องเจาะทั้ง relay ของบุคคลที่สามและ load balancer ของ Apple
  • อุปกรณ์ผู้ใช้เข้ารหัสคำขอสำหรับ subset ของโหนด PCC เท่านั้น ไม่ใช่ทั้งบริการ PCC
    • load balancer ส่งคืน subset ของโหนดที่มีแนวโน้มพร้อมประมวลผลคำขอ
    • load balancer ไม่มีข้อมูลระบุตัวผู้ใช้หรืออุปกรณ์ จึงไม่สามารถทำให้ชุดโหนดเอนเอียงสำหรับผู้ใช้รายใดรายหนึ่งได้
    • แม้โหนดเดียวถูกเจาะ ก็ถอดรหัสได้เพียงส่วนน้อยของคำขอที่เข้ามา
    • ชุดโหนด PCC ที่ load balancer เลือกสามารถ audit ทางสถิติได้

ความโปร่งใสที่ตรวจสอบได้และการเข้าถึงของนักวิจัย

  • Apple เห็นว่าเพื่อความเชื่อมั่นสาธารณะต่อ PCC นักวิจัยด้านความปลอดภัยต้องสามารถตรวจสอบการรับประกันด้านความปลอดภัยและความเป็นส่วนตัวแบบ end-to-end ได้
  • เมื่อเปิดตัว PCC มีแผนเผยแพร่ software image ของ production build ทั้งหมด เพื่อการวิจัยด้านความปลอดภัย
  • อุปกรณ์ผู้ใช้ถูกออกแบบให้ส่งข้อมูลเฉพาะไปยังโหนด PCC ที่สามารถพิสูจน์ทาง cryptography ได้ว่ากำลังรันซอฟต์แวร์ที่ถูกขึ้นทะเบียนสาธารณะ
  • แผนความโปร่งใสที่ตรวจสอบได้ของ Apple ประกอบด้วย
    • เผยแพร่ measurement ของโค้ดทั้งหมดที่รันใน PCC ลงใน transparency log แบบ append-only ที่ป้องกันการแก้ไขด้วย cryptography
    • เปิดเผย log และ binary software image ที่เกี่ยวข้องให้ผู้เชี่ยวชาญด้านความเป็นส่วนตัวและความปลอดภัยตรวจสอบและยืนยันได้
    • เผยแพร่และดูแลชุดเครื่องมือทางการสำหรับวิเคราะห์ซอฟต์แวร์โหนด PCC
    • ให้รางวัลผลการวิจัยสำคัญผ่าน Apple Security Bounty
  • production PCC software image ทั้งหมดจะเปิดเผยเพื่อการตรวจสอบ binary แบบอิสระ
    • รวม OS, แอปพลิเคชัน และไฟล์ executable ที่เกี่ยวข้อง
    • นักวิจัยสามารถนำไปเทียบกับ measurement ใน transparency log เพื่อตรวจสอบได้
    • ซอฟต์แวร์จะถูกเปิดเผยภายใน 90 วันหลังรวมเข้า log หรือหลังมี software update ที่เกี่ยวข้องให้ใช้งาน แล้วแต่ว่าเหตุการณ์ใดเกิดก่อน
    • เมื่อ release ถูกลงนามเข้าไปใน log แล้ว จะไม่สามารถลบออกโดยไม่ถูกตรวจพบได้
  • อุปกรณ์ผู้ใช้จะ wrap request payload key ด้วย public key ของโหนดนั้นก็ต่อเมื่อ measurement ที่โหนด PCC พิสูจน์มาตรงกับ software release ใน public transparency log
  • Code Signing ป้องกันการโหลดซอฟต์แวร์ที่ไม่ได้รับอนุมัติ และทำให้โค้ดทั้งหมดของโหนด PCC ถูกรวมอยู่ในการ attestation

สภาพแวดล้อมวิจัย PCC และรางวัล

  • Apple วางแผนมาตรการเพิ่มเติมสามประการเพื่อให้นักวิจัยตรวจสอบคำมั่นด้านความเป็นส่วนตัวของ PCC และค้นหาปัญหาได้อย่างรวดเร็ว
    • เปิดเผย PCC Virtual Research Environment
      • ชุดเครื่องมือและ image สำหรับจำลองโหนด PCC บน Mac ที่มี Apple silicon
      • สามารถบูตเวอร์ชันซอฟต์แวร์ PCC ที่แก้ไขเพียงเล็กน้อยเพื่อให้ virtualize ได้สำเร็จ
    • นอกเหนือจาก binary image ของ production PCC build ทั้งหมด จะเปิดเผยบางส่วนของ source code PCC ที่สำคัญต่อความปลอดภัยเป็นระยะ
    • เป็นครั้งแรกบนแพลตฟอร์ม Apple ที่รวมเฟิร์มแวร์ sepOS และ bootloader iBoot ไว้ใน PCC image แบบ plaintext
  • Apple Security Bounty ให้รางวัลผลการวิจัยใน software stack ทั้งหมดของ PCC
  • ปัญหาที่ทำให้คำมั่นด้านความเป็นส่วนตัวของ PCC อ่อนแอลงจะได้รับรางวัลสูงเป็นพิเศษ

สิ่งที่จะเปิดเผยต่อไป

  • PCC ถูกออกแบบมาให้เป็นไปตามข้อกำหนดเรื่องการคำนวณแบบไร้สถานะ, การรับประกันที่บังคับใช้ได้, ไม่มี privileged access, ไม่เจาะจงเป้าหมาย และความโปร่งใสที่ตรวจสอบได้
  • หลัง PCC เปิดให้ใช้งานแบบ beta จะมีคำอธิบายเชิงเทคนิคที่ลึกขึ้นตามมา
  • มีแผนแชร์รายละเอียดทางเทคนิคเพิ่มเติมเกี่ยวกับการใช้งานและการทำงานของข้อกำหนดหลักแต่ละข้อในอนาคต
  • Apple จะเปิดเผยซอฟต์แวร์ PCC และ PCC Virtual Research Environment ให้แก่นักวิจัยด้านความปลอดภัยเป็นครั้งแรกในเร็ว ๆ นี้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-06-11
ความคิดเห็นจาก Hacker News

  • ทุกอย่างที่เชื่อมต่อกับคลาวด์หรืออินเทอร์เน็ต หากไม่เป็น โอเพนซอร์ส และเซิร์ฟเวอร์ไม่ได้เป็นแบบ กระจายศูนย์ สุดท้ายก็ต้องเชื่อใจใครสักคนอยู่ดี
    Apple อาจพยายามอย่างเต็มที่ไม่ให้ใครนอกจากตัวเองเข้าถึงข้อมูลได้ แต่ Apple ควบคุมทุก endpoint, การอัปเดต iPhone และเซิร์ฟเวอร์ทั้งหมด
    ทำให้นึกถึงบทความ “web-based encryption is always snake oil”: https://www.devever.net/~hl/webcrypto
    แม้แต่ข้อมูลที่เก็บไว้ในเครื่อง Apple ก็มีอำนาจจะเข้าถึงได้หากต้องการ และถ้ามีคำสั่งจากรัฐบาลก็อาจทำเช่นนั้นได้ ดังนั้นคำว่า “ส่วนตัว” ในที่นี้จึงใกล้เคียงกับความหมายว่า มีแค่ Apple เท่านั้นที่รู้ได้ มากกว่าจะหมายถึงไม่มีใครรู้
    แม้ทางเลือกอื่นอาจทำให้ข้อมูลรั่วไหลไปหลายที่มากกว่า แต่สิ่งนี้ก็ยังห่างไกลจากการเข้ารหัสที่ไม่มีวันถูกเจาะอย่างที่โฆษณาไว้

    • ผมว่าเกณฑ์ประเมินนี้ไม่ยุติธรรมเสียทีเดียว เพราะมันจับ Apple ไปรวมกับพวกอย่าง Google หรือ OpenAI
      Google ติดตามผู้ใช้อย่างชัดเจนเพื่อโฆษณา ระบบแนะนำ และ AI โดยไม่ได้ปิดบัง และนั่นคือแกนหลักของโมเดลธุรกิจ
      ตรงกันข้าม Apple ดูจริงจังพอสมควรกับการทำให้พนักงานไม่สามารถเข้าถึงข้อมูลผู้ใช้ในระบบ AI นี้ได้ อีกทั้งยังจำกัดการทำ logging และ observability อย่างมาก และถึงขั้นออกแบบชิปกับระบบปฏิบัติการเอง
      การทำให้ไคลเอนต์ไม่สื่อสารกับระบบที่ไม่ได้รับการตรวจสอบก็เป็นความแตกต่างที่สำคัญ
      จะเชื่อคำพูดของ Apple ตรง ๆ ไม่ได้ก็จริง แต่ผมมองว่า การตรวจสอบโดยบุคคลที่สาม คือหัวใจในการเชื่อถือและยืนยันความเป็นส่วนตัวของระบบนี้
      คำพูดที่ว่า “Apple รู้ว่าคุณกำลังทำอะไร” ให้ความหมายแฝงเหมือนว่าคนภายใน Apple สามารถเข้าถึงข้อมูลที่ส่งจากอุปกรณ์ไปยัง private cloud ได้ ซึ่งดูเหมือนจะไม่ใช่ความจริง
      อีกปัจจัยหนึ่งที่ช่วยให้เชื่อถือได้คือ ความเป็นส่วนตัว เป็นเสาหลักสำคัญของโมเดลธุรกิจ Apple มายาวนาน Apple ประสบความสำเร็จทางการเงินจากการขายผลิตภัณฑ์ด้วยวิธีอื่น และการหันไปขายข้อมูลก็ทั้งไม่จำเป็นและไม่ใช่ไอเดียธุรกิจที่ดี
      จะตั้งข้อสงสัยไว้ก่อนจนกว่าจะมีการตรวจสอบจากบุคคลที่สามก็สมเหตุสมผล แต่การบอกว่าแนวทางของ Apple ไม่ได้ดีกว่า OpenAI หรือ Google ในเรื่องข้อมูลและความเป็นส่วนตัวนั้นไม่ยุติธรรม
    • ตรงประโยคที่ว่า “ต้องเป็นโอเพนซอร์สและเซิร์ฟเวอร์ต้องกระจายศูนย์” ถ้าจะให้แม่นกว่านั้นควรเป็น โอเพนซอร์สและโฮสต์เองได้
      ถ้าคนทั่วไปไม่สามารถรันเซิร์ฟเวอร์เองได้ แค่มีโค้ดอยู่ใน public repository ก็ยังไม่พอ เพราะไม่มีทางรู้ว่าโค้ดนั้นตรงกับสิ่งที่รันอยู่บนคลาวด์เซิร์ฟเวอร์จริงหรือไม่
    • ถ้าไม่ได้ตรวจสอบเองทั้งการออกแบบฮาร์ดแวร์ กระบวนการผลิต และซอฟต์แวร์ทั้งหมด ต่อให้รันในเครื่องก็ยังเท่ากับว่าต้องเชื่อใจคนจำนวนมากอยู่ดี
    • อันนี้ไม่ถูกต้องนัก ถ้าคุณ เชื่อคณิตศาสตร์ ก็สามารถพิสูจน์ได้ว่าซอฟต์แวร์ทำงานตามที่อ้างจริง
      แน่นอนว่าต้องมีงานตรวจสอบเพิ่มเติม แต่ถึงอย่างนั้นก็ยังเป็นความก้าวหน้าครั้งใหญ่
    • ถ้าจะใช้เทคโนโลยี ก็ต้องเชื่อใจใครสักคนอยู่แล้ว Apple โฟกัสกับคอมพิวเตอร์ส่วนบุคคลมาตั้งแต่ก่อตั้ง สื่อสารเรื่องนี้อย่างสม่ำเสมอ และผลงานที่ผ่านมาก็ถือว่าใช้ได้
      ในมุมผม ทางเลือกอื่นดูแตกกระจัดกระจายและไม่มีจุดโฟกัสชัดเจน ผมเลยเลือกเชื่อ Apple

  • มีคอมเมนต์ที่ดีจากนักเข้ารหัสลับ Matt Green อยู่ที่นี่: https://x.com/matthew_d_green/status/1800291897245835616?t=C...
    ไม่รู้ว่า Matt ทราบไหมว่าถ้าไม่มีบัญชี X จะอ่านทวีตไม่ได้ น่าจะใช้ BlueSky หรือ Mastodon จะดีกว่า
    รวมเธรดไว้ที่นี่: https://threadreaderapp.com/thread/1800291897245835616.html?...

    • ถ้าเขาไม่อยากให้ใครอ่านทวีตของตัวเองจริง ๆ เขาก็คงใช้ BluSky หรือ Mastodon ไปแล้ว
    • มีสองทวีตที่สะดุดตาเป็นพิเศษ
      “ในบล็อกโพสต์น่าจะมีรายละเอียดทางเทคนิคมากกว่านี้อีกประมาณ 6 อย่าง เป็นการออกแบบที่ระมัดระวังมาก ถ้าคุณให้เงินก้อนใหญ่กับทีมชั้นยอดเพื่อสร้างคลาวด์ ‘ส่วนตัว’ ที่ดีที่สุดในโลก มันก็คงออกมาหน้าตาแบบนี้”
      “แน่นอนว่าเราต้องจำไว้ว่า superspy ไม่ใช่ศัตรูที่ใหญ่ที่สุดเสมอไป สำหรับคนจำนวนมาก ศัตรูที่ใหญ่ที่สุดคือบริษัทที่ขายอุปกรณ์และซอฟต์แวร์ให้พวกเขา ระบบ PCC นี้เป็นคำมั่นสัญญาที่เป็นรูปธรรมว่า Apple จะ ‘ไม่แอบดู’ ข้อมูลผู้ใช้ ซึ่งมีความหมายมาก”
      ผมยังชอบแนวทางที่ข้อมูลอยู่ในอุปกรณ์มากกว่า แต่ อย่างน้อยนี่ก็เป็นคำมั่นสัญญาครั้งใหญ่ในทิศทางที่ถูกต้อง หรืออาจเป็นทิศทางที่ผิดแต่ก็ยังทำได้ดีกว่าคู่แข่งมากก็ได้
    • ส่วนที่ทำให้ติดใจคือ “Apple ดูเหมือนไม่มีแผนจะแจ้งอย่างชัดเจนเมื่อข้อมูลออกจากอุปกรณ์ไปยัง Private Compute ผู้ใช้ไม่ได้ให้ความยินยอม และอาจไม่ได้รับการแจ้งเตือนด้วย มันแค่เกิดขึ้นเหมือนเวทมนตร์”
      คาดว่าน่าจะมีตัวเลือกให้ปิดฟีเจอร์ AI ทั้งหมด ทั้ง on-device และ off-device
      มีเหตุผลอะไรไหมที่ผู้ผลิตอุปกรณ์จะไม่ใส่ตัวเลือกแบบ ใช้ AI บนเครื่องเท่านั้น? ฟีเจอร์ AI ใน iOS 17 ตอนนี้ก็ใช้งานได้โดยไม่ต้องมี iCloud
      คงจะดีถ้า Apple ใช้โดเมนเฉพาะอย่าง *.pcc.apple.com เพื่อให้กรองได้ในระดับเครือข่าย
    • อ่านได้ที่นี่แม้ไม่มีบัญชี X: https://nitter.poast.org/matthew_d_green/status/180029189724...
    • จริง ๆ แล้ว Matt ใช้บัญชี Mastodon อย่างสม่ำเสมอ แต่ดูเหมือนเรื่องนี้ยังไม่ได้โพสต์ที่นั่น: https://ioc.exchange/@matthew_d_green

  • อ่านทั้งหมดแล้วสุดท้ายก็ลงเอยที่คำว่า “เชื่อเราเถอะ” อยู่ดี Apple สามารถเซ็นและอนุมัติอัปเดตที่มี backdoor ได้ทุกเมื่อ และรัฐบาลก็สามารถบังคับให้ Apple ทำแบบนั้นได้ด้วยลายเซ็นครั้งเดียว แถมทุกอย่างอาจเกิดขึ้นอย่างเงียบ ๆ
    เข้าใจว่ามีข้อดีในสิ่งที่ Apple ทำ แต่ถ้าจะ ขายความไว้ใจ ก็ต้องจริงใจ 100% และหากยังไม่เปิดเผยอย่างโปร่งใสว่ายังมีความเป็นไปได้ในการเข้าถึงข้อมูลแบบนี้ ข้อความทั้งหมดก็จะเสียความน่าเชื่อถือ

    • Apple มีสิทธิ์ root อยู่แล้ว และซอฟต์แวร์ก็เป็น closed source ไม่มีทางใดเลยที่จะหยุดการอัปโหลดข้อมูลทั้งหมดได้ในตอนนี้
      ถ้าคุณไม่สามารถเชื่อใจคนที่สร้างระบบปฏิบัติการได้ ปัญหาก็ลึกกว่าการกังวลเรื่องการประมวลผล AI นอกอุปกรณ์มาก
    • ตรรกะนั้นก็ไม่ต่างจากสิ่งที่ Apple ทำกับ iPhone ได้อยู่แล้ว การที่ไปประมวลผลบนเซิร์ฟเวอร์ไม่ได้เปลี่ยนอะไรเลย
      Apple สามารถกดปุ่มครั้งเดียวให้ iPhone อัปโหลดข้อมูลอะไรก็ได้ขึ้นเซิร์ฟเวอร์ ตามตรรกะนี้ก็แปลว่าไม่ควรเชื่ออะไรเลย รวมถึง AI ที่รันในเครื่องด้วย อาจจะจริง แต่ก็ไม่ค่อยใช้ได้จริง
      ช่วงท้ายของเธรด Matthew Green สรุปไว้ดีมาก: “บางครั้งความสมบูรณ์แบบก็ขัดขวางสิ่งที่ดีมากได้ ในโลกความจริง ทางเลือกแทน on-device คือการส่งข้อมูลอ่อนไหวไปให้ OpenAI หรือที่อื่นที่น่าสงสัยยิ่งกว่า สำหรับหลายคน ศัตรูตัวใหญ่ที่สุดก็คือบริษัทที่ขายอุปกรณ์และซอฟต์แวร์ให้พวกเขา PCC คือคำมั่นสัญญาที่เป็นรูปธรรมว่า Apple จะ ‘ไม่แอบดู’ ข้อมูล และนี่เป็นเรื่องใหญ่ ตอนนี้เรากำลังเข้าสู่โลกที่บางส่วนของโทรศัพท์ไปอยู่ในดาต้าเซ็นเตอร์ห่างออกไป 2,000 ไมล์ คนสายความปลอดภัยก็ต้องคุ้นกับความจริงนั้นและทำให้ทุกส่วนปลอดภัยที่สุดเท่าที่ทำได้”

  • น่าสนใจมาก Private Cloud Compute ของ Apple ดูเหมือนจะมีแนวคิดเดียวกันกับโปรเจกต์โอเพนซอร์ส System Transparency ที่ผมกับเพื่อนร่วมงานเริ่มไว้เมื่อ 6 ปีก่อน
    หวังว่าจะได้เห็นรายละเอียดทางเทคนิคเพิ่มเติม ถ้ามีคนจาก Apple มาเห็น ก็สามารถติดต่อ stromberg@mullvad.net ได้ เรายินดีคุยเรื่องดีไซน์ของเราเทียบกับของ Apple หรือให้ฟีดแบ็ก
    ลิงก์ที่เกี่ยวข้อง: https://mullvad.net/en/blog/system-transparency-future
    http://system-transparency.org
    http://sigsum.org

    • https://en.m.wikipedia.org/wiki/Confidential_computing
      สิ่งที่ Apple ทำคือ Confidential Computing ลองดูตัวอย่างการนำไปใช้แล้วจะเข้าใจรายละเอียดทางเทคนิคมากขึ้น
    • ตอนดูประกาศ ผมก็คิดแบบเดียวกันทันทีและนึกถึง System Transparency เหมือนกัน อยากรู้ว่าเมื่อรายละเอียดถูกเปิดเผยและเข้าใจกันอย่างครบถ้วนแล้ว ผู้คนจะประเมินมันออกมาอย่างไร
    • ระบบประเภทนี้ส่วนใหญ่ เช่น Intel SGX, AMD SEV และเทคโนโลยีใหม่ของ NVIDIA ใช้องค์ประกอบพื้นฐานคล้ายกัน แต่ผมคิดว่าจุดต่างของ Apple อยู่ที่คุณภาพของการนำไปใช้จริงและคุณภาพของระบบโดยรวม
      Apple ไม่ได้เป็นสมาชิกของ Confidential Computing Consortium แต่ ARM เป็นสมาชิก
      ผมค่อนข้างมองบวกกับ Trusted Computing และดูเหมือนแรงขับเคลื่อนกำลังเพิ่มขึ้น
      ถ้าเปิดกว้างกว่านี้ และสามารถควบคุมทั้งสแตกพร้อมติดตั้ง root certificate หรือคีย์ของตัวเองลงบนแพลตฟอร์มฮาร์ดแวร์ได้ ก็คงดี แต่ถึงอย่างนั้นมันก็ยังให้ประโยชน์ได้มาก
      ถ้า Apple ดันเรื่องนี้เข้าสู่ตลาดกระแสหลักได้ ก็คาดว่าการนำไปใช้จะเพิ่มขึ้นอีก

  • ส่วนที่ว่า “เป็นครั้งแรกบนแพลตฟอร์ม Apple ที่อิมเมจ PCC รวมเฟิร์มแวร์ sepOS และบูตโหลดเดอร์ iBoot แบบ plaintext ทำให้นักวิจัยสามารถศึกษาคอมโพเนนต์สำคัญเหล่านี้ได้ง่ายกว่าที่เคย” นั้นดีมาก
    แต่ส่วนที่ว่า “ซอฟต์แวร์จะถูกเผยแพร่ภายใน 90 วันหลังจากถูกรวมไว้ใน log หรือหลังมีการปล่อยอัปเดตซอฟต์แวร์ที่เกี่ยวข้อง แล้วแต่อย่างไหนจะเกิดก่อน” หมายความว่าในทางทฤษฎียังอาจมี ช่องว่างสูงสุด 90 วัน ระหว่างการปล่อยซอฟต์แวร์ที่มีช่องโหว่กับความสามารถในการถูกค้นพบ
    หวังว่าการเผยแพร่อิมเมจจริงจะใกล้เคียงกับการเผยแพร่ทันทีมากกว่าการรอถึงเพดานสูงสุด

    • ถ้าผู้ตรวจสอบจู้จี้ถามเรื่อง backdoor ของ NSA หรือ CCP มากเกินไป ก็คงแก้ได้ด้วยตาราง อัปเดตแล้วค่อยย้อนกลับทุก 89 วัน

  • ในสหรัฐฯ ความเป็นส่วนตัวแบบสมบูรณ์เป็นไปไม่ได้ เพราะรัฐบาลไม่เพียงบังคับให้ Apple เปิดให้ดูภายในได้ แต่ยังอาจสั่งห้ามไม่ให้บอกเรื่องนั้นด้วย
    ในทางปฏิบัติแทบไม่มีทางที่ Apple จะเลี่ยง “ข้อจำกัด” นี้ได้ ถ้ามีโอกาสก็อย่าลืมขอบคุณ “ตัวแทน” ที่โหวตต่ออายุ PATRIOT Act

    • เซิร์ฟเวอร์ Private Cloud Compute ไม่มีสตอเรจถาวร ดังนั้นต่อให้เปิดให้ดูภายในก็คงไม่มีอะไรให้ดู
      ถ้าจะเก็บข้อมูลจากคำขอที่เข้ามา ก็น่าจะต้องเป็นอะไรอย่างการดักฟังแบบเรียลไทม์ตามที่รัฐบาลร้องขอ ซึ่งอาจเป็นอีกสถานการณ์หนึ่ง
      แน่นอนว่าผมก็เป็นแค่คนคนหนึ่งบนอินเทอร์เน็ต แค่นึกข้อโต้แย้งต่อความกังวลนี้ขึ้นมาได้เท่านั้น เลยไม่รู้เหมือนกันว่าคิดมาถูกทางหรือเปล่า
    • ในฐานะคนเอเชีย ผมรู้สึกว่า expression “open up the kimono” ทั้งน่าอึดอัดและชวนขนลุก คิดว่าคงไม่ใช่มีแค่ผมที่รู้สึกแบบนั้น
    • ความเป็นส่วนตัวที่รับประกันได้ กับ ความเป็นส่วนตัวที่พิสูจน์ได้ เป็นคนละอย่างกัน
      รัฐบาลอาจขอข้อมูลได้ แต่ระบบของ Apple จะทำให้การแทรกแซงแบบนั้นถูกเปิดเผยต่อสาธารณะ แม้ Apple เองจะพูดไม่ได้ก็ตาม
    • สิ่งที่ Apple ทำได้ และดูเหมือนจะทำจริงทั่วทั้งผลิตภัณฑ์ของตัวเอง คือไม่ถือครองข้อมูลที่ถูกขอไว้ตั้งแต่แรก หรืออย่างน้อยก็ไม่ได้ถือไว้ในรูปแบบ plaintext
      ต่อให้เป็น national security letter ก็ไม่สามารถขอข้อมูลที่ไม่มีอยู่อีกแล้วได้
    • จากบทความของ Apple ก็ดูเหมือนจะเป็นไปได้ เลยสงสัยว่ามีส่วนไหนเป็นพิเศษที่ทำให้คุณติดใจหรือเปล่า

  • มีคำถามใหญ่ข้อหนึ่งว่า สิ่งนี้มีไว้เพื่อใครกันแน่?
    อย่าเข้าใจผิด นี่เป็นความพยายามที่ยอดเยี่ยมและเป็นงานเนิร์ดระดับ A+ มันเป็นสิ่งที่พูดภาษาของฉัน
    แต่ฉันคงแค่มองหาวิธีปิด ฟีเจอร์ที่โทรกลับบ้าน เพราะตั้งแต่แรกก็ไม่ต้องการพฤติกรรมแบบนั้นอยู่แล้ว
    นี่มีไว้เพื่อให้ฉันบอกคนอื่นว่า “Apple เป็นตัวเลือกที่ปลอดภัยที่สุด” งั้นหรือ? ฉันไม่อยากแนะนำ Linux เพราะไม่อยากต้องมาทำ tech support
    ตอนนี้รู้สึกเหมือนตัวเองกลายเป็นคนแก่ที่ตะโกนว่า “อย่ามายุ่งกับข้อมูลของฉัน” แล้ว

    • Apple ต้องการความแตกต่าง และเลือก ความเป็นส่วนตัว เป็นวิธีนั้น ซึ่งฉันเห็นด้วย
      พาดหัวข่าวเกี่ยวกับความพยายามด้าน AI ของ Microsoft ส่วนใหญ่แทบจะเหมือนฝันร้าย และมีข่าวในแง่ลบมากมาย
      ถ้าข่าวเกี่ยวกับ Apple AI เต็มไปด้วยเรื่องที่ว่าพวกเขาดูแลความปลอดภัยและความเป็นส่วนตัวอย่างเข้มงวดจนเกินพอดี ผู้คนก็น่าจะสบายใจขึ้นบ้างที่จะใช้งาน
      ฉันไม่ได้ใช้ผลิตภัณฑ์ของ OpenAI มากนัก แต่ถ้าจะใช้ ก็คงเลือกใช้ผ่านชั้น anonymization ของ Apple แทนที่จะไปหา OpenAI โดยตรง
    • ถ้าปิดไม่ได้ แล้วใช้เหตุผลนั้นมาเสนอความปลอดภัยสุดขั้วแบบนี้ จะเป็นอย่างไร?
    • นี่มีไว้เพื่อผู้ถือหุ้น เพราะกระแสการลงทุน AI ทำให้มูลค่าตลาดของ Microsoft และ Nvidia ตอนนี้มากกว่า Apple แล้ว
      Apple ต้องแสดงให้เห็นว่าตัวเองก็เป็นบริษัทที่มี AI เป็นศูนย์กลางได้ เพียงแต่ Apple มีวัฒนธรรมองค์กรที่ต้องการรักษาความเป็นส่วนตัวไว้
    • มันมีไว้เพื่อคนอย่างฉัน
      ฉันไม่ได้กังวลเรื่องที่รัฐบาลจะเข้าถึงข้อมูล แต่อยากไม่ให้ ผู้ไม่หวังดี อย่างพวกมิจฉาชีพ รัฐบาลต่างชาติ บริษัท ad tech และบริษัทประกัน เข้าถึงข้อมูลส่วนตัวของฉัน
      และในขณะเดียวกันก็ยังอยากใช้ความสามารถของ LLM ด้วย มันเป็นข้อเรียกร้องที่ไม่สมจริงขนาดนั้นเลยหรือ?
      ในความเป็นจริง ฉันคาดว่ารัฐบาลสหรัฐมีข้อมูลทั้งหมดของฉันอยู่แล้ว ไม่ชอบสภาพนี้หรอก แต่ความจริงก็คือความจริง
    • มันยังมีไว้เพื่อคู่แข่งที่พยายามผลักดันเรื่องเล่าว่า Apple “ตามหลัง” ด้วย
      ที่จริงแล้ว Apple มีทั้ง LLM และโครงสร้างพื้นฐานคลาวด์ ในระดับ iPhone พร้อมอยู่แล้ว และนี่ไม่ใช่งานที่ทำกันแค่ 2 ปี
      Apple แค่เน้นเรื่องความเป็นส่วนตัวตามที่ผู้คนคาดหวัง
      Gemini เองก็อาจอ้างเรื่องความเป็นส่วนตัวได้ แต่ถ้าเป็นจริง ผู้คนก็น่าจะคิดว่าประสิทธิภาพจะด้อยลงแทน

  • สงสัยว่ามันเทียบกับ AWS Nitro Enclaves ที่ Apple พูดถึงสั้น ๆ อย่างไร
    ความต่างหลักดูจะอยู่ที่สามารถตรวจสอบได้ลึกถึงระดับเฟิร์มแวร์
    Nitro Enclaves ไม่ได้ให้ค่าการวัดของเฟิร์มแวร์[0] หรือไฮเปอร์ไวเซอร์ และระบุว่าโค้ดไฮเปอร์ไวเซอร์สามารถอัปเดตแบบโปร่งใสได้ทุกเมื่อ[1]
    Apple วางแผนจะให้ทั้งระบบปฏิบัติการ Secure Enclave Processor อย่าง sepOS และอิมเมจบูตโหลดเดอร์
    บล็อกโพสต์ไม่ได้เขียนไว้ชัดเจน แต่ฟังดูเหมือนว่าจะให้ซอร์สโค้ดขององค์ประกอบเหล่านี้ด้วย
    [0]: https://docs.aws.amazon.com/enclaves/latest/user/set-up-atte...
    [1]: https://docs.aws.amazon.com/pdfs/whitepapers/latest/security...

    • Nitro วัดเฟิร์มแวร์อยู่แล้ว ถ้ามีเฟิร์มแวร์ที่ต่างจากที่คาดไว้ เซิร์ฟเวอร์ก็จะถูกแยกออกจากเครือข่ายที่ใช้ EC2 โดยพฤตินัย หรือไม่ก็ถูกรีเซ็ตอัตโนมัติ
      ระบบจะมีการเรียกอัตโนมัติ และมีโอกาสสูงที่ทีมความปลอดภัยจะเข้ามาเกี่ยวข้องด้วย
      ใน EC2 ไฮเปอร์ไวเซอร์ไม่ใช่เฟิร์มแวร์ จึงไม่มีเหตุผลที่จะวัดไฮเปอร์ไวเซอร์เฟิร์มแวร์
      เฟิร์มแวร์ BIOS/UEFI ของเมนบอร์ด ถ้าถูกแก้ไขก็จะถูกเขียนทับ
      โค้ดไฮเปอร์ไวเซอร์มีการเซ็นกำกับเสมอเหมือนโค้ดทุกชนิด และถูกสตรีมไปยังเซิร์ฟเวอร์ผ่านระบบความปลอดภัยที่ตรวจสอบได้ซึ่งใช้ measured boot หรือ secure boot ของการ์ด Nitro
      ฉันไม่แน่ใจว่าคำที่ใช้กับลูกค้าอย่าง “Nitro enclaves” หมายถึงอะไรกันแน่ แต่เหล่าวิศวกร EC2 จะขยับกันราวกับกองทัพทันทีแม้ประเมินว่าเป็นความเสี่ยงด้านความปลอดภัยเพียงเล็กน้อย
      เรื่องพื้นฐานพวกนี้ถูกจัดการไว้หมดแล้ว และไปไกลถึงขั้นรับประกันว่าแม้แต่ใน core dump ก็จะไม่มีข้อมูลลูกค้าจริงหลุดเข้าไป แม้ในรูปแบบเข้ารหัสก็ตาม
    • AWS ต้องทำแบบนี้เพราะมีซิลิคอนของตัวเอง ส่วน Intel, ARM และ AMD มี attestation ในระดับเฟิร์มแวร์และไฮเปอร์ไวเซอร์ให้อยู่แล้ว

  • อยากเห็นระบบปฏิบัติการนี้มากจริง ๆ และมองโลกในแง่ดีอย่างระมัดระวังว่ามันอาจเป็นกรณีแรกที่บริษัทยักษ์ใหญ่ด้านเทคโนโลยีมอบ การรับประกันความปลอดภัยที่ตรวจสอบได้ จริง ๆ
    ขึ้นอยู่กับว่ามันจะพัฒนาไปอย่างไร Apple อาจสามารถสร้างความไว้วางใจที่ผู้ใช้มีอยู่แล้วให้กลายเป็นสิ่งที่จับต้องได้จริงในระดับหนึ่ง และนั่นก็ถือว่าเจ๋งมาก
    ที่เจ๋งยิ่งกว่าคือการให้การตรวจสอบสายโซ่การดูแลทั้งหมด และถ้าจะทำแบบนั้นก็น่าจะต้องเปิดเผยส่วนอื่น ๆ ของสแตกบางส่วนด้วย
    โดยเฉพาะถ้าระบบปฏิบัติการคลาวด์จะเป็นโอเพนซอร์สตามที่สัญญาไว้ นั่นมีคุณค่ามหาศาล
    ตอนนี้ความกังวลหลักคือ หากมีการใช้ virtualization ในการปรับใช้จริง Secure Enclave ของส่วนระบบปฏิบัติการที่ยังเป็นกรรมสิทธิ์ซึ่งทำงานอยู่บนอุปกรณ์ผู้ใช้อาจส่งมอบกุญแจ และไฮเปอร์ไวเซอร์ที่เราไม่ได้ตรวจสอบอาจมีแบ็กดอร์สำหรับเข้าถึงคอนเทนเนอร์ได้
    คนที่มีความเชี่ยวชาญด้านความปลอดภัยสูงกว่านี้คงจะตั้งคำถามได้ดีกว่า
    ถ้า Apple ตอบสนองต่อฟีดแบ็กจากนักวิจัย ก็อาจทำให้ส่วนต่าง ๆ ของ toolchain นี้ตรวจสอบได้มากขึ้น
    ต่อให้ Apple จะไม่สามารถยืนยันความปลอดภัยของกรณีใช้งานที่ Apple อนุมัติเองได้ ระบบปฏิบัติการคลาวด์นี้ก็ยังอาจเป็นความก้าวหน้าครั้งใหญ่ของ การประมวลผลที่ปลอดภัย และคลาวด์ที่ปลอดภัย และผู้คนก็อาจโฮสต์เองอย่างอิสระหรือสร้างอนุพันธ์ของมันได้
    กรณีแย่ที่สุดคือ Apple ไม่ได้ทำสิ่งนี้จริง ๆ แต่ดูอย่างน้อยก็มีโอกาสค่อนข้างสูงที่จะรักษาสัญญานั้นไว้ได้ และถ้าเป็นเช่นนั้น แม้แต่กรณีแย่ที่สุดก็จะกลายเป็นว่า “มีโค้ดเบสโอเพนซอร์สที่เป็นประโยชน์มากสำหรับการประมวลผลที่ปลอดภัยขนาดใหญ่เกิดขึ้นมา” ซึ่งก็ยังเป็นเรื่องดีไม่ว่าส่วนอื่นจะเป็นอย่างไร

    • AWS Nitro Enclaves[0] ก็เป็นกรณีที่ใกล้เคียงกัน แต่จุดใหญ่คือ Apple ได้นำ private compute ไปทำเป็นผลิตภัณฑ์สำหรับลูกค้า macOS และ iOS กว่า 1 พันล้านคน
      [0] https://docs.aws.amazon.com/enclaves/latest/user/nitro-encla...
    • วงการเทคโนโลยีชอบลอก Apple
      ใน Asahi Linux มีสรุปภาพรวมด้านความปลอดภัยของ on-device boot chain ไว้อย่างดี: https://github.com/AsahiLinux/docs/wiki/Apple-Platform-Secur...
      ข้อความที่ว่า “เราจะเผยแพร่ PCC Virtual Research Environment ซึ่งเป็นชุดเครื่องมือและอิมเมจที่สามารถจำลอง PCC node บน Apple silicon Mac และบูตซอฟต์แวร์ PCC เวอร์ชันที่ปรับแก้เพียงเล็กน้อยเพื่อให้ virtualization ทำงานสำเร็จ” ดูเหมือนจะหมายความว่า PCC node เป็นแบบ bare metal
      จะสามารถจำลอง PCC node บน iPad Pro ที่ใช้ M4 Apple Silicon ได้ด้วยหรือไม่?

  • ส่วนที่บอกว่า “สุดท้าย เราได้ใช้ Swift on Server เพื่อสร้างสแตกแมชชีนเลิร์นนิงใหม่สำหรับโฮสต์ foundation model บนคลาวด์” น่าสนใจ
    ตรงนี้เห็นคำว่า Swift on Server โผล่มาชัดเจน: https://www.swift.org/documentation/server/