OEM용 Windows 10의 BitLocker 드라이브 암호화

  • 아티클

BitLocker 드라이브 암호화는 운영 체제가 오프라인인 동안 드라이브가 변조되지 않도록 하여 오프라인 데이터 및 운영 체제 보호를 제공합니다. BitLocker 드라이브 암호화는 신뢰할 수 있는 컴퓨팅 그룹에 정의된 대로 정적 신뢰 루트 측정을 지원하는 개별 또는 펌웨어 TPM을 사용합니다.

BitLocker 드라이브 암호화 하드웨어 요구 사항

BitLocker 드라이브 암호화는 Windows 파티션과 별도로 시스템 파티션을 사용합니다. BitLocker 시스템 파티션은 다음 요구 사항을 충족해야 합니다.

  • BitLocker 시스템 파티션은 활성 파티션으로 구성됩니다.
  • BitLocker 시스템 파티션을 암호화하면 안 됩니다.
  • BitLocker 시스템 파티션에는 필수 파일이 사용하는 공간 이상으로, 250MB 이상의 여유 공간이 있어야 합니다. 이 추가 시스템 파티션은 파티션이 250MB의 사용 가능한 공간 요구 사항을 충족하는 한 Windows RE(복구 환경) 및 OEM 도구(OEM에서 제공)를 호스트하는 데 사용할 수 있습니다.

자세한 내용은 시스템 및 유틸리티 파티션, 하드 드라이브 및 파티션을 참조하세요.

BitLocker 자동 디바이스 암호화

BitLocker 자동 디바이스 암호화는 BitLocker 드라이브 암호화 기술을 사용하여 사용자가 최신 대기 또는 HSTI 규격 하드웨어에서 OOBE(첫 실행 경험)를 완료한 후 내부 드라이브를 자동으로 암호화합니다.

참고 항목

BitLocker 자동 디바이스 암호화는 OOBE(기본 제공) 환경 중에 시작됩니다. 그러나 사용자가 Microsoft 계정 또는 Azure Active Directory 계정으로 로그인한 후에만 보호가 활성화(준비)됩니다. 그 때까지는 보호가 일시 중단되고 데이터가 보호되지 않습니다. BitLocker 자동 디바이스 암호화는 로컬 계정에서 사용하도록 설정되지 않습니다. 이 경우 BitLocker 제어판을 사용하여 BitLocker를 수동으로 사용하도록 설정할 수 있습니다.

BitLocker 자동 디바이스 암호화 하드웨어 요구 사항

BitLocker 자동 디바이스 암호화는 다음 경우에 사용하도록 설정됩니다.

  • 디바이스에는 TPM 1.2 또는 TPM 2.0의 TPM(신뢰할 수 있는 플랫폼 모듈)이 포함되어 있습니다.
  • UEFI 보안 부팅이 사용하도록 설정되었습니다. 자세한 내용은 보안 부팅을 참조하세요.
  • 플랫폼 보안 부팅이 사용하도록 설정되었습니다.
  • DMA(직접 메모리 액세스) 보호가 사용하도록 설정되었습니다.

Windows 10 자동 BitLocker 디바이스 암호화를 사용하도록 설정하기 전에 다음 테스트를 통과해야 합니다. 이 기능을 지원하는 하드웨어를 만들려면 디바이스가 이러한 테스트를 통과했는지 확인해야 합니다.

  1. TPM: 디바이스에는 PCR 7을 지원하는 TPM이 포함되어야 합니다. System.Fundamentals.TPM20.TPM20을 참조하세요.

    • 확장 가능한 카드가 있으면 부팅 중에 UEFI BIOS에 의해 OROM UEFI 드라이버가 로드되는 경우 BitLocker는 PCR7 바인딩을 사용하지 않습니다.
    • PCR7에 바인딩되지 않는 디바이스를 실행하고 Bitlocker를 사용하는 경우 일반 UEFI PCR 프로필(0,2,4,11)을 사용할 때 BitLocker가 여전히 안전하기 때문에 보안 단점이 없습니다.
    • 최종 bootmgr Windows Prod CA 전에 추가 CA 해시(또는 Windows Prod CA)는 BitLocker가 PCR7을 사용하도록 선택하는 것을 방지합니다. 추가 해시가 UEFI CA(Microsoft 타사 CA) 또는 다른 CA에서 온 것인지는 중요하지 않습니다.

  2. 보안 부팅: UEFI 보안 부팅이 사용하도록 설정되었습니다. System.Fundamentals.Firmware.UEFISecureBoot를 참조하세요.

  3. 최신 대기 요구 사항 또는 HSTI 유효성 검사. 이 요구 사항은 다음 중 하나에 의해 충족됩니다.

    • 최신 대기 요구 사항이 구현됩니다. 여기에는 UEFI 보안 부팅에 대한 요구 사항 및 무단 DMA로부터의 보호가 포함됩니다.
    • Windows 10 버전 1703부터 HSTI 테스트를 통해 이 요구 사항을 충족할 수 있습니다.
      1. 플랫폼 보안 부팅 자체 테스트(또는 레지스트리에 구성된 추가 자체 테스트)는 구현 및 통과된 것으로 HSTI에서 보고해야 합니다.
      2. Thunderbolt를 제외하면 HSTI는 허용되지 않는 DMA 버스를 보고하지 않아야 합니다.
      3. Thunderbolt가 있는 경우 HSTI는 Thunderbolt가 안전하게 구성되어 있음을 보고해야 합니다(보안 수준은 SL1 – "사용자 권한 부여" 이상이어야 함).

  4. 부팅해야 하는 모든 항목 외에 250MB의 여유 공간이 있어야 합니다(WinRE를 시스템 파티션에 배치한 경우 Windows 복구). 자세한 내용은 시스템 및 유틸리티 파티션을 참조 하세요.

위에 나열된 요구 사항이 충족되면 시스템 정보에 시스템에서 BitLocker 자동 디바이스 암호화를 지원하는 것으로 표시됩니다. 이 기능은 Windows 10 버전 1703 이상에서 사용할 수 있습니다. 시스템 정보를 확인하는 방법은 다음과 같습니다.

  1. 시작을 클릭하고 시스템 정보를 입력합니다.
  2. 시스템 정보 앱을 마우스 오른쪽 단추로 클릭하고 관리자 권한으로 열기를 클릭합니다. 예를 클릭하여 앱이 디바이스를 변경할 수 있도록 허용합니다. 일부 디바이스에서는 암호화 설정을 보려면 상승된 권한이 필요할 수 있습니다.
  3. 시스템 요약에서 디바이스 암호화 지원을 참조하세요. 이 값은 디바이스가 암호화된 경우 또는 그렇지 않은 경우 비활성화된 이유를 나타냅니다.

디바이스에 펌웨어 업데이트 적용

OEM은 HLK 테스트를 실행하는 것 외에도 BitLocker가 켜져 있는 펌웨어 업데이트를 테스트해야 합니다. 디바이스가 불필요하게 복구를 시작하지 못하도록 하려면 다음 지침에 따라 펌웨어 업데이트를 적용합니다.

  1. BitLocker 일시 중단(펌웨어 업데이트가 보안 부팅 정책을 변경하는 경우에만 PCR[07]에 바인딩된 디바이스에 필요)
  2. 업데이트 적용
  3. 디바이스를 다시 시작합니다.
  4. BitLocker 다시 시작

펌웨어 업데이트는 디바이스가 짧은 시간 동안만 Bitlocker를 일시 중단하도록 요구해야 하며, 디바이스는 최대한 빨리 다시 시작해야 합니다. BitLocker는 WMI(Windows Management Instrumentation)에서 DisableKeyProtectors 메서드를 사용하여 종료하기 직전에 프로그래밍 방식으로 일시 중단할 수 있습니다.

허용되지 않는 DMA 가능 버스/디바이스가 검색됨

디바이스 암호화 지원의 이 시스템 정보 상태는 Windows에서 DMA 위협을 노출할 수 있는 하나 이상의 잠재적인 외부 DMA 지원 버스 또는 디바이스를 검색했음을 의미합니다.

이 문제를 해결하려면 IHV에 문의하여 이 디바이스에 외부 DMA 포트가 없는지 확인합니다. IHV에서 버스 또는 디바이스에 내부 DMA만 있음을 확인한 경우 OEM은 이를 허용 목록에 추가할 수 있습니다.

허용되는 목록에 버스 또는 디바이스를 추가하려면 레지스트리 키에 값을 추가해야 합니다. 이렇게 하려면 AllowedBuses 레지스트리 키의 소유권을 먼저 가져와야 합니다. 다음 단계를 수행합니다.

  1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses 레지스트리 키로 이동합니다.

  2. 레지스트리 키를 마우스 오른쪽 단추로 클릭하고 사용 권한...을 선택합니다.

  3. 고급을 클릭하고, 소유자 필드에서 변경 링크를 클릭하고, 사용자 계정 이름을 입력하고, 이름 확인을 클릭한 다음, 확인을 세 번 클릭하여 모든 권한 대화 상자를 닫습니다.

  4. 레지스트리 키를 마우스 오른쪽 단추로 클릭하고 사용 권한...을 다시 선택합니다.

  5. 추가... 단추를 클릭하고, 사용자 계정을 추가하고, 이름 확인을 클릭한 다음, [모든 권한 허용] 아래의 확인란을 선택합니다. 그런 후 OK를 클릭합니다.

그런 다음, AllowedBuses 키 아래에서 안전한 것으로 확인된 플래그가 지정된 각 DMA 지원 버스에 대한 문자열(REG_SZ) 이름/값 쌍을 추가합니다.

  • 키: 디바이스 식별 이름 /설명
  • 값: PCI\VEN_ID&DEV_ID.

ID가 HLK 테스트의 출력과 일치하는지 확인합니다. 예를 들어 이름이 "Contoso PCI Express 루트 포트", 공급업체 ID 1022 및 디바이스 ID 157C인 안전한 디바이스가 있는 경우 contoso PCI Express Root Port라는 레지스트리 항목을 REG_SZ 데이터 형식으로 만듭니다. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses

여기서 값 = "PCI\VEN_1022&DEV_157C"

BitLocker 자동 디바이스 암호화 사용 안 함

OEM은 디바이스 암호화를 사용하지 않도록 설정하고 대신 디바이스에서 자체 암호화 기술을 구현하도록 선택할 수 있습니다. BitLocker 자동 디바이스 암호화를 사용하지 않도록 설정하려면 무인 파일을 사용하고 PreventDeviceEncryption을 True로 설정하면 됩니다.

또는 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker 레지스트리 키를 업데이트할 수 있습니다.

값: PreventDeviceEncryption 이 True(1)와 같습니다.

BitLocker HLK 테스트 문제 해결

테스트 중인 디바이스에 대한 다음 정보를 알고 있는 경우 심사가 훨씬 간단합니다.

  1. TPM 사양(예: 1.2, 2.0)
  2. BitLocker PCR 프로필(예: 7, 11 또는 0, 2, 4, 11)
  3. 컴퓨터가 AOAC가 아닌지 AOAC인지 여부(예: Surface 디바이스는 AOAC 컴퓨터)

이 정보는 권장되지만 심사를 수행할 필요는 없습니다.

BitLocker HLK 문제는 일반적으로 잘못된 테스트 결과 해석 또는 PCR7 바인딩 문제 중 하나와 관련이 있습니다.

잘못된 테스트 결과 해석

HLK 테스트는 여러 테스트 단계로 구성됩니다. 일부 테스트 단계는 전체 테스트의 성공/실패에 영향을 주지 않고 실패할 수 있습니다. 결과 페이지 해석에 대한 자세한 내용은 여기를 참조하세요. 일부 테스트 단계가 실패했지만 전체 테스트가 통과하면(테스트 이름 옆에 녹색 확인으로 표시됨) 여기서 중지합니다. 테스트가 성공적으로 실행되었으며 더 이상 작업이 필요하지 않습니다.

심사 단계:

  1. 컴퓨터에 대해 올바른 테스트를 실행하고 있는지 확인합니다. 실패한 테스트 > 인프라 > 로그 수집 > 단계를 마우스 오른쪽 단추로 클릭하면 IsAOAC 항목에 대한 RUNTIMEBLOCK.xml 내부가 표시됩니다. IsAOAC=true이고 비 AOAC 테스트를 실행하는 경우 오류를 무시하고 컴퓨터에 대해 이 테스트를 실행하지 마세요. 필요한 경우 재생 목록을 전달하기 위해 Microsoft 지원 팀에 문의하세요.

    Screenshot of the failing test. The item Is A O A C is selected.

  2. 필터가 테스트에 적용되는지 여부를 확인합니다. HLK는 잘못 매핑된 테스트에 대한 필터를 자동으로 제안할 수 있습니다. 필터는 테스트 단계 옆에 있는 원 안에 녹색 확인 표시로 나타납니다. (일부 필터는 후속 테스트 단계가 실패했거나 취소되었음을 표시할 수 있습니다.) 특수 아이콘으로 테스트 단계를 확장하여 필터에 대한 확장된 정보를 검사합니다. 필터가 테스트 실패를 무시한다고 표시되면 여기서 중지합니다.

Screenshot of filters

PCR7 문제

두 PCR7 테스트와 관련된 일반적인 BitLocker 문제는 PCR7에 바인딩하지 못하는 것입니다.

심사 단계:

  1. HLK 로그에서 오류 메시지를 찾습니다. 실패한 테스트 단계를 확장하고 Te.wtl 로그를 검사합니다. (테스트 단계 > 작업 로그 > Te.wtl을 마우스 오른쪽 단추로 클릭하여 이 로그에 액세스할 수도 있습니다.) 다음 오류가 표시되면 심사 단계를 계속 수행합니다.

    Screenshot of the error message in H L K logs.

  2. 관리자 권한으로 msinfo32를 실행하고 보안 부팅 상태/PCR7 구성을 확인합니다. 보안 부팅이 켜진 상태에서 테스트를 실행해야 합니다. PCR7 바인딩이 지원되지 않는 경우 적절한 레거시 PCR HLK 테스트를 대신 실행합니다. PCR7 바인딩이 불가능한 경우 심사 단계를 계속 수행합니다.

  3. 오류 로그를 검사합니다. 테스트 작업 > 추가 파일을 마우스 오른쪽 단추로 클릭합니다. 일반적으로 PCR7 바인딩 문제는 잘못된 PCR7 측정의 결과입니다.

    1. 이벤트 로그. Microsoft-BitLocker-Management 로그에는 PCR7을 사용할 수 없는 이유에 대한 중요한 오류 정보가 포함되어 있습니다. BitLocker HLK 테스트는 BitLocker가 설치된 컴퓨터에서만 실행되어야 합니다. 이벤트 로그는 해당 로그를 생성하는 컴퓨터에서 검사해야 합니다.
    2. 측정된 부팅 로그 이 로그는 C:\Windows\Logs\MeasuredBoot에서도 찾을 수 있습니다.

  4. TBSLogGenerator.exe 또는 동등한 값을 사용하여 측정된 부팅 로그를 구문 분석합니다. HLK 컨트롤러에서 TBSLogGenerator.exe는 HLK를 설치한 HLK 테스트 디렉터리 아래에 있습니다(예: C:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Tests\amd64\nttest\BASETEST\ngscb\TBSLogGenerator.exe)

    1. TBSLogGenerator.exe - <path to measured boot log>> OutputLog.txt인 경우
    2. OutputLog.txt에서 "PCR[07]"을 검색하고 순서대로 나열된 측정값을 검사합니다. 첫 번째 측정값은 다음과 유사합니다.

Screenshot of the measurements list in Output Log dot t x t.

BitLocker는 신뢰 측정값의 특정 정적 루트가 PCR7에서 신뢰 측정값의 정적 루트를 예상하며, 이러한 측정값의 변형으로 PCR7에 대한 바인딩이 금지되는 경우가 많습니다. 다음 값은 PCR7로 (순서대로 그리고 그 사이에 불필요한 측정 없이) 측정되어야 합니다.

  • SecureBoot 변수의 내용
  • PK 변수의 내용
  • KEK 변수의 내용
  • EFI_IMAGE_SECURITY_DATABASE 변수의 내용(DB)
  • EFI_IMAGE_SECURITY_DATABASE1 변수의 내용(DBX)
  • (선택 사항이지만 일반적인 EV_SEPARATOR)
  • 부팅 경로에서 EFI 드라이버 또는 EFI 부팅 애플리케이션의 유효성을 검사하는 데 사용되는 EFI_IMAGE_SECURITY_DATABASE의 항목 BitLocker는 여기에 하나의 항목만 예상합니다.

측정된 부팅 로그의 일반적인 문제:

  • UEFI 디버그 모드 켜기
  • 누락된 PK 또는 KEK 변수: PK/KEK 측정값에 데이터가 없습니다(예: 0의 4바이트)
  • 신뢰할 수 없는 UEFI CA 서명인

UEFI 디버그 모드를 사용하는 실행과 같은 일부 측정된 부팅 문제는 테스터가 해결할 수 있습니다. 다른 문제에는 errata가 필요할 수 있습니다. 이 경우 Microsoft 지원 팀에 문의하여 지침을 받아야 합니다.