คีย์ IPsec ที่แชร์ล่วงหน้า: ไบต์เบื้องหลังสตริงที่คุณพิมพ์

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

เกตเวย์ทำอะไรกับสตริง

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

ดังนั้นคำถามที่มีประโยชน์จึงไม่ใช่ «สิ่งเหล่านี้ดูเหมือนกันหรือไม่» แต่เป็น «แต่ละการใช้งานแฮชลำดับไบต์ใดอย่างแม่นยำ»

ไบต์ส่วนเกินมาจากไหน

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

เปรียบเทียบด้วยเครื่องมือที่แสดงไบต์ไม่ใช่รูปสัญลักษณ์ printf '%s' "$PSK" | xxd | tail -2 พิมพ์ส่วนท้ายของค่าเป็นเลขฐานสิบหก ซึ่งจะเห็น 0a หรือ 20 ที่หลงเหลือได้ชัดเจน ทำที่ทั้งสองฝั่งแล้วเปรียบเทียบดัมป์ทั้งสองเคียงกัน ทำกับวัสดุทดสอบที่สร้างขึ้น ไม่ใช่กับความลับของระบบผลิตที่คุณจะทิ้งไว้ในประวัติเชลล์

เข้ารหัสแล้วไม่ได้หมายถึงเข้ารหัสลับ

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

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

ขีดจำกัดที่อ้างนั้นเป็นของชุดค่าผสมเดียว

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

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

แก้ไขการแสดงข้อมูล ไม่ใช่ความแข็งแรง

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

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