ASHWID(앱 관련 하드웨어 ID)를 사용하여 장치별 앱 논리를 구현하는 방법에 대한 지침

Applies to Windows and Windows Phone

이 항목에서는 클라우드 구성 요소가 있는 앱이 백 엔드 서비스와 함께 ASHWID(응용 프로그램 관련 하드웨어 ID)를 사용하여 장치별 논리를 구현하는 방법을 보여 줍니다. 장치별 라이선싱 정책을 사용하는 앱은 이 범주에 속하는 앱의 예입니다.

참고  이 항목에서는 암호화 및 콘텐츠 라이선싱 환경에 대해 완전히 이해한 것으로 가정합니다.

소개

Windows 스토어 앱은 여러 장치 간에 데이터와 콘텐츠를 쉽게 공유하도록 설계되었습니다. 소비자가 이러한 환경을 즐기는 동안 콘텐츠 사용자 허가자에게는 콘텐츠 배포를 고정된 수의 장치로 제한하는 메커니즘이 필요한 경우가 자주 있습니다. 콘텐츠 라이선싱 앱과 같은 일부 앱은 장치별 라이선싱 정책을 준수해야 합니다. 백 엔드 클라우드 서비스와 함께 ASHWID(응용 프로그램 관련 하드웨어 ID)에서 솔루션을 제공합니다. ASHWID는 여러 가지 개별 하드웨어 특징을 표시하여 앱/패키지와 장치 간의 강력한 바인딩을 제공합니다. 사용자 개인 정보를 보호하기 위해 ASHWID는 앱마다 다릅니다. 기본 하드웨어가 변경되지 않는 한 동일한 앱에서 두 번 호출하면 ASHWID가 동일합니다. 그러나 사용자가 USB Bluetooth 어댑터를 분리하는 경우처럼 장치의 하드웨어 프로필이 변경되면 ASHWID가 변경됩니다. 백 엔드 클라우드 서비스는 ASHWID를 확인하여 이전에 보고된 값과 비교할 수 있습니다. ASHWID는 달라지지만 구문 분석하면 차이가 시스템에 메모리 추가와 같은 사소한 변경으로 인해 발생한 것인지 확인할 수 있습니다. 이러한 차이에 대한 오차 허용 수준은 백 엔드 클라우드 서비스의 구현에 따라 달랍니다. ASHWID를 구성하는 특정 요소 및 해당 요소를 구문 분석하는 방법에 대한 지침은 다음 섹션에서 제공합니다.

상위 수준의 앱은 다음 단계를 수행할 수 있습니다.

  1. 앱의 클라이언트 코드에서 HardwareIdentification.GetPackageSpecificToken 메서드를 호출하고 ASHWID를 앱의 서버 백 엔드에 반환합니다.
  2. 클라우드 서비스는 이 값이 Windows에서 제공되었으며 신뢰할 수 있는지 검증합니다.
  3. 클라우드 서비스는 가져온 ASHWID를 이 사용자가 제공하여 이전에 기록된 값과 비교하여 일치 여부를 확인하고 장치가 서비스에서 허용된 오차 허용 수준 내에 있는지를 결정합니다.
  4. 클라우드 서비스는 특정 장치에서 해당 콘텐츠의 사용을 허용하거나 허용하지 않습니다.

유용한 항목

이 항목에서 사용되는 정의설명

Package ID

패키지 이름, 게시자, 버전, 리소스 및 architecture(x86, x64, ARM 또는 중립)로 이루어진 5부 튜플로 구성됩니다.

Package full name

게시자 이름이 해시된 연결된 패키지 ID입니다. ( <package name>_<Version>_<Architecture>_< Resources>_<Base32(SHA256(Publisher))>) e.g. microsoft.office_15.0.0.0_x86_en-us_tf9ntdy1vxe7p (마지막 용어가 게시자의 해시임) .

Package family name

해시된 게시자 이름과 연결된 패키지 이름입니다.

암호화 nonce

보안 엔지니어링에서 nonce는 한 번만 사용되는 숫자입니다. 일반적으로 숫자의 다시 사용 가능성을 줄일 만큼 충분히 큰 난수로 구현됩니다. nonce는 인증 프로토콜에서 재생 공격을 방지하는 데 사용됩니다. .

ASHWID

앱 관련 하드웨어 ID입니다.

 

ASHWID의 구조

ASHWID는 앱이 실행되는 특정 장치의 여러 가지 개별 하드웨어 특성을 캡슐화합니다. ASHWID는 시스템 차원 동작의 대상 지정을 방지하고 사용자의 개인 정보를 보호하기 위해 각 앱/패키지에 따라 달라지도록 의도적으로 설계되었습니다. ASHWID는 시스템 차원 광고 시나리오를 사용하도록 설계되지 않았습니다.

ASHWID는 장치를 구성하는 구성 요소를 사용하여 생성됩니다. 각 구성 요소(있는 경우)는 반환된 ASHIWD 바이트 스트림의 섹션에 영향을 줍니다. 아래에 9개의 구성 요소가 나열되어 있습니다.

  1. 프로세서의 CPU ID
  2. 메모리의 크기
  3. 디스크 장치의 일련 번호
  4. 네트워크 어댑터(예: NIC MAC 주소)
  5. 오디오 어댑터
  6. 도킹 스테이션
  7. Bluetooth 주소
  8. 모바일 광대역 장치 ID
  9. BIOS

ASHWID는 정확히 9개의 구성 요소 ID로 구성되지 않을 수 있습니다. 가능한 이유는 다음과 같습니다.

  • 대상 하드웨어에 정확히 9개의 개별 구성 요소가 없을 수 있습니다. 예를 들어 데스크톱에 도킹 스테이션이 없을 수 있습니다.
  • 장치에 동일한 유형의 구성 요소가 여러 개 있을 수 있습니다. 예를 들어 두 개의 오디오 어댑터가 있을 수 있습니다.
  • 각 실제 디스크 드라이브는 하나의 구성 요소 ID를 구성합니다. 3개의 실제 디스크 드라이버가 있는 데스크톱 시스템은 3개의 구성 요소 ID를 반환합니다.
  • 도킹 스테이션에 연결된 경우 태블릿은 추가 네트워크 어댑터(이더넷) 및 오디오 어댑터(HDMI 또는 아날로그 오디오 출력 포트)에 대해 구성 요소 ID를 반환합니다.

아래에 표시된 대로 각 구성 요소를 나타내는 바이트 스트림의 섹션을 식별할 수 있습니다.

바이트 스트림은 여러 그룹의 4바이트로 구성됩니다. 처음 2바이트에는 구성 요소의 유형이 포함되고 다음 2바이트에는 해당 값이 포함됩니다. 아래 표를 사용하여 각 구성 요소의 유형을 식별합니다.

바이트 스트림 표현구성 요소
1,0프로세서
2,0 메모리
3,0디스크 장치
4,0네트워크 어댑터
5,0 오디오 어댑터
6,0도킹 스테이션
7,0모바일 광대역
8,0Bluetooth
9,0시스템 BIOS

 

샘플 ASHWID

서로 다른 구성 요소 ID의 열거 순서가 반드시 순차적이지는 않습니다. 다음 스트림은 몇 가지 샘플 ASHWID를 보여 줍니다. 스트림에서 구성 요소 ID의 번호 및 해당 순서는 달라질 수 있습니다.

  • 7,0,124,215,3,0,206,143,8,0,128,55,5,0,12,222,5,0,128,255,6,0,1,0,4,0,20,22,4,0,48,155,1,0,250,155,2,0,162,217,9,0,92,101

    Samsung Intel Core i5 슬레이트에 있는 모바일 광대역입니다.

  • 7,0,124,215,3,0,206,143,8,0,128,55,5,0,126,129,5,0,12,222,5,0,128,255,6,0,1,0,4,0,20,22,4,0,48,155,4,0,178,193 ,1,0,250,155,2,0,162,217,9,0,92,101

    도킹된 경우 같은 장치에 있는 세 개의 다른 오디오 어댑터와 도킹된 경우 세 개의 다른 네트워크 어댑터입니다.

  • 3,0,188,97,3,0,76,128,3,0,250,138,5,0,220,130,6,0,1,0,4,0,20,164,1,0,204,49,2,0,226,37,9,0,22,72

    데스크톱에 있는 세 가지 다른 디스크입니다.

  • 3,0,24,211 ,5,0,182,46,5,0,54,49,6,0,1,0,4,0,203,9,1,0,148,99,2,0,162,255,9,0,140,234

    Nvidia Tegra 3 장치입니다. 장치나 폼 요소에 관계없이 스트림"6,0,1,0"은 도킹 스테이션에 해당함을 알 수 있습니다.

클라이언트에서 ASHWID 생성

API 사용

HardwareIdentification.GetPackageSpecificToken 메서드는 Windows 스토어 앱에서 해당 앱이 실행되고 있는 장치의 ASHWID를 생성하는 방법을 제공합니다. 이 API를 호출하는 두 개의 앱은 동일한 장치에서 서로 다른 ASHWID를 반환합니다. 지정된 앱/패키지의 경우 ASHWID가 다음 항목의 영향을 받지 않습니다.

  • OS 다시 설치
  • 원스톱 복원
  • OS SKU 업그레이드
  • 앱의 버전 업데이트
  • 동일한 장치에서 사용자 변경

Windows 스토어 앱의 클라우드 서비스 구성 요소는 선택적인 nonce, 서명 및 인증서를 사용하여 ASHWID가 정품인지 확인할 수 있습니다. 이 WinRT API는 지원되는 모든 프로그래밍 언어에서 프로젝션을 통해 사용할 수 있습니다.

선택적 nonce 사용

앱에는 GetPackageSpecificToken 메서드에 대한 입력으로 암호화 nonce를 전달하는 옵션이 있습니다. 클라우드에서는 매번 다른 nonce를 제공하여 반환된 ASHWID가 실제로 Windows에서 제공되었으며 사용자에 의해 재생되지 않았는지 검증할 수 있습니다. nonce는 ASHWID의 최신성을 확인하는 데 도움이 되며 재생 공격을 완화할 수 있습니다. 클라우드 서비스에서 nonce를 사용할 경우 클라우드 서비스가 nonce를 보낸 후 ASHWID가 생성되었는지 확인하는 방법이 있습니다. 클라우드 서비스에서 재생 공격이 염려되는 경우에는 null nonce를 전달하지 않는 것이 좋습니다.

샘플 클라이언트 쪽 코드

ASHWID를 만드는 클라이언트 쪽 코드 예는 HardwareIdentification.GetPackageSpecificToken을 참조하세요.

클라우드에서 ASHWID 처리

하드웨어 드리프트 설명

장치를 구성하는 구성 요소는 변경될 수 있습니다. 이러한 변경을 '하드웨어 드리프트'라고 합니다. 지정된 장치의 ASHWID는 다양한 이유로 쿼리되는 시기에 따라 변경될 수 있습니다.

  • 사용자는 기존 장치를 업그레이드하거나 확장하여 ASHWID에 영향을 주는 구성 요소가 변경되도록 결정할 수 있습니다.
  • 사용자는 구성 요소 목록에 추가되는 주변 장치를 해당 장치에 일시적으로 연결할 수 있습니다.
  • 전원 관리 장치(ARM 프로세서에서 실행되는 슬레이트 및 장치의 경우)는 배터리 수명을 유지하기 위해 특정 하드웨어 구성 요소의 전원을 끌 수 있습니다.

하드웨어 드리프트는 앱에서 ASHWID 바이트 스트림을 있는 그대로 사용하면 안 되는 이유입니다. 몇 가지 하드웨어 구성 요소가 변경되거나 전원이 꺼진 경우 API에서 다른 ASHWID를 반환합니다. 앱에서 동일한 장치를 새 장치로 잘못 식별할 위험이 있습니다. 다음은 하드웨어 드리프트를 발생시킬 수 있는 몇 가지 시나리오입니다.

  • 일과가 끝나갈 즈음 사용자는 집에 도착할 때까지 배터리가 유지되도록 하려고 합니다. 따라서 Bluetooth 및 Wi-Fi의 전원은 끄고 클라우드 연결을 위해 3G/4G를 켜 둡니다.
  • 사용자가 USB 3G 데이터 카드의 전원을 연결합니다.
  • 기본 OS/System on Chip 전원 관리에서 특정 코어의 전원을 끌 수 있습니다.

각 시나리오에서 앱이 하드웨어 드리프트를 해결할 수 있는 방법 중 하나는 비즈니스 논리에 따라 반환된 각 구성 요소 ID에 가중치를 추가하여 점수를 계산하는 것입니다. 계산된 점수는 동일한 장치로 식별되도록 클라우드 구성 요소에서 설정한 임계값을 통과해야 합니다.

다음은 클라우드 서비스 내에서 하드웨어 드리프트를 처리할 수 있는 유일한 방법을 보여 주는 간단한 그림입니다.


If 	[(Component_1_previous == Component_1_current) x Weight_1 + 
(Component_2_previous == Component_2_current) x Weight_2 + 
(Component_3_previous == Component_3_current) x Weight_3 + ……..
(Component_n_previous == Component_n_current) x Weight_n]  
>= [Threshold_for_being_the_same_device]
Then It_is_the_same_device	

장치 식별에서 상대적 가중치 사용

상대적 가중치는 비즈니스 논리 및 허용되는 하드웨어 드리프트로 결정한 사항에 따라 달라집니다. 명시적으로 권장되는 가중치 값은 없습니다. 일부 구성 요소는 다른 구성 요소보다 변경될 가능성이 적으며 더 높은 가중치를 받을 가능성이 적습니다. 예를 들어 BIOS는 오디오 어댑터보다 변경될 가능성이 적습니다. 시스템에 연결된 드라이브 수에 따라 여러 디스크 드라이브가 표시될 수 있습니다. OS가 설치되어 있는 드라이브의 구성 요소 ID는 변경될 가능성이 적습니다. 대부분의 x86/x86-64 시스템에 있는 프로세서 구성 요소 ID는 매우 안정적입니다. 도킹 스테이션 구성 요소에서 동일한 구성 요소 ID를 반환하는 경우 0 가중치를 할당하는 것이 적합할 수 있습니다.

클라우드에서 ASHWID 인증

반환된 ASHWID는 서명되어 있습니다. 이 ASHWID는 앱에서 반환된 ASHWID가 Windows에서 제공되었는지를 검증하는 방법을 제공합니다. 이동 nonce를 입력으로 전달하면 재생 공격을 방지할 수 있습니다.

ASHWID는 클라이언트에서 개인 키를 사용하여 해시됩니다. 아래 다이어그램에서는 서명의 형식을 보여 줍니다.

서명의 형식

인증서 해지 목록

원격으로 개인 키가 손상될 가능성이 있습니다. 이 경우 체인의 모든 인증서에 대해 해지 확인을 사용하는 한 키를 업데이트하는 추가 코드가 앱(클라이언트 또는 클라우드)에 없어도 됩니다.

클라우드 쪽 워크플로에 대한 지침

다음은 클라우드 쪽 구성 요소 개발자가 따를 수 있는 워크플로입니다. 인증서, 서명 및 하드웨어 ID를 받으면 다음과 같은 단계를 사용하여 ASHWID의 신뢰성을 검증합니다.

  1. 인증서의 신뢰성 및 유효성을 검증합니다. 이 단계에서는 "Microsoft Assurance Designation Root 2011" 루트 인증서를 클라우드 시스템에서 신뢰할 수 있는 것으로 가정합니다. 루트 인증서는 Windows 기반 서버의 신뢰할 수 있는 루트 저장소에 수동으로 추가해야 합니다.
    1. Certificate blob에 PKCS#7 형식의 인증서 체인이 있습니다. 빌드하고 인증서 체인을 신뢰할 수 있는지 검증합니다. 만료된 리프 인증서로 인한 신뢰 체인 검증 오류는 무시해야 합니다.
    2. 인증서 체인에서 해지 오류가 검사되었는지 확인합니다. 오프라인 CDP로 인한 해지 오류는 무시하는 것이 좋습니다.
    3. 리프 인증서에 "1.3.6.1.4.1.311.10.5.40" EKU가 있는지 확인합니다.
    4. 인증서 체인의 루트 인증서에서 공개 키를 쿼리하고 "Microsoft Assurance Designation Root 2011" 루트 인증서의 공개 키와 일치하는지 확인합니다.
  2. ASHWID가 순수하게 신뢰할 수 있는 Windows 코드에서 생성되었는지 검증합니다.
    1. 서명 blob은 nonce(있는 경우)와 ASHWID 연결에서 SHA1 해시의 서명된 blob입니다.
    2. 리프 인증서를 사용하여 서명된 해시 서명이 클라우드 서비스 및 받은 하드웨어 바이트 스트림에서 전송된 원래 nonce와 일치하는지 검증합니다.

관련 항목

ASHWID(앱 관련 하드웨어 ID) 클라우드 구성 요소
HardwareToken
HardwareToken.Certificate
HardwareToken.Signature
HardwareIdentification
HardwareIdentification.GetPackageSpecificToken

 

 

표시:
© 2014 Microsoft