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

องค์ประกอบของแอพพลิเคชั่น

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

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

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

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

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

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

รูปแบบการอนุญาตของ Android: การเข้าถึง Protected APIs

แอปพลิเคชันทั้งหมดบน 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 Maps สิทธิ์ของแอปพลิเคชันที่ติดตั้ง -- Gmail
สิทธิ์ในการติดตั้งแอปพลิเคชัน -- Google Mapsสิทธิ์ของแอปพลิเคชันที่ติดตั้ง -- Gmail

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

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

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

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

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

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

  • เจตนา : เจตนาเป็นวัตถุข้อความธรรมดาที่แสดงถึง "ความตั้งใจ" ที่จะทำอะไรบางอย่าง ตัวอย่างเช่น หากแอปพลิเคชันของคุณต้องการแสดงหน้าเว็บ แอปพลิเคชันจะแสดง "เจตนา" เพื่อดู URL โดยการสร้างอินสแตนซ์ 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 ไปใช้โดยใช้กลไกอื่นๆ เช่น ซ็อกเก็ตเครือข่ายหรือไฟล์ที่เขียนได้ทั่วโลก สิ่งเหล่านี้คือเฟรมเวิร์ก Android IPC ที่แนะนำ นักพัฒนา 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 เพื่อปกป้องข้อมูลจากแอปพลิเคชันของบุคคลที่สาม

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

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

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

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

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

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

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

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

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

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

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

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

หากต้องการเพิ่มเป็น CA สาธารณะชุดใหม่ในชุดสต็อค Android CA ต้องดำเนินการตาม กระบวนการ Mozilla CA Inclusion Process แล้วจึงยื่นคำขอคุณลักษณะต่อ 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 เหล่านี้เท่านั้น สำหรับรายละเอียดเพิ่มเติม โปรดดูที่ Network Security Configuration

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

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

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

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

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

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

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

การตรวจสอบใบสมัคร

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

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

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

เฟรมเวิร์ก Android DRM ถูกนำไปใช้ในสถาปัตยกรรมสองชั้น (ดูรูปด้านล่าง):

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

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

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

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