ความปลอดภัยของแอปพลิเคชัน

องค์ประกอบของการประยุกต์ใช้งาน

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

โครงสร้างหลักของแอปพลิเคชัน Android คือ:

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

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

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

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

รูปแบบการอนุญาตของ Android: การเข้าถึง API ที่ได้รับการป้องกัน

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

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

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

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

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

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

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

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

สิทธิ์เริ่มต้นของระบบอธิบายไว้ที่ https://developer.android.com/reference/android/Manifest.permission.html แอปพลิเคชันอาจประกาศการอนุญาตของตนเองเพื่อให้แอปพลิเคชันอื่นใช้ การอนุญาตดังกล่าวไม่ได้ระบุไว้ในตำแหน่งข้างต้น

เมื่อกำหนดการอนุญาต แอ็ตทริบิวต์ ProtectionLevel จะบอกระบบว่าผู้ใช้จะได้รับแจ้งอย่างไรเกี่ยวกับแอปพลิเคชันที่ต้องได้รับอนุญาต หรือใครได้รับอนุญาตให้ถือสิทธิ์ รายละเอียดเกี่ยวกับการสร้างและการใช้สิทธิ์เฉพาะแอปพลิเคชันอธิบายไว้ที่ https://developer.android.com/guide/topics/security/security.html

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

ผู้ใช้เข้าใจแอปพลิเคชันบุคคลที่สามอย่างไร

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

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

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

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

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

สิทธิ์ในการติดตั้งแอปพลิเคชัน — Google Translate	การอนุญาตของแอปพลิเคชันที่ติดตั้ง — Gmail

รูปที่ 1 การแสดงสิทธิ์สำหรับแอปพลิเคชัน

การสื่อสารระหว่างกระบวนการ

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

Android ยังมีกลไก IPC ใหม่:

• Binder : กลไกการเรียกขั้นตอนระยะไกลตามความสามารถน้ำหนักเบาที่ออกแบบมาเพื่อประสิทธิภาพสูงเมื่อทำการเรียกระหว่างกระบวนการและข้ามกระบวนการ Binder ถูกใช้งานโดยใช้ไดรเวอร์ Linux แบบกำหนดเอง ดู https://developer.android.com/reference/android/os/Binder.html

• บริการ : บริการ (ที่กล่าวถึงข้างต้น) สามารถจัดเตรียมอินเทอร์เฟซที่สามารถเข้าถึงได้โดยตรงโดยใช้เครื่องผูก

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

• ContentProviders : ContentProvider คือคลังข้อมูลที่ให้การเข้าถึงข้อมูลบนอุปกรณ์ ตัวอย่างคลาสสิกคือ ContentProvider ที่ใช้ในการเข้าถึงรายชื่อผู้ติดต่อของผู้ใช้ แอปพลิเคชันสามารถเข้าถึงข้อมูลที่แอปพลิเคชันอื่นเปิดเผยผ่าน ContentProvider และแอปพลิเคชันยังสามารถกำหนด ContentProviders ของตนเองเพื่อเปิดเผยข้อมูลของตนเอง ดู https://developer.android.com/reference/android/content/ContentProvider.html

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

API ที่คำนึงถึงต้นทุน

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

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

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 ที่จัดส่งบนอุปกรณ์ของตนได้ อย่างไรก็ตาม อุปกรณ์ที่ใช้เวอร์ชัน 7.0 ขึ้นไปจะมีชุด CA ของระบบที่เหมือนกัน เนื่องจากไม่อนุญาตให้ผู้ผลิตอุปกรณ์แก้ไขอีกต่อไป

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

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

การลงนามใบสมัคร

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

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

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

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

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

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

การตรวจสอบแอปพลิเคชัน

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

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

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

กรอบงาน Android DRM ถูกนำมาใช้ในสถาปัตยกรรมสองชั้น (ดูรูปด้านล่าง):

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

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

รูปที่ 3 สถาปัตยกรรมการจัดการสิทธิ์ดิจิทัลบนแพลตฟอร์ม Android