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

ที่ Google เราเชื่อว่าผลิตภัณฑ์ของเราควรได้รับการออกแบบมาให้ปลอดภัย ซึ่งเป็นเหตุผลที่เราสร้างระบบปฏิบัติการ Android Automotive สำหรับยานพาหนะที่กำหนดโดยซอฟต์แวร์ (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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TLS ที่อิงตาม DICE เพื่อรักษาความปลอดภัยในการสื่อสารจาก VM ไปยัง VM

การอิงตัวตนของโฮสต์กับความเป็นจริง

กฎทองของ DICE (เครื่องมือสร้างตัวระบุอุปกรณ์): หากมีการเปลี่ยนแปลงโค้ดบรรทัดเดียวในเฟิร์มแวร์ (แม้จะเป็นการอัปเดตเล็กน้อยหรือการใช้ช่องโหว่ที่เป็นอันตราย) ตัวระบุอุปกรณ์แบบรวม (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