2 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักวิจัยด้านความปลอดภัย 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

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

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Hacker News
  • เมื่อดูโพสต์ของนักวิจัยที่ค้นพบช่องโหว่นี้ Nightmare-Eclipse ดูเหมือนว่าเรื่องนี้ดำเนินต่อเนื่องมาตั้งแต่เกือบหนึ่งสัปดาห์ก่อนแล้ว
    ในวันอังคารที่ 12 พฤษภาคม 2026 เขาเขียนว่า “คราวนี้มีช่องโหว่สองตัว [YellowKey] [GreenPlasma] [...] วัน Patch Tuesday ครั้งหน้าจะมีเรื่องเซอร์ไพรส์ใหญ่สำหรับ Microsoft” และในวันพุธที่ 13 พฤษภาคมก็เขียนว่า “ถ้าฉันเปิดเผยเรื่องทั้งหมดได้เมื่อไร ผู้คนจะเห็นว่าการระเบิดอารมณ์ของฉันนั้นมีเหตุผลพอสมควร และมันจะไม่ทำให้ Microsoft ดูดีเลย”
    บล็อกของผู้เขียน: https://deadeclipse666.blogspot.com/
    ในโพสต์แรกเมื่อเดือนมีนาคม 2026 มีข้อความทำนองว่า “มีใครบางคนผิดข้อตกลงของเรา และฉันหมดตัวจนเสียบ้านไปด้วย พวกเขาแทงข้างหลังฉันทั้งที่รู้ว่าจะจบแบบนี้ นี่ไม่ใช่การตัดสินใจของฉัน แต่เป็นของพวกเขา”
    ไม่แน่ใจว่าควรมองเรื่องนี้อย่างไร แต่ฟังดูคล้ายคนวงในที่กำลัง “ปล่อยข้อมูล” อยู่ และคนอื่นก็ดูเหมือนจะทำซ้ำผลลัพธ์ได้ด้วย

    • มากกว่าจะเป็นคนวงใน ดูเหมือนว่าเขากำลังทำ กระบวนการเปิดเผยช่องโหว่ กับ Microsoft อยู่ แล้วไม่ทราบว่าเพราะเหตุใดจึงโกรธจนตัดสินใจเปิดเผยออกมา
    • มีการพูดถึงเรื่องนี้บน HN ไปแล้วหลายครั้ง ตัวอย่างเช่นที่นี่: https://news.ycombinator.com/item?id=48130519
      จะเรียกสิ่งนี้ว่าแบ็กดอร์หรือไม่นั้น สุดท้ายก็ขึ้นอยู่กับว่าปกติคุณมอง “บั๊กหรือแบ็กดอร์” อย่างไร และมันไม่ใช่เรื่องเล่าแบบง่าย ๆ สไตล์สื่อเทคโนโลยีที่ชอบพาดหัวว่า “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 ตอนบูตก็เป็นเรื่องที่รู้กันดีและชัดเจนอยู่แล้ว จึงไม่คิดว่านี่คือการเปิดโปงที่จะสั่นสะเทือนโลก แต่ก็เป็นบั๊กที่น่าสนใจ
    • ผมอยากรีบอ่านโพสต์บล็อกที่อธิบายว่าเกิดอะไรขึ้นกันแน่ และทำไมคนนี้ถึงตัดสินใจ แฉ M$ แบบนี้
  • สรุปที่ดีกว่า: https://infosec.exchange/@wdormann/116565129854382214
    exploit ที่เผยแพร่ออกมาไม่มีผลกับ BitLocker ที่ใช้ PIN หากไม่มี PIN อยู่แล้ว BitLocker ก็ไม่ปลอดภัยตั้งแต่แรก
    ผู้เขียนต้นฉบับอ้างว่าตนมี exploit ที่ใช้ได้แม้มี PIN แต่ยังไม่ได้แสดงหลักฐานในตอนนี้

    • บริษัทของคุณบังคับใช้ PIN หรือไม่? ที่สำคัญกว่านั้นคือบริษัท ประกันภัยไซเบอร์ ที่บริษัทคุณจ่ายเงินให้ บังคับใช้ PIN หรือไม่?
      ผมไม่เคยเห็นบริษัทไหนบังคับใช้ PIN กับ BitLocker เลย
    • BitLocker ยังมีตัวเลือกที่เหนือกว่า PIN อีกขั้น คือใช้ USB stick ที่เก็บคีย์สำหรับใช้เฉพาะตอนบูต เนื่องจากข้อมูลไม่ได้ถูกเก็บอยู่บนอุปกรณ์ จึงน่าจะปลอดภัยจากการโจมตีนี้
    • ถ้าสมมติว่าคำอ้างเรื่องเวอร์ชัน PIN เป็นจริง ก็น่าสนใจว่าทำไมถึงเลือกเปิดเผยเวอร์ชันที่อ่อนกว่าและแทบไม่มีประโยชน์แทน ผมมีความคิดอยู่บ้างแต่ยังไม่มีอะไรเป็นหลักฐาน
  • ที่มา: 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 มีสิทธิ์นั้นอยู่ Windows เก็บ คีย์ถอดรหัสไว้ใน TPM ทำให้ WinRE สามารถถอดรหัสดิสก์ได้แม้ไม่มี recovery key
      ดังนั้นการโจมตีนี้จึงต้องใช้ WinRE ไม่ใช่การบูตจากอะไรอย่าง Ubuntu live CD
      และก็ไม่จำเป็นต้องแพตช์ USB ไดรฟ์ WinRE ที่มีอยู่ทั้งหมด แค่เพิกถอนลายเซ็น Secure Boot ก็จะทำให้ไม่ผ่านการตรวจสอบของ TPM และจึงไม่สามารถถอดรหัสดิสก์ใด ๆ ได้
  • “ผู้เชี่ยวชาญด้านความปลอดภัยมักแนะนำว่าไม่ควรพึ่งระบบเข้ารหัสเพียงระบบเดียว และควรประเมินทางเลือก การเข้ารหัสดิสก์ทั้งลูก ที่ผ่านการตรวจสอบมาอย่างดี เช่น VeraCrypt”
    ถ้ามีการฝังแบ็กดอร์ใน FDE จริง การบอกให้คนเลิกใช้ Windows ไปใช้ Linux น่าจะสมเหตุสมผลกว่า
    ถ้าใส่แบ็กดอร์ไว้ใน FDE ได้ ก็ควรถือว่าคงไม่ได้มีแบ็กดอร์แค่ตัวเดียวในระบบปฏิบัติการด้วย ซอฟต์แวร์ปิดซอร์สไม่ควรถูกเชื่อถือเลย และโอเพนซอร์สที่ยังไม่ได้รับการตรวจสอบอย่างเหมาะสมก็ไม่ควรถูกเชื่อถือเช่นกัน

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

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

    • นั่นไม่ใช่งานสาย “ความปลอดภัย” แต่เป็น งานด้าน compliance ต่างหาก สิ่งเดียวที่ลูกค้าองค์กรส่วนใหญ่สนใจจริง ๆ ก็คือเรื่องนี้
      พอทำตามกฎ compliance ครบหมด และทำตาม “best practice” ที่ได้รับอิทธิพลจาก MS แล้ว ไม่ว่าจะเกิดอะไรขึ้นก็จะไม่กลายเป็นความผิดของตัวเอง
    • iOS ก็สร้าง iCloud backup ที่ไม่ได้เข้ารหัสแบบ end-to-end เป็นค่าปริยายเช่นกัน ทำให้หน่วยงานสืบสวนร้องขอข้อมูลอย่างแชต ประวัติการท่องเว็บ ฯลฯ ได้ โดย Signal เป็นข้อยกเว้นที่หลุดออกไป
      คุณเปิด 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 ขายอยู่

    • วิธี “เข้าเชลล์ฉุกเฉินด้วยแฟลชไดรฟ์ที่บูตได้” ใช้ไม่ได้ TPM จะปล่อยคีย์เฉพาะเมื่อตอนบูตเข้าไปยังระบบปฏิบัติการที่ “ได้รับอนุมัติ” เท่านั้น โดยเฉพาะคือต้องตรงกับ สถานะ PCR ที่คีย์เข้ารหัสถูก bind ไว้
      การใช้ไมโครคอนโทรลเลอร์ราคา 5 ดอลลาร์บัดกรีเข้ากับขาบางจุดเพื่อดัก TPM key ทำได้เฉพาะกับ dTPM เท่านั้น ส่วน fTPM ไม่ได้รับผลกระทบแบบนี้ และถูกใช้งานแพร่หลายกว่ามากเมื่อเทียบกับ dTPM
    • Ubuntu ก็ออก TPM-based FDE มาเมื่อไม่กี่เวอร์ชันก่อน ตอนนั้นผมก็คิดแบบเดียวกันจึงตัดสินใจไม่ใช้
      การพิมพ์ passphrase ตอนบูตเป็นความเคยชินระดับกล้ามเนื้อไปแล้ว และให้ความปลอดภัยที่เรียบง่ายและไว้ใจได้
      คุณยังสามารถกู้ข้อมูลได้แม้ไม่มีเมนบอร์ด
      สำหรับการใช้งานประจำวัน ถ้าใช้แบบไฮบริดที่มีสล็อตซึ่งรวม Secure Boot+TPM+passphrase เพื่อป้องกัน evil maid attack และมีสล็อต passphrase สำรองอีกอันหนึ่ง ก็น่าจะโอเค
    • มีการอ้างว่ามี exploit สำหรับ TPM+PIN ด้วยเช่นกัน แต่ยังต้องรอดูว่าจะน่าเชื่อถือหรือไม่
      https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
    • Linux LUKS ก็สามารถตั้งค่าแบบเดียวกันนี้ได้เป๊ะ
      นี่ดูจะเป็นการโจมตีต่อ Secure Boot chain มากกว่าจะเป็นการโจมตี BitLocker โดยตรง
      คุณค่าของการปลดล็อกโดยไม่มี PIN จะมีเมื่อ threat model จำกัดอยู่แค่การทิ้งดิสก์ การถอดดิสก์ออก หรือการแยก TPM ออกจากดิสก์
      หากอุปกรณ์นั้นมีผู้ใช้หลายคนใช้งานเป็นประจำ การให้ป้อน PIN อาจไม่สะดวกหรืออาจเป็นไปไม่ได้ จึงกลายเป็นสถาปัตยกรรมที่ย้ายการตรวจสอบสิทธิ์การเข้าถึงไปยังองค์ประกอบของระบบปฏิบัติการที่เชื่อถือได้
    • มันเป็นบั๊กที่ร้ายแรงมากก็จริง แต่ BitLocker ก็ยังนับเป็นการเข้ารหัสดิสก์ทั้งลูก เพียงแต่สามารถข้ามการยืนยันตัวตนได้เท่านั้น
  • ยังมีใครจำข้อความ “การใช้ TrueCrypt ไม่ปลอดภัยและอาจมีปัญหาด้านความปลอดภัยที่ไม่ได้รับการแก้ไข” ได้ไหม? ;)

    • เรื่องนี้ทำให้นึกถึง TrueCrypt/VeraCrypt น่าจะเป็นไปได้ว่ามันคือโซลูชันเข้ารหัสที่ปลอดภัยกว่า อย่างน้อยหลังเหตุการณ์นี้ก็ดูปลอดภัยกว่าชัดเจน