พิสูจน์ว่าโปรโตคอลไม่สามารถโจมตีได้

พิจารณาโปรโตคอลต่อไปนี้:

1. $A\ลูกศรขวา B: \{N_A,A\}_{pk(B)}$

2. $B\ลูกศรขวา A: \{N_B,N_A\}_{pk(A)}$

3. $A\rightarrow B: แฮช(N_B, A, B)$

โดยตั้งใจไว้ว่าเมื่อใด $A$ หรือ $B$ ได้เสร็จสิ้นบทบาทของตนเองในโปรโตคอลแล้ว พวกเขามั่นใจได้ว่าอีกฝ่ายหนึ่งมีส่วนร่วมในโปรโตคอลกับพวกเขาและสิ่งนั้น $N_A$ และ $N_B$ เป็น nonces แบบสุ่มที่สร้างขึ้นโดย $A$ และ $B$. $\{X\}_{Y}$ หมายความว่า $X$ ถูกเข้ารหัสภายใต้คีย์ $Y$.

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

ไม่มีความสามารถของผู้โจมตีที่กำหนดไว้อย่างชัดเจนหรือการรับประกันความปลอดภัยขององค์ประกอบต่างๆ (การเข้ารหัสคีย์สาธารณะ ฟังก์ชันแฮช ฯลฯ) ไม่ใช่เรื่องง่ายที่จะบอกว่าโปรโตคอลนี้ "เชื่อมต่อได้" หรือไม่

เนื่องจากเราได้รับ "carte blanche" ฉันจะแสดงการโจมตี PITM สองครั้งตามรูปแบบความปลอดภัยและผู้โจมตีที่แตกต่างกัน

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

การโจมตี 1: การผูกมัดข้อมูลประจำตัวที่ไม่ถูกต้องและความต้องการ PKE ที่ปลอดภัยมากกว่า CPA

ตามที่เขียนไว้ ดูเหมือนว่าโปรโตคอลควรจะปลอดภัยตราบเท่าที่มีการใช้รูปแบบ PKE ที่ "ปลอดภัย" อย่างไรก็ตาม แนวคิดพื้นฐานเกี่ยวกับความปลอดภัยเช่นเดียวกับความปลอดภัยเชิงความหมายนั้นยังไม่เพียงพอ ในระดับสูง เมื่อสิ้นสุดการโจมตี $A$ คิดว่ากำลังคุยกันอยู่ $B$, ในขณะที่ $B$ คิดว่าพวกเขากำลังพูดคุยกับผู้โจมตีพูด $E$.

ในการทำเช่นนั้น เราจะแสดง CPA ที่ปลอดภัย PKE ซึ่งการโจมตีเป็นไปได้ อนุญาต $\คณิตศาสตร์ E$ เป็นแบบแผน PKE "ไฮบริด" (อิงตามอย่างอื่น) บนฟังก์ชันประตูกล ที่เข้ารหัสของข้อความ $m$ ภายใต้ $pk$ประกอบด้วยการสร้างค่าสุ่มโดยประมาณ $s$ จากนั้นสร้างคีย์การเข้ารหัสแบบสมมาตร $k = H(s)$. $k$ จากนั้นจะใช้เพื่อเข้ารหัสข้อความด้วยการเข้ารหัสแบบสตรีม เช่น อัลกอริทึม โดยสร้างข้อความเข้ารหัส $ค$. ไซเฟอร์เท็กซ์สุดท้ายจากโครงร่าง PKE คือ $$\{m\}_{pk} = (enc_{PKE}(pk, s), ค)$$ การโจมตีทำงานดังนี้

1. $ A\ลูกศรขวา B: c_1 = \{N_A,A\}_{pk(B)} $
2. ผู้โจมตีสกัดกั้นข้อความนี้ สร้างผู้ใช้ใหม่ $E$แก้ไขข้อความรหัสเป็นค่า $c_1'$ ดังกล่าวเพื่อถอดรหัสเป็น $N_A, E$. สิ่งนี้เป็นไปได้เนื่องจากเรากำลังใช้รหัสสตรีม (เรายังถือว่า nonce และตัวตนมีความยาวคงที่ เป็นต้น...)
3. $B$ ถอดรหัสข้อความและดูเหมือนว่า $E's$ ข้อมูลประจำตัว ดังนั้น ข้อความที่สองจะถูกส่งไป $E$
4. $B \ลูกศรขวา E: c_2 = \{N_A. N_B\}_{pk_E}$.
5. $E$ ถอดรหัส $c_2$และได้รับ nonce
6. $E \ลูกศรขวา A: c_2' = \{N_A, N_B\}_{pk_A}$
7. $A \ลูกศรขวา B: c_3 = H(N_B, A, B)$
8. $E$ สกัดกั้นดร็อบบ์ $c_3$ และส่ง $c_3' = H(N_B, E, B)$

จากกระแสข้างต้น มุมมองของ $A$ ก็เหมือนกับว่ามีปฏิสัมพันธ์กับ $B$ในขณะที่มุมมองของ $B$ ราวกับว่ามีปฏิสัมพันธ์กับ $E$.

การโจมตี 2: การเปิดเผยความลับในระยะยาวและความซื่อสัตย์ของการประนีประนอม

ที่นี่ความสามารถของผู้โจมตีแข็งแกร่งขึ้น และเราอนุญาตให้ประนีประนอมกับคีย์ลับระยะยาวได้ เห็นได้ชัดว่าถ้า $sk_A$ ถูกบุกรุก (และ $A$ ยังไม่ทราบ) ผู้โจมตีสามารถปลอมตัวได้ $A$ ตามใจ; อย่างไรก็ตาม ดูเหมือนว่าเป็นเรื่องปกติที่จะคาดหวังว่าหาก $A$ ดำเนินการเซสชันด้วยความซื่อสัตย์ $B$, $A$ ควรมีความมั่นใจว่าเธอคุยกับใคร อย่างไรก็ตามในการโจมตีครั้งนี้ การประนีประนอมของ $sk_A$ หมายความว่าผู้โจมตีสามารถสวมบทบาทเป็นบุคคลใดก็ได้ $A$.

แนวคิดพื้นฐานข้างต้นคือ ผู้โจมตี PITM จะสามารถถอดรหัสข้อความที่สองได้ $\{N_A, N_B\}_{pk_A}$. ผู้โจมตีสามารถสรุปการโต้ตอบกับ $A$ และ "ตัดสาย" ไปทาง B ด้วยเหตุนี้ $A$ คิดว่าพวกเขากำลังพูด $B$ ทั้งที่คุยกับบีอยู่แท้ๆ

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

ประกันที่ต้องการคือ

(ผู้เข้าร่วม) มั่นใจได้ว่าอีกฝ่ายได้เข้าร่วมในโปรโตคอล กับพวกเขาเหล่านั้น

แต่ฉันจะลบ กับพวกเขาเหล่านั้นเนื่องจากไม่ชัดเจน และฉันไม่เห็นคำจำกัดความที่แน่ชัดว่า crypto สามารถตอบสนองได้ (เป็นไปได้เสมอที่ Man-in-the-Middle จะส่งต่อข้อความโดยไม่เปลี่ยนแปลง) ฉันจะแทนที่ด้วย ตั้งแต่โปรโตคอลเริ่มต้นซึ่งไม่ต้องสับสนกับความแข็งแกร่งมากนัก ตามระเบียบการไปตามปกติ.

ในขั้นตอนที่ 1 $N_A$ ถูกสุ่มเลือกโดย $A$ และเข้ารหัสภายใต้ $pk(B)$เป็นส่วนหนึ่งของข้อความธรรมดาของ $\{N_A,A\}_{pk(B)}$. เท่านั้นเท่านี้ $A$ หรือเอนทิตีบางอย่างที่มีความสามารถในการถอดรหัสในระดับหนึ่ง $\{N_A,A\}_{pk(B)}$นั่นเป็นเพียง $B$สามารถรู้อะไรเกี่ยวกับ $N_A$ ด้านข้างยาว. ดังนั้นเมื่อสรุปขั้นตอนที่ 2 แล้ว $A$ ได้รับสิ่งที่ถอดรหัสเป็น $N_A$และพวกเขารู้ว่าพวกเขาไม่ได้ใช้ $N_A$ เพื่อจุดประสงค์อื่นนอกเหนือจากการสร้างข้อความของขั้นตอนที่ 1 พวกเขามีการรับประกันว่า $B$ เข้าร่วมในโปรโตคอล ฉันจะไม่ทำให้การรับประกันนี้เป็นเชิงปริมาณ โดยสงวนไว้สำหรับทิศทางอื่น

ในขั้นตอนที่ 2 $N_B$ ถูกสุ่มเลือกโดย $B$ และเข้ารหัสภายใต้ $pk(ก)$เป็นส่วนหนึ่งของข้อความธรรมดาของ $\{N_B,N_A\}_{pk(A)}$. เท่านั้นเท่านี้ $B$ หรือเอนทิตีที่มีความสามารถในการถอดรหัสในระดับหนึ่ง $\{N_B,N_A\}_{pk(A)}$นั่นเป็นเพียง $A$สามารถรู้อะไรเกี่ยวกับ $N_B$ ด้านข้างยาว. ทะลึ่ง
 (a) แฮชเป็นออราเคิลแบบสุ่มที่มีความกว้างเอาต์พุต $k_H$,
(ข) $N_B$ ถูกเลือกอย่างเท่าเทียมกันโดยการสุ่มและมีความกว้าง $k_N$,
 (c) ศัตรูใด ๆ มีความได้เปรียบตามขอบเขต $\epsilon$ ต่อต้านการเข้ารหัส
จากนั้นกล่าวว่าฝ่ายตรงข้ามน่าจะเป็นขอบเขตบนโดย $2^{-k_H}+2^{-k_N}+\epsilon$ เพื่อหาค่าแฮชของขั้นตอนที่ 3 อย่างแน่นอน ดังนั้นเมื่อสรุปขั้นตอนที่ 3 แล้ว $B$ พบค่าดังกล่าวสำหรับแฮชที่พวกเขาคำนวณใหม่ และพวกเขารู้ว่าไม่ได้ใช้ $N_B$ เพื่อจุดประสงค์อื่นนอกเหนือจากการสร้างข้อความของขั้นตอนที่ 2 พวกเขามีการรับประกันว่า $A$ เข้าร่วมในโปรโตคอล

หากเหตุผลนี้ถูกต้อง ขั้นที่ 3 ก็สามารถทำให้ง่ายขึ้นได้ $A\ลูกศรขวา B:\ แฮช(N_B)$. ถ้าไม่ฉันอยากรู้ว่าทำไม! สิ่งนี้ไม่ถูกตีความว่าเป็นคำแนะนำในการทำให้เข้าใจง่าย: การรวมข้อมูลประจำตัวในสิ่งที่แฮชสามารถช่วยได้เท่านั้น และฉันเห็นอย่างคลุมเครือว่าสามารถบล็อกการเปลี่ยนแปลงโดยเจตนาของโปรโตคอลได้ แต่ไม่ใช่ประเภทที่ทำลายการรับประกันความปลอดภัยเมื่อฉันพูดใหม่ มัน.

รายการสมมติฐานบางส่วนที่ไม่ได้ระบุไว้ในคำถาม

• การเพิ่มภายหลัง: คีย์สาธารณะเป็นที่รู้จักและเชื่อถือได้ก่อนที่โปรโตคอลจะเริ่มทำงาน
• การเพิ่มในภายหลัง: การเข้ารหัสมีความปลอดภัย IND-CCA2. ไซน์ ฉันไม่มั่นใจว่าเราจะหนีไปพร้อมกับทรัพย์สินที่มีมูลค่าน้อยกว่าได้ไหม ฉันขอเลือกทางที่ปลอดภัยดีกว่า
• มักจะไม่ระบุในการวิเคราะห์โปรโตคอล ผู้รับข้อความ
  • พยายามถอดรหัสและยกเลิกหากล้มเหลว (เช่นเดียวกับการถอดรหัสรหัส IND-CCA2 จำนวนมาก)
  • แยกวิเคราะห์ข้อความที่ถอดรหัสตามข้อตกลงที่ระบุไว้สำหรับรุ่นของพวกเขาและยกเลิกหากล้มเหลว
  • ตรวจสอบค่าที่ได้รับกับค่าที่คาดไว้หากทราบจากขั้นตอนก่อนหน้าหรือสามารถคำนวณได้ (ดังที่เกิดขึ้นสำหรับแฮชของขั้นตอนที่ 3 บน $B$ ด้าน) และยกเลิกเมื่อไม่มีการแข่งขัน ดูเหมือนว่าไม่จำเป็นที่การเปรียบเทียบดังกล่าวจะทำในเวลาคงที่
  • หรือ/และใช้ค่าดังกล่าวซ้ำสำหรับตัวแปรที่มีชื่อเดียวกันในขั้นตอนต่อไป
• ในข้อความธรรมดาของข้อความที่เข้ารหัส เครื่องหมายลูกน้ำเป็นสัญลักษณ์รูปแบบหนึ่งของการต่อข้อมูลที่มีข้อกำหนด ซึ่งจากผลลัพธ์นั้นยังคงมีความเป็นไปได้ที่จะแยก ณ จุดที่เกิดการต่อข้อมูล เช่น เนื่องจากหนึ่งในสองข้อความที่ต่อกันมีขนาดคงที่ ดูเหมือนว่าไม่จำเป็นสำหรับเครื่องหมายลูกน้ำที่ใช้ในข้อความที่แฮชในขั้นตอนที่ 3
• ในข้อความ $A$ และ $B$ เป็นตัวตนของผู้เข้าร่วมบาร์นี้
• เอนทิตีใช้คีย์ส่วนตัวเพื่อวัตถุประสงค์ในการถอดรหัสข้อความที่ได้รับเท่านั้น
• หลังจากขั้นตอนที่ 1 $B$ ตัดสินใจว่าคีย์สาธารณะใดที่พวกเขาใช้สำหรับการเข้ารหัสในขั้นตอนที่ 2 และเลือกผู้รับที่จะส่งในขั้นตอนนั้น บนพื้นฐานของส่วนที่สอง $A$ ของข้อความถอดรหัสในขั้นตอนที่ 1 และยกเลิกหากไม่ทราบรหัสสาธารณะที่เกี่ยวข้อง ไม่จำเป็นสำหรับการรักษาความปลอดภัยของโปรโตคอลตามที่ระบุว่าตรวจสอบว่าส่วนที่ 2 นี้ไม่ใช่ตัวตนของตน
• หากผู้เข้าร่วมพยายามเชื่อมต่อหลายรายการพร้อมกัน อย่างที่เซิร์ฟเวอร์ทำเป็นประจำ จะถือว่าพวกเขาเก็บตัวแปรแยกต่างหากสำหรับแต่ละอินสแตนซ์ของโปรโตคอล ฉันไม่เห็นเหตุผลว่าทำไมการพยายามเชื่อมต่อหลายครั้งที่เอนทิตีมีส่วนร่วมนั้นเป็นไปไม่ได้ในทิศทางที่แตกต่างกัน
• ฉันไม่สนใจแชนแนลด้านข้างที่ไม่ได้กล่าวถึง โจมตีข้อบกพร่อง และข้อผิดพลาดในการนำไปใช้งาน