จะเขียนค่าหลายค่าเพื่อตรวจสอบความถูกต้องของ MAC ได้อย่างไร

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

ฉันได้พบ คำถามที่มีอยู่นี้เกี่ยวกับ MACing หลายข้อความแต่ฉันรู้สึกว่าโซลูชันที่เสนอไม่สามารถสรุปได้ดีสำหรับข้อความมากกว่าสองข้อความ

พิจารณาตัวอย่างที่วางแผนไว้ต่อไปนี้:

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

สมมติว่ารายการบันทึกมีโครงสร้างดังต่อไปนี้:

{
  สร้างขึ้นที่: "1621012345",
  ข้อความ: "รายการแรก"
}

ฉันสามารถสร้าง MAC สำหรับรายการบันทึกได้อย่างไร้เดียงสา ล เช่น $$ mac = \text{HMAC}(K, l.createdAt \| l.ข้อความ) $$ ที่ไหน $\|$ หมายถึงการเชื่อมต่อและ $K$ คือกุญแจลับ

ถ้าฉันต้องดำเนินการต่อเพื่อจัดเก็บรายการบันทึกนี้และ MAC บนเซิร์ฟเวอร์และเรียกคืนในภายหลัง เซิร์ฟเวอร์สามารถส่งคืนได้

{
  สร้างที่: "1621012",
  ข้อความ: "345รายการแรก",
  mac: "<การคำนวณ MAC ด้านบน>"
}

เนื่องจาก 1621012 || 345 รายการแรก ก็เหมือนกับ 1621012345 || รายการแรก ฉันจะไม่สังเกตเห็นการจัดการเมื่อตรวจสอบ MAC

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

ฉันสามารถคิดวิธีจัดการกับสิ่งนี้ได้ดังต่อไปนี้:

1. กระจายตัวคั่น

ถ้าฉันคำนวณ MAC เป็น $mac = \text{HMAC}(K, l.createdAt \| \text{':'} \| l.message)$ ฉันเชื่อว่าการโจมตีครั้งนี้จะไม่สามารถทำได้อีกต่อไป เมื่อมองแวบแรก ดูเหมือนว่ามีปัญหาที่อักขระตัวคั่นอาจปรากฏในข้อความ แต่นั่นทำให้เป็นไปไม่ได้ที่จะสร้างค่าใหม่จากสตริงที่ต่อกันอย่างชัดเจน ซึ่งไม่เกี่ยวข้องในสถานการณ์นี้ ฉันไม่สามารถคิดวิธีที่จะทำให้การคำนวณของ MAC คลุมเครือได้ที่นี่ วิธีง่ายๆ นี้มีความปลอดภัยหรือไม่?

2. ค่าแฮชก่อนเชื่อมต่อ

ฉันสามารถคำนวณ MAC ได้ เช่น $mac = \text{HMAC}(K, \text{SHA256}(l.createdAt) \| \text{SHA256}(l.message))$ (หรือฟังก์ชันแฮชการเข้ารหัสอื่นๆ) สิ่งนี้ทำให้แน่ใจว่าฝ่ายตรงข้ามไม่สามารถปรับเปลี่ยนคุณค่าที่ฉันเชื่อมโยงอย่างมีความหมายได้ นอกจากนี้ยังช่วยให้แน่ใจว่าค่าที่ต่อกันมีความยาวคงที่เสมอ การแฮชเพิ่มมูลค่าใด ๆ เมื่อเทียบกับแนวคิดแรกหรือไม่?

3. ตรวจสอบความถูกต้องของข้อมูลที่มีโครงสร้างทั้งหมด

ฉันยังสามารถคำนวณ MAC ผ่านวัตถุ JSON ที่สมบูรณ์ของรายการบันทึก หมายความว่าฉันมีตัวคั่นที่มีความหมายและซับซ้อนมากขึ้น (คีย์และไวยากรณ์) โดยทั่วไปเช่น JWT โปรดทราบว่าวิธีการนี้ยังมีข้อเสียบางประการ ซึ่งส่วนใหญ่มักเกิดจากการสูญเสียความยืดหยุ่นของ API และความจำเป็นในการกำหนดมาตรฐาน JSON มีบล็อกโพสต์ที่ยอดเยี่ยมเกี่ยวกับเรื่องนี้ที่ https://latacora.micro.blog/2019/07/24/how-not-to.html.

ฉันไม่มีวิธีแก้ปัญหาที่ดีสำหรับปัญหานี้หรือไม่? มีวิธีที่แนะนำในการจัดการกับสิ่งนี้หรือไม่?

เพื่อตอบคำถามของฉันเองบางส่วนที่นี่: ในความเป็นจริงแล้ว ความคิดที่ 1 ไม่ปลอดภัย.

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

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

โดยส่วนตัวแล้วฉันอาจจะใช้เวอร์ชันที่สอง (การแฮชค่าก่อนเชื่อมต่อ) แต่ฉันยังคงสนใจหากมีคนอื่นเจอสิ่งนี้และคุณจะแก้ไขได้อย่างไร