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

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

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

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

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

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

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

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

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

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

Proven Vulnerability Management

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

บทสรุป

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

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