คำถามด้านความปลอดภัยที่มีประโยชน์ไม่ใช่ว่าการเข้ารหัสฟังดูแข็งแกร่งเพียงใด แต่คือปกป้องอะไร ใครถือกุญแจ และมีหลักฐานใดรองรับคำกล่าวอ้าง
คำว่า “การเข้ารหัสระดับทหาร” ให้ข้อมูลไม่เพียงพอสำหรับการประเมินแอปส่งข้อความ คำนี้ไม่ได้บอกว่าใครถือกุญแจ บทสนทนาใดได้รับการปกป้อง ข้อมูลสำรองเปิดเผยข้อความที่ไม่ได้เข้ารหัสหรือไม่ หรือจะเกิดอะไรขึ้นเมื่ออุปกรณ์ถูกเจาะระบบ
วิธีรับมือที่มีประโยชน์ไม่ใช่การมองข้ามการเข้ารหัส แต่คือการแทนที่คำเรียกที่ดูน่าประทับใจด้วย คำกล่าวอ้างที่เฉพาะเจาะจงและตรวจสอบได้
AES-256 เป็นการเลือกอัลกอริทึม ไม่ใช่แบบจำลองความปลอดภัยที่ครบถ้วน
AES เป็นมาตรฐานสาธารณะ ไม่ใช่เทคโนโลยีลับทางทหาร FIPS 197 ของ NIST ระบุ AES-128, AES-192 และ AES-256 โดยตัวเลขท้ายชื่อบอกความยาวกุญแจ มาตรฐานนี้ได้รับการปรับปรุงด้านการเรียบเรียงในปี 2023 โดยไม่ได้เปลี่ยนอัลกอริทึม
อัลกอริทึมเข้ารหัสที่แข็งแกร่งยังอาจถูกใช้ในระบบที่เปิดให้ผู้ให้บริการเข้าถึงข้อความที่ไม่ได้เข้ารหัสได้ ถามว่าใครสามารถถอดรหัส ไม่ใช่ถามเพียงว่ากุญแจยาวเท่าใด และควรถามด้วยว่ากุญแจถูกสร้างและจัดเก็บอย่างไร ยืนยันตัวตนอย่างไร และเงื่อนไขความผิดพลาดแบบใดจะทำให้แอปหยุด แทนที่จะทำงานต่ออย่างไม่ปลอดภัย
เมื่อผู้ขายระบุ AES-GCM นั่นเฉพาะเจาะจงกว่าการระบุเพียง AES เพราะ GCM ผสานการเข้ารหัสกับการตรวจสอบความถูกต้องแท้จริงของข้อมูล แต่การจัดการ nonce อย่างถูกต้อง การตรวจสอบแท็ก และข้อกำหนดด้านการนำไปใช้อื่น ๆ ยังสำคัญ ข้อกำหนด GCM ของ NIST คือเอกสารอ้างอิงทางเทคนิค ส่วนโลโก้ไม่ใช่หลักฐานว่าแอปนำไปใช้อย่างถูกต้อง
คำกล่าวอ้างสี่ประเภทที่การตลาดมักนำมารวมกัน
| คำกล่าวอ้าง | สิ่งที่ครอบคลุม | สิ่งที่ไม่ได้พิสูจน์ |
|---|---|---|
| การเข้ารหัสระหว่างส่ง | การปกป้องข้อมูลบนการเชื่อมต่อ เช่น จากแอปถึงเซิร์ฟเวอร์ | เซิร์ฟเวอร์ไม่สามารถอ่านเนื้อหาได้ |
| การเข้ารหัสข้อมูลที่จัดเก็บ | การปกป้องข้อมูลที่จัดเก็บภายใต้แบบจำลองกุญแจและการเข้าถึงที่กำหนด | ผู้ดำเนินการไม่มีกุญแจถอดรหัส |
| การเข้ารหัสจากต้นทางถึงปลายทาง | การปกป้องเนื้อหาระหว่างจุดปลายทางที่กำหนด | ความปลอดภัยของจุดปลายทางที่ถูกเจาะ หรือความซื่อสัตย์ของผู้รับ |
| การสร้างกุญแจที่ทนต่อภัยคุกคามหลังยุคควอนตัม | ความต้านทานต่อภัยคุกคามควอนตัมที่ระบุในการสร้างกุญแจ | การตรวจสอบแอปทั้งหมด การไม่เปิดเผยตัวตน หรือการรับประกันความปลอดภัยในอนาคต |
การเข้ารหัสระหว่างส่ง ไม่ได้ หมายความว่าฐานข้อมูลของผู้ให้บริการทุกรายเก็บข้อความที่ไม่ได้เข้ารหัสแบบดิบ ๆ บริการอาจเข้ารหัสข้อมูลที่จัดเก็บด้วย ความแตกต่างที่สำคัญคือผู้ให้บริการควบคุมกุญแจหรือสามารถเข้าถึงเนื้อหาที่อ่านได้ด้วยวิธีอื่นหรือไม่ ควรอธิบายอย่างแม่นยำ แทนที่จะใช้คำโฆษณาหนึ่งแทนอีกคำหนึ่ง
หากต้องการคำอธิบายเบื้องต้นที่กว้างขึ้น โปรดดูบทความเรื่องสิ่งที่การเข้ารหัสจากต้นทางถึงปลายทางปกป้อง
“ใช้มาตรฐาน NIST” ไม่เท่ากับ “ผ่านการตรวจรับรอง FIPS”
FIPS 203 กำหนด ML-KEM ซึ่งเป็นกลไกห่อหุ้มกุญแจ แอปส่งข้อความอาจระบุว่าใช้อัลกอริทึมนี้ โดยไม่ได้หมายความว่าแอปทั้งตัวได้รับการรับรองหรือผ่านการทบทวนอย่างเป็นอิสระ มาตรฐาน การทดสอบอัลกอริทึม การตรวจรับรองโมดูลเข้ารหัส และการตรวจสอบความปลอดภัยของผลิตภัณฑ์ เป็นหลักฐานคนละประเภทกัน
โครงการตรวจรับรองโมดูลเข้ารหัสของ NIST ระบุชัดเจนว่าการนำฟังก์ชันที่ได้รับอนุมัติมาใช้ยังไม่เพียงพอที่จะยืนยันว่าโมดูลผ่านการตรวจรับรอง FIPS 140 หากผลิตภัณฑ์โฆษณาว่าผ่านการตรวจรับรอง ให้ขอใบรับรอง โมดูลและเวอร์ชันที่แน่นอน สภาพแวดล้อมการทำงาน และการกำหนดค่าที่ได้รับอนุมัติ จากนั้นตรวจว่าใบรับรองนั้นครอบคลุมส่วนใดของผลิตภัณฑ์จริง ๆ
นี่เป็นอีกเหตุผลที่ไม่ควรใช้ “ความปลอดภัย 256 บิต” เป็นคะแนนรวมของแอปส่งข้อความทั้งตัว การประกอบโปรโตคอล การจัดการกุญแจ และการนำไปใช้อาจมีข้อจำกัดต่างกัน
การยืนยันตัวตนด้วยรหัสผ่านไม่ใช่การเข้ารหัสข้อความ
กลไกเข้าสู่ระบบตอบว่าผู้ใช้สามารถเข้าถึงบัญชีได้หรือไม่ ส่วน E2EE ตอบว่าใครสามารถอ่านเนื้อหาข้อความที่ได้รับการปกป้อง ทั้งสองอย่างไม่ได้ให้คุณสมบัติของอีกฝ่ายโดยอัตโนมัติ
ตัวอย่างเช่น SRP ถูกออกแบบมาให้ยืนยันตัวตนโดยไม่ส่งรหัสผ่านจริง แต่ไม่ได้หมายความว่าการขโมยฐานข้อมูลยืนยันตัวตนจะไม่มีอันตราย คำอธิบายด้านความปลอดภัยของ SRP ใน RFC 5054 อธิบายว่าค่าตรวจสอบที่ถูกขโมยเปิดทางให้โจมตีด้วยการเดารหัสผ่านและก่อความเสี่ยงอื่น ๆ อย่าสรุปว่า “ไม่มีรหัสผ่านให้ขโมย ดังนั้นการเจาะเซิร์ฟเวอร์จึงไม่มีผลสำคัญ”
สำหรับผู้อ่าน สิ่งที่ควรถามต่อในทางปฏิบัติคือการกู้คืนบัญชี เซสชันที่ยังใช้งานอยู่ และความสัมพันธ์ระหว่างการเข้าถึงบัญชีกับกุญแจเข้ารหัส คำตอบที่เพียงย้ำว่า “ความรู้เป็นศูนย์” ยังไม่คลี่คลายคำถามสำคัญเหล่านี้
คำถามห้าข้อสำหรับประเมินหน้าความปลอดภัยของแอปส่งข้อความ
- ครอบคลุมส่วนใดบ้าง? แชตส่วนตัว กลุ่ม ไฟล์ การโทร โพสต์สาธารณะ และข้อมูลสำรอง อาจมีขอบเขตต่างกัน
- ใครถือกุญแจที่นำไปใช้ได้? รวมถึงกุญแจกู้คืน อุปกรณ์ที่เชื่อมโยง และโหมดประมวลผลฝั่งเซิร์ฟเวอร์
- ยืนยันตัวตนของจุดปลายทางอีกฝ่ายอย่างไร? มองหาการตรวจสอบกุญแจ คำเตือนการเปลี่ยนแปลงที่มีความหมาย และแบบจำลองความไว้วางใจที่มีเอกสารอธิบาย
- มีหลักฐานอะไรบ้าง? ข้อกำหนด บิลด์ที่สร้างซ้ำได้ เวกเตอร์ทดสอบ และการตรวจสอบอิสระ ตอบคำถามคนละแบบ ถามถึงเวอร์ชันและขอบเขตของแต่ละอย่าง
- อะไรยังมองเห็นได้หรือเสี่ยงต่อการโจมตี? เมทาดาทา อุปกรณ์ที่ถูกเจาะ ข้อความที่ถูกคัดลอก และเนื้อหาสาธารณะ ไม่ควรถูกละออกจากคำอธิบาย
ใช้เกณฑ์เดียวกันกับ Livara ด้วย เอกสารความปลอดภัย ระบุ LVR1 และ LGS1 พร้อมเผยแพร่ขอบเขตการทำงาน ให้มองสิ่งเหล่านี้เป็นคำกล่าวอ้างของผลิตภัณฑ์ที่ต้องประเมิน ไม่ใช่การรับรองอิสระ ส่วน Proof Lab เสนอการสาธิตและการตรวจสอบไฟล์ผลลัพธ์ในขอบเขตจำกัด ไม่ใช่หลักฐานว่าทุกฟีเจอร์หรือทุกรุ่นปลอดภัย
วิธีอ่านรายงานการตรวจสอบอิสระ
ตรวจวันที่ ผู้ตรวจสอบ รีวิชันของโค้ด แพลตฟอร์มที่รวมอยู่ และองค์ประกอบที่ไม่อยู่ในขอบเขต อ่านข้อค้นพบและสถานะการแก้ไข ไม่ใช่ดูเพียงตราสรุป การตรวจสอบไลบรารีเข้ารหัสไม่ได้ครอบคลุมการกู้คืนบัญชี เว็บแอป การแจ้งเตือน หรือความปลอดภัยในการปฏิบัติงานโดยอัตโนมัติ
การไม่มีรายงานตรวจสอบคือช่องว่างของหลักประกัน ไม่ใช่หลักฐานของช่องโหว่ใดโดยเฉพาะ ในทางกลับกัน การตรวจสอบก็ไม่ใช่การรับประกันตลอดชีวิต การเปรียบเทียบที่มีประโยชน์ควรบันทึกหลักฐานและข้อจำกัด แทนที่จะประกาศผู้ชนะว่า “ปลอดภัยที่สุด” ในทุกกรณี
คำถามที่พบบ่อย
“ระดับทหาร” เป็นอีกชื่อหนึ่งของ AES-256 เสมอหรือไม่?
ไม่ใช่ อย่าอนุมานอัลกอริทึมหรือการรับรองที่เฉพาะเจาะจงจากคำนี้ ขอให้ผู้ขายระบุให้แน่ชัดว่าหมายถึงอะไร
การเข้ารหัสที่แข็งแกร่งขึ้นหยุดการจับภาพหน้าจอหรือมัลแวร์ได้หรือไม่?
ไม่สามารถหยุดผู้รับจากการคัดลอกเนื้อหา หรือหยุดอุปกรณ์ที่ถูกเจาะจากการเปิดเผยข้อมูลที่มันเข้าถึงได้ สิ่งเหล่านี้เป็นภัยคุกคามคนละประเภท
อะไรเป็นสัญญาณที่ดีกว่าคำโฆษณาด้านความปลอดภัย?
ขอบเขตที่ชัดเจน โปรโตคอลที่ระบุชื่อ ข้อจำกัดที่อธิบายตรงไปตรงมา และหลักฐานที่ตรวจสอบได้เกี่ยวกับการนำไปใช้ในรุ่นที่แจกจ่ายจริง คำอธิบายควรช่วยให้คุณตัดสินใจได้ว่าจะเชื่อถืออะไร และอะไรยังต้องตรวจสอบต่อ
