Partager via

Microsoft UEFI CA 서명 정책 업데이트

  • Article

이 글에서는 UEFI 서명 정책 변경 사항에 대해 설명합니다. 이 중요한 변경 사항은 보안 부팅이 보안 목표에 부합하도록 하고 UEFI 서명 제출물 소요 시간을 합당하게 유지하도록 하는데 있습니다. 또한 이 글에서는 기존 UEFI 서명 정책 라이선싱 조건의 몇 가지 중요한 부분을 다시 한 번 강조합니다.

UEFI 서명은 Windows 개발자 센터 하드웨어 대시보드가 제공하는 서비스로서 Microsoft의 서명을 위해 x86 또는 x64 컴퓨터를 대상으로 하는 UEFI 펌웨어 이진 값을 제출할 수 있어, 보안 부팅을 사용하고 UEFI CA로 서명한 코드를 실행하는 Windows 실행 컴퓨터에 더욱 쉽게 설치할 수 있습니다.

Microsoft는 재량에 따라 제출물 서명을 하거나 하지 않을 권한이 있지만 이 요구 사항 목록은 준수해야 합니다. 그래야 제출물 서명 처리 소요 시간이 빨라지고 취소를 피하는 데도 도움이 됩니다. Microsoft는 서명하기 전에 설문지, 패키지 테스트, 이 요구 사항에 대한 기타 보안 테스트 등 후속 검토를 실시할 수 있습니다.

1. 2014년 3월 15일부터, UEFI 제출물은 EV 인증서를 요구합니다.

        a. 2014년 3월 15일부터, SysDev는 새로운 제출물과 갱신에 대해 DigiCert 나 VeriSign의 EV 인증서를 받습니다.

        b. 기존 제출자는 2014년 8월 15일 까지non-EV 코드 서명 인증서에서 EV 서명 인증서로 전환하면 됩니다. 이러한 연장은 문제없이 이전이 가능하도록 하기 위해 제공됩니다.

2. 고객에게 릴리스될 생산 품질 코드(내부용 코드나 도구 아님. 예: RTM(release to manufacturing) 코드)만 UEFI 서명할 수 있습니다. 내부용 코드의 경우 개발과 테스트 중에는 SecureBoot를 끄거나 보안 부팅 데이터베이스에 자체 키를 추가하는 것이 좋습니다.

3. UEFI 서명을 위해 제출된 코드에는 수정된 형태의 코드를 장치에 설치하기 위한 승인 키 요구 권한을 부여하는 라이선스나 GPLv3가 적용되지 않습니다. 이미 서명한 라이선스가 적용되는 코드는 서명이 취소될 수 있습니다. 예를 들어, GRUB 2는 GPLv3에 따라 라이선스를 취득하며 서명되지 않습니다.

4. 특정 기술을 사용하는 코드와 관련해 알려진 맬웨어 벡터가 있으면 그 코드는 서명되지 않고 취소될 수 있습니다. 예를 들어, SecureBoot 인라이트닝하지 않은 GRUB 버전 사용은 서명되지 않습니다.

5. 모든 코드 모듈은 실행 전에 인증되어야 합니다. 그러지 않으면 제출물이 서명되지 않으며 이미 서명했더라도 취소될 수 있습니다.

a. 제출물이 GRUB 또는 다른 로더를 로드하면 SecureBoot 인라이트닝해야 합니다.

예를 들어, SecureBoot 패치가 포함된 최신 GRUB 2가 있습니다.

b. 개발자들은 초기 부팅이 완료되면 보안 부팅 보안 요구 사항이 충족되었다고 생각할 수 있습니다. 하지만 인증되지 않은 코드 실행 후 보안 부팅 시스템이 다른 운영 체제 인스턴스의 시작을 허용하면 보안 부팅의 보안 보증이 침해됩니다. 이러한 취약성이 악용될 경우 제출물이 취소될 수 있습니다.

6. 제출물이 shim(다른 부트로더에 실행 전달)일 경우:

a. 코드 서명 키는 물리적으로 안전한 환경에서 최소 이중 요소 승인을 사용하여 신뢰할 수 있는 역할을 맡고 있는 직원만이 백업, 저장 및 복구해야 합니다.

  • 개인 키는 하드웨어 암호화 모듈로 보호해야 합니다. 여기에는 HSM, 스마트 카드, 스마트 카드와 비슷한 USB 토큰 및 TPM 등이 포함됩니다.
  • 운영 환경은 최소 FIPS 140-2 수준 2 이상의 보안 수준을 확보해야 합니다.

포함된 인증서가 EV 인증서인 경우 위 요구 사항을 모두 만족해야 합니다. UEFI CA 서명 소요 시간을 단축하는 EV 인증서를 사용하는 것이 좋습니다.

b. 제출자는 shim이 직접 및 나중에 로드하는 모든 것을 위한 강력한 취소 방식을 설계 및 구현해야 합니다.

c. 키를 잃어버리거나 키를 잘못 사용하거나 키가 누출된 경우 해당 키를 사용하는 모든 제출물이 취소됩니다.

d. 일부 shim은 SecureBoot 시스템에 취약하다고 알려져 있습니다. 서명 소요 시간을 단축하려면 shim - GitHub 브랜치에서 0.7 이상의 소스 코드를 사용하는 것이 좋습니다.

7. 서명을 받기 위한 제출 전에 제출 전 테스트 문서(UEFI 제출물용)에 따라 제품을 테스트해야 합니다.

8. 제출물 코드에 알려진 보안 취약점이 있는 경우 기능이 해당 코드를 노출하지 않았더라도 제출물은 서명되지 않습니다. 예를 들어 OpenSSL의 알려진 최신 보안 버전은 0.9.8za 및 1.0.1h이므로 제출물에 알려진 취약점이 포함된 이전 버전이 포함되어 있으면 제출물이 서명되지 않습니다.