AAOS SDV - ออกแบบเพื่อความปลอดภัย

ที่ Google เราเชื่อว่าผลิตภัณฑ์ของเราควรได้รับการออกแบบเพื่อความปลอดภัย ซึ่งเป็นเหตุผลที่เราสร้างระบบปฏิบัติการ Android Automotive สำหรับยานยนต์ที่กำหนดโดยซอฟต์แวร์ (AAOS SDV) บน แพลตฟอร์มที่มีอยู่ซึ่งได้รับการพิสูจน์แล้วว่าใช้งานได้จริง โดยใช้ประโยชน์จากเทคโนโลยีระบบเสมือนจริง เช่น Cuttlefish แม้ว่า ประกาศการเปิดตัวของเราจะมุ่งเน้นไปที่ฟีเจอร์ต่างๆ แต่บล็อกโพสต์นี้จะสรุปแนวคิดด้านความปลอดภัยบางอย่าง

พื้นฐาน: การแยกโดเมน

ระบบเสมือนจริงเพื่อแยกอินสแตนซ์ที่โฮสต์ร่วมกัน

แนวโน้มปัจจุบันในการรวมหน่วยควบคุมอิเล็กทรอนิกส์ (ECU) ไว้ในชิปเดียวจะลดการแยกเนื่องจากมีการเรียกใช้หลายโดเมนควบคู่กันไป

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

ความปลอดภัยของ Android ที่สืบทอดมา

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

การแยกกระบวนการและการปฏิเสธโดยค่าเริ่มต้น

AAOS SDV เป็นไปตามโมเดลการแยกตามรหัสผู้ใช้ (UID) ของ Android เพื่อตั้งค่าแซนด์บ็อกซ์สำหรับแต่ละแอปพลิเคชัน แต่ละบริการจะทำงานในกระบวนการเฉพาะที่มี UID ที่ไม่ซ้ำกันเพื่อจัดการสิทธิ์เข้าถึง ไดเรกทอรีข้อมูล และข้อจำกัดอื่นๆ เราใช้ความสามารถของ Portable Operating System Interface (POSIX) เพื่อจำกัดการดำเนินการอย่างเข้มงวด และใช้ร่วมกับ Security-Enhanced Linux (SELinux) เพื่อบังคับใช้ท่าที "ปฏิเสธโดยค่าเริ่มต้น" แนวทางนี้จำกัดแต่ละบริการให้อยู่ในระดับต่ำสุดที่จำเป็นอย่างยิ่ง ซึ่งหมายความว่าการกำหนดค่าที่ขาดหายไปจะบล็อกการเข้าถึงแทนที่จะสร้างระบบที่มีการอนุญาตมากเกินไป เราใช้กลยุทธ์เดียวกันนี้กับระบบสิทธิ์การสื่อสารของเราตามที่อธิบายไว้ในส่วนท้ายของบทความนี้

การจัดการช่องโหว่ที่ได้รับการพิสูจน์แล้ว

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

ความสมบูรณ์: การเผยแพร่ซอฟต์แวร์ที่ปลอดภัย

นอกเหนือจากการรับประกันการแยกกระบวนการแล้ว แพลตฟอร์มที่ปลอดภัยต้องรับประกันความสมบูรณ์ของโค้ดก่อนการดำเนินการ เราเผยแพร่ซอฟต์แวร์อย่างปลอดภัยผ่านแนวทางต่อไปนี้

การเผยแพร่ซอฟต์แวร์ที่ผ่านการตรวจสอบสิทธิ์

AAOS SDV มีวิธีการติดตั้ง 2 วิธี วิธีแรกคือการติดตั้งซอฟต์แวร์ลงในพาร์ติชันระบบ ผลิตภัณฑ์ หรือผู้ให้บริการแบบอ่านอย่างเดียวโดยตรง ซึ่งจะตรวจสอบลายเซ็นทุกครั้งที่บูต วิธีนี้จะรักษาความปลอดภัยให้กับคอมโพเนนต์ระบบพื้นฐาน

วิธีที่สองคือการใช้แพ็กเกจ Android Pony EXpress (APEX) สำหรับบริการ APEX แต่ละรายการจะห่อหุ้มซอฟต์แวร์และการพึ่งพาอาศัยกัน โดยถือว่าแพ็กเกจเป็นพาร์ติชันที่มีการตรวจสอบลายเซ็นแบบบังคับ ใน AAOS SDV, APEX ถือว่าการลงชื่อโค้ดเป็นสัญญาต่อเนื่องที่บังคับใช้โดยฮาร์ดแวร์ APEX ช่วยลดการเรียกใช้โค้ดที่เป็นอันตรายผ่านเสาหลัก 4 ประการ ได้แก่

1. พื้นที่เก็บข้อมูลที่ไม่เปลี่ยนแปลง

• กลไก: เคอร์เนลของ Android จะวนซ้ำไฟล์ apex_payload.img โดยตรงเป็นอุปกรณ์จัดเก็บข้อมูลดิบโดยใช้ loopback แบบอ่านอย่างเดียว และต่อเชื่อมด้วยแฟล็ก MS_RDONLY ที่เข้มงวด
• เหตุผลที่ปลอดภัยกว่า: วิธีนี้จะไม่แสดงเส้นทางการเขียนไปยังระบบปฏิบัติการเนื่องจากระบบไม่ได้แตกไฟล์ลงในพื้นที่เก็บข้อมูลของยานพาหนะ แม้ว่าผู้โจมตีจะได้รับสิทธิ์ระดับรูท แต่ก็ไม่สามารถแก้ไขโค้ด APEX ที่กำลังทำงานอยู่ได้เนื่องจากเลเยอร์ระบบไฟล์จะปฏิเสธคำสั่งเขียนทั้งหมด

2. ความสมบูรณ์แบบเข้ารหัส

• กลไก: ลายเซ็นแบบเข้ารหัสจะตรวจสอบ Merkle Tree ของอิมเมจระบบไฟล์ทั้งหมด
• เหตุผลที่ปลอดภัยกว่า: เคอร์เนลใช้ dm-verity ต่อบล็อกเพื่อตรวจสอบลายเซ็นสำหรับบล็อกข้อมูลทุกๆ 4 KB แบบเรียลไทม์ หากผู้โจมตีแก้ไขบล็อกดิบบนหน่วยความจำแฟลช เคอร์เนลจะตรวจพบแฮชไม่ตรงกันและหยุดการดำเนินการทันที

3. การแยกกักตัวอย่างเข้มงวด

• กลไก: วิธีนี้จะใช้กฎการแยกกระบวนการตามที่อธิบายไว้ในส่วนการแยกกระบวนการเพื่อสร้างแซนด์บ็อกซ์ โดยติดตั้ง APEX เป็นพาร์ติชันเฉพาะภายใต้ /apex
• เหตุผลที่ปลอดภัยกว่า: แต่ละบริการจะได้รับไดเรกทอรีผู้ใช้และข้อมูลของตนเอง ซึ่งจำกัดการเข้าถึงเว้นแต่จะมีการแชร์อย่างชัดเจน การสร้างพาร์ติชันเฉพาะจะทำให้ Android สร้างเนมสเปซของตัวลิงก์เฉพาะ ซึ่งช่วยให้มั่นใจว่าเฉพาะไลบรารีที่แสดงอย่างชัดเจนเท่านั้นที่จะเข้าถึงได้จากเดมอนระบบที่ไม่ได้รับสิทธิ์ จึงช่วยลดพื้นที่ผิวของการโจมตี

4. การกู้คืนแบบอะตอม

• กลไก: APEX ใช้การออกแบบ "ใช้งาน/สำรอง" เพื่อเปิดใช้ การย้อนกลับแบบบัฟเฟอร์ 2 เท่า APEX ที่แฟลชจากโรงงานจะยังคงอยู่ในพาร์ติชัน /system ที่ไม่เปลี่ยนแปลง ในขณะที่การอัปเดตจะอยู่ในพาร์ติชัน /data ที่เปลี่ยนแปลงได้
• เหตุผลที่ปลอดภัยกว่า: หากการอัปเดตล้มเหลวหรือดูเหมือนเป็นอันตราย เดมอน apexd จะทำเครื่องหมายว่า "ล้มเหลว" ในระหว่างการบูตช่วงแรก ระบบจะสลับลิงก์สัญลักษณ์กลับไปยังพาร์ติชัน /system ทันที การกู้คืนแบบอะตอมนี้ช่วยให้มั่นใจว่าระบบจะไม่ยังคงอยู่ในสถานะที่เสียหาย

ความยืดหยุ่น: การพัฒนาที่ปลอดภัยต่อหน่วยความจำ

การโหลดที่ยืนยันแล้วจะปกป้องระบบจากการแก้ไขภายนอก แต่ความยืดหยุ่นของแพลตฟอร์มยังขึ้นอยู่กับวิธีสร้างโค้ดพื้นฐาน สำหรับคอมโพเนนต์ใหม่ที่พัฒนาขึ้นสำหรับ AAOS SDV เราให้ความสำคัญกับความปลอดภัยของหน่วยความจำ

Rust เป็นภาษาหลัก

AAOS SDV มุ่งเป้าไปที่ระบบขนาดเล็กที่มีข้อกำหนดด้านความพร้อมใช้งานที่รวดเร็ว ซึ่งทำให้ไม่สามารถสร้างบนสแต็ก Android เต็มรูปแบบได้ เราจึงจำกัดขอบเขตไว้ที่เฟรมเวิร์กเนทีฟ เราได้พัฒนาคอมโพเนนต์หลายรายการนอกเหนือจากโครงสร้างพื้นฐานที่มีอยู่และนำ Rust มาใช้เป็นภาษาหลักเพื่อสร้างโครงสร้างพื้นฐานที่จำเป็นสำหรับระบบแบบกระจาย นอกจากนี้ เรายังใช้ Rust เพื่อพัฒนาตรรกะทางธุรกิจของบริการ ซึ่งช่วยให้พาร์ทเนอร์เขียนซอฟต์แวร์ที่ปลอดภัยได้ By design, Rust ใช้ประโยชน์จากฟีเจอร์ความปลอดภัยของหน่วยความจำเพื่อช่วยป้องกันช่องโหว่ด้านความปลอดภัยของหน่วยความจำประเภททั่วไป ในขณะเดียวกันก็รองรับปริมาณงานของทีมเมื่อเขียนโค้ดเนทีฟ.

ความน่าเชื่อถือแบบกระจาย: การควบคุมเครือข่ายและการเข้าถึง

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

การจัดสรรอุปกรณ์และแบบ Mesh

เมชของ AAOS SDV สร้างการตรวจสอบสิทธิ์โดยผูกข้อมูลประจำตัวเครือข์ข่ายของคอมโพเนนต์ทุกรายการทางคณิตศาสตร์กับสถานะการดำเนินการไบนารีจริง โมเดลนี้จะแทนที่ความน่าเชื่อถือของซอฟต์แวร์โดยนัยด้วยการตรวจสอบที่รูทด้วยฮาร์ดแวร์

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

การแยกที่บังคับใช้โดยฮาร์ดแวร์และโปรโตคอลการกักกันอัตโนมัติจะรักษาความปลอดภัยให้กับแพลตฟอร์ม อุปกรณ์เพียร์ภายในเมช SDV ใช้การตรวจสอบสิทธิ์และการรับรองตาม DICE ตามที่อธิบายไว้ในส่วนต่อไปนี้ เพื่อช่วยระบุและควบคุมการดำเนินการโค้ดที่ไม่ได้รับอนุญาตหรือการงัดแงะการกำหนดค่า

TLS ตาม DICE เพื่อรักษาความปลอดภัยให้การสื่อสารระหว่าง VM กับ VM

การยึดข้อมูลประจำตัวของโฮสต์กับความเป็นจริง

กฎทองของ DICE (Device Identifier Composition Engine): หากมีการเปลี่ยนแปลงโค้ดเพียงบรรทัดเดียวในเฟิร์มแวร์ (แม้จะเป็นการอัปเดตเล็กน้อยหรือการใช้ประโยชน์ที่เป็นอันตราย) ตัวระบุอุปกรณ์แบบผสม (CDI) ที่ได้มาจะเปลี่ยนไปทั้งหมด ซึ่งจะสร้างคีย์นามแฝงที่แตกต่างกันโดยสิ้นเชิง

DICE และ TLS (Transport Layer Security) ผสานรวมกันเพื่อแก้ปัญหาพื้นฐานของสถาปัตยกรรมแบบ Zero-Trust นั่นคือ การตรวจสอบสิทธิ์เครื่องไปพร้อมๆ กับการยืนยันความสมบูรณ์ของซอฟต์แวร์

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

ใบรับรองแบบเดิมจะพิสูจน์ได้เพียงการครอบครองข้อมูลลับเท่านั้น แต่ไม่สามารถตรวจจับการงัดแงะเฟิร์มแวร์ได้ DICE แก้ปัญหานี้ผ่าน การจัดเลเยอร์การบูตที่วัดผลได้ ดังนี้

• ข้อมูลลับของอุปกรณ์ที่ไม่ซ้ำกัน (UDS): ข้อมูลลับแบบเข้ารหัสแบบสุ่มที่สร้างขึ้นระหว่างการผลิต เฉพาะบูตโหลดเดอร์ระยะแรกเท่านั้นที่เข้าถึง UDS ได้ โดยซอฟต์แวร์และอินเทอร์เฟซภายนอกอื่นๆ ทั้งหมดจะเข้าถึงไม่ได้
• การวัดผลแบบเลเยอร์ (ตัวระบุอุปกรณ์แบบผสม): ROM ของฮาร์ดแวร์จะเริ่มต้นเชนโดยการแฮช UDS ด้วย โค้ดที่แน่นอนและ การกำหนดค่าของเฟิร์มแวร์เลเยอร์ถัดไป ซึ่งจะสร้าง CDI ซึ่งจะเชื่อมโยงตามลำดับเมื่อบูตแต่ละเลเยอร์ถัดไป

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

การควบคุมการเข้าถึงแบบเลเยอร์

AAOS SDV ใช้กลยุทธ์การป้องกันแบบหลายชั้นเพื่อเปิดใช้การอัปเดตยานพาหนะแบบไดนามิกโดยไม่กระทบต่อกลไกการเข้าถึง โมเดลนี้อาศัยเลเยอร์ความน่าเชื่อถือหลัก 2 เลเยอร์ ได้แก่

1. สิทธิ์ระดับบริการ: กำหนดทรัพยากรเฉพาะที่บริการใน VM ที่กำหนดสามารถเข้าถึงหรือแสดงในเมช
2. สิทธิ์ระดับ VM: กำหนดขอบเขตการสื่อสารระหว่าง VM สำหรับบริการทั้งหมดที่โฮสต์ใน VM ที่เฉพาะเจาะจง

โมเดลนี้ช่วยให้ OEM สามารถสร้างสมดุลระหว่างความปลอดภัยและความสามารถในการอัปเดต สำหรับบริการที่ไม่ไวต่อความปลอดภัย นโยบายระดับ VM ที่อนุญาตจะเปิดใช้การติดตั้งผ่านการอัปเดต APEX แบบเบาแทนการติดตั้งใช้งาน VM ใหม่ทั้งหมด

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

บทสรุป

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

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