노하드(PXE) + Secure Boot 동시 달성 가이드: shim·서명·DHCP 실현가능?

4

요약

Secure Boot를 켜면 서명되지 않은 PXE 부팅 로더가 차단됩니다.
해법은 1) 마이크로소프트 서명 shim 사용, 2) 자체 서명 키 등록,
3) 서명된 부트 체인(shim → grub/ipxe → 커널/부트로더) 확립입니다.
DHCP/TFTP/HTTPBoot 경로를 재정의하면 노하드와 보안을 함께 달성합니다.
키 저장소(db/dbx/KEK/PK)와 2025년 갱신 키 호환성을 반드시 점검합니다.
날짜 기준: 2025-10-13 환경 기준으로 검증한 실무 체크리스트를 제공합니다.

본문

문제 정의: 노하드(PXE) 환경에서 Secure Boot를 활성화하면 UEFI 펌웨어가
네트워크로 내려받은 부팅 로더(예: ipxe.efi, grubx64.efi)가 신뢰되지 않아
즉시 차단됩니다. 이는 UEFI Secure Boot가 db(dbx)의 신뢰·폐기 목록에 따라
로더의 서명을 검증하기 때문입니다. 해결 핵심은 '신뢰 가능한 첫 단계'를
네트워크로 전달하고, 이후 단계의 로더·커널까지 모두 서명 체인에 편입하는
것입니다. 실무에선 shimx64.efi(마이크로소프트 서명)를 NBP로 배포하고,
shim이 허용한 키(MOK/배포자 키)로 다음 로더(grubx64.efi 또는 ipxe.efi)를
검증·구동하도록 체인을 구성합니다.

체크리스트(아키텍처 선택)

• 1) 윈도우 배포형: wdsmgfw.efi(서명됨) → 부팅 메뉴 → WIM/PE 로드
  
• 2) 리눅스/커스텀형: shimx64.efi(서명됨) → grubx64.efi → 커널/Initrd
  
• 3) iPXE 연계형: shimx64.efi → grubx64.efi → (서명된) ipxe.efi 체인
  
• 4) HTTPBoot 병행: DHCP가 bootfile-url로 shim/bootx64.efi를 지정
  

문제 원인

1) 직접 원인: ipxe.efi·grubx64.efi가 마이크로소프트 UEFI CA 또는 db에
등록된 키로 서명되지 않음. dbx(폐기 목록)에 의해 과거 서명물이 차단됨
2) 간접 원인: 구형 펌웨어의 KEK/db가 2023년 이후 키 체계와 불일치
3) 환경 제약: CSM·레거시 PXE 의존, 보안 부팅 체인과 충돌, 구형 드라이버

해결 방법

1) 즉시 조치: UEFI Only·CSM Off로 전환하고, NBP를 shimx64.efi로 지정
DHCP Option 67(또는 HTTPBoot의 bootfile-url)을 shim 경로로 변경합니다.
2) 근본 조치: 키·서명 체인 확립
a) 배포 키 생성(개인/조직용) 후 grubx64.efi·ipxe.efi·커널을 이 키로 서명
b) MOK(머신 오너 키) 등록 또는 펌웨어 db에 배포자 키를 등록해 신뢰 확보
c) dbx 업데이트로 취약 서명물 차단 상태를 최신으로 유지합니다.
3) 대안 경로: 윈도우 배포는 wdsmgfw.efi 사용(기본 서명), 리눅스/커스텀은
shimx64.efi → grubx64.efi 체인으로 이행. iPXE는 grub에서 체인로딩합니다.

구성 절차(리눅스/커스텀형 예시)

1) 키 준비: 배포자용 X.509 키 쌍 생성(PE/COFF 서명용), 공개키를 MOK/또는 db에
2) shim 배포: 공급사 서명 shimx64.efi를 TFTP/HTTP 경로에 배치, NBP로 지정
3) 로더 서명: grubx64.efi와 ipxe.efi(선택)를 배포자 키로 서명해 저장
4) 체인 구성: grub.cfg에서 커널·initrd·ipxe.efi 경로를 정의하고 모두 서명본 사용
5) 키 등록: mokutil 또는 펌웨어 메뉴로 MOK(또는 db)에 공개키를 등록
6) 검증: 테스트 좌석에서 Secure Boot On 상태로 PXE → shim → grub → 커널 순
7) 롤백: 비상용으로 Secure Boot Off·레거시 이미지 경로를 별도로 보관

DHCP/TFTP/HTTPBoot 포인트

1) UEFI 전용 DHCP 스코프 분리: UEFI x64에 shimx64.efi를 옵션67로 제공
2) HTTPBoot 병행: bootfile-url로 http://서버/EFI/BOOT/bootx64.efi 지정
3) 벤더 클래스 식별자 확인: "PXEClient"·"HTTPClient" 구분·응답값 검증
4) IPv6 환경: dhcp6.bootfile-url·vendor-class 등 옵션 정의를 맞춥니다.
5) WDS/윈도우 배포: wdsmgfw.efi를 유지, 보안 키 갱신 이슈를 수시 점검

키 저장소·보안 주의

1) UEFI 키 체계: PK(플랫폼 키) → KEK → db/dbx 순으로 신뢰 사슬 구성
2) 2023~2025 키 전환: 일부 구형 펌웨어는 새 UEFI CA 키가 없어 실패
3) 대응: 펌웨어 업데이트 또는 KEK/db 갱신으로 새 서명물 신뢰 확보
4) dbx(폐기 목록) 업데이트 누락 시 취약 shim/grub이 부팅 차단될 수 있음
5) 조직 운영: 전 좌석 동일 키·동일 체인 적용, 분기별 키·dbx 갱신 표준화

PC방 운영 체크리스트

1) 좌석군: 보안 부팅군과 점검군을 분리, 점검군에서 체인 검증 후 전환
2) 이미징: UEFI·GPT 전용 이미지 표준화, 레거시 이미지는 보관만 유지
3) 예외관리: 특정 보드/펌웨어에서 키 미호환 시 펌웨어 업데이트 우선
4) 문서화: '키·서명·경로·DHCP 옵션'을 자산화, 변경 시 릴리즈 노트 작성
5) 비상플랜: dbx 갱신 실패·서명 만료 시 롤백 경로와 공지문 사전 준비

한줄평

PXE도 보안도 둘 다 잡을 수 있습니다. 핵심은 '서명 체인'입니다.

출처

Microsoft Learn: Secure Boot 키 관리 가이드
Debian Wiki: Secure Boot 개요
Oracle Linux Docs: UEFI 키 구조(PK/KEK/db/dbx)
SUSE Docs: UEFI HTTPBoot 설정 가이드
iPXE 포럼: shim·MOK·서명 체인 사례
The Foreman 커뮤니티: 멀티 디스트로 Secure Boot 논의
Tom's Hardware: 2025년 키 전환 이슈