2. 배경
WEB 기반 비디오와 DRM
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에 어려움이 존재
INISOFT Co.,Ltd
3. Market Trends
미디어 콘텐트 보안을 위한 시장의 대응
• 배경
• 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기반으로 규격 제정
INISOFT Co.,Ltd
4. SSL로는 안되는가?
왜 SSL으로는 미디어 보안이 되지 않는가?
• 상호 인증 필요
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를 이용한 보안이 필요
INISOFT Co.,Ltd
5. DRM의 기본 구성요소
미디어 콘텐트 보호의 구성 요소
콘텐트 포맷
MPEG-DASH
• 파일 포맷
로 표준화 중
• 스트리밍 포맷
• 콘텐트 암호화/복호화 규격
Common Interface
안전한 전달 / 배포 권한 기술
• 단말 인증 ( PKI ) • PPV / Subscription
• 메시지 암호화/서명 • 권한 상속
• Device 간 권한 공유
INISOFT Co.,Ltd
7. Definitions
Definitions
1) CDM : Content Decryption Module
2) Key System :
3) Session-ID :
4) Initialization Data :
INISOFT Co.,Ltd
* Diceplayer for android
8. 구동 시나리오
1 ) 초기화
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 초기화 시도.
INISOFT Co.,Ltd
* Diceplayer for android
9. 구동 시나리오
1 ) 초기화 예 – OMA DRM
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>2498sdfcvxs@ri.example.com</roURL>
<roapURL>http://ri.example.com/ro.cgi?tid=g97sd976s90</roapURL>
<protocol>Acquisition</protocol>
<signature>...signature_data...</signature>
</roapTrigger>
INISOFT Co.,Ltd
* Diceplayer for android
10. 구동 시나리오
2 ) CanPlayType()을 통한 Negotiation
iniData를 통하여 사용할 KeySystem을 선택하는 과정
CanPlayType( MimeType , KeySystem )을 통하여 현재의 UA가 재생가능한 KeySystem을 선택
INISOFT Co.,Ltd
* Diceplayer for android
11. 구동 시나리오
3 ) GenerateKeyRequest()를 통한 License 요청
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 DOMString? sessionId;
readonly attribute Uint8Array message;
readonly attribute DOMString? defaultUrl;
};
여기에는 라이선스 서버의 URL과 Post해야할 message가 포함되어 있다.
App은 이를 받아서 HTTP로 라이선스 서버에 POST한다.
INISOFT Co.,Ltd
* Diceplayer for android
12. 구동 시나리오
3 ) GenerateKeyRequest()를 통한 License 요청 예
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"
URL : Contents ID를 포함
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<deviceID>
<keyIdentifier xsi:type="roap:X509SPKIHash"> ROAP Request :
<hash>vXENc+Um/9/NvmYKiHDLaErK0gk=</hash>
</keyIdentifier>
</deviceID> Device 정보 / 서버 정보 /
<riID> Device의 인증서
<keyIdentifier xsi:type="roap:X509SPKIHash"> Replay attack을 막기위한
<hash>aXENc+Um/9/NvmYKiHDLaErK0fk=</hash>
</keyIdentifier> nonce등
</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>
INISOFT Co.,Ltd
* Diceplayer for android
13. 구동 시나리오
4 ) 라이선스 수신 및 AddKey()
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;
readonly attribute DOMString? sessionId;
};
addKey가 수행되고 Key수신을 위해서 라이선스 서버와 계속해서 메시지를 주고 받아야 하는 경우
MediaKeyMessageEvent 발생
서버 URL / 요청할 Message를 App에 전달.
3 / 4 번을 반복 수행하고 최종적으로 Key 수신이 완료되면 MediaKeyCompleteEvent로 완료
INISOFT Co.,Ltd
* Diceplayer for android
14. 구동 시나리오
5) 재생
Media Player와 CDM 모듈간의 내부 연동
미디어 포맷마다 암호화 방식이 달라서 이 부분은 별도의 표준화가 필요한 상황 ( 표준화 없이 개별 Browser
별로 개발될 가능성도 높음 )
Media Player / CDM 모두 OS/HW 의존성이 높은 모듈이고 상호간의 Trust 관계가 필요한 부분이기 때문에
( Studio 인증에서 요구되는 Robustness Rule을 만족시키기 위해서 ) 표준화 없이 개별 플랫폼 , DRM 마다
각기 다른 방식으로 구현될 가능성이 높음
AddKey()
Media
Streaming Demux Decode Render
Player
CDM Decrypt
복호화 KEY
INISOFT Co.,Ltd
