encrypted media extention

INISOFT Co.,Ltd

Encrypted Media Extensions v0.1Draft proposal

INISOFT Co., Ltd.

Taehyun Kim

[email protected]

2012.06.14

mailto:[email protected]

INISOFT Co.,Ltd

HTML5 Video tag를 기반으로하는 Web 비디오

시장은 커져왔으나 해결되지 않는 문제는 컨텐츠 보호가 필요한

Premium 비디오를 제공하는 방법이 없다는 것.

현재는 Flash/Silverlight와 같은 Plug-in이 필요.

Media Play부분과 콘텐트 보호 부분의 분리가 어려움.

Plug-in 포팅 이슈. ( HW GPU가속등 )

Plug-in이 필요한 부분과 표준화가 가능한 부분의 분리가 필요.

• Mobile Smart Device 시장의 확대

• HW Video 가속 등 Plug-in 개발업체가 각 Device마다 대응하기 어려워짐

• Adobe의 Flash plug-in 개발 포기

• 표준을 통하여 HW 가속은 제조사가 Media 보안은 보안 업체가 하는 분리 방안이

필요해진 상황

• Device 별로 지원 가능한 Plug-in이 달라서 서비스 Deploy에 어려움이 존재

배경

WEB 기반 비디오와 DRM

INISOFT Co.,Ltd

• 배경

• HD 영상의 일반화로 Network / Storage 비용 증가

• Codec의 사실상의 통일 : H.264 / AAC

• Simulcrypt for Broadcasting

• 암호화 송출은 단일 규격 + 복수의 CAS를 통한 Key 전달 규격

• Multi DRM + Single Format

• 보안상의 이유와 규제 , 업체들간의 이해관계로 인하여 KEY를 전달하는 방식에 대한표준화는 불가능

• 1개의 파일포맷으로 다수의 DRM을 지원하는 방안이 대두되고 있음

• UltraViolet Common File format : 디즈니를 제외한 주요 스튜디오 및 서비스 , 솔루션 , 단말업체가 모임

• MPEG-DASH Common Encryption : 단일한 암호화 방식을 제공

• 스트리밍 포맷의 단일화

• iOS의 HTTP Live Streaming 으로 촉발된 Adaptive Streaming 포맷의 대중화

• MPEG-DASH로 기존의 모든 HTTP기반 Adaptive Streaming 규격을 단일화 하려는움직임

• OIPF / 3GPP 등 다수의 표준에서 MPEG-DASH기반으로 규격 제정

Market Trends

미디어 콘텐트 보안을 위한 시장의 대응

INISOFT Co.,Ltd

• 상호 인증 필요

Client Side Certificate 필요

DRM은 Client User를 못 믿는 구조. USER가 아닌 System/Device를 Trust하는 구조

• Protocol에 대한 비밀 주의

완벽한 콘텐트 보안은 HW적인 구현 밖에 없음.

SW구현으로는 어느 정도 타협 해야 함.

- Perfect한 protocol보다는 비밀주의를 통한 Reverse engineering 방지

- 코드 난독화 등 Key Hardening technique 사용

Cookie / HTTP 인증만으로는 정상적인 ID/Password를 알고 있는 사용자가 Key를

유출 시키는 것을 방지하기 어려움

별도의 Device key를 이용한 보안이 필요

SSL로는 안되는가?

왜 SSL으로는 미디어 보안이 되지 않는가?

INISOFT Co.,Ltd

DRM의 기본 구성요소

미디어 콘텐트 보호의 구성 요소

콘텐트 포맷

• 파일 포맷

• 스트리밍 포맷

• 콘텐트 암호화/복호화 규격

권한 기술

• PPV / Subscription

• 권한 상속

• Device 간 권한 공유

안전한 전달 / 배포

• 단말 인증 ( PKI )

• 메시지 암호화/서명

MPEG-DASH

로 표준화 중

Common Interface

INISOFT Co.,Ltd

Encrypted Media Ext.

INISOFT Co.,Ltd

1) CDM : Content Decryption Module

2) Key System :

3) Session-ID :

4) Initialization Data :

Definitions

Definitions

* Diceplayer for android

INISOFT Co.,Ltd

Key System을 선택하기 위한 시나리오

미디어 스트림 자체에 CDM을 초기화 하기 위한 Initialization Data를(복수개 가능) 포함한다.

Ex) 라이선스 취득을 위한 라이선스 서버 URL, Contents ID

needKey event : CDM 재생이 필요함을 알림

미디어 스트림에 포함된 Init Data를 Application에 전달.

interface MediaKeyNeededEvent : Event {

readonly attribute DOMString? keySystem;

readonly attribute DOMString? sessionId;

readonly attribute Uint8Array? initData;

};

전달 받은 KeySystem 정보를 이용하여 CDM 초기화 시도.

구동 시나리오

1 ) 초기화


INISOFT Co.,Ltd

OMA DRM에는 다음과 같은 초기화 구동 Data가 필요.

ROAP Trigger

KeySystem : OMA DRM

iniData :

<roapTrigger xmlns="http://www.openmobilealliance.org/xmlns/roaptrigger">

<riID>

<keyIdentifier xsi:type="roap:X509SPKIHash">

<hash>aXENc+Um/9/NvmYKiHDLaErK0fk=</hash>

</keyIdentifier>

</riID>

<roURL>[email protected]</roURL>

<roapURL>http://ri.example.com/ro.cgi?tid=g97sd976s90</roapURL>

<protocol>Acquisition</protocol>

<signature>...signature_data...</signature>

</roapTrigger>

구동 시나리오

1 ) 초기화 예 – OMA DRM


INISOFT Co.,Ltd

iniData를 통하여 사용할 KeySystem을 선택하는 과정

CanPlayType( MimeType , KeySystem )을 통하여 현재의 UA가 재생가능한 KeySystem을 선택

구동 시나리오

2 ) CanPlayType()을 통한 Negotiation


INISOFT Co.,Ltd

NeedKey Event에서 수신된 CDM 초기화 데이터를 CDM모듈에 전달하고 이를

통하여 라이선스 수신 요청 메시지를 생성

void generateKeyRequest(in DOMString keySystem, in Uint8Array? initData);

CDM 모듈은 initData 정보를 기초로 하여 Key Request를 보낼 URL과 Data를 생성한다.

이를 MediaKeyMessage event로 전달한다.

[Constructor(DOMString type, optional MediaKeyMessageEventInit eventInitDict)]

interface MediaKeyMessageEvent : Event {

readonly attribute DOMString keySystem;


readonly attribute Uint8Array message;

readonly attribute DOMString? defaultUrl;

};

여기에는 라이선스 서버의 URL과 Post해야할 message가 포함되어 있다.

App은 이를 받아서 HTTP로 라이선스 서버에 POST한다.

구동 시나리오

3 ) GenerateKeyRequest()를 통한 License 요청


INISOFT Co.,Ltd

The request is for a Device RO.

<?xml version="1.0" encoding="utf-8"?>

<roap:roRequest

xmlns:roap="urn:oma:bac:dldrm:roap-1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<deviceID>


<hash>vXENc+Um/9/NvmYKiHDLaErK0gk=</hash>

</keyIdentifier>

</deviceID>

<riID>


<hash>aXENc+Um/9/NvmYKiHDLaErK0fk=</hash>

</keyIdentifier>

</riID>

<nonce>32efd34de39sdwefqwer</nonce>

<time>2004-03-17T14:20:00Z</time>

<roInfo>

<roID>n8yu98hy0e2109eu09ewf09u</roID>

</roInfo>

<certificateChain>

<certificate>miib123121234567</certificate>

<certificate>miib234124312431</certificate>

</certificateChain>

<signature>321ue3ue3ue10ue2109ue1ueoidwoijdwe309u09ueqijdwqijdwq09uwqwqi009</signature>

</roap:roRequest>

구동 시나리오

3 ) GenerateKeyRequest()를 통한 License 요청 예


URL : Contents ID를 포함

ROAP Request :

Device 정보 / 서버 정보 /

Device의 인증서

Replay attack을 막기위한

nonce등

INISOFT Co.,Ltd

GenerateKeyRequest()의 결과를 라이선스 서버에 전달하면 그 결과가 수신됨

이를 AddKey()로 CDM에 전달하여 Key를 추가.

void addKey(in DOMString keySystem, in Uint8Array key, in Uint8Array? initData, in DOMString?

sessionId);

addKey가 성공적으로 완료(복호화에 필요한 Key를 수신)되면 MediaKeyComplete Event가 발생

[Constructor(DOMString type, optional MediaKeyCompleteEventInit eventInitDict)]

interface MediaKeyCompleteEvent : Event {

readonly attribute DOMString keySystem;


};

addKey가 수행되고 Key수신을 위해서 라이선스 서버와 계속해서 메시지를 주고 받아야 하는 경우

MediaKeyMessageEvent 발생

서버 URL / 요청할 Message를 App에 전달.

3 / 4 번을 반복 수행하고 최종적으로 Key 수신이 완료되면 MediaKeyCompleteEvent로 완료

구동 시나리오

4 ) 라이선스 수신 및 AddKey()


INISOFT Co.,Ltd

CDM

Media

Player

Media Player와 CDM 모듈간의 내부 연동

미디어 포맷마다 암호화 방식이 달라서 이 부분은 별도의 표준화가 필요한 상황 ( 표준화 없이 개별 Browser

별로 개발될 가능성도 높음 )

Media Player / CDM 모두 OS/HW 의존성이 높은 모듈이고 상호간의 Trust 관계가 필요한 부분이기 때문에

( Studio 인증에서 요구되는 Robustness Rule을 만족시키기 위해서 ) 표준화 없이 개별 플랫폼 , DRM 마다

각기 다른 방식으로 구현될 가능성이 높음

구동 시나리오

5) 재생

Streaming Demux

Decrypt

Decode Render

AddKey()

복호화 KEY

INISOFT Co.,Ltd

감사합니다.

encrypted media extention

Technology