เฟรมเวิร์กโพรโทคอล Noise

Noise Protocol Framework (Trevor Perrin, 2016; ฉบับปรับปรุงปัจจุบันปี 2018) เป็นกรอบงานสำหรับสร้างโพรโทคอลช่องทางปลอดภัยโดยใช้ primitive ชุดเล็กและภาษารูปแบบ แทนที่จะกำหนดโพรโทคอลเดียว Noise กำหนดคลังคำศัพท์ของรูปแบบการจับมือ ซึ่งอธิบายลำดับและการเรียงลำดับของการดำเนินการ DH รูปแบบ Noise ที่ถูกต้องทุกรูปแบบสามารถนำไปสร้างเป็นอินสแตนซ์ด้วยฟังก์ชัน DH (Curve25519 หรือ Curve448) การเข้ารหัส (AESGCM หรือ ChaChaPoly) และแฮช (SHA-256, SHA-512, BLAKE2) ที่ระบุจริง Noise ถูกใช้ใน WireGuard, WhatsApp, Signal (ในฐานะพื้นฐานของ X3DH), Lightning Network และ I2P

การจับมือของ Noise ทุกครั้งมีผู้เริ่มต้น (I) และผู้ตอบ (R) แต่ละฝ่ายอาจมีคีย์สองประเภท ได้แก่ คีย์คงที่ (คีย์ระบุตัวตนระยะยาว เขียนแทนด้วย s/S) และคีย์ชั่วคราว (สร้างขึ้นใหม่สำหรับแต่ละเซสชัน เขียนแทนด้วย e/E) ตัวอักษรพิมพ์เล็กหมายถึงคีย์ของฝ่ายภายในเครื่อง ส่วนตัวอักษรพิมพ์ใหญ่หมายถึงคีย์สาธารณะของฝ่ายระยะไกล รูปแบบ Noise จะระบุว่าคีย์ใดถูกส่ง (เป็นข้อความธรรมดาหรือเข้ารหัส) และดำเนินการ DH ใดบ้าง ตัวอย่างเช่น "e" หมายถึง "ส่งคีย์สาธารณะชั่วคราวของฉัน" ส่วน "es" หมายถึง "ดำเนินการ DH(my_ephemeral, remote_static)" ผลลัพธ์ DH แต่ละรายการจะถูกผสมเข้าไปในสถานะแฮชที่กำลังดำเนินอยู่ของการจับมือ

แกนหลักของ Noise คือ SymmetricState ซึ่งรักษาค่าสามค่า ได้แก่ ck (คีย์เชื่อมโยง เริ่มต้นด้วยแฮชของชื่อโพรโทคอล), h (แฮชการจับมือ หรือแฮชของบันทึกการสื่อสารที่กำลังคำนวณ) และ k (คีย์เข้ารหัสปัจจุบัน) MixKey(input) เรียกใช้ HKDF(ck, input) เพื่อปรับปรุง ck และ k ส่วน MixHash(data) จะแฮช data แล้วผสมเข้ากับ h EncryptAndHash(plaintext) จะเข้ารหัสด้วย k แล้วผสมข้อความเข้ารหัสเข้ากับ h ขณะที่ DecryptAndHash(ciphertext) จะถอดรหัสและผสมข้อความเข้ารหัสเข้ากับ h แฮชการจับมือ h ทำหน้าที่ผูกกับบันทึกการสื่อสาร—การแก้ไขข้อความใด ๆ โดยผู้โจมตีจะทำให้ h เปลี่ยนและทำให้การถอดรหัสล้มเหลว เมื่อจบการจับมือ Split() จะสร้าง CipherStates แยกกันสองชุดสำหรับการส่งและการรับ

Noise_XX เป็นรูปแบบการรับรองตัวตนซึ่งกันและกันที่ใช้กันมากที่สุด โดยให้การรับรองตัวตนด้วยคีย์คงที่ของทั้งสองฝ่าย และส่งคีย์คงที่ของทั้งสองฝ่ายระหว่างการจับมือ รูปแบบ: (1) -> e (ผู้เริ่มต้นส่งคีย์สาธารณะชั่วคราว) (2) <- e, ee, s, es (ผู้ตอบส่งคีย์ชั่วคราว ดำเนินการ DH(e,e) และ DH(e,s_resp) แล้วส่งคีย์คงที่ที่เข้ารหัส) (3) -> s, se (ผู้เริ่มต้นส่งคีย์คงที่ที่เข้ารหัส และดำเนินการ DH(s_init, e_resp)) หลังขั้นตอนที่ 3 ทั้งสองฝ่ายได้ผสมผลลัพธ์ DH สามรายการเข้ากับคีย์เซสชัน ได้แก่ ee (ความลับส่งต่อ), es (การรับรองเซิร์ฟเวอร์) และ se (การรับรองไคลเอนต์) คีย์เซสชันไม่ขึ้นกับการที่คีย์ระยะยาวใด ๆ ถูกเปิดเผยหลังจบเซสชัน

WireGuard ใช้รูปแบบที่พัฒนามาจาก Noise_IK ซึ่งผู้เริ่มต้นทราบคีย์คงที่ของผู้ตอบล่วงหน้า (1) -> e, es, s, ss (ผู้เริ่มต้นส่งคีย์ชั่วคราว ดำเนินการ DH(e, S_resp) ส่งคีย์คงที่ที่เข้ารหัส และดำเนินการ DH(s_init, S_resp)) (2) <- e, ee, se (ผู้ตอบส่งคีย์ชั่วคราว ดำเนินการ DH(e_resp, e_init) และ DH(e_resp, S_init)) รูปแบบ IK ช่วยซ่อนข้อมูลระบุตัวตนของผู้เริ่มต้น (คีย์คงที่ของผู้เริ่มต้นถูกเข้ารหัสด้วยคีย์คงที่ของผู้ตอบในขั้นตอนที่ 1) และทำงานเสร็จภายในหนึ่ง RTT WireGuard เพิ่มประทับเวลาไว้ภายในข้อมูลเพย์โหลดของผู้เริ่มต้นที่เข้ารหัส เพื่อป้องกันการเล่นซ้ำ สิ่งนี้ทำให้ WireGuard มีความเรียบง่ายอันเป็นเอกลักษณ์ นั่นคือการจับมือ VPN ที่เสร็จสมบูรณ์ภายในแพ็กเก็ต UDP สองแพ็กเก็ต

แฮชการจับมือ h เมื่อจบการจับมือของ Noise คือแฮชของบันทึกการสื่อสารที่ครอบคลุมทุกข้อความที่ส่ง ค่านี้ทำหน้าที่เป็นค่าผูกช่องทาง—ทั้งสองฝ่ายคำนวณ h เดียวกัน และโพรโทคอลของบุคคลที่สามใด ๆ ที่ต้องการผูกกับเซสชัน Noise สามารถใส่ h เป็นค่า nonce หรือรหัสช่องทางได้ สิ่งนี้ทำให้เกิดการรับรองตัวตนแบบประกอบได้ กล่าวคือ ขั้นตอนการรับรองตัวตนด้วยใบรับรองแบบ TLS สามารถทำงานหลังการจับมือของ Noise และผูกใบรับรองเข้ากับเซสชันเฉพาะนี้ผ่าน h การผูกช่องทางช่วยป้องกันการโจมตีแบบส่งต่อข้อมูลรับรอง ซึ่งข้อมูลรับรองตัวตนจากเซสชันหนึ่งถูกนำมาเล่นซ้ำกับอีกเซสชันหนึ่ง Split() ส่ง h ให้แอปพลิเคชันพร้อมกับคีย์เซสชัน

Noise รองรับรูปแบบการเลื่อนออกไปสำหรับสถานการณ์ที่ผู้เริ่มต้นไม่ทราบคีย์คงที่ของผู้ตอบล่วงหน้า Noise_NX (ผู้เริ่มต้นไม่มีคีย์คงที่ ผู้ตอบส่งคีย์ของตน) มีลักษณะคล้าย TLS ทางเดียว Noise_XX รองรับกรณีที่ทั้งสองฝ่ายต้องแลกเปลี่ยนคีย์กัน Noise_IK สามารถเปลี่ยนไปใช้ Noise_XXfallback ได้ หากการคาดเดาคีย์คงที่ของผู้ตอบโดยผู้เริ่มต้นไม่ถูกต้อง (เช่น หลังการหมุนเวียนคีย์) รูปแบบทางเลือกสำรองช่วยให้ผู้ตอบส่งสัญญาณว่า "คุณใช้คีย์ผิด นี่คือคีย์สาธารณะใหม่ของฉัน" โดยไม่เปิดเผยต่อผู้สังเกตการณ์ภายนอกว่ามีการใช้ทางเลือกสำรอง จึงยังคงความไม่เปิดเผยรายละเอียดของโพรโทคอลไว้

WhatsApp และ Signal ใช้ Noise_XX เพื่อสร้างช่องทางปลอดภัยระหว่างไคลเอนต์กับเซิร์ฟเวอร์ โพรโทคอลไบนารีของ WhatsApp ใช้ Noise_XX ร่วมกับ Curve25519, ChaChaPoly และ SHA-256 คีย์คงที่ของไคลเอนต์คือคีย์ระบุตัวตนระยะยาวของไคลเอนต์ หลังการจับมือของ Noise ชั้นแอปพลิเคชันจะดำเนินการรับรองตัวตนเพิ่มเติม (การลงทะเบียน Signal และการยืนยันหมายเลขโทรศัพท์) การตกลงคีย์ X3DH (Extended Triple Diffie-Hellman) ดำเนินการ DH สี่ครั้งเพื่อสร้างความลับร่วมระหว่างผู้ใช้สองคนผ่านการแลกเปลี่ยนข้อความแบบไม่พร้อมกัน วิธีนี้ไม่ใช่รูปแบบ Noise มาตรฐาน แต่ใช้แนวคิดการผสม DH ที่คล้ายกัน จากนั้น Double Ratchet จะรับช่วงต่อเพื่อเข้ารหัสข้อความอย่างต่อเนื่อง

Noise และ TLS 1.3 แก้ปัญหาเดียวกัน (การแลกเปลี่ยนคีย์ที่มีการรับรองตัวตน) ด้วยแนวคิดที่แตกต่างกัน TLS 1.3 เป็นโพรโทคอลเดียวที่กำหนดชุดการเข้ารหัส รูปแบบใบรับรอง (X.509) และส่วนขยายไว้ตายตัว โดยออกแบบมาสำหรับเว็บเบราว์เซอร์และเซิร์ฟเวอร์—เป็นโพรโทคอลที่ใช้ได้กับกรณีส่วนใหญ่ Noise เป็นกรอบงานที่ไม่ได้กำหนดรูปแบบใบรับรอง ไม่กำหนด PKI และไม่ผูกกับการส่งข้อมูล วิธีนี้ทำให้ Noise มีขนาดเล็กกว่า (การใช้งาน Noise ทั้งหมดของ WireGuard มีขนาดไม่ถึง 400 บรรทัดของโค้ด) และให้เหตุผลเชิงรูปแบบได้ง่ายกว่า แต่แอปพลิเคชันต้องจัดการการระบุตัวตนแยกต่างหาก Noise เหมาะกับระบบปิด (แอปพลิเคชันกับเซิร์ฟเวอร์, VPN) ที่การใช้ PKI เป็นสิ่งเกินจำเป็น ส่วน TLS เหมาะกับระบบเปิด (เว็บ) ที่ต้องการการทำงานร่วมกันของใบรับรอง

รูปแบบ Noise ได้รับการวิเคราะห์อย่างเป็นทางการในแบบจำลองความปลอดภัย eCK (extended Canetti-Krawczyk) Kobeissi, Bhargavan และ Blanchet วิเคราะห์ Noise โดยใช้ Proverif และพบการพิสูจน์การรับรองตัวตนและการรักษาความลับของคีย์สำหรับรูปแบบ Noise พื้นฐานทั้ง 12 รูปแบบ การพิสูจน์เหล่านี้ตั้งอยู่บนสมมติฐานความยากของ DH มาตรฐาน (Curve25519) และความปลอดภัยของฟังก์ชัน AEAD และแฮชพื้นฐาน ลักษณะการประกอบของ Noise (การผสม DH แต่ละรายการอย่างต่อเนื่อง) ทำให้ให้เหตุผลได้ง่ายกว่าโพรโทคอลลักษณะ TLS ที่ซับซ้อน ซึ่งมีการเปลี่ยนสถานะจำนวนมาก การตรวจสอบการเข้ารหัสของ Noise ทำให้ WireGuard และ WhatsApp มีความเชื่อมั่นในความปลอดภัยของโพรโทคอลในระดับสูงก่อนนำไปใช้งาน

ข้อผิดพลาดที่พบบ่อยในการใช้งาน Noise: (1) ความสับสนเกี่ยวกับรูปแบบ—การใช้ Noise_IK เมื่อคีย์คงที่ของผู้ตอบไม่ได้ถูกแจกจ่ายล่วงหน้าอย่างน่าเชื่อถือ จะทำให้ข้อมูลระบุตัวตนไม่ตรงกัน (ผู้เริ่มต้นอาจเข้ารหัสข้อมูลไปยังคีย์ที่ไม่ถูกต้องโดยไม่รู้ตัว) (2) การป้องกันการเล่นซ้ำ—Noise ให้การรับรองตัวตน แต่ไม่ได้ป้องกันการเล่นซ้ำของข้อความในเฟสการส่งข้อมูล ต้องบังคับใช้ nonce (ตัวนับขนาด 64 บิต) และเมื่อค่าตัวนับวนกลับ (หลังส่งข้อความครบ 2^64 ข้อความ) ต้องเปลี่ยนคีย์ใหม่ (3) ความถูกต้องของบทนำโพรโทคอล—บทนำของ Noise (สตริงไบต์ที่ผสมเข้าไปใน h ก่อนเริ่มการจับมือ) ต้องมีบริบททั้งหมดของโพรโทคอล (เวอร์ชัน ตัวเลือกอัลกอริทึม) เพื่อป้องกันการโจมตีแบบลดระดับ (4) การใช้ PSK ในทางที่ผิด—Noise รองรับส่วนขยาย PSK สำหรับผสมคีย์ที่แบ่งปันล่วงหน้า โดย PSK ต้องมีเอนโทรปีสูง ไม่ใช่รหัสผ่านของผู้ใช้

สัญกรณ์รูปแบบ Noise "es" หมายถึงอะไรในรูปแบบการจับมือ

Noise เป็นกรอบงานสำหรับสร้างโพรโทคอลการแลกเปลี่ยนคีย์ที่มีการรับรองตัวตน โดยใช้ภาษารูปแบบของการดำเนินการ DH SymmetricState รักษาคีย์เชื่อมโยง (ck) แฮชของบันทึกการสื่อสาร (h) และคีย์เข้ารหัส (k) ซึ่งปรับปรุงด้วย MixKey/MixHash Noise_XX ให้การรับรองตัวตนซึ่งกันและกันภายใน 1.5 RTT ส่วน Noise_IK (WireGuard) ทำงานเสร็จภายใน 1 RTT เมื่อทราบคีย์ของผู้ตอบล่วงหน้า แฮชการจับมือ h ทำหน้าที่เป็นการผูกช่องทาง Noise ได้รับการตรวจสอบอย่างเป็นทางการสำหรับรูปแบบหลักทั้งหมดผ่าน Proverif และเหมาะกับโพรโทคอลระบบปิด (WireGuard, WhatsApp) มากกว่า TLS เมื่อไม่จำเป็นต้องใช้ PKI การใช้งานที่ถูกต้องต้องมีการป้องกันการเล่นซ้ำ ความถูกต้องของบทนำโพรโทคอล และ PSK ที่มีเอนโทรปีสูง