Android IKEv2: ใบรับรองผู้ใช้กับ CA ทำหน้าที่ต่างกัน
ช่องหนึ่งพิสูจน์ว่าโทรศัพท์เป็นใคร อีกช่องตัดสินว่าเชื่อถือเกตเวย์ใด โปรไฟล์ IKEv2 ของ Android แยกสองอย่างนี้ออกจากกันเพราะแฮนด์เชกทำเช่นนั้น
หน้าจอ Android IKEv2 ที่ขอทั้งใบรับรองผู้ใช้และใบรับรอง CA ดูเหมือนต้องการสิ่งเดียวกันถึงสองครั้ง แต่ไม่ใช่ IKEv2 รับรองทั้งสองฝ่ายในทั้งสองทิศทางภายในการแลกเปลี่ยนครั้งเดียว และโทรศัพท์มีบทบาทต่างกันในแต่ละทิศทาง คือต้องพิสูจน์ว่าตนเป็นใคร และต้องตัดสินว่าเชื่อถือเกตเวย์ใด ใบรับรองผู้ใช้ตอบคำถามแรก CA ที่เชื่อถือได้ตอบคำถามที่สอง และทั้งสองแทนกันไม่ได้
สองทิศทางของการรับรองในการแลกเปลี่ยนครั้งเดียว
IKEv2 สร้างช่องควบคุมในสองระยะ การแลกเปลี่ยนแรกเจรจาอัลกอริทึมและคีย์ ส่วนครั้งที่สองคือ IKE_AUTH พา AUTH เพย์โหลดหนึ่งรายการจากแต่ละฝ่ายพร้อมอัตลักษณ์ของแต่ละฝ่าย เพย์โหลดคือลายเซ็นหรือ MAC ที่คำนวณเหนือการแลกเปลี่ยน และตรวจสอบกับสิ่งที่ผู้รับเชื่อถืออยู่แล้ว
เกตเวย์พิสูจน์อัตลักษณ์ของตนด้วยใบรับรองของตน และโทรศัพท์ตรวจสอบห่วงโซ่ของใบรับรองนั้นขึ้นไปถึงรากที่ยินดีจะเชื่อถือ จากนั้นตรวจว่าอัตลักษณ์ในใบรับรองตรงกับเกตเวย์ที่ตั้งใจจะเข้าถึง โทรศัพท์พิสูจน์อัตลักษณ์ของตนด้วยข้อมูลรับรองของตน และเกตเวย์ตรวจสอบกับ CA ที่ออกใบรับรองไคลเอนต์
นั่นคือกลไกทั้งหมดเบื้องหลังสองช่องนี้ ใบรับรองผู้ใช้คือคำกล่าวที่โทรศัพท์กล่าวเกี่ยวกับตนเอง ส่วนช่อง CA คือคำกล่าวเกี่ยวกับผู้ที่โทรศัพท์จะเชื่อถือ โปรไฟล์ที่มีอย่างหนึ่งแต่ขาดอีกอย่างไม่สามารถทำการรับรองแบบสองทางให้สำเร็จได้ และการลองซ้ำไม่กี่ครั้งก็ไม่เปลี่ยนสิ่งนั้น ความล้มเหลวทั้งสองยังดูต่างกัน คือคีย์ผู้ใช้ที่หายไปทำให้โทรศัพท์สร้างลายเซ็นไม่ได้เลย ขณะที่สมอความเชื่อถือที่หายไปทำให้ไม่ยอมรับใบรับรองของเกตเวย์
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
ตัวสร้างโปรไฟล์ของ Android ขออะไร
ตัวสร้างโปรไฟล์ IKEv2 ของ Google เปิดเผยวิธีรับรองแต่ละวิธีแยกกัน ไม่ใช่โหมดใบรับรองเดียว วิธีลายเซ็นดิจิทัลรับใบรับรองผู้ใช้ คีย์ส่วนตัว และ CA รากของเซิร์ฟเวอร์ วิธีอื่นรับชื่อผู้ใช้กับรหัสผ่าน หรือคีย์ที่แชร์ไว้ล่วงหน้า
อ่านลายเซ็นนั้นให้ละเอียด เพราะมันเข้ารหัสกลไกข้างต้น ไม่มีช่องสำหรับคีย์ส่วนตัวของผู้ใช้ในวิธีชื่อผู้ใช้กับรหัสผ่าน และไม่มีช่องสำหรับสมอความเชื่อถือของเกตเวย์ในวิธี PSK ด้วยเหตุผลง่าย ๆ ว่าวิธีเหล่านั้นพิสูจน์คนละสิ่ง การผสมกันโดยวางรหัสผ่านลงในช่องใบรับรองจะได้โปรไฟล์ที่ล้มเหลวที่ IKE_AUTH พร้อมข้อความที่ไม่ระบุชื่อทั้งสอง
ชนิดคีย์ส่วนตัวที่เอกสารระบุสำหรับวิธีลายเซ็นดิจิทัลคือ RSA เมนูที่ติดป้าย IPsec หรือใบรับรองไม่ได้หมายความว่ารองรับ ECDSA และโปรไฟล์ที่ประกอบขึ้นบนสมมติฐานว่ารองรับจะล้มเหลวที่ API ของแพลตฟอร์มก่อนที่เครือข่ายจะเข้ามาเกี่ยวข้องด้วยซ้ำ
ทำไมใบรับรองผู้ใช้สาธารณะอย่างเดียวจึงไม่พอ
AUTH เพย์โหลดคือลายเซ็นเหนือการแลกเปลี่ยนที่สร้างด้วยคีย์ส่วนตัวของไคลเอนต์ การมีใบรับรองสาธารณะทำให้เกตเวย์ตรวจลายเซ็นได้ แต่ไม่ช่วยอะไรโทรศัพท์ ซึ่งต้องใช้คีย์ในการสร้างลายเซ็น การนำเข้าเฉพาะ .crt แล้วทิ้งคีย์ไว้ข้างหลังคือรูปแบบที่พบบ่อยที่สุดของความล้มเหลวนี้
โครงสร้างพื้นฐานคีย์ของ Android สะท้อนสิ่งนั้น การเลือกอัตลักษณ์ไคลเอนต์ต้องผ่าน KeyChain ซึ่งต้องเข้าถึงคีย์ส่วนตัวที่เกี่ยวข้อง ไม่ใช่แค่รายการใบรับรอง แพ็กเกจลงทะเบียนหรือขั้นตอนการจัดการอุปกรณ์ที่ติดตั้งทั้งคู่พร้อมกันคือวิธีปกติที่จะได้อัตลักษณ์ที่ใช้งานได้ การคัดลอกไฟล์ใบรับรองด้วยมือมักไม่ใช่
ดังนั้นสองรายการในโปรไฟล์จึงไม่ใช่ชุดใบรับรองกับสำเนาของมัน อย่างหนึ่งคือคู่คีย์ที่แพลตฟอร์มต้องใช้ลงลายเซ็นได้ อีกอย่างคือสมอความเชื่อถือที่แพลตฟอร์มใช้เปรียบเทียบ ตรวจทั้งสองเป็นข้อเท็จจริงแยกกัน คือโปรไฟล์นี้ลงลายเซ็นได้หรือไม่ และมันรู้ว่าจะเชื่อถือใครหรือไม่
สมอความเชื่อถือเป็นของแอปพลิเคชัน ไม่ใช่ของโทรศัพท์
การติดตั้งใบรับรองรากในที่เก็บของผู้ใช้ไม่ได้ทำให้ทุกแอปพลิเคชัน Android เชื่อถือมัน ตั้งแต่ Android 7 แอปต้องเลือกใช้ผ่านการกำหนดค่าความปลอดภัยเครือข่ายของตน และก่อนเวอร์ชันนั้น CA ที่ผู้ใช้ติดตั้งได้รับการยอมรับกว้างกว่ามาก การกำหนดค่าความเชื่อถือของแอปอาจต่างกัน และไคลเอนต์ VPN ที่จัดการวัสดุความเชื่อถือของตนเองอาจไม่เคยดูที่เก็บของผู้ใช้เลย นั่นคือเหตุผลที่ไฟล์ CA เดียวกันใช้ได้ในไคลเอนต์หนึ่งแต่ดูเหมือนถูกละเลยในอีกตัวหนึ่ง
มีแบบจำลองความเป็นเจ้าของสองแบบตามมา โปรไฟล์ VPN ที่ระบบจัดการใช้การติดตั้งใบรับรองของอุปกรณ์หรือขั้นตอนลงทะเบียนของผู้ดูแลระบบ แล้วโปรไฟล์จึงอ้างอิง CA ที่ตั้งใจไว้ VPN ที่แอปจัดการเก็บวัสดุความเชื่อถือของตนเองและใช้การนำเข้าตามเอกสารของตนเอง ซึ่งอาจแยกจากหน้าจอการตั้งค่า Android โดยสิ้นเชิง นั่นคือที่ที่คุณซ่อมห่วงโซ่ที่ขาดด้วย คือในที่เก็บ CA และการเลือกโปรไฟล์สำหรับกรณีที่ระบบจัดการ และในหน้าจอนำเข้าของไคลเอนต์เองสำหรับกรณีที่แอปจัดการ
ตัดสินว่าคุณอยู่ในแบบจำลองใดก่อนนำเข้าสิ่งใด แล้วยืนยันการเลือกความเชื่อถือของโปรไฟล์ที่ใช้งานอยู่ภายหลัง หากคำแนะนำของผู้ให้บริการกับเมนูของไคลเอนต์ขัดกัน พฤติกรรมตามเอกสารของไคลเอนต์ชนะสำหรับการติดตั้งนั้น แต่ CA ยังต้องมาจากผู้ให้บริการผ่านช่องทางที่คุณตรวจสอบได้ ชื่อไฟล์ไม่ใช่หลักฐานว่าใครเป็นผู้ออก
เลือกโหมดก่อน แล้วจึงเลือกไฟล์
โหมดใบรับรองต้องมีคู่คีย์ไคลเอนต์ มี CA ผู้ออกทางฝั่งเกตเวย์ มีสมอความเชื่อถือสำหรับใบรับรองเกตเวย์ และมีความคาดหมายว่าอัตลักษณ์ใดที่ใบรับรองนั้นต้องบรรจุ โหมดชื่อผู้ใช้กับรหัสผ่านแทนที่คู่คีย์ไคลเอนต์ด้วยข้อมูลรับรอง แต่คงข้อกำหนดความเชื่อถือของเกตเวย์ไว้ โหมด PSK แทนที่ทั้งสองด้วยความลับที่แชร์กันและเปลี่ยนแบบจำลองความเชื่อถือแทนที่จะทำให้ง่ายขึ้น
ไม่ว่าคุณจะเลือกแบบใด ให้เปิดการตรวจสอบปกติไว้ ตัวเลือกไม่ตรวจสอบ ที่ไคลเอนต์บางตัวมีให้ จะตัดการตรวจสอบที่ช่อง CA มีไว้ทำ และไม่ได้แก้สมอความเชื่อถือที่หายไป การยอมรับใบรับรองเซิร์ฟเวอร์ใดก็ได้เพราะการเชื่อมต่อทำงานได้โดยไม่ต้องใช้มันก็เช่นกัน
จากนั้นตรวจสอบในที่ที่ถูกต้อง คือนำเข้าวัสดุ เชื่อมต่อหนึ่งครั้ง และยืนยันในรายละเอียดการเชื่อมต่อของไคลเอนต์ว่าอัตลักษณ์ของเกตเวย์เป็นสิ่งที่คุณคาดไว้ และโปรไฟล์รายงานวิธีรับรองที่คุณตั้งใจจะใช้ การเชื่อมต่อที่สำเร็จโดยเลือกวิธีผิดคือการกำหนดค่าที่คุณยังไม่เข้าใจ และจะล้มเหลวเมื่อผู้ให้บริการเข้มงวดนโยบายในครั้งถัดไป