หลักการออกแบบโพรโทคอลที่ปลอดภัย

การออกแบบโพรโทคอลที่ปลอดภัยตั้งสมมติฐานว่าผู้โจมตีควบคุมเครือข่ายทั้งหมด แบบจำลอง Dolev-Yao (1983) ระบุว่า ผู้โจมตีสามารถดักจับ อ่าน หน่วงเวลา เล่นซ้ำ ลบ และแก้ไขข้อความใด ๆ ที่อยู่ระหว่างการส่งได้ ผู้โจมตีสามารถสร้างข้อความที่แยกไม่ออกจากข้อความของฝ่ายที่ซื่อสัตย์ ผู้โจมตีสามารถประกอบข้อความใหม่จากส่วนประกอบของข้อความที่ทราบอยู่ ผู้โจมตีไม่สามารถทำลาย primitive ทางการเข้ารหัสได้ (ถอดรหัสโดยไม่มีคีย์หรือปลอมแปลงลายเซ็นไม่ได้) สิ่งสำคัญคือ ผู้โจมตีมีขอบเขตด้านการคำนวณ—ทำงานได้ในเวลาพหุนาม—แต่ควบคุมช่องทางการสื่อสารทั้งหมด ความปลอดภัยของโพรโทคอลหมายถึงการบรรลุเป้าหมายด้านการรับรองตัวตนและความลับ แม้ต้องเผชิญกับผู้โจมตีที่มีความสามารถสูงเช่นนี้ โดยอาศัยเพียงความยากในการคำนวณของ primitive พื้นฐาน

Abadi และ Needham (1994) สรุปบทเรียนเชิงปฏิบัติจากการออกแบบโพรโทคอลเป็นชุดหลักการดังนี้ (1) ทุกข้อความควรบอกความหมายของตนเอง: การตีความข้อความควรสมบูรณ์ในตัว ไม่ขึ้นกับบริบท (2) เงื่อนไขที่ทำให้ผู้มีส่วนร่วมดำเนินการใด ๆ ควรระบุไว้อย่างชัดเจนในโพรโทคอล (3) หากข้อมูลระบุตัวตนของผู้มีส่วนร่วมมีความสำคัญ ควรระบุไว้อย่างชัดเจนในข้อความ (4) ต้องชัดเจนว่าใช้การเข้ารหัสด้วยเหตุใด: การเข้ารหัสให้การรักษาความลับ ส่วนการลงลายเซ็นให้การรับรองตัวตน—อย่าใช้การเข้ารหัสแทนการลงลายเซ็น (5) ควรเข้ารหัสข้อความในชั้นของโพรโทคอลที่ต้องการรักษาความลับ หลักการเหล่านี้ช่วยป้องกันข้อบกพร่องประเภท NS ได้มากมาย

การโจมตีแบบเล่นซ้ำเป็นหนึ่งในช่องโหว่ของโพรโทคอลที่พบได้บ่อยที่สุด กลไกตรวจสอบความใหม่ช่วยให้มั่นใจว่าข้อความที่ได้รับถูกสร้างขึ้นเมื่อไม่นานมานี้ ไม่ใช่ข้อความจากเซสชันเก่าที่ถูกนำมาเล่นซ้ำ มีสองแนวทาง: (1) Nonce (หมายเลขที่ใช้เพียง ONCE)—การท้าทายและตอบกลับที่ผู้รับส่งค่าสุ่มและคาดหวังให้ค่านั้นถูกส่งกลับมาในคำตอบ คำตอบต้องมี nonce ที่เข้ารหัสหรือลงลายเซ็นไว้ เพื่อป้องกันไม่ให้บันทึกเก่าถูกนำมาใช้ตอบการท้าทายได้ (2) ประทับเวลา—ทั้งสองฝ่ายใส่เวลาปัจจุบัน และจะปฏิเสธข้อความที่มีประทับเวลาล้าสมัย ประทับเวลาต้องใช้นาฬิกาที่ทำให้ตรงกัน (Kerberos ยอมให้คลาดเคลื่อนได้ 5 นาที) ควรใช้ nonce เมื่อไม่สามารถทำให้นาฬิกาตรงกันได้ ส่วนประทับเวลาช่วยให้การตรวจสอบแบบไร้สถานะทำได้ง่ายขึ้น

การใช้คีย์เข้ารหัสเดียวกันสำหรับหลายวัตถุประสงค์ทำให้เกิดปฏิสัมพันธ์ที่เป็นอันตรายได้ หากใช้คีย์ K ทั้งสำหรับการเข้ารหัสและการรับรองตัวตน ผู้โจมตีอาจป้อนข้อความเข้ารหัสที่สร้างขึ้นเป็นพิเศษให้กลไกการรับรองตัวตน เพื่อดึงข้อมูลออกมา TLS 1.3 หลีกเลี่ยงปัญหานี้อย่างเคร่งครัดด้วย HKDF-Expand-Label ซึ่งใช้ป้ายกำกับที่แตกต่างกันสำหรับคีย์ที่สร้างขึ้นแต่ละรายการ ได้แก่ "c hs traffic" (การจับมือของไคลเอนต์), "s hs traffic" (การจับมือของเซิร์ฟเวอร์) และ "c ap traffic" (แอปพลิเคชันของไคลเอนต์) แม้คีย์การจับมือจะถูกเปิดเผย คีย์แอปพลิเคชันที่สร้างจากแขนง HKDF อื่นก็ยังคงปลอดภัย การออกแบบโพรโทคอลต้องตรวจสอบคีย์ทุกตัวเพื่อหาความเสี่ยงจากการใช้หลายวัตถุประสงค์ และสร้างคีย์แยกต่างหากสำหรับแต่ละวัตถุประสงค์

ข้อมูลรับรองการพิสูจน์ตัวตนต้องถูกผูกไว้กับเซสชันเฉพาะที่นำไปใช้ หากไม่มีการผูกดังกล่าว ข้อมูลรับรองที่ได้มาในเซสชันหนึ่งอาจถูกนำกลับมาใช้ซ้ำในอีกเซสชันหนึ่งได้ เทคนิคมีดังนี้: (1) ใส่ตัวระบุเซสชันไว้ในข้อมูลที่ลงลายมือชื่อหรือคำนวณ MAC (2) ใส่บันทึกการแลกเปลี่ยน DH ไว้ในลายมือชื่อ (แนวทาง STS) (3) ใช้กุญแจเซสชันที่ได้จาก HKDF คำนวณ MAC บนข้อมูลระบุตัวตน (แนวทาง SIGMA) ข้อความเสร็จสิ้นของ TLS 1.3: MAC(server_finished_key, transcript_hash) — MAC ครอบคลุมบันทึกการแลกเปลี่ยนทั้งหมด ดังนั้นการนำข้อความเสร็จสิ้นจากเซสชันอื่นมาใช้ซ้ำจึงไม่สำเร็จ การผูกนี้เองที่ป้องกันการโจมตีข้ามเซสชันซึ่งพบใน Kerberos รุ่นแรกและตัวแปรของ NS

โพรโทคอลควรเปิดเผยเฉพาะข้อมูลขั้นต่ำที่จำเป็นต่อการทำงานเท่านั้น ควรเปิดเผยตัวตนเฉพาะแก่ผู้ที่จำเป็นต้องทราบ อย่าใส่หมายเลขลำดับใบรับรองหรือตัวระบุที่ทำให้เชื่อมโยงเซสชันเข้ากับตัวตนได้ เว้นแต่จำเป็น TLS 1.3 เข้ารหัสใบรับรองของเซิร์ฟเวอร์ (ต่างจาก TLS 1.2 ที่ส่งเป็นข้อความธรรมดา) จึงลดข้อมูลที่ผู้ดักฟังแบบพาสซีฟนำไปใช้ได้ ESNI (SNI ที่เข้ารหัส ซึ่งปัจจุบันคือ ECH — ClientHello ที่เข้ารหัส) เข้ารหัสการบ่งชี้ชื่อเซิร์ฟเวอร์เพื่อซ่อนว่าไคลเอนต์กำลังเชื่อมต่อกับเซิร์ฟเวอร์ใด การเปิดเผยข้อมูลขั้นต่ำยังเป็นหลักการของการออกแบบโทเค็นด้วย โดยข้ออ้างสิทธิ์ของ JWT ควรมีเฉพาะข้อมูลที่จำเป็นต่อการอนุญาตเท่านั้น ไม่ใช่ระเบียนข้อมูลตัวตนทั้งหมด

การเจรจาเวอร์ชันเป็นพื้นผิวการโจมตีที่พบได้บ่อย ผู้โจมตีจะตัดออกหรือแก้ไข ClientHello เพื่อบังคับให้ทั้งสองฝ่ายใช้โพรโทคอลเวอร์ชันเก่าที่อ่อนแอกว่า วิธีป้องกันมีดังนี้: (1) การเจรจาเวอร์ชันที่ผ่านการพิสูจน์ตัวตน — ใส่เวอร์ชันที่เจรจาได้ไว้ในบันทึกการแลกเปลี่ยนที่ลงลายมือชื่อ (ข้อความเสร็จสิ้นของ TLS ครอบคลุม ClientHello ซึ่งรวมเวอร์ชันไว้ด้วย) (2) ตัวบ่งชี้การลดระดับ — TLS 1.3 กำหนดไบต์พิเศษใน ServerHello.Random เมื่อลดระดับไปใช้ TLS 1.2 เพื่อให้ไคลเอนต์ตรวจจับการลดระดับได้ (3) การป้องกันความไม่เข้ากันกับเวอร์ชัน — เซิร์ฟเวอร์ต้องปฏิเสธ ClientHellos ที่มีรูปแบบไม่ถูกต้องโดยไม่ลดระดับกลับไปใช้เวอร์ชันอื่นอย่างเงียบ ๆ (4) SCSV — TLS_FALLBACK_SCSV แจ้งเซิร์ฟเวอร์ว่าไคลเอนต์กำลังลองเชื่อมต่อใหม่ด้วยเวอร์ชันที่ต่ำกว่า ทำให้เซิร์ฟเวอร์ปฏิเสธการลดระดับที่ไม่ถูกต้องได้

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

โพรโทคอลที่ซับซ้อนมักล้มเหลวตรงขอบเขตของเครื่องสถานะ หากการเปลี่ยนสถานะไม่ชัดเจน — จะเกิดอะไรขึ้นหากข้อความที่ 3 มาถึงก่อนข้อความที่ 2 หรือหากมีข้อความประเภทที่ไม่คาดคิดมาถึง — การทำงานของส่วนต่าง ๆ อาจไม่สอดคล้องกัน ทำให้เกิดความไม่สอดคล้องที่ผู้โจมตีใช้ประโยชน์ได้ ข้อกำหนดของโพรโทคอลต้องระบุสิ่งต่อไปนี้: เครื่องสถานะทั้งหมด (สถานะและการเปลี่ยนสถานะที่ถูกต้องทุกกรณี) พฤติกรรมเมื่อได้รับข้อมูลนำเข้าที่ไม่คาดคิด (ปฏิเสธพร้อมข้อผิดพลาดเฉพาะหรือเพิกเฉยอย่างเงียบ ๆ) ระยะหมดเวลาและขีดจำกัดการส่งซ้ำ รวมถึงการล้างข้อมูลเซสชัน ในอดีต SSL/TLS ประสบปัญหาจากการทำงานของเครื่องสถานะที่แตกต่างกันในแต่ละการนำไปใช้ — CVE-2014-0160 (Heartbleed) เป็นความล้มเหลวของเครื่องสถานะโดยพื้นฐาน กล่าวคือ มีการประมวลผลคำขอส่งสัญญาณชีพในสถานะที่ไม่ได้จำกัดขอบเขตหน่วยความจำอย่างเหมาะสม

โพรโทคอลเข้ารหัสมักไม่ได้ถูกใช้งานเพียงลำพัง โพรโทคอล AKE จะสร้างกุญแจเซสชัน ซึ่งจากนั้นจะถูกใช้โดยโพรโทคอลในชั้นแอปพลิเคชัน หากออกแบบโพรโทคอล AKE และโพรโทคอลแอปพลิเคชันแยกจากกันโดยไม่คำนึงถึงความสามารถในการประกอบร่วมกัน การทำงานร่วมกันอาจทำให้ความปลอดภัยเสียหายได้ กรอบงาน Universal Composability (UC) (Canetti, 2001) นำเสนอแบบจำลองที่เข้มงวดสำหรับการประกอบโพรโทคอล โดยโพรโทคอลจะปลอดภัยตาม UC หากยังคงปลอดภัยเมื่อประกอบเข้ากับโพรโทคอลอื่นที่ปลอดภัยตาม UC ในรูปแบบใด ๆ TLS 1.3, Signal และ Noise มุ่งให้มีความปลอดภัยที่ประกอบร่วมกันได้ ในทางปฏิบัติ ควรใช้การผูกช่องทาง (ส่งออกแฮชของบันทึกการแลกเปลี่ยน) เพื่อเชื่อมเซสชัน AKE เข้ากับการพิสูจน์ตัวตนของแอปพลิเคชันในภายหลัง ซึ่งป้องกันการส่งต่อข้อมูลรับรองระหว่างเซสชันที่สร้างขึ้นโดยโพรโทคอล AKE เดียวกัน

ผู้ออกแบบโพรโทคอลมักทำผิดพลาดในรูปแบบเดิม ๆ ซ้ำแล้วซ้ำเล่า (1) การสร้างการเข้ารหัสขึ้นเอง: การพัฒนาโครงสร้างการเข้ารหัสแบบบล็อก, MAC หรือการสร้างกุญแจเองโดยไม่มีการทบทวนโดยผู้เชี่ยวชาญ (2) ความไว้วางใจโดยนัย: สันนิษฐานแหล่งที่มาของข้อความจากบริบทเครือข่ายแทนหลักฐานทางการเข้ารหัส (3) การรักษาความปลอดภัยที่เลือกเปิดปิดได้: ทำให้การเข้ารหัสหรือการพิสูจน์ตัวตนกำหนดค่าได้ ซึ่งท้ายที่สุดมักนำไปสู่การลดระดับ (4) โทเค็นที่มีอายุยาวนานโดยเพิกถอนไม่ได้: ออก JWT หรือกุญแจเซสชันที่มีอายุการใช้งานยาวนานโดยไม่มีกลไกเพิกถอน (5) การเพิกเฉยต่อช่องทางข้อผิดพลาด: การไม่พิสูจน์ตัวตนของข้อความข้อผิดพลาดเปิดโอกาสให้ผู้โจมตีแทรกข้อผิดพลาดเพื่อชักนำพฤติกรรมของโพรโทคอล (6) การใช้การเข้ารหัสเพื่อพิสูจน์ตัวตน: การเข้ารหัสข้อมูลไม่ได้ยืนยันแหล่งที่มาของข้อมูล หากไม่มี MAC หรือลายมือชื่อ

การออกแบบโพรโทคอลที่ปลอดภัยนำหลักการที่ได้รับการยอมรับมาใช้ ได้แก่ แบบจำลองผู้โจมตี Dolev-Yao (ผู้โจมตีที่ควบคุมเครือข่าย) หลักการของ Abadi-Needham (การระบุตัวตนอย่างชัดเจนและข้อความที่มีข้อมูลครบถ้วนในตัวเอง) ความใหม่ของข้อมูลผ่านค่าที่ใช้ครั้งเดียวหรือเวลาประทับ การแยกกุญแจโดยใช้ HKDF พร้อมป้ายกำกับที่แตกต่างกัน การผูกข้อมูลรับรองการพิสูจน์ตัวตนเข้ากับเซสชัน การเปิดเผยข้อมูลขั้นต่ำ การป้องกันการลดระดับผ่านการพิสูจน์ตัวตนของบันทึกการแลกเปลี่ยน ความไม่สามารถดัดแปลงได้ผ่าน AEAD และการทำแฮชบันทึกการแลกเปลี่ยน เครื่องสถานะที่ชัดเจนพร้อมการจัดการข้อผิดพลาดที่กำหนดไว้อย่างแน่นอน รวมถึงความสามารถในการประกอบร่วมกันผ่านการพิสูจน์ความปลอดภัยตามแบบจำลอง UC การละเมิดหลักการเหล่านี้เป็นสาเหตุของช่องโหว่ด้านการเข้ารหัสระดับโพรโทคอลที่เป็นที่รู้จักเกือบทั้งหมด