กลุ่ม DH ที่ใช้ร่วมกัน กับความลับใหม่: ทำไมการโจมตีจึงถูกลง

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

ครึ่งสาธารณะไม่ใช่ครึ่งที่อ่อนแอ และนั่นคือกับดัก

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

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

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

การคำนวณล่วงหน้าให้อะไรกับผู้โจมตีจริง ๆ

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

บทความ Logjam ปี 2015 แสดงให้เห็นการลดระดับลงเป็น Diffie-Hellman 512 บิตระดับส่งออก และประเมินว่าการโจมตีกลุ่มขนาดใหญ่ที่ถูกใช้ซ้ำอย่างกว้างขวางด้วยทรัพยากรจำนวนมากจะต้องใช้ต้นทุนเท่าใด การสาธิตนั้นเป็นรูปธรรม การประมาณเป็นการประมาณ และไม่มีสิ่งใดเป็นหลักฐานว่าเซสชัน VPN ใดถูกถอดรหัส

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

การเป็นมาตรฐานไม่เหมือนกับการอ่อนแอ

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

แยกโครงสร้างออกจากกันเมื่อคุณใช้เหตุผลกับมัน ข้อสรุปเกี่ยวกับ Diffie-Hellman เหนือฟิลด์จำกัดไม่ได้บอกอะไรเกี่ยวกับ X25519 และข้อสรุปเกี่ยวกับกลุ่ม MODP 1024 บิตก็ไม่ได้บอกอะไรเกี่ยวกับกลุ่ม 3072 บิต นโยบายความแข็งแกร่งเป็นรายกลไก รายขนาด และรายเวอร์ชันโปรโตคอล นี่คือเหตุผลที่วลีการเข้ารหัสที่แข็งแกร่งไม่ใช่ข้อความที่ตรวจสอบได้

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

อ่านกลุ่มที่เจรจาบนการเชื่อมต่อจริง

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

บันทึกบรรทัดนั้นก่อนและหลังการเปลี่ยนนโยบาย และเก็บทั้งสองไว้ในบันทึกการเปลี่ยนแปลง การเปรียบเทียบคือหลักฐาน

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

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

ตรวจสอบกลุ่มและตัวตนของคู่สนทนาแยกกัน

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

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

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

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