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

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

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

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

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

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

การรักษาความปลอดภัยของ Android ที่รับค่ามา

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

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

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

Proven Vulnerability Management

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

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

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

การนำส่งซอฟต์แวร์ที่ตรวจสอบสิทธิ์แล้ว

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

ประการที่ 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. การแยกแบบเข้มงวด

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การสร้างตัวตนของโฮสต์ให้เป็นจริง

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

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

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

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

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

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

การควบคุมการเข้าถึงแบบแบ่งชั้น

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

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

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

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

บทสรุป

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

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