ติดตั้งใช้งานการรักษาความปลอดภัย

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

หน้านี้แสดงแนวทางปฏิบัติแนะนำด้านความปลอดภัยตามประสบการณ์ของเรา ซึ่งต่อยอดจากเอกสารการออกแบบเพื่อความปลอดภัยที่เรามีให้นักพัฒนาแอป รวมถึงรายละเอียดเฉพาะสำหรับการสร้างหรือการติดตั้งซอฟต์แวร์ระดับระบบในอุปกรณ์

ทีมรักษาความปลอดภัยของ Android ได้รวมการทดสอบไว้ในชุดเครื่องมือทดสอบความเข้ากันได้ของ Android (CTS) และ Android Lint เพื่อให้การนำแนวทางปฏิบัติแนะนำเหล่านี้ไปใช้ได้ง่ายขึ้น เราขอแนะนำให้ผู้ติดตั้งใช้งานอุปกรณ์มีส่วนร่วมในการทดสอบที่จะช่วยผู้ใช้ Android คนอื่นๆ ได้ (ดูการทดสอบที่เกี่ยวข้องกับความปลอดภัยได้ที่ root/cts/tests/tests/security/src/android/security/cts)

กระบวนการพัฒนา

ใช้แนวทางปฏิบัติแนะนำต่อไปนี้ในกระบวนการและสภาพแวดล้อมการพัฒนา

ตรวจสอบซอร์สโค้ด

การตรวจสอบซอร์สโค้ดสามารถตรวจหาปัญหาด้านความปลอดภัยได้หลากหลาย รวมถึงปัญหาที่ระบุไว้ในเอกสารนี้ Android ขอแนะนําอย่างยิ่งให้ตรวจสอบซอร์สโค้ดทั้งด้วยตนเองและแบบอัตโนมัติ แนวทางปฏิบัติแนะนำ

• เรียกใช้ Android Lint กับโค้ดแอปทั้งหมดที่ใช้ Android SDK และแก้ไขปัญหาที่พบ
• ควรวิเคราะห์โค้ดเนทีฟโดยใช้เครื่องมืออัตโนมัติที่ตรวจจับปัญหาการจัดการหน่วยความจำได้ เช่น บัฟเฟอร์ที่ล้น และข้อผิดพลาดที่เพิ่มขึ้น 1 รายการ
• ระบบการสร้างของ Android รองรับโปรแกรมตรวจสอบ LLVM หลายรายการ เช่น AddressSanitizer และ UndefinedBehaviorSanitizer ซึ่งสามารถใช้เพื่อวัตถุประสงค์นี้ได้

ใช้การทดสอบอัตโนมัติ

การทดสอบอัตโนมัติสามารถตรวจหาปัญหาด้านความปลอดภัยได้หลากหลาย รวมถึงปัญหาหลายอย่างที่กล่าวถึงด้านล่าง แนวทางปฏิบัติแนะนำ

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

รูปภาพระบบป้าย

ลายเซ็นของอิมเมจระบบมีความสําคัญอย่างยิ่งต่อการพิจารณาความสมบูรณ์ของอุปกรณ์ แนวทางปฏิบัติแนะนำ

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

รับรองแอป (APK)

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

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

เผยแพร่แอป

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

• อัปโหลดแอปไปยัง Google Play เพื่ออนุญาตให้อัปเดตอัตโนมัติโดยไม่ต้องมีการอัปเดตผ่านอากาศ (OTA) แบบเต็ม ผู้ใช้จะดาวน์โหลดแอปที่อัปโหลดแต่ยังไม่ได้เผยแพร่โดยตรงไม่ได้ แต่แอปจะยังคงได้รับการอัปเดต ผู้ใช้ที่ติดตั้งแอปไว้ก่อนหน้านี้จะติดตั้งแอปอีกครั้งและ/หรือติดตั้งในอุปกรณ์เครื่องอื่นได้
• สร้างชื่อแพ็กเกจแอปที่เชื่อมโยงกับบริษัทของคุณอย่างชัดเจน เช่น โดยใช้เครื่องหมายการค้าของบริษัท
• แอปที่เผยแพร่โดยผู้ผลิตอุปกรณ์ควรอัปโหลดใน Google Play Store เพื่อหลีกเลี่ยงการแอบอ้างชื่อแพ็กเกจโดยผู้ใช้บุคคลที่สาม หากผู้ผลิตอุปกรณ์ติดตั้งแอปในอุปกรณ์โดยไม่เผยแพร่แอปใน Play Store นักพัฒนาแอปรายอื่นอาจอัปโหลดแอปเดียวกัน ใช้ชื่อแพ็กเกจเดียวกัน และเปลี่ยนข้อมูลเมตาของแอปได้ เมื่อแสดงแอปต่อผู้ใช้ ข้อมูลเมตาที่ไม่เกี่ยวข้องนี้อาจทำให้เกิดความสับสน

ตอบสนองต่อเหตุการณ์

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

• สร้างอีเมล security@your-company.com หรืออีเมลที่คล้ายกัน แล้วเผยแพร่ให้ผู้อื่นทราบ
• หากทราบปัญหาด้านความปลอดภัยที่ส่งผลกระทบต่อระบบปฏิบัติการ Android หรืออุปกรณ์ Android จากผู้ผลิตอุปกรณ์หลายราย คุณควรติดต่อทีมรักษาความปลอดภัยของ Android โดยยื่น รายงานข้อบกพร่องด้านความปลอดภัย

ติดตั้งใช้งานผลิตภัณฑ์

ใช้แนวทางปฏิบัติแนะนำต่อไปนี้เมื่อติดตั้งใช้งานผลิตภัณฑ์

แยกกระบวนการรูท

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

• อุปกรณ์ควรเรียกใช้โค้ดที่จำเป็นขั้นต่ำในฐานะรูท ใช้กระบวนการ Android ปกติแทนกระบวนการรูททุกครั้งที่เป็นไปได้ ICS Galaxy Nexus มีกระบวนการรูทเพียง 6 รายการ ได้แก่ vold, inetd, zygote, tf_daemon, ueventd และ init หากกระบวนการต้องทำงานในฐานะรูทในอุปกรณ์ ให้บันทึกกระบวนการในคำขอฟีเจอร์ AOSP เพื่อให้สามารถตรวจสอบแบบสาธารณะได้
• หากเป็นไปได้ ควรแยกโค้ดรูทออกจากข้อมูลที่ไม่น่าเชื่อถือและเข้าถึงผ่าน IPC เช่น ลดฟังก์ชันการทำงานของรูทเป็นบริการขนาดเล็กที่เข้าถึงได้ผ่าน Binder และแสดงบริการที่มีสิทธิ์ลายเซ็นแก่แอปที่มีสิทธิ์ต่ำหรือไม่มีสิทธิ์ในการจัดการการรับส่งข้อมูลในเครือข่าย
• กระบวนการรูทต้องไม่ฟังในซ็อกเก็ตเครือข่าย
• กระบวนการรูทต้องไม่มีรันไทม์อเนกประสงค์สําหรับแอป (เช่น Java VM)

แยกแอประบบ

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

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

แยกกระบวนการ

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

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

ไฟล์ SUID ที่ปลอดภัย

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

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

โปรแกรมตรวจสอบ CTS มีการทดสอบที่ให้ข้อมูลซึ่งแสดงรายการไฟล์ SUID โดยไฟล์ setuid บางไฟล์ไม่อนุญาตตามการทดสอบ CTS

ซ็อกเก็ตการฟังที่ปลอดภัย

การทดสอบ CTS ล้มเหลวเมื่ออุปกรณ์กำลังฟังในพอร์ตใดก็ตามในอินเทอร์เฟซใดก็ตาม ในกรณีที่ดำเนินการไม่สำเร็จ Android จะตรวจสอบว่ามีการใช้แนวทางปฏิบัติแนะนำต่อไปนี้

• อุปกรณ์ไม่ควรมีพอร์ตการฟัง
• พอร์ตที่กำลังรอการเชื่อมต่อต้องปิดใช้ได้โดยไม่ต้อง OTA ซึ่งอาจเป็นการเปลี่ยนแปลงการกำหนดค่าเซิร์ฟเวอร์หรืออุปกรณ์ของผู้ใช้
• กระบวนการรูทต้องไม่ฟังพอร์ตใดๆ
• กระบวนการที่ UID ของระบบเป็นเจ้าของต้องไม่ฟังพอร์ตใดๆ
• สำหรับ IPC ในพื้นที่ที่ใช้ซ็อกเก็ต แอปต้องใช้ซ็อกเก็ตโดเมน UNIX ที่จำกัดการเข้าถึงไว้เฉพาะกลุ่ม สร้างตัวระบุไฟล์สําหรับ IPC และตั้งค่าเป็น +RW สําหรับกลุ่ม UNIX ที่เฉพาะเจาะจง แอปไคลเอ็นต์ต้องอยู่ในกลุ่ม UNIX นั้น
• อุปกรณ์บางเครื่องที่มีตัวประมวลผลหลายตัว (เช่น วิทยุ/โมเด็มแยกจากตัวประมวลผลแอป) ใช้ซ็อกเก็ตเครือข่ายเพื่อสื่อสารระหว่างตัวประมวลผล ในกรณีเช่นนี้ ซ็อกเก็ตเครือข่ายที่ใช้สำหรับการสื่อสารระหว่างโปรเซสเซอร์ต้องใช้อินเทอร์เฟซเครือข่ายที่แยกไว้เพื่อป้องกันการเข้าถึงโดยแอปที่ไม่ได้รับอนุญาตในอุปกรณ์ (กล่าวคือ ใช้ iptables เพื่อป้องกันการเข้าถึงโดยแอปอื่นๆ ในอุปกรณ์)
• เดมอนที่จัดการพอร์ตการฟังต้องมีความทนทานต่อข้อมูลที่ไม่เป็นรูปแบบ Google อาจทำการทดสอบแบบ Fuzz กับพอร์ตโดยใช้ไคลเอ็นต์ที่ไม่ได้รับอนุญาต และไคลเอ็นต์ที่ได้รับอนุญาต (หากเป็นไปได้) ระบบจะบันทึกข้อขัดข้องเป็นข้อบกพร่องที่มีความรุนแรงที่เหมาะสม

ข้อมูลบันทึก

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

• แอปหรือบริการของระบบไม่ควรบันทึกข้อมูลที่ได้จากแอปของบุคคลที่สามซึ่งอาจมีข้อมูลที่ละเอียดอ่อน
• แอปต้องไม่บันทึกข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ (PII) เป็นส่วนหนึ่งของการทํางานตามปกติ

CTS มีการทดสอบที่ตรวจสอบว่ามีข้อมูลที่ละเอียดอ่อนที่อาจอยู่ในบันทึกของระบบหรือไม่

จำกัดการเข้าถึงไดเรกทอรี

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

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

ไฟล์การกําหนดค่าที่ปลอดภัย

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

• ไฟล์การกําหนดค่าที่กระบวนการที่มีสิทธิ์ใช้ไม่ควรอ่านได้แบบทุกคน
• ไฟล์การกําหนดค่าที่กระบวนการที่มีสิทธิ์ใช้ต้องไม่เขียนได้แบบทุกคน

จัดเก็บไลบรารีโค้ดเนทีฟ

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

จำกัดการเข้าถึงโปรแกรมควบคุมอุปกรณ์

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

ปิดใช้ ADB

Android Debug Bridge (adb) เป็นเครื่องมือสําคัญสําหรับการพัฒนาและการแก้ไขข้อบกพร่อง แต่ออกแบบมาเพื่อใช้ในสภาพแวดล้อมที่ปลอดภัยและควบคุมได้ ไม่ควรเปิดใช้สําหรับการใช้งานทั่วไป แนวทางปฏิบัติแนะนำ

• ADB ต้องปิดใช้โดยค่าเริ่มต้น
• ADB ต้องกำหนดให้ผู้ใช้เปิดใช้ก่อนจึงจะยอมรับการเชื่อมต่อได้

ปลดล็อก Bootloader

อุปกรณ์ Android จํานวนมากรองรับการปลดล็อก ซึ่งช่วยให้เจ้าของอุปกรณ์แก้ไขพาร์ติชันระบบและ/หรือติดตั้งระบบปฏิบัติการที่กําหนดเองได้ กรณีการใช้งานทั่วไป ได้แก่ การติดตั้ง ROM ของบุคคลที่สามและการพัฒนาระดับระบบในอุปกรณ์ ตัวอย่างเช่น เจ้าของอุปกรณ์ Google Nexus สามารถเรียกใช้ fastboot oem unlock เพื่อเริ่มกระบวนการปลดล็อก ซึ่งจะแสดงข้อความต่อไปนี้ต่อผู้ใช้

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

• เมื่อผู้ใช้ยืนยันคำสั่งปลดล็อกแล้ว อุปกรณ์ต้องเริ่มล้างข้อมูลทันที ต้องไม่ตั้งค่า Flag unlocked จนกว่าจะลบอย่างปลอดภัยเสร็จสมบูรณ์
• หากการลบอย่างปลอดภัยไม่สำเร็จ อุปกรณ์จะต้องอยู่ในสถานะล็อก
• หากอุปกรณ์บล็อกที่รองรับ ควรใช้ ioctl(BLKSECDISCARD) หรือเทียบเท่า สำหรับอุปกรณ์ eMMC การดำเนินการนี้หมายถึงการใช้คำสั่ง Secure Erase หรือ Secure Trim สำหรับ eMMC เวอร์ชัน 4.5 ขึ้นไป การดำเนินการนี้หมายถึงการใช้การลบหรือการตัดตามปกติตามด้วยการล้างข้อมูล
• หากอุปกรณ์บล็อกพื้นฐานไม่รองรับ BLKSECDISCARD ต้องใช้ ioctl(BLKDISCARD) แทน ในอุปกรณ์ eMMC การดําเนินการนี้เป็นการดำเนินการ Trim ตามปกติ
• หากระบบไม่รองรับ BLKDISCARD คุณสามารถเขียนทับอุปกรณ์บล็อกด้วยค่า 0 ทั้งหมดได้
• ผู้ใช้ปลายทางต้องมีตัวเลือกในการกำหนดให้ล้างข้อมูลผู้ใช้ก่อนที่จะแฟลชพาร์ติชัน เช่น ในอุปกรณ์ Nexus การดำเนินการนี้จะทำได้ผ่านคำสั่ง fastboot oem lock
• อุปกรณ์อาจบันทึกผ่าน Efuse หรือกลไกที่คล้ายกันว่าอุปกรณ์ถูกปลดล็อกและ/หรือล็อกอีกครั้งหรือไม่

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

อุปกรณ์ที่ปลดล็อกแล้วอาจล็อกอีกครั้งได้โดยใช้คำสั่ง fastboot oem lock การล็อก Bootloader จะปกป้องข้อมูลผู้ใช้ด้วยระบบปฏิบัติการที่กำหนดเองใหม่ในลักษณะเดียวกับที่ระบบปฏิบัติการของผู้ผลิตอุปกรณ์เดิมทำได้ (เช่น ระบบจะล้างข้อมูลผู้ใช้หากมีการปลดล็อกอุปกรณ์อีกครั้ง)