โพรโทคอล Station-to-Station (STS)

โพรโทคอลจากสถานีถึงสถานี (STS) (Diffie, van Oorschot, Wiener, 1992) ได้รับการออกแบบมาเพื่อให้การตกลงกุญแจที่มีการพิสูจน์ตัวตนโดยไม่ต้องมีบุคคลที่สามที่เชื่อถือได้ การแลกเปลี่ยนกุญแจ DH เพียงอย่างเดียวไม่มีการพิสูจน์ตัวตน ผู้โจมตีแบบคนกลางสามารถแทนที่ค่า DH ด้วยค่าของตนเอง และสร้างเซสชันแยกกับแต่ละฝ่ายที่เข้าใจว่าตนใช้กุญแจร่วมกัน STS ผสาน DH เข้ากับลายเซ็นดิจิทัลและใบรับรองกุญแจสาธารณะเพื่อให้ทั้งสองฝ่ายพิสูจน์ตัวตนซึ่งกันและกัน ทั้งสองฝ่ายพิสูจน์ตัวตนโดยลงลายเซ็นบนบันทึกการแลกเปลี่ยน DH ซึ่งผูกกุญแจเซสชันเข้ากับตัวตนของฝ่ายเหล่านั้น STS มีอิทธิพลโดยตรงต่อการออกแบบ IKE (การแลกเปลี่ยนกุญแจอินเทอร์เน็ตสำหรับ IPsec) และ SSH

โพรโทคอล STS ดำเนินการดังนี้ Alice และ Bob ตกลงใช้กลุ่ม DH ร่วมกัน (จำนวนเฉพาะ p และตัวกำเนิด g) (1) Alice ส่ง g^a mod p ให้ Bob (2) Bob ส่ง g^b mod p, Cert_B, Sig_B{g^b, g^a} ให้ Alice Bob ลงลายเซ็นบนการต่อกันของค่า DH ทั้งสองโดยใช้กุญแจส่วนตัวของตน (3) Alice ตรวจสอบใบรับรองและลายเซ็นของ Bob จากนั้นส่ง Cert_A, Sig_A{g^a, g^b} ซึ่งเข้ารหัสด้วยกุญแจเซสชัน K = (g^ab mod p) ตัวตนและลายเซ็นของ Alice ถูกเข้ารหัส จึงช่วยปกป้องตัวตนของ Alice จากผู้ดักฟังแบบไม่แทรกแซง ผู้ดักฟังดังกล่าวจะไม่สามารถเชื่อมโยง Alice กับเซสชันนี้ได้ ทั้งสองฝ่ายคำนวณ K = g^ab mod p และพิสูจน์ตัวตนซึ่งกันและกันผ่านลายเซ็น

การเปรียบเทียบ STS กับ DH ที่ไม่มีการพิสูจน์ตัวตนแสดงให้เห็นว่าการพิสูจน์ตัวตนเพิ่มสิ่งใดเข้ามา ใน DH ธรรมดา Mallory ดักจับ g^a และ g^b แล้วแทนที่ด้วย g^m กับ Alice และ g^m กับ Bob เพื่อสร้าง K1 = g^am และ K2 = g^bm Mallory จึงถอดรหัสการสื่อสารทั้งหมดได้ ใน STS Bob ลงลายเซ็นบน {g^b, g^a} โดยลายเซ็นนี้ครอบคลุมค่า DH ที่แน่นอนของเซสชันนี้ แม้ Mallory จะแทนที่ g^b ด้วย g^m แต่ก็ไม่สามารถปลอมลายเซ็นที่ถูกต้องโดยใช้กุญแจในใบรับรองของ Bob ได้ Alice จึงปฏิเสธเซสชันนั้น ประเด็นสำคัญคือ การพิสูจน์ตัวตนในการแลกเปลี่ยนกุญแจต้องครอบคลุมบันทึกการแลกเปลี่ยน DH ไม่ใช่เพียงคำกล่าวอ้างเกี่ยวกับตัวตน

STS มีคุณสมบัติความลับแบบส่งต่ออย่างสมบูรณ์ (PFS) เพราะกุญแจเซสชันได้มาจากค่า DH ชั่วคราว (g^a, g^b) ซึ่งถูกทิ้งหลังจบเซสชัน แม้กุญแจระยะยาวสำหรับลงลายเซ็นของ Bob จะถูกเจาะในภายหลัง เซสชัน STS ที่บันทึกไว้ก่อนหน้านี้ก็ไม่สามารถถอดรหัสได้ ผู้โจมตีต้องใช้เลขชี้กำลัง DH ชั่วคราว a และ b ซึ่งไม่เคยถูกเก็บไว้ คุณสมบัตินี้เป็นคุณสมบัติเดียวกับที่ต้องการใน TLS เมื่อใช้ชุดการเข้ารหัส ECDHE หากไม่มี DH ชั่วคราว เช่น ใช้การขนส่งกุญแจ RSA ซึ่งกุญแจเซสชันถูกเข้ารหัสด้วยกุญแจ RSA แบบคงที่ของเซิร์ฟเวอร์ การเจาะกุญแจระยะยาวจะทำให้เซสชันในอดีตทั้งหมดถูกถอดรหัสได้

STS เข้ารหัสใบรับรองและลายเซ็นของ Alice ในขั้นตอนที่ 3 จึงปกป้องตัวตนของผู้ตอบสนองจากผู้ดักฟังแบบไม่แทรกแซง ผู้สังเกตการณ์แบบไม่แทรกแซงจะเห็นเพียงค่า DH ของ Alice และใบรับรองของ Bob ซึ่ง Bob ส่งแบบไม่เข้ารหัสในขั้นตอนที่ 2 ตัวตนของ Alice จึงถูกซ่อนจากการดักฟังแบบไม่แทรกแซง ผู้โจมตีเชิงรุกที่พยายามโจมตีแบบ MITM จะถูกตรวจพบเมื่อการตรวจสอบลายเซ็นล้มเหลว ความไม่สมมาตรนี้ (ตัวตนของผู้เริ่มต้นเปิดเผยต่อผู้โจมตีเชิงรุก แต่ตัวตนของผู้ตอบสนองได้รับการปกป้องจากผู้ดักฟังแบบไม่แทรกแซง) เป็นการแลกเปลี่ยนในการออกแบบโดยเจตนา การปกป้องตัวตนของทั้งสองฝ่ายอย่างสมบูรณ์จากผู้โจมตีเชิงรุกต้องใช้โพรโทคอลที่ซับซ้อนขึ้น เช่น การแบ่งปันค่า DH ล่วงหน้าหรือการใช้องค์ประกอบของกลุ่มแบบนิรนาม

IKE (การแลกเปลี่ยนกุญแจอินเทอร์เน็ต) ซึ่งเป็นโพรโทคอลจัดการกุญแจสำหรับ IPsec มีที่มาจาก STS โดยตรง IKEv1 (RFC 2409) นำการพิสูจน์ตัวตนด้วยลายเซ็นแบบ STS มาใช้ในโหมดหลัก IKEv2 (RFC 7296) เป็นการออกแบบใหม่ที่กระชับกว่าและมีการแลกเปลี่ยนข้อความสี่ช่วง ได้แก่ IKE_SA_INIT (การแลกเปลี่ยน DH และค่าใช้ครั้งเดียว) และ IKE_AUTH (ตัวตน ใบรับรอง และลายเซ็นบนบันทึกการแลกเปลี่ยนของ IKE_SA_INIT) รูปแบบลายเซ็นคือ AUTH = PRF(SK_pi, transcript) สำหรับ PSK หรือเป็นลายเซ็นดิจิทัลบนออกเตตของ IKE_SA_INIT สำหรับการพิสูจน์ตัวตนด้วยใบรับรอง IKEv2 ยังรองรับโพรโทคอลการพิสูจน์ตัวตนแบบขยายได้ (EAP) สำหรับการพิสูจน์ตัวตนด้วยรหัสผ่านแบบเก่า ซึ่งคล้ายกับการรองรับวิธีการพิสูจน์ตัวตนต่าง ๆ ของ STS

การพิสูจน์ตัวตนด้วยกุญแจของ SSH ใช้กลไกที่คล้ายกับขั้นตอนที่ 3 ของ STS หลังจากการแลกเปลี่ยนกุญแจ DH (SSH_MSG_KEXDH_REPLY มีทั้งกุญแจสาธารณะของเซิร์ฟเวอร์ ค่า DH และลายเซ็นบนแฮชการแลกเปลี่ยน) ไคลเอนต์จะตรวจสอบกุญแจโฮสต์ของเซิร์ฟเวอร์ สำหรับการพิสูจน์ตัวตนของไคลเอนต์ (SSH_MSG_USERAUTH_REQUEST พร้อมวิธี publickey) ไคลเอนต์จะลงลายเซ็นบน {session_id, username, service, method, key_algo, public_key} โดยใช้กุญแจส่วนตัวของตน session_id ได้มาจากบันทึกการแลกเปลี่ยน DH จึงผูกการพิสูจน์ตัวตนเข้ากับเซสชันนี้โดยเฉพาะ และป้องกันการปลอมแปลงข้ามเซสชันที่สร้างปัญหาให้กับ NS SSH ไม่ได้ใช้ใบรับรองเป็นค่าเริ่มต้น แต่รองรับใบรับรองผ่าน ssh-keygen -s (การลงลายเซ็นใบรับรอง) สำหรับการนำไปใช้งานขนาดใหญ่

STS เป็นสมาชิกของตระกูลโพรโทคอลการแลกเปลี่ยนกุญแจที่มีการพิสูจน์ตัวตน (AKE) SIGMA (การลงลายเซ็นและ MAC) ซึ่ง Hugo Krawczyk ทำให้อยู่ในรูปแบบทางการ SIGMA เพิ่ม MAC ให้กับ STS โดยแต่ละฝ่ายลงลายเซ็นบนบันทึกการแลกเปลี่ยนและคำนวณ MAC ให้กับตัวตนของตนภายใต้กุญแจเซสชัน: MAC(K, identity) MAC จะผูกตัวตนเข้ากับกุญแจเซสชัน และป้องกันการโจมตีเฉพาะแบบหนึ่งที่ผู้โจมตีสามารถเชื่อมโยงลายเซ็นจากเซสชันต่างกันได้ SIGMA-I (ปกป้องตัวตนของผู้เริ่มต้น), SIGMA-R (ปกป้องตัวตนของผู้ตอบสนอง) และ SIGMA-0 (ไม่มีการปกป้องตัวตน) เป็นรูปแบบต่าง ๆ IKEv2 และ X3DH ของซิกแนลเป็นโพรโทคอลในตระกูล SIGMA รูปแบบ SIGMA ให้การพิสูจน์ความปลอดภัยที่เคร่งครัดสำหรับการออกแบบลักษณะเดียวกับ STS

STS มีช่องโหว่ต่อการโจมตีการปลอมตัวเมื่อกุญแจถูกเจาะ (KCI): หากกุญแจระยะยาวของ Alice ถูกเจาะ ผู้โจมตีสามารถปลอมตัวเป็นฝ่ายใดก็ได้เพื่อสื่อสารกับ Alice ในเซสชันใหม่ (เพราะผู้โจมตีสามารถปลอมลายเซ็นของ Alice บนบันทึกการแลกเปลี่ยนใด ๆ ได้) นั่นหมายความว่าการที่กุญแจของฝ่ายหนึ่งถูกเจาะทำให้ผู้โจมตีสามารถปลอมตัวเป็นฝ่ายอื่นต่อฝ่ายนั้นได้ KCI เป็นคุณสมบัติที่หลีกเลี่ยงไม่ได้ในโพรโทคอล AKE ที่อาศัยลายเซ็น การป้องกันต้องทำให้กุญแจเซสชันขึ้นอยู่กับข้อมูลจากทั้งสองฝ่ายในลักษณะที่ป้องกันไม่ให้ฝ่ายที่ถูกเจาะแทนที่ข้อมูลนั้น HMQV (Menezes-Qu-Vanstone แบบแฮช) และ NAXOS ให้การต้านทาน KCI โดยแลกกับความซับซ้อนเพิ่มเติม

STS ให้คุณสมบัติการป้องกันการปฏิเสธความรับผิดชอบ: ลายเซ็นพิสูจน์ได้อย่างแน่นอนด้วยวิธีเข้ารหัสว่าใครพูดอะไร คุณสมบัตินี้อาจไม่เป็นที่ต้องการในบางกรณี ในการสนทนาส่วนตัว ผู้เข้าร่วมอาจไม่ต้องการให้สามารถนำหลักฐานทางการเข้ารหัสของข้อความที่ตนกล่าวไปแสดงต่อศาลได้ การส่งข้อความแบบไม่เปิดเผยบันทึก (OTR) และดับเบิลแรตเชตของซิกแนลให้คุณสมบัติการปฏิเสธความรับผิดชอบได้ แทนที่จะลงลายเซ็นบนข้อความ ทั้งสองใช้กุญแจ MAC ที่ทั้งผู้ส่งและผู้รับถือครอง หลังการสนทนา ทั้งสองฝ่ายสามารถอ้างว่าอีกฝ่ายสร้างข้อความขึ้นเองได้ เนื่องจากต่างฝ่ายต่างมีกุญแจที่ใช้สร้าง MAC การแลกเปลี่ยนนี้คือ การมีคุณสมบัติการปฏิเสธความรับผิดชอบได้ต้องแลกกับการสูญเสียการป้องกันการปฏิเสธความรับผิดชอบ STS และการออกแบบลักษณะเดียวกันเหมาะกับกรณีที่ต้องมีความรับผิดชอบตรวจสอบได้ ส่วน OTR และซิกแนลเหมาะกับกรณีที่ให้ความสำคัญกับการปฏิเสธความรับผิดชอบได้

ความปลอดภัยของ STS ได้รับการวิเคราะห์แบบไม่เป็นทางการในเอกสารต้นฉบับ แต่ได้รับการพิสูจน์อย่างเป็นทางการโดย Bellare และ Rogaway (1993, 1994) ในแบบจำลองความปลอดภัยของ AKE ที่มีความสำคัญในวงการ ทั้งสองกำหนดความหมายของการที่โพรโทคอลแลกเปลี่ยนกุญแจจะปลอดภัยไว้ว่า กุญแจเซสชันต้องแยกแยะไม่ได้จากค่าสุ่ม แม้ผู้โจมตีจะสามารถลงทะเบียนฝ่ายต่าง ๆ เปิดเผยกุญแจเซสชัน เปิดเผยกุญแจระยะยาว (ยกเว้นของเซสชันเป้าหมาย) และควบคุมเครือข่ายได้ แบบจำลองความปลอดภัยที่อิงการจำลองนี้ ซึ่งได้รับการขยายโดย Canetti-Krawczyk และต่อมาโดย UC (การประกอบเข้าด้วยกันแบบสากล) เป็นมาตรฐานสำหรับการพิสูจน์โพรโทคอล AKE ในปัจจุบัน TLS 1.3 ซิกแนล และนอยส์ล้วนมีการพิสูจน์อย่างเป็นทางการในรูปแบบต่าง ๆ ของแบบจำลองนี้

STS ผสานการแลกเปลี่ยนคีย์ DH ชั่วคราวเข้ากับลายเซ็นดิจิทัล เพื่อให้เกิดการตกลงคีย์ที่มีการรับรองตัวตนโดยไม่ต้องใช้ TTP ทั้งสองฝ่ายลงลายเซ็นบนบันทึกการสื่อสารของ DH ซึ่งทำให้การรับรองตัวตนผูกอยู่กับเซสชันนั้น STS ให้ความลับส่งต่อ (DH ชั่วคราว) การรับรองตัวตนซึ่งกันและกัน (ลายเซ็น) และการปกป้องข้อมูลระบุตัวตนของผู้ตอบ (ข้อมูลของ Alice ถูกเข้ารหัสก่อนส่ง) STS มีอิทธิพลโดยตรงต่อ IKEv2 และการรับรองตัวตนด้วยคีย์ของ SSH SIGMA ทำให้ STS เป็นรูปแบบที่เป็นทางการด้วย MAC ของข้อมูลระบุตัวตนและการพิสูจน์ความปลอดภัย KCI เป็นจุดอ่อนโดยธรรมชาติของ STS ซึ่งบรรเทาได้ด้วย HMQV/NAXOS การปฏิเสธความเชื่อมโยงได้ (เช่นเดียวกับ Signal) จำเป็นต้องแทนที่ลายเซ็นด้วย MAC เพื่อรับรองความถูกต้องระดับข้อความ