ตัวเลือกสำหรับนักพัฒนาแอปที่ปลอดภัย

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

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

หน้านี้อธิบายการใช้งานการอ้างอิงซึ่งประกอบด้วยแอปตัวควบคุมข้อจำกัดการแก้ไขข้อบกพร่องและปลายทางผู้ออกโทเค็นระยะไกล

คำศัพท์

นอกจาก คำศัพท์แล้ว เรายังใช้คำต่อไปนี้ในหน้านี้ด้วย

• JSON Web Signature (JWS) ซึ่งกำหนดไว้ใน RFC 7515
• สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (NIST)

การออกแบบ

ผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) สามารถให้สิทธิ์นักพัฒนาแอปด้วยโทเค็น JSON Web Signature (JWS) (RFC7515) ในการใช้งานการอ้างอิง โทเค็นเพื่อการเข้าถึงจะออกโดย OEM และใช้โดยแอปตัวควบคุมข้อจำกัด โทเค็นเพื่อการเข้าถึงได้รับการออกแบบมาเพื่อป้องกันการโจมตีแบบ Replay และโทเค็นที่ปลอมแปลง

รูปที่ 1 การออกแบบ

การผสานรวมและการกำหนดค่า

ผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) ต้องระบุข้อจำกัดเริ่มต้นในการบูตครั้งแรก โดย OEM จะทำเช่นนี้ด้วยการซ้อนทับทรัพยากรแบบคงที่หลายรายการเพื่อลบล้างค่าเริ่มต้นในเฟรมเวิร์ก AOSP

คุณกำหนดค่าข้อจำกัดเริ่มต้นสำหรับผู้ใช้ระบบแบบไม่มีส่วนหัวได้ด้วยสตริง config_defaultFirstUserRestrictions ใน frameworks/base/core/res/res/values/config.xml เช่น

<!-- User restrictions set when the first user is created.
         Note: Also update appropriate overlay files. -->
    <string-array translatable="false" name="config_defaultFirstUserRestrictions">
        <item>no_debugging_features</item>
        <item>no_install_unknown_sources</item>
        <item>no_install_unknown_sources_globally</item>
    </string-array>

คุณกำหนดค่าข้อจำกัดเริ่มต้นสำหรับคนขับ ผู้โดยสาร และแขกได้ใน frameworks/base/core/res/res/xml/config_user_types.xml OEM สามารถซ้อนทับสตริงเหล่านี้เพื่อกำหนดข้อจำกัดเริ่มต้นสำหรับผู้ใช้แต่ละประเภทตามลำดับ เช่น

<user-types>
    <full-type name="android.os.usertype.full.SECONDARY" >
        <default-restrictions
            no_debugging_features="true"
            no_install_unknown_sources="true"/>
    </full-type>
    <full-type name="android.os.usertype.full.GUEST" >
        <default-restrictions
            no_debugging_features="true"
            no_install_unknown_sources="true"/>
    </full-type>
</user-types>

ตัวควบคุมค่ากำหนดหมายเลขบิลด์

ใน AAOS ระบบจะจัดการการโต้ตอบของผู้ใช้กับแถวค่ากำหนดหมายเลขบิลด์ ในการตั้งค่าโดย BuildNumberPreferenceController.java ซึ่งอยู่ใน packages/apps/Car/Settings/src/com/android/car/settings/system/BuildNumberPreferenceController.java

เมื่อตั้งค่าข้อจำกัดของผู้ใช้ no_debugging_features (UserManager.DISALLOW_DEBUGGING_FEATURES) แล้ว BuildNumberPreferenceController จะระงับการนับถอยหลังสำหรับนักพัฒนาแอปในบิลด์ที่ใช้งานจริง (user) เมื่อมีการแตะ

@Override
protected boolean handlePreferenceClicked(Preference preference) {
    if (DevelopmentSettingsUtil.isDevelopmentSettingsEnabled(getContext())) {
        return true;
    }

    // Enforce restriction on production (user) builds
    if (Build.IS_USER && mUserManager.hasUserRestriction(UserManager.DISALLOW_DEBUGGING_FEATURES)) {
        showToast(R.string.dev_access_blocked_toast);
        return true;
    }

    mDevHitCountdown--;
    if (mDevHitCountdown == 0) {
        DevelopmentSettingsUtil.setDevelopmentSettingsEnabled(getContext(), true);
        showToast(R.string.show_dev_on);
    }
    return true;
}

การใช้ Build.IS_USER จะช่วยให้บิลด์เวอร์ชันที่ใช้งานจริงบังคับใช้การล็อกดาวน์ด้านความปลอดภัยอย่างเข้มงวด ในขณะที่ทีมวิศวกรรมภายในในบิลด์ userdebug ยังคงเข้าถึงตัวเลือกสำหรับนักพัฒนาแอปได้โดยใช้ท่าทางสัมผัสแตะ 7 ครั้งเพื่อทำการทดสอบโดยไม่ต้องลบล้างอินเทอร์เฟซบรรทัดคำสั่ง (CLI) ด้วยตนเอง

ตัวควบคุมข้อจำกัดการแก้ไขข้อบกพร่อง

การใช้งานการอ้างอิงของตัวควบคุมข้อจำกัดการแก้ไขข้อบกพร่อง (DRC) มีให้ใช้งานใน AOSP ที่ packages/apps/Car/DebuggingRestrictionController

DRC ช่วยให้ OEM ยกเลิกข้อจำกัด no_debugging_features ในรถยนต์ที่ใช้งานจริงชั่วคราวและแบบไดนามิกสำหรับช่างเทคนิคและนักพัฒนาแอปที่ได้รับอนุญาต แอป DRC ในรถยนต์จะแจ้งให้ผู้ใช้ตรวจสอบสิทธิ์กับแบ็กเอนด์ของ OEM และส่งโทเค็นเพื่อการเข้าถึงที่ลงชื่อด้วยการเข้ารหัสลับเพื่อเปิดใช้ adb และตัวเลือกสำหรับนักพัฒนาแอปสำหรับเซสชันการวินิจฉัยที่จำกัดเวลา แทนที่จะเปิดเครื่องมือแก้ไขข้อบกพร่องไว้ถาวรหรือกำหนดให้มีการแฟลชเฟิร์มแวร์ใหม่

การใช้งานการอ้างอิงของ DRC ประกอบด้วยคอมโพเนนต์หลัก 2 รายการ ได้แก่

• แอปไคลเอ็นต์ DRC ในรถยนต์ (app/): แอปของระบบที่ได้รับสิทธิ์ (มีสิทธิ์ MANAGE_USERS) ในเครื่องเล่นวิทยุที่ตรวจสอบสิทธิ์นักพัฒนาแอป ตรวจสอบลายเซ็นใบรับรอง X.509, ชื่อโฮสต์, Nonce และการหมดอายุของโทเค็น JWS ขาเข้า รวมถึงสลับข้อจำกัด no_debugging_features แบบไดนามิกโดยใช้ UserManager
• ผู้ออกโทเค็นระบบคลาวด์ (server/): เว็บเซอร์วิสแบ็กเอนด์ (ทำให้ใช้งานได้เป็น Firebase Cloud Functions) ที่ตรวจสอบสิทธิ์ข้อมูลเข้าสู่ระบบของนักพัฒนาแอปและออกโทเค็นเพื่อการเข้าถึง JWS RS256 ที่ลงชื่อด้วยการเข้ารหัสลับพร้อมหน้าต่างการหมดอายุที่จำกัด

ดูวิธีการตั้งค่าทั้งหมด เครื่องมือสร้างใบรับรอง และขั้นตอนการทำให้ใช้งานได้ใน คู่มือการผสานรวมตัวควบคุมข้อจำกัดการแก้ไขข้อบกพร่อง

การทดสอบ

Google ขอแนะนำให้ OEM เริ่มต้นด้วยการใช้งานการอ้างอิงแล้วจึงสร้างต่อจากนั้น

1. หลังจากกำหนดค่าข้อจำกัดในไฟล์ซ้อนทับแล้ว ให้คอมไพล์ AAOS และ ตรวจสอบโฟลว์ที่กำหนด ใช้แอปการอ้างอิงและบริการที่เปิดใช้ JWS ในเครื่อง เพื่อยืนยันการตั้งค่าการเข้าถึง
2. ไม่บังคับ: กำหนดค่าระบบให้ใช้บริการระบบคลาวด์ที่เปิดใช้ JWS ตรวจสอบว่าคุณเห็นโฟลว์ที่คาดไว้ในบริการแบ็กเอนด์