Score:1

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

ธง ws

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

ฉันคิดว่าจะใช้ AEAD กับ block cypher เพื่อยกของหนัก เช่น AES ในโหมด GCM ปัญหาที่ฉันพบคือการป้องกันการโจมตีซ้ำ และฉันได้แนวคิดต่อไปนี้ มาเรียกอุปกรณ์กันเถอะ $A$ และ $B$ และพิจารณาการติดต่อสื่อสารจาก $A$ ถึง $B$ เท่านั้น.

  • $A$ สร้างสตริงแบบสุ่ม $a$ แล้วส่งมาที่ $B$.
  • $B$ สร้างสตริงแบบสุ่ม $ข$ แล้วส่งมาที่ $A$.
  • ทั้งคู่ $A$ และ $B$ คำนวณ $h=H(k \Vert a \Vert b)$ สำหรับฟังก์ชันแฮชการเข้ารหัสบางอย่าง $H$,และใช้ $h$ เป็นเวกเตอร์เริ่มต้นตัวแรกสำหรับโครงร่าง AEAD

เมื่อไหร่ก็ตาม $A$ ต้องส่งข้อความ $m$ ถึง $B$มันเข้ารหัส $m$ เพื่อให้ได้ไซเฟอร์เท็กซ์ที่สอดคล้องกัน $ค$คำนวณแท็กการรับรองความถูกต้อง $t$และส่ง $c \Vert t$ ถึง $A$ (ข้อความมีความยาวคงที่ดังนั้นความยาวของ $c \Vert t$ มีค่าคงที่) แล้ว $A$ เพิ่มขึ้น $h$ และเริ่มต้นโครงร่าง AEAD อีกครั้งด้วย IV ใหม่ $h$.

กระบวนการถอดรหัสจะคล้ายกัน: $B$ ได้รับ $c \Vert t$ถอดรหัส $ค$ เข้าไปข้างใน $m$ตรวจสอบความถูกต้องของข้อความโดยใช้แท็ก $t$เพิ่มขึ้น $h$และเริ่มต้นโครงร่าง AEAD อีกครั้งด้วยค่าใหม่เป็น $h$.

สื่อสารจาก $B$ ถึง $A$ มีความสมมาตรอย่างสมบูรณ์ ยกเว้นว่า IV เริ่มต้นนั้น $H(k \Vert b \Vert a)$.

มีข้อบกพร่องใด ๆ ที่เห็นได้ชัดกับแนวคิดข้างต้นหรือไม่? ฉันกำลังประดิษฐ์ล้อใหม่หรือไม่? ถ้าเป็นเช่นนั้น แนวทางแก้ไขปัญหานี้คืออะไร?

kelalaka avatar
in flag
ค้นหาเล็กน้อย [มาตรการตอบโต้การโจมตีซ้ำ](https://crypto.stackexchange.com/search?q=replay+attack+countermeasure) และดู [จุดสิ้นสุดของคำตอบ](https://crypto.stackexchange.com/a/ 41327/18298)
Steven avatar
ws flag
ฉันทราบดีว่าสามารถหลีกเลี่ยงการโจมตีแบบเล่นซ้ำได้โดยเพิ่มการประทับเวลาหรือตัวนับ อย่างไรก็ตามอุปกรณ์ $A$ ไม่รักษาสถานะระหว่างการรีบูต (เป็นอุปกรณ์ฝังตัว) และไม่มีนาฬิกาภายใน (ฉันไม่ต้องการพึ่งพาการซิงโครไนซ์เวลาผ่านอินเทอร์เน็ตเพราะจะต้องอาศัยการเชื่อมต่ออินเทอร์เน็ตที่ใช้งานได้)
kelalaka avatar
in flag
แล้วต้องเซ็น...
Steven avatar
ws flag
คุณช่วยอธิบายเพิ่มเติมเกี่ยวกับวิธีที่ลายเซ็นจะช่วยต่อต้านการโจมตีซ้ำได้ไหม แม้ว่าข้อความจะเซ็นชื่อแล้ว ฉันจะสามารถตรวจสอบความถูกต้องได้เท่านั้น แต่จะตรวจสอบไม่ได้ว่าข้อความนั้นถูกเล่นซ้ำหรือไม่ ยิ่งไปกว่านั้น แผน AEAD ที่ฉันเสนอควรให้ความถูกต้องอยู่แล้ว มีอะไรผิดปกติกับโครงการที่ฉันเสนอหรือไม่? สำหรับฉันแล้วดูเหมือนว่า $h$ ควรรับประกันว่าเป็นความลับ "ต่อเซสชัน" แบบสุ่มที่แบ่งปันระหว่าง $A$ และ $B$ มีปัญหากับการใช้ $h$ เพื่อเริ่มต้น IV และเพิ่ม IV หลังจากแต่ละข้อความหรือไม่
SAI Peregrinus avatar
si flag
ทำไมต้องสตริง? ทำไมไม่เป็นค่าไบนารีที่มีความยาวคงที่ เหตุใดจึงใช้แฮช H แทนแฮชหรือ MAC ที่มีคีย์ที่เหมาะสม
Steven avatar
ws flag
@SAIPeregrinus. ค่าไบนารีความยาวคงที่นั้นใช้ได้อย่างสมบูรณ์แบบ อันที่จริงนั่นคือสิ่งที่ฉันคิดไว้แม้ว่าฉันจะเขียนสตริงก็ตาม นอกจากนี้ ฉันค้นหาคีย์แฮชและดูเหมือนว่าจะให้บริการตามวัตถุประสงค์เดียวกันกับ $H$ ดังนั้นในคำอธิบายด้านบน $H(k \Vert a \Vert b)$ สามารถแทนที่ด้วย $HMAC(k,a \ Vert b)$. ขอบคุณ.
Score:1
ธง it

ฉันคิดว่านี่คือจุดที่สำคัญที่สุดของคุณ (จากความคิดเห็น):

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

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

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

Steven avatar
ws flag
ขอขอบคุณ. ฉันแค่ต้องการให้แน่ใจว่าฉันเข้าใจแผนการที่คุณเสนออย่างถูกต้อง คุณกำลังแนะนำให้ฉันทำการแลกเปลี่ยนคีย์ Diffie-Hellman ในขณะที่ใช้แบบแผน AEAD กับคีย์ที่แบ่งปันล่วงหน้าของฉันเพื่อรับประกันการรับรองความถูกต้อง (ฉันต้องเข้ารหัสที่นี่หรือไม่) ที่นี่แบบแผน AEAD จะต้องใช้ IV แบบฮาร์ดโค้ด อย่างไรก็ตามคีย์ DH ที่เจรจาไว้ $k$ จะเป็นความลับและแตกต่างกันไปในแต่ละเซสชันจากนั้นฉันสามารถใช้ $k$ เป็นคีย์เซสชันสำหรับโครงร่าง AEAD อื่นเพื่อแลกเปลี่ยนข้อความจริง ตามที่ฉันเข้าใจว่าแต่ละข้อความต้องการ IV ที่แตกต่างกัน ในกรณีนี้ ฉันสามารถใช้ตัวนับที่เริ่มต้นจาก $0$ ได้หรือไม่
Steven avatar
ws flag
นอกจากนี้ ดูเหมือนว่าส่วนที่ 1 ทั้งหมดของโปรโตคอลกำลังทำงาน [การแลกเปลี่ยนคีย์ที่ตรวจสอบสิทธิ์ด้วยรหัสผ่าน](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#Password-authenticated_key_agreement) หากเป็นกรณีนี้ เราสามารถใช้แนวคิดที่ร่างไว้ในวิกิพีเดียได้หรือไม่ กล่าวคือ $A$ และ $B$ มีความลับที่แบ่งปันล่วงหน้าแล้ว $s$; พวกเขาคำนวณคีย์เซสชัน $k$ โดยใช้การแลกเปลี่ยนคีย์ DH จากนั้น $A$ ส่ง $hash(s \Vert 0 \Vert k)$ ไปยัง $B$ ซึ่ง $B$ จะตรวจสอบความถูกต้องของ $A$ สมมาตร $B$ ส่ง $hash(s \Vert 1 \Vert k)$ ถึง $A$ การสื่อสารดำเนินการโดยใช้ $k$ เป็นคีย์เซสชัน

โพสต์คำตอบ

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