เบราว์เซอร์เรียกใช้การเข้ารหัสที่แข็งแกร่งได้ แต่โค้ดที่ส่งมายังเบราว์เซอร์ก็ยังต้องเชื่อถือได้เช่นกัน
เบราว์เซอร์สามารถเข้ารหัสจากต้นทางถึงปลายทางภายในเครื่อง รวมถึงการสร้างคีย์ร่วมแบบหลังควอนตัม โดยไม่ต้องติดตั้งแอปส่งข้อความแบบเนทีฟ คำถามที่ยากไม่ใช่ว่าคณิตศาสตร์เหล่านี้ทำงานในแท็บได้หรือไม่ แต่คือแอปพลิเคชันที่ส่งมาถึงผู้ใช้ วิธีจัดการคีย์ และเส้นทางการอัปเดตนั้นสมควรได้รับความไว้วางใจในระดับที่บทสนทนาต้องการหรือไม่
การเข้าถึงผ่านเว็บอาจสะดวกเมื่อไม่สามารถติดตั้งแอปได้ แต่ไม่ได้ทำให้แอปปลอดจากการเซ็นเซอร์ โฮสติ้งที่ถูกเจาะ ส่วนขยายที่เป็นอันตราย หรืออุปกรณ์ที่ถูกเจาะ
องค์ประกอบพื้นฐานด้านการเข้ารหัสของเบราว์เซอร์
WebCrypto เปิดให้ใช้การทำงานระดับล่างสำหรับการเข้ารหัส การอนุมานคีย์ การลงลายมือชื่อ และการจัดการคีย์ การใช้งานทั่วไปมีองค์ประกอบพื้นฐานอย่าง AES-GCM และ ECDH การทำงานเหล่านี้เป็นเพียงส่วนประกอบ ไม่ใช่โพรโทคอลส่งข้อความที่มีการยืนยันความแท้จริงอย่างครบถ้วน
เว็บแอปสามารถเพิ่มการใช้งาน ML-KEM ที่ผ่านการทบทวนแล้วด้วย JavaScript หรือ WebAssembly ในกรณีที่ไม่มี API เนทีฟที่ต้องการ การรองรับของเบราว์เซอร์เปลี่ยนแปลงได้ นักพัฒนาจึงควรทดสอบความสามารถในเวอร์ชันเป้าหมายที่แน่นอน แทนการสมมติว่าทุกเบราว์เซอร์มีอัลกอริทึมเหมือนกัน
ลำดับการทำงานแบบไฮบริดในเชิงแนวคิดมีดังนี้:
- สร้างคีย์ที่เหมาะสมด้วยความสุ่มที่ปลอดภัยทางการเข้ารหัส
- ยืนยันความแท้จริงของข้อมูลคีย์ของคู่สนทนาด้วยกลไกตัวตนของโพรโทคอล
- รับส่วนที่นำมาประกอบเป็นความลับร่วมทั้งแบบดั้งเดิมและแบบหลังควอนตัม
- รวมส่วนเหล่านั้นตามกระบวนการสร้างคีย์ที่กำหนดและบริบทของบทสนทนา
- ใช้คีย์ที่อนุมานได้สำหรับการเข้ารหัสแบบยืนยันความแท้จริง โดยจัดการ nonce และสถานะอย่างถูกต้อง
นี่เป็นโครงร่างเพื่ออธิบาย ไม่ใช่สูตรสำหรับนำไปพัฒนา FIPS 203 กำหนดมาตรฐาน ML-KEM แต่ไม่ได้รับรองแอปพลิเคชันเบราว์เซอร์ใดโดยเฉพาะ หรือกำหนดทุกขั้นตอนของโพรโทคอลแชต
การส่งผ่าน HTTPS เป็นส่วนหนึ่งของแบบจำลองความไว้วางใจ
โดยปกติเซิร์ฟเวอร์จะส่ง JavaScript และ WebAssembly ที่จะประมวลผลข้อความที่ไม่เข้ารหัส แอปพลิเคชันที่ถูกแก้ไขอย่างประสงค์ร้ายสามารถอ่านข้อความก่อนเข้ารหัสหรือหลังถอดรหัสได้ แม้ไลบรารีการเข้ารหัสจะใช้อัลกอริทึมที่เชื่อถือได้ก็ตาม
HTTPS ช่วยยืนยันแหล่งที่มาและปกป้องการส่งจากการแทรกแซงทางเครือข่าย แต่ไม่ได้พิสูจน์ว่าผู้ดำเนินการต้นทาง ระบบนำขึ้นใช้งาน หรือส่วนประกอบที่พึ่งพาไม่ถูกเจาะ หน้าเว็บ HTTPS ทั่วไปไม่ได้กลายเป็นแพ็กเกจแอปพลิเคชันที่ลงลายมือชื่ออย่างอิสระโดยอัตโนมัติ
ข้อพิจารณาด้านความปลอดภัยของ WebCrypto จาก W3C กล่าวถึงการแทรกสคริปต์และความจำเป็นในการปกป้องความครบถ้วนสมบูรณ์ของแอปพลิเคชัน Content Security Policy การจัดการส่วนประกอบที่พึ่งพาอย่างรอบคอบ และมาตรการความปลอดภัยเว็บอื่น ๆ ช่วยลดความเสี่ยง แต่ไม่มีมาตรการใดทำให้สคริปต์ใด ๆ จากต้นทางเดียวกันกลายเป็นผู้สังเกตที่ไม่ถูกไว้วางใจและไม่สามารถแตะข้อมูลของแอปได้
WebAssembly อยู่ภายในขอบเขตความปลอดภัยเดียวกับแอปเช่นกัน แซนด์บ็อกซ์จำกัดการเข้าถึงโฮสต์ผ่านอินเทอร์เฟซที่กำหนดไว้ แต่ไม่ได้ทำให้หน้าที่เรียกใช้น่าเชื่อถือ การคอมไพล์ C เป็น Wasm ไม่ได้ทำให้ภาษาต้นทางมีความปลอดภัยด้านหน่วยความจำ
คีย์ไม่จำเป็นต้องอยู่เฉพาะใน RAM
โปรแกรมส่งข้อความในเบราว์เซอร์อาจเก็บคีย์หรือสถานะที่เข้ารหัสไว้อย่างถาวร เพื่อให้ผู้ใช้กลับมาใช้ตัวตนเดิมได้ และอาจมีการเชื่อมโยงอุปกรณ์หรือการกู้คืนที่เข้ารหัส พฤติกรรมเหล่านี้ต้องมีเอกสารอธิบาย ไม่ใช่สมมติว่าไม่มีอยู่
คำถามที่ควรถาม ได้แก่:
- คีย์ใดถูกเก็บอย่างถาวร และอยู่ในพื้นที่จัดเก็บใดของเบราว์เซอร์?
- จะเกิดอะไรขึ้นเมื่อล้างข้อมูลเว็บไซต์หรือสิ้นสุดเซสชันการท่องเว็บแบบส่วนตัว?
- โค้ดอันตรายที่ทำงานในบริบทของแอปยังใช้คีย์ที่ไม่สามารถดึงออกมาได้หรือไม่?
- การอัปเดตที่เพิ่งส่งมาสามารถเข้าถึงสถานะเก่าในเครื่องได้หรือไม่?
- การกู้คืนเรียกคืนตัวตน ประวัติข้อความ หรือทั้งสองอย่าง?
คีย์ WebCrypto ที่ไม่สามารถดึงออกมาได้จำกัดการส่งออกผ่าน API แต่ตัวมันเองไม่ได้ป้องกันโค้ดแอปที่เป็นอันตรายจากการร้องขอการทำงานที่ได้รับอนุญาตหรือเก็บรวบรวมข้อความที่ไม่เข้ารหัส
ไคลเอนต์เว็บและเนทีฟมีข้อแลกเปลี่ยนต่างกัน
| ประเด็น | ไคลเอนต์เบราว์เซอร์ | ไคลเอนต์เนทีฟ |
|---|---|---|
| การเผยแพร่ | ต้นทาง โฮสติ้ง และกระบวนการอัปเดตเว็บ | ร้านแอปหรือกระบวนการแจกจ่ายและลงลายมือชื่อแพ็กเกจ |
| การเก็บข้อมูลถาวรในเครื่อง | ที่เก็บข้อมูลของเบราว์เซอร์และพฤติกรรมโปรไฟล์ | ที่เก็บข้อมูลแอปของระบบปฏิบัติการและวงจรชีวิตแอป |
| พื้นที่เสี่ยง | สคริปต์จากต้นทางเดียวกัน ส่วนขยาย และช่องโหว่เบราว์เซอร์ | ส่วนประกอบที่แอปพึ่งพาและช่องโหว่ของระบบปฏิบัติการหรือแอป |
| ความพร้อมใช้งาน | โดเมนที่เข้าถึงได้และบริการเครือข่ายที่จำเป็น | แอปที่ติดตั้งแล้วยังต้องใช้บริการเครือข่ายที่จำเป็นของตน |
ไม่มีคอลัมน์ใดตัดสินผู้ชนะได้โดยไม่ตรวจสอบการนำไปใช้งาน เว็บแอปอาจยังเข้าถึงได้หลังถูกถอดจากร้านแอป แต่โดเมนที่ถูกบล็อกหรือเส้นทางเครือข่ายที่ขาดหายก็ยังทำให้เข้าใช้งานไม่ได้
วัดประสิทธิภาพแทนการให้คำมั่น
ตาม FIPS 203 นั้น ML-KEM-768 ใช้คีย์สำหรับการห่อหุ้มขนาด 1,184 ไบต์ และข้อความเข้ารหัสขนาด 1,088 ไบต์ ขนาดเหล่านี้ช่วยอธิบายว่าเหตุใดโพรโทคอลจึงอาจกำหนดจังหวะอัปเดต KEM แทนการแนบข้อมูลใหม่ไปกับทุกข้อความสั้น ๆ แต่ไม่ใช่ค่าที่วัดแบนด์วิดท์หรือความเร็วของทั้งแอปพลิเคชัน
การทดสอบสมรรถนะที่มีประโยชน์ต้องระบุเบราว์เซอร์ อุปกรณ์ บิลด์ วิธีวอร์มอัป การทำงานที่วัด และการกระจายของเวลา ควรรวมการเริ่มต้นหน้า การโหลดโมดูล การใช้หน่วยความจำ อุปกรณ์ระดับล่าง และภาระเพิ่มเติมของเครือข่ายด้วย คำกล่าวอย่าง “ต่ำกว่าสองมิลลิวินาทีในโทรศัพท์สมัยใหม่ทุกเครื่อง” ต้องมีผลการวัดที่เผยแพร่รองรับ บทความนี้ไม่ได้ให้ผลการวัดดังกล่าว
เมื่อนำมาใช้กับ Livara
ภาพรวมความปลอดภัย ของ Livara อธิบาย LVR1 และขอบเขตการกู้คืน ส่วน Proof Lab สาธิตการทำงานภายในเครื่องบางส่วนของ P-256, HKDF และ AES-GCM โดยหน้านั้นระบุชัดว่าการประกอบ LVR1/LGS1 อย่างครบถ้วนอยู่นอกขอบเขตการทดสอบ ดังนั้นการสาธิตที่ผ่านจึงไม่ได้พิสูจน์ความปลอดภัยของโค้ดเว็บที่ส่งมอบทั้งหมด
ก่อนสนทนาเรื่องอ่อนไหวในเบราว์เซอร์ ให้ใช้ไคลเอนต์ของแท้ที่ยังได้รับการดูแล อ่านแบบจำลองภัยคุกคาม ปัจจุบัน ปกป้องโปรไฟล์เบราว์เซอร์ และตรวจสอบคู่สนทนาผ่านกระบวนการตรวจคีย์ที่รองรับ ความสะดวกและการเข้ารหัสที่มีประโยชน์อยู่ร่วมกันได้ ตราบใดที่ขอบเขตการส่งมอบผ่านเว็บยังเป็นส่วนหนึ่งของการประเมิน
