เมื่อคุณถือว่า C ทำหน้าที่เป็นปฏิปักษ์ กำลังดักฟัง และสามารถสร้างข้อความตามข้อมูลที่ได้รับมา คุณต้องออกแบบโปรโตคอลด้วยความระมัดระวัง สิ่งนี้เกิดจากข้อเท็จจริงที่ว่า C สามารถถ่ายทอด เล่นซ้ำ และสร้างข้อความได้ ดังนั้น คุณต้องป้องกันการเล่นซ้ำและการโจมตีจากคนกลาง นอกจากนี้ การจัดการเซสชันโปรโตคอล (พร้อมกัน) หลายเซสชัน
คุณรู้อยู่แล้วว่าลายเซ็นคงที่อาจไม่เพียงพอ โดยพื้นฐานแล้ว ปัญหาของคุณคือแรงจูงใจสำหรับโปรโตคอลการตรวจสอบสิทธิ์ และการออกแบบนั้นไม่ใช่เรื่องเล็กน้อย หากคุณดูที่โปรโตคอล NeedhamâSchroeder 1 หรือโปรโตคอล Woo-Lam 2 คุณจะเห็นว่าเวกเตอร์การโจมตีที่คาดไม่ถึงอาจทำให้โปรโตคอลของคุณเสียหายได้ เนื่องจากทั้งสองตัวอย่างไม่ปลอดภัยในเวอร์ชันดั้งเดิม
โดยพื้นฐานแล้ว แนวทางปฏิบัติที่ดีที่สุดสำหรับการออกแบบโปรโตคอลที่ปลอดภัยคือ:
- ตั้งสมมติฐานในแง่ร้ายที่สุด
- ใส่ผู้ส่งและผู้รับในข้อความ (เช่น กุญแจสาธารณะ)
- ใช้การเข้ารหัสเพื่อให้แน่ใจว่าผู้รับที่ถูกต้องเท่านั้นที่สามารถอ่านเนื้อหาได้
- ใช้ nonces / timestamps เพื่อรับความสดใหม่
- สร้าง nonce ด้วยตัวคุณเองเพื่อป้องกันการโจมตีซ้ำ
- เซ็นชื่อและเข้ารหัสส่วนประกอบร่วมกันเสมอ
แต่ยังคงมี: มีโปรโตคอลที่ถือว่าปลอดภัยซึ่งไม่ปฏิบัติตามทุกจุดและโปรโตคอลที่ไม่ปลอดภัยที่ปฏิบัติตาม
ไม่ว่าในกรณีใด คุณต้องการวิเคราะห์โปรโตคอลของคุณ (กึ่ง) โดยอัตโนมัติโดยใช้ตัวอย่างการตรวจสอบแบบจำลองหรือการพิสูจน์ทฤษฎีบท