การโจมตี Padding Oracle โดยละเอียด

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

การเข้ารหัสแบบบล็อกต้องการข้อมูลนำเข้าเป็นบล็อกขนาดคงที่ การเติมข้อมูลแบบ PKCS#7 จะเติมข้อมูลในบล็อกสุดท้าย: หากต้องเติม 3 ไบต์ ให้เพิ่มสามไบต์ที่มีค่า 0x03 แต่ละไบต์ หากบล็อกมีข้อมูลเต็มอยู่แล้ว ให้เพิ่มบล็อกเติมข้อมูลทั้งบล็อก โดยไบต์ทั้ง 16 ไบต์มีค่าเป็น 0x10 ระหว่างการถอดรหัส ระบบจะตรวจสอบว่าไบต์เติมข้อมูลสอดคล้องกันหรือไม่ โดยไบต์ทั้ง N ไบต์ต้องมีค่า N แล้วจึงลบไบต์เหล่านั้นออก หากการเติมข้อมูลไม่ถูกต้อง การถอดรหัสควรล้มเหลว

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

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

เมื่อกู้คืนไบต์สุดท้ายได้แล้ว จะมุ่งเป้าไปที่ไบต์ก่อนสุดท้าย ค่าการถอดรหัสระหว่างกลางของไบต์สุดท้ายเป็นที่ทราบแล้ว จึงบังคับให้มีค่าเป็น 0x02 ได้ จากนั้นลองค่าทั้ง 256 ค่าสำหรับไบต์ก่อนสุดท้าย จนกว่าการเติมข้อมูล 0x02 0x02 จะถูกต้อง กระบวนการนี้ทำซ้ำกับทุกไบต์ ทำให้กู้คืนบล็อกขนาด 16 ไบต์ได้ครบ โดยเฉลี่ยต้องสอบถามตัวตรวจสอบ 256 * 16 = 4,096 ครั้งต่อบล็อก หากตัวตรวจสอบตอบสนองรวดเร็ว กระบวนการนี้อาจเสร็จสิ้นภายในไม่กี่วินาที

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

POODLE (การตรวจสอบการเติมข้อมูลของการเข้ารหัสรุ่นเก่าที่ถูกลดระดับ) ใช้ประโยชน์จากการตรวจสอบการเติมข้อมูลแบบ CBC ของ SSL 3.0 โดย SSL 3.0 ใช้รูปแบบการเติมข้อมูลที่ไม่ใช่ PKCS#7 แต่การโจมตีได้ปรับแนวคิดของตัวตรวจสอบมาใช้ ผู้โจมตีที่สามารถแทรกเนื้อหาในเซสชัน SSL 3.0 และบังคับให้ไคลเอ็นต์ลดระดับไปใช้ SSL 3.0 ได้ จะสามารถกู้คืนคุกกี้เซสชันด้วยเทคนิคตัวตรวจสอบการเติมข้อมูล POODLE ทำให้ต้องยกเลิกการใช้งาน SSL 3.0

ลัคกีเธอร์ทีน (ค.ศ. 2013) ใช้ประโยชน์จากช่องทางด้านเวลาในรูปแบบตรวจสอบ MAC แล้วจึงเข้ารหัสของ CBC ใน TLS เวลาที่ใช้ตรวจสอบ MAC แตกต่างกันเล็กน้อยระดับไม่กี่นาโนวินาที โดยขึ้นอยู่กับว่าการเติมข้อมูลถูกต้องหรือไม่ จึงสร้างตัวตรวจสอบด้านเวลาได้ BEAST (ค.ศ. 2011) ใช้ประโยชน์จากเวกเตอร์เริ่มต้นที่คาดเดาได้ในโหมด CBC ของ TLS 1.0 เพื่อโจมตีแบบเลือกข้อความต้นฉบับต่อคุกกี้เซสชัน การโจมตีทั้งสองแสดงให้เห็นว่า CBC ใน TLS นั้นนำไปใช้อย่างถูกต้องได้ยากโดยพื้นฐาน

การป้องกันที่เด็ดขาดต่อการโจมตีตัวตรวจสอบการเติมข้อมูลคือการใช้โหมด AEAD แทน CBC โหมด AEAD เช่น การเข้ารหัสตามมาตรฐานการเข้ารหัสขั้นสูงขนาด 256 บิต-GCM และ ChaCha20-โพลี1305 จะตรวจสอบความถูกต้องก่อนเริ่มการถอดรหัสหรือตรวจสอบการเติมข้อมูล หากแท็กยืนยันความถูกต้องไม่ถูกต้อง การถอดรหัสจะไม่เกิดขึ้นเลย จึงไม่มีข้อมูลเกี่ยวกับการเติมข้อมูลรั่วไหล TLS 1.3 กำหนดให้ใช้ AEAD และตัด CBC ออกทั้งหมด

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

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

การโจมตีตัวตรวจสอบการเติมข้อมูลต้องการสิ่งใดจากระบบเป้าหมาย จึงจะถอดรหัสข้อความเข้ารหัสได้โดยไม่ต้องมีกุญแจ

สรุปตัวตรวจสอบการเติมข้อมูล: คุณสมบัติ XOR ของการถอดรหัส CBC ทำให้ควบคุมการเปลี่ยนแปลงไบต์ของข้อความต้นฉบับได้ การตรวจสอบการเติมข้อมูลแบบ PKCS#7 เผยสัญญาณแบบสองค่า ผู้โจมตีจะลองค่าไบต์ต่าง ๆ และสังเกตการตอบกลับว่าถูกต้องหรือไม่ เพื่อกู้คืนข้อความต้นฉบับทีละไบต์ การโจมตีในโลกจริง ได้แก่ POODLE, ลัคกีเธอร์ทีน และ BEAST การป้องกันคือเปลี่ยนไปใช้ AEAD (GCM และ ChaCha20-โพลี1305) ซึ่งตรวจสอบความถูกต้องก่อนถอดรหัส