ความปลอดภัย

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

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

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

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

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

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

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

การรักษาความลับและความสมบูรณ์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• เฟิร์มแวร์ pVM จะไม่บูตหากยืนยันรูปภาพเริ่มต้นไม่ได้

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

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

ระบบปฏิบัติการของเครื่องเสมือน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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