ความปลอดภัย

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

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

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

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

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

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

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

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

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

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