Share via

하드웨어 보안 테스트 가능성 사양

  • 아티클

소개

HSTI는 Windows 디바이스에서 보안 기능이 잘못 구성되지 않도록 보호합니다. 고객 입장에서 HSTI는 구매한 머신이 기본적으로 안전하다는 최상의 보증을 제공합니다. IHV 및 IBV 입장에서 HSTI는 보안 약속이 유지되도록 합니다. OEM 및 ODM의 경우 독점 솔루션을 개발하지 않고도 배송하는 시스템이 기본적으로 안전하게 구성되고 보안이 유지되도록 할 수 있습니다.

HSTI 테스트의 결과는 Windows 호환성 테스트에서 사용되며 지원되는 보안 기능을 사용하도록 디바이스가 제대로 구성되었는지 확인하는 데 사용할 수 있습니다. 이러한 테스트는 안전하지 않은 테스트 키를 포함할 수 있는 엔지니어링 디바이스와 같이 현장에서 안전하지 않은 엔지니어링 디바이스를 식별하는 데 사용할 수 있습니다. 이러한 테스트의 결과는 Windows OS에서 안전하지 않은 디바이스에 워터마크(또는 유사한 표시기)를 표시하는 데 사용할 수 있습니다.

참고

  하드웨어 인터페이스를 구현하고 이 항목에 지정된 대로 설명서 및 도구를 공유하기 위해 플랫폼이 필요합니다.

배경

이 내용을 읽는 사용자는 UEFI의 기본 사항을 알고 UEFI 사양의 섹션 27 “보안”과 NIST SP 800-147을 포함하는 보안 부팅 기술을 이해하고 있어야 합니다.

이 요구 사항에는 다음과 같은 세 가지 측면이 있습니다.

  • 하드웨어 및 펌웨어 보안 상태를 쿼리하기 위한 플랫폼 독립 인터페이스
  • 위 인터페이스 구현에 대한 디자인 및 선택적 코드 검토
  • 설명서 및 도구 공유

개괄적인 구현

비트 필드

IHV는 플랫폼의 테스트 가능한 보안 기능을 나타내는 비트 필드를 정의합니다. 이 비트 필드는 IHV, IBV 또는 OEM HSTI 테스트에서 반환된 HSTI 개체에 사용할 수 있는 모든 정의 가능한 비트를 완전히 포함합니다. IHV 구현자는 IBV가 HSTI 테스트 결과를 올바르게 반환하기 위해 비트 필드의 정의를 디자인하고 적절한 설명서를 제공해야 합니다.

SecurityFeaturesRequired

SecurityFeaturesRequired 필드는 필드가 IHV HSTI 개체에 있으며 IHV가 필요한 보안 기능의 비트 필드를 정의하는 방법인 경우에만 처리에 사용됩니다.

SecurityFeaturesImplemented

HSTI 개체를 반환하는 테스트에서 구현한 보안 기능의 비트 필드입니다.

SecurityFeaturesVerified

HSTI 개체를 반환하는 테스트에서 확인한 보안 기능의 비트 필드입니다.

구현 지침

IHV는 Windows 호환성 요구 사항을 준수하는 플랫폼에 대한 참조 보안 디자인을 개발합니다. 또한 IHV 및 IBV는 참조 보안 구현의 적절한 사용을 확인하고 하드웨어 보안 테스트 인터페이스를 통해 결과를 보고하는 프로그래밍 방식 테스트도 구현합니다. 이러한 테스트는 OEM 및 ODM에 컴파일된 모듈(원본이 아님)으로 전달되며 수정 없이 작동해야 합니다. OEM/ODM이 참조 보안 디자인에서 벗어나면 이러한 테스트 모듈이 오류를 보고할 수 있으며, OEM/ODM은 수정 사항을 검토하고 이러한 예외를 보고하는 추가 HSTI 인스턴스를 구현하기 위해 Microsoft에 문의해야 합니다. OEM은 수정할 필요 없이 참조 디자인 및 설명서를 따라 이러한 보안 모듈을 활용할 수 있어야 합니다. 보안 모듈을 추가하거나 보안 모듈의 동작을 수정하려는 OEM은 Microsoft와 함께 디자인을 검토해야 합니다.

테스트 모듈 구현자의 구현의 일부로 구조체가 포함됩니다. 이 구조체의 프로토타입은 아래 “프로토타입 섹션”에 포함되어 있습니다. IHV는 보안 참조 검사 목록에서 각 비트의 의미를 정의합니다. IHV는 비트 필드에 있는 각 비트의 의미를 추가로 정의합니다. 마지막으로, IHV는 OEM 구조체에 “필수” 비트 필드를 포함하며, 모든 요구 사항에 대해 “구현됨” 비트 필드에 비트를 설정할 것임을 프로그래밍 방식으로 테스트할 수 있습니다.

IBV 및 OEM은 해당 비트가 나타내는 보안 기능의 존재를 프로그래밍 방식으로 확인하는 디자인을 Microsoft에 제시한 경우 “구현됨” 필드에 비트를 설정할 수 있습니다. 이러한 테스트가 통과되면 해당 구조체에서 “확인됨” 필드를 설정할 수 있습니다.

IHV, IBV 및 OEM에 대한 테스트 모듈(있는 경우)을 실행해야 합니다. SecurityFeaturesEnabled 필드의 비트에 설정된 실제 값은 통과 테스트 결과를 나타냅니다. 테스트를 실행하지 않거나 통과하지 못하면 대표 비트에 대해 0 값을 설정해야 합니다.

결과 처리 논리 예제

이 예제는 결과 처리에서 사용할 논리를 대표합니다. 구현됨 비트 필드는 1이 구현됨을 의미하고 0이 구현되지 않음을 의미하는 형식을 따라야 합니다. 구현된 것이 있으면 이 필드는 필수 필드입니다. 결과 비트 필드는 0이 실패했거나 테스트가 없음을 의미하고 1이 긍정 통과만을 의미하는 형식을 따라야 합니다.

모든 결과가 계산되면 IHV 결과 비트 필드는 필수 비트 필드와 NXOR됩니다. 모든 비 IHV 결과 비트 필드는 해당 구현됨 비트 필드와 AND됩니다. 결과 비트 필드는 전체 결과를 얻기 위해 모두 함께 OR됩니다. 이 작업의 통과 결과는 완전히 1로 구성된 비트 필드가 됩니다.

결과물 및 소유권

IHV(독립 하드웨어 공급업체) 및 IBV(독립 BIOS 공급업체)

연결된 대기 시스템을 지원하는 실리콘 공급업체 및 IBV는 해당 참조 플랫폼의 해당 하드웨어 및 펌웨어 보안 상태를 쿼리하기 위한 플랫폼 독립 인터페이스를 구현해야 합니다. 이러한 구현은 컴파일된 모듈 형태로 전달되어야 합니다. 이러한 모듈은 서명하는 것이 좋으며 이 모듈을 실행할 때는 서명 검사가 수행됩니다. 목적은 하드웨어 및 펌웨어 디자인 및 상태를 쿼리하여 플랫폼의 적절한 보안 프로비저닝을 보고하는 것입니다.

OEM 및 ODM

OEM 및 ODM은 공급업체에서 제공한 HSTI 테스트를 수정하거나 변조해서는 안 됩니다. OEM 및 ODM은 시스템이 Windows 인증 요구 사항의 구성 요소로 HSTI 테스트를 통과하도록 보장해야 합니다.

Windows 하드웨어 인증 요구 사항 - Windows 8.1 WHCR

  • System.Fundamentals.Firmware.UEFISecureBoot
  • System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby

OEM에 수정 대신, 동일하거나 더 나은 보안을 제공하는 대체 방법을 제공하는 방법이 필요한 경우 추가 보안 검사를 제공할 수 있습니다. OEM 보안 검사는 적어도 하나의 IHV 또는 IBV 보안 테스트를 완전히 포함해야 합니다. OEM은 사용 전 디자인 검토를 위해 Microsoft에 디자인을 제출해야 하며 다른 HSTI 테스트 공급자와 동일한 설명서 및 도구 공개 요구 사항이 적용됩니다. Microsoft의 승인이 있으면 OEM은 IHV 및 IBV 테스트 시 확장되는 보안 테스트를 포함할 수 있습니다.

OEM 증명은 HSTI 디자인의 일부로 필요하지 않습니다. HSTI는 OEM에 대한 요구 사항 목록이 아니며 펌웨어, 하드웨어 및 구성 매개 변수의 효과적인 프로그래밍 방식 보안 테스트를 보장하는 인터페이스입니다.

보안 상태 인터페이스

인터페이스는 UEFI 버전 2.4에 정의된 EFI 어댑터 정보 프로토콜을 기준으로 합니다.

플랫폼 보안 상태 인터페이스

요약

플랫폼 보안 정보 - Windows 하드웨어 인증 요구 사항 System.Fundamentals.Firmware.CS.UEFISecureBoot, System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby 및 System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning에 대한 플랫폼 적합성 관련 정보를 반환합니다.

프로토타입

InformationType

#define ADAPTER_INFO_PLATFORM_SECURITY_GUID \
     {0x6be272c7, 0x1320, 0x4ccd, { 0x90, 0x17, 0xd4, 0x61, 0x2c, 0x01, 0x2b, 0x25 }}

#define PLATFORM_SECURITY_VERSION_VNEXTCS   0x00000003

#define PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE   0x00000001  // IHV
#define PLATFORM_SECURITY_ROLE_PLATFORM_IBV 0x00000002
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_OEM 0x00000003 
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_ODM  0x00000004

해당 InformationBlock:

typedef struct { 
    UINT32  Version,
    UINT32  Role,
    CHAR16  ImplementationID[256],
    UINT32  SecurityFeaturesSize,
    UINT8   SecurityFeaturesRequired[],     //Ignored for non-IHV
    UINT8   SecurityFeaturesImplemented[],
    UINT8   SecurityFeaturesVerified[],
    // CHAR16   ErrorString[];
} ADAPTER_INFO_PLATFORM_SECURITY;
용어 Description

버전

PLATFORM_SECURITY_VERSION_VNEXTCS를 반환합니다.

역할

이 인터페이스 게시자의 역할입니다. IHV 및 IBV와 같은 참조 플랫폼 디자이너는 각각 PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE 및 PLATFORM_SECURITY_ROLE_PLATFORM_IBV를 반환해야 합니다. 디자이너의 테스트 모듈이 모든 보안 기능을 완전히 확인할 수는 없는 경우 플랫폼 구현자, OEM 및 ODM은 구현자 역할로 이 인터페이스를 게시해야 합니다.

ImplementationID

이 구현의 사람이 읽을 수 있는 공급업체, 모델 및 버전입니다. “SiliconVendorX Chip1234 v1” 및 “BIOSvendorY BIOSz v2”를 예로 들 수 있습니다.

SecurityFeaturesSize

SecurityFeaturesRequired 및 SecurityFeaturesEnabled 배열의 크기(바이트)입니다. 배열 크기는 같아야 합니다.

SecurityFeaturesRequired

PLATFORM_SECURITY_VERSION 버전에서 정의한 보안 요구 사항을 충족하기 위해 구현해야 하는 모든 보안 기능에 해당하는 IHV 정의 비트 필드입니다. 예를 들어 버전을 충족하려면 7개의 기능을 구현해야 할 수 있으며 0b01111111 값이 보고될 수 있습니다.

SecurityFeaturesImplemented

이 모듈에서 프로그래밍 방식으로 테스트를 구현한 모든 보안 기능에 해당하는 게시자 정의 비트 필드입니다.

SecurityFeaturesVerified

이 구현에서 구현된 것으로 확인된 모든 보안 기능에 해당하는 게시자 정의 비트 필드입니다.

ErrorString

OEM/ODM이 오류를 해결하는 단계에 대한 설명서를 찾는 데 사용할 수 있는 고유 식별자를 포함하며 줄당 하나의 오류(CR/LF 종료됨)를 나타내는 Null로 종료된 문자열로, 설명서에 대한 URL을 사용하는 것이 좋습니다. 예를 들어 

0x4827 JTAG not disabled http://somewhere.net/docs/remediate4827.html \r\n0x2744 Platform Secure Boot key not provisioned http://somewhere.net/docs/remediate2744.html

메모리 관리 고려 사항

HSTI 모듈 간의 호환성을 위해 구현자는 AllocatePages()가 아닌 AllocatePool()을 사용해야 합니다.

HSTI 구현의 디자인 검토

Microsoft는 모든 테스트 인터페이스 구현에 대해 예비 디자인 검토를 수행해야 합니다. 디자인 검토에서 제시될 수 있는 질문의 예제는 HSTI 디자인 고려 사항 섹션에 제공됩니다.

선택적 코드 검토

HSTI 구현자는 Microsoft에서 수행하는 코드 검토를 요청할 수 있습니다. 코드 검토는 리소스의 우선 순위 및 가용성에 따라 제공될 수 있으며 보장되지 않습니다. 코드 검토는 비공개 계약에 따라 수행됩니다.

설명서 및 도구 공유

실리콘 및 펌웨어 공급업체는 OEM에 제공하는 모든 필수 보안 관련 참조 설명서 및 도구를 Microsoft에 제공해야 합니다. 이 설명서 및 도구는 Windows OEM에 제공될 때까지는 사용 가능해야 합니다. 여기에는 펌웨어, 펌웨어 및 부팅 복구, 하드웨어 진단, 펌웨어 진단, 부팅 진단 융합, 설치 및 업데이트와 관련된 모든 설명서 및 도구가 포함되어야 합니다. 제공된 이 설명서 및 도구는 랩 환경에서 HSTI 검사를 수행하기에 충분해야 합니다.

HSTI 디자인 고려 사항

다음은 HSTI 구현자가 HSTI 구현을 위해 고려해야 하는 디자인 고려 사항을 설명하는 목록입니다. 이것은 엄격한 요구 사항 목록이 아니며 완전한 고려 사항 목록도 아닙니다. HSTI 구현자는 작업 중인 보안 기능의 유효성을 가능한 한 포괄적으로 검사하는 테스트를 작성합니다. Microsoft에서 디자인을 검토하기 전에 이 목록을 검토하여 개요를 파악하는 것이 좋으며, 이러한 기능을 구현하는 경우 최대한 광범위하게 테스트하는 것이 좋습니다.

실리콘 제공업체/공급업체(IHV) HSTI 검사

  1. RSA 2048 및 SHA256만(또는 유사한 암호화 강도) 사용하나요?
  2. 보호된 스토리지에 펌웨어 코드가 있어야 합니다.
    1. spiflash를 보호하나요?
    2. eMMC 파티션을 다시 설정할 때까지 읽기 전용을 구현하나요?
    3. 서명된 펌웨어 검사를 지원하나요? OEM에서 설치한 펌웨어는 읽기 전용이거나 보안 펌웨어 업데이트 프로세스로 보호됩니다.
  3. 보안 펌웨어 업데이트 프로세스
    1. 기본적으로 보안 펌웨어 업데이트 프로세스가 테스트 키를 사용하여 설정되나요? (권장)
    2. 테스트 키가 프로덕션에서 사용되는지 확인하나요?
    3. 안전하지 않은 펌웨어 버전으로의 롤백을 허용하나요? 그렇다면 보호 메커니즘이란 무엇인가요? 롤백이 발생할 때 TPM을 지우나요?
  4. SecureBoot를 재정의할 백도어가 있나요?
    1. 시스템이 Secureboot를 우회하라는 인라인 메시지를 지원하나요? 그렇다면 SecureBoot를 사용하도록 설정할 경우 이 기능이 사용되지 않나요?
    2. 제조 백도어가 있나요? SecureBoot를 사용하도록 설정한 경우에는 사용하지 않도록 설정하고, 프로덕션 시스템에서는 항상 사용하지 않도록 설정할 수 있는지 확인하나요?
  5. [CS] 부팅 무결성 지원
    1. 부팅 무결성을 지원하며, 기본적으로 이 기능이 사용하도록 설정되어 있나요?
    2. 플랫폼은 초기 부팅 코드를 저장하기 위해 종료 시 ROM 또는 OTP(일회성 프로그래밍 가능) 메모리를 사용하고, 종료 시 ROM 또는 보안 종료 시 SRAM에서 실행하기 위한 전원 켜기 재설정 논리를 제공합니다.
  6. [CS] 내부 및 외부 DMA로부터 보호
    1. 부팅하는 동안 필요한 구성 요소에 대해서만 내부 DMA를 켜두나요? 그리고 다른 모든 구성 요소에 대해서는 사용하지 않도록 설정합니다.
    2. 부팅하는 동안 필요한 구성 요소에 대해서만 외부 DMA를 켜두나요? 그리고 다른 모든 구성 요소에 대해서는 사용하지 않도록 설정합니다.
    3. 펌웨어에 DMA 보호를 사용하거나 사용하지 않도록 설정하는 옵션이 있는 경우 배송 구성에는 기본적으로 DMA 보호가 사용하도록 설정되어 있어야 합니다.
    4. 다양한 NV 및 휘발성 스토리지 지역에 DMA 방식으로 액세스할 수 있는 버스/디바이스(퓨즈, 보안 엔진, TZ, 비디오, 캐시, IMEM, 커널 메모리)는 무엇이며 어떻게 보호되나요?
    5. MOR 비트 구현을 지원하나요?
  7. 외부 하드웨어 디버거에 대한 보호
    1. JTAG를 지원하나요? SecureBoot가 ON인 경우 JTAG가 OFF인가요?
    2. JTAG 보호를 사용하지 않도록 설정하기 위해 제조 백도어 제공하나요? 이 백도어가 프로덕션 시스템에 없는지 확인하나요?
    3. JTAG를 사용하도록 설정할 경우 TPM을 지우나요?
    4. 다른 하드웨어 디버거를 지원하나요? 또한 그에 대해 동일한 검사를 수행하나요?
  8. 디바이스별 고유 비밀을 올바르게 프로비저닝했나요?
  9. 가지고 있는 보안 퓨즈(공급업체별)란?
    1. SOC SecureBoot 퓨즈
    2. 인증 또는 암호화 퓨즈와 같은 디바이스별 고유 비밀
    3. JTAG 퓨즈
    4. SOC 앱 프로세서 SecureBoot 퓨즈
    5. SOC MBA 프로세서 SecureBoot 퓨즈
    6. SOC 최신 프로세서 SecureBoot 퓨즈
    7. 사용하는 플랫폼용 기타 SOC 특정 퓨즈

IBV HSTI 검사

  1. RSA 2048 및 SHA256만(또는 그 이상) 사용하나요?
  2. 호환성 지원 모듈(CSM)
    1. CSM을 사용하도록 설정하는 옵션을 제공하나요?
    2. SecureBoot가 사용하도록 설정될 경우 CSM 로드 차단을 확인하나요?
    3. [CS]CSM이 CS 시스템에 영구적으로 없는지 확인하나요?
  3. 보호된 스토리지에 펌웨어 코드가 있어야 합니다.
    1. spiflash를 보호하나요?
    2. eMMC 파티션을 다시 설정할 때까지 읽기 전용을 구현하나요?
    3. 서명된 펌웨어 검사를 지원하나요? OEM에서 설치한 펌웨어는 읽기 전용이거나 보안 펌웨어 업데이트 프로세스로 보호됩니다.
  4. 보안 펌웨어 업데이트 프로세스
    1. 기본적으로 보안 펌웨어 업데이트 프로세스가 테스트 키를 사용하여 설정되나요?
    2. 테스트 키가 프로덕션에서 사용되는지 확인하나요?
    3. 안전하지 않은 펌웨어 버전으로의 롤백을 허용하나요? 그렇다면 보호 메커니즘이란 무엇인가요? 롤백이 발생할 때 TPM을 지우나요?
    4. 테스트 키가 사용되고 있나요?
  5. SecureBoot를 재정의할 백도어가 있나요?
    1. 시스템이 Secureboot를 우회하라는 인라인 메시지를 지원하나요? 그렇다면 SecureBoot를 사용하도록 설정할 경우 이 기능이 사용되지 않나요?
    2. 제조 백도어가 있나요? SecureBoot를 사용하도록 설정한 경우에는 사용하지 않도록 설정하고, 프로덕션 시스템에서는 항상 사용하지 않도록 설정할 수 있는지 확인하나요?
  6. [CS] 내부 및 외부 DMA로부터 보호
    1. 부팅하는 동안 필요한 구성 요소에 대해서만 내부 DMA를 켜두나요? 그리고 다른 모든 구성 요소에 대해서는 사용하지 않도록 설정합니다.
    2. 부팅하는 동안 필요한 구성 요소에 대해서만 외부 DMA를 켜두나요? 그리고 다른 모든 구성 요소에 대해서는 사용하지 않도록 설정합니다.
    3. 펌웨어에 DMA 보호를 사용하거나 사용하지 않도록 설정하는 옵션이 있는 경우 배송 구성에는 기본적으로 DMA 보호가 사용하도록 설정되어 있어야 합니다.
    4. 다양한 NV 및 휘발성 스토리지 지역에 DMA 방식으로 액세스할 수 있는 버스/디바이스(퓨즈, 보안 엔진, TZ, 비디오, 캐시, IMEM, 커널 메모리)는 무엇이며 어떻게 보호되나요?
    5. MOR 비트 구현을 지원하나요?