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

ความล้มเหลวสามแบบเบื้องหลังกล่องโต้ตอบเดียว

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

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

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

FailureWhat it meansWhat recovers itWhat does not
User not authenticatedKey needs a presence checkSupported unlock or authorization flowA VPN account password reset
Key permanently invalidatedBinding is gone; key unusableReplacement enrollment for that identityRetrying, rebooting, reinstalling the client
Transient provider errorService could not complete nowThe provider's documented retry pathClearing app data

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

การลงทะเบียนใหม่กับการล้างข้อมูล

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

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

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

ลองใหม่เฉพาะสิ่งที่ลองใหม่ได้

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

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

อ่านห่วงโซ่สาเหตุ ไม่ใช่อุปกรณ์

แอปห่อข้อยกเว้นต้นฉบับ และสตริงที่เป็นมิตรใน UI มักซ่อนฟิลด์เดียวที่ตัดสินสาขา เก็บห่วงโซ่สาเหตุและตราเวลาของความพยายาม: ข้อยกเว้นชั้นนอกมักระบุการดำเนินการ และสาเหตุระบุสภาพของคีย์

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

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

สิ่งที่ต้องบันทึกขณะตัดสินใจ

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

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

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

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

บทความที่เกี่ยวข้อง