KR101763084B1

KR101763084B1 - 신뢰의 하드웨어 루트를 사용하는 미디어 클라이언트 장치 인증

Info

Publication number: KR101763084B1
Application number: KR1020167004548A
Authority: KR
Inventors: 미하일 미하일로프; 라즈 나이르
Original assignee: 에릭슨 에이비
Priority date: 2013-07-23
Filing date: 2014-07-23
Publication date: 2017-07-28
Also published as: BR112016001608A2; KR20160105380A; CN105706048B; US20180211016A1; MX2016000881A; CN105706048A; EP3025226A4; EP3025226A1; CA2919106C; MX359837B; US10395012B2; US20160162669A1; US9922178B2; CN110287654A; BR112016001608B1; EP3025226B1; CA2919106A1; WO2015013412A1; CN110287654B

Abstract

미디어 재생을 위한 클라이언트 장치가 유저-인스톨가능한 미디어 클라이언트 애플리케이션을 포함하는데, 이는 디지털 권리 관리(DRM) 시스템의 클라이언트-측면을 구현한다. 클라이언트 장치는 보안 부트를 채용하고 유저-인스톨된 애플리케이션을 입증한다. 애플리케이션은 역설계에 대항해서 강화되고, 이는 보안 부트 내로 속박하기 위해서 클라이언트 장치에 의해 제공된 특별한 API를 사용해서, 보안 부트와 애플리케이션 내에 포함된 DRM 시스템의 클라이언트-측면 사이의 갭을 브리징한다.

Description

신뢰의 하드웨어 루트를 사용하는 미디어 클라이언트 장치 인증{MEDIA CLIENT DEVICE AUTHENTICATION USING HARDWARE ROOT OF TRUST}

클라이언트 장치상에 인스톨된 애플리케이션을 통해서 클라이언트 장치와 서버 사이에 신뢰(trust)를 수립하기 위한 기술이 개시된다.

클라이언트 장치는 미디어의 렌더링 또는 재생을 위해 적용된다. 이는 IP 접속 가능성을 갖는 STB(Set-Top-Box)가 될 수 있다. 또한, 이는, 스마트폰, 또는 소정의 다른 타입의 클라이언트 장치와 같은 모바일 장치가 될 수 있다. 클라이언트 장치상에서 구동하는 오퍼레이팅 시스템은, Android, Linux, Windows 8, 또는 소정의 다른 오퍼레이팅 시스템이 될 수 있다.

클라이언트 장치는, 이들이 항상 존재하고 제거 또는 변경될 수 없는, 하드웨어 내에 구워진(burnt into) 하나 이상의 비밀 값을 갖는다. 보안 부트 처리는, 이들이 팩토리에서 또는 인가된 갱신 프로세스 동안 인스톨되었고 템퍼(temper)되지 않았음에 따라, 부가적인 비밀들, 부트 로더, 오퍼레이팅 시스템 자체 및 그 다양한 컴포넌트와 같은 소정의 컴포넌트의 영구, 비휘발성 스토리지가, 부트 시간에서 입증될 수 있고, 진품인 것으로 나타낼 수 있는 것을 보장하기 위해서, 이들 비밀 값에 의존한다.

장치 및 오퍼레이팅 시스템의 무결성이 입증되면, 애플리케이션(자동적으로 또는 유저에 의해 시작된)은, 장치상에서 이용가능한 및 보안 부트 프로세스 동안 입증된 비밀 값을 사용하는 시스템에 의해 제공된 특별한 애플리케이션 프로그래밍 인터페이스(API)를 사용해서, 클라이언트 장치와 서버 사이에서 신뢰를 수립한다.

디지털 권리 관리(DRM) 시스템의 클라이언트-측면을 구현하는 애플리케이션은, 클라이언트 장치상에서 유저-인스톨 가능한/재생 가능하다. 클라이언트 장치는 보안 부트를 채용하고, 유저-인스톨된 애플리케이션을 입증한다. 애플리케이션은 역설계에 대항해서 강화될 수 있고, 이는 클라이언트 장치에 의해 제공된 특별한 API를 사용해서, 보안 부트 내로 속박되어, 보안 부트와 애플리케이션 내에 포함된 DRM 시스템의 클라이언트-측면 사이의 갭을 브리징한다.

상기 및 다른 목적, 형태 및 장점은, 다른 관점을 통해서 동일 부분에 대해서 동일한 참조부호로 언급하는 첨부 관점에 도시된 바와 같이, 본 발명의 특정 실시형태로부터 명백하게 된다.

도 1은 콘텐츠 전달 및 재생을 위해 네트워크된 시스템의 블록도;
도 2는 컴퓨터화된 장치의 하드웨어 체계의 블록도;
도 3은 클라이언트 장치의 소프트웨어/펌웨어 체계의 개략적인 도면;
도 4는 보안 프로세서의 콘텐츠 및 클라이언트 장치 내의 플래시-프로그램가능한(플래시) 메모리의 개략적인 도면;
도 5는 보안 부트 프로세스의 하이-레벨 흐름도;
도 6은 장치 등록 프로세스에 대한 메시지 흐름도;
도 7은 코드 난독화 기술에서의 관계를 나타내는 그래프;
도 8은 코드 난독화 기술을 위한 메시지 흐름도.

도 1은 암호화된 비디오 파일과 같은 보호된 콘텐츠를 기억, 전달 및 플레이하는 네트워크된 시스템의 적절한 컴포넌트의 단순화된 도면이다. 이 단순화된 도면에 있어서, 시스템은 네트워크(14)를 통해 클라이언트 장치(12)에 접속된 세트의 백엔드 서버 또는 "백엔드"(10)를 포함한다. 백엔드(10)는 이하 더 상세히 기술된다. 클라이언트 장치(12)는, 암호화된 콘텐츠 파일의 해독을 포함하는, 일반적으로 재생 능력을 갖는 컴퓨터화된 장치이다. 예들의 클라이언트 장치는, 개인용 컴퓨터, 태블릿 컴퓨터, 스마트폰 등을 포함한다. 암호화된 콘텐츠 파일을 해독하기 위해 사용된 해독 키가 백엔드(10)에 의해 클라이언트 장치(12)에 제공된다. 이하 더 기술된 바와 같은 동작에서, 클라이언트 장치(12)는 자체를 백엔드(10)에 인증하고, 식별된 암호화된 콘텐츠(예를 들어, 특정 비디오)를 플레이하기 위해 그 인가를 수립하는 정보를 제공한다. 백엔드(10)는 하나 이상의 해독 키를 제공함으로써 응답하여, 클라이언트 장치(12)가 비디오를 위한 콘텐츠 파일(들)을 해독할 수 있게 한다. 클라이언트 장치(12)는 암호화된 콘텐츠 파일을 백엔드(10)의 콘텐츠 서버(도시 생략)로부터 획득하고, 파일을 해독 키를 사용해서 해독하며, 그 다음 해독된 콘텐츠를 렌더(플레이)한다.

백엔드(10)는 하나 이상의 서버 컴퓨터를 사용해서 구현될 수 있는데, 이는 동일-위치(예를 들어, 데이터센터 내에서)되거나 또는 다중 위치에 걸쳐서 동일 방식으로 분산될 수 있다. 몇몇 또는 모든 서버는 콘텐츠 전달 네트워크(CDN)의 부분이 될 수 있다. 동작에 있어서, 콘텐츠 발행자로부터의 콘텐츠는 습득될 수 있고, 그 다음 클라이언트 장치(12)에 대한 세그먼트-기반 전달을 위해서 세그먼트된다. 미디어 준비 엔진은 콘텐츠 암호화/해독 키를 백엔드(10)의 디지털 권리 관리(DRM) 서버로부터 획득하고, 이 키를 사용해서 암호화된 형태로 기억 및 나중의 전달을 위해서 콘텐츠를 암호화한다. 백엔드(10)는 DRM-관련된 동작 및 통신을 위한 중심 포인트로서 권리 서버를 채용할 수 있는데, 이 경우 DRM 서버는, 적합한 네트워크 프로토콜을 사용해서 암호화 키를 생성, 기억 및 검색하기 위해서, 더 특별하게 재단될 수 있다.

도 2는 클라이언트 장치(12) 및 백엔드(10)의 서버를 실현하기 위해 사용될 수 있는 것과 같은 컴퓨터화된 장치의 일반화된 묘사이다. 이는, 하나 이상의 데이터 버스(28)에 의해 함께 결합된 하나 이상의 프로세서(20), 메모리(22), 로컬 스토리지(24) 및 입력/출력(I/O) 인터페이스 회로(26)를 포함한다. I/O 인터페이스 회로(26)는 장치를 하나 이상의 외부 네트워크(네트워크(12)와 같은), 부가적인 스토리지 장치 또는 시스템, 및 본 기술에서 일반적으로 공지된 바와 같은 다른 입력/출력 장치에 결합시킨다. 본 명세서에서 기술된 바와 같은 장치의 시스템-레벨 기능성은, 전형적으로 메모리(22) 내에 기억된 및 프로세서(들)(20)에 의해 검색 및 실행된 컴퓨터 프로그램 명령(소프트웨어)을 실행하는 하드웨어에 의해 제공된다. 기능을 수행하는 소프트웨어 컴포넌트의 본 명세서의 소정의 설명은, 소프트웨어 컴포넌트의 명령을 실행할 때, 컴퓨터 또는 컴퓨터화된 장치의 동작에 대한 간단한 참조로서 이해된다. 또한, 도 2에서의 컴포넌트의 수집은 "처리 회로"로서 언급될 수 있고, 주어진 소프트웨어 컴포넌트를 실행하는 것이 기능-특정된 회로로서 볼 수 있을 때, 예를 들어 콘텐츠 플레이어 기능을 구현하는 소프트웨어 컴포넌트를 실행할 때 "플레이어 회로"로서 볼 수 있다. 이하 기술된 바와 같이, 클라이언트 장치(12)는 보안의 목적을 위해서 더 특정된 하드웨어 체계를 포함한다.

하나의 실시형태에 있어서 클라이언트 장치(12)는, 자체를 미디어 전달 및 재생의 DRM 측면을 포함하는 센시티브 애플리케이션에 빌려주는, 특정된 체계를 갖는다. 특히, 클라이언트 장치(110)는 보안 실행 환경과 정상 또는 비-보안 환경 사이의 파티션 회로 및 기능성일 수 있다. 하드웨어 컴포넌트는 비-보안 환경에서의 애플리케이션 프로세서 및 보안 환경에서의 분리 보안 프로세서를 포함한다. 비-보안 환경에서의 오퍼레이팅 소프트웨어는, 오퍼레이팅 시스템(O/S) 및 콘텐츠 플레이어 애플리케이션("앱(app)"으로서 언급)을 포함할 수 있다. 하나의 실시형태에 있어서, 오퍼레이팅 시스템은 모바일 장치용의 Android® 오퍼레이팅 시스템이다. 보안 환경 내의 컴포넌트는, 클라이언트 장치(12)가 콘텐츠를 해독하기 위한 해독 키를 획득할 수 있게 하기 위해서, 백엔드(10)(도 1)와의 신뢰의 루트(root of trust)를 수립하기 위한 책임이 있다. 보안 환경은 보안 커널 및 보안 메모리를 포함한다. 또한, 클라이언트 장치는, 장치(2)를 등록, 미디어 오브젝트의 재생에 대한 권리 오브젝트를 획득, 및 미디어 오브젝트의 해독 및 플레이를 가능하게 하는 다른 기능을 수행하기 위해 백엔드(10)에 요청을 송신하는, 미디어 클라이언트를 포함하다. 미디어 클라이언트는 보안과 비-보안 환경 사이에서 파티션된 분리 보안 및 비-보안 부분을 가질 수 있다.

하나의 실시형태에 있어서, 클라이언트 장치(12)의 보안 환경은, ARM 아키텍처에 따라 실현된 보안 프로세서만 아니라 보안-관련된 사용을 위해 특별하게 재단된 보안 커널 및 보안 메모리를 포함하는, 소위 TrustZone 패밀리의 컴포넌트를 채용할 수 있다. 신뢰의 루트를 수립하는 것은, 장치(12)(예를 들어, 모바일 폰 핸드셋)를 조립하기 위해 사용된 회로 보드 내에 매립된 보안 처리 하드웨어에 의해 제공된 보안 형태에 부분적으로 기반할 수 있다. 칩셋 제조업자는 하드웨어를 제공하고, 장치 제조업자(OEM)는 이하 더 기술된 바와 같은 소정의 펌웨어(코드)를 로드한다.

도 3은 소프트웨어 관점으로부터 클라이언트 장치(12)의 체계를 나타내는데, 또한 보안과 비-보안 환경 사이에서 상기된 파티션하는 것을 반영한다. 이는, 미디어 플레이어(30), 미디어 클라이언트(32), 오퍼레이팅 시스템(OS) 커널(34) 및 보안 펌웨어(36)를 포함한다. 미디어 클라이언트(32)는, 백엔드(10)에 대한 기능적인 접속(38)을 갖는다. 동작에 있어서, 미디어 플레이어(130)는, 디스플레이와 같은 클라이언트 장치(12)의 적합한 설비 상에 비디오와 같은 미디어를 렌더링한다. 또한, 미디어 플레이어(30)는, 본 기술에서 일반적으로 공지된 바와 같이, 유저가 미디어의 선택 및 재생을 제어할 수 있게 하는, 그래픽 유저 인터페이스를 포함한다. 미디어 클라이언트(32)는, 장치 등록, 암호화 키의 전달, 및 네크워크(14)로부터 미디어(콘텐츠)의 다운로드의 전체 제어를 포함하는, 재생(렌더링)을 위해 미디어의 다운로드와 관련된 다양한 기능을 수행한다.

도 4는 보안 프로세서(40) 및 비휘발성 플래시-프로그램가능한(플래시) 메모리(42)를 포함하는 클라이언트 장치(12) 내의 소정의 구조 및 데이터 아이템을 나타낸다. 이하 기술된 동작에 있어서, 보안 프로세서(40)는 코드를 실행 및 플래시(42) 내에 기억된 데이터 아이템에 액세스한다. 그런데, 보안 프로세서(40)는 또한 관련된 하부-레벨(하드웨어) 컴포넌트 및 동작을 갖는다. 특히, 프로세서(40)는, 리셋 또는 파워 사이클링에 따라 자동적으로 실행된 작은 프로세서 부트(PROC Boot) 루틴(44)을 기억하는, 리드 온리 메모리(ROM)를 포함한다. 이는, 또한, 루트 퍼블릭 키(PuK) KEY1, BL 루트 키 KEY4, 및 키 파티션(part.) 키 KEY5를 포함하는 소정의 기본적인 데이터 아이템의 영구적인 하드웨어-레벨 스토리지를 위한, 1-시간 프로그램가능한(OTP) 스토리지(46)를 포함한다. OTP 스토리지는, 예를 들어 클라이언트 장치(12)의 제작의 시간에서, 선택적으로 개방된("브라운(blown)") 어레이의 퓨즈를 사용해서 실현될 수 있다.

플래시(42)는 각각의 시그네처(SIG)(50)에 따른 다음의 아이템을 기억한다:

1. 외부 루트 퍼블릭 키(48: Extemal root public key)(KEY2) 및 시그네처(50-1)

2. 빠른 부트 코드(52: Fast boot) 및 시그네처(50-2)

3. 암호화 대칭적 키(54)(KEY3) 및 시그네처(50-3)

4. 부트 인수(56: boot argument) 및 시그네처(50-4)

5. 복구 코드(58:Recovery code) 및 시그네처(50-5)

6. 커널 코드(60: Kernel code) 및 시그네처(50-6)

7. 시스템 코드(62) 및 시그네처(50-7)

도 5는 보안 부트 프로세스를 아웃라인한다.

70에서, 프로세서 부트 코드(44)는 다음의 특정 동작을 사용해서 KEY2의 시그네처(50-1)를 입증한다:

1. 외부 루트 퍼블릭 키(KEY2)의 체크섬의 보안 해시 H2(예를 들어, SHA-256 해시)를 계산.

2. OTP(46) 내의 루트 퍼블릭 키(KEY1)를 판독하고, KEY2의 시그네처(50-1)를 해독하기 위해서 KEY1를 사용하고, H2에 비교.

72에서, 프로세서 부트 코드(44)는 KEY2를 사용해서 빠른 부트 화상(52)의 시그네처(50-2)를 입증한다. 이는, KEY2로 시그네처(50-2)를 해독함으로써 및, 결과를 빠른 부트 화상(52)의 해시를 갖는 계산된 보안과 비교함으로써, 수행된다.

이 스테이지에서, 빠른 부트 화상(52)은 메모리 내에 로드되고, 실행을 시작한다. 후속하는 단계가 보안 프로세서에 의해서만 수행될 수 있는 OTP(46)에 액세스하는 것을 요구하기 때문에, 빠른 부트는 보안 프로세서에 의해 실행된다.

74에서, 암호화된 KEY3(54)는 해독되고, 그 시그네처는 입증된다. 다음의 단계가 사용된다:

a. 우선, 암호화된 KEY3가 OTP(46) 내에 기억된 BL 루트 키 KEY4를 사용해서 해독한다.

b. 다음에, 해독된 KEY3의 AES CBC-MAC 시그네처가 KEY4 및 KEY5로부터 도출된 중간 키를 사용해서 계산한다.

c. KEY3의 기억된 시그네처(50-3)는 키 파티션 키 KEY5를 사용해서 해독한다.

d. 단계 b 및 c의 각각의 출력은 KEY3의 무결성을 입증하기 위해서 비교된다.

76에서, 빠른 부트가 KEY3을 사용해서 플래시(42)의 나머지 파티션을 체크한다:

1. 부트 인수(56)의 시그네처(50-4)를 체크한다.

2. 복구 코드(58)의 시그네처(50-5)를 체크한다.

3. 커널(60)의 시그네처(50-6)를 체크한다.

4. 시스템 코드(62)의 시그네처(50-7)를 체크한다.

상기 보안 부트 프로세스 후, 제어는 커널(60)을 통과한다.

하나의 실시형태에 있어서, 키 KEY1 및 KEY2는 2048 비트 길이다. 이들은, 이 특허의 양수인과 같은 DRM 인프라구조의 특정 제공자에 의해 제공될 수 있다. 스마트폰과 같은 그렇지 않은 통상적인 클라이언트 장치(12)는, 양수인으로부터의 것을 포함하는 특정된 인증 인가들로부터의 인가를 사용해서, 사인된 앱의 실행을 허용만 하도록 수정되는 것이 필요할 수 있다.

도 6은 다음과 같이 후속하는 장치 등록 처리를 도시한다:

1. 미디어 클라이언트(32)는 특별한 커널 콜을 사용해서 장치 일련 번호(S)들을 요청 및 획득한다. 하나의 실시형태에 있어서 일련 번호 S는 연쇄의 manufacturer_id(4 bytes) + device_model(4 bytes) + batch_no(8 bytes) + serial_no(8 bytes)로서 형성된다.

2. 미디어 클라이언트(32)는 다음을 포함하는 인증 요청을 백엔드(10)까지 송신한다: S + App_Id(4 bytes) + Android_Time_Stamp(14 bytes) + random_nonce_l(16 bytes).

3. 백엔드(10)는 외부 루트 퍼블릭 키(KEY2)에 대응하는 2048-비트 개인 키를 사용해서 수신된 정보를 암호화한다

4. 암호화된 메시지가 백엔드(10)에 의해 장치(12)로 송신된다.

5. 미디어 클라이언트(32)는 커널(34)로부터 KEY2를 요청한다.

6. 미디어 클라이언트(32)는 백엔드(10)로부터의 메시지를 해독하고, 시간 스탬프, 난스(nonce) 등을 입증하기 위해서 KEY2을 사용한다.

7. 미디어 클라이언트(32)는 커널(34)로부터 장치 등록 메시지를 요청한다.

8. 커널(34)은 보안 펌웨어(36)에 요청해서, 하나의 실시형태에 있어서 KEY2로 암호화된 (장치 아이디 토큰 + '#' + Android_Time_stamp + '#' + random_nonce_l)을 포함하는 장치 등록 메시지를 생성하는데, 여기서 장치 아이디 토큰(device id token)은 S + ChipID(4 bytes) + IN(24 bytes)의 보안 해시이고, IN는 chipset_manufacturer_id(4 bytes) + batch_no(8 bytes) + serial_no(12 bytes)인 개별화된 수이다)

9. 장치 등록 메시지는 백엔드(10)에 송신된다.

10. 백엔드(10)는 KEY2에 대응하는 개인 키로 메시지를 해독하고, 타임스탬프 및 난스를 입증하며, 장치 등록을 위한 장치 식별로서 장치 아이디 토큰을 사용한다.

11. 백엔드(10)는 장치 등록의 결과를 미디어 클라이언트(32)로 리턴시킨다.

앱 인증을 위한 강건한 난독화

도 7 및 8은, 복제하기 어려운 방식으로 코드의 난독화에 기반한, 미디어 클라이언트(32)와 같은 센시티브 애플리케이션의 인증의 기술을 묘사하기 위해 사용된다.

앱 인증은 2-웨이 인증된 보안 채널을 수립하기 위해 사용된 개인 키를 해독하기 위해서 화이트-박스 해독기의 결합에 의해 달성된다. 입증할 수 있게-확고한 난독기가 역설계에 대항해서 및 확장 템퍼-저항(extension tamper-resistance)에 의해 사용된다. 난독기는, 플래트닝된 제어 흐름에서 도달가능한 문제점으로 감소될 수 있는 NP-완료인 3SAT와 같은, 공지된 확고한 문제점과 결합해서 제어-흐름 플래트닝(flattening)을 사용한다. 즉, 제어 흐름을 아는 것은 공지된 확고한 문제점을 해결하는 것과 동등하다.

난독화 과정(코드 개발 시간에서 수행)

라이센스 키 검색 및 미디어 재생에 포함된 미디어의 클라이언트 코드(32)의 부분은 이 과정을 사용해서 난독화되는데, 이 과정은 그 개발 환경에서 코드 개발자에 의해 수행된 다음의 단계를 포함한다.

단계 1 : 불투명한 술어(predicates)의 패밀리를 선택한다. 이들은 이하 단계 5에서 나타낸 바와 같이 조건문 코드를 생성하기 위해 사용된다. 이러한 조건들은, 리니어 코드를 취하고 큰 브랜칭 구조를 생성하는, 이하 기술되는 코드 플래트닝 과정에서 사용된다. 이용가능한 패밀리들은:

RPR(Root of Rrime Residue):

이는 다음과 같이 규정된다 -

소정의 프레임 P=4X+3, 및 소정의 < P, 술어 생성 템플릿은 "｛(A^(X+1))²-A)｝%P" 여기서 %는 mod 동작을 가리킨다. 이는, 모두 0 또는 FALSE로 평가하는 A 및 X를 변화시킴으로써 술어의 패밀리를 생성한다.

유사하게, P=8X+5일 때, 대응하는 템플릿은 ｛((4*A)^(X+1)/2)²-A)｝%P"이다.

일반적으로, 이들 술어는 "L-R" 형태를 갖는데, 여기서 L은 ((4*A)^(X+1)/2)²이고 R은 A이다. 우리는 동일한 프레임 잔여로 이 패밀리의 2개의 인스턴스를 랜덤하게 뽑고, 2개의 좌측 파트를 L-L'으로서 사용하는데, 여기서 L'은 다른 A' 및 P'를 갖는 패밀리로부터이고, 여기서 A%P =A'%P'이다. L-L'이 0으로 평가하는 것이 명확하다.

또한, 술어는 표현에서 혼합될 수 있는데, 여기서 A%P는 넌-제로 표현을 획득하기 위해서 A'%P'와 동일하지 않게 된다. 넌-제로 표현을 얻기 위한 다른 방식은, 다음에 나타낸 바와 같이, 항상 참이 아닌 식별자를 사용하기 위한 것이다.

SQP (Simple Quadratic Polynomial):

이는 다음과 같이 규정된다 -

"7*Y²-1-X²"는 소정의 정수 X 및 Y에 대해서 결코 0이 아니다.

여기서, 이 술어는 넌-제로 표현인 L-R로서 사용된다. 이 타입의 술어는 도입하는 조건에 대해서 사용된다.

단계 2: 다음에, 난독화 변수의 수집이 생성되고, 그 다음 그래프 구조의 인스턴스를 구축하기 위해 사용된 후, 이하 단계 3에서 기술된 바와 같이 코드 난독화 내에 매립된다. 이러한 그래프 구조의 개략적인 예들을 도 7에 나타내었다. 예를 들어, 1024와 같은 몇몇 선택된 수의 변수가 될 수 있다. 이들은, CTR DRBG의 암호 특성을 갖는 코인 토스 선택을 사용해서 2개의 그룹 G_1 및 G_2로 임으로 분할된다. 선택은 생성된 수의 패리티(parity)에 기반하며; 기수의 것만을 G_1로 취한다. G_1 또는 G_2의 멤버쉽은 프로그래머에게 결코 드러나지 않고 공지되지 않는다. 어느 세트 내에서 멤버쉽을 선언하는 코드 내에 스테이트먼트(statement)가 없고; 프로그래머는, 이하 기술된 바와 같이 k 절로 이루어지는 3SAT 문제점, 3SATm의 인스턴스를 구축하기 위해 멤버쉽을 사용하는 것에 주목하자.

3SATm =(a∨s₁∨t₁)∧(￢t₁∨S₂∨t₂)∧(￢t₂∨s₃∨t₃)...(￢t_k-1∨s_k∨￢a)

여기서 k > 3은 이하의 증명에 대해서 필요하게 된다.

여기서 k는 세트 G_1의 사이즈이고, 각각의 s_i는 세트 G_1로부터이고, 참(TRUE)으로 설정된다. 나머지 a 및 t₁ 내지 t_k-1은 실행시 계산된 랜덤 불리언(Boolean) 값으로 설정된다.

변수의 실재 설정은, 이하 나타낸 바와 같이 불투명한 술어를 사용해서 숨겨진다.

예를 들어, 설정 S_i=TRUE 대신, RPR를 사용해서 다음과 같이 행한다 -

설정 S_i = 1-(｛((4*A_i)^(x+1)/2)²-A_i｝%P_i) 여기서 몇몇 A_i&P_i에 대해서 A_i< P_i.

나머지 리터럴(literal) tj는 동일한 생성하는 템플릿을 사용하지만 상기와 같은 코인 토스 과정을 사용하는 Pj보다 작은 또는 큰 Aj를 선택해서 랜덤 값으로 설정된다.

리터럴의 계산은 소프트웨어 개발자에 의해 코드를 통해서 분산된다. 설정의 분배는, 코드 난독화에 대해서 중요한 것으로 고려되는 넌-로컬리티(non-locality)의 성질을 달성하기 위해서 수행된다.

다음에, 그래프 G는 3SATm의 리터럴을 사용해서 계산된다. 꼭지점은 k+1 컬러로 컬러링될 수 있어서, 3SATm이 만족할 수 있을 때만, 그 엔드상에서 동일한 컬러를 갖는 에지가 없게 된다. 그러면, TRUE에 대한 s_i의 설정이 3SATm을 만족하므로, 우리는 그래프가 (k+1)-컬러러블(colorable)인 것을 알게 된다. 이 지식은 개발자에만 공지되므로, 그래프 내의 램덤 에지의 엔드의 컬러를 체크하기 위해 사용될 수 있어, 컬러링의 상태를 결정하고, 그 다음 코드 세그먼트를 보호하기 위해 사용된다.

그래프 G는 다음과 같이 구축된다:

· 각각의 리터럴 t_i, ￢t_i, S_j, a 및 ￢a는 그래프 G 내의 노드이다.

· 각각의 절 C_i는 컬러링된 i 및 C_i 내에 있지 않은 리터럴에 접속된 노드이다.

· 각각의 노드 s_i는 컬러링된 i이고 모든 다른 s 노드 및 모든 리터럴 t_j 및 ￢t_i에 접속되며, 여기서 j￢= i이다.

각각의 노드 t_i 및 ￢t_i는 에지에 의해 접속된다. 각각의 노드 t_i는 컬러링된 i이고, 노드 ￢t_i는 컬러링된 k+1이다. 유사하게, 노드 a 및 ￢a는 에지에 의해 접속되고, 각각 컬러링된 1 및 k+1이다. 우리는 t_i 및 s_i를 "TRUE" 노드로서 언급하게 될 것이다. 프로그램의 실행 동안, t_i 및 ￢t_i의 값은 랜덤하게 변화되고, 값이 TRUE 또는 FALSE인지에 의존해서, 대응하는 컬러링은 i로부터 (k+1)로 변경는 것에 주목하자. [주목: 우리는 k+1 컬러를 FALSE 컬러로 언급하게 될 것이다.]

부명제: 그래프 G는 (k+1)-컬러러블.

증명:

각각의 절 C_i는 최대 3 리터럴을 갖고, 적어도 4 절(clause)이 있으며, 각각의 절은 적어도 하나의 j에 대해서 t_j 및 ￢t_j 모두에 접속되어야 한다. 따라서, 절은 k+1 컬러로 컬러링될 수 없다.

따라서, 컬러가 i인 각각의 C_i 내에 TRUE 노드가 있으면, 그래프 G는 (k+1)-컬러러블이다. 우리는 s_i가 항상 TRUE인 것을 알므로, 그래프 G는 (k+1)-컬러러블이다. [각각의 절이 1로부터 k로의 컬러 중 하나의, 즉 TRUE 노드 중 하나의 컬러 중 하나로 컬러되어야 하는 것에 주목하자.]

단계 3: 다음에, 비난독화된 코드의 다양한 부분이 처리를 위해 마크 오프(marked off)된다. 이는 코드 생성 동안 수동으로 수행된다. 이들 부분은, 다음에 기술된 바와 같이 코드 플래트닝을 위해 나중에 판독되는, 특별한 커멘트 인디케이터를 사용해서 태그된다. 코드 플래트닝의 처리는, 정확한 제어 흐름을 복구하는 처리가 그래프 컬러링의 일반적인 인스턴스 - NP-완료 문제점을 해결하는 것과 동등하게 되도록, 매립된 인스턴스에 대한 질문과 함께 브랜칭 코드를 도입하기 위한 것임에 주목하자. 인스턴스는 상기 단계 2에서 기술된 리터럴을 사용해서 구축된다. 부가적으로, 상기된 바와 같이, 인스턴스는 랜덤 컬러 할당 및 t 노드의 재연결을 갖고도 k+1 컬러로 컬러러블이다. 즉, 노드는, 도면에 나타낸 바와 같은 대칭 때문에, 그래프 G에서 그룹 2와 3 사이에서 이행할 수 있다. 이 성질은 이하 규정된 몇몇 컬러링-세이프 조작을 사용함으로써 난독화에서 활용된다. -

컬러링-세이프 조작

1. 랜덤 시간에서, 그룹 2 및 3 및 그룹 1 및 C 사이의 노드들을 스와핑 및 따라서 포인터를 조정;

2. 그룹 1, 2, 3, 및 C를 가로질러 및 컬리링에 대해 등정형인 방식으로 1 내에서 포인터를 이동.

주목: 조작은 그래프 내의 특정 노드만을 어드레스해야 하고, 노드 선택을 위한 로직은 코드 생성에서 수행된다. 즉, 그룹 멤버쉽은 코드 내에서 결코 명백하지 않다.

실행에 있어서, 노드는 노드와 그래프 G의 그룹 사이의 랜덤 맵핑을 갖는 어레이로 할당된다. 코드 난독화 생성기 프로그램만이 3-SAT 인스턴스에 관해서 안다. 난독화된 프로그램만이 (k+1)-컬러 인스턴스 그래프 G를 갖는다. 즉, G에 대한 솔루션의 유효성은 개발자에만 공지되고, 모니터에 결코 드러나지 않는다.

단계 4: 코드 플래트닝(code flattening)은 스테이트먼트의 리니어 시퀀스를 브랜치된 형태로 변형함으로써 달성된다. 따라서, 시퀀스

X1; X2; X3; ...; Xn으로 시작하면,

주목: 데드 코드는, 다음과 같이 SQP로부터와 같은 불투명한 술어를 사용해서 세그먼트의 길이를 증기시키기 위해서 도입되는데:

"(L-R) == 0이면, 생성하는 템플릿을 사용해서 초기에 기술된 바와 같이 소정의 리터럴을 랜덤 값으로 설정한다.".

다음의 구조를 얻는다 -

조건문 할당 S = ｛Li, Lj, ...｝((color(t_a) == color(not t_a))(color(t_m) color(s n)) ...))

/** 이는 (color(t_a) == color(not t_a))이면, S = Li;

(color(t_m) == color(t_n))이면, S = Lj; 등을 의미한다

이들 중 하나가 정확한 값의 S **/를 이끌게 된다

L: 스위치(S)

｛

케이스 1 : 불투명한 술어에 의해 보호된(

X1;

조건문 할당을 통해서 새로운 S를 계산; GoTo L;

케이스 2: 불투명한 술어에 의해 보호된(

X2;

조건문 할당을 통해서 새로운 S를 계산;

GoTo L;

등.

｝

예들: 다음의 코드를 난독화한다:

Func _123(a, b, c):

이는 다음과 같이 확장된다 -

X1 : (Ll-Rl)이면,

｛

Func_123(a, c, b) /** Xn 하에서 정확한 것으로부터 몇몇은 닮았지만 약간 다르다 **/

s-k를 1-L2-R2로 설정

｝

X2: (L2-R2)이면,

｛

Func_123(a, b, b)

s_m을 L5-R5로 설정

｝

...등...

Xn (Ln==Rn)이면, /** n이 3의 배수인 곳, 즉 n = 3k **/

｛

Func_123(a,b,c); /** 오리지널 코드 **/

s_x를 Lm-Rm로 설정

｝

이는 다음의 구조로 플래트닝된다.

/** n 실행 단계를 m <= n 시퀀스들로 분할. **/

/** N 라벨의 세트 C를 랜덤하게 선택 및 이들 라벨의 순열, P=P1 ..Pm을 선택 **/

/** 이제, 플래트닝된 구조 내의 "실행"의 순서로서 랜덤 순열 R(embedding P)을 뽑는다 **/

/** 구조를 통한 각각의 시간에서, m 시퀀스 중 하나만이 실행된다 **/ 시작하는 라벨 S = 조건문 할당 ｛004, 120, ... ｝(컬러 tl == 컬러 t5, 컬러 C50 != 컬러 t50, ...)으로 설정

/** 이는 S를 120으로 설정하지만, 정적인 다음을 분석은 결정할 수 없다 **/

L: 스위치(S)｛

케이스 0 :

｛

/** 다음 S 값에 조건문 할당이 뒤따르는 세그먼트 **/

｝

*** 등. *****

케이스 1 :

｛

/** 이는, S 값이 거짓이었으면 액션; 이 경우, 이것은 디코이(decoy) **/

X5' /** 몇몇이 시퀀스 X5를 닮게 하는 **/

몇몇 노드 t_i를 뽑고, 이들을 랜덤하게 변화시키며, 포인터를 조정

S의 조건문 할당

Go to L

｝

*** 등. *****

케이스 P1 : /** clause_num(Pl)에 대한 정확한 케이스 **/

｛

X1 /** 이것이 이 컬러에 대한 정확한 시퀀스이면 **/

S의 조건문 할당

Go to L

｝

*** N 케이스까지 커버하기 위해서 등 **

｝

예에서 나타낸 바와 같이, N 라벨의 특정 순열이 선택된다. 순열 내에서 제1라벨로 시작하면, 그 케이스 바디로 스위치하게 위해서 사용된 스위치 변수의 정확한 설정에 대응하기 위해서 값이 계산되는데, 그 스위치 바디는 치환에 있어서 다음 엘리먼트의 정확한 설정의 값을 생성하는 코드를 계산하는 등으로 된다. 이 변수의 설정은, 3SATm 인스턴스에 의해 맵핑된 그래프의 노드의 컬러 설정에 대해서 테스트하는 조건문 코드로 보호된다. 컬러링 문제점에 대한 솔루션의 설정의 지식만이, 브로트 포스 서치(brute-force-search)에 의지하지 않고, 케이스의 정확한 선택을 하게 한다.

따라서, 실행될 다음 어드레스(케이스의 라벨)의 값만이 케이스 스테이트먼트의 내측에서 계산에 의해서 공지된다. 더욱이, 각각의 이들 케이스는, 다음에 기술된 바와 같이 다른 보호된 스테이트먼트 내측의 다음 라벨의 값을 계산한다. 각각의 고 어라운드(go around) 상에서 우리는 다음 케이스 라벨을 설정하고, 바른 결합에 대해서만 각각의 k 컬러에 대한 정확한 설정을 개런티할 N 케이스가 있다. 라벨의 잘못된 설정에 대해서, 케이스 스테이트먼트는 다음 반복에 대해서 S의 잘못된 값을 계산할 것이다. 또한, 라벨의 값을 통해서 하나만의 정확한 순회(traversal)가 있고, 우리는 나중에 정확한 순회가 컬러링 문제점 및 차례로 3SAT 문제점의 솔루션의 지식의 증거인 것을 증명하게 될 것이다. 즉, NP-확고한 다른 방식만이 랜덤 추측한다.

단계 5: 불투명한 술어(X)로 보호하는 것은, 다음의 구조를 사용함으로써 달성된다.

(A-B = 0)이면,

｛

난독화되는 코드

｝그렇지 않으면

｛

이것을 부정확하게 만드는 작은 변수로 정확한 코드와 같은 코드를 디코이한다.

｝

대안적인 형태는,

(A-B+C = 0)이면, /** 여기서 C는 G1으로부터의 리터럴 중 하나 **/

｛

난독화되는 코드

｝

그렇지 않으면

｛

｝

인증 프로토콜

인증 프로토콜은 도 8에 아웃라인되고 다음과 같이 기술된다:

1. 개발자는 다음을 포함하는 코드를 생성:

a. 2048-비트 퍼블릭 키(PUB)(2048 비트 길이 및 128-비트 AES 키(WB-AES-Key-2)로 암호화된 /dev/random을 사용해서 개발 서버상에 생성된)만 아니라

b. 화이트-박스 해독기(그 키는 WB-AES-Key-2)

[주목: 퍼블릭 키를 암호화하기 위한 이유는 이하 설명된 바와 같이 그 진본성을 보장하기 위해서이다.]

2. [다음은 Android® 플랫폼에 대한 특정들을 가질 수 있다] APP에 특정된, 2048 비트 길이 개인 서명의 키(APP PRK)가 개발 서버의 보안 기준들을 매칭시키는 보안 서버상에서 /dev/random을 사용해서 생성된다. 대응하는 퍼블릭 키(APP PUB)는, APP_PRK로 사인된(즉, 자체-사인된) X.509 인증(APP CERT)을 생성하기 위해 사용된다. 이 인증은 전송을 보안하기 위해서 PGP를 사용하는 이메일을 통해서 개발자에 안전하게 반송된다. APP_CERT는 WB-AES-Key-2로 암호화되고, AMC 내에 기억된다.

3. 상기된 바와 같이 앱은 난독화되고, 다음 단계에서 가리키는 바와 같이 앱스토어를 통해서 분배를 준비된다.

4. [또한 안드로이드] 콘텐츠 제공자(또는 콘텐츠 제공자 대신 앱 개발자)는 그 또는 그녀의 구글 플레이 안드로이드 개발자 콘솔(Google Play Android Developer Console) 어카운드를 사용해서 사인된 앱을 제출한다. 사인된 인증은 제출자의 id를 인증한다. 콘텐츠 제공자/앱 개발자는 "키툴" 유틸리티를 사용해서 APP_CERT를 "키스토어" 내에 기억해야 한다. 최종적으로, 앱은, 키스토어 및 키 얼라이어스(key alias)를 입력하고 APP_CERT를 앱 포장 내에 삽입함에 따라 "jarsigner" 유틸리티를 사용하는 구글 플레이 앱스토어를 통한 분배를 위해 APP_CERT로 포장된다.

5. [또한 안드로이드] 유저는, 그의 장치상에서 앱을 다운로드, 인스톨 및 시작한다. 설치의 시간에서, 안드로이드 OS는 앱에 첨부된 인증의 유효성을 체크한다. 이는 설치 프로세스의 부분으로서 수행된다. 부가적으로, 우리는 다음에 기술된 바와 같이 인증의 진본성의 입증을 수행한다.

6. 앱의 각각의 시작에 대해서, 앱에 첨부된 인증은 입증되어야 한다. 앱("클라이언트"로 공지된 바와 같이)의 인스턴스는 AMC 내에 기억된 암호화된 APP_CERT를 해독하기 위해서 화이트-박스 해독기를 시작 및 사용한다. 이 해독된 스트링으로부터, 클라이언트는 다음과 같이 앱의 시그네처를 인증하기 위해서 APP_PUB*(유리가 신뢰하는)를 사용한다.

이하 나타낸 바와 같이, 앱에 첨부된 인증은 packageInfo api를 통해서 시그네처를 획득함으로써 유효화된다. 우선, 인증 내의 퍼블릭 키는 APP_PUB*와 비교되고, 이것이 매칭되면 우리는 시그네처를 입증하기 위해서 진행한다. 인증에 첨부된 시그네처는 APP_PUB*을 사용해서 해독되어, 인증의 체크섬의 암호그래픽 해시를 획득하는데, 이는 그 다음 직접적으로 입증될 수 있다. 이 시그네처가 인증되면, 클라이언트는 백엔드로 상호-인증된 SSL-세션을 셋업하기 위해서 진행한다. 이 단계는 앱의 각각의 시작과 함께 수행된다.

[또한 안드로이드] packageInfo.signatures api는 앱 시그네처로부터 퍼블릭 키를 얻도록 사용될 수 있다. 이는, 개발자의 id를 인증만하기 위해서 사용되고, APP_PUB*의 신뢰 값에 대항해서 비교될 수 있다.

public void onCreate(Bundle savedInstanceState)｛

super.onCreate(savedInstanceState);

PackageManager pm = this.getPackageManager();

String packageName = this.getPackageName();

int field = PackageManager.GET_SIGNATURES;

PackageInfo packageInfo = pm.getPackageInfo(packageName, field);

Signature[] signatures = packageInfo.signatures;

// 및 여기서 우리는 DER 인코딩된 X.509 인증을 갖는다

byte[] certificate = signatures[O].toByteArray();

｝

7. 클라이언트는, 엔트로피를 위한 /dev/random을 사용해서 개발 서버상에서 생성된 2048 비트 키로 개발자에 의해 사인된 X.509 인증(CLIENT_CERT)을 사용한다. CLIENT_CERT는 앱 내에 매립된다. 2-웨이 인증된 보안 채널의 수립은 AES-128 화이트-박스 해독기를 사용해서 달성되어, 개인 SSL 키(SSL)를 해독하고, 이를 사용하여 보안 채널을 수립한다. SSL은 2048 비트 길이이고 엔트로피를 위한 /dev/random을 사용해서 개발 서버상에 생성된다. SSL는 화이트박스 키 WB-AES-KEY2("장치 등록"으로 불리는 섹션 하에서 문서에서 초기에 기술된 것과 동일한)로 기억되고 암호화되고(암호화는 개인 키 SSL의 기밀성를 보호하기 위해서 필수적이다), AES 암호화 및 강건한 난독화의 세기가 주어진 보안으로 간주된다. 서버는 그 자체의 인증을 클라이언트로 인증하기 위해서 사용한다.

8. 백엔드는 SSL을 통한 상호 인증에 의해 클라이언트를 인증한다.

9. 다음에, 클라이언트는 상기된 바와 같이 장치 등록을 행한다. 통지가 푸시되거나 또는 난스가 푸시될 필요는 없다.

10. 그 다음, 백엔드는, WB-AES-Key-2로 암호화된 콘텐츠 키를 센드 다운(send down)한다.

11. 키는 정적인 메모리 내에서만 해독되고, 암호화되지 않은 디스크상에 결코 기억되지 않는다. 더욱이, 키는 콘텐츠 해독에 대해서만 해독되고, 이하 기술된 바와 같이 강건한 및 안전한 비트-패턴으로 오버라이트함으로써 메모리는 안전하게 지워진다.

12. WB_AES-Key-2 및 APP_PUB은 강제된 앱 갱신으로 재개(renew)된다.

다른 방안

해독된 세션-키를 포함하는 버퍼는 사용 후 강건한 및 안전한 비트-패턴으로 오버라이트된다. 우리는, 힙 메모리를 사용하지 않고 로컬 버퍼만(즉, 스택 변수 내의)을 사용해야 하고, 제어가 루틴을 벗어나 통과할 때 이들은 안전하게 지워져야 한다. 다양한 비트-패턴(0xF6, 0x00, OxFF, 랜덤, 0x00, OxFF, 랜덤)은 버퍼 내로 시퀀스로 기입된다. 암호화되지 않은 키는 디스크에 결코 기입되지 않는다.

그래프-컬러링에 대한 실행 디스커버리의 등가:

기술은 다음의 2개의 주장에 의해 부분적으로 특성이 부여된다:

1. 스테이트먼트 X1..Xn을 실행하는 정확한 시퀀스는, G의 컬러링에 기반한 조건문들(보호에서 사용됨)에 대한 정확한 대답의 지식을 의미한다.

2. 플래트닝된 구조를 통한 실행을 통해서 만나는 G의 컬러링에 관한 조건문들에 대한 정확한 세트의 대답은 정확한 실행 시퀀스 X1..Xn으로 귀결된다.

제1주장은, 난독화의 구축으로부터 뒤따른다. 즉, 정확한 실행 시퀀스 X1..Xm는 그래프-컬러링 문제점의 인스턴스 G에 대한 솔루션의 선험적인 지식을 나타낸다. 이는, 그래프의 구조 및 컬러링이 조사에 의한 시간에 앞서 공지되지 않기 때문는다. 이는, 시퀀스 X1..Xn 내측에 포함하는 코드의 다른 부분에서 변한다. 솔루션의 선험적인 지식 없이, 어떻게 일반적인 컬러링 문제점을 해결하는지를 알아야 하는데, 이는 계산적으로 어렵다.

제2주장에 대해서, 이는, 조건문들의 정확한 설정에 묶인 소정의 실행 시퀀스가 실행의 정확한 순서를 계산해야하는 것을 보이는데 충분하다. 이는, 그래프-컬러링 문제점에 대한 등가의 실행 디스커버리를 수립하게 되는데, 여기서 후자의 솔루션은 NP-완료되는 것으로 공지된다.

토대: E=1. 이 시퀀스에 대해서 하나의 순서만이 있기 때문에, 명제는 평범하게 TRUE이다.

귀납 가설(I.H.): 명제가 몇몇 E=m에 대해서 TRUE인 것을 추정하는데, 여기서 m>1, 즉 G의 그래프 컬러링에 관한 조건물들에 정확히 대답하는 소정의 실행 시퀀스는 또한 X1..Xn의 정확한 실행이다.

그러면, 이는, 명제가 E=m+1에 대해서 유지하는 것을 나타낸다. 그 실행 시퀀스 Y가 길이 m+1을 갖는 문제점의 인스턴스를 고려하자.

시퀀스 Y의 소정의 엘리먼트의 구조는 다음과 같이 -

A1 A2 A3 A4 A5 (1)

여기서

1. A1 및 A3은 거짓 불투명한 술어들에 의해 보호된 디코이 코드의 하나 이상의 인스턴스;

2. A2는 실행될 필요가 있는 실재 코드;

3. A4는 스위치 스테이트먼트의 다음 값 S의 조건문 할당; 및

4. A5는 GoTo

Y의 마지막 2개의 엘리먼트를 y' 및 y"로 하자. 이제, 우리는, 이전의 실행 시퀀스 Y의 실행 그래프에 등정형인, 즉 X1..Xn의 정확한 실행 시퀀스인, 길이 m의 실행을 생성하기 위해 이들 엘리먼트를 결합하기 위한 방법을 발견한다.

우리는 다음과 같이 이러한 결합을 규정한다:

A1' A1" A2' A2" A3' A3" Combined(A4', A4") A5" (2)

여기서 y' 및 y" 각각에 속하는 A 컴포넌트는 프레임 노션(prime notation)으로 가리켜진다.

Combined(U, V)는 U 및 V에서의 개별적인 조건들 및 대응하는 할당 스테이트먼트의 조건들의 애그리게이션으로부터 규결하는 조건문 할당이다. 명백하게, 상기 (2)에서의 결합은 (1)의 동일한 구조를 갖는다. 결과적으로, 이는 길이의 실행 시퀀스로 귀결하는 엘리먼트 y' 및 y"를 교체할 수 있다.

I.H.로부터, 우리는, 그 조건문들이 G의 컬러링을 정확히 만족하는 소정의 이러한 실행 시퀀스(길이 m의)가, X1..Xn의 정확한 실행인 것을 안다. 또한, 우리는, 이러한 시퀀스의 조건문들이 Y의 대응하는 실행으로 맵핑하며, 여기서 조건문들이 단계 y' 및 y"에 걸쳐서 분할하는 것을 안다. 우리는, 이 실행 시퀀스가 또한 정확한 것을 나타낼 필요만 있다.

특히, 우리는, 결합된 시퀀스가 정확했던 것을 안다. 그러므로, 우리는, 이제, 어떻게 Y의 오리지널 시퀀스 내로의 분해가 실행의 정확도를 유지하게 되는가를 보일 필요가 있다. y"가 널(null)인 경우를 제외하고, 우리는, 컬러링에 관한 질문을 만족하는 y" 내의 조건문들이 있으면, 이들은 구축에 의한 실행의 정확한 단계를 포함해야하는 것을 관찰한다. y' 및 y"의 다른 컴포넌트가 컬러링-세이프, 즉 이들이 조건물 내의 컬러-관련된 질문의 결과를 변경하지 않는 것에 주목하자.

도 8은 다음의 동작을 포함하는, 상기된 기술을 도시한다:

1. 2048-비트 키 쌍(APP_PUB, APP_PRK) 생성; APP_CERT 생성;

2. X=WB-AES-Key-2를 갖는 Encrypt(PUB); Y= WB-AES-Key-2를 위한 화이트박스 해독기; 앱 내에 매립된 X & Y; 3-SAT 인스턴스을 사용해서 앱을 난독화;

3. 난독화된 앱을 송신

4. APP_CERT으로 앱을 서명 및 앱스토어에 제출

5. 다운로드; 인스톨; 앱 시작

6. 시작할 때 AMC는 Y를 사용해서 X를 해독하여, APP_PUB*을 얻는다; APP_PUB*를 사용해서 앱 시그네처를 유효화; Y를 사용해서 SSL을 해독

7. 백엔드로 상호 인증된 SSL 세션을 생성. 독특한 id를 갖는 장치 등록 요청을 송신.

8. 플레이 요청시, 콘텐츠 키를 위한 백엔드를 요구

9. WB-AES-Key-2로 암호화된 콘텐츠 키를 센드 다운

도 8에서, 아이템 7-9에 대한 점선은 2048 비트 키를 갖는 SSL 세션을 가리킨다.

요약하면, 다음은 본 개시된 방법 및 장치의 중요한 측면이다:

DRM 시스템의 클라이언트-측면을 구현하는 애플리케이션은, 클라이언트 장치 상에서 유저-인스톨가능한/재생가능하다.

클라이언트 장치는 보안 부트를 채용 및 유저-인스톨된 애플리케이션을 입증한다.

애플리케이션은 역설계에 대항해서 강화된다.

애플리케이션은 보안 부트 내에 속박하기 위해서 클라이언트 장치에 의해 제공된 특별한 API를 사용해서, 보안 부트와 애플리케이션 내에 포함된 DRM 시스템의 클라이언트-측면 사이의 갭을 브리징한다.

본 발명의 다양한 실시형태를 특히 나타내고 기술하였지만, 첨부된 청구항에 의해 규정된 바와 같이 본 발명의 정신 및 범위로부터 벗어남이 없이, 형태 및 세부 사항에서의 다양한 변경이 만들어질 수 있는 것으로 이해될 것이다.

Claims

클라이언트 장치상에 유저-인스톨되는 미디어 클라이언트만 아니라 클라이언트 장치에 통신 가능하게 결합된 권리 관리 서버에 클라이언트 장치가 자체의 진본성을 증명하는 방법으로서:
화상이 클라이언트 장치 내에 영구적으로 기억된 것을 확인(confirm)하기 위해 보안 부트 처리에 참가하고, 실행을 위한 펌웨어가 권리 관리 서버에서의 개인 암호화 키 및 화상 내에 보안 기억된 대응하는 퍼블릭 암호화 키를 채용하는 권리 관리 방안에서 사용하기 위해 특히 키 입력(keyed)되는 것을 포함하며, 펌웨어가 퍼블릭 암호화 키를 사용해서 암호화된 장치 등록 메시지를 복귀시킴으로써 미디어 클라이언트로부터의 요청에 응답하기 위해서 구성 및 실행에 따라 동작하고, 보안 부트 처리가, (1) 클라이언트 장치의 1회-프로그램가능한(OTP) 스토리지 내에 보안 기억된 제1입증 키를 사용해서 기억된 퍼블릭 암호화 키의 시그네처를 입증하고, (2) 화상 내에 포함된 암호화된 대칭적 키를 해독하고, OTP 스토리지 내에 보안 기억된 하나 이상의 제2입증 키를 사용해서 해독된 대칭적 키의 시그네처를 입증하며, (3) 해독된 대칭적 키를 사용해서 영구적으로 기억된 화상의 시그네처를 입증하는, 참가 및 포함 단계와;
보안 부트 프로세스의 성공적인 완료에 따라 펌웨어를 로딩 및 실행하는 단계와;
후속하는 동작 동안 펌웨어에 의해 및 미디어 클라이언트로부터의 요청에 응답해서, 암호화된 장치 등록 메시지를 생성하기 위해 영구적으로 기억된 퍼블릭 암호화 키를 사용하고, 장치 인증 프로세스의 부분으로서 권리 관리 서버로 포워딩하기 위해 암호화된 장치 등록 메시지를 미디어 클라이언트에 복귀시키는, 사용 및 복귀 단계를 포함하여 구성되고,
보안 부트 처리는, 프로세서-레벨 부트 및 화상 내에 포함된 펌웨어 부트 루틴을 사용하는 후속하는 펌웨어-레벨 부트를 포함하고, 펌웨어-레벨 부트는 암호화된 대칭적 키의 해독 및 영구적으로 기억된 화상의 시그네처의 입증을 수행하며, 프로세서-레벨 부트에 의해, 펌웨어 부트 루틴의 시그네처를 입증하는 것을 더 포함하고, 시그네처의 성공적인 입증에 따라, 그 다음 펌웨어 부트를 개시하는 것을 특징으로 하는 방법.
삭제
제1항에 있어서,
화상은, 기억된 퍼블릭 암호화 키, 암호화된 대칭적 키, 및 화상의 펌웨어 컴포넌트에 대한 각각의 기억된 시그네처를 기억하고, 주어진 키 또는 펌웨어 컴포넌트에 대한 시그네처를 입증하는 것이, (1) 주어진 키 또는 펌웨어 컴포넌트에 대한 시그네처를 계산, 및 (2) 계산된 시그네처를 기억된 시그네처 중의 각각의 하나와 비교하는 것을 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,
미디어 클라이언트는 디지털 권리 관리(DRM) 시스템의 클라이언트 측면을 구현하고, 클라이언트 장치상에 유저-인스톨된 것을 특징으로 하는 방법.
제4항에 있어서,
클라이언트 장치의 펌웨어는 클라이언트 장치상의 유저-인스톨된 미디어 클라이언트를 입증하는 것을 특징으로 하는 방법.
제4항에 있어서,
미디어 클라이언트는, 보안 부트 내로 속박하기 위해서 클라이언트 장치에 의해 제공된 특별한 API를 사용하여, 보안 부트와 애플리케이션 내에 포함된 DRM 시스템의 클라이언트-측면 사이의 갭을 브리징하는 것을 특징으로 하는 방법.
클라이언트 장치로서:
하나 이상의 프로세서와;
메모리와;
입력/출력 인터페이스 회로와;
이들 사이의 고속 데이터 전달을 위해 프로세서, 메모리 및 입력/출력 회로를 함께 결합하는 하나 이상의 데이터 버스를 포함하여 구성되고,
메모리는, 클라이언트 장치상에 유저-인스톨되는 미디어 클라이언트만 아니라 클라이언트 장치에 통신 가능하게 결합된 권리 관리 서버에 클라이언트 장치가 자체의 진본성을 증명하는 방법을 수행하게 하기 위해, 프로세서에 의해 실행된 컴퓨터 프로그램 명령을 기억하며, 상기 방법은:
화상이 클라이언트 장치 내에 영구적으로 기억된 것을 확인(confirm)하기 위해 보안 부트 처리에 참가하고, 실행을 위한 펌웨어가 권리 관리 서버에서의 개인 암호화 키 및 화상 내에 보안 기억된 대응하는 퍼블릭 암호화 키를 채용하는 권리 관리 방안에서 사용하기 위해 특히 키 입력(keyed)되는 것을 포함하며, 펌웨어가 퍼블릭 암호화 키를 사용해서 암호화된 장치 등록 메시지를 복귀시킴으로써 미디어 클라이언트로부터의 요청에 응답하기 위해서 구성 및 실행에 따라 동작하고, 보안 부트 처리가, (1) 클라이언트 장치의 1회-프로그램가능한(OTP) 스토리지 내에 보안 기억된 제1입증 키를 사용해서 기억된 퍼블릭 암호화 키의 시그네처를 입증하고, (2) 화상 내에 포함된 암호화된 대칭적 키를 해독하고, OTP 스토리지 내에 보안 기억된 하나 이상의 제2입증 키를 사용해서 해독된 대칭적 키의 시그네처를 입증하며, (3) 해독된 대칭적 키를 사용해서 영구적으로 기억된 화상의 시그네처를 입증하는, 참가 및 포함 단계와;
보안 부트 프로세스의 성공적인 완료에 따라 펌웨어를 로딩 및 실행하는 단계와;
후속하는 동작 동안 펌웨어에 의해 및 미디어 클라이언트로부터의 요청에 응답해서, 암호화된 장치 등록 메시지를 생성하기 위해 영구적으로 기억된 퍼블릭 암호화 키를 사용하고, 장치 인증 프로세스의 부분으로서 권리 관리 서버로 포워딩하기 위해 암호화된 장치 등록 메시지를 미디어 클라이언트에 복귀시키는, 사용 및 복귀 단계를 포함하여 구성되고,
보안 부트 처리는, 프로세서-레벨 부트 및 화상 내에 포함된 펌웨어 부트 루틴을 사용하는 후속하는 펌웨어-레벨 부트를 포함하고, 펌웨어-레벨 부트는 암호화된 대칭적 키의 해독 및 영구적으로 기억된 화상의 시그네처의 입증을 수행하며, 프로세서-레벨 부트에 의해, 펌웨어 부트 루틴의 시그네처를 입증하는 것을 더 포함하고, 시그네처의 성공적인 입증에 따라, 그 다음 펌웨어 부트를 개시하는 것을 특징으로 하는 클라이언트 장치.
삭제
제7항에 있어서,
화상은, 기억된 퍼블릭 암호화 키, 암호화된 대칭적 키, 및 화상의 펌웨어 컴포넌트에 대한 각각의 기억된 시그네처를 기억하고, 주어진 키 또는 펌웨어 컴포넌트에 대한 시그네처를 입증하는 것이, (1) 주어진 키 또는 펌웨어 컴포넌트에 대한 시그네처를 계산, 및 (2) 계산된 시그네처를 기억된 시그네처 중의 각각의 하나와 비교하는 것을 포함하는 것을 특징으로 하는 클라이언트 장치.
제7항에 있어서,
미디어 클라이언트는 디지털 권리 관리(DRM) 시스템의 클라이언트 측면을 구현하고, 클라이언트 장치상에 유저-인스톨된 것을 특징으로 하는 클라이언트 장치.
제10항에 있어서,
클라이언트 장치의 펌웨어는 클라이언트 장치상의 유저-인스톨된 미디어 클라이언트를 입증하는 것을 특징으로 하는 클라이언트 장치.
제7항에 있어서,
미디어 클라이언트는, 보안 부트 내로 속박하기 위해서 클라이언트 장치에 의해 제공된 특별한 API를 사용하여, 보안 부트와 애플리케이션 내에 포함된 DRM 시스템의 클라이언트-측면 사이의 갭을 브리징하는 것을 특징으로 하는 클라이언트 장치.