เกตเวย์สองตัวที่ตั้งค่าด้วยคีย์ที่แชร์ไว้ล่วงหน้าคีย์เดียวกันทำแฮนด์เชคจนสำเร็จ และการดักจับแพ็กเก็ตไม่แสดงความลับใดที่วิ่งผ่านสาย ส่วนนี้คือส่วนที่คนจำได้ ส่วนที่น่าสนใจคือแต่ละเวอร์ชันคำนวณอะไรจริง ๆ เพื่อพิสูจน์ว่ารู้ความลับ เพราะ IKEv1 กับ IKEv2 สร้างหลักฐานนั้นจากข้อมูลตั้งต้นต่างกัน และเปิดเผยข้อมูลต่างกันระหว่างทำ อ่านร่องรอยทั้งสองเทียบกันแล้วความต่างจะไม่ใช่แค่เรื่องผิวเผิน

หลักฐานต้องบรรลุอะไร

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

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

IKEv1 โหมดหลัก: สร้าง SKEYID แล้วจึงพิสูจน์

โหมดหลักใช้หกข้อความ คู่แรกเจรจาความสัมพันธ์ด้านความปลอดภัย คู่ที่สองแลกค่า Diffie-Hellman สาธารณะกับ nonce คู่ที่สามพาตัวตนและฮาชพิสูจน์ตัวตนไปภายใต้การเข้ารหัสที่เพิ่งตั้งขึ้น RFC 2409 กำหนดโครงสร้างไว้ เมื่อพิสูจน์ตัวตนด้วยคีย์ที่แชร์ไว้ล่วงหน้า SKEYID สร้างจากความลับและ nonce ทั้งสอง ส่วนวัสดุกุญแจภายหลังสร้างจาก SKEYID ค่าใช้ร่วมกันของ Diffie-Hellman คุกกี้ และค่าคงที่

ฮาชในข้อความที่ห้าและที่หกคำนวณจากค่า Diffie-Hellman คุกกี้สองตัว ข้อเสนอ และตัวตนของผู้ส่ง โดยใช้ SKEYID เป็นคีย์ ผู้รับคำนวณใหม่ด้วยความลับที่ตั้งไว้ของตน หากไม่ตรงกันการแลกเปลี่ยนจบลง และความลับเองไม่เคยเป็นเพย์โหลด

โหมด Aggressive บีบงานเดียวกันให้เหลือสามข้อความ หมายความว่าตัวตนและฮาชพิสูจน์ตัวตนวิ่งไปก่อนที่ช่องทางเข้ารหัสจะมีอยู่ นี่คือการเปิดเผยจริงสำหรับความลับที่เดาได้ และเป็นคนละเรื่องกับคำถามว่าความลับถูกส่งไปหรือไม่ IKEv1 ถูกยกเลิกโดย RFC 9395 ร่องรอยเก่าจึงเป็นการฝึกวินิจฉัย ไม่ใช่เป้าหมายการติดตั้ง

IKEv2: การสร้างที่ต่างออกไปและเพย์โหลด AUTH ที่ต่างออกไป

IKEv2 ไม่ใช้ตารางกุญแจของ IKEv1 ซ้ำ กุญแจ IKE เริ่มต้นมาจากเมล็ดที่สร้างจาก nonce และค่าใช้ร่วมกันของ Diffie-Hellman และความสัมพันธ์ด้านความปลอดภัยลูกที่สร้างจากเมล็ดนั้น คีย์ที่แชร์ไว้ล่วงหน้าไม่ป้อนเข้าสู่เมล็ดเลย

จากนั้นการพิสูจน์ตัวตนปรากฏเป็นเพย์โหลด AUTH สำหรับการพิสูจน์ด้วยคีย์ร่วม RFC 7296 กำหนดรูปแบบที่เติมให้ความลับ ซึ่งได้จากการฮาชความลับด้วยสตริงคงที่ Key Pad for IKEv2 แล้วจึงฮาชข้อมูลการแลกเปลี่ยนที่ลงลายมือชื่อและตัวตนด้วยคีย์ที่เติมแล้วนั้น ผู้ตรวจสอบสามารถสร้างค่าเดิมขึ้นใหม่ได้ ผู้เฝ้าดูทำไม่ได้หากไม่มีความลับ

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

ผู้เฝ้าดูได้เรียนรู้อะไรจริง ๆ

ค่า Diffie-Hellman สาธารณะ ข้อเสนอ nonce และคุกกี้ปรากฏในทั้งสองเวอร์ชัน ตัวตนปรากฏใน IKEv1 โหมด Aggressive และถูกป้องกันในกรณีอื่น ความลับไม่เคยปรากฏ

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

จะใช้การเปรียบเทียบนี้อย่างไร

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

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

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