ความปลอดภัย

Android VirtualizationFramework (AVF) ใช้วิธีการรักษาความปลอดภัยแบบเลเยอร์โดยที่แต่ละเลเยอร์จะมีการบังคับใช้เพิ่มเติม เพื่อป้องกันการเรียกใช้เพย์โหลดที่กำหนดเองภายใน pVM รายการเลเยอร์ความปลอดภัยของ AVF มีดังนี้

• Android จะตรวจสอบว่ามีเพียงแอปที่มีสิทธิ์ pVM เท่านั้นที่ได้รับอนุญาตให้สร้างหรือตรวจสอบ pVM

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

• pVM มีการป้องกันเชิงลึก เช่น SELinux สำหรับเพย์โหลดที่ทำงานใน pVM การป้องกันในเชิงลึกไม่อนุญาตให้ข้อมูลการแมปเป็นไฟล์ปฏิบัติการ (neverallow execmem) และรับรองว่า W^X จะเก็บไฟล์ทุกประเภท

โมเดลความปลอดภัย

การรักษาข้อมูลที่เป็นความลับ ความสมบูรณ์ และความพร้อมใช้งาน (CIA Triad) ประกอบขึ้นเป็นโมเดลที่ออกแบบมาเพื่อเป็นแนวทางของนโยบายความปลอดภัยของข้อมูล

• การรักษาข้อมูลที่เป็นความลับคือชุดของกฎที่จำกัดการเข้าถึงข้อมูล
• ความซื่อสัตย์คือการรับรองว่าข้อมูลเชื่อถือได้และถูกต้อง
• ความพร้อมใช้งานเป็นการรับประกันการเข้าถึงข้อมูลที่เชื่อถือได้โดยบุคคลที่ได้รับอนุญาต

การรักษาข้อมูลที่เป็นความลับและความสมบูรณ์

การรักษาข้อมูลที่เป็นความลับเกิดขึ้นจากพร็อพเพอร์ตี้การแยกหน่วยความจำที่บังคับใช้โดย pKVM Hypervisor โดย pKVM จะติดตามการเป็นเจ้าของหน่วยความจำของหน้าหน่วยความจำจริงแต่ละหน้าและคำขอใดๆ จากเจ้าของสำหรับหน้าเว็บที่จะแชร์ pKVM จะดูแลให้มีเพียง pVM ที่มีสิทธิ์ (โฮสต์และผู้มาเยือน) เท่านั้นที่แมปหน้าที่ระบุในตารางหน้าขั้นที่ 2 ซึ่งควบคุมโดยไฮเปอร์ไวเซอร์ สถาปัตยกรรมนี้ทำให้เนื้อหาของหน่วยความจำที่เป็นของ pVM ยังคงเป็นส่วนตัว เว้นแต่เจ้าของจะแชร์เนื้อหาดังกล่าวกับ pVM อื่นอย่างชัดแจ้ง

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

ความสมบูรณ์จะมีผลกับข้อมูลในหน่วยความจำและการคํานวณ pVM จะทำสิ่งต่อไปนี้ไม่ได้

• แก้ไขความทรงจำของกันและกันโดยไม่ต้องได้รับความยินยอม
• กำหนดสถานะ CPU ของกันและกัน

ข้อกำหนดเหล่านี้บังคับใช้โดย Hypervisor อย่างไรก็ตาม ปัญหาด้านความสมบูรณ์ของข้อมูลยังเกิดขึ้นกับพื้นที่เก็บข้อมูลเสมือนเมื่อต้องใช้โซลูชันอื่นๆ เช่น dm-verity หรือ AuthFS ด้วย

หลักการเหล่านี้ไม่แตกต่างจากการแยกกระบวนการที่นำเสนอโดย Linux ซึ่งการเข้าถึงหน้าหน่วยความจำถูกควบคุมด้วยตารางหน้าขั้นที่ 1 และการสลับบริบทของเคอร์เนลระหว่างกระบวนการ อย่างไรก็ตาม ส่วน EL2 ของ pKVM ซึ่งบังคับใช้คุณสมบัติเหล่านี้มีลำดับขั้นในการโจมตีน้อยกว่าถึง 3 ลำดับเมื่อเทียบกับเคอร์เนลของ Linux ทั้งหมด (ราวๆ 10,000 เทียบกับ 20 ล้านบรรทัด) จึงให้ความมั่นใจได้มากกว่ากรณีการใช้งานที่มีความละเอียดอ่อนเกินไปที่ต้องอาศัยการแยกกระบวนการ

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

ส่วนที่เหลือของหน้านี้กล่าวถึงการรักษาข้อมูลที่เป็นความลับและการรับประกันความสมบูรณ์ที่องค์ประกอบแต่ละอย่างเกี่ยวกับ pKVM มีให้

ไฮเปอร์ไวเซอร์

pKVM เป็นไฮเปอร์ไวเซอร์ที่ใช้ KVM ซึ่งแยก pVM และ Android ในสภาพแวดล้อมการดำเนินการที่ไม่น่าเชื่อถือซึ่งกันและกัน พร็อพเพอร์ตี้เหล่านี้จะระงับไว้ในกรณีที่เกิดการละเมิดภายใน pVM ใดๆ รวมถึงโฮสต์ ไฮเปอร์ไวเซอร์สำรองที่ปฏิบัติตาม AVF จะต้องให้พร็อพเพอร์ตี้ที่คล้ายกัน

• pVM จะเข้าถึงหน้าเว็บที่เป็นของเอนทิตีอื่นไม่ได้ เช่น pVM หรือ Hypervisor เว้นแต่เจ้าของหน้าเว็บจะแชร์ไว้อย่างชัดแจ้ง กฎนี้รวมถึง pVM ของโฮสต์และมีผลกับทั้งการเข้าถึง CPU และ DMA

• ก่อนที่ pVM จะใช้ระบบจะส่งคืนไปยังโฮสต์ เช่น เมื่อ pVM ถูกทำลาย ระบบก็จะล้างข้อมูลออก

• ระบบจะล้างข้อมูลหน่วยความจำของ pVM และเฟิร์มแวร์ pVM ทั้งหมดจากการเปิดเครื่องของอุปกรณ์หนึ่งก่อนที่ Bootloader ของระบบปฏิบัติการจะทำงานในการเปิดเครื่องครั้งถัดไป

• เมื่อมีการแนบโปรแกรมแก้ไขข้อบกพร่องของฮาร์ดแวร์ เช่น SJTAG pVM จะเข้าถึงคีย์ที่สร้างก่อนหน้านี้ไม่ได้

• เฟิร์มแวร์ pVM จะไม่เปิดเครื่องหากยืนยันอิมเมจเริ่มต้นไม่ได้

• เฟิร์มแวร์ pVM จะไม่เปิดเครื่องหากความสมบูรณ์ของ instance.img ถูกบุกรุก

• เชนใบรับรอง DICE และตัวระบุอุปกรณ์แบบผสม (CDI) ที่ให้ไว้กับอินสแตนซ์ pVM จะดึงมาจากอินสแตนซ์นั้นได้เท่านั้น

ระบบปฏิบัติการของผู้มาเยือน

Microdroid เป็นตัวอย่างของระบบปฏิบัติการที่ทำงานภายใน pVM Microdroid ประกอบด้วย Bootloader ที่ใช้ U-boot, GKI และส่วนย่อยของพื้นที่ผู้ใช้ Android รวมถึงเพย์โหลด Launcher ระบบจะเก็บพร็อพเพอร์ตี้เหล่านี้ไว้ในกรณีที่เกิดการบุกรุกภายใน pVM รวมถึงโฮสต์ ระบบปฏิบัติการอื่นที่ทำงานใน pVM ควรให้คุณสมบัติที่คล้ายกัน

• Microdroid จะไม่เปิดเครื่องหากยืนยัน boot.img, super.img, vbmeta.img หรือ vbmeta\_system.img ไม่ได้

• Microdroid จะไม่เริ่มทำงานหากการยืนยัน APK ล้มเหลว

• อินสแตนซ์ Microdroid เดียวกันจะไม่สามารถเปิดเครื่องได้แม้ว่าจะอัปเดต APK แล้วก็ตาม

• Microdroid จะไม่เปิดเครื่องหาก APEX ไม่ผ่านการยืนยัน

• Microdroid จะไม่เปิดเครื่อง (หรือเปิดเครื่องด้วยสถานะเริ่มต้นที่ชัดเจน) หากมีการแก้ไข instance.img นอก pVM ของผู้เข้าร่วม

• Microdroid ให้เอกสารรับรองไปยังเชนการเปิดเครื่อง

• การแก้ไข (ไม่มีการรับรอง) ในอิมเมจดิสก์ที่แชร์กับ pVM ของผู้เข้าร่วมจะทำให้เกิดข้อผิดพลาด I/O ในฝั่ง pVM

• เชนใบรับรอง DICE และ CDI ที่มอบให้กับอินสแตนซ์ pVM จะดึงมาได้ด้วยอินสแตนซ์ดังกล่าวเท่านั้น

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

Android

พร็อพเพอร์ตี้ต่อไปนี้มีการดูแลโดย Android ในฐานะโฮสต์ แต่จะไม่เป็นจริงในกรณีที่โฮสต์ถูกบุกรุก

• pVM ของผู้เข้าร่วมจะโต้ตอบกับ pVM ของผู้เข้าร่วมรายอื่นโดยตรง (เช่น เพื่อทำการเชื่อมต่อ vsock) ไม่ได้

• มีเพียง VirtualizationService ใน pVM ของโฮสต์เท่านั้นที่สร้างช่องทางการสื่อสารไปยัง pVM ได้

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

• ระบบจะไม่ใช้ตัวระบุที่เรียกว่าตัวระบุบริบท (CID) ซึ่งใช้ในการตั้งค่าการเชื่อมต่อ vsock ระหว่างโฮสต์และ pVM ซ้ำเมื่อ pVM ของโฮสต์ทำงานอยู่ เช่น คุณจะแทนที่ pVM ที่ทำงานอยู่ด้วยรายการอื่นไม่ได้

ความพร้อมใช้งาน

ในบริบทของ pVM แล้ว availability หมายถึงโฮสต์ที่จัดสรรทรัพยากรให้แขกอย่างเพียงพอเพื่อให้แขกสามารถทำงานตามที่ออกแบบมาได้

โดยโฮสต์จะเป็นผู้รับผิดชอบการกำหนดเวลา CPU เสมือนของ pVM KVM ซึ่งต่างจากไฮเปอร์ไวเซอร์ Type-1 ทั่วไป (เช่น Xen) ทำการตัดสินใจออกแบบที่ชัดเจนเพื่อมอบสิทธิ์การกำหนดเวลาภาระงานให้กับเคอร์เนลของโฮสต์ เนื่องด้วยขนาดและความซับซ้อนของเครื่องมือจัดตารางเวลาในปัจจุบัน การตัดสินใจเกี่ยวกับการออกแบบนี้ช่วยลดขนาดของฐานระบบคอมพิวเตอร์ที่เชื่อถือได้ (TCB) ลงได้อย่างมาก และช่วยให้โฮสต์สามารถตัดสินใจเรื่องกำหนดการได้อย่างสมเหตุสมผลเพื่อเพิ่มประสิทธิภาพ แต่โฮสต์ที่เป็นอันตรายอาจเลือกไม่กำหนดเวลาให้แขกรับเชิญ

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

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

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

การเปิดเครื่องที่ปลอดภัย

ข้อมูลจะเชื่อมโยงกับอินสแตนซ์ของ pVM และการเปิดเครื่องที่ปลอดภัยช่วยให้มั่นใจว่าระบบควบคุมการเข้าถึงข้อมูลของอินสแตนซ์ได้ การเปิดเครื่องครั้งแรกของอินสแตนซ์จะจัดสรรโดยสุ่มสร้าง Salt ลับสำหรับ pVM และดึงรายละเอียด เช่น คีย์สาธารณะและแฮชสำหรับการยืนยันจากอิมเมจที่โหลด ข้อมูลนี้จะใช้เพื่อยืนยันการเปิดเครื่องครั้งต่อๆ ไปของอินสแตนซ์ pVM และตรวจสอบว่ามีการเผยแพร่ข้อมูลลับของอินสแตนซ์ไปยังรูปภาพที่ผ่านการตรวจสอบแล้วเท่านั้น กระบวนการนี้จะเกิดขึ้นในทุกขั้นตอนการโหลดภายใน pVM ได้แก่ เฟิร์มแวร์ pVM, pVM ABL, Microdroid และอื่นๆ

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

แต่ละระยะจะส่งออบเจ็กต์ CBOR ที่เข้ารหัสตามที่กำหนดไว้ไปยังขั้นตอนถัดไป ออบเจ็กต์นี้มีข้อมูลลับและห่วงโซ่ใบรับรอง DICE ซึ่งมีข้อมูลสถานะสะสม เช่น ขั้นตอนสุดท้ายที่โหลดอย่างปลอดภัยหรือไม่

อุปกรณ์ที่ปลดล็อกแล้ว

เมื่อปลดล็อกอุปกรณ์ด้วย fastboot oem unlock ระบบจะล้างข้อมูลผู้ใช้ ขั้นตอนนี้จะปกป้องข้อมูลผู้ใช้จากการเข้าถึงที่ไม่ได้รับอนุญาต ข้อมูลที่เป็นส่วนตัวสำหรับ pVM จะใช้ไม่ได้เช่นกันเมื่อมีการปลดล็อกอุปกรณ์

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

บุคคลระยะไกลจะเฝ้าสังเกตสถานะที่อาจไม่ปลอดภัยนี้ได้โดยตรวจสอบสถานะการเปิดเครื่องที่ได้รับการยืนยันของอุปกรณ์ในใบรับรองเอกสารรับรองคีย์