ฟีเจอร์ความปลอดภัย iOS ยุคใหม่ – เจาะลึก SPTM, TXM และ Exclaves

 (arxiv.org)
1 คะแนน โดย GN⁺ 2025-10-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โดยพื้นฐานแล้ว เคอร์เนล XNU ของระบบปฏิบัติการ Apple ให้ขอบเขตความเชื่อถือแบบเดี่ยวมาโดยตลอด
  • ระยะหลังมีความพยายามเปลี่ยนแปลงเพื่อลดผลกระทบของช่องโหว่ความปลอดภัย ผ่าน การแยกสถาปัตยกรรมเคอร์เนลและการทำให้เป็นแบบไมโครเคอร์เนล
  • การนำ Secure Page Table Monitor (SPTM) มาใช้ในปี 2023 ทำให้เกิดการแยกฟังก์ชันสำคัญและโครงสร้างโดเมนความเชื่อถือรูปแบบใหม่
  • กลไกความปลอดภัยสมัยใหม่อย่าง Exclaves และ Trusted Execution Monitor (TXM) ถูกสร้างขึ้นบนพื้นฐานของ SPTM
  • การปรับปรุงเชิงโครงสร้าง เหล่านี้ทำให้แม้เกิดการเจาะระบบเคอร์เนล ก็ไม่ได้ทำให้ความน่าเชื่อถือของทั้งระบบลดลงทันที

ภาพรวม

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

แรงจูงใจของการเปลี่ยนแปลงหลักและทิศทางการวิจัย

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

กลไกหลักของ SPTM (Secure Page Table Monitor)

  • SPTM เป็นคอมโพเนนต์ที่มีสิทธิ์สูงสุดของระบบ ทำงานที่ Guarded Level 2 (ระดับสิทธิพิเศษสูงสุด) ร่วมกับ Guarded Execution Feature (GXF)
  • GXF เพิ่มระดับการป้องกันในแนวนอนเข้าไปในโครงสร้าง exception level ของ AArch64 เดิม เพื่อแยกกิจกรรมอ่อนไหวของระบบออกจากการเข้าถึงโดยตรงจาก XNU
  • SPTM มอบโดเมนความเชื่อถือ (domain of trust) ผ่านกฎการ retype เฟรมและการแมปหน่วยความจำ โดยแยกพื้นที่ตามหน้าที่ของแต่ละส่วน
  • ตัวอย่างสำคัญของโดเมนความเชื่อถือนี้ได้แก่ TXM (รับผิดชอบการลงนามโค้ดและการตรวจสอบสิทธิ์) และ Exclaves (ฟีเจอร์ความปลอดภัยการแยกพื้นที่ยุคใหม่)

Exclaves และกลไกการสื่อสาร

  • Exclaves คือสภาพแวดล้อมสำหรับการประมวลผลที่ทำงานในเขตความเชื่อถืออิสระ และพึ่งพาระบบป้องกัน/ควบคุมหน่วยความจำที่อิงกับ SPTM
  • การสื่อสารระหว่าง Exclaves กับระบบถูกทำผ่านหลายวิธี เช่น xnuproxy (ตัวจัดการคำขอด้านความปลอดภัย) และเฟรมเวิร์ก IPC อย่าง Tightbeam IPC
  • Tightbeam มีโครงสร้าง IPC ที่ซับซ้อน ทั้งการสร้าง endpoint, message buffer และการเชื่อมต่อแบบ client-server
  • ในฐานะกรณีใช้งานจริงของ Exclaves งานวิเคราะห์นี้ยังครอบคลุมการควบคุมตัวบ่งชี้ความเป็นส่วนตัว เช่น ไฟแสดงการบันทึกหรือการใช้งานเสียง

การเสริมความปลอดภัยและแนวโน้มในอนาคต

  • เมื่อฟังก์ชันหลักของระบบถูกแยกออกจากการเข้าถึงโดยตรงของ XNU ก็เกิดกลไกป้องกันเพิ่มเติมที่ช่วยรักษาระดับความน่าเชื่อถือของทั้งระบบไว้ได้ แม้เคอร์เนลจะถูกเจาะ
  • ผลการวิเคราะห์เชิงลึกของปฏิสัมพันธ์ระหว่าง SPTM, Exclaves และ TXM ชี้ให้เห็นว่าเกิดโครงสร้างการป้องกันแบบหลายชั้นที่แข็งแกร่งกว่าที่เคยมีมาก
  • ในบทสรุป งานวิจัยได้นำเสนอภาพรวมหลังการนำ SPTM มาใช้ ความเป็นไปได้ในการเสริมความปลอดภัยต่อไป ข้อจำกัดที่ยังคงมีอยู่ และทิศทางของการวิจัยต่อยอดโดยสังเขป

โครงสร้างและคำแนะนำสำหรับเนื้อหาเชิงลึก

บทที่ 1: แรงจูงใจ–เป้าหมาย–โครงสร้าง

  • บริบททางประวัติศาสตร์ของการขยับสู่การแยกเคอร์เนลของ Apple และความจำเป็นของงานวิจัย
  • เน้นย้ำคุณูปการของงานวิจัยนี้

บทที่ 2: ภูมิหลังและพื้นฐาน

  • แนะนำ exception level ของ สถาปัตยกรรม AArch64, วิธีเข้าถึงหน่วยความจำ และเทคนิคการป้องกันเฉพาะของชิป Apple (Fast Permission Restrictions, Page Protection Layer, Guarded Execution Feature, Shadow Permission Remap Register)
  • สรุปงานวิจัยด้านความปลอดภัยเดิมและข้อจำกัดของงานเหล่านั้น

บทที่ 3: สภาพแวดล้อมการวิเคราะห์

  • อธิบายฮาร์ดแวร์ เฟิร์มแวร์ เครื่องมือ สัญลักษณ์ และรีจิสเตอร์เฉพาะของ Apple ที่ใช้เป็นเป้าหมาย

บทที่ 4: ภาพรวมการออกแบบสถาปัตยกรรมทั้งหมด

  • แสดงโครงสร้างระบบโดยรวมที่ครอบคลุมทั้ง EL (exception level) และ GL (ระดับการป้องกันแนวนอน)

บทที่ 5: โครงสร้างเชิงลึกของ SPTM

  • อธิบายรายละเอียดองค์ประกอบพื้นฐานของ SPTM การเริ่มต้นระบบ วิธีเรียกใช้ (เคอร์เนล·TXM·Secure Kernel) และ header/dispatch table
  • ลำดับการจัดการ event ภายใน SPTM, GENTER และโฟลว์การประมวลผล SVC/HVC (hypervisor call)
  • ตรรกะการ retype เฟรม: อธิบายเป็นขั้นตอนตั้งแต่การเรียกใช้และการตรวจสอบ การตรวจความถูกต้องตามประเภท/โดเมน การอัปเดต SPRR (Permission Remapping) ไปจนถึงการจบการเรียกใช้
  • กระบวนการแมปเพจและกลไกความปลอดภัยที่เกี่ยวข้อง

บทที่ 6: บทบาทของ Secure Kernel

  • พื้นฐานการดำเนินงานด้านความปลอดภัย เช่น การเรียก SPTM ของ Secure Kernel และการประมวลผล SVC

บทที่ 7: ระบบ Exclaves

  • คอมโพเนนต์หลัก เช่น Exclaves, Exclavecore และ ExclaveKit
  • การจัดการหน่วยความจำ/ทรัพยากรของ Exclave, การจัดกลุ่มตามโดเมน, state machine ของ conclave (พื้นที่ย่อย) และการโต้ตอบกับ user space
  • วิธีการสื่อสาร เช่น การสร้าง endpoint/การจัดตารางเวลา, Mach port, IPC สไตล์ seL4, xnuproxy, Tightbeam และตัวอย่างการใช้งานจริง (เช่น privacy indicator)

บทที่ 8: TXM (Trusted Execution Monitor)

  • วิธีที่ TXM ทำงานร่วมกับ SPTM รวมถึงโครงสร้างการทำงานของ dispatch, retyping และการดูแลพื้นที่ป้องกัน
  • อธิบายหน้าที่ด้านความปลอดภัยของ TXM และวิธีประมวลผลการเรียกใช้งาน

บทที่ 9~10: อภิปรายภาพรวมและบทสรุป

  • ประเด็นด้านความปลอดภัย ข้อจำกัดปัจจุบัน และทิศทางอนาคตจากการนำ SPTM และ Exclaves มาใช้
  • ปิดท้ายงานวิจัยพร้อมภาคผนวกที่มีเอกสารอ้างอิงและคำอธิบายคำศัพท์

คำอธิบายคำศัพท์สำคัญ

  • XNU: เคอร์เนลหลักของระบบปฏิบัติการ Apple ย่อมาจาก ‘X is Not Unix’
  • SPTM: โมดูลหลักที่มอบโดเมนความเชื่อถือผ่านการป้องกันและการแบ่งแยกหน่วยความจำ
  • TXM: ผู้กำกับดูแลความปลอดภัยที่รับผิดชอบงานอ่อนไหว เช่น การตรวจสอบการลงนามโค้ด
  • Exclaves: สภาพแวดล้อมความปลอดภัยที่เชื่อถือได้ซึ่งทำงานแบบแยกออกจากกันทั้งทางกายภาพและเชิงตรรกะ
  • Tightbeam IPC: เฟรมเวิร์กที่รองรับการสื่อสารอย่างปลอดภัยระหว่าง Exclaves กับระบบ
  • GXF/GL: ระดับ exception/protection ตาม AArch64 และความสามารถควบคุมเขตความเชื่อถือแนวนอนบนพื้นฐาน Guarded Level ที่เพิ่มเข้ามา

บทสรุป

สถาปัตยกรรมความปลอดภัยของ iOS ยุคใหม่กำลังพัฒนาไปในทิศทางที่เพิ่ม การแยกความเชื่อถือและการแบ่งบทบาท ให้สูงสุด โดยมี SPTM, TXM และ Exclaves เป็นแกนกลาง โครงสร้างการป้องกันแบบเป็นชั้นเช่นนี้ช่วยลดความเสี่ยงจากการเจาะระบบในชั้นล่างของเคอร์เนลได้อย่างก้าวกระโดด และเป็นรากฐานทางเทคนิคที่ทำให้รับมือกับภัยคุกคามด้านความปลอดภัยในอนาคตได้อย่างมั่นคง

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

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

 
GN⁺ 2025-10-15
ความเห็นจาก Hacker News

  • ผมคิดว่าทีม SEAR และ Apple ทำงานด้านความปลอดภัยของ iOS ได้ยอดเยี่ยมจริง ๆ อยากชื่นชมอย่างมากในจุดนี้
    ทั้งความพยายามฝังฟีเจอร์ด้านความปลอดภัยตั้งแต่ระดับฮาร์ดแวร์ไปจนทั่วทั้งสแตกก็น่าประทับใจ และยังคอยตรวจดู exploit แบบ ITW (การโจมตีที่เกิดขึ้นจริง) พร้อมศึกษาวิธีป้องกันอย่างต่อเนื่อง
    ตัวอย่างเช่นเคยนำฟีเจอร์อย่าง PPL มาใช้ แต่เมื่อสรุปได้ว่ามันไม่สมบูรณ์แบบก็กล้าตัดทิ้งแล้วมองหาเทคนิคใหม่
    Apple มีโครงสร้างแบบบูรณาการแนวดิ่ง จึงทำเรื่องแบบนี้ได้ง่ายกว่า Android มาก ในฝั่ง Android ต้องไปขอความร่วมมือจากผู้ผลิตฮาร์ดแวร์ (QC, Mediatek) และต้องผ่านหลายชั้นอย่าง linux kernel, AOSP, LLVM upstream เป็นต้น
    Pointer Authentication Codes (PAC) ก็เป็นอีกตัวอย่างที่ดี Apple ใช้แนวคิดแบบ “เราลองทำเอง” โดยดูแล LLVM branch ของตัวเองเพื่อใส่ฟีเจอร์นี้เข้าไป และก็ช่วยอุดช่องทางการโจมตีที่อิงกับ ITW ได้จริง

    • เหตุผลที่ผมซื้อผลิตภัณฑ์ของ Apple ไม่ใช่แค่เพราะมันเด่นเรื่องความปลอดภัยและความเป็นส่วนตัวเท่านั้น แต่เพราะ Apple ลงมือผลักดันเรื่องพวกนี้ด้วยความตั้งใจและแพสชัน ทั้งที่ไม่ใช่สิ่งจำเป็นต่อการทำเงินของบริษัทโดยตรง
      ในทางปฏิบัติ นอกเหนือจากการตลาดแล้ว พวกเขายังดึงแฮกเกอร์ระดับหัวกะทิจากชุมชน jailbreaking มาร่วมทีมความปลอดภัย และสร้างนวัตกรรมอย่าง Private Relay, เมลแบบส่วนตัว, trusted compute, multi-party inference เป็นต้น
      แน่นอนว่า Apple ก็มีปัญหาเรื่องท่าทีที่ดูหน้าไหว้หลังหลอกอยู่จริง เช่น การยอมให้ใช้ VPN (แต่ยกเว้นทราฟฟิกที่ไปยังเซิร์ฟเวอร์ของ Apple), ค่าตั้งต้นด้านความเป็นส่วนตัว (ยกเว้น Wi‑Fi calling หรือ “journaling suggestions”) ซึ่งน่าผิดหวัง
      พูดตามจริงคือมันยังมีเงื่อนไขว่าไม่ได้ปลอดภัยจาก Apple และพันธมิตรเครือข่ายบางรายอยู่ดี แต่ถึงอย่างนั้น Google ก็ยังให้ความรู้สึกประมาณว่า “ปลอดภัยสำหรับทุกคน ยกเว้น Google หรือผู้ลงโฆษณาที่ซื้อโฆษณาจาก Google” ดังนั้นผมจึงมองว่า Apple นำอยู่มาก

    • แม้จะทุ่มเทงานวิศวกรรมอย่างมหาศาลแล้ว iMessage ก็ยังคงมีเส้นทางที่โค้ดน่าสงสัยสามารถไปรันในเคอร์เนลได้อยู่ และนั่นทำให้ 0-click exploit ยังคงมีต่อไป

    • ข้อดีอีกอย่างของความพยายามแบบนี้คือ ถ้า Apple ทำให้เส้นทางโค้ดใด ๆ ถูกรันได้แม้เพียงครั้งเดียวบนโปรเซสเซอร์รุ่นใหม่ที่เสริมความปลอดภัยแล้ว ความปลอดภัยของทุกแพลตฟอร์มก็จะดีขึ้นตามไปโดยธรรมชาติ
      ในทางทฤษฎี ปัญหาที่จับได้ยากด้วย static analysis อย่างเดียวก็อาจตรวจพบได้ง่ายขึ้น และยังได้ insight ที่ลึกกว่าการดูแค่ crash แบบธรรมดา

    • ที่จริง Google ก็สามารถเพิ่ม MTE ได้ตั้งแต่หลายปีก่อนแล้ว แต่ไม่ต้องการบังคับใช้กับ OEM ในฐานะส่วนหนึ่งของการรับรอง Android
      เรียกได้ว่าเป็นประวัติศาสตร์ที่ซ้ำรอยคล้ายกับเรื่องอัปเดต OS

    • ตอนนี้เหตุผลที่ Apple ใส่ใจเรื่องความปลอดภัย ไม่ได้มีแค่การปกป้องผู้ใช้เท่านั้น
      โดยแก่นแล้วมันคือการทำให้ผู้ใช้รันซอฟต์แวร์ที่ไม่ได้รับอนุมัติเองหรือทำสิ่งอย่างการเจลเบรกได้ยากขึ้น เพื่อรักษาการผูกขาด App Store เอาไว้
      ท้ายที่สุดแล้วผมมองว่าบริษัทให้ความสำคัญกับผลประโยชน์ของตัวเองมากกว่าผลประโยชน์ของผู้ใช้

  • ทุกครั้งที่อ่านเรื่องความปลอดภัยของ iOS ผมมักทึ่งกับความซับซ้อนของมันเสมอ
    มีทั้งชั้นฮาร์ดแวร์ ชั้นเคอร์เนล เทคนิค sandboxing หลากหลายรูปแบบ และเลเยอร์อีกมาก
    เลยสงสัยว่าโครงสร้างแบบนี้เป็น “มาตรการชั่วคราวที่เติมทับบนการออกแบบที่เคยตั้งสมมติฐานเรื่องความเชื่อใจเอาไว้ในอดีต” หรือไม่
    ถ้าออกแบบใหม่ตั้งแต่ต้นจะทำให้มันง่ายกว่านี้ได้ไหม และมีระบบปฏิบัติการ (OS) ที่ออกแบบเช่นนั้นอยู่จริงหรือเปล่า

    • ช่องโหว่เป็นสิ่งหลีกเลี่ยงไม่ได้ ยิ่งแพลตฟอร์มรองรับการใช้งานหลากหลายมากเท่าไร
      วิธีรับมือกับเรื่องนี้ก็คือการป้องกันหลายชั้น (Defence-in-depth)

    • iOS มีพื้นฐานมาจาก MacOS และ MacOS ก็มีรากจาก NeXT ซึ่งสืบทอดมาจาก Unix
      มันถูกออกแบบมาโดยคำนึงถึงการไม่ไว้วางใจผู้ใช้ตั้งแต่แรก
      ระดับความไว้วางใจผู้ใช้ก็เปลี่ยนไปตามยุคสมัย และช่วงหลังยังซับซ้อนขึ้นอีกจากความสามารถด้านเครือข่ายที่เชื่อมต่ออยู่ตลอดเวลา รวมถึงภัยคุกคามใหม่หลังยุค Spectre

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

    • seL4 เป็นโครงสร้างไมโครเคอร์เนลที่เร็ว ปลอดภัย และผ่านการพิสูจน์อย่างเป็นทางการ
      มันยอดเยี่ยมทั้งด้านการควบคุมการเข้าถึงระดับสูง การรองรับ virtual machine และอื่น ๆ
      บทความอธิบายสถาปัตยกรรมไมโครเคอร์เนล seL4
      แต่เพราะยังขาด “ส่วนที่เหลือ” อยู่ ผมจึงมองว่ามันใกล้เคียงกับงานวิจัยมากกว่าจะเป็นระบบปฏิบัติการที่ใช้งานจริง

    • ผมคิดว่าอาจลองทำทั้งสองทางก็ได้ไม่ใช่หรือ
      แม้แต่ “ความปลอดภัยฮาร์ดแวร์” เองก็ยังมีสมมติฐานเรื่องความเชื่อถือเฉพาะของมัน แต่สุดท้ายมันก็เป็นเพียงซอฟต์แวร์ที่ฮาร์ดโค้ดไว้ ดังนั้นยิ่งความซับซ้อนเพิ่มขึ้น โอกาสเกิดบั๊กก็ยิ่งเพิ่มตาม

  • ใน Keynote ของ Ivan Krstić ที่งาน Hexacon ครั้งนี้ Apple ประกาศว่าจะยกระดับโปรแกรม bug bounty
    บล็อกทางการที่เกี่ยวข้อง

  • สงสัยว่าปัญหาการเชื่อมต่อแบบ plain text (ไม่ได้เข้ารหัส) ระหว่างการอัปเดตตามรอบหรือเวลารันแอป ได้รับการแก้ไขแล้วหรือยัง
    ข้อมูลอ้างอิงที่เกี่ยวข้อง