Score:6

TLS 1.3 - เหตุใดจึงไม่มีการระบุโหมดเข้ารหัสแล้วเป็น MAC

ธง cn

ฉันได้เกาหัวของฉันในขณะที่ทำไม TLS 1.3 ไม่รวมโหมดเข้ารหัสแล้ว MAC (EtM) ปัญหาก่อนหน้านี้ทั้งหมดใน TLS เกิดจาก MAC แล้วเข้ารหัส ในขณะที่เข้ารหัสแล้ว MAC จะหลีกเลี่ยงปัญหาทั้งหมดที่เกิดจากการเติมข้อมูลในอดีต เนื่องจากผู้รับสามารถตรวจสอบความสมบูรณ์ของข้อความได้โดยไม่ต้องถอดรหัสข้อความก่อน แล้วจึงจัดการการเติมข้อมูลผิดพลาดอย่างถูกต้อง

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

ในขณะที่มี ChaCha20-Poly1305 ใช้แทน หมายความว่าคุณละทิ้งการใช้ฮาร์ดแวร์ AES บนไมโครคอนโทรลเลอร์ แม้ว่า ChaCha20 จะทำงานได้ดีกับไมโคร 32 บิต แต่ก็ยังคงใช้พลังงานมากกว่าฮาร์ดแวร์ AES ในตัว และน่าจะช้ากว่านั้นขึ้นอยู่กับไมโคร นอกจากนี้ Poly1305 ยังต้องการการคำนวณทางคณิตศาสตร์แบบโมดูลาร์ตัวเลขขนาดใหญ่เมื่อเทียบกับฟังก์ชันแฮชจำนวนมาก

ฉันแค่เกาหัวเพราะไม่มีอะไรผิดปกติกับ EtM ฉันยังพบร่าง IETF AES-CBC-HMAC ที่ดำเนินการ EtMอย่างไรก็ตาม มันไม่เคยผ่านการร่างซึ่งทำให้ฉันรู้สึกแปลก

แก้ไข: เนื่องจากมีการกล่าวถึงชุด CCM Cipher ในขณะที่เรียกใช้ AES ในโหมด CTR จะหลีกเลี่ยงการเติม oracles มันไม่ได้อยู่ในชุดรหัสบังคับหรืออย่างใดอย่างหนึ่ง ควร ใช้ห้องชุด ดู: Cipher Suites ที่จำเป็นต้องนำไปใช้ ดังนั้นโดยทั่วไปแล้วเราไม่สามารถใช้ประโยชน์จากฮาร์ดแวร์ AES บนไมโครได้หากไม่มี GCM (เช่น เซิร์ฟเวอร์จำนวนมากปิดใช้งาน CCM โดยค่าเริ่มต้น และทั้ง Firefox และ Chrome ก็เปิดใช้งาน CCM) ดูเหมือนจะแปลกอีกครั้งที่ไม่มีอะไรอยู่ระหว่างนี้ และฉันไม่เห็นเหตุผลที่ดีว่าทำไม และโหมด EtM ดูเหมือนจะเป็นตัวเลือกที่ดี แต่ไม่เคยถูกเพิ่มเข้าไปในมาตรฐานด้วยซ้ำ

Score:5
ธง in

สำหรับอุปกรณ์ฝังตัวมี โหมด CCMซึ่งโดยพื้นฐานแล้วเป็นวิธีที่ปลอดภัยในการดำเนินการ AES-CBC-MAC + AES-CTR ในโหมดแพ็กเก็ต (ซับซ้อนโดยไม่จำเป็น แต่ค่อนข้างมีประสิทธิภาพ) โปรดทราบว่านี่คือการเข้ารหัส MAC แล้วโดยทั่วไป แต่เป็นส่วนหนึ่งของโหมดความปลอดภัยโดยรวม การโจมตีจาก oracles นั้นไม่สามารถใช้งานได้อย่างแน่นอนเนื่องจากโหมดตัวนับไม่ต้องการการเติม

ciphersuites ที่มีอยู่คือ:

  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_CCM_8_SHA256 (ตามที่กำหนด ใน RFC 6655)

หลังยังมีแท็กการรับรองความถูกต้องที่มีประสิทธิภาพมากกว่า (เกี่ยวกับขนาด ไม่ใช่ความพยายามในการคำนวณ) ที่ 8 ไบต์ / 64 บิต ซึ่ง ควรจะเพียงพอ.

ดังนั้นฉันเดาว่าพวกเขาไม่คิดว่าจำเป็นต้องมีอัลกอริทึมอื่น เนื่องจากมีระบบฝังตัวไม่กี่ตัวที่มีการเร่งความเร็ว SHA-1 หรือ SHA-256

หมายเหตุ:

  • แฮชที่ส่วนท้ายของ ciphersuite ใช้สำหรับการสืบทอดคีย์เซสชันเท่านั้น (PRF ใน TLS) ดังนั้นจึงไม่ได้ใช้สำหรับแต่ละข้อความ
  • AES ในโหมด CTR และ ใน CBC-MAC จะใช้เฉพาะในโหมดการส่งต่อ / การเข้ารหัส ดังนั้นคุณไม่จำเป็นต้องมีการสนับสนุนฮาร์ดแวร์สำหรับการดำเนินการถอดรหัส
kelalaka avatar
in flag
มีเหตุผลเฉพาะในการเขียน AES-CBC-MAC + AES-CTR แทน AES-CTR + AES-CBC-MAC นอกเหนือจากการระบุว่า MAC ดำเนินการก่อนการเข้ารหัสหรือไม่
Maarten Bodewes avatar
in flag
@kelalaka ไม่ฉันคิดว่าวิธีนี้จะทำให้สับสนน้อยลง
kelalaka avatar
in flag
อาจจะเพิ่ม $$c = \big(\operatorname{AES-CTR}(m)\|(\operatorname{AES-CTR}(m_0) \oplus \operatorname{AES-CBC-MAC}\big(Nonce\mathbin\ |ข้อมูลที่เกี่ยวข้อง \mathbin\|m) \big)\big)$$ จะทำให้ชัดเจนหรือไม่ชัดเจนมากขึ้น
cn flag
แน่นอนว่ามี CCM เป็นเรื่องปกติ เช่น หากคุณควบคุมเซิร์ฟเวอร์ที่อุปกรณ์ของคุณกำลังพูดคุยด้วย เช่น คำขอ api เป็นต้น... สิ่งหนึ่งที่ฉันสังเกตเห็นคือเซิร์ฟเวอร์อื่น ๆ ดูเหมือนจะปิดการใช้งานบ่อยครั้ง นอกจากนี้ chrome และ firefox ยังไม่เปิดใช้งานชุดเข้ารหัสนั้นอีกเพื่อจำกัดตัวเลือก
cn flag
อีกสิ่งหนึ่งที่คุณพูดถึง CCM ไม่ใช่ EtM แต่ใช่ การรัน AES โดยพื้นฐานแล้วเป็นรหัสสตรีมจะหลีกเลี่ยงการเติม oracles อย่างไรก็ตาม อย่างที่ฉันได้พูดถึงโหมดการทำงานของ CCM ดูเหมือนจะไม่ได้เปิดใช้งานอย่างกว้างขวาง โดยพื้นฐานแล้ว การบังคับบางอย่างเช่น ChaCha20-Poly1305 เพื่อความเข้ากันได้ที่กว้างขึ้น เนื่องจาก GCM จะต้องการการคูณที่น้อยลง มันยังทำให้ฉันแปลกใจเพราะมีช่องว่างที่นี่ โดยที่ดูเหมือนว่าโหมด EtM บางโหมดจะเปิดใช้งานได้กว้างกว่า และดูแปลกที่ไม่มีโหมด EtM สำหรับ TLS 1.3
Maarten Bodewes avatar
in flag
แน่นอน แต่ยังไม่ชัดเจนว่าเป็นอย่างไร เช่น CBC + HMAC ก็เช่นกัน มันอาจจะไม่ใช่ชุดรหัสที่จำเป็น ดังนั้นจึงเป็นตัวเลือกเช่นกัน CCM นั้นไม่ใช่ EtM นั้นไม่ตรงประเด็น ... ตราบใดที่ยังปลอดภัย ไม่น่าเป็นไปได้ที่ใครสักคนจะใช้มันเพื่อถอดรหัส ใช้และตรวจสอบ - แม้ว่าจะเป็นไปได้ก็ตาม
cn flag
CBC + HMAC เป็นโครงสร้างที่รู้จักกันดี และหากดำเนินการในโครงสร้าง EtM จะหลีกเลี่ยงข้อผิดพลาดหลักของ MAC ในการเข้ารหัส ดูเหมือนจะไม่มีเหตุผลที่แม้ว่าจะเป็นทางเลือกที่จะยังคงเปิดใช้งานบ่อยขึ้นเนื่องจากเป็นโครงสร้างที่รู้จักกันดี

โพสต์คำตอบ

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