보안 부팅 키 만들기 및 관리 지침 Windows
| 키/db 이름 | 변수 | 소유자 | 참고 |
|---|---|---|---|
PKpub |
PK |
OEM |
PK – 1만 해당. RSA 2048 이상이어야 합니다. |
Microsoft Corporation KEK CA 2011 |
KEK |
Microsoft |
db 및 dbx에 대한 업데이트를 허용합니다. |
Microsoft Windows 프로덕션 CA 2011 |
db |
Microsoft |
서명 데이터베이스(db)의 이 CA를 사용하면 Windows 부팅할 수 https://go.microsoft.com/fwlink/?LinkId=321192 있습니다. |
사용할 수 없음 서명 데이터베이스 |
Dbx |
Microsoft |
Microsoft의 알려진 잘못된 키, CAS 또는 이미지 목록 |
보안 펌웨어 업데이트 키 |
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 crypto 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 사용자 지정 솔루션 공급자
공개 키 암호화는 어려울 수 있으며 새로운 암호화 개념을 이해해야 합니다. 제조 환경에서 작동하도록 보안 부팅을 얻는 데 도움이 될 수 있는 사용자 지정 솔루션 공급자가 있습니다.
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.exe (권장 하지 않음)
Makecert.exe는 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 참조).
이러한 작업은 매년 한 번만 수행할 수 있습니다. 최대 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 s와 같은 Pc ’ 는 id 기반 "k/m 인증"이 필요한 보안 수준 3을 지원 합니다. 즉, k 엔터티는 토큰을 사용 하 여 HSM에 대 한 액세스 권한을 부여 받습니다. 그러나 HSM에서 개인 키에 대 한 액세스 권한을 얻으려면 인증을 위해 적어도 k 개 이상의 m 토큰이 있어야 합니다.
예를 들어 HSM에 액세스 하려면 5 개 중 3 개의 토큰을 인증 해야 합니다. 이러한 멤버는 보안 책임자, 트랜잭션 권한 부여자 및/또는 임원 관리의 멤버일 수 있습니다.
HSM 토큰
HSM에는 토큰을 제공 해야 하는 정책이 있을 수 있습니다.
로컬로
통해
자동화 되도록 구성 됨
토큰 및 토큰 암호를 조합 하 여 사용 하는 것이 좋습니다.
2.4 보안 부팅 및 타사 서명
2.4.1 UEFI 드라이버 서명
UEFI 드라이버는 문서의 다른 위치에 설명 된 대로 db의 CA 또는 키로 서명 하거나 db에 포함 된 드라이버 이미지의 해시를 가져야 합니다. Microsoft는 Microsoft CORPORATION UEFI CA 2011를 사용 하 여 WHQL 드라이버 서명 서비스와 유사한 UEFI 드라이버 서명 서비스를 제공 합니다. 이로 서명 된 모든 드라이버는 Microsoft UEFI CA를 포함 하는 모든 Pc에서 원활 하 게 실행 됩니다. OEM이 신뢰할 수 있는 드라이버에 서명 하 고 db에 OEM CA를 포함 하거나 db에 드라이버의 해시를 포함 하는 것도 가능 합니다. 모든 경우에 데이터베이스에서 UEFI 드라이버 (옵션 ROM)를 신뢰할 수 없으면 실행 하지 않아야 합니다.
시스템 펌웨어 이미지에 포함 된 모든 드라이버는 다시 확인할 필요가 없습니다. 전체 시스템 이미지의 일부가 되 면 PC에서 드라이버를 신뢰할 수 있는 충분 한 보증을 제공 합니다.
Microsoft는 UEFI 드라이버에 서명 하려는 모든 사용자가 사용할 수 있게 되었습니다. 이 인증서는 Windows HCK Secure Boot 테스트의 일부입니다. https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/UEFI CA 서명 정책 및 업데이트에 대 한 자세한 내용을 보려면 [이 블로그] (()를 따르세요.
2.4.2 sections 부팅 로더
Microsoft UEFI 드라이버 서명 인증서는 다른 OSs에 서명 하는 데 사용할 수 있습니다. 예를 들어 Fedora ’ s Linux 부팅 로더에서 서명 됩니다.
이 솔루션에 ’ 는 키 Db에 추가 해야 하는 인증서가 더 이상 필요 하지 않습니다. 비용 효율성 외에도 모든 Linux 배포에 사용할 수 있습니다. 이 솔루션은 Windows를 지 원하는 모든 하드웨어에서 작동 하므로 광범위 한 하드웨어에 유용 합니다.
UEFI-CA는에서 다운로드할 수 있습니다 https://go.microsoft.com/fwlink/p/?LinkID=321194 . 다음 링크에는 HCK UEFI 서명 및 전송 Windows에 대 한 자세한 내용이 포함 되어 있습니다.
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과 통신할 수 있도록 합니다.
보안 팀의 일부인 팀 멤버가 식별 되 고 토큰이 할당 됩니다. M m 인증을 위해 HSM 하드웨어를 설정 해야 합니다.
보안 부팅 키 및 인증서 사전 생성 섹션 1.3 ~ 1.5를 참조 하세요.
HSM Api를 사용 하 여 PK 및 펌웨어 업데이트 키 및 인증서를 미리 생성 (미리 생성) 합니다.
필수-PK (모델 당 1 권장), 펌웨어 업데이트 키 (요소당 권장 1), Microsoft KEK, Db, DbxNOTE: OEM에서 Microsoft KEK, db 및 .dbx ’ 를 생성 하지 않아도 되며 완전성을 위해 설명 되어 있습니다. 선택 사항-OEM/타사 KEK db, .dbx 및 OEM Db로 이동 하는 기타 모든 키입니다.
PC에 Windows 이미지를 적용 합니다.
Microsoft db 및 .dbx를 설치합니다. 1.3.6 및 부록 B 보안 부팅 api섹션을 참조 하세요.
Microsoft Windows 프로덕션 PCA 2011을 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 Corporation UEFI CA 2011을 UEFI db에 설치합니다.
보안 부팅 펌웨어 업데이트 키 - 섹션 1.3.5를 참조하세요.
Windows RT PC만 해당: 보안 펌웨어 업데이트 공개 키 또는 해당 해시를 설치하여 공간을 절약합니다.
SoC에서만 보안 펌웨어 업데이트 키(공개 또는 해시)를 굽는 등 다른 작업을 수행해야 할 수 있습니다.
보안 부팅을 사용하도록 설정합니다. 부록 B 보안 부팅 API를 참조하세요.
UEFI PK에 OEM/ODM PKpub(인증서를 선호하지만 키는 괜찮습니다)를 설치합니다.
보안 부팅 API를 사용하여 PK를 등록합니다. 이제 보안 부팅에 대해 PC를 사용하도록 설정해야 합니다.
참고
끝에 PK를 설치하는 경우 MS KEK, db, dbx는 ’ 서명할 필요가 – 없습니다. SignerInfo가 없어야 합니다. 바로 가기입니다.
보안 부팅 테스트:모든 독점 테스트를 실행하고 지침에 따라 HCK 테스트를 Windows. 부록 B 보안 부팅 API를 참조하세요.
배송 플랫폼:PKpriv는 다시 사용되지 않을 가능성이 높으며 안전하게 유지합니다.
서비스:향후 펌웨어 업데이트는 서명 서비스를 사용하여 보안 펌웨어 업데이트 "프라이빗" 키로 안전하게 서명됩니다.
3.1 리소스
보안 전략 백서 - https://go.microsoft.com/fwlink/p/?linkid=321288
Windows HCK 제출 -https://go.microsoft.com/fwlink/p/?linkid=321287
부록 – 제조를 위한 보안 부팅 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에서 HCK 서명 또는 VeriSign 드라이버를 Windows 해야 합니다.
Windows HCK Secure Boot 로고 테스트 (자동화)
이 테스트는 적절 한 기본 보안 부팅 구성을 확인 합니다. 다음 내용이 포함됩니다.
- 보안 부팅이 사용 됩니다.
- PK는 알려지지 않은 테스트 PK입니다.
- KEK에는 프로덕션 Microsoft KEK가 포함 되어 있습니다.
- db에는 프로덕션 Windows CA가 포함 되어 있습니다.
- .dbx가 제공 됩니다.
- 많은 1kB 변수가 생성/삭제 됩니다.
- 32kB 변수가 만들어지거나 삭제 됩니다.
Windows HCK Secure Boot 수동 테스트 폴더 레이아웃
Windows HCK Secure Boot Manual 로고 테스트 폴더 레이아웃은 아래에 설명 되어 있습니다.
"\Test"폴더에는 다음이 포함 됩니다.- 제조 및 서비스 테스트
- 테스트 구성에서 프로그래밍 방식으로 보안 부팅 사용
- 서비스 테스트
- Db에 인증서 추가, 함수 확인
- .Dbx에 해시 추가, 함수 확인
- 인증서를 .dbx에 추가, 함수 확인
- .Dbx에 600 + 해시 추가, 크기 확인
- PK를 프로그래밍 방식으로 변경
"\Generate"폴더에는 다음을 보여 주는 스크립트가 있습니다.테스트 인증서를 만드는 방법
테스트 인증서 및 개인 키가 포함 되어 있습니다.
모든 테스트를 만든 방법
서명 된 패키지로 인증서 및 해시 설정
이를 직접 실행 하 고 자신의 인증서로 대체할 수 있습니다.
"\certs"폴더는 부팅에 필요한 모든 인증서를 Windows 합니다.참고
’에서 사용 하는 방법을 사용 하 여
"ManualTests\generate\TestCerts"키와 인증서를 생성 하지 마세요. 이는 Windows HCK 테스트 목적 으로만 사용 됩니다. 안전 하지 않으며 권장 하지 않는 디스크에 저장 된 키를 사용 합니다. 이는 프로덕션 환경에서 사용 하기 위한 것이 아닙니다.
"ManualTests\example\OutOfBox"폴더에는 프로덕션 Pc에 보안 부팅을 설치 하는 데 활용할 수 있는 스크립트가 있습니다.는
"ManualTests\generate\tests\subcreate_outofbox_example.ps1"이러한 예제가 생성 된 방법을 보여 주고 파트너가 PK 및 기타 메타 데이터를 대체할 수 있는 경우 "TODO" 섹션을 포함 합니다.
HCK UEFI 서명 및 전송 Windows
자세한 내용은 다음 링크를 제공 합니다.
부록 C – 연방 브리지 인증 기관 인증서 정책 보증 매핑
매우
이 수준은 개인의 id와 관련 하 여 가장 낮은 수준의 보증을 제공 합니다. 이 수준의 주요 기능 중 하나는 서명 되는 정보에 대 한 데이터 무결성을 제공 하는 것입니다. 이 수준은 악의적인 활동의 위험이 낮은 것으로 간주 되는 환경과 관련이 있습니다. 인증을 요구 하는 트랜잭션에는 적합 하지 않으며 일반적으로 기밀성이 필요한 트랜잭션에는 적합 하지 않지만 더 높은 수준의 보증을 포함 하는 인증서를 사용할 수 없는 경우에 사용할 수 있습니다.
기본
이 수준은 데이터 손상의 위험과 결과가 있는 환경과 관련 된 기본적인 보증 수준을 제공 하지만 중요 한 중요 한 것으로 간주 되지 않습니다. 여기에는 악의적인 액세스 가능성이 높은 개인 정보에 대 한 액세스 권한이 포함 될 수 있습니다. 사용자가 악의적이 지 않은 것으로 간주 됩니다.
중간
이 수준은 데이터 손상의 위험과 결과가 보통 인 환경과 관련이 있습니다. 여기에는 상당한 금전적 가치를 가진 트랜잭션이나 사기 위험이 있거나 악의적인 액세스 가능성이 매우 큰 개인 정보에 대 한 액세스가 포함 될 수 있습니다.
높음
이 수준은 데이터에 대 한 위협이 높은 경우 또는 보안 서비스의 실패 결과가 높은 경우 사용 하기에 적합 합니다. 여기에는 매우 높은 가치의 트랜잭션 또는 높은 수준의 사기 위험이 포함 될 수 있습니다.
관련 항목
HSM을 사용 하 여 보안 부팅 키 생성 및 서명 (예제)
이 문서는 Oem과 Odm에서 제조 환경의 보안 부팅 키 및 인증서를 만들고 관리 하는 방법을 안내 합니다. 또한 플랫폼 키 (pks)의 생성, 저장 및 검색, 보안 펌웨어 업데이트 키 및 keks (타사 키 Exchange 키)와 관련 된 질문을 해결 합니다.
참고
이러한 단계는 PC Oem에 국한 되지 않습니다. 기업 및 고객은 이러한 단계를 사용 하 여 보안 부팅을 지원 하도록 서버를 구성할 수도 있습니다.
UEFI 및 보안 부팅에 대 한 Windows 요구 사항은 Windows 하드웨어 인증 요구 사항에서 찾을 수 있습니다. 이 문서에서는 새 요구 사항을 소개 하거나 공식 Windows 프로그램을 나타내지는 않습니다. 이는 보안 부팅 키를 만들고 관리 하기 위한 효율적이 고 안전한 프로세스를 구축 하는 데 도움을 주기 위해 인증 요구 사항 외의 지침으로 제공 됩니다. UEFI 보안 부팅은 실행이 허용 되기 전에 코드를 인증 하는 공개 키 인프라를 사용 하는 것을 기반으로 하기 때문에 중요 합니다.
판독기는 UEFI의 기본 사항, 보안 부팅에 대 한 기본 이해 ( uefi 사양의27 장) 및 PKI 보안 모델을 알고 있어야 합니다.
Windows에서 보안 부팅의 유효성을 검사 하는 요구 사항, 테스트 및 도구는 현재 HCK (하드웨어 인증 키트)를 Windows통해 사용할 수 있습니다. 그러나 이러한 HCK 리소스는 Windows 배포를 위한 키 만들기 및 관리를 처리 하지 않습니다. 이 문서는 펌웨어에서 사용 하는 키 배포를 통해 파트너에 게 안내 하는 데 도움이 되는 리소스의 핵심 관리를 다룹니다. 이는 규범적인 지침을 제공 하지 않으며 새로운 요구 사항은 포함 하지 않습니다.
이 페이지에서 다음을 수행합니다.
- 1. 보안 부팅, Windows 및 키 관리 는 Windows 및 보안 부팅에 적용 되는 부팅 보안 및 PKI 아키텍처에 대 한 정보를 포함 합니다.
- 2. 핵심 관리 솔루션 은 파트너의 요구에 맞는 주요 관리 및 디자인 솔루션을 설계 하는 데 도움이 됩니다.
- 3. 요약 및 리소스 에는 부록, 검사 목록, api 및 기타 참조가 포함 됩니다.
이 문서는 고객 준비 Pc, 공장 배포 도구 및 주요 보안 모범 사례를 개발 하기 위한 시작 지점으로 사용 됩니다.
1. 보안 부팅, Windows 및 키 관리
UEFI (UEFI(Unified Extensible Firmware Interface)) 사양은 보안 부팅 이라는 펌웨어 실행 인증 프로세스를 정의 합니다. 보안 부팅은 업계 표준으로, 플랫폼 펌웨어가 인증서를 관리 하 고, 펌웨어를 인증 하 고, 운영 체제가이 프로세스와 상호 작용 하는 방식을 정의 합니다.
보안 부팅은 실행을 허용 하기 전에 모듈을 인증 하는 PKI (공개 키 인프라) 프로세스를 기반으로 합니다. 이러한 모듈에는 펌웨어 드라이버, 옵션 Rom, 디스크의 UEFI 드라이버, UEFI 응용 프로그램 또는 UEFI 부팅 로더가 포함 될 수 있습니다. 보안 부팅은 실행 전에 이미지 인증을 통해 루트킷과 같은 사전 부팅 맬웨어 공격의 위험을 줄여 줍니다. 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 Public-Key 인프라 (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에 제공 되며 액세스할 수 있거나 "공용"입니다. 이 문서에서는 "pub" 접미사를 사용 하 여 공개 키를 나타냅니다. 예를 들어 PKpub는 PK의 공개 절반을 나타냅니다.
1.2.5 개인 키
PKI가 작동 하려면 개인 키를 안전 하 게 관리 해야 합니다. 조직 내에서 신뢰할 수 있는 소수의 사용자가 액세스할 수 있어야 하 고 강력한 액세스 정책 제한을 적용 하 여 물리적으로 안전한 위치에 저장 해야 합니다. 이 문서에서는 "priv" 접미사를 사용 하 여 개인 키를 나타냅니다. 예를 들어 PKpriv는 PK의 개인 절반을 나타냅니다.
인증서 1.2.6
디지털 인증서의 주요 용도는 이진 등의 서명 된 데이터 원본을 확인 하는 것입니다. 인증서의 일반적인 용도는 TLS (전송 계층 보안) 또는 SSL(Secure Sockets Layer) (SSL)를 사용 하는 인터넷 메시지 보안입니다. 인증서로 서명 된 데이터를 확인 하면 받는 사람이 데이터의 원본을 확인 하 고 전송 중에 변경 되었는지 확인할 수 있습니다.
일반적으로 디지털 인증서에는 상위 수준, DN (고유 이름), 공개 키 및 서명이 포함 됩니다. DN은 인증서의 공개 키와 일치 하는 개인 키를 보유 하는 (예: 회사) 엔터티를 식별 합니다. 개인 키로 인증서를 서명 하 고 인증서에 서명을 배치 하면 개인 키가 공개 키에 연결 됩니다.
인증서는 다른 형식의 데이터를 포함할 수 있습니다. 예를 들어, X.509 인증서는 인증서 형식, 인증서 일련 번호, 인증서 서명에 사용된 알고리즘, 인증서를 발급한 CA 이름, 인증서를 요청하는 엔터티의 이름 및 공개 키, CA의 서명 등을 포함합니다.
인증서 체인 1.2.7
시작: 인증서 체인:
그림 2: 세 인증서 체인
사용자 인증서는 CA의 개인 키와 같은 다른 개인 키로 서명 되는 경우가 많습니다. 이는 두 인증서 체인을 구성 합니다. 사용자 인증서가 진짜 인지 확인 하는 데는 인증서에서 CA의 공개 키가 필요한 서명 확인이 포함 되어 있는지 확인 합니다. 하지만 CA의 공개 키를 사용 하려면 먼저 포함 된 CA 인증서를 확인 해야 합니다. CA 인증서는 자체 서명 되므로 CA 공개 키를 사용 하 여 인증서를 확인 합니다.
사용자 인증서는 루트 CA의 개인 키로 서명 하지 않아도 됩니다. 인증서가 CA의 개인 키로 서명 된 중개자의 개인 키로 서명 될 수 있습니다. 사용자 인증서, 중간 인증서 및 CA 인증서의 세 가지 인증서 체인 인스턴스입니다. 그러나 두 개 이상의 중개자가 체인에 포함 될 수 있으므로 인증서 체인의 길이는 모두 다를 수 있습니다.
1.3 보안 부팅 PKI 요구 사항
UEFI에서 정의 된 신뢰의 루트는 플랫폼 키와 OEM 또는 ODM 펌웨어 코어에 포함 된 키로 구성 됩니다. Uefi 전 보안 및 신뢰의 루트는 UEFI 보안 부팅 프로세스에서 처리 되지 않고 대신 NIST (표준 및 기술) (NIST) 및이 문서에서 참조 하는 TCG(신뢰할 수 있는 컴퓨팅 그룹) (TCG) 게시를 통해 처리 됩니다.
1.3.1 보안 부팅 요구 사항
’보안 부팅을 구현 하기 위해 다음 매개 변수를 고려해 야 합니다.
- 고객 요구 사항
- Windows 하드웨어 호환성 요구 사항
- 키 생성 및 관리 요구 사항
Hsm (하드웨어 보안 모듈)과 같은 보안 부팅 키 관리를 위한 하드웨어를 선택 하 고, 정부 및 기타 기관에 제공 하기 위한 Pc의 특별 한 요구 사항을 고려 하 고, 다양 한 보안 부팅 키의 수명 주기를 만들고, 채우고, 관리 하는 프로세스를 수행 해야 합니다.
1.3.2 보안 부팅 관련 키
보안 부팅에 사용 되는 키는 다음과 같습니다.
그림 3: 보안 부팅 관련 키
위의 그림 3은 보안 부팅을 사용 하는 PC의 서명 및 키를 나타냅니다. 플랫폼은 제조 하는 동안 OEM이 펌웨어에 설치 하는 플랫폼 키를 통해 보안이 유지 됩니다. 다른 키는 펌웨어 실행을 허용 하거나 허용 하지 않도록 키를 저장 하는 데이터베이스에 대 한 액세스를 보호 하기 위해 보안 부팅에서 사용 됩니다.
권한 있는 데이터베이스 (db)에는 신뢰할 수 있는 펌웨어 구성 요소 및 운영 체제 로더를 나타내는 공개 키와 인증서가 포함 되어 있습니다. 사용할 수 없는 서명 데이터베이스 (.dbx)에는 악의적이 고 취약 한 구성 요소 및 손상 된 키 및 인증서의 해시가 포함 되어 있으며 이러한 악성 구성 요소의 실행이 차단 됩니다. 이러한 정책의 강도는 Authenticode 및 PKI (공개 키 인프라)를 사용 하 여 펌웨어에 서명 하는 것을 기반으로 합니다. PKI는 정보 교환 중에 신뢰를 설정 하는 인증서를 작성, 관리 및 해지 하기 위한 잘 설정 된 프로세스입니다. PKI는 보안 부팅에 대 한 보안 모델의 핵심입니다.
이러한 키에 대 한 자세한 내용은 다음과 같습니다.
PK (1.3.3 Platform Key)
UEFI 2.3.1 정오표 C의 27.5.1 섹션에 따라 플랫폼 키는 플랫폼 소유자와 플랫폼 펌웨어 간의 트러스트 관계를 설정 합니다. 플랫폼 소유자는 UEFI 2.3.1 정오표 C의 7.2.1 섹션에 지정 된 키의 공개 절반 (pkpub)을 플랫폼 펌웨어에 등록 합니다. 이 단계에서는 플랫폼을 설치 모드에서 사용자 모드로 이동 합니다. 핵심 키
EFI_CERT_X509_GUID알고리즘 RSA, 공개 키 길이 2048 비트 및 서명 알고리즘 sha256RSA을 사용 하 여 플랫폼 키를 입력 하는 것이 좋습니다. 저장소 공간이 중요할 경우 플랫폼 소유자는 형식을 사용할 수 있습니다EFI_CERT_RSA2048_GUID. 공개 키는이 문서의 앞부분에서 설명한 대로 서명을 확인 하는 데 사용 됩니다. 플랫폼 소유자는 나중에 키의 개인 절반 (PKpriv)을 사용할 수 있습니다.- 플랫폼 소유권을 변경 하려면 보안 부팅을 사용 하지 않도록 설정 하는 UEFI 정의 설정 모드로 펌웨어를 설정 해야 합니다. 제조 하는 동안이 작업을 수행 해야 하는 경우에만 설치 모드로 되돌립니다.
- 데스크톱 PC의 경우 Oem은이와 연결 된 PK 및 필요한 PKI를 관리 합니다. 서버에서 Oem은 기본적으로 PK 및 필요한 PKI를 관리 합니다. Enterprise 고객 또는 서버 고객은 pk를 사용자 지정 하 여 UEFI 보안 부팅 펌웨어에서 트러스트를 잠금으로 잠글 수 있도록 OEM 신뢰 pk를 사용자 지정 전용 pk로 바꿀 수도 있습니다.
1.3.3.1 KEK (키 Exchange 키)를 등록 하거나 업데이트 하는 데 플랫폼 키를 등록 합니다.
플랫폼 소유자는 UEFI 사양 2.3.1 정오표 C의 7.2.1 섹션에 지정 된 대로 UEFI 부팅 서비스 SetVariable ()을 호출 하 고 플랫폼을 다시 설정 하 여 플랫폼 키 (Pkpub)의 공개 절반을 등록 합니다. 플랫폼이 설치 모드인 경우 새 Pkpub 는 pkpub 로 서명 됩니다. 플랫폼이 사용자 모드에 있는 경우 새 Pkpub 는 현재 pkpub로 서명 해야 합니다. PK가 형식이 면
EFI_CERT_X509_GUIDpk에서 발급 된 인증서의 개인 키가 아니라 직접EFI_CERT_X509_GUID에서 서명 해야 합니다.플랫폼 키 지우기 1.3.3.2
플랫폼 소유자는 UEFI Boot Ser 사용법 ()을 호출 하 여 플랫폼 키 (Pkpub)의 공개 절반을 삭제 합니다. 플랫폼이 설치 모드에 있으면 빈 변수를 인증 하지 않아도 됩니다. 플랫폼이 사용자 모드에 있는 경우 빈 변수는 현재 Pkpriv로 서명 해야 합니다. 자세한 내용은 UEFI 사양 2.3.1 정오표 C의 7.2 (변수 서비스) 섹션을 참조 하세요. 프로덕션 PKpriv는 패키지에 서명 하는 데 사용 하지 않는 것이 좋습니다 .이 경우에는 보안 부팅을 프로그래밍 방식으로 사용 하지 않도록 설정할 수 있기 때문입니다. 이는 주로 사전 프로덕션 테스트 시나리오입니다.
플랫폼 키는 안전한 플랫폼 특정 메서드를 사용 하 여 지울 수도 있습니다. 이 경우 전역 변수 설정 모드도 1로 업데이트 되어야 합니다.
그림 4: 플랫폼 키 상태 다이어그램
1.3.3.3 PK 생성
UEFI 권장 사항에 따라 공개 키를 비휘발성 저장소에 저장 해야 하며,이는 PC에서 변조 방지 및 삭제 저항력이 있습니다. 개인 키는 파트너 또는 OEM ’ s 보안 Office에서 안전 하 게 유지 되며 공개 키만 플랫폼에 로드 됩니다. 2.2.1 및 2.3 섹션에 자세한 내용이 있습니다.
생성 되는 PK 수는 OEM (Platform owner)의 재량에 있습니다. 이러한 키는 다음과 같을 수 있습니다.
PC 당 하나 각 장치에 대해 하나의 고유 키가 있어야 합니다. 이는 보안 요구 사항이 높은 정부 기관, 금융 기관 또는 기타 서버 고객을 위해 필요할 수 있습니다. 많은 수의 Pc에 대 한 개인 및 공개 키를 생성 하려면 추가 저장소 및 암호화 처리 성능이 필요할 수 있습니다. 그러면 나중에 장치에 펌웨어 업데이트를 푸시할 때 장치를 해당 PK와 매핑 하는 복잡성이 추가 됩니다. HSM 공급 업체에 따라 많은 수의 키를 관리 하는 데 사용할 수 있는 몇 가지 HSM 솔루션이 있습니다. 자세한 내용은 HSM을 사용 하 여 보안 부팅 키 생성을 참조 하세요.
모델 당 하나 PC 모델 마다 하나의 키가 있습니다. 여기서의 단점은 키가 손상 된 경우 동일한 모델 내의 모든 컴퓨터가 취약 하다는 것입니다. 이는 데스크톱 Pc 용 Microsoft에서 권장 됩니다.
제품 라인 당 하나 키가 손상 되 면 전체 제품 라인은 취약 해질 수 있습니다.
OEM 당 하나 설정 하는 것이 가장 간단 하지만, 키가 손상 되 면 제조업체에서 제조 하는 모든 PC가 취약 해질 수 있습니다. 공장 바닥에서 작업 속도를 높이려면 PK와 잠재적으로 다른 키를 미리 생성 하 여 안전한 위치에 저장할 수 있습니다. 나중에이를 검색 하 여 어셈블리 줄에서 사용할 수 있습니다. 2 장 및 3 장는 자세한 정보를 포함 합니다.
PK 1.3.3.4 키를 재입력 합니다.
PK가 손상 되거나 고객의 요구 사항으로 인해 보안상의 이유로 자체 PK를 등록할 수 있는 경우이 기능이 필요할 수 있습니다.
PK를 만들기 위해 선택한 방법에 따라 모델 또는 PC에 대 한 재입력을 수행할 수 있습니다. 모든 최신 Pc는 새로 만든 PK로 서명 됩니다.
프로덕션 PC에서 PK를 업데이트 하려면 PK 또는 펌웨어 업데이트 패키지를 대체 하는 기존 PK로 서명 된 변수 업데이트가 필요 합니다. OEM은 SetVariable () 패키지를 만들어 PK와 같은 간단한 응용 프로그램을 사용 하 여 배포할 수도 있습니다. 펌웨어 업데이트 패키지는 보안 펌웨어 업데이트 키로 서명 되 고 펌웨어에 의해 확인 됩니다. 펌웨어 업데이트를 수행 하 여 PK를 업데이트 하는 경우 KEK, db 및 .dbx가 유지 되도록 주의를 기울여야 합니다.
모든 Pc에서 보안 펌웨어 업데이트 키로 PK를 사용 하지 않는 것이 좋습니다. PKpriv가 손상 되 면 보안 펌웨어 업데이트 키가 동일 하기 때문입니다. 이 경우 업데이트 프로세스도 손상 되었기 때문에 새 PKpub를 등록 하기 위한 업데이트를 사용할 수 없습니다.
Soc Pc에서는 PK를 보안 펌웨어 업데이트 키로 사용 하지 않는 또 다른 이유가 있습니다. 이는 Windows 하드웨어 인증 요구 사항을 충족 하는 pc에서 보안 펌웨어 업데이트 키가 결합에 영구적으로 burnt 때문입니다.
KEK (1.3.4 key Exchange key) 키 교환 키는 운영 체제와 플랫폼 펌웨어 간의 트러스트 관계를 설정 합니다. 각 운영 체제 (그리고 잠재적으로 플랫폼 펌웨어와 통신 해야 하는 각 타사 응용 프로그램)는 플랫폼 펌웨어에 공개 키 (Kekpub)를 등록 합니다.
1.3.4.1 키 Exchange 키 등록
키 교환 키는 1.4 서명 데이터베이스 (Db 및 .dbx)의 설명에 따라 서명 데이터베이스에 저장 됩니다. 서명 데이터베이스는 인증 된 UEFI 변수로 저장 됩니다.
플랫폼 소유자는 UEFI 사양 2.3.1 정오표 C에서 7.2 (변수 서비스) 섹션에 지정 된 대로 setvariable ()을 호출 하 여 키 교환 키를 등록 합니다. 특성 집합 및 새 키를 포함 하는 데이터 매개 변수를 사용 하거나, getvariable ()을 사용 하 여 새 키 교환 키를 추가 하 고, 기존 키에 새 키 교환 키를 추가한 다음, UEFI 사양 아래의 7.2 (변수 서비스) 섹션에 지정 된 대로 setvariable ()을 사용 하 여 데이터베이스를 작성 합니다. 특성 집합이 없는 2.3.1 정오표 C
플랫폼이 설치 모드인 경우 서명 데이터베이스 변수는 서명 하지 않아도 되지만 SetVariable () 호출에 대 한 매개 변수는 7.2.1 섹션의 인증 된 변수에 지정 된 대로 계속 준비 되어야 합니다. 플랫폼이 사용자 모드에 있는 경우 서명 데이터베이스는 현재 PKpriv로 서명 되어야 합니다.
KEK을 지우는 1.3.4.2
KEK를 "지우기" (삭제) 할 수 있습니다. 컴퓨터에 PK가 설치 되어 있지 않으면 "clear" 요청에 서명할 필요가 없습니다. 서명 된 경우 KEK을 지우려면 PK 서명 된 패키지가 필요 하 고, db 또는 .dbx를 지우려면 KEK에 있는 엔터티에서 서명 된 패키지가 필요 합니다.
1.3.4.3 Microsoft KEK
Microsoft KEK는 .dbx를 업데이트 하 고 잠재적으로 db를 업데이트 하 여 최신 Windows 서명 이미지를 준비 하는 방식으로 잘못 된 이미지의 해지를 허용 해야 합니다.
KEK 데이터베이스에 Microsoft Corporation KEK CA 2011을 포함 하 고 다음 값을 포함 합니다.
- SHA-1 인증서 해시:
31 59 0b fd 89 c9 d7 4e d0 87 df ac 66 33 4b 39 31 25 4b 30. - 서명 소유자 GUID:
{77fa9abd-0359-4d32-bd60-28f4e78f784b}. - Microsoft에서 파트너에 게 인증서를 제공 하 고
EFI_CERT_X509_GUID또는 형식 서명으로 추가할 수 있습니다EFI_CERT_RSA2048_GUID.
Microsoft KEK certificate는에서 다운로드할 수 있습니다 https://go.microsoft.com/fwlink/?LinkId=321185 .
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의 신뢰할 수 있는 타사 컨트롤을 허용 하는 추가 keks를 사용할 수 있습니다.
- SHA-1 인증서 해시:
1.3.5 보안 부팅 펌웨어 업데이트 키 보안 펌웨어 업데이트 키는 업데이트 해야 할 경우 펌웨어에 서명 하는 데 사용 됩니다. 이 키의 최소 키 강도는 RSA-2048입니다. 모든 펌웨어 업데이트는 OEM, ODM 또는 IBV (독립 BIOS 공급 업체)와 같은 신뢰할 수 있는 대리자 또는 보안 서명 서비스에서 안전 하 게 서명 해야 합니다.
NIST 게시 800-147 필드 펌웨어 업데이트 는 지침의 모든 요소를 지원 해야 합니다.
펌웨어 플래시 저장소에 대 한 모든 업데이트는 작성자에 의해 서명 되어야 합니다.
펌웨어는 업데이트의 서명을 확인 해야 합니다.
안전한 펌웨어 업데이트를 위한 키 만들기 1.3.6
모든 펌웨어 업데이트에 서명 하는 데 동일한 키가 사용 됩니다. 또한 보안 펌웨어 업데이트 키에 연결 된 키를 사용 하 여 펌웨어 업데이트에 서명할 수 있습니다.
PC 당 하나의 키 (예: PK 또는 모델 당 하나 또는 제품 라인 당 하나)가 있을 수 있습니다. PC 당 하나의 키가 있는 경우 수백만 개의 고유 업데이트 패키지를 생성 해야 함을 의미 합니다. 리소스 가용성에 따라 어떤 방법을 사용 하 든 고려 하세요. 모델 또는 제품 라인 별로 키가 있으면 손상 된 것입니다.
보안 펌웨어 업데이트 공개 키 (또는 공간을 절약 하는 해시)는 플랫폼 – 일반적으로 보호 된 플래시 (PC) 또는 일회성 (일회성 프로그래밍 가능 결합)의 일부 보호 된 저장소에 저장 됩니다.
이 키의 해시만 저장 되어 공간을 절약 하는 경우 펌웨어 업데이트에 키가 포함 되 고 업데이트 프로세스의 첫 번째 단계에서 업데이트의 공개 키가 플랫폼에 저장 된 해시와 일치 하는지 확인 합니다.
캡슐은 재부팅을 통해 OS가 UEFI 환경에 데이터를 전달할 수 있는 수단입니다. Windows는 UEFI UpdateCapsule ()를 호출 하 여 시스템 및 PC 펌웨어 업데이트를 제공 합니다. exitbootservices ()를 호출 하기 전에 부팅 시에는 Windows Windows 드라이버 저장소에 있는 새 펌웨어 업데이트를 UpdateCapsule ()에 전달 합니다. UEFI 시스템 펌웨어는이 프로세스를 사용 하 여 시스템 및 PC 펌웨어를 업데이트할 수 있습니다. 이 Windows 펌웨어 지원을 활용 하 여 OEM은 system 및 PC 펌웨어의 펌웨어를 업데이트 하기 위해 동일한 일반 형식 및 프로세스를 사용할 수 있습니다. Windows에 대해 UEFI UpdateCapsule ()를 지원 하려면 펌웨어가 ACPI ESRT 테이블을 구현 해야 합니다.
Windows uefi 펌웨어 업데이트 플랫폼에 대 한 지원 구현에 대 한 자세한 내용은 uefi 펌웨어 업데이트 플랫폼 Windows 설명서를 참조 하세요.
업데이트 캡슐은 메모리 나 디스크에 있을 수 있습니다. Windows 메모리 업데이트를 지원합니다.
1.3.6.1 캡슐(메모리 내 캡슐)
다음은 메모리 내 업데이트가 작동하기 위한 이벤트 흐름입니다.
- OS의 애플리케이션에 의해 메모리에 캡슐화됩니다.
- 사서함 이벤트가 BIOS에 보류 중인 업데이트를 알리도록 설정됩니다.
- PC가 다시 부팅되고, 캡슐 이미지를 확인하고, BIOS에서 업데이트가 수행됩니다.
1.3.7 일반적인 펌웨어 업데이트 워크플로
- 펌웨어 드라이버를 다운로드하여 설치합니다.
- 다시 부팅합니다.
- OS 로더는 펌웨어를 검색하고 확인합니다.
- OS 로더는 이진 Blob을 UEFI에 전달합니다.
- UEFI는 펌웨어 업데이트를 수행합니다(이 프로세스는 실리콘 공급업체가 소유함).
- OS 로더 검색이 성공적으로 완료되었습니다.
- OS에서 부팅을 완료합니다.
1.4 서명 데이터베이스(Db 및 Dbx)
1.4.1 허용되는 서명 데이터베이스(db)
EFI db의 콘텐츠는
_IMAGE_SECURITY_DATABASE로드된 이미지를 확인할 때 신뢰할 수 있는 이미지를 제어합니다. 데이터베이스는 허용된 이미지를 식별하기 위해 여러 인증서, 키 및 해시를 포함할 수 있습니다.Windows OS 로더가 로드될 수 있도록 SHA-1 인증서 해시가 인 Microsoft Windows 프로덕션 PCA 2011이 db에 포함되어야 합니다. Windows CA는 에서 다운로드할 수 https://go.microsoft.com/fwlink/p/?linkid=321192 있습니다.
Windows RT 이외의 PC에서 OEM은 SHA-1 인증서 해시가 인 Microsoft Corporation UEFI CA 2011을 포함하는 것을 고려해야 합니다. 이 인증서를 사용하여 UEFI 드라이버 및 애플리케이션에 서명하면 사용자에 대한 추가 단계 없이도 타사의 UEFI 드라이버 및 애플리케이션이 PC에서 실행될 수 있습니다. UEFI CA는 에서 다운로드할 수 https://go.microsoft.com/fwlink/p/?linkid=321194 있습니다.
Windows RT 이외의 PC에서 OEM은 다른 운영 체제 또는 OEM 승인 UEFI 드라이버 또는 앱을 허용하는 추가 항목을 db에 포함할 수도 있지만 이러한 이미지는 어떤 방식으로든 PC의 보안을 손상해서는 안됩니다.
1.4.2 DbDefault:플랫폼 공급업체는 dbDefault 변수에 Signature Database에 대한 기본 항목 집합을 제공할 수 있습니다. 자세한 내용은 UEFI 사양의 섹션 27.5.3을 참조하세요.
1.4.3 사용할 수 없음 서명 데이터베이스(dbx)
EFI_IMAGE_SIGNATURE_DATABASE1db를 확인하기 전에 이미지를 확인할 때 dbx의 내용을 확인해야 하며 일치하는 항목이 있으면 이미지가 실행되지 않도록 해야 합니다. 데이터베이스는 금지된 이미지를 식별하기 위해 여러 인증서, 키 및 해시를 포함할 수 있습니다. Windows 하드웨어 인증 요구 사항에 따르면 dbx가 있어야 하므로 Microsoft가 dbx 업데이트 제공을 시작할 때까지 의 SHA-256 해시와 같은 더미 값을0안전한 자리 표시자로 사용할 수 있습니다. Microsoft에서 최신 UEFI 해지 목록을 다운로드하려면 여기를 클릭합니다.1.4.4 DbxDefault:플랫폼 공급업체는 dbxDefault 변수에 Signature Database에 대한 기본 항목 집합을 제공할 수 있습니다. 자세한 내용은 UEFI 사양의 섹션 27.5.3을 참조하세요.