AES-GCM สามารถปกป้องความลับของข้อความและตรวจจับการเปลี่ยนแปลงที่ไม่ได้รับอนุญาตได้ แต่ตัวมันเองไม่ได้บอกผู้รับว่าข้อความที่ถูกต้องในด้านอื่นนั้นเคยถูกประมวลผลแล้วหรือยัง
ข้อกำหนดสามอย่างที่สับสนกันได้ง่ายคือ คู่คีย์/nonce ที่ไม่ซ้ำสำหรับการเข้ารหัส การยืนยันความแท้ของข้อความและบริบท และการจัดการ replay ในระดับโพรโทคอล HKDF ช่วยสร้างคีย์ได้ แต่ไม่ได้ทำให้ทั้งสามข้อสำเร็จโดยอัตโนมัติ
การใช้ nonce ซ้ำกับ replay เป็นคนละเหตุการณ์
| เหตุการณ์ | สิ่งที่เกิดขึ้น | การปกป้องที่จำเป็น |
|---|---|---|
| ใช้ nonce ซ้ำระหว่างเข้ารหัส | ข้อความธรรมดาที่ต่างกันถูกเข้ารหัสด้วยคีย์ GCM และ nonce เดียวกัน | กลยุทธ์จัดสรรคีย์/nonce ที่เชื่อถือได้ |
| การดัดแปลง | ข้อความเข้ารหัสหรือบริบทที่ผ่านการยืนยันความแท้ถูกเปลี่ยน | การถอดรหัสพร้อมยืนยันความแท้และปฏิเสธเมื่อการตรวจสอบล้มเหลว |
| Replay | ข้อความเข้ารหัสที่เคยถูกต้องถูกส่งมอบอีกครั้ง | สถานะและกฎของแอปที่รู้จำข้อความซ้ำหรือข้อความล้าสมัย |
| การสลับลำดับ | ข้อความที่ถูกต้องมาถึงในลำดับต่างออกไป | กฎลำดับที่โพรโทคอลกำหนดและการจัดการข้อความผิดลำดับอย่างมีขอบเขต |
ข้อความเข้ารหัสที่ถูกนำมาส่งซ้ำอาจยังมีแท็กยืนยันความแท้ที่ถูกต้อง เพราะไม่มีอะไรถูกเปลี่ยน จึงไม่ถูกต้องที่จะกล่าวว่าข้อความซ้ำทุกข้อความจะไม่ผ่านการยืนยันของ AES-GCM โดยอัตโนมัติ RFC 5116 แยกอินเทอร์เฟซ AEAD ออกจากบริการป้องกัน replay อย่างชัดเจน
เหตุใดคู่คีย์และ nonce จึงต้องไม่ซ้ำ
Nonce ของ GCM ไม่จำเป็นต้องเป็นความลับ แต่ต้องเป็นไปตามข้อกำหนดความไม่ซ้ำของวิธีนี้ภายใต้คีย์ที่กำหนด Nonce ขนาด 96 บิต หรือ 12 ไบต์เป็นรูปแบบที่พบบ่อย แต่การเลือกความยาวนั้นไม่ได้รับประกันว่าการสร้างจะถูกต้อง
การใช้คีย์และ nonce เดิมเข้ารหัสข้อความธรรมดาที่ต่างกันทำให้ใช้กระแสคีย์เข้ารหัสซ้ำ และเปิดเผยความสัมพันธ์ระหว่างข้อความธรรมดา อีกทั้งอาจทำลายความแท้และทำให้ปลอมแปลงได้ ผลกระทบร้ายแรง แต่ไม่ควรอธิบายว่าเปิดเผยคีย์เก่าทุกคีย์หรือทุกข้อความในบัญชีโดยอัตโนมัติ ขอบเขตที่ได้รับผลขึ้นอยู่กับคีย์ที่ใช้ซ้ำและโพรโทคอล
NIST SP 800-38D กำหนด GCM และข้อกำหนดของมัน การนำไปใช้ต้องทำตามขีดจำกัดจำนวนครั้งที่เรียกใช้และกฎการสร้าง nonce ที่เกี่ยวข้อง ไม่ใช่กฎประมาณง่าย ๆ ว่า “ปลอดภัยจนถึงข้อความจำนวนนี้”
HKDF ช่วยอะไร
HKDF ซึ่งกำหนดใน RFC 5869 สร้างวัสดุคีย์จากข้อมูลลับขาเข้าผ่านขั้นตอน extract และ expand โพรโทคอลสามารถใช้ป้ายกำกับบริบทและข้อมูลเข้าที่ต่างกันเพื่อแยกคีย์สำหรับแต่ละวัตถุประสงค์
HKDF เป็นแบบกำหนดผลแน่นอน หากไคลเอนต์ที่ล่มหรือถูกย้อนสถานะใช้สถานะและข้อมูลเข้าเดิมซ้ำ ก็อาจสร้างผลลัพธ์เดิมอีกครั้ง ดังนั้นการเพิ่ม HKDF ในการออกแบบไม่ได้ทำให้การใช้ nonce ซ้ำเป็นไปไม่ได้
คีย์ต่อข้อความสามารถลดปริมาณเนื้อหาที่ปกป้องด้วยคีย์เดียว แต่การเดินหน้าสถานะอย่างปลอดภัย การแยกคีย์ และการลบยังคงสำคัญ ค่า nonce เดียวกันภายใต้คีย์ที่ต่างกันจริงไม่ใช่ความผิดพลาดเดียวกับการใช้คู่คีย์/nonce ซ้ำ โพรโทคอลต้องยืนยันให้ได้ว่าคีย์เหล่านั้นต่างกันจริง
การป้องกัน replay เป็นหน้าที่ของโพรโทคอล
ผู้รับอาจติดตามรหัสข้อความ ตำแหน่งในลำดับ ยุคของเซสชัน หรือคีย์ ratchet ที่ใช้ไปแล้ว ฟิลด์ที่เกี่ยวข้องต้องผ่านการยืนยันความแท้ เพื่อไม่ให้ผู้โจมตีเปลี่ยนป้ายของข้อความเก่าให้เป็นข้อความใหม่
จากนั้นแอปต้องตัดสินว่าข้อความซ้ำหมายถึงอะไร การแสดงกล่องข้อความซ้ำทำให้ไม่สะดวก แต่การดำเนินการเดียวกันสองครั้งอาจร้ายแรงกว่า การลองส่งใหม่บนเครือข่ายเป็นเรื่องปกติ จึงมักต้องมีการประมวลผลแบบ idempotent ควบคู่กับการตรวจสอบทางวิทยาการเข้ารหัส
อย่าบังคับให้ข้อความที่ถูกต้องทุกข้อความมาถึงตามลำดับอย่างเคร่งครัด เว้นแต่โพรโทคอลจะกำหนดไว้ ไคลเอนต์มือถือเชื่อมต่อใหม่ ลองใหม่ และรับข้อความล่าช้าอยู่เป็นประจำ การจัดการที่ปลอดภัยต้องแยกข้อความมาช้าที่ถูกต้องออกจากข้อความที่ใช้ไปแล้วหรืออยู่ผิดบริบท
สิ่งที่ควรทดสอบก่อนอ้างว่าป้องกันได้
- รีสตาร์ตหลังจัดสรร nonce แต่ก่อนบันทึกการส่ง: การจัดสรรอาจซ้ำได้หรือไม่?
- กู้คืนสแนปช็อตสถานะเก่า: คีย์ ตัวนับ หรือบันทึก replay อาจย้อนกลับได้หรือไม่?
- ส่งพร้อมกันจากสอง worker หรืออุปกรณ์: โดเมนคีย์/nonce ของแต่ละฝ่ายแยกจากกันหรือไม่?
- ส่งมอบข้อความที่ถูกต้องเดิมสองครั้ง: แอปดำเนินการเพียงครั้งเดียวหรือไม่?
- เปลี่ยนรหัสเซสชันหรือส่วนหัว: บริบทถูกผูกไว้ด้วยวิทยาการเข้ารหัสหรือไม่?
- ส่งมอบข้อความที่ถูกต้องแบบผิดลำดับ: รองรับความล่าช้าที่กำหนดได้โดยไม่ยอมรับสถานะล้าสมัยหรือไม่?
API ถอดรหัสพร้อมยืนยันความแท้ควรคืนข้อความธรรมดาให้แอปเฉพาะเมื่อการตรวจสอบสำเร็จ นี่เป็นข้อกำหนดของอินเทอร์เฟซ ไม่ใช่คำกล่าวว่าไม่มีการนำไปใช้ใดคำนวณบัฟเฟอร์ข้อความธรรมดาชั่วคราวภายในเลย
อ่านคำกล่าวของ Livara อย่างถูกต้อง
เอกสารความปลอดภัย ของ Livara ระบุ AES-256-GCM เชนต่อข้อความ และบริบท LVR1/LGS1 องค์ประกอบพื้นฐานเหล่านี้ไม่ได้พิสูจน์ด้วยตัวเองว่าการกู้คืนหลังล่ม การจัดสรร nonce หรือการปฏิเสธ replay ถูกต้อง คำกล่าวเช่นนั้นต้องมีรายละเอียดโพรโทคอลที่ระบุเวอร์ชันและหลักฐานการทดสอบ
การออกแบบที่แข็งแรงกำหนดแต่ละหน้าที่อย่างชัดเจน: การสร้างคีย์ให้คีย์ตามที่ต้องการ AEAD ยืนยันความแท้ของเนื้อหาและบริบท และตรรกะโพรโทคอลที่เก็บสถานะตัดสินว่าข้อความที่ถูกต้องยอมรับได้ในขณะนี้หรือไม่
