คู่มือ Threat Model แบบไม่เป็นทางการของ Soatok

 (soatok.blog)
2 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Threat model ไม่ได้จบแค่การเขียนว่าต้องปกป้องอะไรและผู้โจมตีคือใคร แต่จะนำไปใช้ตัดสินใจด้านการออกแบบได้เมื่อเผยให้เห็นความสัมพันธ์ระหว่างทรัพย์สิน สมมติฐาน และภัยคุกคามที่ตั้งใจไม่นำมาพิจารณาด้วย
  • โมเดลที่ดีมองทรัพย์สินไม่ใช่เป็นรายการ แต่เป็น กราฟ และตรวจสอบความเสี่ยงกับสมมติฐานด้วยการค่อย ๆ จำกัดขอบเขต input, output และ dependency ของคอมโพเนนต์
  • เมื่อสมมติฐานพัง ความเสี่ยงที่เคยยอมรับไว้ก็ต้องนำกลับมาพิจารณาใหม่ และการโจมตี Invisible Salamanders จะกลายเป็นปัญหาเมื่อฟีเจอร์รายงานการใช้งานในทางที่ผิดของ E2EE ขัดแย้งกับสมมติฐานของ AEAD ที่ว่า “มีคีย์ที่ถูกต้อง 1 คีย์ต่อข้อความหนึ่งข้อความ”
  • กรณีของ publickey.directory แยกดูสมมติฐาน ทรัพย์สิน ผู้มีบทบาท และสถานะความเสี่ยง แต่ก็ไม่ได้สมบูรณ์แบบ ส่วน threat model ของ Matrix v1.18 ใกล้เคียงกับรายการประเภทการโจมตี และขาดเรื่องการเข้ารหัสกับการจัดการคีย์
  • การทำ threat modeling ช่วยให้ตัดสินใจออกแบบได้ดีขึ้น โดยแยกข้อจำกัดของตัวเลือกทางเทคนิคออกจากความเสี่ยงจริง เช่น การยืนยันตัวตนด้วย passkey, การออกแบบ E2EE แบบกระจายศูนย์ และข้อถกเถียงเรื่อง PQC

คำถามที่ threat model ต้องตอบ

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

ปัญหาที่เกิดขึ้นเมื่อสมมติฐานพัง

  • การโจมตี Invisible Salamanders อาจทำลายฟีเจอร์รายงานการใช้งานในทางที่ผิดเมื่อมีการนำฟีเจอร์ดังกล่าวมาใช้ในการออกแบบระบบส่งข้อความ E2EE บางแบบ
  • การโจมตีนี้เกี่ยวพันกับสมมติฐานของสกีม AEAD อย่าง AES-GCM และ ChaCha20-Poly1305
    • สกีมเหล่านี้มีสมมติฐานว่า สำหรับข้อความหนึ่ง ๆ จะมีคีย์ที่ถูกต้องเพียงคีย์เดียว
    • หากนำคีย์ที่ถูกต้องหลายคีย์มาใช้กับข้อความเดียว หรือสร้าง confused deputies ก็จะหลุดออกจากการรับประกันด้านความปลอดภัยของอัลกอริทึม
  • การเขียนสมมติฐานให้ชัดเจนช่วยให้ระบุ unknown unknowns ของตนเองได้
  • ไม่จำเป็นต้องสมบูรณ์แบบ แต่ต้องชัดเจนว่ากำลังยึดอะไรเป็นเงื่อนไขตั้งต้น

ขั้นตอนเริ่มต้นทำ threat modeling

  • หากต้องการทำ threat modeling อย่างมืออาชีพ แนะนำให้อ่าน Threat Modeling Manifesto
  • ในงานปฏิบัติ ให้เริ่มจากเขียน 7 รายการในรูปแบบที่คัดลอกไปใช้ได้อย่างรวดเร็ว
  • จากนั้นวาดคอมโพเนนต์ของระบบที่จะวิเคราะห์ลงบนกระดาษหรือเครื่องมือดิจิทัล
    • หากวิดเจ็ตใดสื่อสารโดยตรง พึ่งพา หรือมีปฏิสัมพันธ์กับวิดเจ็ตอื่น ให้ทำเครื่องหมายความสัมพันธ์นั้น
    • วิธีแสดงความสัมพันธ์ควรเป็นแบบที่มีประโยชน์ที่สุดสำหรับผู้ทำงาน
  • ล้อมกราฟทั้งหมดด้วยกล่อง แล้วค่อย ๆ ลดขนาดกล่องเพื่อโฟกัสแต่ละคอมโพเนนต์
    • ในแต่ละรอบ ให้บันทึก input และ output ของคอมโพเนนต์
    • ตอบคำถาม 7 ข้อให้ได้มากที่สุด
  • เมื่อเจาะลึกเท่าที่ระดับ abstraction อนุญาตแล้ว ให้ระดมสมองว่าสำหรับชั้นที่ไม่ได้ขุดลึกลงไปอีก เราตั้งสมมติฐานอะไรไว้บ้าง
  • ฐานข้อมูลอาจไม่ได้พึ่งพาความปลอดภัยของ X25519 ในแบบเดียวกับ load balancer
  • ความสัมพันธ์ที่ไม่เหมาะสม เช่น RSS feed ไหลเข้าสู่ฐานข้อมูล ควรถูกบันทึกไว้ และเป้าหมายคือถ้าเป็นไปได้ให้ตัดความสัมพันธ์นั้นออก

กรณีของ publickey.directory

  • งานที่มอบความโปร่งใสของคีย์ให้ Fediverse ถูกติดตามที่ publickey.directory
  • งานนี้เริ่มจากสเปก public-key-directory-specification และในสเปกมี threat model รวมอยู่ด้วย
  • Threat model ดังกล่าวประกอบด้วยส่วนต่อไปนี้
    • สมมติฐาน
    • ทรัพย์สิน
    • ผู้มีบทบาทและชื่อบทบาท รวมถึงผู้โจมตีและคนที่ต้องการปกป้อง
    • ความเสี่ยงและสถานะความเสี่ยง
  • สถานะความเสี่ยงแบ่งเป็นสี่แบบ
    • Prevented by design: การโจมตีไม่ทำงานโดยตัวการออกแบบ
    • Mitigated: หากสมมติฐานไม่ผิด การโจมตีไม่ควรสำเร็จ
    • Addressable: มีวิธีลดผลกระทบ แต่ต้องใช้ความพยายามหรือความระมัดระวัง และผู้ดูแลระบบต้องรับรู้
    • Open: เป็นความเสี่ยงที่ลดผลกระทบไม่ได้หรือเลือกไม่ลดผลกระทบ และการโจมตีนั้นจะสำเร็จ
  • Threat model นี้ก็ไม่ได้สมบูรณ์แบบเช่นกัน
    • ไม่ได้เชื่อมความสัมพันธ์ระหว่างทรัพย์สินกับผู้มีบทบาททั้งหมดเป็นกราฟที่คนอ่านเข้าใจง่าย
    • ส่วนความเสี่ยงอาจมีจุดบอดที่ยังไม่ได้พิจารณา
    • อาจตกหล่นสมมติฐานที่สำคัญต่อความปลอดภัยของระบบ

ความแตกต่างระหว่าง Matrix และ Signal

  • Security Threat Model ของ Matrix v1.18 ระบุประเภทการโจมตี เช่น การปฏิเสธการให้บริการ การปลอมแปลง สแปม และการสอดแนม
  • เอกสารดังกล่าวมีปัญหาต่อไปนี้
    • ใกล้เคียงกับรายการประเภทการโจมตี
    • ไม่มี รายการสมมติฐาน
    • ไม่มีรายการทรัพย์สินและความสัมพันธ์ระหว่างทรัพย์สิน
    • รายการการโจมตีไม่ครบถ้วน
    • แม้ Matrix จะโปรโมตว่าเป็น E2EE messenger แต่ threat model ไม่กล่าวถึงการเข้ารหัสหรือการจัดการคีย์
  • Threat model ของ Matrix แทบไม่เปลี่ยนมากนักตั้งแต่ v1.1 และในช่วงนั้นก็มีการเปิดเผยช่องโหว่ รวมถึงการโจมตีเชิงคริปโตเพิ่มเติมอีกสองรายการของ Lotte
  • ถึงอย่างไร Matrix ก็ยังมี threat model
  • Signal ให้สเปกทางเทคนิค แต่ threat model อยู่ในรูปแบบที่ผู้ใช้ต้องทำความเข้าใจเอง
  • ต่อให้เป็น threat model ที่ไม่ดี ก็ยังดีกว่า ไม่มี threat model เลย

วิธีที่ threat model ช่วยปรับปรุงการออกแบบ

  • ในงานความปลอดภัยมักมีสุภาษิตว่า ผู้ป้องกันต้องถูกเสมอ ส่วนผู้โจมตีต้องสำเร็จแค่ครั้งเดียว
  • หากผู้ป้องกันเตรียมพร้อมเพียงพอ ก็สามารถกำหนดภูมิประเทศที่ผู้โจมตีจะเคลื่อนไหวได้
  • defense-in-depth ที่แท้จริงรวมถึงการเข้าใจ threat model ให้เพียงพอเพื่อไล่ผู้โจมตีเข้าสู่ทางตันที่คาดเดาได้

  • การป้องกัน Credential stuffing

    • Credential stuffing เป็นการโจมตีที่เรียบง่ายแต่มีประสิทธิภาพมากเกินไปในโลกจริง
    • สาเหตุคือผู้คนใช้รหัสผ่านซ้ำ
    • เนื่องจากผู้ใช้จดจำรหัสผ่านที่ไม่ซ้ำและปลอดภัยหลายชุดได้ยาก password manager จึงเป็นมาตรการลดผลกระทบที่เหมาะสมอยู่ช่วงหนึ่ง
    • ปัจจุบัน passkey ถูกมองว่าเป็นตัวเลือกที่ดีกว่า
    • passkey เป็นวิธีที่เป็นมิตรกับผู้ใช้มากขึ้นในการทำให้การยืนยันตัวตนใช้ การเข้ารหัสแบบอสมมาตร
    • ในกรณีที่ดีที่สุด ใช้ฮาร์ดแวร์ security token อย่าง SoloKeys หรือ YubiKeys
    • ในกรณีทั่วไป ระบบปฏิบัติการหรือ password manager จะเป็นผู้ให้ความสามารถนี้
    • เพื่อหลีกเลี่ยงการโจมตีง่าย ๆ ที่คล้ายกับ credential stuffing จำเป็นต้องมีการออกแบบต่อไปนี้
      • ออกแบบให้แอปพลิเคชันต้องใช้ passkey
      • ให้ผู้ใช้ลงทะเบียน passkey หลายอัน หรืออย่างน้อยต้องมีหนึ่งอันสำหรับสำรอง
      • จัดเตรียมเส้นทาง break glass ให้ผู้ดูแลระบบเพิ่ม passkey ใหม่ได้สำหรับผู้ใช้ที่สูญเสีย credentials ทั้งหมด
      • งานดูแลระบบดังกล่าวต้องถูกบันทึก log ในลักษณะที่ผู้ดูแลระบบเซ็นเซอร์ไม่ได้
      • หากเป็นไปได้ ไม่ควรรองรับรหัสผ่านสำหรับการยืนยันตัวตนเลย
      • รหัสผ่านสำหรับ derivation ของคีย์เข้ารหัสสามารถใช้ได้ในบริบทที่แยกต่างหาก
    • passkey ป้องกัน phishing ได้ เพราะขณะลงทะเบียน credentials จะถูกผูกกับชื่อโดเมนด้วยวิธีทางคริปโต
    • แม้การ onboarding passkey จะมีต้นทุน แต่ก็สามารถลดภาระ support จาก credential stuffing และ phishing ได้มากกว่า
    • เมื่อกำจัดความคาดหวังที่ไม่สมจริงว่ามนุษย์ต้องจดจำ secret ที่มี entropy สูงและต้องไม่ใช้ซ้ำ ก็สามารถลบการโจมตีได้หลายคลาสและปรับปรุง usability ไปพร้อมกัน
    • มีการอ้างประโยคของ Avi Douglen ว่า “ความปลอดภัยที่แลกมาด้วย usability ย่อมบั่นทอนความปลอดภัย”

E2EE แบบกระจายศูนย์และ threat model

  • มีข้อเสนอ 2 แบบที่กำลังถกเถียงกันสำหรับ E2EE ของ direct message
    • ActivityPub E2EE specification ที่มุ่งเป้าไปยัง DM แบบไม่สาธารณะของซอฟต์แวร์ Fediverse เช่น Mastodon
    • โปรเจกต์อย่าง Germ Network ที่มีเป้าหมายเดียวกันสำหรับ ATProto เช่น BlueSky
  • ทั้งสองโปรเจกต์เคยพิจารณาในบางช่วงว่าจะใช้ MLS เป็นโปรโตคอลจัดการคีย์สนทนาแบบ E2EE
  • ในระบบแบบไม่รวมศูนย์ MLS มีข้อจำกัดสำคัญสองข้อ
    • MLS ระบุแนวคิดนามธรรมที่เรียกว่า Authentication Service
    • ลำดับข้อความ มีความสำคัญต่อความปลอดภัยของ ratcheting tree ที่รองรับ epoch ของ MLS
  • สำหรับข้อจำกัดแรก หาก ActivityPub เลือกใช้ความโปร่งใสของคีย์ ก็ต้องระบุวิธีจัดการเมื่อข้อความ KeyUpdate หลายรายการแข่งขันกันข้ามหลายเซิร์ฟเวอร์
  • สถานการณ์ของ ATProto และ BlueSky ซับซ้อนกว่า
    • ATProto ไม่มี instance แบบเดียวกับ Fediverse
    • ในการวิเคราะห์ความปลอดภัย ต้องมองเกือบเหมือน P2P
    • อาจต้องใช้โปรโตคอลซับซ้อนที่รับประกันลำดับข้อความในระบบกระจาย เช่น แนวทางแบบ Raft consensus algorithm
    • หรือข้าม MLS แล้วเลือก pairwise E2EE โดยยอมละทิ้ง abstraction ของกลุ่ม
  • หากความลับของข้อความระหว่างผู้ใช้เป็นเป้าหมายด้านความปลอดภัย และต้องการให้โฮสติงกระจายศูนย์ การออกแบบแบบบล็อกเชนของ ATProto จะเป็นอุปสรรคต่อการใช้โปรโตคอลตกลงคีย์กลุ่มที่มีประสิทธิภาพและเป็นมาตรฐานในปัจจุบัน
  • Threat modeling สามารถเผยข้อจำกัดด้านการออกแบบเช่นนี้ได้ตั้งแต่ขั้นวาดแบบเริ่มต้น

บทบาทของ threat modeling ที่เห็นในข้อถกเถียงเรื่อง PQC

  • เกี่ยวกับ hybrid post-quantum constructions มีการอภิปราย RFC ใน mailing list ของ IETF TLS working group เพื่อกำหนด code point ของ non-hybrid ML-KEM
  • สมมติฐานของการอภิปรายมีดังนี้
    • ML-KEM ไม่ได้ออกแบบโดย NSA
    • ผู้ยื่นหลักคือ Peter Schwabe ซึ่งเคยร่วมงานกับ Daniel J. Bernstein และไลบรารีเข้ารหัส NaCl และพำนักในเยอรมนี
    • ผู้ยื่นรายอื่น ๆ ก็อยู่ในหลายพื้นที่ของยุโรป
    • ตามบทความของ Sophie Schmieg ทฤษฎีสารสนเทศตัดความเป็นไปได้ของ backdoor ใน ML-KEM
    • ML-KEM ถูกเลือกผ่านความพยายามมาตรฐานสากลแบบเปิดของ NIST ที่ดำเนินมา 10 ปี
    • NIST, FIPS และ NSA กำหนดให้ใช้ non-hybrid ML-KEM และ ML-DSA ในระบบลับ
  • draft ของ IETF ดังกล่าวระบุ non-hybrid ML-KEM และทำเครื่องหมาย Recommend=N
  • RFC ของ hybrid KEM จะถูกทำเครื่องหมาย Recommend=Y และ hybrid KEM จะถูกแนะนำมากกว่า non-hybrid KEM
  • ระบบที่ตั้งค่าให้ใช้ hybrid KEM เสมอจะไม่มีความปลอดภัยลดลงแม้จะมี RFC ของ ML-KEM
  • Google Chrome รองรับ non-hybrid ML-KEM อยู่แล้ว และข้อเท็จจริงนี้จะไม่เปลี่ยนแม้ไม่มี IETF RFC ออกมา
  • ผลเชิงปฏิบัติของ RFC นี้คือการปลดข้อจำกัดเชิงกระบวนการให้กับองค์กรที่ต้องปฏิบัติตาม CNSA 2.0, FIPS 140-3 หรือกฎคล้ายกัน และต้องการหมายเลข IETF RFC ที่เสถียร ไม่ใช่ Internet Draft
  • ประเด็นนี้อาจพบได้บ่อยในบางสายธุรกิจที่ขายให้ลูกค้าภาครัฐโดยเฉพาะ

  • ความต่างระหว่าง Hybrid PQ+ECDH กับ Pure PQ

    • ความเสี่ยงที่เผชิญใน KEM ไม่ใช่ “การถอดรหัสหลัง Q-Day” แต่คือ Harvest Now, Decrypt Later
    • Q-Day ใช้เป็นคำย่อที่หมายถึงเวลาที่ผู้โจมตีมีคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับการเข้ารหัส
    • หากแยกความเสี่ยง จะได้ดังนี้
      • ECDH ล้วน ๆ หรือไม่มี PQ จะถูกเจาะย้อนหลังได้ในวัน Q-Day
      • PQ ล้วน ๆ จะไม่ถูกเจาะในวัน Q-Day ภายใต้สมมติฐานว่าอัลกอริทึม PQ ไม่พังก่อน
      • Hybrid PQ+ECDH เป็นการ hedge ต่อการล่มสลายของอัลกอริทึมก่อน Q-Day แต่หลัง Q-Day แล้วไม่มีประโยชน์เมื่อเทียบกับ Pure PQ
    • การสนับสนุน ECDH + ML-KEM เท่ากับยอมรับว่าในระยะยาว ML-KEM เป็นอัลกอริทึมที่ปลอดภัย
    • เหตุผลที่ชอบ hybrid สรุปได้เป็นสองข้อ
      • ทำให้การนำ PQ มาใช้เร็วขึ้น เพราะยอมรับได้ง่ายกว่าอัลกอริทึมที่ไม่คุ้นเคยโดยสิ้นเชิง
      • ช่วยรับมือกรณี ML-KEM หรือการเข้ารหัสฐาน lattice ทั้งหมดเกิดการล่มสลายเชิงอัลกอริทึม
    • หากต้องการ hedge ในแบบที่ทนต่อคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับการเข้ารหัสได้ด้วย จำเป็นต้องใช้ PQ+PQ hybrid
    • หากให้ความสำคัญกับความหลากหลายของอัลกอริทึม ข้ออ้างที่ซื่อตรงกว่าน่าจะเป็น 3-way hybrid แบบ ML-KEM + HQC + ECDH
    • ML-KEM เป็น KEM ฐาน lattice และเชื่อกันว่าทนต่อการโจมตีด้วยควอนตัม
    • HQC เป็น KEM ฐาน code และเชื่อกันว่าทนต่อการโจมตีด้วยควอนตัม
    • ECDH เป็นวิธีที่ใช้อยู่ในปัจจุบัน แต่เปราะบางต่อการโจมตีด้วยควอนตัม
    • Threat modeling สามารถใช้ในข้อถกเถียงเช่นนี้เพื่อแยกการคัดค้านเชิงอุดมการณ์ออกจากความเสี่ยงทางเทคนิค

ส่งท้าย

  • บนอินเทอร์เน็ตมีคู่มือจำนวนมากที่อธิบาย threat model และ methodology ที่เกี่ยวข้องอย่างเป็นทางการ
  • เป้าหมายในที่นี้คือการมี smoke test เพื่อคัดกรองคุณภาพและประสิทธิผลของเอกสาร threat model ได้อย่างรวดเร็ว
  • Threat model ที่ดีต้องเผยให้เห็นความสัมพันธ์ของทรัพย์สิน สมมติฐาน และความเสี่ยงที่ยอมรับไว้ ไม่ใช่แค่สิ่งที่ปกป้อง ผู้โจมตี วิธีโจมตี และมาตรการป้องกัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Lobste.rs
  • ตอนแรกคิดว่าคราวนี้เขียนบล็อกโดยแทบไม่มี ท่าทีหยิ่งยโสและน่าขัดใจ เลย กำลังจะชมอยู่แล้ว แต่สุดท้ายก็ไปถึงช่วงที่เป็น บทความวิจารณ์ Matrix แบบที่พบบ่อยในบล็อกนั้นจนได้
    “ความไม่เป็นมิตร” เป็นเหตุผลที่ใช้แจ้งรายงานคอมเมนต์ได้ แต่ถ้าอยากทำให้อินเทอร์เน็ตสายเทคนิคดีขึ้น ผมคิดว่าเราควรเลิกเสพน้ำเสียงก้าวร้าวที่ผู้เขียนคนนี้ใช้บ่อยเกินไปในบล็อก และหยุดแนะนำมันด้วย อาจถึงขั้นพิจารณาแบนโดเมนนั้นไปเลยก็ได้
    • นั่นเป็น คำวิจารณ์ที่ค่อนข้างสมเหตุสมผล โดยยกถ้อยคำที่เป็นเป้าหมายของการวิจารณ์มาทั้งหมด และเสนอเหตุผลโต้แย้งที่มีสาระ ผมมองว่าเป็นตัวอย่างที่ดีกว่าคำวิจารณ์ส่วนใหญ่เสียอีก
    • นี่คือ วัฒนธรรมแห่งการดูหมิ่น: https://blog.aurynn.com/2015/12/16-contempt-culture
    • ผมไม่เข้าใจว่าการเรียกใครสักคนว่า “ไอ้โง่หยิ่งยโสและน่าขัดใจ” พร้อมกับเสนอให้แบนเขาเพราะไม่เป็นมิตรนั้นเข้ากันได้อย่างไร ควรแสดงให้เห็นการเปลี่ยนแปลงที่ตัวเองอยากเห็นด้วยตัวเอง
    • ผมว่าน้ำเสียงก็โอเคนะ
      และผมคิดว่าโปรโตคอลที่บอกว่า “ทุกอย่างคือกราฟ” ควรถูกปฏิบัติเหมือนเป็น โปรเจกต์วิจัย จริง ๆ บทสรุปก็คือ “แย่แล้ว อัลกอริทึมกราฟนี่จริง ๆ แล้วให้เหตุผลได้ยากมาก” นั่นเอง