ความปลอดภัย

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

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

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

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

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

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

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

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

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

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

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

การรักษาความลับและความซื่อสัตย์

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

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

ความสมบูรณ์ ใช้กับข้อมูลในหน่วยความจำ และ การคำนวณ pVM ไม่สามารถ:

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

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

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

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

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

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

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

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

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

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

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

• เฟิร์มแวร์ pVM จะไม่บูตหากไม่สามารถตรวจสอบอิมเมจเริ่มต้นได้

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

• Boot Certificate Chain (BCC) และ Compound Device Identifiers (CDI) ที่มอบให้กับอินสแตนซ์ pVM สามารถรับได้จากอินสแตนซ์นั้นเท่านั้น

ระบบปฏิบัติการเกสต์

Microdroid เป็นตัวอย่างของระบบปฏิบัติการที่ทำงานภายใน pVM Microdroid ประกอบด้วย bootloader ที่ใช้ 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 ให้การรับรองห่วงโซ่การบูต

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

• BCC และ CDI ที่มอบให้กับอินสแตนซ์ pVM สามารถรับได้จากอินสแตนซ์นั้นเท่านั้น

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

หุ่นยนต์

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

• Guest pVM ไม่สามารถโต้ตอบโดยตรงกับ pVM แขกอื่นๆ (เช่น ทำการเชื่อมต่อ vsock )

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

  หมายเหตุ: สามารถส่งผ่านช่องทางที่จัดตั้งขึ้นไปยังผู้อื่นได้

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

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

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

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

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

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

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

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

บูตอย่างปลอดภัย

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

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

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

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

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

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

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