การรักษาความปลอดภัยของแอป

หน้านี้อธิบายแง่มุมต่างๆ เกี่ยวกับความปลอดภัยของแอป

องค์ประกอบของแอป

Android มีแพลตฟอร์มโอเพนซอร์สและสภาพแวดล้อมของแอปสำหรับอุปกรณ์เคลื่อนที่ ระบบปฏิบัติการหลักใช้เคอร์เนล Linux แอป Android ส่วนใหญ่มักเขียนด้วยภาษาโปรแกรม Java และทำงานใน เครื่องเสมือน Android Runtime (ART) อย่างไรก็ตาม คุณยังเขียนแอปด้วยโค้ดเนทีฟ ได้ด้วย แอปจะได้รับการติดตั้งจากไฟล์เดียวที่มีนามสกุลไฟล์ APK

องค์ประกอบหลักของแอป Android มีดังนี้

• AndroidManifest.xml: ไฟล์ AndroidManifest.xml เป็นไฟล์ควบคุมที่บอกระบบว่าจะทำอย่างไรกับ คอมโพเนนต์ระดับบนสุดทั้งหมด (โดยเฉพาะกิจกรรม บริการ ตัวรับสัญญาณการออกอากาศ และผู้ให้บริการเนื้อหาที่อธิบายไว้ด้านล่าง) ในแอป นอกจากนี้ยัง ระบุสิทธิ์ที่จำเป็นด้วย

• กิจกรรม: โดยทั่วไป กิจกรรมคือโค้ดสำหรับงานเดียวที่เน้นผู้ใช้โดยใช้คลาส Activity กิจกรรมมักจะรวมถึงการแสดง UI ต่อผู้ใช้ แต่ก็ไม่จำเป็นเสมอไป เนื่องจากบาง กิจกรรมไม่แสดง UI โดยปกติแล้ว กิจกรรมอย่างใดอย่างหนึ่งของแอปจะเป็นจุดเริ่มต้นของแอป

• บริการ: บริการคือส่วนของโค้ดที่ทำงานในเบื้องหลังโดยอิงตามคลาสService ซึ่งสามารถทำงานในกระบวนการของตัวเอง หรือในบริบทของกระบวนการของแอปอื่น คอมโพเนนต์อื่นๆ จะผูกกับ บริการและเรียกใช้เมธอดในบริการผ่านการเรียกใช้กระบวนการระยะไกล ตัวอย่างบริการคือเครื่องเล่นสื่อ แม้ว่าผู้ใช้จะออกจาก UI การเลือกสื่อแล้ว แต่ผู้ใช้ก็อาจยังต้องการให้เพลงเล่นต่อไป บริการจะทำให้เพลงเล่นต่อไปแม้ว่า UI จะทำงานเสร็จแล้วก็ตาม

• ตัวรับสัญญาณการออกอากาศ: ตัวรับสัญญาณการออกอากาศคือออบเจ็กต์ของคลาส BroadcastReceiver ซึ่งจะมีการสร้างอินสแตนซ์เมื่อกลไก IPC ที่เรียกว่า Intent ซึ่งเป็นอินสแตนซ์ของคลาส Intent ได้รับการออกโดยระบบปฏิบัติการหรือแอปอื่น ตัวอย่างเช่น แอป สามารถลงทะเบียนตัวรับสัญญาณสำหรับข้อความแบตเตอรี่เหลือน้อยและ เปลี่ยนลักษณะการทำงานตามข้อมูลดังกล่าวได้

โมเดลสิทธิ์ของ Android: เข้าถึง API ที่ได้รับการป้องกัน

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

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

API ที่ได้รับการป้องกันเหล่านี้ประกอบด้วย

• ฟังก์ชันกล้อง
• ข้อมูลตำแหน่ง (GPS)
• ฟังก์ชันบลูทูธ
• ฟังก์ชันโทรศัพท์
• ฟังก์ชัน SMS/MMS
• การเชื่อมต่อเครือข่าย/ข้อมูล

ทรัพยากรเหล่านี้จะเข้าถึงได้ผ่านระบบปฏิบัติการเท่านั้น หากต้องการใช้ API ที่ได้รับการป้องกันในอุปกรณ์ แอปต้องกำหนด ความสามารถที่ต้องการในไฟล์ Manifest Android ทุกเวอร์ชัน 6.0 ขึ้นไปใช้ โมเดลสิทธิ์รันไทม์ หากผู้ใช้ขอฟีเจอร์จากแอปที่ต้องใช้ API ที่ได้รับการป้องกัน ระบบจะแสดงกล่องโต้ตอบเพื่อแจ้งให้ผู้ใช้ ปฏิเสธ หรือ อนุญาต สิทธิ์

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

ผู้ใช้สามารถดูสิทธิ์ของแอป ที่ติดตั้งไว้ก่อนหน้านี้ได้ในการตั้งค่าอุปกรณ์ นอกจากนี้ ผู้ใช้ยังปิดฟังก์ชันการทำงานบางอย่าง ทั่วโลกได้เมื่อต้องการ เช่น การปิดใช้ GPS, วิทยุ หรือ Wi-Fi

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

สิทธิ์เริ่มต้นของระบบอธิบายไว้ที่ Manifest.permission แอปอาจประกาศสิทธิ์ของตัวเองเพื่อให้แอปอื่นๆ ใช้ สิทธิ์ดังกล่าวจะไม่อยู่ในตำแหน่งที่กล่าวถึงข้างต้น

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

ความสามารถบางอย่างของอุปกรณ์ เช่น ความสามารถในการส่ง Intent การออกอากาศทาง SMS จะไม่พร้อมใช้งานสำหรับแอปของบุคคลที่สาม แต่แอปที่ติดตั้งไว้ล่วงหน้าโดย OEM อาจใช้ความสามารถเหล่านี้ได้ สิทธิ์เหล่านี้ใช้สิทธิ์ signatureOrSystem

วิธีที่ผู้ใช้เข้าใจแอปของบุคคลที่สาม

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

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

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

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

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

สิทธิ์ในการติดตั้งแอป - Google แปลภาษา	สิทธิ์ของแอปที่ติดตั้ง - Gmail

รูปที่ 1 การแสดงสิทธิ์ของแอป

การสื่อสารระหว่างโปรเซส

โปรเซสสามารถสื่อสารโดยใช้กลไกแบบ Unix ดั้งเดิม ตัวอย่างเช่น ระบบไฟล์ ซ็อกเก็ตภายใน หรือสัญญาณ อย่างไรก็ตาม สิทธิ์ของ Linux จะยังคงมีผล

นอกจากนี้ Android ยังมีกลไก IPC ใหม่ๆ ดังนี้

• Binder: กลไกการเรียกใช้โพรซีเยอร์ระยะไกล (RPC) แบบเบาที่อิงตามความสามารถ ซึ่งออกแบบมาให้มีประสิทธิภาพสูงเมื่อทำการเรียกใช้ในโปรเซสและข้ามโปรเซส Binder ได้รับการติดตั้งใช้งานโดยใช้ไดรเวอร์ Linux ที่กำหนดเอง ดูคำอธิบายของคลาสได้ที่ Binder

• บริการ: บริการสามารถมอบอินเทอร์เฟซที่เข้าถึงได้โดยตรง โดยใช้ Binder ดูคำอธิบายโดยละเอียดเพิ่มเติมได้ที่ องค์ประกอบของแอป

• Intent: Intent คือออบเจ็กต์ข้อความอย่างง่ายที่แสดงถึง ความตั้งใจที่จะทำบางสิ่ง ตัวอย่างเช่น หากแอปต้องการแสดง หน้าเว็บ แอปจะแสดง Intent ที่จะดู URL โดยการสร้างอินสแตนซ์ Intent และส่งต่ออินสแตนซ์นั้นไปยังระบบ ระบบจะค้นหาโค้ดอื่นๆ (ในกรณีนี้คือเบราว์เซอร์) ที่รู้วิธีจัดการ Intent นั้นและ เรียกใช้โค้ดดังกล่าว นอกจากนี้ยังสามารถใช้ Intent เพื่อออกอากาศเหตุการณ์ที่น่าสนใจ (เช่น การ แจ้งเตือน) ทั่วทั้งระบบได้ด้วย ดูคำอธิบายของคลาสได้ที่ Intent

• ผู้ให้บริการเนื้อหา: ผู้ให้บริการเนื้อหาคือที่เก็บข้อมูลที่ให้สิทธิ์ เข้าถึงข้อมูลในอุปกรณ์ ตัวอย่างคลาสสิกคือผู้ให้บริการเนื้อหาที่ ใช้ในการเข้าถึงรายชื่อติดต่อของผู้ใช้ แอปสามารถเข้าถึงข้อมูล ที่แอปอื่นๆ เปิดเผยด้วยผู้ให้บริการเนื้อหา และแอป ยังกำหนดผู้ให้บริการเนื้อหาของตัวเองเพื่อเปิดเผยข้อมูลของตัวเองได้ด้วย ดูคำอธิบายของคลาสได้ที่ ContentProvider

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

API ที่อาจมีค่าใช้จ่าย

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

• โทรศัพท์
• SMS/MMS
• เครือข่าย/ข้อมูล
• การเรียกเก็บเงินสำหรับการซื้อในแอป
• การเข้าถึง NFC

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

การเข้าถึงซิมการ์ด

แอปของบุคคลที่สามจะเข้าถึงซิมการ์ดในระดับต่ำไม่ได้ ระบบปฏิบัติการจะจัดการการสื่อสารทั้งหมดกับซิมการ์ด รวมถึงการเข้าถึงข้อมูลส่วนบุคคล (รายชื่อติดต่อ) ในหน่วยความจำซิมการ์ด นอกจากนี้ แอปยังเข้าถึงคำสั่ง AT ไม่ได้ เนื่องจากคำสั่งเหล่านี้ได้รับการจัดการโดย Radio Interface Layer (RIL) เท่านั้น RIL ไม่มี API ระดับสูงสำหรับคำสั่งเหล่านี้

ข้อมูลส่วนบุคคล

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

รูปที่ 2 การเข้าถึงข้อมูลผู้ใช้ที่ละเอียดอ่อนจะทำได้ผ่าน API ที่ได้รับการป้องกันเท่านั้น

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

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

อุปกรณ์ป้อนข้อมูลที่ละเอียดอ่อน

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

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

ข้อมูลเมตาของอุปกรณ์

Android ยังมุ่งมั่นที่จะจำกัดการเข้าถึงข้อมูลที่ไม่ละเอียดอ่อนโดยเนื้อแท้ แต่ข้อมูลดังกล่าวอาจเปิดเผยลักษณะของผู้ใช้ ความชอบของผู้ใช้ และลักษณะการใช้ของผู้ใช้โดยอ้อม

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

ผู้ออกใบรับรอง

Android มีชุดผู้ออกใบรับรองของระบบที่ติดตั้งไว้ ซึ่งเป็นที่เชื่อถือได้ทั่วทั้งระบบ ก่อน Android 7.0 ผู้ผลิตอุปกรณ์สามารถแก้ไขชุด CA ที่จัดส่งในอุปกรณ์ของตนได้ อย่างไรก็ตาม อุปกรณ์ที่ใช้ Android 7.0 ขึ้นไปจะมีชุด CA ของระบบที่เหมือนกัน เนื่องจากผู้ผลิตอุปกรณ์ไม่ได้รับอนุญาตให้แก้ไขอีกต่อไป

หากต้องการเพิ่มเป็น CA สาธารณะใหม่ในชุด CA ของ Android CA ต้องดำเนินการตามกระบวนการรวม CA ของ Mozilla ให้เสร็จสมบูรณ์ จากนั้นยื่นคำขอฟีเจอร์กับ Android ( https://code.google.com/p/android/issues/entry) เพื่อเพิ่ม CA ลงในชุด CA ของ Android ใน โครงการโอเพนซอร์ส Android (AOSP)

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

App Signing

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

ใน Google Play การลงนามแอปจะเชื่อมโยงความไว้วางใจที่ Google มีต่อนักพัฒนาแอปและความไว้วางใจที่นักพัฒนาแอปมีต่อแอปของตน นักพัฒนาแอปทราบว่าแอปของตนได้รับการจัดหาให้แก่อุปกรณ์ Android โดยไม่มีการแก้ไข และนักพัฒนาแอปต้องรับผิดชอบต่อลักษณะการทำงานของแอป

ใน Android การลงนามแอปเป็นขั้นตอนแรกในการวางแอปไว้ใน App Sandbox ใบรับรองแอปที่ลงนามจะกำหนดว่ารหัสผู้ใช้ ใดเชื่อมโยงกับแอปใด แอปต่างๆ จะทำงานภายใต้ รหัสผู้ใช้ที่แตกต่างกัน App Signing ช่วยให้มั่นใจว่าแอปหนึ่งจะไม่สามารถ เข้าถึงแอปอื่นๆ ได้ ยกเว้นผ่าน IPC ที่กำหนดไว้อย่างชัดเจน

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

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

นอกจากนี้ แอปยังประกาศสิทธิ์ด้านความปลอดภัยในระดับการป้องกันลายเซ็น ได้ด้วย ซึ่งจะจำกัดการเข้าถึงเฉพาะแอปที่ลงนามด้วยคีย์เดียวกัน ในขณะที่ยังคง UID และ Application Sandbox ที่แตกต่างกัน ระบบอนุญาตให้มีความสัมพันธ์ใกล้ชิดกับ Application Sandbox ที่แชร์ผ่านฟีเจอร์ UID ที่แชร์ ซึ่งแอป 2 รายการขึ้นไปที่ลงนามด้วยคีย์นักพัฒนาแอปเดียวกันสามารถ ประกาศ UID ที่แชร์ในไฟล์ Manifest ได้

การตรวจสอบแอป

Android 4.2 ขึ้นไปรองรับการตรวจสอบแอป ผู้ใช้สามารถเลือกที่จะ เปิดใช้ ยืนยันแอป และให้ผู้ยืนยันแอปประเมินแอป ก่อนการติดตั้ง การตรวจสอบแอปสามารถแจ้งเตือนผู้ใช้หากผู้ใช้พยายามที่จะ ติดตั้งแอปที่อาจเป็นอันตราย และหากแอปไม่ดีเป็นพิเศษ ระบบ จะบล็อกการติดตั้ง

การจัดการสิทธิ์ดิจิทัล

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

เฟรมเวิร์ก DRM ของ Android ได้รับการติดตั้งใช้งานใน 2 เลเยอร์สถาปัตยกรรม (ดูรูปที่ 3) ดังนี้

• API เฟรมเวิร์ก DRM ซึ่งเปิดเผยต่อแอปผ่านเฟรมเวิร์กแอป Android และทำงานผ่าน ART VM สำหรับแอปมาตรฐาน

• ตัวจัดการ DRM ของโค้ดแบบเนทีฟ ซึ่งติดตั้งใช้งานเฟรมเวิร์ก DRM และเปิดเผยอินเทอร์เฟซสำหรับปลั๊กอิน (เอเจนต์) DRM เพื่อจัดการการจัดการสิทธิ์และการถอดรหัสสำหรับรูปแบบ DRM ต่างๆ

รูปที่ 3 สถาปัตยกรรมของ DRM ในแพลตฟอร์ม Android