การปฏิเสธที่น่าเชื่อได้ในแอป: คืออะไรและทำไมจึงสำคัญ

การปฏิเสธที่น่าเชื่อได้หมายความว่าพิสูจน์ไม่ได้ว่าข้อมูลที่ซ่อนไว้มีอยู่

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

คู่มือนี้อธิบายว่าการปฏิเสธที่น่าเชื่อได้ทำงานอย่างไรในแอป ความต่างระหว่างการปฏิเสธได้ทางวิทยาการเข้ารหัสอย่างแท้จริงกับโหมดล่อที่มีแค่ภายนอก สถานการณ์จริงที่เรื่องนี้สำคัญ และวิธีประเมินคำอ้างเรื่องการปฏิเสธได้

การปฏิเสธที่น่าเชื่อได้ในการเข้ารหัสหมายถึงอะไร

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

แนวคิดนี้เริ่มจากการเข้ารหัสดิสก์ TrueCrypt (และ VeraCrypt ผู้สืบทอด) บุกเบิกไดรฟ์ข้อมูลที่ซ่อนอยู่ คือไดรฟ์ข้อมูลเข้ารหัสที่อยู่ภายในไดรฟ์ข้อมูลเข้ารหัสอีกอัน รหัสผ่านหนึ่งเปิดไดรฟ์ข้อมูลชั้นนอกที่มีไฟล์ธรรมดา อีกรหัสผ่านเปิดไดรฟ์ข้อมูลชั้นในที่ซ่อนอยู่ซึ่งมีไฟล์อ่อนไหว ผู้ตรวจทางนิติวิทยาศาสตร์บอกไม่ได้ว่ามีไดรฟ์ข้อมูลที่ซ่อนอยู่หรือไม่ เพราะพื้นที่ว่างในไดรฟ์ข้อมูลชั้นนอกเต็มไปด้วยข้อมูลสุ่มที่แยกไม่ออกจากข้อมูลเข้ารหัส

สำหรับแอป การปฏิเสธที่น่าเชื่อได้หมายความว่าข้อมูลรับรองที่ต่างกัน (รหัสผ่าน PIN รูปแบบ) เปิดชุดข้อมูลที่ต่างกัน และไม่มีข้อมูลเมตา รีจิสทรี แฟล็กการกำหนดค่า หรือร่องรอยเชิงโครงสร้างใดที่เผยว่ามีชุดข้อมูลเพิ่มเติม

การปฏิเสธได้อย่างแท้จริงเทียบกับโหมดล่อที่มีแค่ภายนอก

นี่คือความต่างสำคัญที่แอปส่วนใหญ่ทำผิด

โหมดล่อที่มีแค่ภายนอก (ไม่ใช่การปฏิเสธได้จริง)

แอปห้องนิรภัยจำนวนมากมีฟีเจอร์ "ล่อ" หรือ "PIN ปลอม" คุณตั้ง PIN สำรองที่เปิดพื้นที่แยกซึ่งมีรูปภาพต่างกัน ปัญหาคือแอปเหล่านี้มักเก็บแฟล็กบูลีน รายการในฐานข้อมูล หรือไฟล์การกำหนดค่าที่ระบุว่ามีโหมดล่อและตั้งค่าไว้แล้ว

ผู้ตรวจทางนิติวิทยาศาสตร์ที่เข้าใจแอปจะหาแฟล็กนี้เจอ การพบโหมดล่อที่ตั้งค่าไว้พิสูจน์ว่ามีข้อมูลที่ซ่อนอยู่ การปฏิเสธได้นี้จึงมีแค่ภายนอก ใช้ได้กับคนแอบดูทั่วไปแต่ล้มเหลวเมื่อเจอการตรวจทางนิติวิทยาศาสตร์

สัญญาณของการปฏิเสธได้ที่มีแค่ภายนอก:

• แอปมีสวิตช์ "โหมดล่อ" ในการตั้งค่า
• ไฟล์การกำหนดค่าเก็บว่าเปิดโหมดล่อไว้หรือไม่
• ตารางในฐานข้อมูลแสดง ID ของห้องนิรภัยพร้อมตัวระบุประเภท (หลัก/ล่อ)
• โครงสร้างการจัดเก็บของแอปเปลี่ยนเมื่อเปิดโหมดล่อ
• การลบแล้วติดตั้งแอปใหม่ให้พฤติกรรมต่างกันเมื่อเคยตั้งค่าโหมดล่อไว้

การปฏิเสธได้ทางวิทยาการเข้ารหัสอย่างแท้จริง

การปฏิเสธได้อย่างแท้จริงเป็นคุณสมบัติทางสถาปัตยกรรม ไม่ใช่สวิตช์ฟีเจอร์ ที่จัดเก็บเข้ารหัสต้องออกแบบให้:

1. ข้อมูลรับรองสำรองเปิดเผยเฉพาะชุดข้อมูลของตัวเอง ระบบไม่เก็บแฟล็กล่อแยกที่ระบุว่าข้อมูลรับรองหนึ่งเป็นตัวพราง ข้อมูลรับรองที่ไม่ถูกต้องล้มเหลวได้ แต่ความล้มเหลวนั้นต้องไม่เผยว่ามีชุดข้อมูลที่ยังไม่เปิดเผยอยู่หรือไม่

2. ไม่มีรีจิสทรีของห้องนิรภัย แอปนับไม่ได้ว่ามีห้องนิรภัยกี่ห้อง ไม่มีจำนวน ไม่มีดัชนี ไม่มีรายการ ID ของห้องนิรภัย ผู้ตรวจทางนิติวิทยาศาสตร์ที่ตรวจที่จัดเก็บของแอปจะพบเพียงกลุ่มข้อมูลเข้ารหัสที่แยกแยะไม่ได้

3. ไม่มีแฟล็กการกำหนดค่าที่เผยห้องนิรภัยที่ซ่อนอยู่ ไม่มีค่าบูลีน รายการในฐานข้อมูล หรือไฟล์การตั้งค่าที่บอกว่ามีห้องนิรภัยเพิ่มเติมหรือไม่

4. ที่จัดเก็บมีการเติมข้อมูล พื้นที่รวมที่ใช้ไม่เปลี่ยนตามจำนวนห้องนิรภัยหรือไฟล์ หากไม่เติมข้อมูล ผู้ตรวจอาจประเมินจำนวนห้องนิรภัยได้จากขนาดข้อมูลเข้ารหัสทั้งหมดเทียบกับเนื้อหาที่มองเห็น

5. ข้อมูลเข้ารหัสแยกไม่ออกจากสัญญาณสุ่ม ไม่มีขอบเขตไฟล์ ไม่มีส่วนหัว ไม่มีเครื่องหมายเชิงโครงสร้างที่บอกว่าข้อมูลของห้องนิรภัยหนึ่งสิ้นสุดและอีกห้องเริ่มต้นตรงไหน

สถานการณ์จริงที่เรื่องนี้สำคัญ

การปฏิเสธที่น่าเชื่อได้ไม่ใช่ข้อกังวลทางทฤษฎี มันตอบสถานการณ์จริงที่มีบันทึกไว้และเกิดซ้ำ

การข้ามพรมแดน

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

ความรุนแรงในครอบครัวและความสัมพันธ์ที่มีการบังคับ

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

อุปกรณ์ถูกขโมย

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

การคุ้มครองทางกฎหมายและงานข่าว

นักข่าวที่ปกป้องแหล่งข่าว ทนายความที่ปกป้องไฟล์ของลูกความ และนักเคลื่อนไหวในประเทศเผด็จการ เผชิญสถานการณ์ที่อาจถูกบังคับให้เปิดเนื้อหาในอุปกรณ์ การปฏิเสธได้อย่างแท้จริงเป็นการป้องกันที่น่าเชื่อถือต่อการยึดข้อมูล

สิ่งที่ Vaultaire ทำได้ในปัจจุบัน

Vaultaire ใช้การเข้าถึงที่แยกด้วยรูปแบบ และอินเทอร์เฟซปกติที่ไม่แสดงรายการห้องนิรภัย คุณสมบัติเหล่านี้ช่วยระหว่างการใช้แอปตามปกติ แต่ไม่ได้ตรงตามข้อกำหนดทุกข้อในรายการตรวจการปฏิเสธได้อย่างแท้จริงด้านบน

รูปแบบที่ตั้งค่าไว้เปิดห้องนิรภัยเข้ารหัสที่แยกกัน PBKDF2 สร้างคีย์ห้องนิรภัยจากรูปแบบและ salt ระดับอุปกรณ์ คีย์ที่ตั้งค่าไว้ยืนยันความถูกต้องของดัชนีที่เข้ารหัสและปลดการห่อมาสเตอร์คีย์แบบสุ่ม รูปแบบที่ยังไม่ได้ตั้งค่าจะแสดงสถานะว่าง แทนข้อความ "รูปแบบไม่ถูกต้อง"

รูปแบบการจัดเก็บในเครื่องนับได้ Vaultaire เก็บไฟล์ vault_index_<fingerprint>.bin หนึ่งไฟล์ต่อห้องนิรภัย ลายนิ้วมือนี้ไม่เผยรูปแบบหรือชื่อห้องนิรภัย แต่คนที่เข้าถึงคอนเทนเนอร์ของแอปนับไฟล์ดัชนีได้ การยืนยันความถูกต้องของ AES-GCM และชื่อไฟล์ที่กำหนดแน่นอนยังเปิดทางให้ทดสอบคีย์ห้องนิรภัยที่คาดเดาแบบออฟไลน์ได้ด้วย

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

มีสถานะการกู้คืนและสถานะห้องนิรภัยลวง Vaultaire เก็บข้อมูลการกู้คืนไว้ในฐานข้อมูล Keychain ที่เข้ารหัสด้วย AES-GCM โหมดห้องนิรภัยลวงลบดัชนีในเครื่องและการจับคู่การกู้คืนของห้องนิรภัยที่ไม่ใช่ห้องลวง และตัดอุปกรณ์นั้นออกจากการซิงค์ โหมดนี้ไม่ลบข้อมูลสำรองบนคลาวด์ สำเนาบนอุปกรณ์อื่น หรือข้อมูลเข้ารหัสที่แชร์ไว้ทุกชิ้น และเวลาที่ใช้ขึ้นกับงานในเครื่องที่ต้องทำ

ดังนั้น Vaultaire ให้การแบ่งส่วนในระดับอินเทอร์เฟซและที่จัดเก็บเข้ารหัส ไม่ใช่การพิสูจน์ทางทฤษฎีสารสนเทศว่าไม่มีห้องนิรภัยเพิ่มเติม การจะซ่อนจำนวนห้องนิรภัยในเครื่องจากสแนปช็อตคอนเทนเนอร์ของแอปแบบออฟไลน์ ต้องมีแคตตาล็อกความจุคงที่ในอนาคตที่มีช่องจริงและช่องหลอกซึ่งแยกไม่ออกจากกัน

วิธีประเมินคำอ้างเรื่องการปฏิเสธได้

เมื่อแอปอ้างว่ามีการปฏิเสธที่น่าเชื่อได้ ให้ถาม:

1. มีสวิตช์ "โหมดล่อ" หรือไม่ ถ้ามี ก็เป็นแค่ภายนอก ผู้ตรวจทางนิติวิทยาศาสตร์หาสวิตช์นั้นเจอได้
2. แอปมีรายการหรือฐานข้อมูลห้องนิรภัยหรือไม่ ถ้ามี การมีอยู่ของห้องนิรภัยก็พิสูจน์ได้
3. ตรวจการเดาแบบออฟไลน์ได้หรือไม่ ข้อมูลเข้ารหัสแบบยืนยันความถูกต้องใช้ตรวจคีย์ที่คาดเดาได้โดยไม่ต้องมีแฮชรหัสผ่านแยก ถามว่าอะไรจำกัดต้นทุนการเดา และโครงสร้างการจัดเก็บมีลายนิ้วมือคีย์ที่ตรวจได้ง่ายกว่าหรือไม่
4. พื้นที่ที่ใช้เปลี่ยนตามจำนวนห้องนิรภัยหรือไม่ ถ้าเปลี่ยน การวิเคราะห์ดิสก์ประเมินจำนวนห้องนิรภัยได้
5. แอปนับห้องนิรภัยได้หรือไม่ ถ้าแอปแสดงรายการห้องนิรภัยของคุณได้ รายการนั้นมีอยู่บนอุปกรณ์และค้นพบได้

คำถามที่พบบ่อย

การปฏิเสธที่น่าเชื่อได้ถูกกฎหมายหรือไม่

การใช้การเข้ารหัสที่มีการปฏิเสธที่น่าเชื่อได้ถูกกฎหมายในประเทศประชาธิปไตยส่วนใหญ่ ไม่มีกฎหมายห้ามการมีข้อมูลเข้ารหัสบนอุปกรณ์ที่พิสูจน์ไม่ได้ว่ามีอยู่ ในบางเขตอำนาจศาล (สหราชอาณาจักรภายใต้ RIPA และออสเตรเลียภายใต้ Assistance and Access Act) เจ้าหน้าที่บังคับให้เปิดเผยคีย์เข้ารหัสได้ คำถามทางกฎหมายคือการบังคับให้เปิดเผยคีย์ของข้อมูลที่พิสูจน์ไม่ได้ว่ามีอยู่บังคับใช้ได้จริงหรือไม่ ประเด็นนี้ยังเป็นกฎหมายที่กำลังพัฒนา

เครื่องมือนิติวิทยาศาสตร์ตรวจพบการปฏิเสธที่น่าเชื่อได้ได้หรือไม่

ผู้ตรวจที่ได้คอนเทนเนอร์ของแอป Vaultaire ไปจะตรวจพบที่จัดเก็บเข้ารหัสและนับไดเรกทอรีจัดเก็บรายห้องนิรภัยได้ ไฟล์ราก vault_index_*.bin อยู่ในกลุ่ม 64 ไฟล์ที่มีไฟล์พราง แต่ไดเรกทอรีบอกได้ว่าไฟล์ใดเป็นของจริง ไฟล์เหล่านี้ไม่เปิดเผยชื่อห้องนิรภัยหรือเนื้อหาแบบข้อความธรรมดา แต่จำนวนของไฟล์เผยจำนวนดัชนีเข้ารหัสในเครื่อง การออกแบบปัจจุบันจึงซ่อนห้องนิรภัยจากการใช้งานปกติ ไม่ใช่จากการตรวจที่จัดเก็บทางนิติวิทยาศาสตร์ทุกแบบ

การปฏิเสธที่น่าเชื่อได้ใช้ได้กับรัฐที่มุ่งมั่นหรือไม่

AES-256-GCM ให้ขอบเขตการเข้ารหัสเนื้อหาที่แข็งแรงเมื่อคีย์ nonce และการนำไปใช้ถูกต้อง แต่นั่นไม่ได้ทำให้โครงสร้างการจัดเก็บปัจจุบันของ Vaultaire ปฏิเสธได้ต่อผู้ตรวจระดับรัฐ จำนวนดัชนีในเครื่องยังมองเห็นได้ และการเจาะขณะใช้งานอาจมุ่งไปที่รูปแบบ คีย์ ภาพพรีวิว หรือไฟล์ที่ส่งออกขณะห้องนิรภัยเปิดอยู่ ฟีเจอร์ปัจจุบันแยกสิ่งที่รูปแบบต่าง ๆ เปิดในอินเทอร์เฟซ ไม่ได้สัญญาว่าผู้ตรวจที่มุ่งมั่นจะพิสูจน์ไม่ได้ว่ามีดัชนีในเครื่องเพิ่มเติม

การปฏิเสธที่น่าเชื่อได้ต่างจากห้องนิรภัยที่ซ่อนอยู่อย่างไร

ห้องนิรภัยที่ซ่อนอยู่คือห้องนิรภัยที่ไม่ปรากฏในอินเทอร์เฟซปกติของแอป การปฏิเสธได้ทางวิทยาการเข้ารหัสที่แข็งแรงเป็นอีกคุณสมบัติหนึ่ง คือข้อมูลที่ซ่อนไว้แยกไม่ออกจากที่จัดเก็บว่างที่เติมข้อมูลไว้ ปัจจุบัน Vaultaire ให้คุณสมบัติแรก รูปแบบไฟล์ดัชนีหนึ่งไฟล์ต่อห้องนิรภัยไม่ได้ให้คุณสมบัติที่สองต่อผู้ตรวจที่เข้าถึงคอนเทนเนอร์ของแอปได้

ใช้การปฏิเสธที่น่าเชื่อได้กับข้อมูลสำรองบนคลาวด์ได้หรือไม่

Vaultaire เขียนแมนิเฟสต์ข้อมูลสำรองที่เข้ารหัสและชิ้นไฟล์เข้ารหัสที่เติมข้อมูลแล้วไปยังฐานข้อมูล CloudKit ส่วนตัวของผู้ใช้ ชื่อระเบียนแบบสุ่ม ประเภทระเบียนแบบเดียวกัน การเติมชิ้นข้อมูลเป็น 10 MB และระเบียนล่อช่วยลดการเปิดเผยเนื้อหาโดยตรง จำนวนระเบียน ปริมาณรวม ช่วงเวลา และรูปแบบการอัปเดตยังเป็นข้อมูลเมตาของบริการที่มองเห็นได้ ข้อมูลสำรองบนคลาวด์จึงไม่ได้สร้างที่จัดเก็บขนาดคงที่ที่ปฏิเสธได้ทางทฤษฎีสารสนเทศ

สรุป

การปฏิเสธได้ในระดับการจัดเก็บที่แข็งแรงมุ่งกันไม่ให้ผู้ตรวจแยกข้อมูลที่ซ่อนไว้ออกจากพื้นที่ว่างที่เติมข้อมูลไว้ในที่จัดเก็บเข้ารหัสแบบคงที่ แอปส่วนใหญ่ที่อ้างฟีเจอร์นี้มีเพียงโหมดล่อแค่ภายนอกที่มีแฟล็กการกำหนดค่าซึ่งค้นพบได้ การทำตามนิยามที่เข้มกว่าต้องมีโมเดลภัยคุกคามที่ชัดเจน ไม่มีรีจิสทรีของห้องนิรภัยที่นับได้ ไม่มีแฟล็กการกำหนดค่าที่เผยข้อมูล มีการเติมข้อมูลที่คงที่ และมีระเบียนเข้ารหัสที่ไม่เผยว่าช่องใดเป็นของจริง

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