Secure Boot เป็นส่วนหนึ่งของระบบนิเวศพีซีมาตั้งแต่ปี 2554 แต่ในที่สุดในปี 2566-2568 ก็ได้รับความสนใจ และไม่ใช่ในลักษณะที่ Microsoft, OEM หรือผู้จำหน่ายเฟิร์มแวร์อาจชอบ สิ่งที่ครั้งหนึ่งเคยเป็นฟีเจอร์ความปลอดภัยเบื้องหลังที่เงียบสงบก็กลายมาเป็นเรื่องราวหน้าแรก แท้จริงแล้ว ในขณะที่ใบรับรอง CA‑2023 เปิดตัว ได้เผยให้เห็นถึงความไม่สอดคล้องที่มีมายาวนานในการใช้งานเฟิร์มแวร์ การจัดการใบรับรอง และไปป์ไลน์การอัปเดตในอุตสาหกรรมพีซี ถ้าจะให้พูดสั้นๆ และโหดร้าย มันไม่สวยและไม่สนุกเลย
สำหรับผู้ใช้ Windows ผลลัพธ์ที่ได้คือการผสมผสานสิ่งที่น่ารำคาญเข้าด้วยกันอย่างสับสน ซึ่งรวมถึงคำเตือนการบูต ห่วงโซ่การบูตที่เสียหาย และคำแนะนำของผู้จำหน่ายที่ไม่สอดคล้องกันหรือไม่สอดคล้องกัน ความรู้สึกทั่วไปที่แพร่หลายก็คือ Secure Boot ซึ่งถูกนำมาใช้เพื่อเพิ่มความน่าเชื่อถือและความน่าเชื่อถือ กลับกลายเป็นที่มาของความไม่แน่นอนและความสับสนแทน
บทความนี้จะเปิดเผยเรื่องราวของ Secure Boot คืออะไร วิธีการทำงาน เหตุใด CA‑2023 จึงมีความสำคัญ ผู้จำหน่ายสะดุดอย่างไร และสิ่งที่ผู้ใช้สามารถทำได้เมื่อการอัปเดต Secure Boot ล้มเหลว ในระหว่างนี้ ฉันจะอธิบายคำย่อทุกคำ อธิบาย Trust Chain ทีละขั้นตอน และเสนอคำแนะนำที่เป็นประโยชน์โดยอิงจากการแก้ไขปัญหาในโลกแห่งความเป็นจริง ฉันเพิ่งเสร็จสิ้นการเดินทางอันแสนทรหดหรือยิ่งใหญ่เพื่อซื้อพีซีขนาดเล็กของฉัน (ขนาดตั้งแต่ 10 ถึง 15) ที่รองรับการบูตที่ปลอดภัยอย่างสมบูรณ์ และทำงานจากใบรับรองการบูต CA 2023 เป็นการเดินทางที่ค่อนข้างนานและสอนฉันมากกว่าที่ฉันอยากรู้
Secure Boot คืออะไร และเหตุใดจึงสำคัญ
Secure Boot เป็นคุณสมบัติที่กำหนดโดย Unified Extensible Firmware Interface (UEFI) ซึ่งเป็นการทดแทน BIOS รุ่นเก่าของ Intel ที่ทันสมัย วัตถุประสงค์คือเพื่อให้แน่ใจว่าเฉพาะบูตโหลดเดอร์และส่วนประกอบระบบปฏิบัติการที่เชื่อถือได้และลงนามแล้วเท่านั้นที่สามารถทำงานได้ในระหว่างการเริ่มต้นระบบ
เพื่อให้บรรลุเป้าหมายนี้ Secure Boot ต้องใช้ชุดคีย์การเข้ารหัสที่จัดเก็บไว้ในเฟิร์มแวร์ คีย์เหล่านี้จะกำหนดว่าอะไรเชื่อถือได้ อะไรได้รับอนุญาต และอะไรคือสิ่งต้องห้ามอย่างชัดเจน
นี่คือองค์ประกอบสำคัญ:
รหัสแพลตฟอร์ม (PK)
คีย์แพลตฟอร์มกำหนดเจ้าของระบบ ใครก็ตามที่ควบคุม PK จะควบคุมการกำหนดค่า Secure Boot โดยปกติแล้ว OEM จะติดตั้ง PK ของตนเองที่โรงงาน
คีย์การแลกเปลี่ยนคีย์ (KEK)
Key Exchange Key อนุญาตให้อัพเดตฐานข้อมูล Secure Boot Microsoft, OEM และบางครั้งผู้ดูแลระบบขององค์กรจะดูแล KEK KEK ที่ถูกต้องคือตั๋วที่อนุญาตให้บุคคลที่สามใช้การอัปเดตกับใบรับรองและฐานข้อมูลที่ดูแลรักษาใน UEFI
ฐานข้อมูลลายเซ็นที่อนุญาต (DB)
ฐานข้อมูลนี้มีแฮชและใบรับรองสำหรับโปรแกรมโหลดบูตที่เชื่อถือได้และส่วนประกอบระบบปฏิบัติการ หากมีบางสิ่งเรียกใช้ลายเซ็นที่มีอยู่ในฐานข้อมูล เฟิร์มแวร์จะอนุญาตให้รันได้
ฐานข้อมูลลายเซ็นต้องห้าม (DBX)
นี่คือ “รายการเพิกถอน” ทุกสิ่งใน DBX จะถูกบล็อกอย่างชัดเจน แม้ว่าครั้งหนึ่งเคยเชื่อถือได้ก็ตาม การอัปเดต DBX คือวิธีที่อุตสาหกรรมเพิกถอนโปรแกรมโหลดบูตที่ถูกบุกรุก CA-2011 ดั้งเดิมได้เริ่มต้น Secure Boot ทั้งหมดแล้ว MS วางแผนที่จะเพิกถอนสิ่งนี้ในภายหลังในปี 2569 CA-2023 จะมาแทนที่และจะค่อยๆ เปิดตัวผ่านการอัปเดต Windows Update และ OEM UEFI อย่างช้าๆ แต่แน่นอน
เหตุใด Secure Boot จึงมีความสำคัญ
Secure Boot ได้รับการออกแบบมาเพื่อหยุดรูทคิท บูทคิท และมัลแวร์ก่อนระบบปฏิบัติการอื่นๆ หากผู้โจมตีสามารถโจมตีห่วงโซ่การบูตได้ พวกเขาสามารถซ่อนจากระบบปฏิบัติการ หลบเลี่ยงการตรวจจับ และรักษาความคงอยู่ได้อย่างไม่มีกำหนด พวกเขาจะกลับมาเรื่อยๆ เพราะพวกเขาทำงานภายนอกและเป็นอิสระจากระบบปฏิบัติการ Secure Boot จะหยุดการกระทำดังกล่าว
ตามทฤษฎีแล้ว Secure Boot เป็นโซลูชั่นที่สะอาดตาและสวยงาม ในทางปฏิบัติ ระบบนิเวศ Secure Boot จะยุ่งเหยิง กระจัดกระจาย และเต็มไปด้วย Edge Case
อย่างไรก็ตาม Secure Boot มีความสำคัญมากกว่าและเป็นไบนารีมากกว่าที่เคย ในด้านบวก เมื่อใช้งานได้ก็จะทำงานได้ดี ในด้านลบ เมื่อเกิดปัญหา อาจเป็นเรื่องที่ท้าทาย ก่อกวน และใช้เวลานาน
การประนีประนอม Secure Boot ที่ทริกเกอร์ CA-2023
ในช่วงต้นปี 2023 Microsoft ได้ประกาศปัญหาด้านความปลอดภัยที่สำคัญซึ่งไบนารี Windows Boot Manager รุ่นเก่าถูกบุกรุกในลักษณะที่อาจทำให้เกิดการข้าม Secure Boot ได้ เพื่อบรรเทาปัญหานี้ บริษัทจึงออกการอัปเดต DBX ใหม่ที่เรียกว่าการเพิกถอน CA-2023 การอัปเดตนี้เพิ่มโปรแกรมโหลดบูตที่มีช่องโหว่ลงในรายการต้องห้าม และให้โปรแกรมโหลดบูตใหม่ที่ลงนามพร้อมใบรับรองที่ตรงกันซึ่งรอดพ้นจากการโจมตีและปัญหาดังกล่าว
เหตุใดสิ่งนี้จึงจำเป็น?
ผู้โจมตีได้ค้นพบวิธีใช้ประโยชน์จาก bootloader รุ่นเก่าเพื่อปิดการใช้งานการป้องกัน Secure Boot การเพิกถอนไบนารีเหล่านั้นได้รับการพิสูจน์แล้วว่าจำเป็นต่อการรักษาความสมบูรณ์ของระบบนิเวศ
ทำไมระบบนี้ถึงพัง?
OEM จำนวนมากมี:
- เฟิร์มแวร์ที่ล้าสมัย
- การจัดการ DB/DBX ที่ไม่สอดคล้องกัน
- ไปป์ไลน์การอัพเดตที่ใช้งานไม่ได้
- การใช้งาน Secure Boot ที่ไม่ได้มาตรฐาน
- ชุดคีย์ไม่สมบูรณ์หรือไม่ถูกต้อง
- เฟิร์มแวร์ที่เพิกเฉยต่อการอัปเดต DBX
- เฟิร์มแวร์ที่ปิดกั้นระบบเมื่อใช้การอัพเดต DBX
กล่าวอีกนัยหนึ่ง การเพิกถอนเผยให้เห็นถึงหนี้ทางเทคนิคเป็นเวลาหลายปี ในหลายกรณี การพยายามอัปเดตก็เพียงพอที่จะส่งผลกระทบต่อพีซี ในกรณีที่ดีที่สุด พีซีที่ได้รับผลกระทบอาจไม่สามารถรีสตาร์ทได้ (วอร์มบูตผ่านตัวเลือก Power > Restart ในเมนู Start) กรณีที่แย่ที่สุด พีซีที่ได้รับผลกระทบอาจไม่สามารถบู๊ตได้ หรือแม้แต่เข้าถึง UEFI หลังจากเปิดเครื่องแล้ว ข่าวร้าย!
โพสต์ผลลัพธ์ CA-2023
ระบบหลายล้านระบบจบลงที่หนึ่งในสถานะเหล่านี้:
- เปิดใช้งาน Secure Boot แต่ไม่ได้บังคับใช้การเพิกถอนจริง
- Secure Boot ถูกปิดใช้งานเนื่องจากการอัพเดตล้มเหลว
- Secure Boot ติดอยู่ใน “โหมดผู้ใช้” ด้วยคีย์ที่ไม่ตรงกัน
- ระบบไม่สามารถบูตได้หลังจากอัพเดต DBX
- เฟิร์มแวร์ที่ปฏิเสธที่จะใช้การอัปเดต CA‑2023 เลย
นี่ไม่ใช่ปัญหาเฉพาะของ Microsoft เท่านั้น มันเป็นความล้มเหลวทั่วทั้งระบบนิเวศ แน่นอนว่าสิ่งนี้ทำให้ Secure Boot กลายเป็นปัญหาสำหรับผู้ใช้ที่มีระบบที่แสดงปัญหาดังกล่าวอย่างน้อยหนึ่งปัญหา ในส่วนของฉันเอง หนึ่งในพีซีที่ใช้ชิป Ryzen 5 ที่ใช้ ASRock B550 Extreme4 ของฉันได้แสดงข้อผิดพลาดเหล่านี้เกือบทั้งหมดหรือทั้งหมด ในที่สุด ฉันก็ต้องเปลี่ยนเมนบอร์ดเพื่อที่จะผ่านมันไป
“Secure Boot Chain” ทำงานอย่างไร
เพื่อให้เข้าใจว่าเหตุใด CA‑2023 จึงก่อปัญหามากมาย การดำเนินการผ่านสายโซ่ความเชื่อถือทีละขั้นตอนจะช่วยได้
ขั้นตอนที่ 1: เฟิร์มแวร์ตรวจสอบ PK
หาก PK ถูกต้อง ระบบจะรู้ว่าใคร “เป็นเจ้าของ” แพลตฟอร์ม
ขั้นตอนที่ 2: เฟิร์มแวร์ตรวจสอบ KEK
คีย์เหล่านี้อนุญาตการอัปเดตไปยัง DB และ DBX
ขั้นตอนที่ 3: เฟิร์มแวร์โหลด DB และ DBX
สิ่งเหล่านี้กำหนดสิ่งที่ได้รับอนุญาตและสิ่งต้องห้าม
ขั้นตอนที่ 4: เฟิร์มแวร์ตรวจสอบ bootloader
หากลายเซ็นของ Bootloader ตรงกับรายการใน DB และไม่ได้อยู่ใน DBX ระบบจะทำงาน
ขั้นตอนที่ 5: Bootloader ตรวจสอบส่วนประกอบของระบบปฏิบัติการ
Windows Boot Manager ตรวจสอบลายเซ็นบน winload.efi ไดรเวอร์ และส่วนประกอบก่อนการบูตอื่นๆ
ขั้นตอนที่ 6: ระบบปฏิบัติการบูทด้วยความไว้วางใจเหมือนเดิม
หากทุกอย่างเรียบร้อยดี Windows จะโหลดได้ตามปกติ
อนิจจา การก้าวหลายๆ ขั้นทำให้เกิดโอกาสที่สิ่งต่างๆ จะก้าวไปข้างทาง นั่นคือสิ่งที่ทำให้แนวทางนี้ค่อนข้างเปราะบางและมีแนวโน้มที่จะวางสายหรือล้มเหลวในบางครั้ง สิ่งต่างๆ อาจเสียหายหรือล้มเหลวได้หากมีกรณีใดกรณีหนึ่งต่อไปนี้:
- DB ไม่มีลายเซ็นที่จำเป็น
- KEK ล้าสมัยแล้ว
- PK ไม่ถูกต้อง
- เฟิร์มแวร์ผิดพลาดในการอัพเดต
- Bootloaders ไม่ตรงกัน (Windows จะเก็บสำเนาแยกต่างหากในลำดับชั้นโฟลเดอร์ C:\Windows ในขณะที่อินสแตนซ์อื่นถูกใช้จากพาร์ติชัน EFI)
หากมีรายการดังกล่าว Secure Boot อาจล้มเหลวหรือถอยกลับ นอกจากนี้ยังอาจล้มเหลวในการบังคับใช้ระบอบการปกครองด้านความปลอดภัยอย่างเงียบๆ ตัวอย่างเช่น ฉันพบว่าตัวเองอยู่ในสถานการณ์ที่การบูตทุกครั้งแสดงข้อความที่รายงาน “การเปลี่ยนแปลง CPU” (อย่างไม่ถูกต้อง) และขอให้ยืนยันปัจจุบันหรือย้อนกลับไปยังการตั้งค่าความปลอดภัย TPM ก่อนหน้า นี่คือสิ่งที่ดูเหมือน:
เป็นลักษณะพิเศษที่ทราบกันดีของ ASRock B550 Extreme4 UEFI ที่จะรายงานการเปลี่ยนแปลงโปรเซสเซอร์แม้ว่าจะมีการเปลี่ยนแปลง Secure Boot หรือการอัปเดตเกิดขึ้นก็ตาม ที่จริงแล้ว ฉันต้องป้อน “N” บนหน้าจอนี้เป็นเวลาประมาณสองสัปดาห์ทุกครั้งที่รีบูทระบบเพื่อไปที่เดสก์ท็อป Windows ทำให้การรีบูตแต่ละครั้งใช้เวลาอย่างน้อย 2-3 นาที และทำให้ฉันรำคาญไม่สิ้นสุด
ปัญหา Secure Boot ทั่วไปในผู้จำหน่ายมาเธอร์บอร์ดหลายราย
การเปิดตัว CA‑2023 เผยให้เห็นว่าผู้จำหน่ายแต่ละรายมีระดับวินัยของเฟิร์มแวร์ที่แตกต่างกันอย่างมาก พีซีเดสก์ท็อปและแล็ปท็อปบางเครื่องใช้งานได้โดยไม่มีปัญหา คนอื่นๆ ประสบปัญหาใดๆ ตั้งแต่ความพ่ายแพ้เล็กๆ น้อยๆ ไปจนถึงปัญหาสำคัญๆ ไปจนถึงระบบที่ไม่สามารถบู๊ตได้ มาดูกันว่าผู้ขายต่างๆ มีอาการอย่างไรในสถานการณ์นี้
อัสซุส
บอร์ด ASUS บางรุ่นปฏิเสธที่จะใช้การอัปเดต DBX เว้นแต่ว่า Secure Boot จะถูกปิดใช้งานชั่วคราว ซึ่งเป็นข้อกำหนดที่ขัดแย้งกัน คนอื่นๆ ใช้การอัปเดตแต่ปล่อยให้ระบบอยู่ในสถานะ “ถูกเพิกถอนครึ่งหนึ่ง” อาจยังคงใช้ใบรับรอง CA-2011 (หรือไม่ใช้) แม้ว่าจะมีใบรับรอง CA-2023 ก็ตาม
เอ็มไอ
- บอร์ด MSI บางรุ่น (แต่ไม่ใช่ทั้งหมด) มีชื่อเสียงในด้าน:
- การจัดการ DBX ที่ไม่สอดคล้องกัน
- เฟิร์มแวร์ที่เพิกเฉยต่อการอัปเดต
- โหมด Secure Boot ที่ไม่ตรงกับป้ายกำกับ UI
- ระบบที่เปลี่ยนกลับเป็นคีย์โรงงานโดยไม่คาดคิด
เอเอสร็อค
บอร์ด ASRock มักต้องการการแทรกแซงด้วยตนเองสำหรับสิ่งต่างๆ เช่น:
- การล้างกุญแจ
- ติดตั้งค่าเริ่มต้นจากโรงงานใหม่
- การลงทะเบียนคีย์ Microsoft อีกครั้ง
- ใช้การอัปเดต DBX ด้วยตนเอง
เอกสารของพวกเขามีไม่มากนัก และผู้ใช้หลายคนยังต้องเดาอยู่ ในกรณีของฉันเอง ฉันมีเมนบอร์ดสองตัวที่น่าจะเหมือนกัน โดยเป็นรุ่น B550 Extreme4 ทั้งสองรุ่น หนึ่งในนั้นยอมจำนนต่อการอัปเดตด้วยตนเองและ Microsoft WU ได้จัดเตรียมการอัปเดต อีกฝ่ายไม่สามารถปรับการอัปเดตที่รอดำเนินการจากระบบปฏิบัติการ (ทั้ง WU และนำไปใช้ด้วยตนเอง) กับเนื้อหาของฐานข้อมูลเฟิร์มแวร์ต่างๆ อันที่จริงนั่นคือสิ่งที่กระตุ้นให้เกิดชุดคำเตือน “การเปลี่ยนแปลง CPU” อย่างต่อเนื่องซึ่งปรากฎในส่วนที่แล้วของเรื่องราวนี้
Dell, HP, Lenovo (และ OEM อื่นๆ…)
ผู้จำหน่ายพีซีและแล็ปท็อปสำหรับองค์กรและผู้บริโภค (รวมถึง Acer, ASUS, Dynabook ฯลฯ) โดยทั่วไปทำได้ดีกว่า แต่ก็มี:
- การเปิดตัวแบบเซ
- ระยะเวลาการอัพเดต BIOS/UEFI ไม่สอดคล้องกัน
- บางระบบที่ต้องรีบูตหลายครั้งเพื่อใช้การเปลี่ยนแปลง DBX
ขณะที่ฉันอ่านโพสต์ในฟอรัมที่ answer.microsoft.com, TenForums.com, ElevenForum.com และ TechPowerUp.com ฉันเห็นกระทู้ในฟอรัมหลายร้อยรายการที่ต้องการความช่วยเหลือในการจัดการกับปัญหา Secure Boot แล็ปท็อปจำนวนมากที่เกี่ยวข้อง และเดสก์ท็อปที่เกี่ยวข้องอีกมากมาย โดยเฉพาะอย่างยิ่งการผลิตเบียร์เองที่บ้านหรือจากผู้สร้างร้านบูติกที่ประกอบชิ้นส่วนเชิงพาณิชย์ที่ดีที่สุดเพื่อสร้างพีซีตามความต้องการสำหรับผู้ซื้อที่มีฐานะดี (ดูหัวข้อถัดไป)
พีซีที่สร้างขึ้นเอง
มาเธอร์บอร์ดจากผู้ขายรายเดียวกันอาจมีพฤติกรรมแตกต่างออกไป ขึ้นอยู่กับ:
- ติดตั้งชิปเซ็ตจริงแล้ว
- สาขาเฟิร์มแวร์
- ปีที่วางจำหน่าย
- OEM เทียบกับ SKU ขายปลีก
โดยรวมแล้วยังขาดมาตรฐานที่ชัดเจน ปัญหา Secure Boot ที่ผู้ใช้พบมีอยู่ทั่วทุกที่ ในที่สุดบางคนก็ยอมจำนนต่อ Windows Update หรือการเปลี่ยนแปลงด้วยตนเอง คนอื่น ๆ ต่อต้านความพยายามในการซ่อมแซมหรือแก้ไขอย่างดื้อรั้น โดยส่วนตัวแล้วฉันเคยผ่านพื้นที่ของปัญหานี้มาแล้ว โดยที่ความล้มเหลวเพิ่งเข้ามาแทนที่ความสำเร็จ (แต่ก็ล้มเหลวเช่นกัน)
ผู้ใช้จะทำอะไรได้บ้างหากการอัปเดต Secure Boot ล้มเหลว
มีหลายวิธีที่ทำให้ Secure Boot ล้มเหลวได้ การอัปเดต Windows อาจรายงานความสำเร็จ แต่ DBX (รายการเพิกถอน) ไม่เคยเปลี่ยนแปลง เฟิร์มแวร์อาจรายงานว่า Secure Boot “เปิดใช้งาน” แต่ไม่ได้ถูกบังคับใช้ (PowerShell ยืนยัน-SecureBootUEFI จะรายงานเท็จในกรณีนั้น)
ระบบอาจบู๊ตแต่ไม่ผ่านการตรวจสอบการปฏิบัติตามข้อกำหนด (ดูส่วนสคริปต์ Garlin ภายหลังในเรื่องนี้สำหรับรายละเอียดเพิ่มเติม) Bootloaders อาจไม่ตรงกับรายการ DB หรือระบบอาจบู๊ตอย่างไม่เต็มใจหรือไม่ได้เลยหลังจากการอัพเดต (เหมือนที่เกิดขึ้นกับระบบ ASRock B550 Extreme4 ของฉัน) มีอะไรเกิดขึ้นมากมายที่นี่ ดังนั้นจึงมีหลายสิ่งที่ต้องลองหากจำเป็นต้องแก้ไข มาดูรายการสาเหตุที่อาจฉุนเฉียวและการแก้ไขที่เกี่ยวข้องกัน
คีย์ไม่ตรงกัน (PK/KEK/DB/DBX)
หาก PK หรือ KEK ล้าสมัย เฟิร์มแวร์อาจปฏิเสธการอัปเดตฐานข้อมูลในรายการข้อมูลประจำตัวและค่าที่ถูกต้อง (DB) หรือรายการที่ถูกเพิกถอน (DBX) หากเป็นเช่นนั้น ก็คุ้มค่าที่จะลองแก้ไขอย่างใดอย่างหนึ่งหรือทั้งหมดเหล่านี้:
- รีเซ็ตเป็นคีย์จากโรงงานหรือค่าเริ่มต้น (โดยปกติจะมีให้ใช้งานเป็นการดำเนินการที่เลือกได้ใน UEFI เมื่อ Secure Boot อยู่ในโหมดกำหนดเอง)
- ลงทะเบียนคีย์ Microsoft อีกครั้ง (โดยปกติจะต้องใช้การอัปเดตของ Microsoft อีกครั้ง ซึ่งต้องมีการถอนการติดตั้ง/ติดตั้งใหม่ ซึ่งอาจดำเนินการผ่าน DISM—WU เสนอการย้อนกลับแบบจำกัดเวลา)
เฟิร์มแวร์ละเว้นการอัปเดต DB หรือ DBX
ในพีซีและแล็ปท็อปบางรุ่น UEFI จะไม่ใช้การอัปเดต DB หรือ DBX ยกเว้นภายใต้เงื่อนไขบางประการ อาจจำเป็นต้องปิดการใช้งาน Secure Boot ต้องปิดโมดูลสนับสนุนความเข้ากันได้ (CSM ซึ่งเปิดใช้งาน “บูตคู่” ในโหมด BIOS หรือ UEFI พีซีสมัยใหม่จะใช้เฉพาะ UEFI เท่านั้น แต่รุ่นเก่ามักใช้ทั้งสองวิธี) จะต้องปิด บางครั้ง จะต้องล้างคีย์ Secure Boot (ตัวเลือก UEFI อื่น) จะต้องถูกล้างก่อนที่จะทำการอัพเดต อาจจำเป็นต้องมีการทดลองเพื่อดูว่าอะไรคืออะไร หากคุณโชคดี คุณจะพบข้อมูลจากนักสำรวจผู้กล้าหาญคนอื่นๆ ที่ได้เห็นและแก้ไขปัญหาเฉพาะของคุณแล้ว
Bootloaders ที่ล้าสมัย
สื่อการติดตั้ง Windows รุ่นเก่าหรือดิสก์ซ่อมแซม/กู้คืนอาจรวมโปรแกรมโหลดบูตที่เก่าเกินไปที่จะทำงานกับ Secure Boot อันที่จริงความไม่ตรงกันนี้จะเกิดขึ้นเร็วขึ้นในปี 2569 หลังจากที่ Microsoft เจาะลึกมากขึ้นในการเพิกถอน CA-2011 (ซึ่งเป็นสิ่งที่ bootloaders รุ่นเก่าส่วนใหญ่รวมไว้) หาก bootloader เก่าเกินไป DBX อาจบล็อกมัน การแก้ไขค่อนข้างตรงไปตรงมาเนื่องจากโปรแกรมโหลดบูตไม่โต้ตอบกับเฟิร์มแวร์ (UEFI) ลองซ่อมแซมต่อไปนี้ในกรณีนี้:
- เรียกใช้ Windows Update: อาจแทนที่ bootloader ที่ล้าสมัยด้วยอันปัจจุบัน
- สร้างไฟล์บูตใหม่โดยใช้ยูทิลิตี้ bcdboot
- ตรวจสอบให้แน่ใจว่าพาร์ติชัน EFI นั้นแข็งแรง (และสร้างใหม่หากไม่ใช่)
ข้อบกพร่องของเฟิร์มแวร์หรือสิ่งแปลกประหลาด
โดยเฉพาะอย่างยิ่งในพีซีรุ่นเก่า เป็นความคิดที่ดีที่จะอัปเดต (แฟลช) UEFI ก่อนที่จะเข้าสู่ Secure Boot สำหรับพีซีที่เก่าพอ การอัปเดตในปี 2023 และใหม่กว่าอาจไม่มีอยู่จริง But for systems that require multiple reboots, specific firmware versions, or manual Secure Boot database (DB, DBX) imports, a few techniques will be helpful:
- อัปเดตเฟิร์มแวร์เป็นเวอร์ชันเสถียรล่าสุด (พิจารณารุ่นเบต้าเฉพาะในกรณีที่ตัวเลือกอื่น ๆ ทั้งหมดล้มเหลว: คุณไม่ต้องการแลกเปลี่ยนสาเหตุที่ทำให้เกิดความไม่เสถียรประการหนึ่งกับอีกสาเหตุหนึ่ง)
- หากมีให้ใช้แคปซูลหรืออัปเดตที่ผู้จำหน่ายจัดหาเพื่อใช้การเปลี่ยนแปลงฐานข้อมูล Secure Boot (เช่น MSI MAG Tomahawk ของฉันทำงานไม่ถูกต้องจนกว่าฉันจะแฟลช UEFI ซึ่งมีองค์ประกอบ Secure Boot และ CA-2023 ในตัว)
- ปล่อยให้ Windows Update ดำเนินการหลังจากที่เฟิร์มแวร์เป็นปัจจุบันแล้วเท่านั้น: การอัปเดตใหม่และเฟิร์มแวร์เก่าทำให้เกิดสภาพแวดล้อมที่ผันผวนและมีแนวโน้มที่จะเกิดปัญหา ตามที่ฉันได้เรียนรู้จาก ASRock B550 Extreme4 build
โดยรวมแล้ว หากผู้ใช้พยายามปฏิบัติตามข้อกำหนด Secure Boot ตั้งแต่การอัปเดตเฟิร์มแวร์ไปจนถึงการอัปเดต Windows และเข้าสู่การดำเนินการ UEFI ด้วยตนเองเฉพาะในกรณีที่จำเป็น พวกเขามีโอกาสน้อยมากที่จะติดอยู่ในหลุมตามถนนสายนั้น
สคริปต์ช่วยแก้ปัญหาการอัปเดต Secure Boot ได้อย่างไร
การพัฒนาที่น่าสนใจที่สุดบางส่วนระหว่างการเปิดตัว CA-2023 คือการเกิดขึ้นของเครื่องมือและการวินิจฉัยที่ขับเคลื่อนโดยชุมชน โดยเฉพาะอย่างยิ่ง ผู้ใช้ Eleven Forum VIP และ Guru Garlin ได้จัดทำเธรดมากกว่า 50 หน้าพร้อมสคริปต์ PowerShell ที่มีประโยชน์ และสำรองข้อมูลด้วยการสนับสนุนและการสนทนาที่มีประโยชน์อย่างเหลือเชื่อ สคริปต์ของเขาทำดังต่อไปนี้:
- ระบุคีย์ Secure Boot
- ตรวจสอบรายการ DB/DBX
- ตรวจจับความไม่ตรงกัน
- ระบุ bootloaders ที่ล้าสมัย
- ตรวจสอบสถานะการบังคับใช้
- สร้างรายงานโดยละเอียด
สำหรับผู้ใช้จำนวนมาก สคริปต์ของ Garlin ถือเป็นหน้าต่างแรกที่ชัดเจนว่าเฟิร์มแวร์ของตนกำลังทำอะไรอยู่ เพื่อเป็นการแสดงให้เห็นสิ่งที่สคริปต์ Garlin ส่องสว่าง รูปที่ 1 แสดงผลลัพธ์ของสคริปต์ของเขาชื่อ Check_UEFI-CA2023.ps1 ซึ่งบันทึกจากเดสก์ท็อป MSI MAG Tomahawk B550 ที่เพิ่งสร้างใหม่ของฉัน:
การตรวจสอบภาพหน้าจอด้านบนอย่างละเอียดแสดงให้เห็นว่าพีซีมีทั้งคีย์การแลกเปลี่ยนคีย์ (KEK) ของ CA 2011 และ CA 2023 ติดตั้งอยู่ พร้อมด้วยใบรับรอง DB สำหรับ UEFI CA 2011, Windows PCA 2011 และ CA 2023 สามรสชาติ รายการใบรับรอง DBX ว่างเปล่า (หากคุณดูด้านล่าง คุณจะเห็นว่า CA 2011 ยังไม่ถูกเพิกถอน เมื่อสิ่งนั้นเกิดขึ้น รายการเหล่านั้นควรย้าย ที่นี่)
ไฟล์ EFI แสดงว่าตัวจัดการการบูตอนุญาต UEFI CA 2023 เช่นเดียวกับรีจิสทรี และมีนโยบายความสมบูรณ์ของโค้ด Secure Boot ล่าสุด MS ใช้นโยบายนี้เพื่อบล็อกไบนารีที่มีความสำคัญต่อการบูตที่มีช่องโหว่หรือไวต่อการย้อนกลับ โดยเฉพาะอย่างยิ่งสำหรับ Virtualization Based Security (VBS ดังที่กล่าวไว้ในรายการที่สองในผลลัพธ์โดยรวมของสคริปต์)
สุดท้าย เอาต์พุตสคริปต์แสดงว่าใบรับรอง CA-2011 แบบเก่ายังไม่ถูกเพิกถอน เป็นเรื่องที่จงใจ: ฉันกำลังรอดูว่า Microsoft จะจัดการเรื่องนี้อย่างไรและเมื่อใดผ่าน Windows Update ตามที่พวกเขาสัญญาว่าจะดำเนินการในช่วงครึ่งหลังของปี 2569 เราจะมาดูกันว่าผลจะเป็นอย่างไร…
เหตุใดสคริปต์เหล่านี้จึงมีความสำคัญ
ผู้จำหน่ายไม่ค่อยเปิดเผยสถานะ Secure Boot เต็มรูปแบบของพีซี Windows พื้นผิวเพียงส่วนหนึ่งของภาพนี้ UI เฟิร์มแวร์ไม่สอดคล้องกันและมักจะเรียกสิ่งเดียวกันด้วยชื่อที่ต่างกัน สคริปต์ของ Garlin แสดงให้เราเห็นว่าเกิดอะไรขึ้นภายใน Secure Boot Sphere และบอกเราว่าต้องดำเนินการอะไรบ้างเพื่อให้กระบวนการอัปเดตและติดตามโดยรวมเสร็จสมบูรณ์
จะทำอย่างไรเมื่อ Secure Boot ไม่ใช้การอัปเดต
ต่อไปนี้เป็นขั้นตอนการกู้คืนที่ใช้งานได้จริงทีละขั้นตอน
ขั้นตอนที่ 1: ตรวจสอบสถานะปัจจุบัน
ใช้สคริปต์ของ PowerShell หรือ Garlin เพื่อตรวจสอบ:
- พีเค
- เคเค
- ดีบี
- DBX
- สถานะการบังคับใช้
- เวอร์ชัน Bootloader
ขั้นตอนที่ 2: อัปเดตเฟิร์มแวร์
ติดตั้งอัพเดต BIOS/UEFI ล่าสุด
ขั้นตอนที่ 3: รีเซ็ตคีย์เป็นค่าเริ่มต้นจากโรงงาน
ปิดใช้งาน Secure Boot ตั้งค่าโหมดเป็นกำหนดเอง จากนั้นรีเซ็ตหรือติดตั้งคีย์เริ่มต้นจากโรงงาน (UEFI ที่แตกต่างกันใช้คำศัพท์ที่แตกต่างกัน) ไม่ว่าพวกเขาจะเรียกมันว่าอะไร สิ่งนี้มักจะช่วยล้างข้อมูลที่ไม่ตรงกัน
ขั้นตอนที่ 4: เปิดใช้งาน Secure Boot อีกครั้ง
ตรวจสอบให้แน่ใจว่า CSM ถูกปิดใช้งาน (มักจะเปิดขึ้นเมื่อมีการอัปเดต UEFI โดยจะต้องปิดจึงจะเปิดใช้งาน Secure Boot)
ขั้นตอนที่ 5: ใช้การอัปเดต DBX
ใช้ Windows Update หรือแคปซูลผู้จำหน่ายตามที่มี ตรวจสอบหน้าสนับสนุนของผู้จำหน่ายระบบ (หรือมาเธอร์บอร์ด) เพื่อค้นหา UEFI และการอัปเดตที่เกี่ยวข้อง นั่นคือสิ่งที่ได้ผลสำหรับเมนบอร์ด MSI MAG Tomahawk B550 ของฉัน
ขั้นตอนที่ 6: สร้างไฟล์บูตใหม่ (หากจำเป็น)
คุณสามารถใช้คำสั่งในตัวเพื่อสร้างไฟล์สำหรับบูตของคุณขึ้นมาใหม่ได้โดยการรันคำสั่ง bcdboot C:\Windows/f UEFI บางครั้ง อาจจำเป็นต้องบูตไปที่ดิสก์ซ่อมแซมหรือช่วยเหลือ และเรียกใช้จากสภาพแวดล้อม Windows Recovery (WinRE) จะปลอดภัยกว่าเสมอหากใช้แนวทางนี้ และจะช่วยให้คุณพ้นปัญหาการบูตที่ผ่านมา หรือการบล็อกนโยบายการบูตแบบปลอดภัย หากปัญหาดังกล่าวปรากฏขึ้นและเมื่อใด
ขั้นตอนที่ 7: ตรวจสอบสถานะอีกครั้ง
ยืนยันว่า DBX มีรายการ CA 2023 แน่นอนว่านี่เป็นเวลาที่ดีที่จะเรียกใช้สคริปต์ Check_UEFI-CA2023.ps1 ของ Garlin (หมายเหตุ: หากคุณดูในหน้าต่างคุณสมบัติของไฟล์และเลือกตัวเลือก Unblock คุณสามารถเรียกใช้สคริปต์นี้ใน PowerShell ได้โดยไม่ต้องเปลี่ยนหรือข้ามนโยบายการดำเนินการในเครื่อง ซึ่งแสดงไว้ในภาพหน้าจอด้านล่าง)
IMO, Secure Boot Ecosystem ต้องการการปฏิรูป
การเปิดตัว CA 2023 อย่างค่อยเป็นค่อยไปและความพยายามล่าสุดในการตรวจจับระบบที่สอดคล้องกับข้อกำหนด Secure Boot ในปัจจุบันนั้นน่าสนใจ แต่ยังได้เผยให้เห็นถึงปัญหาและปัญหาเชิงระบบมากมาย ประการหนึ่ง ผู้จำหน่ายเฟิร์มแวร์ขาดการใช้งานและคำศัพท์เฉพาะทางที่สอดคล้องกัน ดังนั้นจึงตกเป็นหน้าที่ของผู้เชี่ยวชาญด้านไอทีและผู้ติดตั้งอื่นๆ ในการทำงาน เพื่อทำให้สิ่งต่าง ๆ รุนแรงขึ้น เอกสารมักจะไม่ดี และไม่สามารถแก้ไขการแก้ไขเมื่อสิ่งต่าง ๆ เสียหายหรือทำงานไม่ถูกต้อง
ขณะนี้ไปป์ไลน์การอัปเดตมีความเปราะบาง ข้อผิดพลาดประการหนึ่ง (เช่น การไม่ตั้งค่า Secure Boot เป็นโหมดกำหนดเองก่อนที่จะพยายามติดตั้งคีย์เริ่มต้นใหม่) อาจทำให้กระบวนการอัปเดตติดขัด และอาจรบกวนลักษณะการทำงานของการบูตตามปกติ บนเดสก์ท็อป ASRock เครื่องใดเครื่องหนึ่งของฉัน ฉันไม่สามารถรีสตาร์ทพีซีเครื่องนั้นได้ตามปกติ และทำได้เพียงใช้การบู๊ตแบบลึกและเย็นเพื่อเข้าสู่ UEFI หรือดำเนินการตลอดวงจรการบูต (ซึ่งกินเวลาสองสัปดาห์ก่อนที่ฉันจะเปลี่ยนเมนบอร์ดเพื่อให้สิ่งต่าง ๆ ทำงานได้ตามปกติอีกครั้ง) สิ่งนี้ยังทำให้ฉันสังเกตเห็นว่า OEM และผู้จำหน่ายมาเธอร์บอร์ดมีคุณภาพที่แตกต่างกันอย่างมากในการใช้งานและการจัดการ Secure Boot ในเวลาเดียวกันกับที่ ASRock mobo กำลังทำให้ฉันบ้าคลั่ง ฉันก็ไม่มีปัญหากับระบบ Lenovo ใด ๆ ของฉัน (บางรุ่นย้อนหลังไปถึงปี 2018) หรือมินิพีซีของ Dell หรือแล็ปท็อป ASUS Snapdragon ของฉันเช่นกัน
สิ่งที่ฉันได้เรียนรู้ระหว่างกระบวนการนี้คือ Secure Boot นั้นแข็งแกร่งพอๆ กับลิงก์ที่อ่อนแอที่สุดเท่านั้น อนิจจา บางระบบมีลิงก์ที่อ่อนแอ ลิงก์ที่อ่อนแอจำนวนมากเปลี่ยนสิ่งที่ควรเป็นการอัปเดตเป็นประจำให้กลายเป็นการต่อสู้ บางส่วนอาจต้องใช้มาตรการที่รุนแรงกว่านี้ เช่น การเปลี่ยนระบบหรือการเปลี่ยนเมนบอร์ด
สิ่งที่ Microsoft, OEM และผู้ใช้ต้องทำ
เด็กทุกคนในสนามเด็กเล่นแห่งนี้จำเป็นต้องทำบางสิ่งเพื่อปรับปรุง Secure Boot morass ในปัจจุบัน ในความคิดของฉัน นี่คือสิ่งที่ทำให้เกิดความสั่นไหวใน Microsoft, OEM และชุมชนผู้ใช้ ประการแรก Microsoft ควรบังคับใช้การรับรองที่เข้มงวดยิ่งขึ้น ด้วยการวินิจฉัยที่ได้รับการปรับปรุงและเครื่องมือที่ดีกว่า (สคริปต์ของ Garlin ค่อนข้างตรงไปตรงมาเมื่อเข้าใจถึงปัญหาหลังเหตุการณ์ ไม่มีเหตุผลใดที่ MS ไม่สามารถเสนอการใช้งานที่สวยงามกว่านี้เพื่อช่วยสิ่งต่าง ๆ ไปได้)
ถัดไป OEM สามารถทำอะไรได้มากมายเพื่อสร้างมาตรฐานพฤติกรรมของเฟิร์มแวร์และใช้คำศัพท์ที่สอดคล้องกัน พวกเขาสามารถทดสอบการอัปเดต DB ได้อย่างละเอียดมากขึ้นเรื่อยๆ และให้ข้อมูลเชิงลึกและความชัดเจนมากขึ้นเกี่ยวกับสถานะ Secure Boot และค่าต่างๆ ในอินเทอร์เฟซ UEFI เครื่องมือย้อนกลับอัตโนมัติที่มีประสิทธิภาพจะช่วยยกเลิกตัวเลือกที่ไม่ถูกต้องหรือไม่ถูกต้อง
และสุดท้าย ผู้ใช้ควรให้ความสำคัญกับความปลอดภัยมากขึ้น นี่หมายถึงการอัปเดตเฟิร์มแวร์เมื่อมีการอัปเดตใหม่ และการแก้ปัญหาเพื่อใช้ (ไม่ปิดใช้งาน) Secure Boot ยกเว้นเมื่อการติดตั้ง การเปลี่ยนแปลงการกำหนดค่า หรือการอัปเดตต้องการให้ปิด (ชั่วคราว) ผู้ใช้ควรตรวจสอบฐานข้อมูล Secure Boot เป็นระยะๆ เพื่อให้แน่ใจว่าเป็นปัจจุบันและถูกต้อง และตรวจสอบให้แน่ใจว่าพาร์ติชั่น EFI นั้นแข็งแรงและเป็นปัจจุบัน
หากทุกคนทำในส่วนของตน Secure Boot ก็สามารถทำหน้าที่ปกป้องระบบจากการบูตและการประนีประนอมและการโจมตีระดับรูทได้ นั่นค่อนข้างสำคัญ ดังนั้นฉันคิดว่ามันคุ้มค่าที่จะทำ
Secure Boot ยังคงมีความสำคัญ แต่จำเป็นต้องปรับปรุง
Secure Boot ยังคงเป็นกลไกการป้องกันที่สำคัญในรูปแบบการรักษาความปลอดภัยของ Windows แต่ตำนาน CA 2023 แสดงให้เห็นว่าระบบนิเวศนี้เปราะบาง ไม่สอดคล้องกัน และเกินกำหนดสำหรับการปรับปรุงให้ทันสมัย ข่าวดีก็คือว่าอุตสาหกรรมกำลังเรียนรู้ ผู้จำหน่ายเฟิร์มแวร์กำลังปรับปรุง Microsoft กำลังเข้มงวดข้อกำหนด เครื่องมือชุมชนกำลังเติมเต็มช่องว่าง แต่บทเรียนนั้นชัดเจน: ความไว้วางใจไม่ใช่สิ่งที่ทำให้ลืมมันไป ความน่าเชื่อถือจะต้องได้รับการบำรุงรักษา ตรวจสอบ และซ่อมแซมเป็นครั้งคราว Secure Boot ก็ไม่มีข้อยกเว้น
คำแนะนำปิดของฉันคือการดูเวลาในขณะที่คุณทำงานเพื่อแก้ไขปัญหา Secure Boot หากปัญหาเกิดขึ้น หากปัญหาใช้เวลาแก้ไขครึ่งวัน ก็ถือว่าพอทนได้ หากนานกว่านั้นก็ถึงเวลาที่จะเริ่มคิดถึงทางเลือกอื่น วิธีแก้ไขปัญหาชั่วคราว และการทดแทน ขณะที่คุณกำลังคิด คุณสามารถปิด Secure Boot ได้ เนื่องจาก Windows ยังคงใช้งานได้หากไม่มี แต่คุณอาจตัดสินใจเปลี่ยนส่วนประกอบฮาร์ดแวร์ที่ค้างและค้างอยู่เหมือนอย่างฉัน แทนที่จะต่อสู้ต่อไปโดยไม่เห็นวิธีแก้ปัญหาที่แน่นอน มันขึ้นอยู่กับคุณ!
บ้าน
แบ่งปัน
จดหมายข่าว
จดหมายข่าว WL
จดหมายข่าว WL!
ก้าวล้ำหน้าด้วยการอัปเดต Windows, IT และ AI ล่าสุด ได้รับความไว้วางใจจากสมาชิกมากกว่า 50,000 ราย
ชื่อ
อีเมล
เข้าร่วมฟรี
*️⃣ ลิงค์ที่มา:
เปิดตัวใบรับรอง CA‑2023 แล้ว เธรดมากกว่า 50 หน้า , หน้าแรก , จดหมายข่าว ,