Score:1

การใช้ RSA เพื่อแลกเปลี่ยนรหัส AES ปลอดภัยหรือไม่

ธง jp

ฉันต้องสร้าง Client-Server Application โดยใช้ Java และฉันต้องการทำให้การสื่อสารปลอดภัย ฉันคิดว่าจะใช้ AES เพื่อเข้ารหัสข้อความและสำหรับการแลกเปลี่ยนคีย์ ฉันจะทำขั้นตอนต่อไป:

  • ลูกค้าสร้างคีย์ RSA และส่งคีย์สาธารณะไปยังเซิร์ฟเวอร์
  • เซิร์ฟเวอร์จะเข้ารหัสคีย์ AES ด้วยคีย์สาธารณะ RSA (คีย์ AES ถูกสร้างขึ้นแบบสุ่มสำหรับลูกค้าทุกคน)
  • ไคลเอนต์ถอดรหัสข้อความด้วยคีย์ส่วนตัว RSA จากนั้นข้อความทั้งหมดจะถูกเข้ารหัสด้วย AES

คำถามของฉันคือ: มันเป็นแนวปฏิบัติที่ดีหรือไม่?

Swashbuckler avatar
mc flag
โดยพื้นฐานแล้ว สิ่งที่คุณอธิบายคือการรวมคีย์โดยใช้คีย์สาธารณะ/ส่วนตัว นอกจากนี้ยังสามารถทำได้ด้วยปุ่มสมมาตรเช่นกัน แทนที่จะคิดค้นวิธีการทำของคุณเองและอาจทำผิดพลาด คุณควรใช้การใช้งานที่มีอยู่จากไลบรารี crypto ที่ดีและใช้สิ่งนั้น
Maarten Bodewes avatar
in flag
คำถามที่แท้จริงคือ: คุณจะเชื่อถือรหัสสาธารณะที่คุณได้รับได้อย่างไร มันอาจจะถูกสร้างขึ้นโดยศัตรู นี่คือจุดที่ PKI เข้ามาเล่น - ค่อนข้างบ่อย PKIX ที่มีใบรับรอง X.509 ที่ใช้ในเช่น เบราว์เซอร์ของคุณสำหรับการรับรองความถูกต้อง TLS (เซิร์ฟเวอร์)
Maarten Bodewes avatar
in flag
มิฉะนั้น ใช่ สามารถใช้ RSA เพื่อดำเนินการสร้างคีย์ได้ โดยมีข้อเสียเปรียบหลักคือการสร้างคู่คีย์ค่อนข้างช้า ดังนั้นหากคุณต้องการใช้คู่คีย์ใหม่สำหรับการเชื่อมต่อแต่ละครั้งเพื่อความปลอดภัยในการส่งต่อ คุณอาจประสบปัญหาด้านประสิทธิภาพ ด้วยเหตุนี้จึงใช้ (EC)DH แทน
kelalaka avatar
in flag
สิ่งนี้ตอบคำถามของคุณหรือไม่ [การเข้ารหัส RSA โดยตรงของคีย์ AES ปลอดภัยหรือไม่](https://crypto.stackexchange.com/questions/76855/is-direct-rsa-encryption-of-aes-keys-secure)
Score:2
ธง kr

ไม่ มันไม่ใช่แนวปฏิบัติที่ดี

  1. มันมีแนวโน้มที่จะ ผู้ชายที่อยู่ตรงกลาง จู่โจม. เมื่อเซิร์ฟเวอร์ได้รับรหัสสาธารณะ จะไม่ทราบว่ารหัสนี้มาจากไคลเอ็นต์หรือจาก "คนที่อยู่ตรงกลาง" ดังนั้น "คนที่อยู่ตรงกลาง" สามารถสกัดกั้นการรับส่งข้อมูลระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ สำหรับไคลเอ็นต์สามารถจำลองเซิร์ฟเวอร์ได้ สำหรับเซิร์ฟเวอร์สามารถจำลองไคลเอนต์ได้ ดังนั้น การสื่อสารทั้งหมดจะเป็น 1) MitM รู้จัก และ 2) ข้อมูลที่ส่งทั้งสองทิศทางสามารถแก้ไขได้โดย MitM
  • --> คุณสามารถหลีกเลี่ยงได้ หากคุณตรวจสอบไคลเอนต์กับเซิร์ฟเวอร์หรือตรวจสอบเซิร์ฟเวอร์กับไคลเอนต์โดยใช้ ใบรับรองคีย์สาธารณะ.
  1. มันมีแนวโน้มที่จะ เล่นซ้ำการโจมตี. สมมติว่าลูกค้าส่งคำสั่ง "โอน 1,000 USD ไปยังบัญชี 123456789" นี่อาจเป็นการดำเนินการที่ถูกต้องตามกฎหมาย แต่ถ้าผู้โจมตีสกัดกั้นการรับส่งข้อมูลและส่งซ้ำภายในระยะเวลาอันสั้น (เพื่อให้เซิร์ฟเวอร์ยังคงใช้คีย์เดียวกันสำหรับการเข้ารหัส AES สำหรับไคลเอนต์นี้) เซิร์ฟเวอร์จะไม่สามารถแยกแยะได้ว่าการรับส่งข้อมูลนี้มาจากไคลเอนต์จาก ผู้โจมตีและจะดำเนินการตามคำสั่งแม้ว่าคุณจะรับรองความถูกต้องของไคลเอ็นต์กับเซิร์ฟเวอร์หรือตรวจสอบความถูกต้องของเซิร์ฟเวอร์กับไคลเอ็นต์ ปัญหานี้จะยังคงอยู่
  • --> คุณสามารถหลีกเลี่ยงได้หากคุณใช้ ไม่เคย.
  1. สิ่งที่ดี: วิธีการปัจจุบันของคุณค่อนข้างดี ส่งต่อความลับ: เซสชันที่ผ่านมาได้รับการปกป้องจากการประนีประนอมคีย์ไคลเอ็นต์หรือรหัสผ่านเซสชันในอนาคต แต่ถ้าคุณแก้ไขปัญหา 1 ที่กล่าวถึงข้างต้น (การตรวจสอบสิทธิ์) และเริ่มใช้คีย์ RSA เดียวกันในหลายๆ เซสชัน คุณจะสูญเสียความลับในการส่งต่อ หากผู้โจมตีได้รับคีย์ส่วนตัว เซสชันที่ผ่านมาทั้งหมดจะถูกถอดรหัส เพื่อป้องกันคุณจะต้องมีมาตรการเพิ่มเติมเช่น ชั่วคราว การแลกเปลี่ยนคีย์ Diffie-Hellman.

  2. สิ่งสำคัญคือต้องใช้ RSA อย่างถูกต้องตามที่ @kelalaka กล่าวถึง ดูรายละเอียด ที่นี่ และ ที่นี่.

ดังนั้น การใช้ TLS ที่จัดเตรียมโดย Java อาจปลอดภัยกว่ามาก แทนที่จะใช้โปรโตคอลของคุณเอง

cn flag
คุณอาจเพิ่ม: สำหรับ TLS 1.3 คณะกรรมการกำหนดมาตรฐานได้ยกเลิก RSA สำหรับข้อตกลงหลักโดยสิ้นเชิง สิ่งที่ประวัติศาสตร์เกี่ยวกับการโจมตี PKCS#1 และ Bleichenbacher ได้แสดงให้เห็น: RSA อาจเป็นตัวเลือกที่ไม่ดีสำหรับการแลกเปลี่ยนคีย์ และไม่คุ้มกับความยุ่งยากที่จะทำให้ถูกต้อง เมื่อปัญหาทั้งหมดแก้ไขได้ง่ายกว่ามากเมื่อใช้วิธีอื่น

โพสต์คำตอบ

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