จำเป็นต้องมีการป้องกันการย้อนกลับของ Android Oreo บนโทรศัพท์ที่เปิดตัวด้วย Android Pie

ระบบปฏิบัติการ Android พาย (Android 9) เพิ่งถ่ายทอดสดวันนี้ สำหรับ Google Pixel, Google Pixel 2 และ แม้แต่ โทรศัพท์ที่จำเป็น เรากำลังเรียนรู้ให้มากที่สุดเท่าที่จะทำได้เกี่ยวกับการเปิดตัวจากการสัมภาษณ์ (Google Pixel 3 จะมีแต่การนำทางด้วยท่าทางเท่านั้น!), ที่ รหัส AOSP ลดลงและสุดท้ายคือเอกสารข้อกำหนดความเข้ากันได้ (CDD) เราโพสต์เกี่ยวกับ คุณสมบัติใหม่สำหรับแอป "เฮฟวี่เวท" ก่อนหน้านี้ แต่ตอนนี้เราพบว่า Google ได้เปลี่ยนถ้อยคำในฟีเจอร์ที่เปิดตัวใน Android Oreo: การป้องกันการย้อนกลับ. คุณลักษณะนี้เกิดขึ้นได้โดย Android ยืนยันบูท 2.0 (หรือเรียกง่ายๆ ว่า Verified Boot) อย่างไรก็ตาม OEM ไม่จำเป็นต้องใช้ AVB 2.0 ในรุ่น Oreo ขณะนี้ Google กำลังกำหนดว่าอุปกรณ์ทั้งหมดที่เปิดตัวด้วย Android Pie รองรับ Verified Boot และโดยการขยายการป้องกันการย้อนกลับ

การป้องกันการย้อนกลับใน Android Oreo

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

คุณลักษณะนี้มีอยู่ในอุปกรณ์เช่น Google Pixel 2, Razer Phone และ OnePlus 6 แต่ไม่มีอยู่ในอุปกรณ์อื่น ๆ เช่น Samsung Galaxy S9 (แม้ว่า Samsung จะมีรูปแบบของตัวเอง การป้องกันการย้อนกลับใน Knox.) ขณะนี้ Google กำลังสร้างฟีเจอร์นี้ที่จำเป็นสำหรับอุปกรณ์ใดๆ ก็ตามที่เปิดตัวด้วย Android Pie

ยืนยันการบูตใน Android Pie

ตามข้อความที่อัปเดตในส่วน "ความสมบูรณ์ของอุปกรณ์" ในเอกสารคำจำกัดความความเข้ากันได้ อุปกรณ์ที่เปิดใช้ Android 9 จะต้องรองรับ Verified Boot

9.10. ความสมบูรณ์ของอุปกรณ์

ข้อกำหนดต่อไปนี้ช่วยให้แน่ใจว่าสถานะของความสมบูรณ์ของอุปกรณ์มีความโปร่งใส การใช้งานอุปกรณ์:

• [C-0-1] ต้องรายงานอย่างถูกต้องผ่านเมธอด System API PersistentDataBlockManager.getFlashLockState() ว่าสถานะ bootloader อนุญาตให้มีการกะพริบของอิมเมจระบบหรือไม่ สถานะ FLASH_LOCK_UNKNOWN สงวนไว้สำหรับการใช้งานอุปกรณ์ที่อัปเกรดจาก Android เวอร์ชันก่อนหน้า โดยที่ไม่มีวิธี API ของระบบใหม่นี้
• [C-0-2] ต้องรองรับ Verified Boot เพื่อความสมบูรณ์ของอุปกรณ์

หากมีการเปิดตัวการใช้งานอุปกรณ์โดยไม่รองรับ Verified Boot บน Android เวอร์ชันก่อนหน้า และไม่สามารถเพิ่มการรองรับคุณสมบัตินี้ได้ด้วยการอัพเดตซอฟต์แวร์ระบบ อาจได้รับการยกเว้นจาก ความต้องการ.

...

• [C-1-10] ต้องใช้การป้องกันการย้อนกลับสำหรับพาร์ติชันที่ใช้โดย Android (เช่นการบูต พาร์ติชันระบบ) และใช้พื้นที่จัดเก็บข้อมูลที่ป้องกันการงัดแงะเพื่อจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดระบบปฏิบัติการขั้นต่ำที่อนุญาต รุ่น
• ควรใช้การป้องกันการย้อนกลับสำหรับส่วนประกอบใดๆ ที่มีเฟิร์มแวร์ถาวร (เช่น โมเด็ม กล้อง) และ ควรใช้ที่เก็บข้อมูลแบบป้องกันการงัดแงะเพื่อจัดเก็บข้อมูลเมตาที่ใช้ในการกำหนดขั้นต่ำที่อนุญาต รุ่น

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

สมาชิกอาวุโส XDA เอ็นพีจอห์นสันซึ่งเป็นสมาชิกของทีม LineageOS คาดการณ์ว่าจะต้องมีการป้องกันการย้อนกลับบนพาร์ติชันที่มีเฟิร์มแวร์ถาวร ต้องการ Secondary Bootloader (SBL) และ eXtensible Bootloader (XBL) tie-ins เนื่องจากพาร์ติชันเหล่านี้ถูกเมาท์ก่อนหน้านี้ในการบู๊ต กระบวนการ. อาจมีค่าใช้จ่ายสูงสำหรับ OEM ขนาดเล็กในการใช้ XBL แบบกำหนดเองเพื่อให้ตรงกับโมเด็มแบบกำหนดเองและพาร์ติชันถาวรอื่น ๆ ดังนั้นบางที Google ไม่ได้สร้างข้อกำหนดนี้เพื่อให้ผู้ผลิตอุปกรณ์ปฏิบัติตามข้อกำหนดล่าสุดใน CDD ได้ง่ายขึ้น

วิธีตรวจสอบว่าโทรศัพท์ของคุณรองรับ AVB 2.0 หรือไม่

มีคำสั่งเชลล์ ADB สองคำสั่งที่คุณสามารถใช้เพื่อตรวจสอบว่าโทรศัพท์ของคุณรองรับ AVB 2.0 หรือไม่

adb shell
dumpsys package | grep "verified_boot"

หรือ

adb shell
getprop | grep "avb"

หากเอาต์พุตของคำสั่งแรกคือ "android.software.verified_boot" แสดงว่ารองรับ AVB 2.0 หากเอาต์พุตของคำสั่งที่สองแสดง "[ro.boot.avb_version]" และ "[ro.boot.vbmeta.avb_version]" และแสดงหมายเลขเวอร์ชันสำหรับแต่ละคำสั่ง แสดงว่าระบบได้รับการรองรับ

การตรวจสอบการบูตและการพัฒนาแบบกำหนดเอง

Android Verified Boot ไม่มีผลกับผู้ใช้ ROM แบบกำหนดเองส่วนใหญ่ แม้ว่าจะเพิ่มการรักษาความปลอดภัยอีกชั้นที่คุณต้องแก้ไขในบางกรณีก็ตาม ตัวอย่างเช่น กระพริบอิมเมจระบบทั่วไป จำเป็นต้องปิดการใช้งาน AVB การแก้ไขพาร์ติชันบางอย่างเช่นผู้จำหน่ายใน OnePlus 6 จำเป็นต้องปิดการใช้งาน AVB เช่นกัน อย่างที่ฉันเพิ่งเรียนรู้. ตาม เอ็นพีจอห์นสันการติดตั้ง AVB 2.0 อย่างถูกต้องทำให้อิมเมจสำหรับบูตแบบกำหนดเองสามารถทำงานร่วมกับโปรแกรมโหลดบูตที่ล็อคได้ เราจะดูว่าการรวม AVB 2.0 ไว้ในอุปกรณ์ที่จัดส่งพร้อมกับ Android Pie ส่งผลต่อภูมิทัศน์อย่างไร แต่เราหวังว่ามันจะไม่ส่งผลให้เกิดสถานการณ์เช่น ล่าสุดทำให้ตกใจมาก ในชุมชน Xiaomi Redmi Note 5 Pro Mandatory AVB 2.0 เป็นเพียงอีกวิธีหนึ่งที่ Google ทำ ปรับปรุงความปลอดภัยของแพลตฟอร์ม Androidแต่การเปลี่ยนแปลงที่ใหญ่ที่สุดในมุมมองของเราคือ การปรับปรุงข้อตกลง OEM เพื่อบังคับใช้แพทช์รักษาความปลอดภัยตามปกติ.