จำนวนบิตในไฟล์คีย์แบบสแตติกไม่ใช่ความแข็งแกร่งของการเข้ารหัส OpenVPN

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

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

ตัวเลขในแบนเนอร์นับอะไรกันแน่

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

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

สองชุดคีย์ในไฟล์เดียว

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

หากต้องการคีย์ที่ยาวขึ้นจริง ๆ การตั้งค่าที่ต้องเปลี่ยนคือการเข้ารหัสหรือไดเจสต์ และตัวสร้างจะผลิตสิ่งที่อัลกอริทึมที่เลือกต้องการ

การอ่านโปรไฟล์บอกคุณว่าคุณมีโหมดใด

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

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

การทบทวนความปลอดภัยควรบันทึกอะไร

บันทึกสามอย่างแยกกัน คือการป้องกันช่องสัญญาณข้อมูลที่ตกลงกัน การป้องกันช่องสัญญาณควบคุม และวิธีที่คู่ค้าพิสูจน์ตัวตนต่อกัน บรรทัดอย่าง data-ciphers AES-256-GCM อธิบายเพียงอย่างแรก และรายงานที่หยุดอยู่ตรงนั้นไม่สามารถตอบได้ว่าช่องสัญญาณควบคุมได้รับการป้องกันหรือไม่เลย ไฟล์คีย์แบบสแตติกอยู่ในหมวดที่สองเมื่อใช้กับ tls-auth หรือ tls-crypt และไม่อยู่ในหมวดใดเลยเมื่อไม่ได้ใช้ ผู้ทบทวนที่ปนหมวดเข้าด้วยกันจะขอไฟล์คีย์ที่ใหญ่ขึ้นในขณะที่สิ่งที่ต้องการคือการเข้ารหัสที่แข็งแกร่งกว่า

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

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