นักวิจัยด้านความปลอดภัยเผยเอ็กซ์พลอยต์ พร้อมอ้างว่า Microsoft สร้างแบ็กดอร์ใน BitLocker
(techspot.com)- นักวิจัยด้านความปลอดภัย Nightmare-Eclipse เปิดเผย YellowKey โดยระบุว่าสามารถข้ามการเข้ารหัสทั้งโวลุ่มของ BitLocker ได้โดยไม่ต้องใช้รหัสผ่าน
- YellowKey สามารถทำซ้ำได้โดยคัดลอกโฟลเดอร์ FsTx ไปยังไดรฟ์ USB ที่ใช้ระบบไฟล์ซึ่งเข้ากันได้กับ Windows แล้วทำตามลำดับขั้นตอนเฉพาะใน WinRE
- เมื่อทำขั้นตอนเสร็จสิ้น จะมีการเปิด command shell และสามารถสำรวจ คัดลอก และจัดการไฟล์ในโวลุ่มที่ BitLocker ปกป้องอยู่ได้
- Nightmare-Eclipse ตั้งข้อสังเกตว่าพฤติกรรมการข้ามนี้เกิดขึ้นเฉพาะใน อิมเมจ WinRE อย่างเป็นทางการ เท่านั้น จึงตั้งข้อสงสัยว่าอาจเป็นแบ็กดอร์ที่จงใจใส่ไว้
- ระบุว่าผลกระทบครอบคลุม Windows 11, Server 2022, Server 2025 และเสริมว่า Windows 10 ไม่ได้รับผลกระทบ
เงื่อนไขการทำงานของ YellowKey
- นักวิจัยด้านความปลอดภัย Nightmare-Eclipse เปิดเผย YellowKey โดยระบุว่าสามารถข้ามการเข้ารหัสทั้งโวลุ่มของ BitLocker ได้อย่างสมบูรณ์
- YellowKey สามารถทำซ้ำได้โดยคัดลอก โฟลเดอร์ FsTx ที่แนบมาไปยังไดรฟ์ USB ที่ฟอร์แมตด้วยระบบไฟล์ที่เข้ากันได้กับ Windows เช่น NTFS, FAT32, exFAT
- มีรายงานว่าสามารถทำงานได้แม้ไม่มีไดรฟ์ USB หากคัดลอกไฟล์ FsTx ไปยัง พาร์ทิชัน Windows EFI และถอดดิสก์ที่เข้ารหัสออกจากระบบชั่วคราว
- จากนั้นให้รีบูตระบบที่มีการป้องกันด้วย BitLocker แล้วเข้าสู่ Windows Recovery Environment(WinRE) ก่อนทำตามลำดับการป้อนข้อมูลที่กำหนด
- หากทำขั้นตอนได้อย่างถูกต้อง จะมี command shell ปรากฏขึ้น และสามารถสำรวจ คัดลอกโวลุ่มที่ BitLocker ปกป้องไว้ หรือดำเนินการด้านไฟล์อื่น ๆ ได้โดยไม่ต้องใช้รหัสผ่าน
เหตุผลของข้อสงสัยเรื่องแบ็กดอร์
- Nightmare-Eclipse ระบุว่า YellowKey มีลักษณะผิดปกติเกินกว่าจะมองว่าเป็นบั๊กความปลอดภัยที่ไม่เคยมีใครรู้มาก่อน และตั้งข้อสงสัยว่า Microsoft อาจใส่ แบ็กดอร์ที่ใช้งานได้จริง ไว้ในระบบปกป้องข้อมูลของ BitLocker
- เหตุผลคือคอมโพเนนต์ที่ก่อให้เกิดปัญหานั้นพบได้เฉพาะใน อิมเมจ WinRE อย่างเป็นทางการ เท่านั้น
- แม้คอมโพเนนต์เดียวกันจะมีอยู่ในอิมเมจติดตั้ง Windows มาตรฐาน แต่ระบุว่าไม่พบพฤติกรรมการข้าม BitLocker แบบเดียวกันในระบบที่ใช้งานจริง
- Nightmare-Eclipse กล่าวว่า “ผมนึกคำอธิบายอื่นไม่ออกนอกจากข้อเท็จจริงที่ว่าสิ่งนี้ตั้งใจทำขึ้น” และเสริมว่า Windows 10 ไม่ได้รับผลกระทบ ขณะที่มีผลเฉพาะกับ Windows 11, Server 2022, Server 2025
การยืนยันจากภายนอกและการเปิดเผยเพิ่มเติม
- มีรายงานว่านักวิจัยบุคคลที่สามได้ยืนยันแล้วว่า YellowKey ทำงานได้ตามวิธีที่ระบุไว้ในเอกสาร GitHub ของ Nightmare-Eclipse
- Nightmare-Eclipse ยังเปิดเผยเอ็กซ์พลอยต์ตัวที่สองชื่อ GreenPlasma ซึ่งระบุว่าสามารถยกระดับสิทธิ์ได้
- GreenPlasma ยังไม่ได้เปิดเผยโค้ด proof-of-concept แบบเต็มที่ทำให้ได้ สิทธิ์ระดับ SYSTEM และส่งสัญญาณว่าอาจเปิดเผยรายละเอียดเพิ่มเติมก่อน Patch Tuesday ในเดือนหน้า
แนวทางบรรเทา
- มีการระบุว่าการบรรเทาข้อสงสัยเรื่องพฤติกรรมแบบแบ็กดอร์ของ YellowKey นั้นค่อนข้างทำได้ง่าย
- ผู้เชี่ยวชาญด้านความปลอดภัยแนะนำว่าไม่ควรพึ่งพาระบบเข้ารหัสเพียงระบบเดียว และควรประเมินทางเลือก การเข้ารหัสดิสก์ทั้งลูก อื่น ๆ ที่ผ่านการตรวจสอบมาอย่างดีด้วย
- ตัวอย่างที่ยกมาคือ VeraCrypt
2 ความคิดเห็น
ความคิดเห็นจาก Lobste.rs
มีข้อมูลว่าแบ็กดอร์นี้จะทำงานได้ก็ต่อเมื่อ WinRE ต้องปลดล็อกไดรฟ์(โพสต์ก่อนหน้า) และถ้าไดรฟ์ถูกป้องกันด้วยรหัสผ่าน ก็น่าจะยังต้องใส่รหัสผ่านนั้น
เป้าหมายจริงน่าจะเป็น Transparent BitLocker ที่เชื่อแค่ TPM และไม่ใช้รหัสผ่านเข้ารหัสดิสก์มากกว่า เมื่อ Windows บูตเต็มรูปแบบแล้วและคีย์เข้ารหัสอยู่ในหน่วยความจำ โดยมีแค่หน้าจอเข้าสู่ระบบที่กันไม่ให้ล็อกอิน สภาพนี้ ไม่ปลอดภัยอย่างที่ฟังดูอยู่แล้ว
เพราะจริง ๆ คือเข้าไปอยู่ใน Windows แล้ว ทำให้มีพื้นผิวการโจมตีขนาดใหญ่มาก และนอกจาก “bugdoor” ของ OP แล้ว ก็เคยมีบั๊กอีกหลายตัวที่ช่วยให้ข้ามหน้าจอเข้าสู่ระบบได้ นอกจากนี้ยังอาจ ดักฟังบัส TPM หรือดึงคีย์จากหน่วยความจำด้วยการโจมตีแบบ cold boot ได้ด้วย
แน่นอนว่ายังน่ากังวลอยู่ แต่ดูเหมือนว่านี่จะเป็นรูปแบบการใช้งาน BitLocker ที่แนะนำกัน และผู้ใช้ทั่วไปก็ไม่ได้ถูกเตือนอย่างเหมาะสมถึงความเสี่ยงของการไม่ใช้รหัสผ่านจริงกับการเข้ารหัสดิสก์ อย่างไรก็ตาม ผมคิดว่าช่องโหว่นี้กระทบเฉพาะกรณีที่ใช้ BitLocker ในแบบที่ไม่ปลอดภัยโดยพื้นฐานอยู่แล้ว และแค่ทำให้การโจมตีที่มีอยู่เดิมง่ายขึ้นเล็กน้อย
แต่ถ้า WinRE สามารถเปิดไดรฟ์ที่เข้ารหัสด้วยรหัสผ่านได้แบบปาฏิหาริย์จริง เรื่องก็จะเปลี่ยนไป แม้ผมคิดว่าถ้าเป็นแบบนั้นจริง น่าจะมีคนสังเกตเห็นตั้งแต่หลายปีก่อนแล้ว
“อย่างที่สอง ไม่ครับ TPM+PIN ก็ไม่ได้ช่วย ปัญหานี้ยังถูกนำไปใช้โจมตีได้อยู่ ผมก็ถามตัวเองเหมือนกันว่า ‘มันจะใช้ได้ในสภาพแวดล้อม TPM+PIN ไหม?’ และคำตอบคือได้ แต่ผมจะไม่ปล่อย PoC เพราะผมคิดว่าแค่สิ่งที่เปิดเผยไปแล้วก็มากเกินพอในทางแย่แล้ว”
พูดอีกอย่างคือ ทันทีที่ Paul Le Roux ถูกจับในคดียาเสพติดและการลอบสังหาร แล้วเริ่มให้ความร่วมมือกับทางการ ก็เหมือนมีการชี้นำให้ผู้ใช้ TrueCrypt ไปใช้ ซอฟต์แวร์ที่มีแบ็กดอร์
ตาม Wikipedia, Le Roux ถูกจับในปี 2012 ดังนั้นไทม์ไลน์นี้ดูไม่สอดคล้องกัน
https://news.ycombinator.com/item?id=7812133
ถ้าจะใส่หมวกทฤษฎีสมคบคิดที่ดูมีเหตุผลขึ้นเรื่อย ๆ การร้องขอคีย์จากคลาวด์อาจทิ้งบันทึกร่องรอยไว้ และอาจต้องมีการอนุมัติทางกฎหมายด้วย
หลังติดตั้ง Windows update ช่วงปลายเดือนเมษายน ผมก็ไม่สามารถถอดรหัสโวลุม BitLocker ด้วย PIN ได้อีกเลย recovery code ใช้ได้ แต่ต่อให้รีเซ็ต PIN หลายครั้งก็ยังบอกว่าผิดอยู่เรื่อย ๆ
สุดท้ายหาสาเหตุไม่เจอและลง Windows ใหม่ มันเป็นบั๊กที่น่าหงุดหงิดมาก และก็เป็นเรื่องบังเอิญที่ชวนขำด้วย
ถ้าผมไปโพสต์ที่ไหนสักแห่งว่า ECDSA มีแบ็กดอร์ ก็ไม่ใช่ว่าสำนักที่ไม่หาแต่คลิกจะเอาไปเขียนเป็นข่าว
การสงสัยว่าเป็นแบ็กดอร์โดยเจตนาก็ไม่ถือว่าเป็นการกระโดดสรุปที่เกินไปมากนัก แต่ก็ยังเป็นแค่การคาดเดา
ส่วนที่ยังไม่มีหลักฐานคือคำอ้างว่าสามารถข้าม BitLocker ที่ตั้งค่า PIN แยกไว้ได้ด้วย ซึ่งไม่ได้อยู่ในบทความนี้
คนนี้ดูมีผลงานที่ดีพอสมควรในการหาช่องโหว่ของ Windows ดังนั้นแม้ไม่มี PoC ผมก็คิดว่าเป็นคำกล่าวอ้างที่ควรจับตาดู
เรื่องมันชัดเจนอยู่แล้วว่า สิ่งที่ต้องป้องกันจากการขโมย ห้ามเก็บไว้บน Windows เด็ดขาด อย่าทำธุรกรรมธนาคาร การลงทุน ภาษี อีเมล โฮสติ้ง การช้อปปิ้ง หรือเรื่องส่วนตัวบน Windows
Windows ควรใช้แค่ (i) เล่นเกม และ (ii) ทำบิลด์สำหรับ Windows เท่านั้น
ความคิดเห็นจาก Hacker News
เมื่อดูโพสต์ของนักวิจัยที่ค้นพบช่องโหว่นี้ Nightmare-Eclipse ดูเหมือนว่าเรื่องนี้ดำเนินต่อเนื่องมาตั้งแต่เกือบหนึ่งสัปดาห์ก่อนแล้ว
ในวันอังคารที่ 12 พฤษภาคม 2026 เขาเขียนว่า “คราวนี้มีช่องโหว่สองตัว [YellowKey] [GreenPlasma] [...] วัน Patch Tuesday ครั้งหน้าจะมีเรื่องเซอร์ไพรส์ใหญ่สำหรับ Microsoft” และในวันพุธที่ 13 พฤษภาคมก็เขียนว่า “ถ้าฉันเปิดเผยเรื่องทั้งหมดได้เมื่อไร ผู้คนจะเห็นว่าการระเบิดอารมณ์ของฉันนั้นมีเหตุผลพอสมควร และมันจะไม่ทำให้ Microsoft ดูดีเลย”
บล็อกของผู้เขียน: https://deadeclipse666.blogspot.com/
ในโพสต์แรกเมื่อเดือนมีนาคม 2026 มีข้อความทำนองว่า “มีใครบางคนผิดข้อตกลงของเรา และฉันหมดตัวจนเสียบ้านไปด้วย พวกเขาแทงข้างหลังฉันทั้งที่รู้ว่าจะจบแบบนี้ นี่ไม่ใช่การตัดสินใจของฉัน แต่เป็นของพวกเขา”
ไม่แน่ใจว่าควรมองเรื่องนี้อย่างไร แต่ฟังดูคล้ายคนวงในที่กำลัง “ปล่อยข้อมูล” อยู่ และคนอื่นก็ดูเหมือนจะทำซ้ำผลลัพธ์ได้ด้วย
จะเรียกสิ่งนี้ว่าแบ็กดอร์หรือไม่นั้น สุดท้ายก็ขึ้นอยู่กับว่าปกติคุณมอง “บั๊กหรือแบ็กดอร์” อย่างไร และมันไม่ใช่เรื่องเล่าแบบง่าย ๆ สไตล์สื่อเทคโนโลยีที่ชอบพาดหัวว่า “Microsoft โดน 1, BitLocker ถูกแฮ็ก”
ประเด็นสำคัญคือบั๊กในฟังก์ชัน replay ของ NTFS transaction log ใน Windows Recovery Environment WinRE ซึ่งทำให้สามารถอ่าน NTFS transaction log จากโวลุมภายนอกแล้วนำไปใช้กับไฟล์ซิสเต็มที่ถูกเมานต์อยู่ได้ ส่งผลให้ผู้โจมตีสามารถข้ามการยืนยันตัวตนของ WinRE ได้
สำหรับ BitLocker ที่ไม่มี PIN หรือรหัสผ่าน การข้ามการยืนยันตัวตนใด ๆ ก็ตามก็เท่ากับข้ามการเข้ารหัสดิสก์ เพราะบูตโหลดเดอร์ได้ unseal ดิสก์ไปแล้ว และ “ข้อบกพร่อง” เชิงสถาปัตยกรรมแบบนี้ก็มีอยู่ใน Linux ที่ตั้งค่าแบบเดียวกันด้วย เช่นกรณีใช้ช่องทำเครื่องหมาย Hardware Disk Encryption ที่เพิ่งเพิ่มเข้ามาไม่นานในตัวติดตั้ง Ubuntu
หากไม่มีหลักฐานเพิ่มเติม จะมองปัญหา NTFS transaction log นี้ว่าเป็นแบ็กดอร์ที่ฝังไว้ หรือเป็นแค่บั๊กแบบ enumeration ธรรมดา ก็ขึ้นอยู่กับระดับทฤษฎีสมคบคิดที่พบได้ทั่วไปในการพัฒนา exploit ส่วนตัวผมมองว่ามันเป็นบั๊กที่ดูเป็นไปได้ และจุดอ่อนของการ unseal ตอนบูตก็เป็นเรื่องที่รู้กันดีและชัดเจนอยู่แล้ว จึงไม่คิดว่านี่คือการเปิดโปงที่จะสั่นสะเทือนโลก แต่ก็เป็นบั๊กที่น่าสนใจ
สรุปที่ดีกว่า: https://infosec.exchange/@wdormann/116565129854382214
exploit ที่เผยแพร่ออกมาไม่มีผลกับ BitLocker ที่ใช้ PIN หากไม่มี PIN อยู่แล้ว BitLocker ก็ไม่ปลอดภัยตั้งแต่แรก
ผู้เขียนต้นฉบับอ้างว่าตนมี exploit ที่ใช้ได้แม้มี PIN แต่ยังไม่ได้แสดงหลักฐานในตอนนี้
ผมไม่เคยเห็นบริษัทไหนบังคับใช้ PIN กับ BitLocker เลย
ที่มา: https://infosec.exchange/@wdormann/116565129854382214
“ในเซสชัน WinRE ทั่วไปจะมีไดเรกทอรี X:\Windows\System32 และมีไฟล์ winpeshl.ini อยู่ในนั้น”
“แต่ใน YellowKey exploit ดูเหมือนว่า fragment ของ Transactional NTFS จากไดรฟ์ USB จะสามารถลบไฟล์ winpeshl.ini บนไดรฟ์อื่นได้”
น่าสนใจ ผมไม่ค่อยรู้จักสภาพแวดล้อมนี้ แต่ถ้ามองแบบซื่อ ๆ มันอาจเป็นปัญหาเรื่องการสร้างหรือส่งต่อ file handle หรือเปล่า? ถ้าใช่ แล้วทำไมถึงต้องมีการกดแป้นพิมพ์ระหว่างการรีบูต WinRE?
ผมก็สงสัยด้วยว่าจะออกแพตช์ได้มากแค่ไหน เพราะมีไดรฟ์ USB ของ WinRE จำนวนมากที่คงไปแตะต้องไม่ได้ แล้วฝั่ง BitLocker จะอัปเดตสิทธิ์การเข้าถึงได้ไหม? ต้องถอดรหัส/เข้ารหัสใหม่หรือไม่? ดูเหมือนว่ายังมีอะไรจะตามมาอีกมาก
ดังนั้นการโจมตีนี้จึงต้องใช้ WinRE ไม่ใช่การบูตจากอะไรอย่าง Ubuntu live CD
และก็ไม่จำเป็นต้องแพตช์ USB ไดรฟ์ WinRE ที่มีอยู่ทั้งหมด แค่เพิกถอนลายเซ็น Secure Boot ก็จะทำให้ไม่ผ่านการตรวจสอบของ TPM และจึงไม่สามารถถอดรหัสดิสก์ใด ๆ ได้
“ผู้เชี่ยวชาญด้านความปลอดภัยมักแนะนำว่าไม่ควรพึ่งระบบเข้ารหัสเพียงระบบเดียว และควรประเมินทางเลือก การเข้ารหัสดิสก์ทั้งลูก ที่ผ่านการตรวจสอบมาอย่างดี เช่น VeraCrypt”
ถ้ามีการฝังแบ็กดอร์ใน FDE จริง การบอกให้คนเลิกใช้ Windows ไปใช้ Linux น่าจะสมเหตุสมผลกว่า
ถ้าใส่แบ็กดอร์ไว้ใน FDE ได้ ก็ควรถือว่าคงไม่ได้มีแบ็กดอร์แค่ตัวเดียวในระบบปฏิบัติการด้วย ซอฟต์แวร์ปิดซอร์สไม่ควรถูกเชื่อถือเลย และโอเพนซอร์สที่ยังไม่ได้รับการตรวจสอบอย่างเหมาะสมก็ไม่ควรถูกเชื่อถือเช่นกัน
เรื่องนี้ดูจะใกล้เคียงกับการ ข้ามการล็อกอิน มากกว่าจะเป็นปัญหาเฉพาะของ BitLocker ถ้าใช้ TPM โดยไม่มี PIN มันก็จะถอดรหัสให้อัตโนมัติ
ปกติผู้โจมตีควรจะข้ามหน้าจอล็อกอินไม่ได้อยู่แล้วจึงน่าจะปลอดภัย แต่ exploit นี้ดูเหมือนจะแสดงวิธีได้เชลล์แบบไม่จำกัดสิทธิ์ในสภาพแวดล้อมกู้คืน
นักวิจัยอ้างว่ามีวิธีข้าม PIN ด้วย แต่ยังไม่ได้เผยแพร่
เมื่อไรผู้เชี่ยวชาญด้านความปลอดภัยจะเริ่มปฏิเสธงานสาย “ความปลอดภัยของผลิตภัณฑ์ Microsoft” กันเสียที? สำหรับผมมาถึงจุดนั้นแล้ว
ความปลอดภัยของผลิตภัณฑ์ Microsoft เป็นแค่งานยุ่ง ๆ ไปวัน ๆ จนกว่าจะพังอีกครั้งด้วยคลื่นลูกใหม่ของหนี้เทคนิคสุดบ้าคลั่งและความโลภของ MS ตอนนี้ถึงขั้นมีแบ็กดอร์แล้ว
พอทำตามกฎ compliance ครบหมด และทำตาม “best practice” ที่ได้รับอิทธิพลจาก MS แล้ว ไม่ว่าจะเกิดอะไรขึ้นก็จะไม่กลายเป็นความผิดของตัวเอง
คุณเปิด ADP เพื่อใช้การสำรองข้อมูลแบบเข้ารหัส end-to-end ได้ แต่ก็มักช่วยอะไรไม่ได้มาก เพราะคู่สนทนาของคุณอาจไม่ได้เปิดใช้
ไม่ได้จะปกป้อง Microsoft เพียงแต่จะบอกว่าบริษัทเหล่านี้ล้วนเป็นส่วนหนึ่งของ PRISM
อยากคุยกันไหมว่าทำไมตอนที่ Windows NT เวอร์ชันหนึ่งเคยถูกปล่อยออกมาโดยเผลอเปิด debug symbols เอาไว้ ชื่อคีย์ที่ Microsoft อ้างว่าเป็น “คีย์สำรอง” ถึงได้ชื่อว่า ..._NSAKEY
มีอยู่ครั้งเดียว ครั้งเดียวจริง ๆ ที่ Windows ถูกปล่อยพร้อม debug symbols เปิดอยู่ และบังเอิญชื่อคีย์เข้ารหัสคือ “NSAKEY”
แน่นอนว่าคนที่ยังคงหลับตาให้กับความผิดของรัฐ ก็จะบอกว่านั่นเป็นเรื่องปกติอย่างยิ่ง และท่องคำแก้ตัวที่ Microsoft ตั้งใจสร้างขึ้นในตอนนั้นว่า “มันไม่ใช่แบ็กดอร์” ต่อไป
พอลองขุด exploit นี้เพิ่ม ก็พบว่ามันเจาะ BitLocker ในโหมด TPM-only นั่นคือไม่มีการยืนยันตัวตนก่อนบูตแต่อย่างใด
ถ้า Secure Boot ตรวจสอบเชนการบูตแล้ว TPM ก็จะปล่อยคีย์เข้ารหัสออกมาเอง ดังนั้นหากมีการเข้าถึงทางกายภาพก็แทบไม่ต่างกันมาก
จะบูตจาก USB ที่ใส่ exploit เพื่อเอาเชลล์ฉุกเฉิน หรือจะซื้อไมโครคอนโทรลเลอร์ราคา 5 ดอลลาร์แล้วบัดกรีเข้ากับขาบางจุดบนเมนบอร์ดเพื่อดัก TPM key ก็ทำได้ทั้งนั้น
Microsoft กำลังขายสิ่งที่โดยรวมไม่ปลอดภัย แต่ทำการตลาดว่าเป็น full-disk encryption คนที่สามารถใส่ exploit ลงแฟลชไดรฟ์แล้วเอาเชลล์มาไล่ดูและคัดลอกไฟล์ได้ ก็ย่อมซื้อไมโครคอนโทรลเลอร์แล้วเปิดวิดีโอสอนบัดกรีใน YouTube ทำตามได้เช่นกัน
ดังนั้นปัญหาไม่ใช่ “exploit” เอง แต่คือ ความรู้สึกปลอดภัยปลอม ๆ ที่ Microsoft ขายอยู่
การใช้ไมโครคอนโทรลเลอร์ราคา 5 ดอลลาร์บัดกรีเข้ากับขาบางจุดเพื่อดัก TPM key ทำได้เฉพาะกับ dTPM เท่านั้น ส่วน fTPM ไม่ได้รับผลกระทบแบบนี้ และถูกใช้งานแพร่หลายกว่ามากเมื่อเทียบกับ dTPM
การพิมพ์ passphrase ตอนบูตเป็นความเคยชินระดับกล้ามเนื้อไปแล้ว และให้ความปลอดภัยที่เรียบง่ายและไว้ใจได้
คุณยังสามารถกู้ข้อมูลได้แม้ไม่มีเมนบอร์ด
สำหรับการใช้งานประจำวัน ถ้าใช้แบบไฮบริดที่มีสล็อตซึ่งรวม Secure Boot+TPM+passphrase เพื่อป้องกัน evil maid attack และมีสล็อต passphrase สำรองอีกอันหนึ่ง ก็น่าจะโอเค
https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
นี่ดูจะเป็นการโจมตีต่อ Secure Boot chain มากกว่าจะเป็นการโจมตี BitLocker โดยตรง
คุณค่าของการปลดล็อกโดยไม่มี PIN จะมีเมื่อ threat model จำกัดอยู่แค่การทิ้งดิสก์ การถอดดิสก์ออก หรือการแยก TPM ออกจากดิสก์
หากอุปกรณ์นั้นมีผู้ใช้หลายคนใช้งานเป็นประจำ การให้ป้อน PIN อาจไม่สะดวกหรืออาจเป็นไปไม่ได้ จึงกลายเป็นสถาปัตยกรรมที่ย้ายการตรวจสอบสิทธิ์การเข้าถึงไปยังองค์ประกอบของระบบปฏิบัติการที่เชื่อถือได้
ยังมีใครจำข้อความ “การใช้ TrueCrypt ไม่ปลอดภัยและอาจมีปัญหาด้านความปลอดภัยที่ไม่ได้รับการแก้ไข” ได้ไหม? ;)