UEFI 유효성 검사 옵션 ROM 지침
Vishal Manan, Architect, OEM Consulting, vmanan@microsoft.com
Jeremiah Windows 보안 SDET, SDET, &jerecox@microsoft.com
TW-WIN 플랜 에코시스템의 엔지니어링 서비스 엔지니어인 브르 Lin tolin@microsoft.com
버전 1.3
이 문서는 OEM 및 ODM이 해당 펌웨어가 보안 부팅 신뢰 체인의 일부로 해당 옵션 ROM의 서명을 확인하는지 확인하는 데 도움이 됩니다.
이 가이드에서는 사용자가 UEFI의 기본 사항, 보안 부팅에 대한 기본적인 이해(UEFI 사양의 1, 2, 13, 20 및 27장) 및 PKI 보안 모델을 알고 있다고 가정합니다.
이 페이지에서 다음을 수행합니다.
소개
옵션 ROM(또는 OpROM)은 플랫폼 초기화 중에 PC BIOS에서 실행하는 펌웨어입니다. 일반적으로 시스템 보드에 상주할 수 있지만 플러그 인 카드에 저장됩니다.
일반적으로 옵션 ROM이 필요한 디바이스는 RAID 모듈용 비디오 카드, 네트워크 어댑터 및 스토리지 드라이버입니다. 이러한 옵션 ROM은 일반적으로 PC에 펌웨어 드라이버를 제공합니다.
여기에는 레거시 PC-AT, 펌웨어 열기 및 EFI 옵션 ROM을 비롯한 다양한 유형의 펌웨어 드라이버가 포함됩니다. 펌웨어 드라이버의 예로는 비디오 카드의 Video BIOS, 이더넷 어댑터용 PXE 부팅 드라이버 및 RAID 컨트롤러의 스토리지 드라이버가 있습니다. 이러한 디바이스에는 일반적으로 펌웨어 드라이버를 제공하는 옵션 ROM이 있습니다.
UEFI(Unified Extensible Firmware Interface)는 레거시 모드 옵션 ROM을 지원합니다.
최신 UEFI 사양(현재 2.3.1 Errata C – 섹션 2.5.1.2)에 따라 ISA(레거시) 옵션 ROM은 UEFI 사양의 일부가 아닙니다. 이 논의에서는 PCI 기반 UEFI 호환 옵션 ROM만 고려됩니다.
PC 펌웨어에 디바이스의 펌웨어를 포함할 수 없는 경우 옵션 ROM을 사용할 수 있습니다. ROM 옵션이 드라이버를 전달하는 경우 IHV는 해당 드라이버를 활용하고 드라이버와 디바이스를 한 곳에 유지할 수 있습니다.
이 문서에서는 옵션 ROM의 유효성을 검사해야 하는 이유에 대해 설명하며 이를 수행하는 몇 가지 기술을 보여줍니다.
UEFI BIOS 및 레거시 BIOS 모두 지원
대부분의 제조업체는 다양한 유형의 PC에 대한 옵션 ROM 및 펌웨어를 포함하는 디바이스를 만듭니다. 일반적인 콤보는 다음과 같습니다.
레거시 ROM만
UEFI 네이티브 OpROM
레거시 ROM + UEFI EBC OpROM
레거시 ROM + UEFI x64 OpROM
레거시 ROM + UEFI x64 + UEFI IA32
레거시 ROM + UEFI x64 + UEFI IA32 + UEFI EBC OpROM
UEFI BIOS는 CSM(호환성 지원 모듈)을 사용하는 경우 레거시 펌웨어 드라이버를 로드하고 실행할 수 있습니다. 보안 부팅을 사용하도록 설정하면 레거시 펌웨어 드라이버가 인증을 지원하지 않으므로 호환성 지원 모듈 및 레거시 ROM의 실행이 금지됩니다. BIOS 구성의 Option ROM 형식이 레거시 ROM으로 설정된 경우 항상 디바이스에서 레거시 ROM을 사용합니다.
Option ROM 형식이 UEFI 호환가능 으로 설정된 경우 최신 EFI ROM(있는 경우)을 사용하고, 없는 경우 레거시 ROM을 사용합니다.
UEFI 드라이버는 많은 새로운 펌웨어 수준 보안 기능뿐만 아니라 UEFI 부팅 시퀀스를 사용하도록 설정하는 데 필요합니다. 예를 들어 UEFI 호환되지 않는 스토리지 컨트롤러에 연결된 광학 디스크에서 Windows 설치하는 것은 보안 부팅을 사용하는 경우 시스템이 UEFI 모드로 부팅되는 경우 불가능합니다.
1. UEFI 및 옵션 ROM
그림 2: UEFI 드라이버 보안 고려 사항, 원본: UEFI 2.3.1 Errata C
다음 텍스트는 UEFI 2.3.1 Errata C에서 시작되었지만 이후 파트너의 인사이트를 통해 수정되었습니다.
UEFI 사용자 프로필은 많은 보안 관련 권한을 자세히 설명하기 때문에 사용자 ID 관리자 및 사용자 자격 증명 공급자와 이러한 사용자 프로필이 실행되는 환경을 신뢰할 수 있는 것이 중요합니다.
다음 내용이 포함됩니다.
이러한 드라이버가 저장되는 스토리지 영역 보호.
이러한 드라이버가 선택되는 수단을 보호합니다.
확인되지 않은 드라이버로부터 이러한 드라이버의 실행 환경을 보호합니다.
이러한 드라이버에서 사용하는 데이터 구조는 여전히 사용되는 동안 권한 없는 드라이버에 의해 손상되지 않아야 합니다.
사용자 ID 관리자, 사용자 자격 증명 드라이버 및 온보드 드라이버와 같은 구성 요소는 플랫폼 정책으로 신뢰할 수 있는 쓰기 보호 플래시 드라이브와 같은 안전한 위치에 위치할 수 있습니다.
일부 다른 드라이버는 옵션 ROM 또는 하드 드라이브 파티션과 같은 보호되지 않는 스토리지 위치에 상주할 수 있으며 쉽게 교체할 수 있습니다. 이러한 드라이버를 확인해야 합니다.
예를 들어 기본 플랫폼 정책은 Driver#### load 옵션에 나열된 드라이버를 성공적으로 확인할 수 있어야 합니다. 그렇지 않으면 이러한 드라이버를 처리하기 전에 사용자를 식별해야 합니다. 그렇지 않으면 드라이버 실행을 지연해야 합니다. 사용자 프로필이 식별()에 대한 후속 호출 또는 동적 인증을 통해 변경되는 경우 Driver#### 옵션은 다시 처리되지 않을 수 있습니다.
사용자 프로필 데이터베이스는 보호할 수 있는지 여부에 따라 다른 UEFI 신호 이벤트를 사용하여 닫힙니다.
UEFI 드라이버 & UEFI 옵션 ROM은 부팅 경로의 디바이스에 대해서만 실행됩니다.
PCI 사양은 동일한 디바이스에서 여러 옵션 ROM 이미지를 허용합니다. 이러한 옵션 ROMS는 레거시 x86 & UEFI일 수 있습니다. UEFI 펌웨어는 ROM 옵션을 선택하기 위한 플랫폼 정책을 설정합니다. 이렇게 하면 선택적 어댑터의 ROM이 자체 제어 디바이스로 실행되도록 할 수 있습니다.
펌웨어는 BDS 및 DXE 단계 중에 서명을 확인합니다. 작업이 진행되는 순서는 다음과 같습니다.
PCI 및 파생 버스 초기화
옵션 ROM에 대한 PCI 디바이스 프로브
찾은 옵션 ROM이 메모리에 매핑됩니다.
DXE 단계는 ROM에 UEFI 드라이버를 로드합니다.
UEFI 옵션 ROM은 메모리의 어디에나 있을 수 있습니다. 기본값은 카드의 ROM이 디바이스를 관리하도록 하는 것입니다. UEFI를 사용하면 플랫폼에서 ROM이 EFI_PLATFORM_DRIVER_OVERRIDE 사용하는 디바이스를 제어하는 옵션에 대한 정책을 제어할 수 있습니다. UEFI는 구성 인터페이스를 등록하는 옵션 ROM을 지원합니다.
보안 부팅을 사용하도록 설정된 PC에서 옵션 ROM 드라이버는 서명되지 않았거나 유효성이 검사되지 않은 경우 보안 위협을 초래합니다. 옵션 ROM에 대한 서명 유효성 검사는 WHCK 요구 사항입니다. 설치 전에 업데이트의 유효성을 검사하기 위해 ROM을 서비스하는 동안에도 마찬가지입니다.
Windows 하드웨어 호환성 프로그램 사양 및 정책 버전 1809:
- 서명된 펌웨어 코드 무결성 검사. OEM에 의해 설치되고 읽기 전용이거나 위에 정의된 보안 펌웨어 업데이트 프로세스에 의해 보호되는 펌웨어는 보호된 것으로 간주될 수 있습니다. 시스템은 보호되지 않는 모든 펌웨어 구성 요소, UEFI 드라이버 및 UEFI 애플리케이션이 SHA-256과 함께 최소 RSA-2048(MD5 및 SHA-1은 금지됨)을 사용하여 서명되었는지 확인하고, 이러한 요구 사항에 따라 서명되지 않은 UEFI 애플리케이션 및 드라이버가 실행되지 않는지 확인해야 합니다(허용되는 서명 알고리즘에 대한 기본 정책임). 이미지 서명이 권한 있는 데이터베이스에 없거나 사용할 수 없는 데이터베이스에 있는 경우 이미지를 시작하지 않아야 하며, 대신 이미지 실행 정보 테이블에 이미지 서명에 대한 정보를 배치해야 합니다.
2. 문제 문
보안 부팅 개발 중에 서명된 UEFI 옵션 ROM을 사용할 수 없으므로 Tiano Core를 비롯한 보안 부팅 지원 UEFI BIOS의 일부 빌드는 기본적으로 UEFI 옵션 ROM을 인증하지 않았습니다. 이렇게 하면 UEFI 보안 부팅의 공격 표면/취약성이 노출됩니다.
2.1. 취약점
이 취약성은 2013년 8월 현재 EDK II 및 UDK2010에 여전히 존재합니다. 원본 유지 관리자는 문제를 인식하고 버그가 제출됩니다. EDK II 및 UDK2010에서 파생된 모든 펌웨어는 Option ROM 확인이 관리되는 방법을 확인해야 합니다. 옵션 ROM 확인 동작은 PcdOptionRomImageVerificationPolicy EDK II SecurityPkg 패키지의 PCD 값에 의해 제어됩니다.
TianoCore 취약성의 소스 코드는 SecurityPkg\SecurityPkg.dec 파일입니다.
## Pcd for OptionRom.
# Image verification policy settings:
# ALWAYS_EXECUTE 0x00000000
# NEVER_EXECUTE 0x00000001
# ALLOW_EXECUTE_ON_SECURITY_VIOLATION 0x00000002
# DEFER_EXECUTE_ON_SECURITY_VIOLATION 0x00000003
# DENY_EXECUTE_ON_SECURITY_VIOLATION 0x00000004
# QUERY_USER_ON_SECURITY_VIOLATION 0x00000005
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00|UINT32|0x00000001
기본값(0x00)은 ALWAYS_EXECUTE 추가 기능 주변 장치용 옵션 ROM에서 서명된 드라이버의 확인을 제대로 수행하지 않습니다. 이는 UEFI 보안 부팅 기능을 구현하는 시스템에 이상적인 값이 아닙니다.
권장 값(최상의 보안): DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04)
권장 값(최고의 유연성): QUERY_USER_ON_SECURITY_VIOLATION (0x05)
EDK II & UDK2010에서 적절 한 코딩 방법은 재정의 메커니즘을 사용 하 여 플랫폼 펌웨어에 대 한 PCD 값을 수정 합니다. 따라서의 값은에서 변경 하면 안 됩니다 PcdOptionRomImageVerificationPolicySecurityPkg\SecurityPkg.dec . 플랫폼의 DSC 파일에 재정의 값을 설정 해야 합니다 ’ . Nt32Pkg\Nt32Pkg.dsc를 사용 하는 예제는 다음과 같습니다.
[PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
PCD 재정의는 [PcdsFixedAtBuild] DSC 파일의 섹션 아래에 배치 해야 합니다. 매개 변수를 재정의 하는 정확한 메커니즘은 BIOS 공급 업체 도구에 따라 다를 수 있습니다.
참고 이 취약점은 독립 BIOS 공급 업체의 UEFI 보안 부팅 BIOS의 초기 구현에 있을 수 있습니다. BIOS 공급 업체에 문의 하 여 버전이 영향을 받을 수 있는지 확인 하십시오.
3. Who 영향을 받습니까?
보안 부팅을 구현 하 고 서명 되지 않은 UEFI 옵션 ROM 드라이버가 있는 UEFI PC입니다. 또한 기존 카드를 가져오는 데 호환 되는 펌웨어에는 옵션 Rom을 확인 하지 않는 보안 취약성이 있을 수 있습니다 ’ .
랩톱, netbooks, 울트라 북, 태블릿: 대부분 영향을 받지 않습니다. 옵션 Rom은 일반적으로 PCI/e, ISA 및 해당 파생물 (ExpressCard, miniPCI, CardBus, PCCard, LPC, 선더볼트 등)과 같은 후면판 버스에 있습니다. 노트북에 이러한 노출이 표시 되어 있지 않으면 공격 노출 영역이 크게 줄어듭니다. 또한 온보드 랩톱 구성 요소에 대 한 UEFI 드라이버가 별도의 옵션 ROM이 아닌 핵심 BIOS 펌웨어 볼륨에 통합 되어 있을 수 있습니다. 따라서 대부분의 랩톱은 위험 하지 않습니다. 또한 레거시 옵션 Rom이 사용 하지 않도록 설정 된 경우 UEFI는 PCI 기반 옵션 Rom만 지원 합니다.
그러나 UEFI BIOS를 포함 하 고 있고 보안 부팅을 구현 하는 데스크톱, 마더보드 또는 서버가 있는 경우 영향을 받을 수 있습니다. 서버 ’ 전용 RAID 컨트롤러 또는 SATA, FC 등의 추가 기능 저장소 컨트롤러 또는 이더넷 PCIe 네트워크 카드에는 옵션 rom이 있을 수 있습니다. 서버에서 광범위 한 기능을 지 원하는 추가 기능 컨트롤러는 일반적 이므로 서버 공간에 특히 적용 됩니다.
이는 클래스 2와 클래스 3 모두에서 32 비트 및 64 비트 Pc에 잠재적으로 영향을 미칠 수 있습니다.
보안 부팅 플랫폼이 플랫폼에 영구적으로 연결 되지 않은 장치에서 옵션 rom을 지원 하 고 이러한 옵션 Rom을 인증 하는 기능을 지 원하는 경우 네트워크 프로토콜 UDP 및 MTFTP에 설명 된 옵션 ROM 유효성 검사 방법과 — UEFI 사양 2.3.1 정오표 C 섹션 7.2에 설명 된 인증 된 EFI 변수를 지원 해야 합니다.
4. 테스트 하는 방법
펌웨어를 개발 하는 경우 Tiano Core를 기반으로 하는 경우 2.1 섹션에 언급 된 취약성을 확인 하세요. 다른 IBV s 펌웨어를 사용 하는 경우 ’ 해당 펌웨어를 확인 하세요. 또는 아래에 설명 된 대로 직접 테스트를 수행할 수 있습니다.
다음이 필요합니다.
UEFI 펌웨어를 사용 하 여 테스트 중인 PC
테스트 중인 PC의 옵션 ROM이 있는 PCI 장치 (예: 비디오 카드)
보안 부팅이 사용 하도록 설정 되었는지 확인
테스트 단계:
- 테스트 중인 PC에 uefi 옵션 ROM이 포함 된 UEFI 추가 PCI 카드를 삽입 합니다.
테스트용 PCI 비디오 카드를 사용 하는 경우 외부 모니터를 후크 합니다.
- 아래 설정을 사용 하 여 보안 부팅을 사용 하도록 설정 합니다.
PK: pk 또는 자체 서명 된 테스트 PK
KEK: MS KEK, PK 서명 Fabrikam 테스트 KEK 또는 다른 KEK
DB: NULL입니다. 이는 NULL 이어야 합니다.
.DBX: NULL.
SecureBoot: UEFI 변수를 true로 설정 해야 합니다.
PC 다시 부팅
다음의 결과가 예상됩니다.
UEFI 펌웨어가 올바르게 구현 된 경우, 옵션 ROM이 있는 이후 UEFI 옵션 ROM 드라이버가 wouldn ’ t 로드를 수행 하면 펌웨어에서 “” 인증서에 대 한 Db를 확인 합니다. “Db ” 가 NULL 이므로 UEFI 드라이버가 로드 되지 않습니다. 예를 들어, 비디오 카드를 사용 하 여 테스트 하는 경우 디스플레이에 아무것도 표시 되지 않습니다.
펌웨어가 ’ 올바르게 구현 되지 않은 경우에는 펌웨어가 ’ Db에서 서명을 확인 하지 않으므로 UEFI 드라이버가 옵션 ROM에서 로드 됩니다 “” . 예를 들어 테스트에 비디오 카드를 사용 하는 경우 옵션 ROM 카드로 후크 된 모니터가 표시 되는 것을 볼 수 있습니다.
참고UEFI 옵션 rom 드라이버가 서명 되었는지 여부에 관계 없이 DB가 null이 고 SB를 사용 하는 경우 (PK 및 KEK이 등록 됨) 옵션 rom이 로드 되지 않습니다.
PK 및 KEK 생성을 위해 WHCK에서 사용할 수 있는 샘플 스크립트를 참조 하세요. 스크립트는에서 다운로드할 수 있습니다 https://go.microsoft.com/fwlink/?LinkId=321292 . 부록 B에는 샘플 스크립트와 자세한 내용이 있습니다.
위의 테스트를 수행 하는 다른 방법에 대해 부록 A를 참조할 수도 있습니다. 이 방법은 ’ DB를 Null로 설정 하지 않아도 되지만 IHV의 부호 없는 UEFI 옵션 ROM 드라이버가 필요 합니다.
5. 문제를 해결 하는 방법
위의 테스트가 실패 하는 경우 IBV를 사용 하 여 필요한 버전을 획득 하 고 옵션 Rom의 유효성을 검사 하도록 구성 합니다. 펌웨어가 테스트를 통과 하는지 확인 합니다. 제공 된 Pc의 경우 보안 펌웨어 업데이트를 수행 해야 합니다. NIST 게시 800-147 및/또는 Windows 8.1 보안 부팅 키 만들기 및 관리 지침을 참조 하세요.
PC를 테스트 하 고 보안 펌웨어 업데이트를 테스트 하기 위한 테스트 도구 (인증 도구 아님)로 HCK Windows 활용할 수 있습니다.
5.1. 드라이버 서명
UEFI 옵션 Rom에 서명 되지 않은 드라이버가 있을 수 있는 경우이 문제를 해결 하는 방법에 대 한 자세한 내용을 확인 하세요.
각 옵션 ROM 드라이버에 개별적으로 서명 합니다. 그러면 PCI 옵션 ROM의 형식이 손상 됩니다. 조합 된 옵션 ROM을 만들기 전에 UEFI 드라이버에 서명 해야 합니다.
Uefi 드라이버를 OpROM에 삽입 하기 전에 uefi 이미지에 서명 하 고 UEFI 셸에서 보안 부팅이 설정 된 상태에서 테스트 & 합니다 (드라이버 파일 로드/언로드). 그런 다음, 서명 된 드라이버를 결합 된 옵션 ROM에 배치 합니다.
Microsoft SysDev center에 IHV를 전달 하 여 SysDev center를 통해 제공 되는 서비스를 통해 등록 된 UEFI 옵션 Rom을 얻을 수 있습니다.
5.2. 업데이트 유효성 검사
위에서 언급 한 테스트를 실행 하 여 취약점이 존재 하지 않는지 확인 합니다. HCK 테스트를 사용 하 여 기능적 재발이 없는지 확인 합니다.
6. 리소스
UEFI 플랫폼 초기화 사양, 볼륨 5 표준, 1.2.1 정오표 A: https://go.microsoft.com/fwlink/p/?linkid=220187
UEFI 2.3.1 사양의 관련 정보:
2.5.1: 레거시 옵션 ROM 문제
10: 프로토콜 – UEFI 드라이버 모델
13.4.2: PCI 옵션 Rom
20: EFI 바이트 코드 가상 컴퓨터
28: to i 개요
29:
30: 모든 구성 처리 및 브라우저 프로토콜
다른 UEFI 개발자의 지원을 위해 Tianocore-devel 메일링 리스트 사용
TechNet: Enterprise 보안을 위한 최선의 구현 방법: 보안 전략
UEFI 사양 정오표 C
부록 A: 서명 되지 않은 옵션 ROM 드라이버를 사용 하 여 테스트 하는 대체 방법
이 방법은 UEFI 옵션 ROM 드라이버가 서명 되었는지 확인 하기 위해 IHV에서 도구를 가져오는 데 사용 됩니다.
다음이 필요합니다.
UEFI 펌웨어를 사용 하 여 테스트 중인 PC
테스트 중인 PC에 연결 된 서명 되지 않은 옵션 ROM 드라이버를 사용 하는 PCI 장치 (예: 비디오 카드)
보안 부팅이 사용 하도록 설정 되었는지 확인
Option rom 드라이버가 서명 되었는지 여부를 명확 하 게 알 수 없는 경우 옵션 ROM 드라이버에서 서명을 검색 하는 옵션 IHV 도구 ’
펌웨어가 올바르게 구현되고 옵션 ROM이 서명되지 않은 경우 카드는 펌웨어에서 검사에 실패하고 카드에 드라이버를 로드하지 않아야 합니다. PC에서 EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND같은 오류 코드를 보고해야 합니다. 비디오 카드를 사용하는 경우 ROM 드라이버가 로드되지 않았기 때문에 PC에 검은색 화면만 표시되는 것을 볼 수 ’ 있습니다.
펌웨어가 잘못 구현되면 이 테스트가 작동합니다.
부록 B: NULL db를 사용하여 보안 부팅을 사용하도록 설정하는 스크립트
현재 보안 부팅 변수 집합(PK 및 KEK)을 사용하거나 이를 테스트하기 위한 테스트 변수를 생성할 수 있습니다.
다음은 테스트 PK, KEK를 생성하고 Db를 NULL로 설정하는 데 사용되는 단계입니다. 보안 부팅이 사용되지 않는지 확인합니다. 그렇지 않으면 이러한 단계에 서명된 UEFI bin 파일이 필요합니다.
참고 UEFI bin 파일에 서명할 필요가 없도록 보안 부팅 변수 Db, KEK 및 PK를 역순으로 ’ 설정합니다.
이 단계 전에 PC는 설치 모드에 있어야 합니다.
- KEK 및 PK 인증서 만들기
이 단계를 수행하려면 Windows SDK에서사용할 수 있는 makecert.exe 도구가 필요합니다.
MakeCert.exe -cy authority -len 2048 -m 60 -a sha256 -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test KEK CA" Fabrikam_Test_KEK_CA.cer
MakeCert.exe -cy authority -len 2048 -m 60 -a sha256 -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test PK" TestPK.cer
- 테스트 PK를 생성하는 스크립트
사용자 고유의 PK를 사용하거나 이를 위해 WHCK의 스크립트를 활용할 수 있습니다. https://go.microsoft.com/fwlink/?LinkId=321292
샘플은 아래에 있습니다.
이 스크립트는 플랫폼 키의 서식을 지정하는 방법을 보여 둡니다. PK는 실제로 secureboot $d = (pwd)를 Import-Module Enable_OEM_SecureBoot.ps1 스크립트에서 설정됩니다. 경로
### 다음 매개 변수 완료 ###############################################################################
$certname = "TestPK" TODO 이 경로를 PK.cer 파일이 있는 위치로 변경합니다. 여기서 HSM $certpath = $d + "" + $certname + ".cer"에 의해 생성된 인증서를 플러그 인합니다.
각 서명에는 데이터베이스에 서명을 삽입한 에이전트를 식별하는 GUID인 소유자 SignatureOwner가 있습니다. 에이전트에는 운영 PC 또는 OEM 제공 드라이버 또는 애플리케이션이 포함될 수 있습니다. 에이전트는 이 필드를 검사하여 서명을 관리해야 하는지 여부를 파악할 수 있습니다. TODO를 OEM SignatureOwner GUID로 바꿉 있습니다. SDK의 Guidgen.exe 도구와 같은 도구 또는 유사한 도구를 사용하여 GUID $sigowner = "55555555-5555-5555-5555-555555555555555"를 생성할 수 있습니다.
$var = "PK" $efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}" $append = $false
### 다른 모든 것이 계산됩니다. ###############################################################################
해결 방법 상대 경로 버그 TODO는 OEM 이름을 $siglist = $certname + "_SigList.bin" $serialization = $certname + " SigList_Serialization_for " +$var+ ".bin" $signature = $serialization + ".p7"로 대체합니다.
$appendstring = "set_" $attribute = "0x27" $example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"
Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -Certificate $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z -AppendWrite:$append
OutputFilePath - 설정된 내용의 내용을 포함하는 생성된 파일의 이름을 지정합니다. 이 매개 변수를 지정하면 콘텐츠가 실제로 설정되지 않고 이 파일에 저장됩니다. 이 경우처럼 PK가 설정되지 않은 경우 -OutputFilePath가 제공되는 경우 유의하세요. 마스터 스크립트는 끝에 설정합니다.
시간 - 미래의 시간이 아닌 한 아래 시간을 변경할 수 있습니다. 그대로 유지하는 데 아무런 문제가 없습니다.
Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist -OutputFilePath $example -AppendWrite:$append
- 테스트 KEK 생성 또는 사용자 고유의 OEM KEK 사용
이를 위해 WHCK에서 사용자 고유의 OEM KEK 또는 스크립트를 활용할 수 있습니다. 자체 테스트 KEK를 생성하는 대신 에서 Fabrikam_PK_SigList.bin을 사용할 https://go.microsoft.com/fwlink/?LinkId=321292 수도 있습니다.
샘플은 아래에 있습니다.
OEM KEK Import-Module secureboot $d = (pwd) 옵션을 추가하는 스크립트입니다. 경로
### 다음 매개 변수 완료 ###############################################################################
$certname = "Fabrikam_Test_KEK_CA" TODO가 이 경로를 PK.cer 파일이 있는 위치로 변경합니다. 여기서 HSM $certpath = $d + "" + $certname + ".cer"에서 생성된 인증서를 플러그 인합니다.
TODO는 이 경로를 OEM_KEK.cer 파일이 있는 위치로 변경합니다. 각 서명에는 데이터베이스에 서명을 삽입한 에이전트를 식별하는 GUID인 소유자 SignatureOwner가 있습니다. 에이전트에는 운영 체제 또는 OEM 제공 드라이버 또는 애플리케이션이 포함될 수 있습니다. 에이전트는 이 필드를 검사하여 서명을 관리해야 하는지 여부를 파악할 수 있습니다. TODO를 OEM SignatureOwner GUID로 바꿉 있습니다. SDK의 Guidgen.exe 도구 또는 유사한 도구를 사용하여 GUID를 생성할 수 있습니다.
$sigowner = "00000000-0000-0000-0000-0000000000000"
$var = "KEK" $efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}" $append = $false
### 다른 모든 것이 계산됩니다. ###############################################################################
$siglist = $certname + "SigList.bin" $serialization = $certname + "SigList_Serialization_for" + $var + ".bin" $signature = $serialization + ".p7" if ($append -eq $false) { $appendstring = "set" $attribute = "0x27" } else { $appendstring = "append_" $attribute = "0x67" } $example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"
Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -CertificateFilePath $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z -AppendWrite:$append
-Time 이후가 아닌 한 아래 시간을 변경할 수 있습니다. 그대로 유지하는 데 아무런 문제가 없습니다.
Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist -OutputFilePath $example -AppendWrite:$append
- Db를 Null로 설정하고 KEK 및 PK를 설정합니다.
이 스크립트에서 가장 먼저 수행하는 일은 Db를 Null로 설정하는 것입니다.
참고 Fabrikam Test KEK CA가 유일한 KEK CA인 경우(Windows KEK CA가 없음) PC가 Windows RE 부팅할 수 있습니다.
스크립트 실행 전에 "Set-ExecutionPolicy Bypass -Force"를 실행합니다.
Import-Module secureboot try { Write-Host "Deleting db..." Set-SecureBootUEFI -Name db -Time "2011-06-06T13:30:00Z" -Content $null } catch { } Write-Host "Fabrikam KEK 설정..." Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath Fabrikam_Test_KEK_CA_SigList.bin -Name KEK
Write-Host "자체 서명된 테스트 PK 설정..." Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath TestPK_SigList.bin -Name PK
Write-Host " n... operation complete. nSetupMode는 이제 0이고 SecureBoot도 0이어야 합니다. 다시 부팅하고 Windows 올바르게 인증되었는지, SecureBoot가 1로 변경되는지 확인합니다."
- ROM 카드 및 테스트 옵션에 연결
테스트는 펌웨어 정확성에 따라 통과하거나 실패해야 합니다. 예를 들면 다음과 같습니다.
펌웨어의 ROM 옵션이 올바르게 구현되고 테스트에 비디오 카드를 사용하는 경우 연결된 모니터에 표시되지 않아야 합니다.
그러나 잘못된 펌웨어를 사용하는 경우 비디오 카드에 디스플레이에 출력이 있어야 합니다.