ความปลอดภัย

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

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

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

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

  หมายเหตุ: การป้องกันแบบหลายชั้นไม่ได้ป้องกันการสื่อสารกับ pVM ซึ่งทำได้โดยการให้สิทธิ์เข้าถึงแฮนเดิล IBinder ของ pVM

รูปแบบการรักษาความปลอดภัย

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

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

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

สำคัญ: pKVM ได้รับการออกแบบมาเพื่อมอบการป้องกันเพิ่มเติมจากการโจมตีที่มุ่งเป้าไปยังระบบปฏิบัติการ Android ของโฮสต์ บุคคลที่มีสิทธิ์เข้าถึงซัพพลายเชนของอุปกรณ์ เช่น OEM และผู้จำหน่าย SoC จะยังคงต้องเชื่อถือต่อไป Android กำลังลงทุนในเทคโนโลยีขั้นสูงที่ยืนยันคุณสมบัติการแยกของไฮเปอร์วิซอร์และคุณสมบัติสถาปัตยกรรม HW อย่างเป็นทางการ

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

การรักษาข้อมูลลับมาจากพร็อพเพอร์ตี้การแยกหน่วยความจำที่ไฮเปอร์วิซอร์ 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 ออกเป็นสภาพแวดล้อมการดำเนินการที่ไม่น่าเชื่อถือซึ่งกันและกัน พร็อพเพอร์ตี้เหล่านี้จะยังคงมีผลในกรณีที่มีการcompromiseภายใน pVM ใดก็ตาม รวมถึงโฮสต์ ไฮเปอร์วิซอร์ทางเลือกที่เป็นไปตาม AVF จะต้องให้พร็อพเพอร์ตี้ที่คล้ายกัน

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

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

• ระบบจะล้างหน่วยความจำของ pVM ทั้งหมดและเฟิร์มแวร์ pVM จากการบูตอุปกรณ์ 1 เครื่องก่อนให้ 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 ต่างจาก Hypervisor ประเภท 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 ในอุปกรณ์ที่ปลดล็อกเพื่อรักษารูปแบบการรักษาความปลอดภัย

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