이 문서는 제조 환경에서 보안 부팅 키와 인증서를 만들고 관리할 때 OEM 및 ODM을 안내하는 데 도움이 됩니다. PK(플랫폼 키), 보안 펌웨어 업데이트 키, 제3자 KEK(키 교환 키)의 만들기, 스토리지 및 검색과 관련된 질문을 다룹니다.
참고 항목
디바이스 OEM, 엔터프라이즈 및 고객은 Microsoft의 Secure Boot 오픈 소스 리포지토리에서 Microsoft 권장 PK, KEK, DB 및 DBX 이진 파일을 찾을 수 있습니다. 이진 파일은 펌웨어에 쉽게 통합할 수 있도록 필요한 EDKII 형식으로 포맷됩니다.
참고 항목
Microsoft Corporation KEK CA 2011은 2026년에 만료되도록 설정되어 있으며 모든 OEM은 새 Microsoft Corporation KEK CA 2023에 대한 업데이트를 만들고 서명하고 Microsoft에 제출해야 합니다. 이렇게 하면 Microsoft가 새 Microsoft KEK CA를 사용하여 시장 내 디바이스를 업데이트할 수 있으므로 시스템에서 2026년 이후에도 DB 및 DBX 업데이트를 계속 받을 수 있습니다. 지침 및 테스트 참고 자료는 다음을 방문하세요. https://aka.ms/KEKUpdatePackage
UEFI 및 보안 부팅에 대한 Windows 요구 사항은 Windows 하드웨어 인증 요구 사항에서 확인할 수 있습니다. 이 문서는 새로운 요구 사항을 소개하거나 공식 Windows 프로그램을 나타내지 않습니다. 보안 부팅 키를 만들고 관리하기 위한 효율적이고 안전한 프로세스를 구축하는 데 도움이 되도록 인증 요구 사항 이상의 지침을 제공하기 위한 것입니다. UEFI 보안 부팅은 실행이 허용되기 전에 코드를 인증하기 위해 공개 키 인프라 사용량을 기반으로 하기 때문에 중요합니다.
읽기 권한자는 UEFI의 기본 사항, 보안 부팅에 대한 기본 이해(UEFI 사양의 27장) 및 PKI 보안 모델을 알고 있어야 합니다.
Windows에서 보안 부팅을 유효성 검사하는 요구 사항, 테스트 및 도구는 오늘부터 Windows HCK(하드웨어 인증 키트)를 통해 제공됩니다. 그러나 이러한 HCK 리소스는 Windows 배포용 키 만들기 및 관리를 다루지 않습니다. 이 백서에서는 파트너가 펌웨어에서 사용하는 키 배포를 안내할 수 있도록 하는 리소스로 키 관리를 다룹니다. 이는 규범적인 지침이 아니며 새로운 요구 사항을 포함하지 않습니다.
이 페이지의 내용:
- 1. 보안 부팅, Windows 및 키 관리에는 Windows 및 보안 부팅에 적용되는 부팅 보안 및 PKI 아키텍처에 대한 정보가 포함되어 있습니다.
- 2. 키 관리 솔루션은 파트너가 필요에 맞는 키 관리 및 설계 솔루션을 설계할 수 있도록 돕기 위한 것입니다.
- 3. 요약 및 리소스에는 부록, 검사 목록, API 및 기타 참조 자료가 포함되어 있습니다.
이 문서는 고객 준비 PC, 공장 배포 도구 및 주요 보안 모범 사례를 개발하는 출발점 역할을 합니다.
1. 보안 부팅, Windows 및 키 관리
UEFI(Unified Extensible Firmware Interface) 사양은 보안 부팅이라는 펌웨어 실행 인증 프로세스를 정의합니다. 업계 표준인 보안 부팅은 플랫폼 펌웨어가 인증서를 관리하는 방법, 펌웨어를 인증하는 방법 및 운영 체제가 이 프로세스와 인터페이스하는 방법을 정의합니다.
보안 부팅은 실행이 허용되기 전에 모듈을 인증하는 PKI(공개 키 인프라) 프로세스를 기반으로 합니다. 이러한 모듈에는 펌웨어 드라이버, 옵션 ROM, 디스크의 UEFI 드라이버, UEFI 애플리케이션 또는 UEFI 부트 로더가 포함될 수 있습니다. Secure Boot는 실행 전 이미지 인증을 통해 루트킷과 같은 사전 부팅 맬웨어 공격의 위험을 줄입니다. Microsoft는 신뢰할 수 있는 부팅 보안 아키텍처의 일부로 Windows 8 이상에서 UEFI 보안 부팅을 사용하여 고객을 위한 플랫폼 보안을 개선합니다. 보안 부팅은 Windows 8 이상 클라이언트 PC와 Windows 하드웨어 호환성 요구 사항에 정의된 Windows Server 2016에 필요합니다.
보안 부팅 프로세스는 그림 1과 같이 다음과 같이 작동합니다.
- 펌웨어 부팅 구성 요소: 펌웨어는 OS 로더가 신뢰할 수 있는지 확인합니다(Windows 또는 신뢰할 수 있는 다른 운영 체제).
- Windows 부팅 구성 요소: BootMgr, WinLoad, Windows 커널 시작. Windows 부팅 구성 요소는 각 구성 요소의 서명을 확인합니다. 신뢰할 수 없는 구성 요소는 로드되지 않고 대신 보안 부팅 수정을 트리거합니다.
- 바이러스 백신 및 맬웨어 방지 소프트웨어 초기화: 이 소프트웨어는 Microsoft에서 발행한 특수 서명이 있는지 확인하여 신뢰할 수 있는 부팅 필요 드라이버이며 부팅 프로세스 초기에 실행됩니다.
- 부팅에 중요한 드라이버 초기화: 모든 부팅 필요 드라이버의 서명은 WinLoad에서 보안 부팅 확인의 일부로 확인됩니다.
- 추가 OS 초기화
- Windows 로그온 화면
그림 1: Windows 신뢰할 수 있는 부팅 아키텍처
UEFI 보안 부팅의 구현은 Windows 8.1에 도입된 Microsoft의 신뢰할 수 있는 부팅 아키텍처의 일부입니다. 맬웨어 악용 진화의 증가 추세는 부팅 경로의 대상을 기본 공격 벡터로 지정하고 있습니다. 맬웨어 방지 제품이 전체 로드를 방지하는 악성 소프트웨어에 의해 사용하지 않도록 설정될 수 있기 때문에 이러한 유형의 공격은 방어하기 어렵습니다. Windows 신뢰할 수 있는 부팅 아키텍처와 보안 부팅을 통한 신뢰할 수 있는 루트 설정을 통해 운영 체제 자체가 로드되기 전에 서명되고 인증된 "알려진" 코드 및 부트 로더만 실행할 수 있도록 하여 부트 경로에서 실행되는 악성 코드로부터 고객을 보호합니다.
1.1 공개 키 인프라(PKI) 및 보안 부팅
PKI는 시스템의 진위성과 신뢰성을 설정합니다. 보안 부팅은 두 가지 높은 수준의 목적을 위해 PKI를 활용합니다.
- 부팅하는 동안 초기 부팅 모듈이 실행을 위해 신뢰할 수 있는지 확인합니다.
- 서비스 요청에 대한 요청을 인증하려면 보안 부팅 데이터베이스 수정 및 플랫폼 펌웨어 업데이트가 포함됩니다.
PKI는 다음으로 구성됩니다.
- 디지털 인증서를 발급하는 CA(인증 기관)입니다.
- CA에서 인증서를 요청하는 사용자의 ID를 확인하는 등록 기관입니다.
- 키를 저장하고 인덱싱할 중앙 디렉터리입니다.
- 인증서 관리 시스템입니다.
1.2 공개 키 암호화
공개 키 암호화는 공개 키와 프라이빗 키라고 하는 수학적으로 관련된 암호화 키 쌍을 사용합니다. 키 중 하나를 알고 있으면 다른 하나가 무엇인지 쉽게 계산할 수 없습니다. 정보를 암호화하는 데 하나의 키가 사용되면 해당 키만 해당 정보를 해독할 수 있습니다. 보안 부팅의 경우 프라이빗 키를 사용하여 코드를 디지털 서명하고 공개 키를 사용하여 해당 코드의 서명을 확인하여 진위성을 증명합니다. 프라이빗 키가 손상되면 해당 공개 키가 있는 시스템은 더 이상 안전하지 않습니다. 이는 부트 키트 공격으로 이어질 수 있으며 프라이빗 키의 보안을 보장하는 책임이 있는 엔터티의 평판을 손상시킬 수 있습니다.
보안 부팅 공개 키 시스템에는 다음이 있습니다.
1.2.1 RSA 2048 암호화
RSA-2048은 비대칭 암호화 알고리즘입니다. RSA-2048 계수를 원시 형식으로 저장하는 데 필요한 공간은 2048비트입니다.
1.2.2 자체 서명된 인증서
인증서의 공개 키와 일치하는 프라이빗 키로 서명된 인증서를 자체 서명된 인증서라고 합니다. 루트 CA(인증 기관) 인증서가 이 범주에 속합니다.
1.2.3 인증 기관
CA(인증 기관)은 인증서 주체의 ID를 확인하고 해당 ID를 인증서에 포함된 공개 키에 바인딩하는 서명된 인증서를 발급합니다. CA는 프라이빗 키를 사용하여 인증서에 서명합니다. 자체 서명된 루트 CA 인증서의 모든 관련 당사자에게 해당 공개 키를 발급합니다.
보안 부팅에서 CA(인증 기관)에는 OEM(또는 그 대리자)과 Microsoft가 포함됩니다. CA는 신뢰할 수 있는 루트를 형성하는 키 쌍을 생성한 다음 프라이빗 키를 사용하여 허용된 조기 부팅 EFI 모듈 및 펌웨어 서비스 요청과 같은 합법적인 작업에 서명합니다. 해당 공개 키는 보안 부팅 지원 PC의 UEFI 펌웨어에 포함되어 배송되며 이러한 작업을 확인하는 데 사용됩니다.
(CA 사용량 및 키 교환에 대한 자세한 내용은 보안 부팅 모델과 관련된 인터넷에서 쉽게 확인할 수 있습니다.)
1.2.4 공개 키
공개 플랫폼 키는 PC에 제공되며 액세스 가능하거나 "공개"됩니다. 이 문서에서 Microsoft는 공개 키를 나타내기 위해 접미사 "pub"를 사용할 것입니다. 예를 들어, PKpub는 PK의 공용 절반을 나타냅니다.
1.2.5 프라이빗 키
PKI가 작동하려면 프라이빗 키를 안전하게 관리해야 합니다. 조직에서 매우 신뢰할 수 있는 소수의 개인이 액세스할 수 있어야 하며 강력한 액세스 정책 제한이 있는 물리적으로 안전한 위치에 있어야 합니다. 이 문서에서는 접미사 "priv"를 사용하여 프라이빗 키를 나타냅니다. 예를 들어, PKpriv는 PK의 프라이빗 절반을 나타냅니다.
1.2.6 인증서
디지털 인증서의 주요 용도는 바이너리 등과 같은 서명된 데이터의 출처를 확인하는 것입니다. 인증서의 일반적인 용도는 TLS(전송 계층 보안) 또는 SSL(Secure Sockets Layer)을 사용하는 인터넷 메시지 보안입니다. 인증서로 서명된 데이터를 확인하면 받는 사람이 데이터의 출처와 전송 중 변경되었는지 여부를 알 수 있습니다.
일반적으로 디지털 인증서에는 DN(고유 이름), 공개 키 및 서명이 포함됩니다. DN은 인증서의 공개 키와 일치하는 프라이빗 키를 보유하는 엔터티(예: 회사)를 식별합니다. 프라이빗 키로 인증서에 서명하고 인증서에 서명을 넣으면 프라이빗 키가 공개 키에 연결됩니다.
인증서에는 다른 유형의 데이터가 포함될 수 있습니다. 예를 들어, X.509 인증서는 인증서 형식, 인증서 일련 번호, 인증서 서명에 사용된 알고리즘, 인증서를 발급한 CA 이름, 인증서를 요청하는 엔터티의 이름 및 공개 키, CA의 서명 등을 포함합니다.
1.2.7 인증서 연결
출처: 인증서 체인:
그림 2: 3개의 인증서 체인
사용자 인증서는 종종 CA의 프라이빗 키와 같은 다른 프라이빗 키로 서명됩니다. 이는 두 개의 인증서 체인을 구성합니다. 사용자 인증서가 정품인지 확인하려면 인증서에서 CA의 공개 키가 필요한 서명을 확인해야 합니다. 그러나 CA의 공개 키를 사용하려면 바깥쪽 CA 인증서를 확인해야 합니다. CA 인증서는 자체 서명되기 때문에 CA 공개 키를 사용하여 인증서를 확인합니다.
루트 CA의 프라이빗 키로 사용자 인증서에 서명할 필요는 없습니다. CA의 프라이빗 키로 인증서에 서명한 중개자의 프라이빗 키로 서명할 수 있습니다. 이는 사용자 인증서, 중간 인증서 및 CA 인증서의 세 가지 인증서 체인의 인스턴스입니다. 그러나 둘 이상의 중개자가 체인의 일부일 수 있으므로 인증서 체인의 길이는 제한이 없습니다.
1.3 보안 부팅 PKI 요구 사항
UEFI에서 정의한 신뢰할 수 있는 루트는 플랫폼 키와 OEM 또는 ODM이 펌웨어 코어에 포함하는 모든 키로 구성됩니다. UEFI 이전 보안 및 신뢰할 수 있는 루트는 UEFI 보안 부팅 프로세스에서 해결되지 않고 대신 이 백서에서 참조하는 NIST(미국 국립표준기술원) 및 TCG(신뢰할 수 있는 컴퓨팅 그룹) 간행물에서 해결됩니다.
1.3.1 보안 부팅 요구 사항
보안 부팅을 구현하려면 다음 매개 변수를 고려해야 합니다.
- 고객 요구 사항
- Windows 하드웨어 호환성 요구 사항
- 키 생성 및 관리 요구 사항.
HSM(하드웨어 보안 모듈)과 같은 보안 부팅 키 관리를 위한 하드웨어를 선택하고 정부 및 기타 기관에 배송할 PC에 대한 특별한 요구 사항을 고려하고 마지막으로 다양한 보안 부팅 키의 수명 주기를 만들기, 채우고 관리하는 프로세스를 고려해야 합니다.
1.3.2 보안 부팅 관련 키
보안 부팅에 사용되는 키는 다음과 같습니다.
그림 3: 보안 부팅 관련 키
위의 그림 3은 보안 부팅이 있는 PC의 서명과 키를 나타냅니다. 플랫폼은 OEM이 제조 과정에서 펌웨어에 설치하는 플랫폼 키를 통해 보호됩니다. 다른 키는 보안 부팅에서 펌웨어 실행을 허용하거나 허용하지 않는 키를 저장하는 데이터베이스에 대한 액세스를 보호하는 데 사용됩니다.
인증된 데이터베이스(db)에는 신뢰할 수 있는 펌웨어 구성 요소 및 운영 체제 로더를 나타내는 공개 키와 인증서가 포함되어 있습니다. 사용할 수 없는 서명 데이터베이스(dbx)에는 악의적이고 취약한 구성 요소의 해시와 손상된 키 및 인증서가 포함되어 있으며 이러한 악의적인 구성 요소의 실행을 차단합니다. 이러한 정책의 강점은 Authenticode 및 PKI(공개 키 인프라)를 사용한 서명 펌웨어를 기반으로 합니다. PKI는 정보 교환 중에 신뢰를 설정하는 인증서를 만들기, 관리 및 취소하기 위한 잘 확립된 프로세스입니다. PKI는 보안 부팅을 위한 보안 모델의 핵심입니다.
다음은 이러한 키에 대한 자세한 내용입니다.
1.3.3 PK(플랫폼 키)
UEFI 2.3.1 정오표 C의 섹션 27.5.1에 따라 플랫폼 키는 플랫폼 소유자와 플랫폼 펌웨어 간에 신뢰 관계를 설정합니다. 플랫폼 소유자는 UEFI 2.3.1 정오표 C의 섹션 7.2.1에 지정된 대로 키(PKpub)의 공용 절반을 플랫폼 펌웨어에 등록합니다. 이 단계는 플랫폼을 설정 모드에서 사용자 모드로 이동합니다. Microsoft는 공개 키 알고리즘 RSA, 공개 키 길이 2048비트 및 서명 알고리즘 sha256RSA를 사용하는
EFI_CERT_X509_GUID유형의 플랫폼 키를 권장합니다. 스토리지 공간이 문제인 경우 플랫폼 소유자는EFI_CERT_RSA2048_GUID유형을 사용할 수 있습니다. 공개 키는 이 문서의 앞부분에서 설명한 대로 서명을 확인하는 데 사용됩니다. 플랫폼 소유자는 나중에 키(PKpriv)의 프라이빗 절반을 사용할 수 있습니다.- 플랫폼 소유권을 변경하려면 펌웨어를 보안 부팅을 사용하지 않도록 설정하는 UEFI 정의 설정 모드로 전환해야 합니다. 제조 중에 이 작업을 수행해야 하는 경우에만 설정 모드로 되돌립니다.
- 데스크톱 및 서버 디바이스의 경우 OEM은 PK와 연결된 필요한 PKI를 관리하거나 OEM에 Microsoft 관리 PK를 사용하도록 선택할 수 있습니다. Microsoft 관리 PK는 Microsoft HSM으로 보호되며 PKI 모범 사례의 일부로 관리됩니다. Windows 에코시스템에 대한 기본 PK입니다.
1.3.3.1 KEK(Key Exchange Key) 등록 또는 업데이트 플랫폼 키 등록
플랫폼 소유자는 UEFI 사양 2.3.1 정오표 C의 섹션 7.2.1에 지정된 대로 UEFI 부팅 서비스 SetVariable()을 호출하고 플랫폼을 다시 설정하여 플랫폼 키(PKpub)의 공용 절반을 등록합니다. 플랫폼이 설정 모드에 있는 경우 새 PKpub는 PKpriv 대응물로 서명되어야 합니다. 플랫폼이 사용자 모드인 경우 새 PKpub는 현재 PKpriv로 서명해야 합니다. PK 유형이
EFI_CERT_X509_GUID이면 PK에 따라 발급된 인증서의 프라이빗 키가 아니라 즉각적인 PKpriv에 의해 서명되어야 합니다.1.3.3.2 플랫폼 키 지우기
플랫폼 소유자는 가변 크기가 0인 UEFI 부팅 서비스 SetVariable()을 호출하고 플랫폼을 다시 설정하여 플랫폼 키(PKpub)의 공용 절반을 지웁니다. 플랫폼이 설정 모드에 있으면 빈 변수를 인증할 필요가 없습니다. 플랫폼이 사용자 모드인 경우 빈 변수는 현재 PKpriv로 서명해야 합니다. 자세한 내용은 UEFI 사양 2.3.1 정오표 C의 섹션 7.2(가변 서비스)를 참조하세요. 보안 부팅을 프로그래밍 방식으로 사용하지 않도록 설정할 수 있으므로 프로덕션 PKpriv를 사용하여 플랫폼을 다시 설정하는 패키지에 서명하지 않는 것이 좋습니다. 이는 주로 사전 프로덕션 테스트 시나리오입니다.
플랫폼 키는 보안 플랫폼별 방법을 사용하여 지울 수도 있습니다. 이 경우 전역 변수 Setup Mode도 1로 업데이트해야 합니다.
그림 4: 플랫폼 키 상태 다이어그램
1.3.3.3 PK 생성
UEFI 권장 사항에 따라 공개 키는 PC에서 변조 및 삭제가 불가능한 비휘발성 스토리지에 저장해야 합니다. 프라이빗 키는 파트너 또는 OEM 보안 사무소에서 안전하게 유지되며 공개 키만 플랫폼에 로드됩니다. 섹션 2.2.1 및 2.3에 자세한 내용이 있습니다.
Microsoft는 PK 인증서를 유지 관리하고 보호하는 책임을 없애기 위해 OEM용 PK를 제공합니다. PK는 Microsoft HSM으로 보호되며 Microsoft PKI 작업의 일부로 관리됩니다.
생성된 PK 수는 플랫폼 소유자(OEM)의 재량에 따릅니다. 이러한 키는 다음과 같을 수 있습니다.
PC당 하나. 각 디바이스에 대해 하나의 고유 키가 있습니다. 이는 정부 기관, 금융 기관 또는 보안 요구 사항이 높은 기타 서버 고객에게 필요할 수 있습니다. 많은 수의 PC에 대한 프라이빗 및 공개 키를 생성하려면 추가 스토리지 및 암호화 처리 능력이 필요할 수 있습니다. 이는 향후 디바이스에 펌웨어 업데이트를 푸시할 때 해당 PK로 디바이스를 매핑하는 복잡성을 추가합니다. HSM 공급업체에 따라 많은 수의 키를 관리하는 데 사용할 수 있는 몇 가지 다른 HSM 솔루션이 있습니다. 자세한 내용은 HSM을 사용한 보안 부팅 키 생성을 참조하세요.
모델당 하나. PC 모델당 하나의 키가 있습니다. 여기서 트레이드오프는 키가 손상되면 동일한 모델 내의 모든 컴퓨터가 취약해질 수 있다는 것입니다. 이는 데스크톱 PC에 대해 Microsoft에서 권장합니다.
제품군당 하나. 키가 손상되면 전체 제품군이 취약해질 수 있습니다.
OEM당 하나. 설정이 가장 간단할 수 있지만 키가 손상되면 제조하는 모든 PC가 취약해질 수 있습니다. 공장 현장에서의 작업 속도를 높이기 위해 PK 및 잠재적으로 다른 키를 미리 생성하여 안전한 위치에 저장할 수 있습니다. 나중에 회수하여 조립 라인에서 사용할 수 있습니다. 2장과 3장에 더 자세한 내용이 있습니다.
1.3.3.4 PK 재입력
이는 PK가 손상된 경우 또는 보안상의 이유로 자체 PK를 등록하기로 결정할 수 있는 고객의 요구 사항으로 필요할 수 있습니다.
PK를 만들기 위해 선택한 방법에 따라 모델 또는 PC에 대해 키 다시 지정을 수행할 수 있습니다. 모든 최신 PC는 새로 만들어진 PK로 서명됩니다.
프로덕션 PC에서 PK를 업데이트하려면 PK를 대체하는 기존 PK로 서명된 변수 업데이트 또는 펌웨어 업데이트 패키지가 필요합니다. OEM은 SetVariable() 패키지를 만들고 PK만 변경하는 PowerShell과 같은 간단한 애플리케이션으로 배포할 수도 있습니다. 펌웨어 업데이트 패키지는 보안 펌웨어 업데이트 키로 서명되고 펌웨어로 확인됩니다. PK를 업데이트하기 위해 펌웨어 업데이트를 수행하는 경우 KEK, db 및 dbx가 보존되도록 주의해야 합니다.
모든 PC에서 PK를 보안 펌웨어 업데이트 키로 사용하지 않는 것이 좋습니다. PKpriv가 손상되면 보안 펌웨어 업데이트 키도 손상됩니다(동일하기 때문에). 이 경우 업데이트 프로세스도 손상되었기 때문에 새 PKpub 등록 업데이트가 불가능할 수 있습니다.
SOC PC에서 PK를 보안 펌웨어 업데이트 키로 사용하지 않는 또 다른 이유가 있습니다. 보안 펌웨어 업데이트 키가 Windows 하드웨어 인증 요구 사항을 충족하는 PC의 퓨즈에 영구적으로 연소되기 때문입니다.
1.3.4 KEK(키 교환 키) 키 교환 키는 운영 체제와 플랫폼 펌웨어 간의 신뢰 관계를 설정합니다. 각 운영 체제(및 잠재적으로 플랫폼 펌웨어와 통신해야 하는 각 타사 애플리케이션)는 공개 키(KEKpub)를 플랫폼 펌웨어에 등록합니다.
1.3.4.1 키 교환 키 등록
키 교환 키는 1.4 서명 데이터베이스(Db 및 Dbx))에 설명된 대로 서명 데이터베이스에 저장됩니다. 서명 데이터베이스는 인증된 UEFI 변수로 저장됩니다.
플랫폼 소유자는 특성이 설정된
EFI_VARIABLE_APPEND_WRITE2.3.1 Errata C의 섹션 7.2(가변 서비스)에 지정된 대로 SetVariable()와 새 키를 포함하는 Data 매개 변수를 호출하거나, GetVariable()을 사용하여 데이터베이스를 읽고 기존 키에 새 키 교환 키를 추가한 다음 특성이 설정되지 않은EFI_VARIABLE_APPEND_WRITE2.3.1 정오표 C의 섹션 7.2(가변 서비스)에 지정된 대로 SetVariable()을 통해 데이터베이스를 작성하여 키 교환 키를 등록합니다.플랫폼이 설정 모드에 있는 경우 서명 데이터베이스 변수에 서명할 필요가 없지만 SetVariable() 호출에 대한 매개 변수는 여전히 섹션 7.2.1에서 인증된 변수에 대해 지정된 대로 준비되어야 합니다. 플랫폼이 사용자 모드인 경우 서명 데이터베이스는 현재 PKpriv로 서명해야 합니다.
1.3.4.2 KEK 지우기
KEK를 "지우기"(삭제)할 수 있습니다. PK가 플랫폼에 설치되어 있지 않으면 "지우기" 요청에 서명할 필요가 없습니다. 서명된 경우 KEK를 지우려면 PK 서명 패키지가 필요하고 db 또는 dbx를 지우려면 KEK에 있는 엔터티에서 서명한 패키지가 필요합니다.
1.3.4.3 Microsoft KEK
다음 Microsoft KEK 인증서는 dbx를 업데이트하고 잠재적으로 최신 Windows 서명된 이미지를 준비하기 위해 db를 업데이트하여 잘못된 이미지를 해지할 수 있도록 하는 데 필요합니다.
Microsoft Corporation KEK 2K CA 2023
- SHA-1 인증서 해시:
459AB6FB5E284D272D5E3E6ABC8ED663829D632B. - 서명 소유자 GUID:
{77fa9abd-0359-4d32-bd60-28f4e78f784b}. - Microsoft는 파트너에게 인증서를 제공하며
EFI_CERT_X509_GUID또는EFI_CERT_RSA2048_GUID유형 서명으로 추가할 수 있습니다. - Microsoft KEK 인증서는 https://go.microsoft.com/fwlink/?linkid=2239775에서 다운로드할 수 있습니다.
- SHA-1 인증서 해시:
1.3.4.4 KEKDefault 플랫폼 공급업체는 KEKDefault 변수에 기본 키 Exchange 키 집합을 제공해야 합니다. 자세한 내용은 UEFI 사양 섹션 27.3.3을 참조하세요.
1.3.4.5 OEM/타사 KEK - 여러 KEK 추가
고객과 플랫폼 소유자는 자신의 KEK를 가질 필요가 없습니다. Windows RT가 아닌 PC에서 OEM은 추가 OEM 또는 db 및 dbx의 신뢰할 수 있는 타사 제어를 허용하기 위해 추가 KEK를 가질 수 있습니다.
1.3.5 보안 부팅 펌웨어 업데이트 키보안 펌웨어 업데이트 키는 업데이트가 필요할 때 펌웨어에 서명하는 데 사용됩니다. 이 키는 RSA-2048의 최소 키 강도를 가져야 합니다. 모든 펌웨어 업데이트는 OEM, ODM 또는 IBV(독립 BIOS 공급업체)와 같은 신뢰할 수 있는 대리자 또는 보안 서명 서비스에서 안전하게 서명해야 합니다.
NIST 간행물 800-147 Field Firmware Update에 따라 다음 지침의 모든 요소를 지원해야 합니다.
펌웨어 플래시 저장소에 대한 모든 업데이트는 작성자가 서명해야 합니다.
펌웨어는 업데이트 서명을 확인해야 합니다.
1.3.6 보안 펌웨어 업데이트용 키 만들기
공용 절반이 PC에 상주할 것이기 때문에 모든 펌웨어 업데이트에 서명하는 데 동일한 키가 사용됩니다. 보안 펌웨어 업데이트 키에 연결된 키로 펌웨어 업데이트에 서명할 수도 있습니다.
PK와 같이 PC당 하나의 키가 있거나 모델당 하나 또는 제품군당 하나의 키가 있을 수 있습니다. PC당 하나의 키가 있는 경우 수백만 개의 고유한 업데이트 패키지를 생성해야 합니다. 리소스 가용성에 따라 어떤 방법이 적합한지 고려합니다. 모델 또는 제품군별로 키를 갖는 것은 좋은 절충안입니다.
보안 펌웨어 업데이트 공개 키(또는 공간 절약을 위한 해시)는 일반적으로 보호되는 플랫폼(PC) 또는 일회용 프로그래밍 가능한 퓨즈(SOC)의 일부 보호된 스토리지에 저장됩니다.
이 키의 해시만 저장되면(공간 절약을 위해) 펌웨어 업데이트에 키가 포함되고 업데이트 프로세스의 첫 번째 단계는 업데이트의 공개 키가 플랫폼에 저장된 해시와 일치하는지 확인하는 것입니다.
캡슐은 OS가 다시 부팅 시 UEFI 환경에 데이터를 전달할 수 있는 수단입니다. Windows는 UEFI UpdateCapsule()을 호출하여 시스템 및 PC 펌웨어 업데이트를 제공합니다. ExitBootServices()를 호출하기 전에 부팅할 때 Windows는 Windows 드라이버 저장소에 있는 새 펌웨어 업데이트를 UpdateCapsule()에 전달합니다. UEFI 시스템 펌웨어는 이 프로세스를 사용하여 시스템 및 PC 펌웨어를 업데이트할 수 있습니다. 이 Windows 펌웨어 지원을 활용하여 OEM은 시스템 및 PC 펌웨어 모두에 대한 펌웨어 업데이트를 위해 동일한 공통 형식 및 프로세스에 의존할 수 있습니다. Windows용 UEFI UpdateCapsule()을 지원하려면 펌웨어가 ACPI ESRT 테이블을 구현해야 합니다.
Windows UEFI 펌웨어 업데이트 플랫폼 지원 구현에 대한 자세한 내용은 Windows UEFI 펌웨어 업데이트 플랫폼 설명서를 참조하세요.
업데이트 캡슐은 메모리나 디스크에 있을 수 있습니다. Windows는 메모리 업데이트를 지원합니다.
1.3.6.1 캡슐(메모리 캡슐)
다음은 메모리 내 업데이트 캡슐이 작동하기 위한 이벤트 흐름입니다.
- 캡슐은 OS의 애플리케이션에 의해 메모리에 저장됩니다.
- BIOS에 보류 중인 업데이트를 알리도록 사서함 이벤트가 설정되었습니다.
- PC 다시 부팅, 캡슐 이미지 확인 및 BIOS에서 업데이트 수행
1.3.7 일반적인 펌웨어 업데이트의 워크플로
- 펌웨어 드라이버를 다운로드하여 설치합니다.
- 다시 부팅하세요.
- OS Loader는 펌웨어를 검색하고 확인합니다.
- OS 로더는 바이너리 Blob을 UEFI에 전달합니다.
- UEFI는 펌웨어 업데이트를 수행합니다(이 프로세스는 실리콘 공급업체 소유).
- OS 로더 검색이 성공적으로 완료되었습니다.
- OS 부팅이 완료됩니다.
1.4 서명 데이터베이스(Db 및 Dbx)
1.4.1 허용된 서명 데이터베이스(db)
EFI
_IMAGE_SECURITY_DATABASEdb의 내용은 로드된 이미지를 확인할 때 신뢰할 수 있는 이미지를 제어합니다. 데이터베이스에는 허용된 이미지를 식별하기 위해 여러 인증서, 키 및 해시가 포함될 수 있습니다.Windows OS 로더가 로드될 수 있도록 하려면 다음 인증서를 db에 포함해야 합니다.
-
Windows UEFI CA 2023
- SHA-1 인증서 해시:
45A0FA32604773C82433C3B7D59E7466B3AC0C67. - 서명 소유자 GUID:
{77fa9abd-0359-4d32-bd60-28f4e78f784b}. - Microsoft는 파트너에게 인증서를 제공하며
EFI_CERT_X509_GUID또는EFI_CERT_RSA2048_GUID유형 서명으로 추가할 수 있습니다. - Windows UEFI CA 2023은 여기에서 https://go.microsoft.com/fwlink/?linkid=2239776다운로드할 수 있습니다.
- SHA-1 인증서 해시:
Windows 부팅 전용으로 잠긴 시스템을 제외하고 OEM은 타사의 UEFI 드라이버 및 응용 프로그램이 사용자에 대한 추가 단계를 요구하지 않고 PC에서 실행되도록 Microsoft 타사 UEFI CA 및 Microsoft Option ROM CA를 포함하는 것을 고려해야 합니다.
Microsoft Corporation UEFI CA 2011
- SHA-1 인증서 해시:
46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3. - 서명 소유자 GUID:
{77fa9abd-0359-4d32-bd60-28f4e78f784b}. - Microsoft는 파트너에게 인증서를 제공하며
EFI_CERT_X509_GUID또는EFI_CERT_RSA2048_GUID유형 서명으로 추가할 수 있습니다. - Microsoft Corporation UEFI CA 2011은 여기에서 https://go.microsoft.com/fwlink/p/?linkid=321194다운로드할 수 있습니다.
- SHA-1 인증서 해시:
Microsoft UEFI CA 2023
- SHA-1 인증서 해시:
B5EEB4A6706048073F0ED296E7F580A790B59EAA. - 서명 소유자 GUID:
{77fa9abd-0359-4d32-bd60-28f4e78f784b}. - Microsoft는 파트너에게 인증서를 제공하며
EFI_CERT_X509_GUID또는EFI_CERT_RSA2048_GUID유형 서명으로 추가할 수 있습니다. - Microsoft UEFI CA 2023은 여기에서 https://go.microsoft.com/fwlink/?linkid=2239872다운로드할 수 있습니다.
- SHA-1 인증서 해시:
Microsoft Option ROM UEFI CA 2023
- SHA-1 인증서 해시:
3FB39E2B8BD183BF9E4594E72183CA60AFCD4277. - 서명 소유자 GUID:
{77fa9abd-0359-4d32-bd60-28f4e78f784b}. - Microsoft는 파트너에게 인증서를 제공하며
EFI_CERT_X509_GUID또는EFI_CERT_RSA2048_GUID유형 서명으로 추가할 수 있습니다. - Microsoft Option ROM UEFI CA 2023은 여기에서 https://go.microsoft.com/fwlink/?linkid=2284009다운로드할 수 있습니다.
- SHA-1 인증서 해시:
1.4.2 DbDefault: 플랫폼 공급업체는 dbDefault 변수에 서명 데이터베이스에 대한 기본 항목 집합을 제공해야 합니다. 자세한 내용은 UEFI 사양의 섹션 27.5.3을 참조하세요.
1.4.3 금지된 서명 데이터베이스(dbx)
db를 확인하기 전에 이미지를 확인할 때
EFI_IMAGE_SIGNATURE_DATABASE1dbx의 내용을 확인해야 하며 일치하는 항목이 있으면 이미지가 실행되지 않도록 해야 합니다. 데이터베이스에는 금지된 이미지를 식별하기 위해 여러 인증서, 키 및 해시가 포함될 수 있습니다. Windows 하드웨어 인증 요구 사항에 따르면 dbx가 있어야 하므로0의 SHA-256 해시와 같은 모든 더미 값은 Microsoft가 dbx 업데이트 제공을 시작할 때까지 안전한 자리 표시자로 사용할 수 있습니다. 여기를 클릭하여 Microsoft에서 최신 UEFI 해지 목록을 다운로드합니다.1.4.4 DbxDefault: 플랫폼 공급업체는 dbxDefault 변수에 서명 데이터베이스에 대한 기본 항목 집합을 제공할 수 있습니다. 자세한 내용은 UEFI 사양의 섹션 27.5.3을 참조하세요.
1.5 모든 PC의 보안 부팅에 필요한 키
참고 항목
디바이스 OEM, 엔터프라이즈 및 고객은 Microsoft의 Secure Boot 오픈 소스 리포지토리에서 Microsoft 권장 PK, KEK, DB 및 DBX 이진 파일을 찾을 수 있습니다. 이진 파일은 펌웨어에 쉽게 통합할 수 있도록 필요한 EDKII 형식으로 포맷됩니다.
| 키/DB 이름 | 변수 | 담당자 | 주의 |
|---|---|---|---|
PKpub |
PK (한국어) |
OEM(제조업체) |
PK – 1 전용. RSA 2048 이상이어야 합니다. |
Microsoft Corporation KEK 2K CA 2023 | KEK |
Microsoft |
db 및 dbx에 대한 업데이트 허용: |
Windows UEFI CA 2023 | 데이터베이스 |
Microsoft |
서명 데이터베이스(db)의 이 CA를 사용하면 Windows에서 다음을 부팅할 수 있습니다. https://go.microsoft.com/fwlink/?LinkId=2239776 |
금지된 서명 데이터베이스 |
dbx |
Microsoft |
Microsoft의 알려진 잘못된 키, CA 또는 이미지 목록 |
보안 펌웨어 업데이트 키 |
OEM(제조업체) |
이 키를 PK와 다르게 사용하는 것이 좋습니다. |
표 1: 보안 부팅에 필요한 키/db
2. 주요 관리 솔루션
아래는 비교에 사용한 몇 가지 메트릭입니다.
2.1 사용된 메트릭
다음 메트릭은 UEFI 사양 2.3.1 Errata C의 요구 사항 및 필요에 따라 HSM PC를 선택하는 데 도움이 될 수 있습니다.
PKI(공개 키 인프라) 관련
- RSA 2048 이상을 지원하나요? - UEFI 사양 2.3.1 Errata C는 키가 RSA-2048 이상일 것을 권장합니다.
- 키를 생성하고 서명하는 기능이 있나요?
- 얼마나 많은 키를 저장할 수 있나요? HSM 또는 연결된 서버에 키를 저장하나요?
- 키 검색을 위한 인증 방법입니다. 일부 PC는 키 검색을 위해 여러 인증 엔터티를 지원합니다.
가격 책정
- 가격 포인트는 무엇인가요? HSM의 가격은 사용 가능한 기능에 따라 $1,500에서 $70,000 사이입니다.
제조 환경
- 공장 현장에서의 작업 속도. 암호화 프로세서는 키 만들기 및 액세스 속도를 높일 수 있습니다.
- 설정, 배포, 유지 관리가 간편합니다.
- 기술과 학습이 필요하나요?
- 백업 및 고가용성을 위한 네트워크 액세스
표준 및 규정 준수
- FIPS 준수 수준은 어느 정도인가요? 변조 방지 기능이 있나요?
- MS 암호화 API와 같은 다른 표준에 대한 지원.
- 정부 및 기타 기관 요구 사항을 충족하나요?
안정성 및 재해 복구
키 백업을 허용하나요?
백업은 CA 컴퓨터 및 HSM과 물리적 위치가 다른 안전한 위치 및/또는 오프사이트 위치에 둘 다 저장할 수 있습니다.
재해 복구를 위한 고가용성을 허용하나요?
2.2 키 관리 옵션
2.2.1 HSM(하드웨어 보안 모듈)
위의 기준에 따르면 이는 아마도 가장 적합하고 안전한 솔루션일 것입니다. 대부분의 HSM은 FIPS 140-2 수준 3을 준수합니다. FIPS 140-2 수준 3 준수는 인증에 대해 엄격하며 키를 HSM에서 내보내거나 가져오지 않도록 요구합니다.
다양한 방법의 키 스토리지를 지원합니다. HSM 자체 또는 HSM에 연결된 서버에 로컬로 저장할 수 있습니다. 서버에서 키는 암호화되어 저장되며 많은 키를 저장해야 하는 솔루션에 적합합니다.
암호화 모듈 보안 정책은 변조 방지 봉인, 잠금 장치, 변조 대응 및 제로화 스위치, 경보와 같은 암호화 모듈에서 구현되는 물리적 보안 메커니즘을 포함하는 물리적 보안 정책을 지정해야 합니다. 또한 조작자가 물리적 보안이 유지되도록 하기 위해 조작자가 요구하는 작업을 지정할 수 있습니다. 예를 들어 조작 방지 봉인의 정기 검사 또는 조작 응답 및 제로화 스위치 테스트와 같은 것입니다.
2.2.1.1 네트워크 HSM
이 솔루션은 보안, 표준 준수, 키 생성, 스토리지 및 검색 측면에서 동급 최고입니다. 이러한 PC의 대부분은 고가용성을 지원하고 키를 백업할 수 있습니다.
이러한 제품의 비용은 제공하는 추가 서비스에 따라 수만 달러에 이를 수 있습니다.
2.2.1.2 독립형 HSM
독립 실행형 서버에서 잘 작동합니다. Microsoft CAPI 및 CNG 또는 HSM에서 지원하는 기타 보안 API를 사용할 수 있습니다. 이러한 HSM은 USB, PCIe 및 PCMCIA 버스를 지원하는 다양한 폼 팩터로 제공됩니다.
선택적으로 키 백업 및 고가용성을 지원합니다.
2.2.2 사용자 지정 솔루션 공급자
공개 키 암호화는 어려울 수 있으며 새로운 암호화 개념에 대한 이해가 필요합니다. 제조 환경에서 Secure Boot를 작동시키는 데 도움을 줄 수 있는 사용자 지정형 솔루션 공급자가 있습니다.
BIOS 공급업체, HSM 회사 및 PKI 컨설팅 회사에서 보안 부팅 PKI가 제조 환경에서 작동하도록 하기 위해 다양한 사용자 지정형 솔루션을 제공합니다.
일부 공급자는 다음과 같습니다.
2.2.2.1 BIOS 공급업체
사용자 지정형 솔루션을 제공할 수 있는 일부 BIOS 공급업체가 있습니다.
2.2.2.2 HSM 공급업체
일부 HSM 공급업체는 사용자 지정형 컨설팅을 제공할 수 있습니다. 자세한 내용은 HSM을 사용한 보안 부팅 키 생성 및 서명(예시)을 참조하세요.
2.2.3 TPM(신뢰할 수 있는 플랫폼 모듈)
TPM(신뢰할 수 있는 플랫폼 모듈)은 암호화에 사용되는 암호화 키를 저장하는 마더보드의 하드웨어 칩입니다. 많은 컴퓨터에 TPM이 포함되어 있지만 PC에 TPM이 없으면 추가할 수 없습니다. 사용하도록 설정되면 신뢰할 수 있는 플랫폼 모듈은 Microsoft BitLocker 기능과 같은 전체 디스크 암호화 제품을 보호하는 데 도움이 될 수 있습니다. PC가 시스템 확인 또는 인증 프로세스를 완료할 때까지 하드 드라이브를 잠그거나 밀봉한 상태로 유지합니다.
TPM은 암호화 및 암호 해독 프로세스에 사용되는 키를 생성, 저장 및 보호할 수 있습니다.
TPM의 단점은 제조 환경에서 처리 속도를 높이는 빠른 암호화 프로세서가 없을 수 있다는 것입니다. 또한 많은 수의 키를 저장하는 데 적합하지 않습니다. FIPS 140-2 수준 3에 대한 백업 및 고가용성 및 표준 준수를 사용하지 못할 수 있습니다.
2.2.4 스마트 카드
스마트 카드는 키를 생성하고 저장할 수 있습니다. 인증 및 변조 방지와 같이 HSM이 지원하는 일부 기능을 공유하지만 많은 키 스토리지 또는 백업이 포함되어 있지 않습니다. 수동 개입이 필요하며 성능이 낮을 수 있으므로 자동화 및 프로덕션 환경에서 사용하기에 적합하지 않을 수 있습니다.
스마트 카드의 단점은 TPM과 유사합니다. 제조 환경에서 처리 속도를 높이는 빠른 암호화 프로세서가 없을 수 있습니다. 또한 많은 수의 키를 저장하는 데 적합하지 않습니다. FIPS 140-2 수준 3에 대한 백업 및 고가용성 및 표준 준수를 사용하지 못할 수 있습니다.
2.2.5 확장 유효성 검사 인증서
EV 인증서는 프라이빗 키가 하드웨어 토큰에 저장되는 높은 보증 인증서입니다. 이는 보다 강력한 키 관리 방식을 수립하는 데 도움이 됩니다. EV 인증서는 스마트 카드와 동일한 단점이 있습니다.
2.2.6 소프트웨어 중심 접근 방식(권장하지 않음)
키 관리를 위해 암호화 API를 사용합니다. 여기에는 암호화된 하드 드라이브의 키 컨테이너에 키를 저장하는 것이 포함될 수 있으며 가상 머신을 사용하여 추가 샌드박싱 및 보안이 가능합니다.
이러한 솔루션은 HSM을 사용하는 것만큼 안전하지 않으며 더 높은 공격 벡터를 노출합니다.
2.2.6.1 Makecert(권장하지 않음)
Makecert는 Microsoft 도구이며 키 생성을 위해 다음과 같이 사용할 수 있습니다. 공격 표면을 최소화하려면 PC를 "에어 갭"해야 할 수도 있습니다. PKpriv가 켜져 있는 PC는 네트워크에 연결되지 않아야 합니다. 안전한 위치에 있어야 하며 실제 HSM이 아닌 경우 최소한 스마트 카드 판독기를 사용해야 합니다.
makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r자세한 내용은 인증서 만들기 도구(Makecert.exe)를 참조하세요.
이 솔루션은 권장되지 않습니다.
2.3 보안 부팅 키용 HSM 키 생성 및 스토리지
2.3.1 프라이빗 키 저장
각 RSA-2048 키에 대한 공간 요구 사항은 2048비트입니다. 키 스토리지의 실제 위치는 선택한 솔루션에 따라 다릅니다. HSM은 키를 저장하는 좋은 방법입니다.
공장 현장에서 PC의 물리적 위치는 보안 케이지와 같이 사용자 액세스가 제한된 보호 구역이어야 합니다.
요구 사항에 따라 이러한 키를 다양한 지리적 위치에 저장하거나 다른 위치에 백업할 수도 있습니다.
이러한 키에 대한 키 다시 제작 요구 사항은 고객에 따라 다를 수 있습니다(연방 브리지 인증 기관 키 다시 제작 지침은 부록 A 참조).
이러한 작업은 1년에 한 번 수행할 수 있습니다. 최대 30년 동안 이러한 키에 액세스해야 할 수 있습니다(키 재입력 요구 사항 등에 따라 다름).
2.3.2 프라이빗 키 검색
여러 가지 이유로 키를 검색해야 할 수 있습니다.
- 업데이트된 PK를 발급하기 위해 PK가 손상되었거나 정부/기타 기관 규정을 준수하기 위해 PK를 검색해야 할 수 있습니다.
- KEKpri는 db 및 dbx를 업데이트하는 데 사용됩니다.
- 보안 펌웨어 업데이트 키 pri는 최신 업데이트에 서명하는 데 사용됩니다.
2.3.3 인증
FIPS 140-2에 따라 인증은 액세스 수준을 기반으로 합니다.
수준 2
보안 수준 2는 최소한 암호화 모듈이 특정 역할을 맡고 해당 서비스 세트를 수행하기 위해 운영자의 권한을 인증하는 역할 기반 인증을 요구합니다.
수준 3
보안 수준 3에는 ID 기반 인증 메커니즘이 필요하여 보안 수준 2에 대해 지정된 역할 기반 인증 메커니즘이 제공하는 보안을 강화합니다. 암호화 모듈은 운영자의 ID를 인증하고 식별된 운영자가 특정 역할을 맡아 해당 서비스 세트를 수행할 권한이 있는지 확인합니다.
HSM과 같은 PC는 ID 기반 "k of m 인증"이 필요한 보안 수준 3을 지원합니다. 이는 k 엔티티에 토큰으로 HSM에 대한 액세스 권한이 부여되지만 HSM에서 프라이빗 키에 대한 액세스를 가져오기 위해 인증이 작동하려면 주어진 시점에서 m 토큰 중 k개 이상이 있어야 함을 의미합니다.
예를 들어 HSM에 액세스하려면 토큰 5개 중 3개를 인증해야 할 수 있습니다. 이러한 멤버는 보안 책임자, 트랜잭션 승인자 및/또는 경영진의 멤버일 수 있습니다.
HSM 토큰
토큰이 있어야 하는 HSM에 대한 정책이 있을 수 있습니다.
로컬로
원격
자동화되도록 구성됨
좋은 방법으로 토큰과 토큰별 암호를 조합하여 사용합니다.
2.4 보안 부팅 및 타사 서명
2.4.1 UEFI 드라이버 서명
UEFI 드라이버는 문서의 다른 부분에 설명된 대로 db의 CA 또는 키에 의해 서명되거나 db에 포함된 드라이버 이미지의 해시가 있어야 합니다. Microsoft는 Microsoft UEFI CA 2023을 사용하여 WHQL 드라이버 서명 서비스와 유사한 UEFI 드라이버 서명 서비스를 제공할 예정입니다. 이에 의해 서명된 모든 드라이버는 Microsoft UEFI CA가 포함된 모든 PC에서 원활하게 실행됩니다. OEM이 신뢰할 수 있는 드라이버에 서명하고 db에 OEM CA를 포함하거나 db에 드라이버의 해시를 포함할 수도 있습니다. 모든 경우에 UEFI 드라이버(옵션 ROM)는 db에서 신뢰할 수 없는 경우 실행되지 않습니다.
시스템 펌웨어 이미지에 포함된 모든 드라이버는 다시 확인할 필요가 없습니다. 전체 시스템 이미지의 일부가 되는 것은 드라이버가 PC에서 신뢰할 수 있다는 충분한 보증을 제공합니다.
Microsoft는 UEFI 드라이버에 서명하려는 모든 사람이 이를 사용할 수 있도록 했습니다. 이 인증서는 Windows HCK 보안 부팅 테스트의 일부입니다. UEFI CA 서명 정책 및 업데이트에 대해 자세히 알아보려면 [이 블로그]((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/)를 팔로우합니다.
2.4.2 부트 로더
Microsoft UEFI 드라이버 서명 인증서는 다른 OS에 서명하는 데 사용할 수 있습니다. 예를 들어, Fedoras Linux 부트 로더는 이에 의해 서명됩니다.
이 솔루션은 Db 키에 인증서를 더 이상 추가할 필요가 없습니다. 비용 효율적일 뿐만 아니라 모든 Linux 배포판에 사용할 수 있습니다. 이 솔루션은 Windows를 지원하는 모든 하드웨어에서 작동하므로 광범위한 하드웨어에 유용합니다.
UEFI-CA는 https://go.microsoft.com/fwlink/p/?LinkID=321194에서 다운로드할 수 있습니다. 다음 링크에는 Windows HCK UEFI 서명 및 제출에 대한 자세한 정보가 있습니다.
3. 요약 및 리소스
이 섹션에서는 위 섹션을 요약하고 단계별 접근 방식을 보여 줍니다.
보안 CA를 설정하거나 파트너를 식별하여 키를 안전하게 생성 및 저장합니다.
타사 솔루션을 사용하지 않는 경우:
HSM 서버에 HSM 소프트웨어를 설치하고 구성합니다. 설치 지침은 HSM 참조 설명서를 확인합니다. 서버는 독립 실행형 또는 네트워크 HSM에 연결됩니다.
HSM 구성에 대한 정보는 섹션 2.2.1, 2.3 및 부록 C를 참조하세요.
대부분의 HSM은 FIPS 140-2 수준 2 및 3 준수를 제공합니다. 수준 2 또는 수준 3 규정 준수를 위해 HSM을 구성합니다. 수준 3 규정 준수는 인증 및 키 액세스에 대한 요구 사항이 더 엄격하므로 더 안전합니다. 수준 3을 권장합니다.
고가용성, 백업 및 인증을 위해 HSM을 구성합니다. HSM 참조 설명서를 확인합니다.
고가용성 및 백업을 위한 HSM 설정에 대한 HSM 공급자 지침을 따릅니다.
또한 네트워크 HSM에는 일반적으로 트래픽을 분리하기 위한 여러 네트워크 포트가 있습니다. 서버가 일반 프로덕션 네트워크와 별도의 네트워크에서 네트워크 HSM과 통신할 수 있도록 합니다.
보안 팀의 일원인 팀 구성원이 식별되고 토큰이 할당되면. k-of-m 인증을 위해 HSM 하드웨어를 설정해야 합니다.
보안 부팅 키 및 인증서 사전 생성. 섹션 1.3 ~ 1.5 참조
HSM API를 사용하여 PK 및 펌웨어 업데이트 키 및 인증서를 사전 생성(미리 생성)합니다.
필수 - PK(모델당 1개 권장), 펌웨어 업데이트 키(모델당 1개 권장), Microsoft KEK, Db, Dbx참고: Microsoft KEK, db 및 dbx는 OEM에서 생성할 필요가 없으며 완전성을 위해 언급되었습니다(선택 사항 - OEM/타사 KEK db, dbx 및 OEM Db에 들어갈 기타 키).
Windows 이미지를 PC에 적용합니다.
Microsoft db 및 dbx를 설치합니다. 섹션 1.3.6 및 부록 B – 보안 부팅 API를 참조하세요.
Windows UEFI CA 2023을 db에 설치합니다.
Microsoft에서 제공하지 않는 경우 빈 dbx를 설치합니다. Windows는 처음 다시 부팅할 때 Windows 업데이트를 통해 DBX를 최신 DBX로 자동 업데이트합니다.
참고 항목
Windows HCK 테스트의 일부인 PowerShell cmdlet을 사용하거나 BIOS 공급업체에서 제공하는 방법을 사용합니다.
Microsoft KEK를 설치합니다. 섹션 1.3.3을 참조하세요.
UEFI KEK 데이터베이스에 Microsoft KEK 설치
주의
Windows HCK 테스트의 일부인 PowerShell cmdlet을 사용하거나 BIOS 공급업체에서 제공하는 방법을 사용합니다.
선택적 단계 - OEM/타사 보안 부팅 구성 요소. 섹션 1.3.4 및 1.4를 참조하세요.
OEM/타사 KEK, db 및 dbx를 만들어야 하는지 확인합니다.
HSM API를 사용하여 OEM/타사 KEK(이전에 생성됨)로 OEM/타사 db 및 dbx에 서명합니다.
OEM/타사 KEK, db 및 dbx를 설치합니다.
UEFI 드라이버 서명 – 섹션 2.4를 참조하세요.
추가 기능 카드 또는 기타 UEFI 드라이버/앱/부팅 로더를 지원하는 경우 Microsoft UEFI CA 2023 및 Microsoft Corporation UEFI CA 2011 을 UEFI db에 설치합니다.
보안 부팅 펌웨어 업데이트 키 - 섹션 1.3.5 참조.
비 Windows RT PC만 해당: 보안 펌웨어 업데이트 공개 키 또는 해시를 설치하여 공간을 절약합니다.
SoC에서만 다른 작업을 수행해야 할 수 있습니다(예: 보안 펌웨어 업데이트 키: 공개 또는 해당 해시 굽기).
보안 부팅 사용하도록 설정. 부록 B – 보안 부팅 API를 참조하세요.
OEM/ODM PKpub(인증서가 기본 설정되지만 키는 괜찮음)를 UEFI PK에 설치합니다.
Secure Boot API를 사용하여 PK를 등록합니다. 이제 PC에서 보안 부팅이 사용하도록 설정되어야 합니다.
참고 항목
마지막에 PK를 설치하면 MS KEK, db, dbx에 서명할 필요가 없으며 SignerInfo가 없어도 됩니다. 이는 바로 가기입니다.
보안 부팅 테스트: 지침에 따라 독점 테스트 및 Windows HCK 테스트를 실행합니다. 부록 B – 보안 부팅 API를 참조하세요.
배송 플랫폼: PKpriv는 다시는 사용되지 않을 것이므로 안전하게 보관합니다.
서비스: 향후 펌웨어 업데이트는 서명 서비스를 사용하여 보안 펌웨어 업데이트 "프라이빗" 키로 안전하게 서명됩니다.
3.1 리소스
보안 전략 백서 - https://go.microsoft.com/fwlink/p/?linkid=321288
Windows HCK 제출 -https://go.microsoft.com/fwlink/p/?linkid=321287
부록 A – 제조를 위한 보안 부팅 PKI 검사 목록
다음은 비 Windows RT PC에서 보안 부팅을 사용하도록 설정하는 데 필요한 단계를 요약한 상위 수준 검사 목록입니다.
보안 부팅 설정
섹션 4의 백서에 따라 보안 전략을 정의합니다(위협 식별, 사전 예방 및 사후 전략 정의).
섹션 4의 백서에 따라 보안 팀을 식별합니다.
보안 CA를 설정하거나 파트너를 식별(권장 솔루션)하여 키를 안전하게 생성 및 저장합니다.
키를 다시 입력하는 빈도에 대한 정책을 식별합니다. 이는 정부 또는 기타 기관과 같은 특별한 고객 요구 사항이 있는지 여부에 따라 달라질 수 있습니다.
보안 부팅 키가 손상된 경우에 대비하여 대체 계획을 세우세요.
섹션 1.3.3 및 1.5에 따라 생성할 PK 및 기타 키의 수를 식별합니다.
이는 고객 기반, 키 스토리지 솔루션 및 PC 보안을 기반으로 합니다.
키 관리에 타사를 사용하는 권장 솔루션을 사용하는 경우 7~8단계를 건너뛸 수 있습니다.
키 관리를 위한 서버 및 하드웨어를 조달합니다. 섹션 2.2.1에 따라 네트워크 또는 독립형 HSM. 고가용성과 키 백업 전략을 위해 하나 또는 여러 HSM이 필요한지 여부를 고려합니다.
HSM에서 인증을 위한 인증 토큰을 가질 최소 3~4명의 팀 구성원을 식별합니다.
HSM 또는 타사를 사용하여 보안 부팅 관련 키 및 인증서를 미리 생성합니다. 키는 PC 유형(SoC, Windows RT 또는 비 Windows RT)에 따라 다릅니다. 자세한 내용은 섹션 1.3~1.5를 참조하세요.
적절한 키로 펌웨어를 채웁니다.
보안 부팅을 사용하도록 설정하려면 보안 부팅 플랫폼 키를 등록합니다. 자세한 내용은 부록 B를 참조하세요.
지침에 따라 독점 테스트 및 HCK 보안 부팅 테스트를 실행합니다. 자세한 내용은 부록 B를 참조하세요.
PC를 배송합니다. PKpriv는 다시는 사용되지 않을 것이므로 안전하게 보관합니다.
서비스(펌웨어 업데이트)
UEFI 구성 요소 업데이트 또는 보안 부팅 키 손상 수정 또는 보안 부팅 키의 주기적 재입력과 같은 여러 가지 이유로 펌웨어를 업데이트해야 할 수 있습니다.
자세한 내용은 섹션 1.3.5 및 섹션 1.3.6을 참조하세요.
부록 B - 보안 부팅 API
보안 부팅 API
다음 API는 UEFI/보안 부팅과 관련됩니다.
GetFirmwareEnvironmentVariableEx: 지정된 펌웨어 환경 변수의 값을 검색합니다.
SetFirmwareEnvironmentVariableEx: 지정된 펌웨어 환경 변수의 값을 설정합니다.
GetFirmwareType: 펌웨어 유형을 검색합니다.
PK 설정
Set-SecureBootUEFI cmdlet을 사용하여 보안 부팅을 켭니다. 코드가 PK를 설정한 후 보안 부팅의 시스템 적용은 다음에 다시 부팅할 때까지 적용되지 않습니다. 다시 부팅하기 전에 코드에서 GetFirmwareEnvironmentVariableEx() 또는 PowerShell cmdlet: Get-SecureBootUEFI를 호출하여 보안 부팅 데이터베이스의 내용을 확인할 수 있습니다.
확인
Msinfo32.exe 또는 PowerShell cmdlet을 사용하여 보안 부팅 변수 상태를 확인할 수 있습니다. WMI 인터페이스가 없습니다. 누군가에게 잘못 서명된 부팅 가능한 USB 스틱(예: Windows HCK 보안 부팅 수동 로고 테스트)을 삽입하여 부팅에 실패하는지 확인하도록 하여 테스트할 수도 있습니다.
보안 부팅 Powershell Cmdlet
Confirm-SecureBootUEFI: UEFI 보안 부팅이 "ON"인가요, True 또는 False인가요?
SetupMode == 0 && SecureBoot == 1
Set-SecureBootUEFI: 인증된 SecureBoot UEFI 변수 설정 또는 추가
Get-SecureBootUEFI: 인증된 SecureBoot UEFI 변수 값 가져오기
Format-SecureBootUEFI: EFI_SIGNATURE_LISTs 및 EFI_VARIABLE_AUTHENTICATION_2 serialization을 만듭니다.
Windows HCK 및 보안 부팅 지침
다음 단계는 시스템 테스트 및 비클래스 드라이버 PC 테스트에 적용됩니다.
보안 부팅 보호를 사용하지 않도록 설정합니다.
BIOS 구성을 입력하고 보안 부팅을 사용하지 않도록 설정합니다.
HCK 클라이언트 소프트웨어를 설치합니다.
다음을 제외한 모든 Windows HCK 테스트를 실행합니다.
- PCR을 사용한 BitLocker TPM 및 복구 암호 테스트[7]
- 보안 부팅을 사용하는 Arm PC에 대한 BitLocker TPM 및 복구 암호 테스트
- 보안 부팅 로고 테스트
- 보안 부팅 수동 로고 테스트
BIOS 구성을 입력하고 보안 부팅을 사용하도록 설정한 다음 보안 부팅을 기본 구성으로 복원합니다.
다음 BitLocker 및 보안 부팅 테스트를 실행합니다.
- PCR을 사용한 BitLocker TPM 및 복구 암호 테스트[7]
- 보안 부팅을 사용하는 Arm PC에 대한 BitLocker TPM 및 복구 암호 테스트
- 보안 부팅 로고 테스트(자동)
BIOS 구성을 입력하고 보안 부팅 구성을 지웁니다. PK 및 기타 키를 삭제하여 PC를 설정 모드로 복원합니다.
참고 항목
x86/x64 PC의 경우 지우기 지원이 필요합니다.
보안 부팅 수동 로고 테스트를 실행합니다.
참고 항목
보안 부팅을 사용하려면 Windows RT가 아닌 PC에서 Windows HCK 서명 또는 VeriSign 드라이버가 필요합니다.
Windows HCK 보안 부팅 로고 테스트(자동)
이 테스트는 적절한 기본 보안 부팅 구성을 확인합니다. 다음 내용이 포함됩니다.
- 보안 부팅 사용.
- PK는 알려진 테스트 PK가 아닙니다.
- KEK에는 프로덕션 Microsoft KEK가 포함됩니다.
- db에는 프로덕션 Windows CA가 포함되어 있습니다.
- dbx가 있습니다.
- 많은 1kB 변수가 만들어지거나 삭제됩니다.
- 32kB 변수가 만들어지거나 삭제됩니다.
Windows HCK 보안 부팅 수동 테스트 폴더 레이아웃
Windows HCK 보안 부팅 수동 로고 테스트 폴더 레이아웃은 다음과 같습니다.
"\Test"폴더에는 다음이 있습니다.:- 제조 및 서비스 테스트
- 테스트 구성에서 프로그래밍 방식으로 보안 부팅 사용하도록 설정
- 서비스 테스트
- db에 인증서 추가, 기능 확인
- dbx에 해시 추가, 기능 확인
- dbx에 인증서 추가, 기능 확인
- 600개 이상의 해시를 dbx에 추가하고 크기 확인
- 프로그래밍 방식으로 PK 변경
"\Generate"폴더에는 다음을 표시하는 스크립트가 있습니다.:테스트 인증서 만들기 방법
테스트 인증서 및 프라이빗 키가 포함되어 있습니다.
모든 테스트가 만들어진 방법
인증서 및 해시를 서명된 패키지로 변환
이를 직접 실행할 수 있으며 고유의 인증서로 대체할 수 있습니다.
"\certs"폴더에는 Windows를 부팅하는 데 필요한 모든 인증서가 있습니다.:참고 항목
키와 인증서를 생성하기 위해
"ManualTests\generate\TestCerts"에 사용된 방법론을 사용하지 마세요. 이는 Windows HCK 테스트 목적으로만 사용됩니다. 그것은 매우 안전하지 않고 권장되지 않는 디스크에 저장된 키를 사용합니다. 이는 프로덕션 환경에서 사용하기 위한 것이 아닙니다.
"ManualTests\example\OutOfBox"폴더에는 프로덕션 PC에 보안 부팅을 설치하는 데 활용할 수 있는 스크립트가 있습니다."ManualTests\generate\tests\subcreate_outofbox_example.ps1"은 파트너가 자신의 PK 및 기타 메타데이터를 대체할 수 있는 경우 이러한 예가 생성된 방법과 "TODO" 섹션을 보여 줍니다.
Windows HCK UEFI 서명 및 제출
다음 링크에 추가 정보가 있습니다.
부록 C – Federal Bridge 인증 기관 인증서 정책 보증 매핑
기본
이 수준은 개인의 ID와 관련하여 가장 낮은 수준의 보증을 제공합니다. 이 수준의 주요 기능 중 하나는 서명되는 정보에 데이터 무결성을 제공하는 것입니다. 이 수준은 악의적인 작업의 위험이 낮은 것으로 간주되는 환경과 관련이 있습니다. 인증이 필요한 트랜잭션에는 적합하지 않고 일반적으로 기밀성을 요구하는 트랜잭션에는 충분하지 않지만, 더 높은 수준의 보증을 가진 인증서를 사용할 수 없는 경우에는 후자에 사용할 수 있습니다.
기본
이 수준은 데이터 손상의 위험과 결과가 있지만 중요한 의미로 간주되지 않는 환경과 관련된 기본 수준의 보증을 제공합니다. 여기에는 악의적인 액세스 가능성이 높지 않은 프라이빗 정보에 대한 액세스가 포함될 수 있습니다. 이 보안 수준에서는 사용자가 악의적일 가능성이 없다고 가정합니다.
중간
이 수준은 데이터 손상의 위험과 결과가 보통인 환경과 관련이 있습니다. 여기에는 상당한 금전적 가치 또는 사기 위험이 있는 트랜잭션 또는 악의적인 액세스 가능성이 상당한 프라이빗 정보에 대한 액세스가 포함될 수 있습니다.
높음
이 수준은 데이터에 대한 위협이 높거나 보안 서비스 장애의 결과가 높은 경우에 사용하기에 적합합니다. 여기에는 매우 높은 가치의 트랜잭션 또는 높은 수준의 사기 위험이 포함될 수 있습니다.