สาธิตการข้าม BitLocker ด้วย memory dump บน Windows 11

 (noinitrd.github.io)
2 คะแนน โดย GN⁺ 2025-01-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นการสาธิตการ dump RAM บนสภาพแวดล้อม Windows 11 24H2 ด้วย Memory-Dump-UEFI เพื่อค้นหา FVEK ซึ่งเป็นคีย์เข้ารหัสทั้งโวลุม และเข้าถึงโวลุมที่ป้องกันด้วย BitLocker
  • หากผู้โจมตีสามารถเข้าถึงอุปกรณ์ได้ทางกายภาพ ก็อาจเล็งคีย์ที่ยังคงอยู่ใน RAM ทันทีหลังรีสตาร์ตได้ แต่ยิ่งไฟถูกตัดนานเท่าไร ความเสี่ยงที่ ข้อมูลใน RAM จะเสียหาย ก็ยิ่งสูงขึ้น
  • การสาธิตนี้ใช้วิธีช็อต ขารีเซ็ต (reset pins) บนเมนบอร์ดเพื่อรีสตาร์ตโดยไม่สูญเสียพลังงาน และไม่ครอบคลุมกรณีการข้าม Secure Boot
  • ใน dump ของ Windows 11 พบ FVEK ใต้แท็ก dFVE และ None แทน FVEc ของ Windows 7 และ Cngb ของ Windows 8.1/10 ในอดีต
  • แม้ Microsoft จะพยายามทำลายคีย์ด้วยฟังก์ชันอย่าง SymCryptSessionDestroy แต่คีย์อาจยังคงอยู่บนฮีป ดังนั้นการวิเคราะห์การทำงานของ BitLocker ด้วย การดีบักระดับเคอร์เนล จึงเป็นแนวทางที่ตรงที่สุด

ขอบเขตของการสาธิตการข้าม BitLocker บน Windows 11

  • เป้าหมายคือ Windows 11 version 24H2 และเป็นวิธีดึง FVEK ซึ่งเป็นคีย์เข้ารหัสทั้งโวลุมของ BitLocker ออกจากหน่วยความจำ
  • ใช้แอปพลิเคชัน UEFI สำหรับ dump เนื้อหา RAM ชื่อ Memory-Dump-UEFI
  • สมมติฐานหลักคือผู้โจมตีต้องสามารถ เข้าถึงอุปกรณ์ได้ทางกายภาพ

เงื่อนไขที่ทำให้การ dump RAM ใช้งานได้

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

การเตรียมบูต USB และการสร้าง dump

  • บูต USB ต้องมีอุปกรณ์เก็บข้อมูลที่มีความจุมากกว่าขนาด RAM ของระบบเป้าหมาย
  • สคริปต์ flashimage.sh ช่วยทำให้การเตรียมแอปพลิเคชันที่บูตได้ง่ายขึ้น
  • ขั้นตอนการสร้างและใช้งานแอปพลิเคชันสำหรับบูตสรุปไว้ที่ MemoryDumpUEFI
  • การรีสตาร์ตขณะ Windows กำลังโหลดอยู่ แต่ก่อนที่หน้าจอล็อกอินจะปรากฏ เป็นช่วงที่มีโอกาสพบ FVEK สูงที่สุด
  • จากนั้นให้บูตจากอุปกรณ์ USB ไปยัง Memory-Dump-UEFI ทันที แล้วรัน app.efi ใน UEFI shell
    • วิธีรันมีขั้นตอนเพิ่มเติมใน README ของแอปพลิเคชัน
    • เวลาที่ใช้ในการ dump ขึ้นอยู่กับขนาด RAM และความเร็วของอุปกรณ์ USB
    • เพื่อหลีกเลี่ยงการเขียนลงไดรฟ์ผิด ควรถอดอุปกรณ์เก็บข้อมูล USB อื่นออก

การจัดการไฟล์ dump และเครื่องมือค้นหา

  • Memory-Dump-UEFI สามารถสร้างไฟล์ dump ได้หลายไฟล์
  • เพื่อให้เป็นไปตามข้อกำหนดของ UEFI ต้องใช้ระบบไฟล์ FAT32 และ FAT32 มี ข้อจำกัดขนาดไฟล์ 4GB
  • concatDumps ในไดเรกทอรี tools ใช้รวม dump หลายไฟล์ตามลำดับเวลาให้เป็นไฟล์เดียว
  • dump เป็นข้อมูลดิบที่อยู่ในหน่วยความจำ ณ เวลานั้น จึงสามารถใช้เครื่องมืออย่าง xxd เพื่อตรวจดูให้อ่านง่ายขึ้นได้
  • searchMem ใช้ค้นหาแพตเทิร์น hex ใน dump และสามารถย้ายไปยังออฟเซ็ตของตำแหน่งที่พบได้

Pool tag และตำแหน่งของ FVEK

  • pool tag คือรหัสระบุ 4 ตัวอักษรที่บ่งชี้ตำแหน่งของ Windows kernel memory pool
  • memory pool ที่เคอร์เนล Windows จัดสรรอาจเป็นตำแหน่งที่เหมาะสำหรับค้นหาข้อมูลอ่อนไหว
  • pooltag.txt มีรายการ pool tag และข้อมูลเกี่ยวกับจุดประสงค์ของแต่ละรายการ
  • ใน Windows รุ่นก่อนหน้า ตำแหน่งของคีย์ BitLocker แตกต่างกัน
    • บน Windows 7 สามารถกู้คืนคีย์ได้จาก pool tag FVEc ซึ่งสอดคล้องกับการจัดสรรการเข้ารหัสของ fvevol.sys
    • บน Windows 8.1 และ Windows 10 สามารถค้นหาคีย์ได้ใน memory pool ของแท็ก Cngb ที่เกี่ยวข้องกับโมดูล ksecdd.sys
  • ใน dump ของ Windows 11 ไม่พบคีย์ใน FVEc และ Cngb แต่พบ FVEK ในสองตำแหน่งแทน
    • ตำแหน่งแรกอยู่ใต้ pool tag dFVE ซึ่งบ่งชี้หน่วยความจำที่ dumpfve.sys จัดสรรไว้
    • dumpfve.sys เกี่ยวข้องกับ full volume encryption crash dump filter ของ BitLocker drive encryption
    • ตำแหน่ง dFVE เป็นจุดที่พบคีย์ได้ง่ายและสม่ำเสมอที่สุด
    • ก่อนหน้าคีย์ในตำแหน่งนี้มีค่า 0x0480 ซึ่งระบุชนิดการเข้ารหัส และในสภาพแวดล้อมของการสาธิตนี้หมายถึง XTS-AES-128
    • ตำแหน่งที่สองอยู่ใต้แท็ก None ซึ่งเกี่ยวข้องกับการเรียก ExAllocatePool
    • ในตำแหน่งนี้พบครึ่งแรกของคีย์สองครั้ง และครึ่งหลังหนึ่งครั้ง

การเข้าถึงโวลุม BitLocker ด้วย FVEK

  • คีย์ที่ได้มาต้องเติมค่าของอัลกอริทึมเข้ารหัสที่ใช้อยู่ไว้ด้านหน้า
  • ในตัวอย่างนี้มีการเติมค่าอัลกอริทึม 0x8004 ไว้หน้าคีย์ในรูปแบบ little endian คือ 0480
  • ค่าที่ประกอบแล้วนี้สามารถบันทึกเป็นไฟล์และใช้งานในรูปแบบ output.fvek ได้
  • ชุดเครื่องมือ dislocker เป็นตัวเลือกที่แนะนำสำหรับตรวจสอบอัลกอริทึมและค่าที่จำเป็น รวมถึงใช้ปลดล็อกพาร์ทิชันที่ป้องกันด้วย BitLocker
  • หากขั้นตอนถูกต้อง ก็จะสามารถใช้ output.fvek เพื่อเข้าถึงข้อมูลในโวลุมที่ป้องกันด้วย BitLocker ได้

การวิเคราะห์การทำงานของ BitLocker และคีย์ที่ค้างอยู่บนฮีป

  • วิธีที่ตรงที่สุดในการทำความเข้าใจการทำงานของ BitLocker คือการใช้ windbg เพื่อดีบักในระดับเคอร์เนล
  • การดีบักเคอร์เนลทำได้ค่อนข้างง่ายผ่านเครื่องเสมือนหรือสาย crossed over USB 3.0 A/A
  • การไล่ดูขั้นตอนการบูตของ Windows ทีละลำดับและสังเกตการทำงานของ BitLocker ช่วยให้ค้นหาคีย์ได้
  • Microsoft พยายามทำลายคีย์ด้วยฟังก์ชันอย่าง SymCryptSessionDestroy แต่คีย์อาจยังคงอยู่บนฮีป จึงไม่สามารถลบคีย์ทั้งหมดได้

ลิงก์อ้างอิง

  • recovering-bitlocker-keys-on-windows-8-1-and-10: เอกสารเกี่ยวกับการกู้คืนคีย์ BitLocker บน Windows 8.1 และ Windows 10
  • dislocker: ชุดเครื่องมือที่ใช้เข้าถึงโวลุม BitLocker
  • SymCrypt: ไลบรารีเข้ารหัสของ Microsoft
  • libbde: ไลบรารีที่เกี่ยวข้องกับ BitLocker Drive Encryption
  • pooltag.txt: รายการ Windows pool tag
  • An Introduction to Pool Tags: เอกสารแนะนำ pool tag ของ Microsoft

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

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

 
GN⁺ 2025-01-01
ความคิดเห็นจาก Hacker News

  • ผมมองว่า BitLocker มีประโยชน์สูงสุดเมื่อใช้ TPM(PCR 7+11)+PIN
    ถ้าไม่มี PIN ก็ควรอ่าน FVEK ไม่ได้ ดังนั้นจึงช่วยบรรเทาการโจมตีนี้ได้ และถ้า BitLocker ทำไว้ถูกต้อง เมื่อใส่ PIN ผิดมากเกินไป TPM จะเข้าสู่โหมดล็อกป้องกันการโจมตีแบบเดาสุ่ม
    ผมพยายามทำคอนฟิกแบบเดียวกันบน Linux มาหลายเดือนแล้ว แต่ systemd-cryptsetup/cryptenroll เป็นของ LUKS ส่วนกรณีของผมคืออยากเข้ารหัสไดเรกทอรีที่ละเอียดอ่อนบางส่วนด้วย fscrypt (คีย์ secure boot และ /home) บน eMMC ในตัวที่ช้า
    พอเกินระดับพื้นฐานไปแล้ว รู้สึกว่าการเขียนโค้ด TPM นั้น ยากสุดขีด: ต้องผูกกับ PCR 7, ผูกกับ PCR 11 ที่เปลี่ยนทุกครั้งเมื่ออัปเดตเคอร์เนล/init/cmdline, ใช้ PIN ไม่ใช่ AuthValue, ใช้นโยบายอนุมัติเดียวกันในการรีเซ็ตตัวนับ DA lockout ตอนล็อกอิน พร้อมทั้งมีรหัสผ่านยาว/AuthValue สำหรับรีเซ็ตด้วยมือ และยังต้องให้ตรงกับลายเซ็น PCR 11 กับกุญแจสาธารณะที่ systemd-stub ให้มาด้วย
    นอกจากคู่มือ TPM พื้นฐานแล้วแทบไม่มีข้อมูลเลย ถ้ามีผู้เชี่ยวชาญก็อยากได้ความช่วยเหลือ นี่เป็นโปรเจกต์ส่วนตัว แต่ถ้าวันหนึ่งทำเสร็จก็ตั้งใจจะเขียนสรุปไว้

    • LUKS มี key slot หลายช่อง เท่าที่จำได้จึงน่าจะใช้ช่องหนึ่งสำหรับปลดล็อกด้วย TPM และใช้อีกช่องสำหรับกู้คืนด้วยรหัสผ่านยาวได้
      วิธีนั้นน่าพิจารณาใช้เป็นกลไกกู้คืน
      หนึ่งในเหตุผลที่มีคนทำงานด้าน TPM โอเพนซอร์สเป็นงานอดิเรกน้อย คือมีทางเลือกมากมายที่ตอบโจทย์คล้ายกันได้ง่ายกว่ามาก
      ถ้าอยากผูกคีย์เข้ารหัสสำคัญไว้กับฮาร์ดแวร์ ก็ซื้อ Yubikey ได้ และถ้ารหัสผ่านเข้ารหัสดิสก์ของโน้ตบุ๊กยุ่งยาก ก็ใช้โหมดสแตนด์บายเมื่อปิดฝาแทนการปิดเครื่องสนิทได้
      ถ้ารหัสผ่านล็อกอินไม่สะดวก ก็มีเครื่องอ่านลายนิ้วมือหรือ Yubikey แบบยืนยันตัวตนด้วยชีวมิติ และถ้าต้องบูตโดยไม่ใช้รหัสผ่าน เช่น คีออสก์ไร้คนดูแลหรือห้องคอมพิวเตอร์ของโรงเรียน ก็ใส่ไว้ในกล่องโลหะแข็งแรงแล้วล่ามโซ่ติดผนัง
      ถ้าเซิร์ฟเวอร์ในดาต้าเซ็นเตอร์ต้องบูตแบบไร้คนดูแล ก็ย้ายไปดาต้าเซ็นเตอร์ที่มีความปลอดภัยทางกายภาพที่เชื่อถือได้ และถ้ายังกังวลอยู่ ก็ใช้ Dropbear หรือ Tang ให้บูตได้เฉพาะเมื่ออยู่ในเครือข่ายที่ถูกต้อง
      ถ้ากำลังเล่น TPM เป็นงานอดิเรกในโฮมแล็บ ก็ควรตรวจสอบให้ดีว่า งานเกี่ยวกับ TPM สนุกจริงหรือไม่ และมีโอกาสสูงที่จะพบว่าอาจไม่ใช่
    • แม้ Windows จะกำหนดให้ต้องใช้ PIN ตอนที่ TPM ได้ FVEK ครั้งแรก สุดท้ายก็ยังต้อง เก็บ FVEK ไว้ใน RAM อยู่ดี
      ไม่อย่างนั้นต้องป้อน PIN ทุกครั้งที่ถอดรหัสบล็อกดิสก์ไม่ใช่หรือ? ผลกระทบด้านประสิทธิภาพจากการเรียก TPM ทุกครั้งที่มีงานกับดิสก์ก็มากด้วย
      การโจมตีนี้อ่านคีย์จาก RAM ดังนั้นผมไม่เข้าใจว่า TPM PIN จะเป็นมาตรการบรรเทาได้อย่างไร
    • ผมคิดว่าใช้ การเข้ารหัสแบบแบ่งคีย์ หรือคีย์ลับที่ถูกเข้ารหัสไว้น่าจะดีกว่า
      ถ้าต้องใส่รหัสผ่านก่อนบูต และต้องนำรหัสผ่านนั้นมารวมกับคีย์ TPM ถึงจะเปิดไดรฟ์ได้ ก็จะช่วยได้ในสถานการณ์ที่ภายหลังมีการค้นพบคีย์ TPM
      แต่สำหรับการโจมตีนี้ ยากจะมั่นใจว่ามาตรการไหนช่วยได้มากแค่ไหน เพราะถ้า OS ต้องคงสิทธิ์อ่าน/เขียนไดรฟ์ไว้ ก็ต้องถือคีย์ไว้ที่ไหนสักแห่ง ดังนั้นแค่เปลี่ยนตำแหน่งที่ไปค้นหาคีย์ ก็น่าจะยังสามารถกู้ข้อมูลจาก RAM แบบนี้ได้ในสถานการณ์ส่วนใหญ่
      เท่าที่จำได้ อุปกรณ์ Apple ไม่ปล่อยคีย์ออกมานอก secure enclave จึงดูเหมือนจะไม่เปราะบางต่อการโจมตีแบบนี้ TPM 3.0 ดูเหมือนจำเป็นต้องเข้าใกล้แนวทางนั้นให้มากขึ้นมาก
    • ผมคิดว่า รหัสผ่านเปิดเครื่องของ BIOS ก็น่าจะใช้ได้เช่นกัน เพราะถ้าไม่มีสิ่งนั้น ระบบก็ไปไม่ถึงจุดที่ TPM ปลด FVEK ให้
      บน ThinkPad สามารถใช้ลายนิ้วมือแทนรหัสผ่านเปิดเครื่องได้ และทำให้อุปกรณ์แทบใช้ไม่ได้สำหรับขโมย ผมจึงชอบคอนฟิกนี้มากกว่า BitLocker PIN
      แน่นอนว่ารหัสผ่านเปิดเครื่องและการยืนยันตัวตนด้วยลายนิ้วมือก็แข็งแรงเท่ากับ TPM เท่านั้น แต่ BitLocker TPM+PIN ก็เหมือนกันไม่ใช่หรือ
    • ผมสงสัยว่า TPM เป็นเหมือน ฮันนีพอต แบบหนึ่งหรือเปล่า
      หลังจากมีซอฟต์แวร์เข้ารหัสโอเพนซอร์สที่ประสบความสำเร็จแล้ว กระแสที่ย้ายไปใช้ TPM ดูแปลก ๆ เหมือนกับบอกว่ามีที่เก็บข้อมูลแบบปลอดภัยสุด ๆ จากบริษัทใหญ่ให้ใช้แล้ว ไม่ต้องกังวลหรือถามอะไร
      ผมอดสงสัยไม่ได้ว่าต้องมีแบ็กดอร์ที่หน่วยข่าวกรองสามารถดาวน์โหลด PIN และรหัสผ่านทั้งหมดแล้วเข้าถึงข้อมูลได้อย่างแน่นอน

  • ผมยังไม่เข้าใจ โมเดลความปลอดภัย ของ BitLocker อย่างถ่องแท้
    ในการติดตั้งส่วนใหญ่ ดูเหมือนว่ากดปุ่มเปิดเครื่องแล้วก็จะบูตเข้า Windows
    ถ้าอย่างนั้นเมื่อมีคนขโมยเครื่องที่มีฮาร์ดไดรฟ์เข้ารหัสไป แค่เปิดเครื่องก็พอแล้วหรือ? คงไม่ใช่แบบนั้นหรอก แต่ขณะเดียวกันก็ไม่รู้ว่ามันป้องกันการโจมตีเฉพาะแบบนี้ได้อย่างไร
    คงต้องสันนิษฐานว่าทราฟฟิกบนบัส SPI ถูกเข้ารหัส จึงไม่สามารถดัมป์คีย์แบบนี้ได้ แต่ไม่ว่าอย่างไร ดูเหมือนเครื่องจะยอมปล่อยคีย์ออกมาได้ค่อนข้างง่าย
    อย่างน้อย LUKS ก็มีพรอมป์ให้ใส่รหัสผ่านเพื่อปลดล็อกไดรฟ์

    • ทราฟฟิกบนบัส SPI ไม่ได้เข้ารหัส
      แปลกดีที่ Microsoft ไม่ใช้การเข้ารหัสพารามิเตอร์ของ TPM ดังนั้นทุก ๆ 1–2 ปี นักวิจัยด้านความปลอดภัยก็จะทำอุปกรณ์ดักฟัง TPM มาเดโมให้ดู
      LUKS ก็ขึ้นอยู่กับการตั้งค่าเช่นกัน Linux ก็สามารถตั้งค่าในลักษณะเดียวกับ Windows ตรงนี้ได้ และเซิร์ฟเวอร์รักษาความปลอดภัยวิดีโอที่บ้านของผมก็ต้องรีบูตแบบเงียบ ๆ เลยตั้งค่าไว้แบบนั้น ผมรู้ว่ามันเสี่ยงต่อการโจมตีแบบ warm/cold boot และพื้นผิวโจมตีทางซอฟต์แวร์ แต่ถ้ามีคนแค่ถอดไดรฟ์ไปก็ยังปลอดภัย
      Windows ก็สามารถตั้งให้ต้องใช้รหัสผ่าน หรือใช้คีย์ TPM ที่ผนึกด้วย PIN authentication ได้
      ถ้าตัดปัญหาเรื่องการเข้ารหัสพารามิเตอร์และการดักฟังบัสออกไป BitLocker จะย้ายขอบเขตจาก “ใครก็อ่านไดรฟ์ได้” ไปเป็น “ต้องโจมตีระดับแพลตฟอร์มเพื่อเอาเนื้อหาในหน่วยความจำ หรือแฮ็กบริการที่ทำงานอยู่ในหน้าจอเข้าสู่ระบบ”
      มันกันสถานการณ์อย่างการขโมยข้อมูลการเงินจากฮาร์ดไดรฟ์ที่ถูกนำกลับมาใช้ใหม่แบบสุ่มได้ดีมาก จึงถือเป็นการยกระดับความปลอดภัยที่ค่อนข้างดีจริง ๆ
    • ถ้าเปิดเครื่องที่ขโมยมา ก็จะไปได้แค่ถึง หน้าจอเข้าสู่ระบบ และไปต่อไม่ได้หากไม่มีรหัสผ่านหรือการยืนยันตัวตนด้วยชีวมิติ
      ต้องมีการเลี่ยงผ่านอย่างช่องโหว่ remote code execution หรือบูตด้วย Windows bootloader รุ่นเก่าที่มีช่องโหว่ เนื่องจากไดรฟ์ถูกล็อกอยู่ วิธีเลี่ยงผ่านยอดฮิตอย่าง “เปลี่ยนซอฟต์แวร์คีย์บอร์ดเป็น cmd.exe” จึงใช้ไม่ได้
      ถ้าไม่มี BitLocker ก็แค่เสียบไดรฟ์ Windows เข้ากับพีซีเครื่องอื่นแล้วดูไฟล์ทั้งหมดได้ แต่ถ้ามี BitLocker ก็ต้องไปสู้กับซอฟต์แวร์ Microsoft ที่มีช่องโหว่ ช่องโหว่ต่าง ๆ หน่วยความจำที่ถูกดัมป์ และอะไรทำนองนั้น ซึ่งก็ไม่ได้สำเร็จเสมอไป
      ถ้าตั้ง BitLocker เป็นโหมด TPM+PIN ก็ทำแม้กระทั่งแบบนั้นไม่ได้ เพราะไม่มีรหัสผ่านสำหรับเปิด TPM จะตั้ง BitLocker เป็นโหมดใช้รหัสผ่านอย่างเดียวก็ได้ แต่จะเสี่ยงต่อการ brute force มากกว่าเยอะ
      LUKS ก็เช่นกัน ปัจจุบันดิสโทร Linux ส่วนใหญ่รองรับ TPM และ TPM+PIN
    • ถูกต้อง แต่เจตนาคือที่หน้าจอเข้าสู่ระบบ (winlogon) หากไม่มีข้อมูลรับรองบัญชีของเครื่องนั้นหรือไม่ได้ลงทะเบียนชีวมิติไว้ ก็แทบทำอะไรจริง ๆ ไม่ได้
      ถ้าพยายามรีบูตเข้า Safe Mode หรือรีบูตไปยัง OS อื่น ยูทิลิตีอัปเดตเฟิร์มแวร์ ฯลฯ ก็ต้องใส่ BitLocker recovery key
      ผมไม่ค่อยแน่ใจว่ากรณี “แฮ็ก” เซ็นเซอร์ลายนิ้วมือหรือเว็บแคมจดจำใบหน้านั้นภายในทำงานอย่างไร
    • จุดประสงค์หลักของการใช้ BitLocker ร่วมกับ PIN+TPM คือทำให้คอมพิวเตอร์ที่ปิดเครื่องอยู่หรือตัวไดรฟ์เองกลายเป็นก้อนอิฐ
      ต้องตั้งสมมติฐานว่า TPM ไม่มีช่องโหว่ที่ดึงคีย์ออกมาได้
      ประเด็นสำคัญคือตอนที่ปิดเครื่องอยู่
      สำหรับการเข้ารหัสไดรฟ์ทั่วไป TPM ช้าเกินกว่าจะถอดรหัสข้อมูลปริมาณมากจริง ๆ สุดท้าย OS จึงต้องถือคีย์ที่สามารถถูกดึงออกมาได้
    • วอลุ่ม BitLocker สามารถมีตัวป้องกันได้หลายแบบ และใช้ไฟล์คีย์ passphrase, PIN, ที่เก็บข้อมูล TPM ได้: https://learn.microsoft.com/en-us/windows-server/administrat...
      ในรุ่น Pro ยังสามารถใช้ Group Policy บังคับให้ต้องมี ขั้นตอนโต้ตอบ ตอนบูตได้ด้วย ทำงานได้แม้ไม่มี TPM และในกรณีนี้จะถามรหัสผ่านทุกครั้งที่เริ่มเครื่อง

  • สิ่งนี้สามารถป้องกันได้อย่างสมบูรณ์ด้วย https://trustedcomputinggroup.org/resource/pc-client-work-gr...
    หากเปิดใช้ไว้ ในกรณีที่ OS ไม่ได้ปิดเครื่องตามปกติจนไม่มีโอกาสลบคีย์เข้ารหัส ก่อนบูตครั้งถัดไป เฟิร์มแวร์จะหยุดและล้าง RAM
    สงสัยว่า Windows ไม่ได้ใช้สิ่งนี้ หรือระบบที่ทดสอบไม่ได้ implement กันแน่

    • เป็นที่ทราบว่า Windows ใช้ฟีเจอร์นี้: https://learn.microsoft.com/en-us/windows/security/operating...
      ระบุว่า “BitLocker ใช้ TCG Reset Attack Mitigation หรือที่เรียกว่า MOR bit (Memory Overwrite Request) ก่อนจะดึงคีย์ออกมาไว้ในหน่วยความจำ”
      อย่างไรก็ตาม ผมไม่เชื่อถือการ implement ของแพลตฟอร์มส่วนใหญ่เลย ไม่เคยเห็นแพลตฟอร์ม UEFI ที่ implement ได้ใกล้เคียงกับคำว่าถูกต้องในรูปแบบใด ๆ
      คงน่าสนใจถ้ารู้ว่านักวิจัยคนนี้ใช้แพลตฟอร์มใด และแพลตฟอร์มนั้นอ้างว่ารองรับ MOR bit หรือไม่
    • มาตรการบรรเทานั้นค่อนข้างง่อยมาก เพราะยังสามารถแทรกแซงระหว่างที่กำลังเขียนทับ RAM ได้
      แค่ดูว่า Team Tweezers โจมตี Wii รุ่นแรกอย่างไรก็พอ
      มาตรการบรรเทาที่แท้จริงคือฟีเจอร์ การเข้ารหัสหน่วยความจำ ของ CPU สมัยใหม่ เพราะมันอยู่ภายในได จึงใช้แหนบแตะไม่ถึง และแค่ลบคีย์ก็พอจึงลบทันที อีกทั้งแม้จะรอดผ่านการตัดต่อไฟมาได้ ก็ยากมากที่จะรบกวน
    • ถึงอย่างนั้นก็ยังไม่สามารถป้องกันการถอดโมดูล RAM ทั้งก้อนออกมาแล้วดัมป์แบบออฟไลน์ได้
      ตามอุดมคติ คีย์ควรเหลืออยู่เฉพาะใน SRAM cache ของ CPU และไม่ควรออกไปนอกไดของ CPU เลย

  • ผมเป็นคนเขียนบทความนี้เอง ถ้ามีคำถามก็ส่งข้อความมาที่บัญชีนี้ได้
    งานนี้สนุกมากจริง ๆ และขอบคุณสำหรับความสนใจอย่างมาก

  • การนำเสนอที่ 38C3 เกี่ยวกับการเลี่ยงผ่าน BitLocker บน Windows 11: https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...

  • เป็นที่ทราบกันค่อนข้างดีว่า BitLocker ปกป้องได้อย่างเหมาะสมเฉพาะกับ คอมพิวเตอร์ที่ปิดอยู่ เท่านั้น และถึงอย่างนั้นก็เฉพาะเมื่อมีการตั้งค่าให้ BitLocker ขอรหัสผ่านตอนบูต
    [0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...

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

    • Microsoft กำลังขยับไปสู่ ความปลอดภัยบนพื้นฐานของ virtualization มากขึ้นเรื่อย ๆ รวมถึงฟีเจอร์สำหรับรัน “enclaves” เพื่อปกป้องชิ้นส่วนซอฟต์แวร์บางส่วน: https://learn.microsoft.com/en-us/windows/win32/trusted-exec...
      คงไม่น่าแปลกใจถ้าอีกไม่นานจะมีการใช้ “เครื่องเสมือน” ที่เข้ารหัสไว้เป็นวิธีเก็บค่าลับเหล่านี้ สิ่งที่จำเป็นคือการรองรับจากฮาร์ดแวร์ที่แพร่หลายบนแพลตฟอร์มผู้บริโภค
      แต่การโจมตี side-channel ของ CPU ก่อนหน้านี้แสดงให้เห็นว่าหน่วยความจำที่เข้ารหัสก็ยังถูกโจมตีได้ (https://www.usenix.org/conference/usenixsecurity21/presentat...) โดยเล็งไปที่แคชตอนที่ CPU ถอดรหัสหน่วยความจำเพื่อให้ทำงานได้ตามปกติ
      น่าจะช่วยทำให้ memory dump ใช้ไม่ได้ผล แต่ RAM ที่เข้ารหัสคงไม่ทำให้การ dump คีย์จากหน่วยความจำหมดไป โดยเฉพาะกับผู้โจมตีที่มีความอดทนหรือมีทักษะสูง
    • ปัจจุบัน Intel มีสิ่งนี้ผ่านฟีเจอร์ Total Memory Encryption และในระบบนิเวศ Windows ก็เล็งไปที่ฝั่งเครื่องเสมือนอย่างเหมาะสม
      https://techcommunity.microsoft.com/blog/windowsosplatform/m...
      การบีบอัดหน่วยความจำมีมานานแล้ว อย่างน้อยก็ตั้งแต่ Windows 10 RTM ระบบปฏิบัติการหลักทั้งหมดต่างก็ implement ฟีเจอร์นี้ แต่ไม่ได้เกี่ยวข้องกับความปลอดภัย

  • บทความที่เกี่ยวข้อง: การเลี่ยง BitLocker บนแล็ปท็อป Lenovo ด้วย logic analyzer ราคาถูก
    https://news.ycombinator.com/item?id=37249623

  • สำหรับการโจมตีที่พึ่งพาการอ่าน memory dump ของเครื่องเป้าหมาย ถ้ามีการเข้าถึงทางกายภาพ ก็สงสัยว่า อุปกรณ์ interposer ที่คัดลอกหรือแก้ไขข้อมูลที่เข้าออก RAM จะเป็นไปได้จริงแค่ไหน
    นึกถึงอุปกรณ์อย่าง “Action Replay” สำหรับ Gameboy ในอดีต ที่แก้ไขหน่วยความจำที่ถูกโหลดหรือรันจากตลับเกมไปยังระบบเพื่อให้โกงเกมได้ วิธีใช้คือเสียบตลับเกมเข้ากับ Action Replay แล้วเสียบ Action Replay เข้ากับ Gameboy
    จะทำสิ่งคล้ายกันระหว่าง RAM กับเมนบอร์ดได้ไหม? เช่นเสียบ RAM เข้ากับอุปกรณ์ แล้วเสียบอุปกรณ์นั้นเข้ากับเมนบอร์ด จากนั้นสังเกตการอ่าน/เขียนหน่วยความจำเพื่อจับสถานะหน่วยความจำ ณ เวลาใดก็ได้
    แบบนั้นจะหลีกเลี่ยงความยุ่งยากที่ต้องปิดเครื่องด้วยมือแล้วหวังว่าข้อมูลที่ต้องการยังคงเหลืออยู่ได้
    ผมไม่ใช่วิศวกรไฟฟ้า ข้อเสนอนี้จึงอาจเป็นไปไม่ได้โดยสิ้นเชิง ข้อจำกัดด้านพื้นที่ทางกายภาพและแบนด์วิดท์ดูจะใหญ่มากแน่นอน แต่เป็นไปได้ไหม?

    • ในทางทฤษฎีเป็นไปได้ ในทางปฏิบัติ ตอนตั้งค่า DDR link ต้องมีการเจรจากันมากระหว่าง memory controller กับ RAM และไม่ง่ายที่จะสร้างสถานการณ์ที่ dump ข้อมูลได้โดยยังรักษา timing เดิมไว้
      คงคาดหวังยากว่าจะมีโซลูชันสำเร็จรูปออกมา
    • CPU AMD/Intel รุ่นใหม่รองรับ การเข้ารหัสหน่วยความจำทั้งหมด แบบโปร่งใส ดังนั้น interposer แบบนั้นจะเห็นเฉพาะข้อมูล RAM ที่ถูกเข้ารหัสเท่านั้น

  • มีคนไม่มากที่รู้ว่า CPU Intel/AMD ที่ออกมาในช่วงไม่กี่ปีมานี้รองรับ การเข้ารหัสหน่วยความจำทั้งหมด แบบโปร่งใส
    เนื้อหาใน RAM จะถูกเข้ารหัสด้วยคีย์สุ่มที่เก็บอยู่ใน memory controller ของ CPU และสร้างขึ้นตอนรีเซ็ต
    โดยปกติ BIOS จะปิดไว้ เพราะมีผลกระทบต่อประสิทธิภาพหน่วยความจำเล็กน้อย (0.1%~1%)
    แต่การโจมตีนี้สามารถถูกป้องกันได้อย่างสมบูรณ์

    • เท่าที่เข้าใจ AMD เรียกฟีเจอร์นี้ว่า SME(Secure Memory Encryption) ส่วน Intel เรียกว่า TME-MK(Total Memory Encryption-Multi Key)