T T A  S t a n d a r  d 
 정보통신단체표준                   제정일: 2010 년 3 월 26 일 
TTAK.KO-08.0023                 
 
   
IPTV 용 교환 가능한 CAS (iCAS) 
(IPTV Interchangeable CAS (iCAS)) 
 
 
  
 
 
               정보통신단체표준(국문표준)  제정일 : 2010 년 3 월 26 일  
TTAK.KO-08.0023  
IPTV 용 교환 가능한 CAS (iCAS)  
(IPTV Interchangeable CAS (iCAS)) 
 
           
 
본 문서에 대한 저작권은 TTA 에 있으며, 이 문서의 전체 또는 일부에 대하여 상업적 
이익을 목적으로 하는 무단 복제 및 배포를 금합니다.   
Copyrightⓒ Telecommunications Te chnology Associations(2010). Al l Rights Reserved. 정보통신단체표준 
TTAK.KO-08.0023 i서    문  
 
1. 표준의 목적 
 
IPTV 서비스를 안전하게 제공하고 사용하기 위하여 서비스 및 콘텐츠 보호 기술 
(CAS)이 필요하다. 본 규격에서는 IPTV 수신 단말의 이동성을 보장하기 위하여 이러한 서비스 및 콘텐츠 보호 기술(CAS) 모듈을 안전하게 다운로드 받아 실행 할 수 있는 기술 규격에 대해 정의한다.   2. 주요 내용 요약  
 
본 표준은 IPTV에서 서비스 및 콘텐츠 보호 기술(CAS) 모듈을 네트워크를 통하여 
안전하게 다운로드 받고 관리하기 위하여 필요 요구사항들을 정의하고 이를 만족하기 위한 세부 기술들을 정의한다. 서비스 및 콘텐츠 보호 기술(CAS) 모듈을 안전하게 다운로드 받기 위한 서버와 IPTV 수신 단말과의 프로토콜들을 정의하며, 다운로드 받은 서비스 및 콘텐츠 보호 기술을 안전하게 관리하고 실행시키기 위하여 IPTV 수신 단말에서 필요한 컴포넌트들을 정의한다.   3. 표준 적용 산업 분야 및 산업에 미치는 영향  
 
본 표준은 IPTV에서 서비스 및 콘텐츠 보호 기술(CAS) 모듈을 안전하게 다운로드 
받아 실행하기 위한 표준화된 기술 규격을 제공하여 IPTV 수신 단말의 이동성을 보장함으로써, 국내 IPTV 활성화를 통한 산업발전에 기여할 수 있다.   4. 참조 표준 (권고) 
 
4.1. 국외표준 (권고) 
 [1] ITU-T X.1191, “Secure applications and services – IPTV security  –  F u n c t i o n a l  
requirements and architecture for IPTV security aspects” 
[2] ATIS-0800001, “IPTV DRM Interope rability Requirements,” April, 2006 
  정보통신단체표준 
TTAK.KO-08.0023 ii4.2. 국내표준  
 [1] TTAE.IT-Y1901, “IPTV 서비스 요구사항 2.0” 
  
5. 참조표준(권고)과의 비교 
 
5.1. 참조표준(권고)과의 관련성 
 
본 표준에서는 참조 표준의 IPTV 보안 요구사항을 검토하여 국내 IPTV 서비스에 적용 
가능한 항목들을 영문 그대로 반영하였으며, 영문 표기로 생기는 오해를 최소화 하기 위하여 “Note”를 이용 부연 설명을 추가하였다.  5.2. 참조한 표준(권고)과 본 표준의 비교표  
   해당사항 없음  
 
6. 지적재산권 관련사항  
 본 표준의 `지적재산권 확약서’ 제출 현황은 TTA 웹사이트에서 확인할 수 있다. 
  7. 적합 인증 관련 사항  
 7.1. 적합 인증 대상 여부  
   해당사항 없음  7.2. 시험 표준 제정 여부  
   해당사항 없음   8. 표준의 이력  
 
판수 제/개정일 제 ․개정내역 
제 1 판 2010. 3. 26 제정 정보통신단체표준 
TTAK.KO-08.0023 iiiPreface 
 
 
1. The Purpose of Standard   
Conditional Access System (CAS) is required for the content pro tection in IPTV 
Service environment. This standard is to define a technical spe cification on secure 
download and manage the CAS S/W module at an IPTV Terminal Devi ce, when 
customers change an IPTV service operator.   2.  The Summary of Contents  
 This standard lists the requirements to securely download and m anage CAS S/W 
over the IP network for IPTV ser vice and the specific technolog ies to satisfy them. This 
specification defines the protocols to securely download a CAS S/W module between 
the IPTV Terminal Device and the server. It also specifies the components required to 
securely manage the downloaded CA S S/W module at the IPTV Termi nal Device.  
  3. The Applicable fields of  industry and its effect   
 
This standard provides the technical specification to securely download and manage 
CAS S/W module at an IPTV Terminal Device when changing an IPTV  service operator. 
Therefore, this standard will contribute for the market growth and the success of the 
domestic IPTV service and related industries.    4. The Reference Standards (Recommendations)   4.1 International Standa rds (Recommendations)  
 [1] ITU-T X.1191, “Secure applications and services – IPTV security  –  F u n c t i o n a l  
requirements and architecture for IPTV security aspects” 
[2] ATIS-0800001, “IPTV DRM Interope rability Requirements,” April, 2006 
 4.2 Domestic Standards   정보통신단체표준 
TTAK.KO-08.0023 iv[1] TTAE.IT-Y1901, “IPTV Service Requirements 2.0” 
  5. The Relationship to Referen ce Standards(Recommendations) 
 5.1 The relationship of Reference Standards  
 
This standard includes some requ irements of the reference stand ards without 
modifications, which comply with  domestic IPTV service environm ents. 
Additional explanation by “Note” is provided to help clarifying  ambiguous 
descriptions in English 
 
5.2 Differences between Reference  Standard(recommendation) and this standard  
 
None 
  6. The Statement of Inte llectual Property Rights  
 
 IPRs related to this standard m ay have been declared to TTA. T he information 
pertaining to these IPRs, if any, is available on the TTA Websi te. 
  7. The Statement of Conformanc e Testing and Certification  
 
7.1 The Object of Conformanc e Testing and Certification 
      
 N o n e  
 
7.2 The Standards of Conforman ce Testing and Certification 
 
 N o n e  
  8. The History of Standard  
 
Edition  Issued date  Contents  
The 1st edition 2010. 3. 26 Established  
 정보통신단체표준 
TTAK.KO-08.0023 v목          차  
 
1. 개요 ......................................................... ............................................................ １ 
1.1. 목적 ....................................................... ....................................................... １ 
1.2. 표준의  구성  및 범위 ............................................................... .......................... １ 
1.3. 용어 ....................................................... ....................................................... １ 
1.4. 약어 ....................................................... ....................................................... ３ 
2. IPTV 용 교환 가능한 CAS 요구사항 ..................................... ..................................... ５ 
2.1. 국제  표준  요구사항 .......................................................... ................................ ５ 
2.2. 국내  요구사항 .......................................................... ....................................... ７ 
3. IPTV 용 교환 가능한 CAS 기술 ....................................... ......................................... ８ 
3.1. 개  요 ............................................................. ................................................ ８ 
3.2. 용어  및 약어 ............................................................ ....................................... ８ 
3.2.1. 용어 정의 .................................................. ................................................. ８ 
3.2.2. 약어 정의 .................................................. ................................................. ９ 
3.3. IPTV  용 교환  가능한  CAS  구조 ............................................................ ........... １０ 
3.4. 사용자  시나리오 .......................................................... ................................. １５ 
3.5. CA  TOKEN 영역 ............................................................ ................................. １８ 
3.5.1. Content Access Token (CA Token) ........................ ..................................... １９ 
3.5.2. CA Token Revocation List (CTRL) ........................ ....................................... ２４ 
3.5.3. CA Token 전송 프로토콜 ....................................... .................................... ２６ 
3.6. SW-DN  영역 ............................................................ ................................... ３４ 
3.6.1. Clone Detection Mechanism .............................. ........................................ ３５ 
3.6.2. CAS S/W 전송 프로토콜 및 Message .......................................................... ３６ 
3.7. CAS  영역 ............................................................ ........................................ ４１ 
3.8. S ECURE VM ............................................................ ...................................... ４１ 
3.8.1. Secure VM 기능 및 요구사항 .................................... ................................. ４２ 
3.8.2. Secure VM 구조 ........................................... ............................................ ４３ 정보통신단체표준 
TTAK.KO-08.0023 vi3.8.3. CAS S/W ................................................ ................................................. ４７ 
3.8.4. Policy ................................................. .................................................... ４８ 
3.8.5. System Call ............................................ ................................................. ５２ 
3.8.6. Event .................................................. .................................................... ５２ 
 
부록 A. CAS SYSTEM EXAMPE (INFORMATIVE) ......................... ....................................... 5 4 
A.1. 3-LEVEL KEY 분배  기법 ............................................................ ............................. 5  5 
A.2. 2-LEVEL KEY 분배  기법 ............................................................ ............................. 6  1 
A.3. EMM  전송  프로토콜  및 메시지 ............................................................... ................ 6  5 
A.4. 콘텐츠  SCRAMBLING  ............................................................... ............................... 7  0 
부록 B. ICAS STACK LAYER 분리 및 API 정의 ............................ ..................................... 7 2 
부록 C. CAS S/W PACKAGE EXECUT ION FLOW (INFORMATIVE) ............ ............................ 7 3 
부록 D. EXAMPLE OF BASIC SYSTEM CALLS ........................... ........................................ 7 5 
 
 정보통신단체표준 
TTAK.KO-08.0023 viiTable of Contents 
 
1. INTRODUCTION ............................................................... ............................................ 1 
1.1. PURPOSE  .............................................................. ................................................. 1 
1.2. SCOPE AND CONSTRUCTION OF STANDARD  .............................................................. ......... 1 
1.3. TERMS ............................................................... .................................................... 1 
1.4. ABBREVIATIONS  .............................................................. .......................................... 3 
2. REQUIRMENTS FOR IPTV INTERCHANGEABLE CAS  ........................................................ 5 
2.1. INTERNATIONAL STANDARD REQUIREMENTS  .............................................................. ......... 5 
2.2. DOMESTIC REQUIREMENTS  .............................................................. ............................. 7 
3. IPTV INTERCHANGEABLE CAS TECHNOLOGY ........................ ......................................... 8 
3.1. INTRODUCTION  .............................................................. ........................................... 8 
3.2. TERMS AND ABBREVIATIONS  .............................................................. ........................... 8 
3.2.1. Definitions of Terms ............................................................... .......................... 8 
3.2.1. Definitions o f Abbreviations ........................... ................................................... 9 
3.3. STRUCTURE OF IPTV  INTERCHANGEABLE CAS ........................................................... ...... 10 
3.4. USER SCENARIOS  ............................................................... ..................................... 15 
3.5. CA TOKEN ZONE .............................................................. ...................................... 18 
3.5.1. Content Access Token (CA Token) ........................ .......................................... 19 
3.5.2. CA Token Revocation List (CTRL) ........................ ............................................ 24 
3.5.3. CA Token Transmission Protocol ......................... ............................................ 26 
3.6. SW-DN  ZONE ............................................................... ........................................ 34 
3.6.1. Clone Detection Mechanism ............................................................... ............. 35 
3.6.2. CAS S/W Transmission Protocol and Message .............. .................................... 36 
3.7. CAS  ZONE .............................................................. ............................................. 41 
3.8. SECURE VM ............................................................ .............................................. 41 
3.8.1. Functions and Requi rements for Secure VM ............... ....................................... 42 
3.8.2. Structure of Secure VM.................................. ................................................. 43 
3.8.3. CAS S/W ................................................ ...................................................... 47 정보통신단체표준 
TTAK.KO-08.0023 viii3.8.4. Policy ................................................. ......................................................... 48 
3.8.5. System Call ............................................ ...................................................... 52 
3.8.4. Event .................................................. ......................................................... 52 
 
APPENDIX A. CAS SYSTEM EXAMPLE (INFORMATIVE) .................. ..................................... 54 
A.1. 3-LEVEL KEY DISTRIBUTION  ............................................................... ........................ 55 
A.2. 2-LEVEL KEY DISTRIBUTION  ............................................................... ........................ 61 
A.3. EMM  TRANSMISSION PROTOCOL AND MESSAGE  .............................................................. . 65 
A.4. CONTENT SCRAMBLING  ............................................................... .............................. 70 
APPENDIX B. ICAS STACK LAYER SEPERATION 및 API DEFINITIONS ..... ............................. 72 
APPENDIX C. CAS S/W PACKAGE EXECUTION FLOW (INFORMATIVE) ...... ........................... 73 
APPENDIX D. EXAMPLE OF BASIC SYSTEM CALLS ..................... ....................................... 75 
 정보통신단체표준 
TTAK.KO-08.0023 ix그림 목차  
 
(그림  3-1) IPTV 단말  소프트웨어  구조 ............................................................... ..................................................... １１ 
(그림  3-2) iCAS 시스템  구조 .............................................................. ............................................................... ...........１２ 
(그림  3-3) CA Token 영역  Flow Diagram  ............................................................... .................................................... １９ 
(그림  3-4) CA Token Format  .............................................................. ............................................................... ............... ２１ 
(그림  3-5) CTRL/SW Download/CAS Server Info base IP.Port  .............................................................. ................. ２３ 
(그림  3-6) CTRL / SW Download / CAS Server Info base URL ............................................................... ................ ２３ 
(그림  3-7) CTRL Format  ............................................................... ............................................................... ...................... ２５ 
(그림  3-8) SSL/TLS Type of CA Token Transmission Protocol  .............................................................. ................. ２７ 
(그림  3-9) CA Token Request Message (SSL/TLS Type)  ............................................................... ........................... ２７ 
(그림  3-10) CA Token Response Message (SSL/TLS Type)  .............................................................. ....................... ２８ 
(그림 3-11)  Challenge & Response Type of CA Token Transmission Protocol  .................................................... ２９ 
(그림  3-12) CA Token Request Message (Digital Envelope Type)  .............................................................. ............ ３１ 
(그림  3-13) CA Token Response Message (Digital Envelope Type)  ............................................................... .........３３ 
(그림 3-14) SW-DN 영역  Block Diagram  ............................................................... ................................................... ３５ 
(그림 3-15) CAS S/W Request & Response  .............................................................. ................................................... ３７ 
(그림  3-16) CAS S/W Request Message ............................................................... .......................................................... ３８ 
(그림  3-17) CAS S/W Response Message  ............................................................... ....................................................... ３９ 
(그림 3-18) SVM Architecture  .............................................................. ............................................................... ...........４４ 
(그림  3-19) Type1 Player 의 Descramble  .............................................................. ....................................................... ４６ 
(그림  3-20) Type2 Player 의 Descramble  .............................................................. ....................................................... ４６ 
(그림  3-21) Example of Policy Monitor ............................................................... ........................................................... ４９ 
(그림  3-22) Policy Monitor 처리과정  .............................................................. ............................................................. ５２ 
(그림  A-1) 3-Level Key Distribution Scheme  .............................................................. ................................................. ５５ 
(그림  A-2) Even/Odd Key  .............................................................. ............................................................... .................... ５６ 
(그림  A-3) ECM Message Format  .............................................................. ............................................................... ......５７ 
(그림  A-4) EMM Structure  ............................................................... ............................................................... .................. ５８ 
(그림  A-5) Structure of Entitlement  ............................................................... ............................................................... ...６０ 정보통신단체표준 
TTAK.KO-08.0023 x(그림  A-6) 2-Level Key Ditstribution Scheme  .............................................................. ................................................ ６２ 
(그림  A-7) EMM Structure  ............................................................... ............................................................... .................. ６３ 
(그림  A-8) Structure of Entitlement  ............................................................... ............................................................... ...６４ 
(그림  A-9) EMM Request and Reponse ............................................................... ........................................................... ６６ 
(그림  A-10) EMM_Request Message ............................................................... ............................................................... ６７ 
(그림  A-11) EMM_Response Message  ............................................................... ............................................................ ６９ 
(그림  C-1) 일반적인  CAS S/W Flow  ............................................................... ............................................................ ７３ 
 정보통신단체표준 
TTAK.KO-08.0023 xi표 목차  
 
<표 3-1> PLAYER 와 SVM 의 역할 ....................................... ........................................... 42 
<표 3-2> 콘텐츠 DESCRAMBLE TYPE ................................... .......................................... 45 
<표 A-1> KEYS USED IN THE ENTITLEMENT MANAGEMENT ............... ............................... 54 
<표 A-2> VALUES OF TRANSPORT_SCRAMBLING_CONTROL FIELD .................................... 71 
<표 D-1> SYSTEM C ALL RETURN 값 .................................. ............................................ 75 
<표 D-2> SYSTEM  CALL 목록 ........................................ ................................................ 76 정보통신단체표준 
TTAK.KO-08.0023 １IPTV 보안 서비스 규격 
 
1. 개요  
1.1. 목적  
IPTV 서비스를 안전하게 제공하고 사용하기 위하여 서비스 및 콘텐츠 보호 기술 
(CAS)이 필요하다. 본 규격에서는 IPTV 수신 단말의 이동성을 보장하기 위하여 이러한 서비스 및 콘텐츠 보호 기술(CAS) 모듈을 안전하게 다운로드 받아 실행 할 수 있는 기술 규격에 대해 정의한다. 
 
 
1.2. 표준의  구성  및 범위  
본 표준은 IPTV에서 서비스 및 콘텐츠 보호 기술(CAS) 모듈을 네트워크를 통하여 
안전하게 다운로드 받고 관리하기 위하여 필요 요구사항들을 정의하고 이를 만족하기 위한 세부 기술들을 정의한다.  
첫 번째로 국외 표준들을 참조하여 국내 IPTV 서비스에 적용 가능한 요구사항들을 
정리하고 국내 IPTV 서비스 환경을 고려한 추가적인 요구사항들을 정의한다. 
두 번째로 정의된 요구사항들을 만족시켜 주기 위한 기술들을 정의한다. 세부적인 
기술 사항으로는 서비스 및 콘텐츠 보호 기술(CAS) 모듈을 안전하게 다운로드 받기 위한 서버와 IPTV 수신 단말과의 프로토콜들과 다운로드 받은 서비스 및 콘텐츠 보호 기술(CAS) 모듈을 안전하게 관리하고 실행시키기 위하여 IPTV 수신 단말에서 필요한 컴포넌트들을 정의한다. 
 
 
1.3. 용어   
Term  Definition  
IPTV 
Interchangeable CAS (iCAS) IPTV 수신  단말의  이동성을  보장하기  위하여  서비스  및 콘텐츠
보호  기술 (CAS) 모듈을  안전하게  다운로드  받아  실행  할 수 있는
기술  정보통신단체표준 
TTAK.KO-08.0023 ２Access Control  The practice of restricting the viewing of TV or the interaction with IPTV 
applications to authorized persons, and to the mechanisms which prevent 
access by unauthorized persons. It includes:  
- Control of boot-load and application load onto the IPTV Terminal Device. 
- Control of access to the service and to the IPTV Terminal Device.  
- Protection of the data carried between IPTV Terminal Device and Service. 
- Usually mutual authentication between IPTV Terminal Device and service. 
Authentication  A mechanism that allows verifyin g an entity’s identity in order to ensure that 
they are who they claim to be.  
Authorization  A mechanism that defines and controls what services or resources an entity 
can access.  
Conditional Access  A mechanism th at is used to protect and control the viewing of traditional 
broadcast TV content, on-demand content, and pay per view. It has been implemented over uni-directional and bi -directional networ ks and co-channel 
transport. It is used both in analog TV broadcast systems and in digital TV delivery systems (where the equivalent  of analog de-scrambling for digital 
services is implemented).  
Content Protection  Ensuring that an end-user can  only use the content they have already acquired 
in accordance with the rights that they have been granted by the rights holder.
DRM  A collection of technologies that technically enable the definition of and the 
enforcement of secure content transportation as well as secure content licensing, including:  
- Protection and control of the viewing of  content that is delivered over IP 
transport.  
- Rights Management for the delivered content.  
Entitlement  Information about the authoriza tion level/s a user has to access and use 
certain services and to access, use, copy and distribute certain contents received in his/her IPTV Terminal Device.  
IPTV Terminal 
Device (IPTV 수신  
단말 ) IPTV Terminal Function (ITF) (as defined in the IPTV Architecture 
Requirements, ATIS-0800002), represents the functionality within the consumer network that is responsible  for terminating the IP signal, and 
converting the content into a readable format (e.g., a STB).  
Key Management  All of the provi sions made in a secure IPTV system, which are related to the 
generation, transport, exchange, storag e, safeguarding, use, revocation and 
renewing of cryptographic keys.  
Message Integrity  The quality of a transmitted me ssage, such that its recipient can be assured 
that the contents of the message have not  been tampered with or altered since 
the time it was transmitted by the sender.  One common approach is to use a 정보통신단체표준 
TTAK.KO-08.0023 ３one-way hash function that combines all of the bytes in the message to 
produce a message digest that is impossibl e to reverse and then make a digital 
signature of this hash value by the sender. Another method involves 
combining message bytes with a key value known only to the sender and recipient in a hash function.  
Privacy  Confidentiality of user viewership and interactions with IPTV systems.  
Rights  The ability to perform a pre-defined set of utilization functions on a content 
item. These utilization functions are the permissions (e.g., to view/hear, copy, 
modify, record, excerpt, sample, transl ate in another language, keep for a 
certain period, distribute), constraints (e.g., play/view/hear multiple times, play/view/hear certain number of hours)  and obligations (e.g., payment, 
tracking information) that apply to th e content and provide liberty of use 
granted to the end-user.  
Rights Expression  The statement of utilization functions that can be performed on a Content 
Item and the conditions in which they can be performed.  
Rights holder  Indicates the entity that is entitled to grant rights.  
Service Protection Ensuring that an end-user can only acquire a service, and, by extension, the 
content contained therein, that he or she is entitled to receive. 
IPTV Terminal Device Protection Ensuring that a terminal device employed by an end-user in the reception of a 
Service can reliably and securely use content while enforcing the rights of use granted for that content, and while phys ically and electronically protecting the 
integrity of the terminal device, and the confidentiality of the content and 
critical security parameters not otherwise protected by encryption or watermarking. 
VOD  Refers, in the context of this docum ent, to all forms of on-demand content 
that are streamed at the request of a su bscriber. This can include, for example, 
movies, music, radio talk shows, distance learning, games, etc.  
User Privacy Protection Ensuring that information considered to  be private (or confidential) by an 
end-user be maintained in confidence,  while remaining subject to mandatory 
disclosure due to legal processes. 
 
 
1.4. 약어  
CA Conditional Access 
CAS Conditional Access System DRM Digital Rights Management ECM Entitlement Control Messages EMM Entitlement Management Messages 정보통신단체표준 
TTAK.KO-08.0023 ４iCAS IPTV Interchangeable CAS 
IPTV Internet Protocol Television IIF IPTV Interoperability Forum IP Internet Protocol ITF IPTV Terminal Function STB Set-Top Box VOD Video On Demand 정보통신단체표준 
TTAK.KO-08.0023 ５ 
2. IPTV 용 교환  가능한  CAS 요구사항  
 
본 장에서는  IPTV 용 교환  가능한  CAS 기술  에 대한  요구사항을  정리한다 . 국제  표준  
규격에서  정의하고  있는  요구사항들  중 국내  IPTV 서비스를  안전하게  제공하기  위한  
IPTV 용 교환  가능한  CAS 기술을  위해  필요한  항목들을  기술하고 , 국내  IPTV 서비스  
환경을  고려하여  추가적으로  필요한  보안  요구사항들을  정의한다 . 이러한  요구사항들은  
국내  IPTV 서비스  주요  기능요소에  대한  세부  규격을  정의하기  위한  지침을  제공한다 .  
 
 
2.1. 국제  표준  요구사항  
 
본 절에서는  IPTV 국제  표준  규격들을  참조하여  작성된  “IPTV 서비스  요구사항  2.0 
(TTAE.IT-Y1901)” 규격에서  정의한  IPTV 서비스  요구사항  중 본 규격에서  지원  가능한  
항목들을  발췌하여  기술한다 .1  
 
[1] The IPTV architecture is required to support c ontent protection as defined in Section 1.3.  
[2] The IPTV architecture is required to support associating content with protection and content 
management metadata to permit the expression of its rights of usage.  
[3] The IPTV architecture is required to support protection of content that is distributed 
simultaneously to a very high number of subscribers (scalability).  
[4] The IPTV architecture is required to support protection of content that is transferred over 
multicast and/or over unicast streams.  
[5] The IPTV architecture is prohibited from pr ecluding support for multiple content and service 
protection mechanisms regardless of specific hardware or software requirements.  
(Note: 상기  요구사항의  “specific hardware or software” 는 특정  제조사에  의존적인  
HW/SW 의 사용을  방지하기  위한  것으로 , 규격에서  정의된  기능을  지원하기  위한  
HW/SW 는 이에  해당되지  않는다 .) 
[6] Scrambling algorithms for broadcast stream are required to support periodic update of 
necessary cryptographic keys.  
[7] Scrambling algorithms for IPTV are required to be built using publicly available and 
standardized cryptographic algorithms.  
[8] The IPTV architecture is required to support service protection, as defined in Section 1.3.  
                                                      
1 본 절에서는 요구사항 번역 시 생길 수 있는 오해를 방지하기 위해 영문 표기 그대로 
발췌하여 기술한다. 정보통신단체표준 
TTAK.KO-08.0023 ６[9] The IPTV architecture is required to support aut horization and authentication of end-user. Note: 
End-user may be subscriber.  
[10] The IPTV architecture is required to support rights management that is independent of specific 
content formats or specifications.  
[11] The IPTV architecture is required to support a mechanism for secure delivery of rights and 
content access control information to the IPTV terminal devices.  
[12] The IPTV architecture is required to support a mechanism for transmitting signaling messages 
securely between the SCP server-side func tions and the SCP client-side functions. 
[13] The IPTV architecture is required to support a mechanism to allow for the confidentiality of 
signaling messages between the SCP server-side functions and the IPTV terminal device SCP client-side functions.  
[14] The IPTV architecture is required to support a mechanism to allow for the authenticity of 
signaling messages between the SCP server-side functions and the IPTV terminal device SCP client-side functions.  
[15] The IPTV architecture is required to support a m echanism to allow for the integrity of signaling 
messages between the SCP server-side functions and the IPTV terminal device SCP client-side functions.  
[16] If the IPTV architecture employs a key management system, such system is required to be 
designed for scalability, reliability, and interoperability.  
[17] The IPTV architecture is prohibited from precluding support for the installation and operation 
of multiple service protection solutions without  any hardware replacement except removable 
devices (such as USB dongle and SIM cards).  
(Note: “operation of multiple service protection solutions” 는 여러  개의  protection solution 을 
실행할  수 있어야  하지만  동시에  여러  개의  protection solution 을 실행하는  것을  
의미하지는  않는다 .) 
[18] The IPTV architecture is prohibited from precluding support for a mechanism for the selection 
of a SCP system from the available SCP system s without any hardware replacement except 
removable devices.  
[19] The IPTV architecture is prohibited from precluding support for secure downloading of a SCP 
system.  
[20] The IPTV architecture is prohibited from precl uding support for verification and authentication 
of the downloaded SCP system mechanisms.  
[21] The IPTV architecture is required to support I PTV terminal device protection, as defined in 
Section 1.3.  
[22]
 The IPTV architecture is required to support a means to authenticate IPTV terminal devices.  정보통신단체표준 
TTAK.KO-08.0023 ７[23] The IPTV architecture is required to support secure download and installation of the SCP 
operating code to IPTV terminal devices.  
[24] The IPTV architecture is required to support user privacy protection, as defined in Section 1.3.  
[25] The IPTV architecture is required to support a mechanism to allow the IPTV terminal device 
SCP client-side functions to authenticate the SCP server-side functions.  
[26] The IPTV architecture is required to allow a sub scriber to set an access control mechanism (e.g. 
a password) in order to restrict access to content and/or services.  
[27] The IPTV architecture is required to be capable of indicating why access to content and/or 
services has been denied to the end-user.  
 
 
2.2. 국내  요구사항  
 
본 절에서는  국제  표준  규격에서  정의하고  있는  요구사항에  추가로  국내  IPTV 서비스  
환경을  고려할  때 필요한  요구사항들을  정의한다 . 
 
[1] IPTV 서비스는  IPTV 수신  단말이  정당한  기기인지를  인증한  후 서비스  및 콘텐츠  
보호  기술  모듈 (CAS) 을 다운로드  시켜주어야  한다 . 
[2] IPTV 용 교환  가능한  CAS 서비스는  소프트웨어  보안모듈의  기술상세  및 
소프트웨어로  보호된  기밀을  침해  또는  조작하려는  시도를  위장하거나  방해하기  
위하여  obfuscation 기술을  사용하여야  한다 . 
 정보통신단체표준 
TTAK.KO-08.0023 ８ 
3. IPTV 용 교환  가능한  CAS 기술  
3.1. 개 요 
본 장에서는  IPTV 서비스  보호를  위한  Interchangeable CAS (iCAS) 기술을  정의한다 . 
기존의  디지털  케이블  방송  및 위성  방송에  적용되어  오던  CAS 기술은  인터넷  양방향  
서비스를  이용한  서비스  시나리오들을  지원하기  어렵기  때문에  다양한  IPTV 서비스  
시나리오를  지원하고  수용할  수 있는  서비스  보호  기술이  필요하다 . 본 장에서는  다양한  
IPTV 서비스  시나리오를  지원할  수 있을  뿐만  아니라  사용자의  서비스  선택권  및 
편리성을  보장해줄  수 있는  iCAS 기술을  정의한다 .  
본 규격의  iCAS 기술은  필요  시 네트워크에  연결하여  CAS S/W 를 다운로드  받아  
사용할  수 있도록  하는  방법이다 . 특정  CAS 에 제약을  받지  않고  하나의  IPTV 수신  
단말을  사용하여  다양한  사업자가  제공하는  서비스를  사용할  수 있고 , 또한  S/W 의 
해킹에  대해서도  빠른  대응이  가능하다 .  
본 규격의  iCAS 기술은  크게  서비스  및 콘텐츠  보호를  위한  CAS (Conditional Access 
System) 기술 , 다운로드  받은  CAS S/W 를 실행  시키기  위한  SVM (Secure Virtual Machine), 
그리고  정당한  권한을  가진  사용자만이  CAS S/W 를 다운로드  받을  수 있도록  하는  COPP 
(Content Protection Platform) 기술로  구성된다 . 본 규격에서는  CAS, SVM, COPP 기술들을  
소개하고 , 각각의  기술을  사용하여  IPTV 서비스를  안전하게  보호하는  방법을  기술한다 . 
 
3.2. 용어  및 약어  
3.2.1.  용어  정의  
Linear TV 사용자가  시청  시간을  제어할  수 없는  방송  서비스  
VoD 사용자가  콘텐츠와  콘텐츠  시청  시점을  선택하여  시청할
수 있는  서비스  (Download VoD, Streaming VoD) 
Push VoD SP의 결정에  따라 , 콘텐츠를  packaging 하여  사용자의  local 
storage 에 전송  저장하는  서비스  
Period Subscription Service 에 일정  기간단위로  가입  (예, 1년) 
PPV  Subscription 이나  Package 구입과  별도로  특정  program event
를 구입하여  시청하는  서비스 . 프로그램을  구입한  모든  가
입자에게  동시에  같은  Program Event 가 전송됨 . 
PVR (Personal Video 
Recorder) Multimedia 콘텐츠를  녹화 , 저장 , 재생할  수 있는  사용자
device 
nPVR (Network PVR) PVR과 동일한  기능이나  recording device 가 Service Provider정보통신단체표준 
TTAK.KO-08.0023 ９영역에  존재  
Time shifting 콘텐츠의  최초  전송시점  이후에  콘텐츠를  재생할  수 있는
기능  
Random Access Point 콘텐츠에서  재생  시작이  가능한  위치  (MPEG 의 I-frame 등) 
Scrambling/Descrambling Video, Audio 등의  콘텐츠를  암호화 /복호화하는  방법  
Encryption/Decryption Scrambling/Descrambling 을 위한  일련의  Key를 암호화 /복호
화하는  방법  
Control Word Descrambler 가 사용하는  key 
Entitlement Control Message 
(ECM) control word 와 access condition 의 cryptogram. Descrambler 를
제어하기  위하여  사용됨  
Entitlement Management 
Message (EMM) Viewer 에게  service 를 descramble 하기  위한  권한을  부여하는
message 
Subscriber Management 
System (SMS) Smart Card 발급 , 청구서  발급 , 시청료  수신  등을  수행하는
business senter. subscriber 의 정보와  decoder 의 serial number 등
을 관리  
Content Access Token (CA 
Token) 콘텐츠에  대한  정보를  담는  Token 
Secure Sockets Layer 
/Transport Layer Security (SSL/TLS) Web 상에서  보안  프로토콜  
Certificate Revocation 
List(CRL) Revoked 된 Certificate 의 List 
CA Token Revocation List 
(CTRL) Revoked 된 CA Token 의 List 
 
 
3.2.2.  약어  정의  
AES Advanced Encryption Standard 
CA Conditional Access CAS Conditional Access System CA Token Content Access Token CBC Cipher Block Chaining 정보통신단체표준 
TTAK.KO-08.0023 １０COPP Content Protection Platform 
CRL Certificate Revocation List CTRL CA Token Revocation List CW Control Word SK Service Key ECM Entitlement Control Message EMM Entitlement Management Message IV Initialization Vector MPEG Moving Picture Experts Group PES Packetized Elementary Stream PSI Program Specific Information PMT Program Map Table PID Packet Identifier TS Transport Stream SMS Subscriber Management System SVM Secure Virtual Machine RSA Rivest-Shamir-Adlemen 
 
 
3.3. IPTV 용 교환  가능한  CAS 구조  
본 규격에서  정의하는  iCAS 구조는  순수  S/W를 기반으로  서비스  가입  후 콘텐츠를  
선택하여  재생하는  과정에서  수행되는  IPTV 수신  단말을  인증하고  CAS S/W 를 
다운로드하고  관리하는  기술을  포함한다 . IPTV 수신  단말에서의  iCAS 모듈은  COPP 
(COntent Protection Platform) 와 SVM(Secure Virtual Machine) 으로  구성되며 , COPP 는 
서버로부터  IPTV 수신  단말을  인증  받고  CAS S/W 를 안전하게  다운로드  받는  과정을  
수행하고 , SVM
은 다운로드  받은  CAS S/W 를 안전하게  수행하는 역할을 담당한다. (그림  
3-1)은 iCAS Stack 을 포함한  IPTV 단말의  구조를  나타낸다 .2  
 
                                                      
2 iCAS Stack 에서 Layer 간의 분리와 API 관련된 사항은 부록 B 에서 정의한다. 정보통신단체표준 
TTAK.KO-08.0023 １１Resources (HW & SW)RAL (Resource Abstraction Layer)Middleware
COPPCASS/W User Experience and Applications Layer
Service Logic Function
PlayerDelivery 
Sys.Metadata 
ClientSecure Virtual 
Machine (SVM)
 
(그림  3-1) IPTV 단말  소프트웨어  구조  
 
CAS S/W 다운로드  과정은  IPTV 서비스  가입  시 수행되며 , 선택적으로  개별  채널  및 콘
텐츠  구매에  따라  추가  수행  될 수도  있다 . IPTV 서비스  보호를  위해  CAS S/W 를 다운로
드 받아  사용하는  과정은  아래와  같이  단계적으로  일어난다 . 
 
• 1단계 : IPTV 서비스에  가입 (또는  콘텐츠  구매 )하고 , 그 결과로  콘텐츠  시청  권한을  
증명하기  위한  CA Token 을 획득한다 . 이후  2, 3단계는  1단계에서  정당한  CA Token 을 
확보한  경우에만  올바르게  수행될  수 있다 . 
• 2단계 : 암호화된  콘텐츠를  복호화하기  위하여  사용되는  CAS S/W 를 다운로드  받는다 . 
본 단계에서는  1단계에서  콘텐츠  시청을  위해  획득한  CA Token 을 S/W Download 
Server 에 제출하고  CA Token 에 대한  검증이  이루어진  경우에  Server 로부터  CAS S/W
를 다운로드  받는다 .  
• 3단계 : 다운받은  CAS S/W 를 실행하여  콘텐츠에  대한  복호화  Key를 포함하는  EMM 
등을  획득하고  IPTV 서비스를  통하여  수신한  암호화된  콘텐츠를  복호화한다 .  
 
본 규격에서  사용되는  콘텐츠  시청  권한  획득이란  IPTV 서비스  가입을  통해  서비스  
이용  권한을  획득하거나  특정  콘텐츠나  채널  구매를  통해  시청  권한을  획득하는  것을  포
함하는  것으로  해당  서비스에  따라  사용  시나리오에  맞게  다양한  방법으로  수행될  수 있
다. 또한 , 3단계에서  수행되는  CAS S/W 의 키 전송과  관련된  사항은  본 iCAS 규격에서는  
포함하지  않으며  각 CAS S/W 에 따라  다르게  동작한다 . 본 규격에서는  3단계를  수행하기  
위해  SVM 에서  CAS S/W 가 동작하고  관리되는  방법에  대해서만  정의한다 .  
본 규격에서  정의하는  iCAS 시스템  구조는  (그림  3-2)와 같다 .  
 정보통신단체표준 
TTAK.KO-08.0023 １２
PlayerSVM
DecoderIPTV Main 
ServerSMSSW Download 
ServerCAS
ServerStreaming 
Server
CASS/W1. 재생요청
3. CA Token4. CAS S/W
검증 요청6. EMM 요청
7. EMM 전송8. Content
(Scrambled)
COPP2. CA Token 요청
CA Token
영역
CAS 영역
5. CAS S/W
정보 전달
SW_DN
영역
 
(그림  3-2) iCAS 시스템  구조  
 
iCAS 시스템의  각 구성요소들은  다음의  역할을  수행한다 .  
• IPTV Main Server – IPTV 운용을  위한  서버로 , EPG, 콘텐츠  관리  등 IPTV 서비스  전반
을 담당하며  본 규격의  범위에는  포함되지  않는다 .  
• SMS – 가입자  관리  및 콘텐츠  구매  관리를  담당하는  서버로써 , 서비스  가입  확인  또
는 콘텐츠  구매  시 콘텐츠  시청  권한을  증명하기  위한  CA Token 을 발급한다 . 
• S/W Download Server – CAS S/W 를 저장 /관리하며 , 사용자의  요청에  따라  CAS S/W 를 
전송하는  역할을  담당한다 .  
• CAS Server – 콘텐츠별  복호화  Key를 관리하고 , 사용자의  요청에  따라  Key를 사용자  
에 전달하는  역할을  담당한다 . 
• Streaming Server – 콘텐츠를  전송하는  역할을  담당한다 . 서비스의  종류에  따라  Linear 
TV 서비스인  경우  실시간  scrambling 이 발생하거나 , V oD 서비스인  경우  사전에  콘텐
츠를  scrambling 하여  저장한  후 전송한다 .  
• COPP Client – iCAS 구조에서  단말에  탑재되어  CA Token 및 CAS S/W 의 수신을  담당
하고 , CAS S/W 운용을  담당하는  역할을  수행한다 .  
• SVM – CAS S/W 는 이식성이  용이하도록  Device 내의  Virtual Machine 에서  수행된다 . 
SVM은 CAS S/W 가 실행되는  Virtual Machine 으로  CAS S/W 에 특화된  system call 및 
event handling 등을  지원하도록  설계된다 . 
• CAS S/W – 암호화된  콘텐츠를  복호화하기  위한  S/W로써  S/W Download Server 로부터  정보통신단체표준 
TTAK.KO-08.0023 １３수신되어  SVM 상에서  수행된다 . 콘텐츠를  복호화하기  위하여  EMM 요청  및 수신을  
담당하고 , EMM 을 통하여  수신된  Key를 해석하여  암호화된  콘텐츠를  복호화하는  기
능을  수행한다 . 
• Player – 본 규격에서  제안하는  iCAS 구조  이외에  IPTV 에서  순수하게  콘텐츠  재생을  
담당하는  부분을  지칭한다 .  
• Decoder – 압축된  콘텐츠를  decoding 하는  기능을  담당한다 . 
 
상기  iCAS 구조에서  시스템의  안전성을  보장하기  위한  인증체계는  다음과  같다 . 
1. IPTV 수신  단말은  자체의  보안  메커니즘을  통해  관련  SW들 안전하게  로딩하고 ,  
키와  중요  정보들이  노출되지  않도록  보호한다 .3 
2. CA Token 을 발급할  때 정당한  사용자만이  CA Token 을 확보하여  사용할  수 있도록 , 
SMS는 단말과  결합된  형태의  CA Token 을 발급  전달한다 .  
(IPTV 수신  단말  인증서  확인  후, IPTV 수신  단말의  공개키로  암호화하여  전달 ) 
3. IPTV 수신  단말은  CAS S/W 를 다운로드  받기  위해  자신이  CAS Token 과 결합된  단말이
라는  것과  복제된  단말이  아니라는  것을  증명한  후에 , 서버로부터  자신의  공개키로  암
호화된  CAS S/W 를 다운로드  받는다 . 
4. CAS S/W 를 다운로드  받은  후 IPTV 수신  단말은  정당한  CAS S/W 인지  확인  후 SVM 에 
로딩시키며 , CAS S/W 와 함께  다운로드  된 Policy 에 의해  Control 되면서  안전성이  보장
된다 . 
결과적으로 , IPTV 수신  단말의  안전성에  대한  가정  하에  IPTV 수신  단말과  결합된  CA 
Token 발행 , IPTV 수신  단말  및 사용  권한  인증 , CAS S/W 검증 , CAS S/W 안전하게  로딩  
후 실행하는  순으로  시스템을  안전도를  보장한다 . 
  
본 규격에서는  위에서  설명한  콘텐츠  획득  3단계를  각각  CA Token 영역 , SW_DN 영역 , 
CAS 영역으로  정의한다 . 각 영역별로  각 구성요소  사이의  동작을  나누어  설명하면  다음
과 같다 .  
 
[CA Token 영역 ] 
선택한  콘텐츠와  Player 의 정보를  CA Token 을 발급하는  SMS 에 전달하여  CA Token 을 생
성하고  Player 에 내려  주는  역할을  담당한다 . CA Token 영역은  다음의  순서로  동작한다 .  
1) Player 는 IPTV Main Server 에 접속해서  사용하고자  하는  콘텐츠를  선택하고 , CA Token 
                                                      
3 단말에서 준수해야 하는 보안 관련 사항들은 본 규격의 Trusted Authority (TA)에서 제정하는 
Robustness Rules 에서 정의된다.  정보통신단체표준 
TTAK.KO-08.0023 １４발급을  위하여  COPP Client 에게  구매  관련  정보를  전달한다 .  
2) COPP Client 는 SMS 에게  CA Token 발급을  요청한다 . 
3) SMS 는 정당한  콘텐츠  시청  권한  획득 (서비스  가입  또는  콘텐츠  구매 )이 확인된  경우  
CA Token 을 생성하고 , 해당  CA Token 을 암호화  하여  COPP Client 에게  전송한다 .  
CA Token 영역의  경우  어떤  시스템에  본 규격의  iCAS 구조를  integration 하는가에  따라  
동작이  달라질  수 있으며 , 본 규격의  경우는  IPTV Main Server 와 SMS 가 완전히  분리된  
형태의  시스템을  가정으로  작성하였다 . 그러나  이 둘이  통합된  시스템의  경우라면  CA 
Token 발급  요청이  COPP Client 를 거치지  않고 , 직접  SMS 에게  전달되는  방법을  사용하
는 것이  보다  바람직하다 .  
 
[SW_DN 영역 ] 
CA Token 을 사용해서  CAS S/W 를 받는  단계로써 , 다음의  순서로  동작한다 .  
1) COPP Client 가 S/W download server 에게  콘텐츠  복호화에  필요한  CAS S/W 를 요청한다 . 
이 과정에서  인증  및 IPTV 수신  단말의  신뢰성  검사를  수행한다 .  
2) S/W download server 는 CA Token 을 검사하여  CA Token 유효성을  검증한다 .  
3) CA Token 에 이상이  없으면  CAS S/W 를 암호화  하여  COPP Client 에게  전송한다 .  
4) COPP Client 는 수신한  CAS S/W 를 VM을 통하여  실행한다 . 
 
[CAS 영역 ] 
CAS S/W 가 동작하면서  암호화된  콘텐츠를  받아  복호화  해서  사용하는  단계이다 . 이 과
정은  CAS 규격에  따라  다를  수 있으며 , 본 규격의  부록  A에서  제안된  CAS를 가정할  경
우 다음과  같이  동작한다 .  
1) CAS S/W (client) 는 CA Token 을 CAS Server 에 전달함으로써  EMM 을 요청한다 . 이때 , CA 
Token은 privacy 를 위하여  CAS Server 의 키를  이용하여  암호화  되어  전송된다 . 
2) CAS Server 는 CA Token 을 검증하여  문제  없는  경우  해당  콘텐츠를  복호화할  수 있는  
Key를 포함한  EMM 을 생성하여  CAS client 에 전송한다 . 이때  EMM 의 Key를 포함한  주
요 정보는  CAS client 가 실행되는  IPTV 수신  단말의  Key로 암호화되어  전송된다 . 
3) CAS client 는 EMM 을 해석하고 , 포함된  Key를 이용하여  암호화된  콘텐츠를  복호화한
다. 복호화된  콘텐츠는  decoder 에 전송되어  재생된다 . 
CAS 영역에서  CAS S/W 는 Secure Virtual Machine (SVM) 상에서  동작한다 .  
 
본 규격에서  정의하는  SVM 은 CAS S/W 를 실행하기  위한  가상의  실행환경 (run-time 정보통신단체표준 
TTAK.KO-08.0023 １５environment) 이다 . 가상의  실행환경을  제공함으로써 , CAS S/W 를 platform independent 하게  
제작할  수 있다 . 또한  SVM 은 악의적인  CAS S/W 로 인한  피해를  막을  수 있도록  다음의  
Security 특성이  고려하여  설계되었다 .  
• CAS S/W 인증 : SVM 에 적재되어  실행되는  모든  CAS S/W 는 배포하는  기관의  전자서
명을  포함한다 . 
• SVM 실행환경  인증 : CAS S/W 는 실행중인  SVM 이 올바른  Device Key 를 가지고  있을  
때, 올바른  기능을  수행할  수 있다 . 
• CAS S/W 의 행동제어 : CAS S/W 는 반드시  Policy 를 포함하고 , CAS S/W 의 허용되는  작
업을  기술하기  때문에 , 예외적인  행동을  차단할  수 있다 . 
• CAS S/W 의 보호 : CAS S/W 는 COPP 에서  전송될  때와  적재될  때, 평문  형태로  코드를  
노출시키지  않는다 . CAS S/W 코드유출로  인한  reverse-engineering 공격을  최소화  할 
수 있다 . 
• 키 보호 : SVM 은 player 와 독립된  보안수준을  제공하기  위하여  H/W 로 제작되거나 , 
obfuscation 으로  보호된다 . 따라서 , SVM 이 포함하는  암호키는  안전하게  보호된다 . 
 
3.4. 사용자  시나리오  
본 절에서는  서비스  가입  및 콘텐츠  구매에  따른  iCAS Component 사이의  동작  Flow 를 
기술한다 . 본 규격에서  정의하는  iCAS 기술은  IPTV 에서의  Linear TV 서비스를  위해  
의무적으로  적용되어야  하며 , 해당  IPTV 서비스가  VOD 지원  시 본 규격의  iCAS 기술을  
따라야  한다 .  
 
[기본  설정 ] 
 
1) COPP Client 는 특정  IPTV 서비스에  가입을  신청한다 . (CA Token 요청 ) 정보통신단체표준 
TTAK.KO-08.0023 １６2) COPP Client 는 가입  절차를  완료하면  IPTV 서비스로부터  해당  서비스  사용을  위한  CA 
Token을 발급  받는다 . 
3) COPP Client 는 SW Download Server 에 CA Token 을 전송한다 . 
4) SW Download Server 는 CA Token 의 유효성을  검증한  후, CAS S/W 를 다운로드  해준다 . 
5) COPP Client 는 CAS S/W 의 유효성을  확인하고 , SVM 에 적재하여  실행한다 . 
 
[VOD 동작  Flow] 
Player COPP Client SVM Streaming Server SMS CAS Server SW Download Server
1) 콘텐츠 재생 요청
3) CA Token 요청
4) CA Token 발급
6) CAS S/W 정보 전달
7) CAS SW 실행
8) EMM 요청 (CA Token  이용)
9) EMM 전송
10) Scrambled 콘텐츠 전송
11) Descrambling
13) CAS 종료2) CA Token 검색
5) CAS S/W 유효성 검증 요청
12) 재생 종료
 
1) Player 는 시청하려는  콘텐츠를  선택하고 , COPP Client 에게  콘텐츠  재생을  요청한다 . 
2) COPP Client 는 재생하려는  콘텐츠에  대한  CA Token 을 가지고  있는지  검색한다 . CA 
Token의 소유  유무와  서비스  시스템의  조건에  따라  다음과  같이  동작한다 .  정보통신단체표준 
TTAK.KO-08.0023 １７• 서비스  사업자  시스템이  하나의  CAS S/W 만을  허용한다면  CAS S/W 가 IPTV 수신  
단말에  이미  존재하는지  확인한  후, 존재한다면  7) 단계로  넘어간다 . 
• 서비스  사업자  시스템이  복수  개의  CAS S/W 사용을  가정한다면 , 5) 단계로  넘어
간다 . 
• CA Token 을 가지고  있지  않다면  다음  단계를  수행한다 . 
3) COPP Client 는 SMS 에게  Content_ID 를 포함하는  콘텐츠  재생하기  위해  CA Token 을 요
청한다 . 
4) 콘텐츠  구매  단계가  완료되었을  경우  SMS 는 이에  해당하는  CA Token 을 발급하여  
COPP Client 에게  전송한다 .  
5) COPP Client 는 해당  CA Token 을 SW Download 서버에게  전송하고  IPTV 수신  단말과  
CA Token 의 유효성을  검사한다 . 
6) IPTV 수신  단말과  CA Token 이 모두  유효하다면  CA Token 을 분석하여 , COPP Client 가 
가지고  있는  CAS S/W 로 해당  콘텐츠  시청이  가능한  경우  사용  CAS S/W 의 ID를 전송하
고, COPP Client 가 가지고  있지  않은  경우  CAS S/W 를 다운로드  하여준다 . 
7) COPP Client 는 CAS S/W 의 유효성을  확인하고 , SVM 에 적재하여  실행한다  
8) CAS S/W 는 콘텐츠  재생에  필요한  EMM 을 얻기  위해 , CAS에게  CA Token 과 함께  EMM 
요청을  전송한다 . 
9) CAS 는 CA Token 의 유효성을  검증하고 , 필요한  EMM 을 CAS S/W 에게  전송한다 . (8번과  
9번 단계는  CAS에 따라  다르게  동작할  수 있으며  추가적인  Flow 가 일어날  수 있다 .) 
10) Player 는 CAS로 보호된  컨텐츠를  수신한다 . 
11) 컨텐츠를  descrambling 하여  재생한다 . 
12) Player 는 콘텐츠  재생을  종료시키며 , COPP Client 에게  통보한다 . 
13) COPP Client 는 SVM 에게  종료  event 를 전달하고  CAS S/W 실행을  종료한다 . 
 
[Linear TV 동작  Flow] 정보통신단체표준 
TTAK.KO-08.0023 １８Player COPP Client SVM Streaming Server SMS CAS Server SW Download Server
1) 콘텐츠 재생 요청
3) CA Token 요청
4) CA Token 발급
6) CAS S/W 정보 전달
7) CAS SW 실행
8) EMM 요청 (CA Token  이용)
9) EMM 전송
10) Scrambled 콘텐츠 전송
10) Descrambling
11) 채널 전환
12) CAS 종료2) CA Token 검색
5) CAS S/W 유효성 검증 요청
재생 중 반복
12) 재생 종료
 
최초  Linear TV 의 재생을  요청하는  단계에서  CA Token 을 검색하고  CAS S/W 의 유효성을  
검증  한 후, channel 의 시청을  시작하고  재생  중 채널의  전환  시에는  로딩되어  있는  CAS 
S/W가 이용가능한지  여부를  확인하고  (확인  불필요  시 생략  가능 ) 가능한  경우  로딩되어  
있는  CAS S/W 를 이용하여  채널  전환을  지원한다 . Linear TV 의 다른  재생과정은  VOD 와 
동일하므로  설명은  생략한다 . 
 
 
3.5. CA Token 영역  
본 절에서는  CA Token 영역에서  사용되는  구성  요소들에  대해  정의하고  관련  프로토콜
들을  기술한다 . CA Token 영역에서  정의하는  구조는  (그림  3-3)과 같다 . COPP Client 는 정보통신단체표준 
TTAK.KO-08.0023 １９SMS를 통하여  콘텐츠에  대한  시청  권한을  획득하고  SMS 는 그 결과로  콘텐츠  시청  권
한을  증명할  수 있는  CA Token 을 생성하여  COPP Client 에게  전송한다 . 콘텐츠  시청  권
한 획득 (예: 서비스  가입  또는  콘텐츠  구매 ) 방법에  대한  사항은  본 규격의  범위에  포함
되지  않으며 , CA Token 은 콘텐츠  구매를  증명할  수 있는  토큰의  역할을  한다 . 
 
PlayerSVM
DecoderIPTV Main 
ServerSMS
1. 재생요청
3. CA Token
COPP2. CA Token 요청
CA Token
영역
 
(그림  3-3) CA Token 영역  Flow Diagram 
 
CA Token 은 발급 (전송 )은 다음  두 단계로  진행되며 , Privacy 보호를  위하여  중요  정보는  
암호화된  형태로  전송된다 . 
• CA Token 발급  요청 : CA Token 발급에  필요한  Data를 수집  하여  송신자 ((IPTV Main 
Server) 로부터  수신  받는다 .  
• CA Token 생성  및 전송 : 단말의  Certificate 를 확인하고  올바른  인증서이면  CA 
Token 을 3.5.1 절의  CA Token Format 에 맞게  생성한  후, 안전하게  Player 에게  
전달한다  
 
3.5.1.  Content Access Token (CA Token) 
COPP Client 에서  CA Token 은 Server 에 사용자의  콘텐츠  시청  권한을  증명하기  위해  사
용되며 , 이러한  역할을  수행하기  위하여  CA Token 은 콘텐츠  구매  정보 , 유효기간  및 
SW Download Server 정보 , 그리고  CAS 정보를  포함하고  있으며  또한  전자서명을  사용해
서 제 3자가  CA Token 내용을  위조 /변조하는  것을  막도록  하고  있다 . CA Token life cycle 
및 message format 은 다음과  같다 .  
 정보통신단체표준 
TTAK.KO-08.0023 ２０1) CA Token Life Cycle 
COPP Client 에서  CA Token 은 사용자가  정상적으로  콘텐츠  시청  권한을  획득했다는  기
록이며 , Server 는 CA Token 을 사용해서  인증을  수행하게  된다 . CA Token 의 life cycle 은 다
음의  4단계로  이루어  진다 .  
• 생성 : 어떤  콘텐츠에  대한  시청  권한을  획득했으며 , 어떤  Server 와 접속을  해야  하는
지에  대한  정보를  포함하여  SMS Server 에서  생성한다 . 
• 전송  및 저장 : CA Token 의 요청이  정당한  IPTV 수신  단말로부터의  요청인지  확인  후, 
정당한  IPTV 수신  단말일  경우  CA Token 을 안전한  방법으로  전송하고  COPP Client
는 이 값을  안전하게  저장한다 . 
• 사용 : CAS S/W 를 다운받거나 , EMM 을 요청하는  단계에서  콘텐츠  시청  권한을  증명
하기  위해  CA Token 을 사용한다 .  
• 삭제 : CA Token 관리  정책을  준수하여  삭제한다 . 
 
2) CA Token Format 
CA Token 이 포함하는  데이터의  종류는  다음의  것들이  있다 .  
• 콘텐츠  사용  권한 : 사용자가  콘텐츠에  대한  시청  권한을  획득했다는  것을  확인할  수 
있는  정보와  콘텐츠  사용  기간  정보를  포함한다 . 이 정보는  iCAS 운영  정책에  따라  
임의 (예 : 서비스  사용  권한 )로 사용할  수 있는  정보이다  
• Device Binding: CA Token 을 요청하지  않은  IPTV 수신  단말이  CA Token 을 사용하는  
것을  막기  위해서  CA Token 에 IPTV 수신  단말의  ID 정보를  포함하는  방법을  통해  
Device binding 시킨다 .  
• CA Token 사용을  위한  부가  정보 : 최신  버전의  CAS S/W 를 받기  위한  SW Download 
Server 정보 , 그리고  EMM 을 받기  위한  CAS Server 정보 , 그리고  CA Token 의 폐기  여
부를  체크하기  위한  CTRL Server 정보를  포함  한다 .   
CA Token 의 Format 은 (그림  3-4)와 같다 .  정보통신단체표준 
TTAK.KO-08.0023 ２１(msb) (lsb)
             bit
byte76543210
0
12
3
4
…
11
12…43
44
4546
47
48…
55
56…
63
646566
67
68…
131
132133
134
135136
…
O1
…
O2
…
O3
…
O4
O4+1
O4+2
O4+3O4+4
…Version (1bytes)
CA Token Length (3bytes)
Expire Time (8bytes)
CTRL Issuer ID (4bytes)
Number of Content ID (= n) (4bytes)CA Token ID (8bytes)
Device ID (32bytes)
CA Token Issuer ID (4bytes)
Issuer Time (8bytes)
Signature(z bytes)
※ O1 = (n*4) + 132, O2 = O1 + w  , O3 = O2  + x , O4 =O3+ yReserved (64bytes)
(CID 1||CID 2||…||CID N)  (n *4 bytes) 
 CTRL Server Info ( w bytes)
SW Download Server Info ( x bytes)
 CAS Server Info ( y bytes)
Signature Algorithm (1byte)
Signature Length (= z) (3bytes)
 
(그림  3-4) CA Token Format 
 
• Version(1byte): CA Token 의 버전  
• CA Token Length (4bytes): Version 과 CA Token Type, CA Token 콘텐츠  Type 을 제외한  정보통신단체표준 
TTAK.KO-08.0023 ２２CA Token 의 전체  길이  
• CA Token ID (8bytes): 콘텐츠의  시청  권한  구분을  위한  transactionID. 즉 CA Token 의 
고유  번호  및 그룹  ID 
• Device ID (32bytes): CA Token 을 발급  요청한  Device ID 
• CA Token Issuer ID (4bytes): CA Token 을 발급한  SMS 의 ID 
• Issure_Time (8bytes): CA Token 의 발급  날짜  UTC 시간을  기준으로  사용 .  
• Expire_Time (8bytes): CA Token 의 유효  시각  UTC 시간을  기준으로  사용 . 
• CTRL Issuer ID(4bytes): CTRL Block 발급에  대한  transaction ID. 
• Reserved (64bytes): 나중의  정의를  위해  남겨둔  영역  
• Number of 콘텐츠  ID (4 bytes): 콘텐츠  ID의 개수 , 옵션  항목  
 값이  0일 경우  콘텐츠  ID항목은  생략한다 . 
• (CID 1 || CID 2 || … || CID N) (N * 4bytes): 콘텐츠  ID (CID) 의 목록  
 CID의 경우  각 서비스  사업자들이  정의한  형태를  따르며 , 사전에  정의된  CID의 포멧에  
따라  CA Token 을 이용한  서비스  적용  방법이  달라질  수 있다 .4  
• CTRL Server Info (w bytes): CTRL 에 Server 에 관한  정보 . 
• SW Download Server Info (x  bytes): SW Download Server 에 관한  정보  
• CAS Server Info (y bytes): CAS Server 에 관한  정보  
• Signature Algorithm (1byte): CA Token 의 서명에  사용되는  Algorithm 
 0x00: RSA(PKCS #1 :RSA Cryptography Standard” Version 2.1) 
 0x01: EC-DSA 
 Others are reserved. 
• Signature Length (3bytes): CA Token 의 Signature Algorithm 에 따른  Signature 의 길이  
• Signature (z bytes): CA Token 의 모든  field들에  대한  서버의  서명값  
 
3) Server Info 표현  방법  
CA Token 에는  3가지  종류의  Server Info 가 사용된다 . 각 서버의  정보  표현  방법으로는  IP 
Address / Port number 를 가지고  표현하는  방법과  URL 정보를  가지고  표현하는  방법  2가
지를  지원한다 .  
 
IP Address / Port Number 를 사용한  ServerInfo 표현  방법은  (그림  3-5)와 같다 .  
 
                                                      
4 예를  들어  기본  콘텐츠들은  동일한  CAS S/W 를 사용하고 , 기본  콘텐츠  ID의 msb가 0으로  
prefix 되어  있다고  가정하자 . 이 때 기본  콘텐츠들을  위한  CA Token 의 Number of 콘텐츠  ID는 1, 
CID는 (0x…xx) 2로 표현할  수 있다 . 정보통신단체표준 
TTAK.KO-08.0023 ２３(msb) (lsb)
             bit
byte76543210
0
1
23456789
1011Address Type (1byte)
Length (3bytes)
CTRL / SW Download / CAS Server Server Port (4bytes)CTRL / SW Download / CAS Server Server IP Address (4bytes)
 
(그림  3-5) CTRL/SW Download/CAS Server Info base IP.Port 
 
• Address Type (1byte): Address 를 나타내는  형태 . IP Address, Port 또는  URL 로 표현 .  
 0x00 : IP Address, Port number   
 0x01 : URL 
• Length (3bytes): Server IP Address, Port number 의 길이   
• CTRL / SW Download / CAS Server Address (4bytes): CTRL / SW Download / CAS Server 의 
IP Address (IPv4 에서  표현  하는  Address 표현  방식 )  
• CTRL / SW Download / CAS Server Port (4 bytes): CTRL / SW Download / CAS Server 의 Port 
Number 
 
URL 을 사용한  Server Info 표현  방법은  (그림  3-6)과 같다 .  
(msb) (lsb)
             bit
byte76543210
0
12
3
4
…Address Type (1byte)
Length (3bytes)
CTRL / SW Download / CAS Server Server URL(z bytes)
 
(그림  3-6) CTRL / SW Download / CAS Server Info base URL 
 
• Address Type(1byte): Address 를 나타내는  형태 . IP Address, Port 또는  URL 로 표현 .  
 0x00 : IP Address , Port number 
 0x01 : URL  
• Length (3bytes): Server 의 URL 길이  
• CTRL / SW Download / CAS Server URL (N by tes): CTRL / SW Download / CAS Server URL 정보통신단체표준 
TTAK.KO-08.0023 ２４ 
3.5.2.  CA Token Revocation List (CTRL) 
CA Token 발급  후, 사용자의  콘텐츠  시청  권한  변경  등의  이유로  CA Token 유효기간  
전체  CA Token 사용을  정지시켜야  하는  경우가  있을  수 있다 . 이를  위해  CA Token 의 폐
기 여부를  확인하기  위한  CA Token Revocation List 를 정의한다 . CTRL life cycle 및 message 
format 은 다음과  같다  
1) CTRL Life Cycle 
CTRL 은 CA Token 발급  후, 사용자의  콘텐츠  시청  권한  변경  등의  이유로  CA Token 유
효기간  전체  CA Token 사용을  정지시켜야  할 경우  사용된다 .  
 
• 생성 : Revoked 된 CA Token 이 발생하면  CTRL Server 는 Revoke 된 CA Token ID 를 모
아 두었다가  주기적으로  CTRL 을 생성한다 .  
• 전송  및 저장 : CA Token 을 검사하고자  하는  자는  CA Token 내의  CTRLServerInfo 값
을 사용해서  CTRL Server 로부터  CTRL 을 다운받을  수 있다 . CTRL 을 다운받은  후, 
CTRL 의 전사서명  검사를  수행하고 , 맞는  경우  저장한다 .  
• 사용 : CA Token ID 가 저장된  CTRL 에 포함되었는지  여부에  대한  검사를  통해  CA 
Token 이 폐기된  것인지를  확인할  수 있다 . 단, 이 과정에서  CTRL 체크하는  시점의  
현 시각이  CTRL 의 Issuer Time 과 Next Issure Time 사이의  범위에  있는지  확인을  하고 , 
만약에  Issuer Time 과 Next Issure Time 사이에  있지  않다면  CTRL Server 에서  새로운  
CTRL 을 download 한 후에  CA Token ID 가 CTRL 에 포함되었는지에  대한  검사를  수행
한다 .   
 
2) CTRL Format 
CTRL 은 Revoked CA Token ID 의 List 로 이루어  진다 . CTRL 에는  다음  번에  접속  하여  
새로운  CTRL 으로  업데이트  해야  하는  시간을  표시  하고  있으며  이 시간을  체크하여  다
음 번 접속  시간이  지났으면  새로운  CTRL 을 다운로드  하도록  하는  필드를  포함하고  있
다.  정보통신단체표준 
TTAK.KO-08.0023 ２５ (msb) (lsb)
             bit 76543210
0123
4
5678
…
1516…23
24
25262728
…
O1
O1 + 1O1 + 2
O1 + 3
O1 + 4
…
※ O1= (n*8) + 28CTRL Length(3bytes)
CTRL Issuer ID(4bytes)
CTRL Issue Date(8bytes)
CTRL Next Issue Date(8bytes)
Number of Revoked CA Token ID (= n) (4bytes)
Signature (z bytes)(Revoked CA Token ID1|| … ||Revoked CA Token IDn) (n* 8 bytes)
Signature Algorithm(1byte)
Signature Length (= z) (3bytes)Version(1byte)
 
(그림  3-7) CTRL Format 
 
• Version Number field (1byte): CTRL 의 version 
• CTRL Total Length (3bytes): CTRL version 을 제외한  CTRL 의 전체  길이  
• CTRL Issuer ID (4bytes): CTRL Block 발급에  대한  transaction ID. 
• CTRL Issue Date (8bytes): CTRL 발급  시간 . 
• CTRL Next Issuer Date (8bytes): CTRL 을 다시  받아야  하는  시간 . 
• Number of Revoked CA Token ID (4bytes) : Revoked CA Token ID 의 수 
• (Revoked CA Token ID 1|| … || Revoked CA Toke n ID N) (N * 8bytes): Revoked CA Token ID
의 목록 . Number of Revoked CA Token ID 만큼  Revoked CA Token ID 를 표현 . Revoked CA 
Token ID1 는 첫 번째  Revoked CA Token ID, Revoked CA Token ID N 은 N번째  Revoked 
ID   
• Reserved field (16bytes): 확장을  위한  field 
• Signature Algorithm (1byte): signature Algorithm . 
 RSA : 0x00 (PKCS #1 :RSA Cryptography Standard” Version 2.1) 
 ECDSA: 0x01 ( FIPS 186-2 : Digital Signature Standard (DSS) ) 
 Others are reserved 정보통신단체표준 
TTAK.KO-08.0023 ２６• Signature Length(3bytes) : Signature 의 길이  
• Signature (z bytes) : CTRL 의 모든  field들에  대한  서버의  서명값  
 
3) Optional CTRL Notificationt 
iCAS 운용  정책  변경에  따라  CTRL 을 업데이트  해야만  하는  상황을  처리하기  위해  
CTRL Notification 절차를  임의로  선택하여  적용  할 수 있다 . CTRL Notification 절차는  
별도로  정의될  수 있고 , 여기에서는  그 결과에  대해서만  정의한다 . CTRL Notification 
절차의  결과는  CTRL 체크  시각이  Issuer Time 과 Next Issuer Time 내에  위치하나  iCAS 
솔루션  제공  업체에서  정의한  CTRL Notification Message 가 iCAS COPP Client 로 전송될  때 
iCAS COPP Client 는 Issuer Time 과 관계  없이  CTRL Server 로부터  CTRL 을 다운로드  할 수 
있도록  하는  것이다 . 
 
3.5.3.  CA Token 전송  프로토콜  
Privacy 보호를  위하여  CA Token Request 메시지와  CA Token Response 메시지  모드  암호
화되어  전송된다 . CA Token 전송을  위해  사용되는  프로토콜  방식은  다음  두 가지로  구분
된다 . 
- SSL/TLS 
- 전자  봉투  
CA Token 전송을  위하여  언급된  두 가지  방식  중 하나를  선택하여  사용할  수 있다 . 
 
1) SSL/TLS 기반  CA Token 전송  방법  
COPP Client 는 콘텐츠에  대한  정보와  CA Token 생성을  요청하는  Device ID 를 보내면  
SMS Server 는 콘텐츠  정보에  따라서  CA Token 을 생성  하여  COPP Client 에게  송신하게  된
다. 이 프로토콜에서  일어나는  모든  Data의 송수신은  SSL/TLS 의 Protocol 로 안전하게  보
호 되어  송수신  된다 . 
 정보통신단체표준 
TTAK.KO-08.0023 ２７[CA Token 전송  프로토콜 ] 
COPP SMS 서버
CA Token_Response :{ CA Token }CA Token_Request:  (CID 1|| … ||CID N)|| Device ID
 
(그림  3-8) SSL/TLS Type of CA Token Transmission Protocol  
 
[CA Token Request Message] 
COPP Client 는 SMS Server 에 CA Token Request Message 를 보내어  CA Token 을 요청한다 . 
CA Token Request Message 에는  CA Token 의 요청하는  콘텐츠들의  목록과  요청한  Device ID
를 포함하게  된다 . 
 (msb) (lsb)
             bit
byte76543210
0
12
3
4
5
67
8
…
39
4041
42
43
44
……Command (2bytes)
Length (4bytes)
Devcie ID (32bytes)
Number of ContentID (4bytes)
(CID 1 || … || CID N) (N * 4bytes)Version (1byte)
Type (1byte)
 
(그림  3-9) CA Token Request Message (SSL/TLS Type) 
 
• Version (1byte) : 현재  Message 의 version. 현재  version 은 0x01. 
• Type (1byte) : Message 의 type. 
 0x00 : CA Token Message SSL/TLS Type  정보통신단체표준 
TTAK.KO-08.0023 ２８ 0x01 : CA Token Message Envelope Type  
 0x10 : CAS S/W Message Type 
 0x20 : CAS Message Type  
 Others are reserved. 
• Command(2bytes) : Message (Length filed 이후의  모든  filed) 의 형태를  정의  
 0x00 : CA Token Request Message 
 0x01 : CA Token Response Message 
• Length( 4bytes) : Message(Length filed 이후의  모든  filed) 의 전체  길이 .  
• Device ID(32bytes) : CA Token 을 요청  하는  Device ID 
• Number of 콘텐츠 ID(4bytes) : CA Token 을 요청하는  콘텐츠의  ID의 개수  
• (CID 1|| … || CID N) (N *4bytes) : CA Token 을 요청하는  콘텐츠  ID를 나타내며 , Number 
of 콘텐츠 ID의 수만큼  콘텐츠  ID를 기술  한다 . Contend ID1 은 첫 번째  콘텐츠  ID, 콘
텐츠  ID N 은 N 번째  콘텐츠  ID를 표현   
 
[CA Token Response Message] 
SMS Server 는 IPTV 수신  단말의  CA Token Request Message 에 대한  응답으로  CA Token 
Response Message 를 전송한다 . CA Token Response Message 에는  SMS Server 에서  생성된  CA 
Token 이 포함된다 .  
(msb) (lsb)
             bit
byte76543210
0
1
2
345
6
789
10
11
12…Type (1byte)Version (1byte)
Command (2bytes)
Length (4bytes)
Result (1byte)
CA Token ((Length - 4) bytes)Reason (3bytes)
 
(그림  3-10) CA Token Response Message (SSL/TLS Type)  
 
• Version (1byte): 현재  Message 의 version. 현재  version 은 0x01. 
• Type (1byte): Message 의 type. 
 0x00 : CA Token Message SSL/TLS Type 
 0x01 : CA Token Message Envelope Type 정보통신단체표준 
TTAK.KO-08.0023 ２９ 0x10 : CAS S/W Message Type 
 0x20 : CAS Message Type  
 Others are reserved. 
• Command(2bytes) : Message 의 형태를  정의  
 0x00 : CA Token Request Message 
 0x01 : CA Token Response Message 
 Others are reserved. 
• Length ( 4bytes) : Message 의 전체  길이 .  
• Result(1byte) : Request Message 의 처리  결과   
 0x00 : Success     
 0x01: Failure  
 others are reserved  
• Reason(3bytes):  
 0x00 : Result 가 Success 일 때    
 0x01 : Syntax Error : Invalid CA Token Request Message 
 Others are reserved 
• CA Token(z bytes): SMSServer 에서  생성된  CA Token 
 
2) 전자  봉투  방식을  이용한  CA Token 전송  방법  
다음과  같은  전자봉투를  사용해서  CA Token 을 보호한다 .  
 
[CA Token 전송  프로토콜 ] 
COPP SMS 서버
CA Token_Request : E{SMS_CERT_PUB,CEK} || E { CEK,( CID 1|| … ||CID N)|| Device ID || Nc}  || Cert
CA Token_Response :E{COPP_CERT_PUB,CEK}|| E{CEK,(Nc || CA Token)}
(그림  3-11) Challenge & Response Type of CA Token Transmission Protocol 
 
COPP Client 는 CA Token Request 메시지로  아래와  같은  데이터를  보낸다 . 
• COPP Client 에서  생성한  One-time Random Key (CEK: CID/CA Token Encryption Key) 를 
SMS Server 의 Public Key 로 암호화 .  
• 콘텐츠  ID와 Nc 그리고  Device ID 를 CEK 로 암호화  정보통신단체표준 
TTAK.KO-08.0023 ３０• COPP Client 의 Certificate5 
 
SMS 서버가  CA Token Response 메시지로  Nc와 CA Token 을 One-time Random Key (CEK)
로 암호화  하여  전송한다 . 이 때 사용되는  CEK 는 CA Token Request 에서  사용한  CEK 와는  
독립적으로  서버가  랜덤하게  생성한  키 값이다 . 
 
[CA Token Request Message] 
IPTV 수신  단말은  SMS Server 에 CA Token Request Message 를 보내어  CA Token 을 요청한
다. CA Token Request Message 에는  CA Token 의 요청하는  콘텐츠들의  목록과  요청한  Device 
ID과 IPTV 수신  단말의  인증서를  같이  전송하게  된다 . 
                                                      
5 COPP Client Certificate 는 IPTV 수신  단말의  인증서를  의미한다 . 정보통신단체표준 
TTAK.KO-08.0023 ３１(msb) (lsb)
             bit
byte76543210
0
123456789
101112…
O1
O1+1O1+2O1+3O1+4
…
O2
O2+1O2+2O2+3O2+4
…
O3
O3+1O3+2O3+3O3+4
…Signature Length (3bytes)
Signature (z byte)Encryption Algorithm (1byte)
SMS_CERT_PUB Enctypted Data Length (3bytes)
E{SMS_CERT_PUB, (CEK Type|| CEK)  }(x bytes)
Number of ContentID (4bytes)
※ O1 = w + 11, O2 = O1+ x + 8, O3 = O2+y+3Signature Algorithm (1byte)Version (1byte)
Type (1byte)
Command (2bytes)
Length (4bytes)
E{CEK, (CID1 || CID2 || … || CIDN )||Device ID || Nc}(y bytes)Cert Length (4bytes)
Cert(w byte)
 
(그림  3-12) CA Token Request Message (Digital Envelope Type) 
 
• Version (1byte): 현재  Message 의 version. 현재  version 은 0x01. 
• Type (1byte): Message 의 type. 
 0x00 : CA Token Message SSL/TLS Type 
 0x01 : CA Token Message Envelope Type 
 0x10 : CAS S/W Message Type 
 0x20 : CAS Message Type  
 Others are reserved. 
• Command (2bytes) : Message 의 형태를  정의  
 0x00 : CA Token Request Message 
 0x01 : CA Token Response Message 정보통신단체표준 
TTAK.KO-08.0023 ３２• Length (4bytes): Message (Length filed 이후의  모든  filed) 의 전체  길이 . 단, Version, Type, 
Length 를 제외  
• Cert_Length (4bytes): COPP Client Certificate 의 길이  
• Cert (w bytes): COPP 의 Certificate. 
• Encryption Algorithm(1byte): SMS Cert 의 Public Key 가 어떤  종류의  알고리즘에  사용되
는 키인지  표시함 .  
 0x00 : RSA-1024  
 Others are reserved. 
• SMS_CERT_PUB Encrypted Data Length (3 bytes): SMS 의 Public Key 로 암호화된  Data의 
길이  
• E{SMS_CERT_PUB, (CEK Type || CEK)} (x bytes): SMS 의 Public Key 로 암호화한  CEK 
 CEK Type (1 byte): CEK 가 어떤  종류의  알고리즘에  사용되는  키인지를  표시함 .  
 0x00 : AES-128  
 Others are reserved. 
 CEK : Nc 와 CID, DeviceID 를 암호화하는데  사용되는  키. 
• Number of 콘텐츠 ID (4bytes): 구매한  콘텐츠의  ID의 개수  
• E{CEK, (CID 1|| … || CID N)||DeviceID||Nc} (y bytes): 콘텐츠  ID들과  Device ID, Nc 를 
CEK로 암호화한  값. CEK Type 에서  정의된  암호  알고리즘을  사용하여  암호화한다 . 
 Nc (32 bytes): COPP Client 에서  생성한  Random Number  
 (CID 1|| … || CID N) (N*4bytes): CA Token 발급  요청하는  콘텐츠  Identifier. 
 DeivceID (32bytes): CA Token 을 발급  요청하는  Device의 Unique한 Identifier 
• Signature Algorithm (1byte): signature Algorithm . 
 RSA : 0x00 (PKCS #1 :RSA Cryptography Standard” Version 2.1) 
 ECDSA: 0x01 ( FIPS 186-2 : Digital Signature Standard (DSS) ) 
 Others are reserved 
• Signature Length (3bytes): Signature 의 길이  
• Signature (z bytes): CA Token Request Message 의 모든  field에 대한  서버의  서명값   
 
[CA Token Response Message] 
SMS 는 CA Token Request Message 에 대한  응답으로  CA Token Response Message 를 전송한
다. 이 메시지를  통해  CA Token 과 COPP Client 가 보낸  난수  값이  COPP Client 의 공개키로  
암호화되어  COPP Client 에게  전송된다 .  정보통신단체표준 
TTAK.KO-08.0023 ３３ (msb) (lsb)
             bit
byte76543210
0
123456
7
89
10111213
…
O1
…Encryption Algorithm (1byte)
※ O1 = y+15E{CEK, Nc||CA Token} (z bytes)Command (2bytes)Version (1byte)
Type (1byte)
Length (4bytes)
Result (1byte)
Reason (3bytes)
E(COPP_CERT_PUB, (CEK Type||CEK)} (y bytes)
 
(그림  3-13) CA Token Response Message (Digital Envelope Type) 
 
• Version (1byte): 현재  Message 의 version. 현재  version 은 0x01. 
• Type (1byte): Message 의 type. 
 0x00 : CA Token Message SSL/TLS Type 
 0x01 : CA Token Message Envelope Type 
 0x10 : CAS S/W Message Type 
 0x20 : CAS Message Type  
 Others are reserved. 
• Command (2bytes): Message 의 형태를  정의  
 0x00 : Request Message 
 0x01 : Response Message 
 Others are reserved. 
• Length (4bytes): Message(Length filed 이후의  모든  filed) 의 전체  길이  
• Result (1byte): Request Message 의 처리  결과   
 0x00 : Success     
 0x01: Failure  
 others are reserved  
• Reason (3bytes):  
 0x00 : Result 가 Success 일 때    
 0x01 : Syntax Error : Invalid CA Token Request Message 정보통신단체표준 
TTAK.KO-08.0023 ３４ Others are reserved  
• Encryption Algorithm (1byte): COPP Client Certificate 의 Public Key 가 어떤  종류의  알고
리즘에  사용되는  키인지  표시함 .  
 0x00 : RSA-1024  
 Others are reserved. 
• COPP_CERT_PUB Encrypted Data Length (3 bytes): COPP Client Certificate 의 Public Key 로 
암호화된  Data의 길이  
• E{COPP_CERT_PUB,(CEK Type || CEK)} (y bytes) : COPP Client Certificate 의 Public Key 로 
암호화한  CEK 
 CEK Type (1 byte) : CEK 가 어떤  종류의  알고리즘에  사용되는  키인지를  표시함 .  
 0x00 : AES-128  
 Others are reserved. 
 CEK : Nc 와 CA Token 을 암호화하는데  사용되는  키. 
• E{CEK, Nc||CA Token} (z bytes): Nc 와 CA Token 을 CEK 로 암호화한  값. CEK Type 에서  
정의된  암호  알고리즘을  사용하여  암호화한다 . 
 Nc (32 bytes) : CA Token 발급  요청  시 COPP Client 가 송신한  Random Number(Nc)  
 CA Token : Client Device 의 결제  정보 . 
 
 
3.6. SW-DN 영역  
COPP Client 는 CA Token 을 SW Download Server 에 전송하여  콘텐츠를  복호화  할 수 있는  
CAS S/W 를 수신한다 . 이 과정에서  CA Token 과 CAS S/W 의 보호가  이루어  진다 . IPTV 서
비스  시스템이  하나의  CAS S/W 사용만을  허락하고  해당  CA Token 이 IPTV 수신  단말에  
이미  존재한다면  CAS S/W 다운로드  과정은  생략된다 . 그러나  CA Token 을 새롭게  다운로
드 받거나  IPTV 서비스  시스템이  복수  개의  CAS S/W 사용을  허락하는  경우  CA Token 
관련  프로토콜  수행  후 CAS S/W 다운로드  과정을  수행한다 . 또한 , 하나의  CAS S/W 를 사
용하는  시스템이라고  하더라도  CAS S/W 의 업데이트를  위해  CA Token 초기화를  지원할  
수 있어야  한다 .6 
                                                      
6 CA Token 초기화를  위한  서버와  단말의  프로토콜은  서비스  사업자들에  의해  정의되며 , CA 
Token 초기화  대신  CAS 자체적으로  CAS S/W 업데이트를  수행할  수 있다 . 정보통신단체표준 
TTAK.KO-08.0023 ３５
PlayerSVM
DecoderSW Download Server
CASS/W기기 신뢰성 및 Content
사용권한 검사
COPPCAS S/W 다운로드또는 CAS S/W 사용 정보 전달
SW_DN
영역
 
(그림  3-14) SW-DN 영역  Block Diagram 
 
IPTV 수신  단말의  CAS S/W 요청에  대해  SW Download Server 는 다음의  2단계  검사를  거
친 후 제공된다 .  
• IPTV 수신  단말  신뢰성  검사 : IPTV 수신  단말에서  CAS S/W 의 해킹  가능성을  줄이고  
복제  기기의  사용을  억제와  정품  기기의  사용을  장려하기  위해  기기의  신뢰성을  검
사한다 . 복제  기기로  판명될  경우  CAS S/W 는 제공되지  않는다 .  
• 사용자  인증 : 콘텐츠  사용  권한이  있는지  여부를  검사한다 .  
 
검사를  통과한  경우  CAS S/W 는 암호화  된 상태로  player 로 전달되며 , player 는 복호화  
후 Secure Virtual Machine 에게  전달한다 .  
 
3.6.1.  Clone Detection Mechanism 
IPTV 수신  단말의  신뢰성  검사를  위해서  IPTV 수산  단말에는  SW Download Server 가 생
성하는  동적  ID (dynamic ID) 기반의  검사  방법을  사용한다 .  
• 이 동적  ID는 매번  CAS S/W 를 요청할  때마다  새로운  임의의  값으로  변경되는  값으
로, IPTV 수신  단말의  처음  동적  ID는 Device ID 와 같도록  설정해  둔다 . 
• IPTV 수신  단말은  SW Download Server 에 접속할  때마다  Device ID 와 동적  ID 값을  
전달한다 . Server 는 동적  ID 값이  자신이  가지고  있는  것과  같을  경우  문제가  없다고  
판단한다 .  
• Server 는 난수적으로  새로운  동적  ID 를 생성한  후, IPTV 수신  단말에게  전달하고  
Server 내의  동적  ID 값을  update 한다 .  정보통신단체표준 
TTAK.KO-08.0023 ３６ 
IPTV 수신  단말의  복제가  일어날  경우  다음과  같은  절차를  통해  복제  기기를  탐지할  
수 있다 .  
• IPTV 수신  단말이  복제  될 경우 , 정품  기기와  복제  기기는  둘 다 동일한  device ID, 
동적  ID를 가지게  된다 . 이 때 정품  기기 (또는  복제  기기 )가 CAS S/W 를 요청할  경우 , 
SW Download Server 는 해당  기기의  동적  ID를 검사하여  확인하고 , 새로운  동적  ID를 
만들어  Server 에 저장하고  이를  해당  IPTV 수신  단말에게  배포한다 .  
• 이 후 복제  기기가  CAS S/W 를 요청하려  할 때 복제  기기는  이전  동적  ID를 가지고  
있게  되므로 , SW Download Server 를 이를  확인하고  기기의  CAS S/W 요청을  거부하게  
된다 .  
 
전체  동작은  (그림  3-15 )에서  자세히  보여준다 . 동적  ID 기반  검사는  IPTV 수신  단말이  
SW Download Server 로부터  CAS S/W 다운로드  시도  시 항상  수행되지만 , 하나의  CAS S/W
만을  사용하는  시스템의  경우  CAS S/W 다운로드는  최초  서비스  가입  이후  거의  발생하
지 않는다 . 따라서 , 일정  주기  동안  CA Token 을 새롭게  다운로드  받지  않는  경우  IPTV 
수신  단말의  Clone Detection 과정이  수행되지  않는다 . 이러한  단점을  보완하기  위하여  특
정 기간  동안  동적  ID가 업데이트  되지  않는  경우  IPTV 수신  단말이  CA Token 을 새롭게  
다운로드  받지  않더라도  주기적으로  CAS S/W 다운로드  과정을  수행하도록  설정되어야  
한다 . 이 때, 동적  ID의 업데이트  주기는  사업자의  선택에  따라  설정될  수 있다 . 
Clone Detection 과정  수행  중 복제  기기가  동적  ID 업데이트  한다면  정당한  IPTV 수신
단말이  서비스를  거부당  할 수 있다 . 정당한  IPTV 수신  단말이  복제기기에  의해  사용이  
차단된  것이  확인되면  해당  Device ID 를 폐지 (revoke) 하여야  한다 . 
 
3.6.2.  CAS S/W 전송  프로토콜  및 Message 
COPP Client 가 SW Download Server 에게  CAS S/W 를 요청하는  프로토콜을  정의한다 . 
COPP Client 의 요청을  받은  SW Download Server 는 Clone Detection 검사  및 CA Token 인
증을  수행하여  문제가  없는  경우에만  CAS S/W 를client 에게  전송한다 . 프로토콜과  메시지
의 간략한  표현를  위해  동적  ID (dynamic ID) 를 DynID 로 표기한다 . 
 
[CAS S/W 전송  프로토콜 ] 
효율성  관점에서  CAS S/W 전송  프로토콜은  다음  2개의  프로토콜을  parallel 하게  진행하
는 방식으로  구성된다 .  
• Clone Detection Protocol: 3.6.1 절에서  정의한  Clone detection 을 위한  프로토콜이다 .  
 Request Message: Client 가 DeviceID 와 DynID 값을  보낸다 .  
 Response Message: Server 를 DynID 를 검사하고 , 맞을  경우  NewDynID 값을  보낸다 .  
• SW Download Protocol  정보통신단체표준 
TTAK.KO-08.0023 ３７ Request Message: CA Token 과 현재  Device 가 가지고  있는  CAS S/W 들의  ID 값을  보낸다 .  
 Response Message: SW Download Server 는 CA Token 이 유효할  경우 , CA Token 에 포함된  콘텐
츠 들이  COPP Client 가 보내온  CAS S/W ID 들 중의  하나로써  재생할  수 있는지를  검사한다 . 가
능하다면 , 사용할  수 있는  CAS S/W ID 값 만을  전달하고 , 그렇지  않은  경우  새로운  CAS S/W 를 
전송한다 . (CA Token 유효성  검사는  CA Token 의 폐기여부를  검사하는  과정을  포함한다 .) 
 
상기  2가지  프로토콜이  결합된  형태의  CAS S/W 전송  프로토콜을  요약하면  (그림  3-15)
과 같다 .  
[참고 ] CAS S/W Request Message 와 Response Message 는 모두  SSL/TLS Protocol 을 사용하
여 보호한다 .  
 
COPP SW Download 서버
Request: {DeviceID || DynID ||(CAS SW ID1|| …|| CAS SW ID N)||  CA Token }
Response :{ DeviceID || newDynID || (CAS SW |CAS SW ID) }
 
(그림  3-15) CAS S/W Request & Response 
 
 
[CAS S/W Request Message] 
이 메시지는  Clone Detection 을 위한  COPP Client 의 DeviceID 와 DynID 값, 그리고  콘텐
츠 사용  권한  검사를  위한  CA Token, 그리고  CAS S/W 재전송을  막기  위한  COPP Client
가 가지고  있는  SW ID 값들  포함한다 . 보안성을  위하여  이 메시지는  SSL/TLS Protocol 을 
사용하여  보호된다 .  
 정보통신단체표준 
TTAK.KO-08.0023 ３８ (msb) (lsb)
             bit
byte76543210
0
12345678
…3940…717273747576…
O1
O1+1O1+2O1+3O1+4
…Type (1byte)
Number of CAS SW (= n) (4bytes)Version (1byte)
Command (2bytes)
Length (4bytes)
DeviceID (32bytes)
(CAS SW ID1 || … || CAS SW IDn) (n * 4bytes)
CA Token (y bytes)CA Token Length (= y) (4bytes)DynID (32bytes)
※ O1 = (n*4) + 75
 
 
(그림  3-16) CAS S/W Request Message 
 
• Version (1byte): 현재  Message 의 version. 현재  version 은 0x01. 
• Type (1byte): Message 의 type. 
 0x00 : CA Token Message Type 
 0x01 : CAS S/W Message Type 
 0x02 : CAS Message Type  
 Others are reserved. 
• Command (2bytes): Message 의 형태를  정의  
 0x00 : Request Message 
 0x01 : CAS S/W Response Message 
 0x02 : CAS S/W ID Response Message 
 Others are reserved. 
• Length (4bytes): Message (Length filed 이후의  모든  filed) 의 전체  길이 . 
• Device ID (32bytes): CAS S/W 를 요청하는  Device ID  정보통신단체표준 
TTAK.KO-08.0023 ３９• DynID (32bytes): IPTV 수신  단말이  저장하는  동적  ID로 IPTV 수신  단말의  신뢰성  검
사를  위해  사용  
• Number of CAS S/W (4bytes): SVM 에서  Caching 되어진  CAS S/W 의 목록  들의  개수  
• CAS S/W ID (N *4bytes): SVM 에서  Caching 된 CAS S/W ID 를 나타내며 , 현재  SVM 에
서 Caching 된 모든  CAS S/W ID List 를 기술  한다 . 만약  현재  SVM 에서  Caching 된 
CAS S/W 가 없다면  CAS S/W ID 를 표현  하지  않는다 . CAS S/W ID1 는 SVM 에서  
Caching 된 CAS S/W ID List 의 첫 번째  CAS S/W ID, CAS S/W IDn 은 Caching 된 CAS 
S/W ID List 의 N 번째  CAS S/W ID 를 나타낸다 . 
• CA Token Length (4bytes): CA Token 의 길이 . 
• CA Token (y bytes): CA Token 의 signature 까지  포함한  모든  내용 . 
 
[CAS S/W Response Message] 
이 메시지는  Clone Detection protocol 을 위한  새로운  DynID 값인  NewDynID 값과 , COPP 
Client가 사용할  CAS S/W 정보를  포함한다 . 보안성을  위하여  이 메시지는  SSL/TLS 
Protocol 을 사용하여  보호된다 .  
 
 (msb) (lsb)
             bit 76543210
0123456789
101112…4344…75767778798081828384… CAS SW PackageVersion(1byte)
Type(1byte)
Command (2bytes)
Length (4bytes)
Result(1byte)
CAS SW ID (4bytes)newDynID (32bytes)
Response Type (1byte)Reason(3bytes)
DeviceID (32bytes)
Response Length (3bytes)
 
(그림  3-17) CAS S/W Response Message 
 정보통신단체표준 
TTAK.KO-08.0023 ４０• Version (1byte): 현재  Message 의 version. 현재  version 은 0x01. 
• Type (1byte): Message 의 type. 
 0x00 : CA Token Message Type 
 0x01 : CAS S/W Message Type 
 0x02 : CAS Message Type  
 Others are reserved. 
• Command(2bytes) : Message 의 형태를  정의  
 0x00 : Request Message 
 0x01 : CAS S/W Response Message 
 0x02 : CAS S/W ID Response Message 
 Others are reserved. 
• Length (4bytes): Message(Length filed 이후의  모든  filed) 의 전체  길이 .  
• Result (1byte): Request Message 의 처리  결과   
 0x00 : Success     
 0x01: Failure  
 others are reserved  
• Reason (3bytes):  
 0x00 : Result 가 Success 일 때    
 0x01 : Syntax Error : Invalid CA Token Request Message 
 Others are reserved  
• Device ID (32bytes): CAS S/W 를 요청하는  Device ID  
• New Dynamic ID (32bytes): IPTV 수신  단말  신뢰성  검사를  위해  SW Download Server 가 
임의로  만들어서  해당  IPTV 수신  단말에  전송하는  동적  ID. 
• Response Type (1byte): CAS S/W ID 로 응답  또는  CAS S/W 로 응답  할 것 인지  응답  
Type을 표현  
 0x00 : CAS S/W ID 
 0x01 : CAS S/W ID and CAS S/W 
• Response Length (3bytes): Response(CAS S/W ID or CAS S/W) 의 길이    
• CAS S/W ID (4bytes): 요청한  CAS S/W List 에 요청한  콘텐츠에  대한  CAS S/W 가 존재  
하면  CAS S/W ID 를 표시하고  CAS S/W List 에 존재하지  않으면  콘텐츠에  맞는  새로운  
CAS S/W ID 를 표시   
• CAS S/W (z bytes): 요청한  CAS S/W List 에 요청한  콘텐츠에  대한  CAS S/W 가 존재  하
지 않으면  요청한  CAS S/W List 에 존재  하지  않는  CAS S/W 를 전송  하고 , CAS S/W 
List안에  존재  하면  어떠한  내용도  포함  하지  않음 . 
 
[보호  방법 ] 
IPTV 수신  단말과  SW Download Server 사이의  모든  통신은  SSL/TLS 를 사용해서  보호
한다 .  정보통신단체표준 
TTAK.KO-08.0023 ４１ 
보안성  측면에서  SSL/TLS 설정은  하기  방법을  따른다 .  
• 인증  방법 : Mutual Authentication Mode  
• Client와 Server 가 모두  인증서를  가지고  있어야  함.  
• SW Download Server 는 반드시  CertificateRequest 메시지를  보내도록  설정   
• Mandatory SSL/TLS CipherSuite: TLS_RSA_WITH_AES_128_CBC_SHA, 
                            TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 
그 외의  CipherSuite 도 사용은  가능하나  128-bit 이하의  비트를  갖는  CipherSuite 는 사용
하지  말아야  한다 .  
 
3.7. CAS 영역  
CAS 영역은  CAS S/W 가 실행되어  보호된  콘텐츠를  재생하는  단계이다 . 이 과정은  본 
규격의  iCAS 상에서  동작하는  CAS에 따라  다르게  설계  가능하며 , 그 세부적인  사항들은  
실행되는  CAS 규격을  따른다 . 본 규격에서는  CAS 영역에  대한  세부  규격은  정의하지  
않는다 . 부록  A에서는  본 규격에서  정의하는  iCAS 구조에  적용  가능한  참고  CAS 기술
을 제공한다 . 
 
3.8. Secure VM  
본 규격의  iCAS 시스템은  TV/Set-top 등의  단말에  CAS 시스템이  필요로  하는  보안  
모듈을  제공하기  위하여  SVM 을 사용한다 . SVM 을 사용함으로써 , 실행코드  수준에서  
이식성  있는  CAS 모듈을  제작할  수 있다 . SVM 은 S/W 혹은  별도  H/W로 구현될  수 있다 .  
 
단말은  UI 처리 , 콘텐츠  수신  및 표현과  같은  Player 부분과  CAS 처리를  위한  SVM 부
분, CAS S/W 의 수신을  담당하는  COPP Client 부분으로  나눌  수 있고 , 각각의  경계  및 역
할은  다음  표와  같다 .7 
모듈  역할  
Player User Input, GUI 처리  
콘텐츠  검색  및 콘텐츠  버퍼  관리 , 컨텐츠  재생  
입출력  제어  
- audio/video 입출력  
- network 입출력  
SVM에 Event 전송  
                                                      
7 Player 의 역할은  향후  IPTV 미들웨어  표준  규격을  기반으로  Player 와 미들웨어  간의  상호  연동  
및 제어  권한  관리  방법  등을  검토하여  수정 /추가된  사항이  본 규격에  반영되어야  한다 . 정보통신단체표준 
TTAK.KO-08.0023 ４２- Channel/Content 변경  관련  
- Descramble 관련  
SVM CAS S/W 실행  
- CAS key management 알고리즘  실행  (EMM/ECM 등) 
- 콘텐츠  descrambling 
- renewability 지원  
COPP Client CAS S/W 의 다운로드  및 로딩  
- CA Token 을 이용한  Single-Sign-On 인증  및 CAS S/W 다운로드  
- CAS S/W 및 Policy 검증  및 SVM 에 적재  
- SVM 에 Event 전송  (시작 /종료 ) 
<표 3-1> Player 와 SVM 의 역할  
 
SVM은 단말  platform 에 상관  없이  downloadable, renewability 지원  가능한  CAS 시스템을  
제공하기  위한  가상의  실행환경 (run-time environment) 이다 . 
 
3.8.1.  Secure VM 기능  및 요구사항  
여러  가지  공격에  대응하여  콘텐츠와  서비스를  안전하게  보호하기  위해서  SVM 은 다음
의 보안  요구사항을  만족해야만  한다 . 
• CAS S/W 인증 : SVM 에 적재되어  실행되는  모든  CAS S/W 는 믿을  수 있는  기관이  인
증한  코드이어야  한다 . 
• 실행환경  인증 : CAS S/W 는 실행되는  SVM 이 믿을  수 있는  실행환경임을  확인하고  
실행될  수 있어야  한다 . 
• CPU 독립성 : SVM에 적재되어  실행되는  CAS S/W 는 단말  CPU의 종류 (예: RISC 계열  
– ARM, MIPS, CISC 계열  – INTEL, AMD 등)에 관계없이  동일한  이미지 (바이너리 )로 
컴파일되고  실행되어야  한다 . 
• OS 독립성 : SVM 에 적재되어  실행되는  CAS S/W 는 단말  OS의 종류 (예 : MS Windows 
계열  OS, Linux/UNIX, RTOS – vxWorks, UCOS 등)에 관계없이  동일한  이미지 (바이너
리)로 컴파일되고  실행되어야  한다 . 
• CAS S/W 의 행동 : CAS S/W 가 실행시간에  준수해야  하는  규칙을  정하고 , 정해진  규칙
에 위배되는  System call 호출이  실행되는지  여부를  실행시간에  검사해야  한다 . 이로
써, 악의적인  행동이나  의도되지  않은  오류를  검출하고  CAS S/W 의 실행을  제어할  
수 있어야  한다 . 
• CAS S/W 의 보호 : CAS S/W 코드는  서버로부터  전송되어  SVM 에 적재될  때까지  그 
내용이  허락되지  않은  IPTV 수신  단말  또는  사용자에게  노출되면  안 된다 . 또한 , 
CAS S/W 코드가  SVM 메모리에  적재될  때 평문으로  노출되는  부분을  최소화  해야  
한다 . 
• 키 보호 : CAS 및 COPP 관련된  암호키는  평문형태로  외부에  전송되거나  CAS S/W 에
게 전달되면  안 된다 . 정보통신단체표준 
TTAK.KO-08.0023 ４３• System call 안전성 : CAS S/W 가 실행시간에  호출하는  System call 은 입력되는  메모리  
주소와  관련하여 , buffer overflow 에 취약하지  않아야  한다 . 
• COPP 연동 : COPP Client 에서  CAS S/W 를 SVM 에 입력할  때, COPP Client 는 CAS S/W
를 외부로  전송하거나  해당  Policy 에 위배되도록  저장하면  안 된다 . 
• Player 연동  : SVM 과 연결되는  Player 는 발생되는  Event 를 모두  SVM 에 충실히  전달
해야  한다 . 임의로  Event 전송을  생략하거나  매개변수  값을  변경해서는  안 된다 . 
• CA Token 연동 : System call 을 통해  COPP Client 에서  관리하는  CA Token 에 접근하여  
값을  읽을  수 있으나 , CA Token 의 내용을  변경할  수는  없어야  한다 . 
 
3.8.2.  Secure VM 구조  
3.8.2.1.  Basic Components  
SVM은 가상의  컴퓨터  시스템으로써 , 다음과  같은  일반적인  구성요소를  가진다 . 
• CPU(Interpreter):  입력된  명령어  코드를  읽고 , 실행한다 . 
• 레지스터 : 32-bit 길이의  32개의  범용  레지스터와  PC (Program Counter) 로 구성되어  있
고, 명령어가  실행될  때 사용된다 . 
• SVM 메모리 : SVM 내부에  존재하며 , 명령어  코드 , stack 등이  위치한다 . 
• System call:  SVM 이 제공하는  함수이다 . 명령어  코드로  구현되기에  성능이  떨어지는  
기능이나  SVM 외부와의  인터페이스로  활용된다 . 세부적인  사항은  부록  D에서  제공
된다 . 
• Event handler:  Player 는 발생하는  다양한  상태를  Event 로 SVM 에 입력한다 . 입력되는  
Event에 따라 , 상황에  맞는  명령어가  실행하는  부분이  Event handler 이다 . 
• Descrambler: CAS S/W 가 정의하는  descramble 알고리즘이  실행되는  코드이다 . Event 
handler 의 일부로  구성된다 . 
• Policy Monitor: CAS S/W 가 함께  배포되는  Policy 에 위배되지  않는지  항상  monitoring
하는  모듈이다 .  
 
다음은  SVM 과 연동되는  Player/COPP Client 부분의  구성요소이다 . 
• Decode Buffer:  Descrambler 가 접근하는  버퍼이며 , decoder 로 넘어가기  직전의  데이터이
다. 
• Event Generator:  SVM이 수신하여  처리할  Event 를 생성시킨다 . 관련  파라미터와  함께  
SVM에 전달된다 . 
• S/W Downloader:  COPP Client 중, 콘텐츠에  관련된  CAS S/W 를 다운로드하고 , SVM 에 
이를  적재시키는  역할을  수행한다 . 
• CA Token:  COPP Client 가 가지고  있는  CA Token 저장소이며 , SVM 은 CAS S/W 의 요청
이 있을  때 이를  읽어  넘겨준다 . 
 
(그림 3-18)은  Player, COPP Client 와 SVM 이 연결된  전체적인  모습을  나타낸다 . SVM 은 
내부적으로  Multi-Thread 기능과  Call-back 등록 /호출  기능을  지원할  수 있어야  한다 . 정보통신단체표준 
TTAK.KO-08.0023 ４４Player
SVMEvent Generator S/W DownloaderUser Interaction Play, Stop, Channel Change, …
Interpreter
System CallsMemory
Registers
Policy MonitorEvent Handler
DescramblerDecoder Buffer
CAT
S/W initialize Events with
ParametersRead CAT
Decrypt scrambled
Content StreamCOPP Player
SVMEvent Generator S/W DownloaderUser Interaction Play, Stop, Channel Change, …
Interpreter
System CallsMemory
Registers
Policy MonitorEvent Handler
DescramblerDecoder Buffer
CA Token
S/W initialize Events with
ParametersRead CAT
Decrypt scrambled
Content StreamCOPP
 
(그림  3-18) SVM Architecture 
 
 
3.8.2.2.  CAS S/W Policy  
CAS S/W 와 Policy 의 의미와  기본적인  역할에  대하여  간략히  기술한다 .  
[CAS S/W 와 COPP Client] 
• CAS S/W 는 CAS 알고리즘을  구현한  실행코드이며 , SVM 에 적재되어  실행되는  명령
어 코드의  집합이다 . 
• COPP Client 는 콘텐츠의  해당  CAS S/W 를 다운로드하고 , 이를  SVM 메모리에  적재함
으로써 , CAS/DRM 기능을  SVM 상에서  수행시킨다 . 
 
[CAS S/W 의 life-time] 
• CAS S/W 가 SVM 에 적재되어  남아있는  시간은  해당  Policy 에 의해  결정된다 . 예를  들
어, CAS S/W 가 VOD 콘텐츠를  재생하고  재생이  종료되면  CAS S/W 가 삭제되도록  
Policy 가 작성될  수 있다 . 이러한  경우에 , CAS S/W 는 콘텐츠가  재생될  때마다  새로운  
버전으로  다운로드  받을  수 있다 . 
• 또한 , CAS S/W 의 life-time 을 Policy 에 의해  철저히  관리하기  위해서는  Player/COPP 
Client는 다운로드  된 CAS S/W 를 iCAS 시스템에서  관리되지  않는  저장소에  저장하
거나  외부로  재전송해서는  안되며 , 재생의  시작 , 종료  등의  관련  Event 를 반드시  
SVM에게  전달해야  한다 . 
 
[Policy] 
• 모든  CAS S/W 에는  해당  Policy 가 존재하고 , SVM 은 Policy 에서  허용  또는  금지하는  
작업이  올바르게  실행되고  있는지를  Policy monitor 를 이용하여  실행시간에  검사한다 . 정보통신단체표준 
TTAK.KO-08.0023 ４５만약 , Policy 에 위배되는  작업이  감지되면 , SVM 은 모든  작업을  즉시  중단하고  결과를  
Player 에게  적절한  방식 (예: 관련  오류를  화면에  표시  등)으로  보고해야  한다 . 
• Policy 에서  정의할  수 있는  작업과  범위에  대해서는  3.8.4 절을  참고하기  바란다 . 
 
 
3.8.2.3.  콘텐츠  Descramble  
콘텐츠  Descramble 방법은  단말구현에  따라  다음  2가지  형태  중 하나의  형태를  가진다 . 
타입  내용  
S/W Descramble 
(Type 1 Player) - Scrambled 콘텐츠  스트림  처리를  전적으로  CAS S/W 가 처리  
- CAS S/W 가 System call 을 통해  콘텐츠  버퍼에  직접  접근  
- CAS S/W 가 MPEG TS parsing 및 decryption 담당  
H/W Descramble 
(Type 2 Player) - IPTV 수신  단말  H/W에 Descramble 모듈이  존재하고 ,  
CAS S/W 는 Key 관리  및 주입만을  담당  
- CAS S/W 는 System call 을 통해  H/W에서  제공하는  API에  
Key 주입   
- CAS S/W 는 콘텐츠  버퍼에  접근하지  않음  
<표 3-2> 콘텐츠  Descramble Type 
 
Player 는 descramble 구현  형태에  따라  EVENT_Descramble Event 를 적절히  발생시켜줄  의
무가  있다 . 예를  들어 , Type 1 Player 는 콘텐츠  수신  버퍼가  일정량  채워지고  decoder 로 데
이터를  보내기  전에  EVENT_Descramble Event 를 발생시켜야  한다 . 다음  그림은  Type 1 
Player 가 기존의  처리경로에  더하여  SVM 을 통한  descramble 을 수행하는  순서를  나타낸다 . 
 정보통신단체표준 
TTAK.KO-08.0023 ４６MPEG buffer Codec
Secure Virtual Machine2. Descramble 이벤트 4. Descramble1. MPEG 스트림
수신 5. 재생
Network
Player 부분
Secure Virtual Machine 부분
3. EMM/ECM 처리MPEG buffer Codec
Secure Virtual Machine2. Descramble 이벤트 4. Descramble1. MPEG 스트림
수신 5. 재생
Network
Player 부분
Secure Virtual Machine 부분
3. EMM/ECM 처리 
(그림  3-19) Type1 Player 의 Descramble 
 
다음  그림은  Descramble H/W 를 내장하고  있는  Type 2 Player 가 SVM 을 통해  CAS 관련  
Key를 얻는  순서를  나타낸다 . 이 경우에는  Descramble H/W 에 새로운  Key를 입력할  때마
다 EVENT_Descramble Event 가 발생되어야  한다 . 예를  들어 , Player 는 스트림  내의  ECM 이 
변경될  때마다  EVENT_Descramble Event 를 발생시킨다 . 
 
MPEG buffer Codec
Secure Virtual Machine2. Descramble 이벤트4. Descramble
Key 입력1. MPEG 스트림
수신
NetworkDescramble
H/W
Player 부분
Secure Virtual Machine 부분
3. EMM/ECM 처리5. 재생
MPEG buffer Codec
Secure Virtual Machine2. Descramble 이벤트4. Descramble
Key 입력1. MPEG 스트림
수신
NetworkDescramble
H/W
Player 부분
Secure Virtual Machine 부분
3. EMM/ECM 처리5. 재생
 
(그림  3-20) Type2 Player 의 Descramble  
 
 정보통신단체표준 
TTAK.KO-08.0023 ４７3.8.3.  CAS S/W 
3.8.3.1.  Brief CAS S/W Package Structure  
CAS S/W 는 다음과  같은  부분으로  이루어진  패키지로  포장되어  전송된다 . 
Section Byte Length note 
Header 48  
Policy described in Header section XML representation  
Code described in Header section  
Signature described in Header section  
 
• Header:  CAS S/W 의 Version, ID 및 각 Section 의 길이  등의  정보를  나타낸다 . 
• Policy:  CAS S/W 에 따라  각기  다른  Security 정책을  정의할  수 있도록  해주는  Policy 
데이터 . Policy Monitor 에 적재된다 . 
• Code:  SVM Code Area 에 적재되어  실행될  명령어  코드부분 .  
• Signature:  위 모든  필드의  위변조를  방지하기  위한  인증기관의  전자서명 . 
 
SVM에서  CAS S/W 가 실행되는  execution flow 에 대한  실시  예를  부록  D에서  제공한다 .  
 
3.8.3.2.  Protection of CAS S/W  
[배포단계의  보호 ] 
CAS S/W 패키지는  배포될  때 COPP Client 에서  정의하는  TLS 등의  방법으로  암호화되어  
보호된다 . 따라서 , 배포단계에서  제 3자가  임의로  CAS S/W 를 획득할  수 없다 .  
 
[실행  시 보호 ] 
SVM 메모리에  적재된  상태의  CAS S/W 코드를  보호하기  위하여 , 다음과  같은  단계로  
코드를  적재 , 실행해야  한다 . 
• 32-bit 길이의  난수  mask 를 동적으로  생성한다 . 
• 코드를  SVM 메모리에  적재할  때, 32-bit 단위로  mask 를 이용하여  XOR 한다 . 
• interpreter 가 명령어를  fetch 할 때, 위 mask 를 이용하여  실행하고자  하는  명령어  1개에  
대해  XOR 하여  코드를  fetch 한다 . 
• 난수  mask 는 CAS S/W 가 메모리에  적재될  때마다  동적으로  생성되어야  하고 , CAS 
S/W가 실행되는  동안  안전하게  보관되어야  한다 . 난수  mask 의 생성과  사용은  COPP 
Client와 SVM 사이에서  안전하게  이루어져야  한다 . 
위와  같이  mask 를 이용하여  코드를  보호하는  방법을  사용하면 , 실행시간에  memory 정보통신단체표준 
TTAK.KO-08.0023 ４８dump 공격으로  인한  코드유출  피해를  최소화  할 수 있다 . 
 
3.8.4.  Policy 
SVM에서  실행되는  CAS S/W 는 CAS client 의 기능을  수행하기  때문에 , 보안적인  오류를  
가진다면  전체  시스템의  취약점이  될 수 있다 . 이러한  문제에  대한  1차적인  대응  방안은  
3.6절에  정의된  것과  같은  CAS S/W 에 대한  서명  검사를  통해  신뢰할  수 있는  기관이  
생성한  CAS S/W 만 SVM 에서  실행되도록  강제하는  방법을  생각할  수 있다 . 그러나 , CAS 
S/W가 의도적  혹은  의도적이지  않은  오류를  내포하는  경우 , 상기  전자서명은  시스템의  
안전성을  보장하기  힘들다 .  
 
이 장에서는  상기  문제점을  해결하기  위해  Policy 기반으로  실시간으로  시스템을  악성  
CAS S/W 로부터  보호하는  방법을  기술한다 . Policy 기반의  SVM 보호  방법의  특징은  다
음과  같다 .  
• Policy 는 CAS S/W 의 구동  시 SVM 이 지켜야  하는  규칙과  CAS S/W 가 지켜야  하는  
규칙들을  정의하며 , CAS S/W 는 반드시  policy 와 함께  배포되어  policy 에서  허용하는  
작업만  수행할  수 있도록  한다 .  
• Policy 는 기본적으로  SVM 과 SVM 이 동작하는  platform 사이의  operation, 즉 system 
call의 허가  여부와  입출력  단자의  제어  여부를  정의한다 . 즉, Policy 는 CAS S/W 가 
구현하는  DRM 표준의  전체  또는  특정  상황에서  일어나서는  안 되는 , 혹은  일어날  
필요가  없는  system call 에 대한  정보를  가지고  있으며 , 이러한  일이  발생할  경우  동
작을  막는다 . . 
 
구현의  한 예로  Policy 를 통해  실행중인  CAS S/W 의 행동을  제한하는  것은  policy monitor
에 의해서  이루어  질 수 있다 . 참고로  policy monitor 가 적용된  예를  살펴보면  다음과  같
다.  정보통신단체표준 
TTAK.KO-08.0023 ４９
 
(그림  3-21) Example of Policy Monitor 
 
 
3.8.4.1.  Policy Items  
Policy 는 XML 문법을  사용하여  표현한다 .  
 
1) SVM Policy 
CAS S/W 를 구동하는  동안  SVM 이 지켜야  할 규칙이다 . 여기에  해당하는  규칙들은  CAS 
S/W가 적재된  후, CAS S/W 가 종료  될 때까지  지켜져야  한다 . 이 policy 에는  CAS S/W 의 
lifetime 을 정의하거나  system call 허가  여부의  default 값(permit or deny) 을 설정할  수 있다 .  
 
[문법  및 표현 ] 
SVM Policy 부분에서  정의하는  Node 는 다음과  같다 . 
• VM_Version: 해당  S/W가 실행되기  위한  SVM 의 최소  버전을  기술한다 . 
• SoftwareLifeTime:  해당  S/W의 life-time 을 기술한다 . Volatile 은 S/W 종료되면  즉시  삭
제되어야  하며 , Permanent, Once, DeleteAfter 등으로  기술될  수 있다 . 
• SystemCallDefault:  Event Policy 부분에서  각 System call 의 기본  호출  허용  여부를  기
술한다 . 만약  Deny 로 기술되면 , 언급하지  않은  모든  System call 은 해당  Event 에서  사
용할  수 없다 . 
• IODefault:  Event Policy 부분에서  각 I/O Port 의 기본  접근  허용  여부를  기술한다 . 만약  
Deny로 기술되면 , 언급하지  않은  모든  I/O는 해당  Event 에서  사용할  수 없다 . 
다음은  SVM Policy 의 예를  나타낸다 . 정보통신단체표준 
TTAK.KO-08.0023 ５０ 
   
•  
 
2) Event Policy 
각 Event 발생  시 허가되거나  허가되지  않은  system call 들을  기술  한다 . CAS S/W 는 일반
적인  명령어를  실행할  때보다  system call 을 이용하여  더 심각한  보안적  문제를  발생시킬  
수 있다 . 따라서  주로  system call 의 실행을  제한함으로써  안전성을  높일  수 있다 . 
SVM은 event-driven 방식으로  동작하기  때문에  각 Event 에서  허용된  system call 과 허용
되지  않는  system call 로 구분한다 . 
만약  허용되지  않은  system call 이 수행되는  경우 , 이를  
악의적인  행동이나  잘못된  행동으로  규정하고 , 각각에  정의된  대응을  하게  된다 . 
예를  들어 , EVENT_Descramble 의 경우 , 복호화관련  system call 은 허용되지만 , Network 관
련 system call 은 금지  될 수 있다 . 이는  CAS S/W 가 구현하는  CAS 및 DRM 표준에  따라
서 달라질  수 있다 . 
 
[문법  및 표현 ] 
SVM Policy 부분에서  정의하는  내용은  다음과  같이  Event 단위의  Node 로 표현된다 . 
• Event_Initialize 
• Event_Terminate 
• Event_Descramble 
• Event_Select 콘텐츠  
• Event_Timer 
각 Event 별 하위  내용은  다음은  하위  Node 로 표현된다 . 
• SystemCall:  해당  Event 에서  SVM Policy 부분에서  정의한  Default 설정  이외에  추가로  
System call 호출  허용  여부를  기술한다 . 
• PermitSystemCall:  허용하는  System call 을 나열한다 . Network 관련  System call 의 경우에
는 attribute 로 IP, Port 를 추가로  사용한다 . 
• DenySystemCall:  금지하는  System call 을 나열한다 . Network 관련  System call 의 경우에
는 attribute 로 IP, Port 를 추가로  사용한다 . 
• IO: 해당  Event 에서  SVM Policy 부분에서  정의한  Default 설정  이외에  추가로  I/O Port
의 접근  허용  여부를  기술한다 . VideoIn, VideoOut, AudioI n, AudioOut, Network, USB 가 
기본적으로  기술  가능하며 , UserSpecificPort 노드에  H/W specific 한 내용을  추가할  수 
있다 . 
• PermitIO:  허용하는  I/O Port 를 나열한다 . <SVM> 
<SoftwareLifeTime>V olatile</SoftwareLifeTime> <SystemCallDefault>Deny</SystemCallDefault> 정보통신단체표준 
TTAK.KO-08.0023 ５１• DenyIO:  금지하는  I/O Port 를 나열한다 . 
다음은  Event Policy 의 예를  나타낸다 . 
 
 
3) Policy monitor 
Policy 가 CAS S/W 실행  중에  올바르게  지켜지기  위해서는  이를  감시하고  강제하는  
Policy monitor 가 필요하다 . 
Policy monitor 은 policy 데이터를  분석하여  각 event 상황에서의  system call 허용  여부에  
대한  정보를  얻는다 . Event 가 발생하고  CAS S/W 가 이를  처리하는  동안  system call 을 요청
하는  경우 , SVM 은 policy monitor 에게  해당  system call 의 허용  여부를  묻는다 . Policy 
monitor 은 내부의  정보를  바탕으로  이에  대한  응답을  하게  된다 . 아래  그림은  이와  같은  
처리  과정의  구현  예를  나타낸다 . <Event_Policy> 
 <Event>   <Event_Descramble>    < S y s t e m C a l l >      <PermitSystemCall>Me mAlloc</PermitSystemCall> 
    <PermitSystemCall>MemCopy</PermitSystemCall>    </SystemCall>    < I O >      < P e r m i t I O >       <VideoIn/>      <VideoOut/>     
 <UserSpecificPort>Component</UserSpecificPort> 정보통신단체표준 
TTAK.KO-08.0023 ５２
 
(그림  3-22) Policy Monitor 처리과정  
 
 
3.8.5.  System Call  
SVM은 CAS S/W 와 인터페이스  방법으로  System call 을 제공하며 , 자주  사용되거나  복잡
한 작업을  포함하게  된다 . System call 구현은  CAS S/W 코드가  아닌  SVM 내에  존재한다 . 
System Call 호출은  Parameter 들을  Stack 에 쌓고 , TRAP instruction 을 호출함으로  이루어진
다. System call 의 API 형태는  다음과  같이  정의한다 . 
 
unsigned int SYSCALL_func ( unsigned int a, int b, unsigned char* c ) ; 
 
• System call 의 return type 은 unsigned int(32 bit) 이다 . 
• System call 의 이름은  ‘SYSCALL_’ 을 prefix 로 갖는다 . 
• System call 의 Parameter 는 signed(4-byte) 및 unsigned word(4-byte) 와 Pointer(4-byte) 를 사
용할  수 있다 . 
 
본 규격에서는  기본적인  System Call 들에  대해서만  정의하고 , 개별  CAS S/W 서비스를  
위해  필요한  System Call 들은  상기에서  정의한  System Call API 를 따르며 , 이에  대한  구체
적인  사항들은  별도로  규정한다 .  
 
 
3.8.6.  Event 
Event는 player/COPP Client 에서  일어난  의미  있는  ‘사건 ’을 일컫는다 . Execution states 는 정보통신단체표준 
TTAK.KO-08.0023 ５３상기  event 를 통해  전이되며 , 특정  event 에 대한  처리는  SVM 이 아닌  SVM 상에서  돌아가
는 CAS S/W 에 의해서  기술된다 .8 
Event는 일반적인  micro controller 의 외부  인터럽트와  비슷하다 . CAS S/W 는 수행  초기화  
과정에서  event 를 처리할  수 있는  event handler 를 등록한다 . Player 가 event 가 생겼음을  
SVM에 알리면  SVM 은 등록된  event handler 를 수행한다 . 
Event message 는 SVM 의 memory 중 message area 로 지정된  위치에  저장된다 . Message 에
는 어떤  event 가 발생했는지를  구분하는  EventID 와 event 의 처리  결과를  전달하기  위한  
return value, event handling 에 필요한  parameter 들이  포함되어  있다 . Event 에 대한  처리가  끝
나면  event handler 는 처리의  결과를  다시  message 에 기록한다 . Event 는 동시에  하나만  처
리가  가능하기  때문에 , Player 는 SVM 이 Event 처리  도중에  event 를 입력하면  안 된다 .  
 
                                                      
8 IPTV 미들웨어  표준  규격을  참조하여  필요한  Event 형식이나  메시지에  대해  정의하여  향후  
개정  작업  시 추가적으로  반영할  예정임 . 정보통신단체표준 
TTAK.KO-08.0023 ５４APPENDIX A.  CAS System Example (Informative) 
 
본 장에서는  CAS 영역에서  사용  가능한  서비스  및 콘텐츠  보호  모듈에  관한  참고  
기술에  대해  기술한다 . 본 시스템에서  콘텐츠는  CW로 암호화되고 , CW는 해당  콘텐츠에  
대한  사용  권한을  가진  IPTV 수신  단말만이  획득할  수 있도록  분배된다 . 본 시스템은  2-
Level 과 3-Level Key 의 키 분배  기법을  지원하며 , 시스템이  적용되는  환경에  따라 , 두 
가지  키 분배  기법이  선택적으로  사용된다 . 2가지  Key 분배기법은  Liner TV 와 Vo D  
모두에  동일하게  적용된다 . 본 CAS 시스템에서는  CAS 서버의  역할을  SAS (Subscriber 
Authorization System) 가 수행하며 , 콘텐츠별  복호화  Key 를 관리하고 , IPTV 수신  단말의  
요청에  따라  Key를 IPTV 수신  단말에  전달하는  역할을  담당한다 . 
권한  관리에  사용되는  Key들을  요약하면  <표 A-1 >과 같다 . <표 A-1>에서  Type 에는  현재  
규격에서  지원하는  알고리즘과  해당  알고리즘에서  사용하는  Key의 길이를  나타내고  있
다. 
 
Keys  Description Type 
CW 
 Control Word. 콘텐츠를  scrambling 하는데  사용
되는  Key.  AES-128 (16 bytes) 
SK Service Key. CW 를 암호화하는데  사용되는
Key.  AES-128 (16 bytes) 
DK Device Key. EMM 에서  EEK 를 암호화하는데
사용되는  Key.  RSA-1024 (128 bytes) 
SASK_PUB
  SAS의 Public Key. EMM 요청  메시지에서
CEK를 암호화하는데  사용되는  Key.  
EMM의 signature 를 검증하는데  사용되는  Key. RSA-1024 (128 bytes) 
EEK Entitlement Encryption Key. EMM 에서
Entitlement 를 암호화하는데  사용되는  Key. 
 AES-128 (16 bytes) 
CEK CID & CA Token Encryption Key. EMM 요청  메
시지에서  CID의 목록과  CA Token 을 암호화하
는데  사용되는  Key. AES-128 (16 bytes) 
<표 A-1> Keys used in the Entitlement Management 
 정보통신단체표준 
TTAK.KO-08.0023 ５５A.1. 3-Level Key 분배  기법  
콘텐츠는  CW를 이용하여  scrambling 되고 , CW는 SK로 암호화되어  ECM 을 형성하며 , SK
는 IPTV 수신  단말의  DK를 이용하여  암호화되어  EMM 을 형성한다 . ECM 은 콘텐츠와  동
일한  채널로  전송되는  반면 , EMM 은 콘텐츠와는  별도의  채널로  사용자의  요청에  의해  전
송된다 . CW는 콘텐츠와  함께  전송되지만 , CW를 복호화  할 수 있는  SK는 시청  권한을  
가진  IPTV 수신  단말 (client) 의 DK로 암호화되어  전송되기  때문에 , 시청  권한을  획득한  
사용자만이  콘텐츠를  이용할  수 있게  된다 .  
콘텐츠를  사용하고자  하는  IPTV 수신  단말 (client) 은 server 에게  자신의  권한  정보를  증
명할  CA Token 을 제출하면서  EMM 를 요청하고 , 서버는  client 가 제출한  CA Token 을 검증
하여  유효한  사용자이면  SK를 해당  client 의 DK로 암호화하여  EMM 을 발급한다 . Client 는 
자신의  DK를 이용하여  EMM 으로부터  SK를 얻어내고 , SK를 이용하여  ECM 으로부터  CW
를 얻어내어 , 최종적으로  CW를 이용하여  콘텐츠를  descrambling 하게  된다 . (그림  A-1)은 3-
Level 키 분배  기법을  간략히  그림으로  나타낸  것이다 . 
Scrambler Descrambler TS
EncryptorCWScrambled TS
DecryptorECM
(Encrypted CW)TS
CWServer Client
Encryptor DecryptorSK
EMM
(Encrypted SK)
DK DK SKScrambler Descrambler TS
EncryptorCWScrambled TS
DecryptorECM
(Encrypted CW)TS
CWServer Client
Encryptor DecryptorSK
EMM
(Encrypted SK)
DK DK SK
 
(그림  A-1) 3-Level Key Distribution Scheme 
 
1) ECM (Entitlement Control Message) 
ECM은 콘텐츠  중간에  삽입되어  콘텐츠와  동일한  채널로  전송되며 , SK로 암호화된  CW
를 포함한다 . CW 복호화에  필요한  SK 값을  요청하고  전송  받는  방법은  A.3절에서  기술
한다 . 
ECM은 MPEG-2 TS Packet 의 형태로  콘텐츠와  함께  전송된다 . ECM 의 PID 정보는  ISO 
13818-1 에 정의된  CA_descriptor() 를 이용하여  전달되며 , CA_descriptor 는 해당  콘텐츠의  정보통신단체표준 
TTAK.KO-08.0023 ５６PMT Table 에 나타난다 .  
ECM에 포함되는  CW는 주기적으로  변경되며 , 변경되는  키는  Even/Odd 두 가지  type중 
하나로  할당되어  두 type의 CW가 번갈아  전송된다 . ECM 의 “CW Even/Odd Flag” 필드에  
해당  CW의 type이 표시된다 . Scrambling 에 사용되는  CW와 ECM 에 포함된  CW의 sync를 
맞추기  위하여 , MPEG2-TS header 의 transport_scrambling_control 필드에  해당  TS packet 을 
scrambling 하는데  사용한  CW의 type을 표시한다 .  
콘텐츠를  실시간으로  descrambling 하기  위해서는  scrambled 콘텐츠가  나타나기  전에  해
당 콘텐츠를  scrambling 하는데  사용된  CW를 획득할  수 있어야  한다 . (그림  A-2)에서  보여
지듯이 , ECM 은 해당  ECM 이 포함하고  있는  CW로 scrambling 한 콘텐츠가  전송되기  전에  
전송되어야  한다 .  
 
(그림  A-2) Even/Odd Key 
 
[ECM Structure] 
ECM 은 콘텐츠를  복호화하기  위한  CW를 안전하게  전송하기  위해  사용된다 .  
CW 뿐만  아니라 , SK도 주기적으로  변경될  수 있기  때문에 , ECM 의 CW를 복호화하기  
위해서는  CW 암호화에  사용된  SK가 어떤  것인지를  확인할  수 있는  방법이  필요하다 . 
본 규격에서는  “SK Even/Odd Flag” 필드를  사용해서  현재  ECM 의 CW를 암호화하는데  사
용된  SK를 구분하는  방법을  사용한다 .  정보통신단체표준 
TTAK.KO-08.0023 ５７  76543210
1
2
3
45
6
78
9
…
n + 8
n + 9
n + 10
n + 11Length (3 bytes)
SK Even/Odd Flag (1 byte)Version (1 byte)
Content Scrambling Algorithm (1 byte)
CRC (4 bytes)E {SK, CW} (n bytes)Content Scrambling Algorithm Mode (1 byte)
CW Even/Odd Flag (1 byte)()(msb) (lsb)
ByteBit
 
(그림  A-3) ECM Message Format 
• Version (1 byte): ECM Format 의 version number. 현재는  ‘0x01’ 로 정의됨 . 
• Length (3 bytes): Version 과 Length 필드의  크기를  제외한  ECM 의 전체  길이 .  
• 콘텐츠  Scrambling Algorithm (1 byte): 콘텐츠  scrambling 에 사용되는  암호  알고리즘 . 현
재는  AES-128 만 정의되어있음 .  
 0x00 : AES-128    
 Others are reserved.  
• 콘텐츠  Scrambling Algorithm Mode (1 byte): 콘텐츠  Scrambling 모드 . 현재는  한가지  모
드만  정의되어  있음 . 
 0x00 : ATIS scrambling algorithm (CBC 기반 ) 
 Others are reserved.  
• SK Even/Odd Flag (1 byte): 현재  ECM 의 CW를 암호화하는데  사용된  SK가 even Key 
인지  odd Key 인지를  나타냄 . SK가 주기적으로  변경될  때 변경된  SK와의  동기화를  위
한 필드 . 최근  수신한  EMM 중 EMM 내의  SK Even/Odd Flag 가 이 flag와 동일한  값을  
가지는  EMM 의 SK를 이용하여  암호화된  CW를 복호화한다 . 
 0x00 : Even Key  
 0x01 : Odd Key  
 Others are reserved.  
• CW Even/Odd Flag (1 byte): 현재  ECM 의 CW가 even Key 인지  odd Key 인지를  나타냄 . 
이 값과  MPEG-TS header 의 transport_scrambling_control field 를 이용하여  CW 적용  시
점을  동기화  시킴 .  
 0x00 : even Key  
 0x01 : odd Key  
 Others are reserved.   
• E {SK, CW} (N bytes) : SK 로 암호화된  CW. CW 의 길이는  콘텐츠  Scrambling Algorithm
에 의해  결정된다 . 예를  들어 , 콘텐츠  Scrambling Algorithm 이 AES-128 이라면 , CW의 
길이는  16bytes 가 된다 . CW 를 암호화하는데  쓰이는  알고리즘은  CW Encryption 
Algorithm 필드에  나타난다 . 만약 , CW 의 길이가  암호알고리즘에서  필요로  하는  값보
다 작다면 , PKCS #5 의 padding 방법을  따라  padding 하여  암호화한다 .   
• CRC-32 (4 bytes): 앞선  모든  field들의  Error Detection 을 위한  CRC 값. ISO/IEC 13818-1
의 Annex A 에 정의된  CRC Decoder 의 register 들의  output 을 0으로  만드는  CRC 값. 정보통신단체표준 
TTAK.KO-08.0023 ５８ 
2) EMM (Entitlement Management Message) 
EMM은 SK를 안전하게  전달하기  위해  사용된다 . EMM 은 콘텐츠와는  별도의  채널로  
EMM을 요청한  client 에게  개별적으로  전송된다 . 콘텐츠를  사용하고자  하는  client 는 서버
에게  EMM 을 내려줄  것을  요청하게  되고 , 서버는  client 가 정당한  구매자인지를  확인한  
후 EMM 을 내려주게  된다 . EMM 요청  및 전송  프로토콜은  A.3절에서  기술한다 . 
 
[EMM Structure] 
EMM은 ECM 내의  암호화된  CW를 복호화  하기  위한  SK를 안전하게  전송하기  위해  사
용된다 . EMM 은 한 개 이상의  “Entitlement” 로 구성되며 , 하나의  “Entitlement” 에는  한 개의  
콘텐츠에  대한  SK정보가  담겨있다 . 즉, 하나의  EMM 에는  복수개의  콘텐츠에  대한  SK정
보가  포함될  수 있다 . 복수개의  Entitlement 는 EEK로 암호화되고 , 이 EEK는 EMM 발급을  
요청한  client 의 DK로 암호화됨으로써 , EMM 발급을  요청한  client 만이  EMM 을 복호화  할 
수 있게  된다 . (그림  A-4 )은 EMM 의 전체  구조를  나타낸  것이고 , (그림  A-5 )은 개별  
Entitlement 의 구조를  나타낸  것이다 . 
 76543210
1
2
3
4
5
6
7
8
9
…
m+8
m+9
m+10
m+11
m+12
…
m+k+11
m+k+12
m+k+13
m+k+14
m+k+15
…E {EEK, (Entitlement 1 || … || Entitlement N)} (k bytes)Reserved (2 bytes)
DK Type (1 byte)
E {DK, (EEK Type || EEK)} ( m bytes)DK Encrypted Data Length (3 bytes)Version (1 byte)
SAS's signature of all preceding fields  (z bytes)Signature Type (1 byte)Number of Entitlement (4 bytes) Key Distribution Method (1 byte)
Signature Length (3 bytes)(msb) (lsb) (msb) (lsb)
ByteBit
 
(그림  A-4) EMM Structure 
• Version (1 byte) : EMM Structure 의 version. 현재는  ‘0x01’ 로 정의됨 . 
• Key Distribution Method (1 byte) : 어떤  Key 분배  기법에  사용되는  EMM 인지  표시 , 본 
절에서는  3-level Key 분배에  대한  EMM 을 정의하므로 , ‘0x00’ 으로  정의됨 . 정보통신단체표준 
TTAK.KO-08.0023 ５９ 0x00 : 3-Level Key Distribution    
 0x01 : 2-Level Key Distribution 
 Others are reserved.  
• Reserved (2 bytes) : 예약된  field.  
• DK Type (1 byte) : DK 의 Type. 어떤  암호화  알고리즘에  사용되는  키인지를  표시 .  
 0x00 : RSA-1024. 
 Others are reserved. 
• DK Encrypted Data Length (3 bytes) : DK 로 암호화한  Data의 길이 .  
• E {DK, (EEK Type || EEK)} (m bytes) : DK 로 EEK의 Type 과 EEK를 암호화한  값.  
 EEK Type (1 byte): EEK 가 어떤  암호화  알고리즘에  사용되는  키인지를  표시 . 
 0x00 : AES-128    
 Others are reserved. 
 EEK : Entitlement 를 암호화하는  키. 키의  종류는  EEK Type 에 의해  결정됨 . 예를  들어 , AES-128
을 쓸 경우  16 bytes 의 AES 용 키가  들어감 .  
• Number of Entitlement (4 bytes): EEK 로 암호화된  Entitlement 의 개수 . 
• E{EEK, (Entitlement 1 || … || Entitle ment N)} (k bytes): Entitlement 를 Entitlement Encryption 
Key 로 암호화한  값. ECB 모드를  사용하며 , Padding 이 필요할  시에는  PKCS#5 의 방식
을 따른다 . 
• Signature Type (1 byte): Signature 의 type  
 0x00 : RSA-1024.  
 Others are reserved. 
• Signature Length (3 bytes): Signature 의 길이  
• SAS’s signature (z bytes): 앞선  모든  field들에  대한  SAS의 서명값  
 정보통신단체표준 
TTAK.KO-08.0023 ６０ 76543210
1
23456
7
89
10111213
14
151617181920
21
…SK Valid From (8 bytes)Entitlement Valid From (8 bytes)SK Even/Odd Flag (1 byte)
CW Encryption Algorithm (1 byte)Content Type  (1byte)CID (4 bytes)
SK (y bytes)CW Encryption Algorithm Mode (1 byte)
Entitlement Valid Until (8 bytes)
SK Valid Until (8 bytes)(msb) (lsb) (msb) (lsb)
()()
ByteBit
 
(그림  A-5) Structure of Entitlement 
 
• CID (4 bytes): EMM 의 SK를 이용하여  재생할  수 있는  콘텐츠의  ID 또는  Channel 의 
ID 
• 콘텐츠  Type (1 byte): 콘텐츠의  type 
 0x00: Linear TV 
 0x01: VoD 
 Others: Reserved 
• SK Even/Odd Flag (1 byte): SK 가 even Key 인지  odd Key 인지를  나타냄 . 
 0x00 : even Key  
 0x01 : odd Key  
 Others are reserved.  
• CW Encryption Algorithm (1 byte) : EMM 에 포함된  SK를 이용하여  ECM 의 CW을 암호
화할  때 사용하는  암호화  알고리즘 . 현재는  AES-128 만 정의되어있음 . 
 0x00 : AES-128    
 Others are reserved.  
• CW Encryption Algorithm Mode (1 byte):  EMM 에 포함된  SK를 이용하여  ECM 의 CW를 
암호화할  때 사용하는  암호화  모드 . 현재는  ECB만 정의되어있음 .  
 0x00 : ECB    
 Others are reserved.  
• Entitlement Valid From (8 bytes) : Entitlement 유효기간의  시작시점 . EMM 에 정의된  콘텐
츠를  사용할  수 있는  권한의  시작  시점 . 이 시점  이전에는  해당  콘텐츠를  사용할  수 
없음 .  정보통신단체표준 
TTAK.KO-08.0023 ６１• Entitlement Valid Until (8 bytes) : Entitlement 유효기간의  종료시점 . EMM 에 정의된  콘텐
츠를  사용할  수 있는  권한의  종료  시점 . 이 시점  이후에는  해당  콘텐츠를  사용할  수 
없음 .  
• SK Valid From (8 bytes) : SK 의 변경주기를  나타내기  위한  필드로써 , SK 유효기간의  시
작시점 . 즉, EMM 에 포함된  SK로 ECM 이 암호화되기  시작하는  시점 . 정확한  CW 암
호화와  SK의 동기화는  SK Even/Odd flag 을 통하여  제어된다 .  
• SK Valid Until (8 bytes) : SK 의 변경주기를  나타내기  위한  필드로써 ,SK 유효기간의  종
료시점 . 즉, EMM 에 포함된  SK의 사용이  종료되고  다음  SK를 사용해야  하는  시각 . 
콘텐츠를  계속  재생하기  위해서는 , 이 시점  이전에  다음  SK를 포함하는  EMM 을 수
신하여야  한다 . 정확한  CW 암호화와  SK의 동기화는  SK Even/Odd flag 을 통하여  제어
된다 . 
• SK (y bytes): ECM 의 CW부분을  암호화 (복호화 )하는데  사용되는  SK. 길이는  CW 
encryption algorithm 에 의하여  결정됨 . 예를  들어 , CW encryption Algorithm 이 AES-128 일 
경우  16bytes.  
 
A.2. 2-Level Key 분배  기법  
2-Level Key 분배기법에서는  3-Level Key 분배  기법과  다르게  SK를 사용하지  않고 , client
의 DK로 직접  CW를 암호화한다 . 콘텐츠는  CW를 이용하여  scrambling 되고 , CW는 DK를 
이용하여  암호화되어  EMM 을 형성한다 . EMM 은 콘텐츠와는  별도의  채널로  client 의 요청
에 의해  전송된다 .  
콘텐츠를  사용하고자  하는  client 는 server 에게  자신의  권한  정보를  증명할  CA Token 을 
제출하면서  EMM 를 요청하고 , 서버는  client 가 제출한  CA Token 을 검증하여  유효한  사용
자이면  CW를 해당  client 의 DK로 암호화하여  EMM 을 발급한다 . Client 는 자신의  DK를 
이용하여  EMM 으로부터  CW를 얻어내어 , CW를 이용하여  콘텐츠를  descrambling 한다 . (그
림 A-6) 은 2-Level Key 분배  기법을  간략히  그림으로  나타낸  것이다 . 정보통신단체표준 
TTAK.KO-08.0023 ６２Scrambler Descrambler TS
EncryptorCWScrambled TS
DKDecryptor
DKEMM
(Encrypted CW)TS
CWServer Client
Scrambler Descrambler TS
EncryptorCWScrambled TS
DKDecryptor
DKEMM
(Encrypted CW)TS
CWServer Client
 
(그림  A-6) 2-Level Key Distribution Scheme 
1) EMM (Entitlement Management Message) 
EMM은 CW를 안전하게  전달하기  위해  사용된다 . EMM 은 콘텐츠와는  별도의  채널로  
EMM을 요청한  client 에게  개별적으로  전송된다 . 콘텐츠를  사용하고자  하는  client 는 서버
에게  EMM 을 내려줄  것을  요청하게  되고 , 서버는  client 가 정당한  구매자인지를  확인한  
후 EMM 을 내려주게  된다 . EMM 요청  및 전송  프로토콜은  A.3절에서  기술한다 . 
[EMM Structure] 
EMM의 기본  구조는  0와 동일하며 , 차이점은  “Entitlement” 에 SK 정보  대신에  CW에 
대한  정보가  포함된다는  것이다 .  
EMM에 포함되는  CW는 주기적으로  변경되며 , 변경되는  키는  Even/Odd 두 가지  type중 
하나로  할당되며 , 이 타입은  Entitlement 의 “CW Even/Odd Flag” field 에 표시된다 . Scrambling
에 사용되는  CW와 EMM 에 포함된  CW의 sync 를 맞추기  위하여 , MPEG2-TS header 의 
transport_scrambling_control 필드에  해당  TS packet 을 scrambling 하는데  사용된  CW의 type
을 표시한다 . 
(그림  A-7)은 EMM 의 전체  구조를  나타낸  것이고 , (그림  A-8)은 개별  Entitlement 의 구조를  
나타낸  것이다 .  정보통신단체표준 
TTAK.KO-08.0023 ６３ 76543210
1
23
4
567
8
9
…
m+8
m+9
m+10
m+11
m+12
…
m+k+11
m+k+12
m+k+13
m+k+14
m+k+15
…E {DK, (EEK Type || EEK)} ( m bytes)Reserved (2 bytes)Version (1 byte)
Key Distribution Method (1 byte)
DK Encrypted Data Length (3 bytes)
SAS's signature of all preceding fields  (z bytes)Number of Entitlement ( 4bytes) 
E {EEK, (Entitlement 1 || … || Entitlement N)} (k bytes)
Signature Type (1 byte)
Signature Length (3 bytes)DK Type (1 byte)()(msb) (lsb)
()(msb) (lsb)
ByteBitByte
 
(그림  A-7) EMM Structure 
• Version (1 byte) : EMM Structure 의 version. 현재는  ‘0x01’ 로 정의됨 . 
• Key Distribution Method (1 byte) : 어떤  Key 분배  기법에  사용되는  EMM 인지  표시 , 본 
절에서는  2-level Key 분배에  대한  EMM 을 정의하므로 , 0x01 으로  정의됨 . 
 0x00 : 3-Level Key Distribution    
 0x01 : 2-Level Key Distribution 
 Others are reserved.  
• Reserved (2 bytes): 예약된  field.  
• DK Type (1 byte): DK 의 Type. 어떤  암호화  알고리즘에  사용되는  키인지를  표시 .  
 0x00 : RSA-1024.  
 Others are reserved. 
• DK Encrypted Data Length (3 bytes): DK 로 암호화된  Data의 길이   
• E {DK, (EEK Type || EEK)} (m bytes): DK 로 EEK의 type과 EEK를 암호화한  값.  
 EEK Type (1 byte): Entitlement Encryption Key 가 어떤  암호화  알고리즘에  사용되는  키인지를  표
시. 
 0x00 : AES-128   
 Others are reserved.  
 EEK : Entitlement Encryption Key. Entitlement 를 암호화하는데  사용되는  키. 
• Number of Entitlement (4 bytes) : EEK 로 암호화된  Entitlement 의 개수 . 
• E{EEK, (Entitlement 1 || … || Entitlement N)} (k bytes) : Entitlement 를 Entitlement 
Encryption Key 로 암호화한  값. ECB 모드를  사용하며 , Padding 이 필요할  시에는  
PKCS#5 의 방식을  따른다 . 정보통신단체표준 
TTAK.KO-08.0023 ６４• Signature Type (1 byte): Signature 의 type  
 0x00 : RSA-1024. 
 Others are reserved. 
• Signature Length (3 bytes): Signature 의 길이  
• SAS’s signature (z bytes) : 앞선  모든  field들에  대한  SAS의 서명  값 
 76543210
1
2
3
4
5
6
78
9
10
11
12
13
14
15
16
17
18
19
2021
…CW Valid Until (8 bytes)
CW (y bytes)Content Encryption Algorithm Mode (1 byte)
Entitlement Valid From (8 bytes)
Entitlement Valid Until (8 bytes)
CW Valid From (8 bytes)Content Type  (1byte)
CW Even/Odd Flag (1 byte)
Content Encryption Algorithm (1 byte)CID (4 bytes)(msb) (lsb) (msb) (lsb)
ByteBitByte
 
(그림  A-8) Structure of Entitlement 
 
• CID (4 bytes): EMM 의 SK를 이용하여  재생할  수 있는  콘텐츠의  ID 또는  Channel 의 
ID 
• 콘텐츠  Type(1 byte): 콘텐츠의  type 
 0x00: Linear TV 
 0x01: VoD 
 Others: Reserved 
• CW Even/Odd Flag (1 byte): CW 가 even Key 인지  odd Key 인지를  나타냄 . 이 값과  콘텐
츠의  MPEG-TS 의 transport_scrambling_control field 를 이용하여  CW적용  시점을  동기화  
시킴 . 
 0x00 : even Key  
 0x01 : odd Key  
 Others are reserved. 
• 콘텐츠  Encryption Algorithm (1 byte): CW 를 이용하여  콘텐츠  Encryption 을 수행할  때 
사용되는  encryption algorithm. 현재는  AES-128 만 정의되어있음 . 
 0x00 : AES-128    
 Others are reserved. 정보통신단체표준 
TTAK.KO-08.0023 ６５• 콘텐츠  Encryption Algorithm Mode (1 byte): 콘텐츠  Encryption 모드 . 현재는  ATIS 에서  
사용하는  CBC 기반  scrambling algorithm 만 정의되어있음 .  
 0x00 : CBC 기반  ATIS scrambling algorithm 
 Others are reserved. 
• Entitlement Valid From (8 bytes) : Entitlement 유효기간의  시작시점 . EMM 에 정의된  콘텐
츠를  사용할  수 있는  권한의  시작  시점 . 이 시점  이전에는  해당  콘텐츠를  사용할  수 
없음 .  
• Entitlement Valid Until (8 bytes) : Entitlement 유효기간의  종료시점 . EMM 에 정의된  콘텐
츠를  사용할  수 있는  권한의  종료  시점 . 이 시점  이후에는  해당  콘텐츠를  사용할  수 
없음 .  
• CW Valid From (8 bytes) : CW 의 변경주기를  나타내기  위한  필드로써 , 현재  EMM 이 포
함하고  있는  CW 유효기간의  시작시점 . 즉, EMM 에 포함된  CW가 콘텐츠  암호화에  
이용되기  시작하는  시점 . 정확한  콘텐츠  암호화와  CW의 정확한  동기화는  CW 
Even/Odd flag 을 통하여  제어된다 .  
• CW Valid Until (8 bytes) : CW 의 변경주기를  나타내기  위한  필드로써 , CW 사용  만료시
점. 즉, EMM 에 포함된  CW의 사용이  종료되고  다음  CW를 사용해야  하는  시각 . 콘
텐츠를  계속  재생하기  위해서는 , 이 시점  이전에  다음  CW를 포함하는  EMM 을 수신
하여야  한다 . 콘텐츠  암호화와  CW의 정확한  동기화는  CW Even/Odd flag 을 통하여  
제어된다 .  
• CW (y bytes): 콘텐츠를  scrambling(descrambling) 하는데  사용되는  CW. 길이는  콘텐츠  
encryption algorithm 에 의하여  결정됨 .    
 
A.3. EMM 전송  프로토콜  및 Message  
[EMM 전송  프로토콜 ] 
콘텐츠를  사용하고자  하는  client 는 서버에게  원하는  콘텐츠  및 자신이  해당  콘텐츠에  
대한  권한을  가졌음을  확인할  수 있는  정보를  담아서  EMM_Request 를 보낸다 .  
• 본 규격에서는  client 가 시청하고자  하는  콘텐츠의  CID ( 콘텐츠  ID) 값들과 , CID 를 
사용할  수 있음을  나타내는  권한  정보인  CA Token 을 SAS의 공개키 (SASK_PUB) 로 
암호화  하여  전송하는  방법을  사용한다 .  
 
서버는  EMM_Request 의 내용을  검사한  후, EMM 이 포함된  EMM_Respose 를 Client 에
게 보낸다 .  
• 본 규격에서는  EMM_Request 의 검사는  CA Token 의 유효성을  검사하고 , CID 값들이  
CA Token 에 포함되어  있는지를  검사하는  과정으로  이루어  진다 . 검사를  통과한  경
우 서버는  EMM 을 생성한  뒤, Client 에게  EMM_Response 를 전송한다 .  
 
Client 는 EMM_Response 를 받은  후, EMM 을 검증하고 , 콘텐츠  복호화에  사용한다 .  
• 본 규격에서는  EMM 검증을  위해  EMM 에 대한  서명  검사를  수행한다 .  
 정보통신단체표준 
TTAK.KO-08.0023 ６６Client Server
EMM_Request : E{SASK_PUB,CEK}||E{CEK,(CID1||…||CIDN||CA Token)}
Verify CA Token 
Genera te EMM
EMM_Response : EMM
 
(그림  A-9) EMM Request and Response 
 
[EMM 변경  처리 ] 
EMM에 포함되는  CW나 SK가 변경되면  client 는 서버에게  변경된  CW나 SK를 포함하고  
있는  새로운  EMM 을 요청해야  한다 . 시청  중에  CW나 SK가 변경되더라도  서비스가  지
속적으로  이루어지도록  하기  위해 , client 는 EMM 의 SK 유효기간이나 , CW유효기간을  확
인하여 , 유효기간이  만료되기  전에  변경될  CW나 SK가 포함된  다음  EMM 을 요청해야  
하며 , 서버는  EMM 이 변경되기  특정시간  (예를  들어  한 시간 ) 전부터 , client 에게  다음  
EMM을 전송해  주어야  한다 .  
본 규격에서는  EMM 에 CW나 SK의 유효기간과  별도로  Entitlement 의 유효기간이  표시되
어 있다 . CW나 SK의 유효기간은  해당  EMM 에 포함된  CW나 SK가 valid 한 기간을  의미
하며 , Entitlement 유효기간은  해당  EMM 을 소유한  client 가 해당  콘텐츠를  볼 수 있는  권
한의  유효기간을  의미한다 . 즉, Client 는 EMM 의 Entitlement 유효기간  안에서는  변경되는  
CW나 SK가 포함된  새로운  EMM 을 발급  받을  수 있지만 , Entitlement 유효기간이  만료되
면 더 이상  EMM 을 발급  받을  수 없다 .  
Client가 현재  EMM 을 요청하는지  다음  EMM 을 요청하는지는  EMM_Request 의 “EMM 
Status” field 를 이용하여  구분된다 .  
 
[EMM_Request Message] 
Client는 EMM_Request message 를 전송하여  서버에게  EMM 을 요청한다 . EMM_Request 
Message 에는  EMM 을 요청하는  콘텐츠들의  CID의 목록과  해당  콘텐츠들에  대한  권한이  
있음을  증명해주는  CA Token 이 함께  전송된다 . CID 목록과  CA Token 은 CEK 로 암호화되
고, CEK 는 SAS 만이  복호화  할 수 있도록  SAS의 Public Key 로 암호화된다 . 
• Client는 한번에  복수개의  콘텐츠에  대한  EMM 을 요청할  수 있는데 , 그 개수는  
Number of CID field 에 나타난다 .  예를  들어 , CID1 과 CID2 의 두 개의  콘텐츠  에 대
한 EMM 을 요청할  때는  Number of CID field 를 2로 설정하고 , (CID1||CID2||CA Token) 정보통신단체표준 
TTAK.KO-08.0023 ６７이 CEK 로 암호화하여  전송한다 . 이때 , CA Token 에는  CID1 과 CID2 에 대한  권한  정보
가 포함되어있어야  한다 .  
• Client는 하나의  CA Token 으로  구매한  모든  콘텐츠에  대한  EMM 을 한번에  모두  요청
할 수도  있다 . 이를  위해서는  Number of CID field 를 0으로  설정하고 , CA Token 만을  
CEK로 암호화하여  전송하면  된다 . 서버는  Number of CID field 가 0인 EMM_Request 
메시지를  받으면  첨부된  CA Token 을 검증한  후, 해당  CA Token 으로  구매한  모든  콘
텐츠에  대한  EMM 을 전송한다 . 
  (mbs) (lsb)
76543210
0
12345
6
789
10
11
1213141516
…
m+15
m+16
m+17
m+18
m+19
…SASK_PUB Type (1 byte)
SASK_PUB Encrypted Data Length (3 bytes)
E {SASK_PUB, (CEK Type || CEK)} ( m bytes)Reserved (3 bytes)
Number of CID (4 bytes) 
E{CEK, (CID 1||CID 2||…||CID N||CAT)} (k bytes)Version (1 byte)
Type (1 byte)
EMM Status (1 byte)Command (2 bytes)
Length (4 bytes)
()
ByteBit
 
(그림  A-10) EMM_Request Message 
• Version (1 byte): 현재  Message 의 version. 현재  version 은 ‘0x01. 
• Type (1 byte): Message 의 type. CAS Message 이므로  0x02 값을  사용 . 
 0x00 : CA Token Message Type  
 0x01 : DRM S/W Message Type  
 0x02 : CAS Message Type  
 Others are reserved. 
• Command (2 bytes) : Command 의 type.  
 0x00 : EMM Request  
 0x01 : EMM Response  
 Others are reserved. 
• Length (4 bytes) : Message 의 길이   
• EMM Status (1 byte): Request Message 가 원하는  EMM 의 상태 . 현재사용중인  EMM 에 
대한  요청인지  next EMM 에 대한  요청인지를  구분하는  값으로  쓰임 .  정보통신단체표준 
TTAK.KO-08.0023 ６８ 0x00 : 현재  EMM    
 0x01 : 다음  EMM  
 Others are reserved.  
• Reserved (3 bytes) : 예약된  field. 
• SASK_PUB Type (1 byte) : SAS 의 Public Key 가 어떤  종류의  알고리즘에  사용되는  키
인지  표시함 .  
 0x00 : RSA-1024. 
 Others are reserved. 
• SASK_PUB Encrypted Data Length (3 bytes) : SAS 의 Public Key 로 암호화된  Data의 길이  
• E{SASK_PUB, (CEK Type || CEK)} (m bytes) : SAS 의 Public Key 로 암호화한  CEK. 
 CEK Type (1 byte) : CEK 가 어떤  종류의  알고리즘에  사용되는  키인지를  표시함 .  
 0x00 : AES-128  
 Others are reserved. 
 CEK : CID 와 CA Token 을 암호화하는데  사용되는  키. 
• Number of CID (4 bytes): EMM 을 요청하는  CID의 개수 . 0일 경우는  첨부된  CA Token 으
로 구매한  모든  콘텐츠  에 대한  EMM 을 요청하는  경우임 .  
• E{CEK, (CID 1||CID  2||…||CA Token} (n bytes): CID 와 CA Token 을 CEK 로 암호화한  값. 
ECB모드를  사용하며 , Padding 이 필요할  시에는  PKCS#5 의 방식을  따른다 . 
 CID (4 bytes) : EMM 을 요청하는  콘텐츠  ID 나 Channel ID  
 CA Token : Client 의 결제  정보 . 
 
[EMM_Response Message] 
서버는  Client 의 EMM_Request 메시지에  대한  응답으로  EMM_Response 를 보낸다 . 
• EMM 요청  메시지에  대한  처리  결과가  success 라면 , 서버는  EMM 을 담은  
EMM_Response (Success Response) 를 보낸다 . 이 과정에서  CA Token 도용을  막기  위하
여 0절에서  정의된  EMM 의 CW Field 를 암호화하는  키와  0절에서  정의된  EMM 구조
에서  SK Field 를 암호화하는  키는  EMM 을 요청한  client 의 DK 가 아니라  
EMM_Request 시 함께  전송된  CA Token 내에  정의된  Device ID 에 해당하는  DK를 이용
한다 .  
• EMM 요청  메시지에  대한  처리결과가  failure 이라면 , EMM 을 포함하지  않은  
EMM_Response (Failure Response) 가 전송된다 .  
• 복수개의  콘텐츠에  대한  EMM 을 요청하였을  때, 전체  콘텐츠에  대한  EMM 발급이  불
가한  경우에만 , Failure Response 가 전송된다 . 즉, 하나라도  발급  가능한  EMM 이 있다
면, Success Response 가 전송된다 . EMM 이 전송되지  않는  이유를  확인하고  싶다면 , 
EMM이 전송되지  않은  콘텐츠의  CID로 EMM 을 발급  요청을  다시  보내서 , Reason 
field의 값으로  확인한다 .  정보통신단체표준 
TTAK.KO-08.0023 ６９ (mbs) (lsb)
76543210
1
23456
7
89
1011
12
1314151617
… EMM (n bytes)Reserved (3 bytes)Command (2 bytes)
Length (4 bytes)
Reason (3 bytes)
EMM Status (1 byte)Result (1 byte)Version (1 byte)
Type (1 byte)
()
ByteBit
 
(그림  A-11) EMM_Response Message 
• Version (1 byte) : 현재  Message 의 version. 현재  version 은 ‘0x01’. 
• Type (1 byte): Message 의 type. CAS Message 이므로  0x02 값을  사용 . 
 0x00 : CA Token Message Type  
 0x01 : DRM S/W Message Type 
 0x02 : CAS Message Type  
 Others are reserved. 
• Command (2 bytes): Command 의 type.  
 0x00 : EMM Request  
 0x01 : EMM Response  
 Others are reserved. 
• Length (4 bytes): Message 의 길이  
• Result (1 byte): EMM_Request Message 의 처리  결과 . 
 0x00 : Success     
 0x0f : Failure  
 Others are reserved.  
• Reason (3 bytes): Result 의 reason code  
 0x00 : Result 가 Success 일 때    
 0x01 : CA Token 의 Signature 가 올바르지  않을  때 
 0x02 : CA Token 의 유효기간이  지났음 . 
 0x03 : 폐기된  CA Token 을 사용했을  때 
 0x04 : Syntax Error. EMM Request Message 의 syntax 오류  
 0x05 : 다음  EMM을 발급할  수 있는  기간이  아님 . 
 0xff : Any other reasons 정보통신단체표준 
TTAK.KO-08.0023 ７０ Others are reserved.  
• EMM Status (1 byte): Request Message 가 원하는  EMM 의 상태 . 현재사용중인  EMM 에 
대한  요청인지  next EMM 에 대한  요청인지를  구분하는  값으로  쓰임 .  
 0x00 : 현재  EMM    
 0x01 : 다음  EMM  
 Others are reserved.  
• Reserved (3 bytes): 예약된  필드 . 
• EMM (m bytes): EMM  
 
A.4. 콘텐츠  Scrambling  
1) 콘텐츠  Format 및 Scrambling 영역   
콘텐츠  format 은 MPEG-2 TS 에 compatible 해야  하며 , TS packet 단위로  암호화된다 . 본 시
스템에서는  PES Level 의 암호화는  지원하지  않으며 , TS Level 의 암호화만을  지원한다 . 콘
텐츠를  구성하는  TS Packet 중 다음의  항목들은  암호화  되지  않는다 .  
• TS Header 
• Adaptation Field 
• PSI Packet 
• Null Packet 
• ECM (0 절에서  정의된  바와  같이  암호화가  되므로 , scrambling algorithm 을 이용하여  별
도 암호화되지  않음 ) 
•  
2) Scrambling 알고리즘  
MEPG-2 Transport Stream packet 은 ATIS 규격의  일부인  IIF DEFAULT SCRAMBLING 
ALGORITHM (IDSA) 을 사용해서  암호화  한다 .  
• TS Packet 의 Payload 만 Cipher Block Chaining(CBC) mode with AES-128 로 암호화  한다 .  
• CBC모드를  위한  Initialization Vectors(IV) 값은  0으로  설정된다 .  
 
[암호화  키 및 암호화  제어  필드 ] 
콘텐츠  암호화에  쓰이는  CW의 길이는  암호화  알고리즘에  따라  달라진다 .  
• 현 규격에서  지원하는  Scramble Algorithm 의 경우  AES-128 사용되며 , 키의  길이는  
16 bytes 이다 .  
 
CW는 주기적으로  변경되며 , even Key 나 odd Key 둘 중 하나로  분류된다 .  
TS packet 을 암호화하는데  쓰인  키의  종류는  해당  TS packet header 의 정보통신단체표준 
TTAK.KO-08.0023 ７１transport_scrambling_control 필드에  표시된다 . 해당필드는  TS packet 의 payload 가 암호화  되
었는지  여부와  암호화되었다면 , 어떤  type의 키로  암호화되어  있는지를  나타낸다 . <표 
A-2> 는 해당  필드의  값을  나타내고  있다 . 
 
Values Descriptioin 
00b Not scrambled 
01b User defined 
10b Even Key  
11b Odd Key  
<표 A-2> Values of transport_scrambling_control field 
 
 정보통신단체표준 
TTAK.KO-08.0023 ７２ 
APPENDIX B.  iCAS Stack Layer 분리  및 API 정의  
iCAS Stack Layer 분리  및 API 정의와  관련된  사항은  본 규격에서는  정의하지  않으며 , 추
후 수정  작업을  통하여  관련  사항을  업데이트하여  표준  규격을  업데이트  할 예정임 . 정보통신단체표준 
TTAK.KO-08.0023 ７３ 
APPENDIX C.  SVM Execution Flow (Informative) 
다음  그림은  SVM 에서  CAS S/W 를 실행하는  실시  예를  나타낸다 . (Linear-TV 시나리오 ) 
Start
EndS/W Load into SVM
Policy Load into SVMValidate S/W
S/W Init
(Event handling)EMM received?
Request Descramble
(Event handling)
Channel Change?Play the contentSuccess
Request SelectContent
(Event handling)
Quit Playing?
Request Termination
(Event handling)Success
N
N
YYFail
(Stop Playing)Fail
Fail
Player / COPP
S/W on SVMStart
EndS/W Load into SVM
Policy Load into SVMValidate S/W
S/W Init
(Event handling)EMM received?
Request Descramble
(Event handling)
Channel Change?Play the contentSuccess
Request SelectContent
(Event handling)
Quit Playing?
Request Termination
(Event handling)Success
N
N
YYFail
(Stop Playing)Fail
Fail
Player / COPP
S/W on SVMPlayer / COPP
S/W on SVM
 
(그림  C-1) 일반적인  CAS S/W Flow 
 
위 그림에서  노란색으로  표시된  부분은  Player 혹은  COPP Client 개체가  수행하는  작업을  
나타내고 , 녹색으로  표시된  부분은  SVM 내부에서  실행되는  CAS S/W 가 수행하는  작업을  
나타낸다 . 간략한  실행  순서는  다음과  같다9. 
1. COPP Client 는 다운로드  받은  CAS S/W 를 Load 루틴으로  SVM에 전달한다 . 
2. Load 루틴은  패키지가  전자서명을  포함하여  올바른  CAS S/W 인지  검사한다 .  
3. 코드  부분과  Policy 부분을  SVM에 적재한  후, 패키지의  헤더에  적힌  Code의 Entry Pointer
를 참조하여  Event Handler 를 등록하고  SVM이 Event를 처리할  수 있는  상태가  되도록  한다 . 
4. COPP Client 는 초기화  Event를 발생시킨다 . CAS S/W 는 초기화  Event를 처리한다 . 
5. CAS S/W 는 네트워크를  통해  원격지로부터  EMM을 수신한다 . 
6. Player는 해당  콘텐츠에  접근하여  재생을  시도한다 .  
7. Player 는 초기  Channel 에 대한  Select콘텐츠  Event를 발생시킨다 . CAS S/W 는 EMM 으로
부터  필요한  채널  재생에  필요한  Key 를 얻는다 . 
                                                      
9 CAS S/W 구현에 따라 실제로 실행되는 순서는 위 그림과 다를 수 있다.  정보통신단체표준 
TTAK.KO-08.0023 ７４8. Player가 수신한  콘텐츠는  CAS로 보호된  콘텐츠이므로 , Descramble Event 를 발생시켜 , CAS 
S/W가 descramble 처리를  하도록  요청한다 . 
9. CAS S/W 는 descramble Event 를 처리한다 . 내부적으로  EMM/ECM 처리  및 CW 처리를  할 
수 있으며 , Player 구현에  따라  H/W에 접근할  수 있다 . 
10. Player는 descramble 된 영상을  화면에  재생한다 . (재생  중에  Descramble Event 발생  및 처
리를  반복적으로  이루어  진다 .) 
11. Player가 다른  Linear-TV 채널의  영상을  재생해야  할 경우 , Player 는 선택된  channel에 대
한 Select콘텐츠  Event를 발생시킨다 . CAS S/W 는 EMM 으로부터  필요한  채널  재생에  필요한  Key 
를 얻는다 .  
12. 더 이상  콘텐츠를  재생하지  않을  경우 , Player는 Termination Event 를 발생시킨다 . CAS S/W
는 종료에  관련된  처리를  완료하고  종료된다 . 
13. Policy에 따라  CAS S/W 를 삭제한다 .  
 정보통신단체표준 
TTAK.KO-08.0023 ７５ 
APPENDIX D.  Example of Basic System Calls 
본 장에서는  기본적인  System Call 들을  정의한다 . 아래  표..는 System Call 의 수행  결과로  
return될 수 있는  값들의  목록을  보여준다 .. 
선언  값 의미  
SVM_SYSCALL_SUCCESS 0x00000000 성공적으로  수행  
SVM_SYSCALL_VIOLATION 0x80000100 Policy 에서  허용되지  않는  System call
SVM_SYSCALL_FAILED 0x80000101 치명적인  오류  발생  
SVM_SYSCALL_INVALIDPARAM 0x80000102 적절하지  않은  parameter 입력  
SVM_SYSCALL_NOTSUPPORT 0x80000103 지원되지  않는  Trap ID 
SVM_SYSCALL_ INVALIDSIGN
  0x80000104 유효하지  않은  전자서명으로  판명됨
SVM_SYSCALL_MSGTOOLONG 0x80000105 공개키  알고리즘에  입력으로  사용된  
값이  허용  길이보다  큰 길이를  가짐
<표 D-1> System Call Return 값 
 
아래  <표 D-2 >은 SVM 에서  지원하는  system call 들의  목록이다 .  
선언  값 의미  
SYSCALL_SetEventHandler 0x1001  
SYSCALL_SetEventMessageArea 0x1002  
SYSCALL_MemAlloc 0x1003 일정  크기의  메모리를  할당함  
SYSCALL_MemCopy 0x1004 메모리의  일정  영역을  다른  영역으로  
복사  
SYSCALL_MemSet 0x1005 메모리의  일정  영역을  주어진  값으로  
초기화  함 
SYSCALL_BlockXor 0x1006 두 개의  Buffer 에 대해  주어진  Byte 
길이  만큼에  대한   XOR 연산  결과를  
계산함  
SYSCALL_EPComplete 0x1007  
SYSCALL_GetCATokenCount 0x1008  정보통신단체표준 
TTAK.KO-08.0023 ７６SYSCALL_GetCATokenSize 0x1009 Index 에 해당하는  CA Token 의 길이를  
구함  
SYSCALL_ReadCAToken 0x100A Index 에 해당하는  CA Token 을 Buffer 에 
읽어들임  
SYSCALL_Random 0x100B 난수를  생성함  
SYSCALL_SHA1 0x100C SHA-1 을 이용해서  주어진  입력에  대한  
Message Digest 를 계산함  
SYSCALL_BlockCipher 0x100D BlockCipher 를 이용해서  입력에  대한  
암호화  및 복호화를  수행함  
SYSCALL_GenSignature 0x100E 주어진  입력에  대한  RSA 서명  값을  
계산함  
SYSCALL_VerifySignature 0x100F RSA 서명  값을  검증함  
SYSCALL_PKEncryption 0x1010 입력  값에  대한  RSA 암호문을  구함  
SYSCALL_PKDecryption 0x1011 입력  값에  대한  RSA 복호문을  구함  
SYSCALL_GetPublicKey 0x1012  
SYSCALL_SVMSpec 0x1013 현재  운용중인  SVM 에 대한  정보를  
얻어옴  
SYSCALL_GetTime 0x1014  
SYSCALL_MapContentBuffer 0x1015 Player 의 Content Buffer 주소를  얻어옴  
SYSCALL_SetDescrambleKey 0x1016 H/W Cipher Module 에 Descramble Key 를 
설정함  
SYSCALL_SocketOpen 0x1017 Secure Socket 을 생성함  
SYSCALL_SocketClose 0x1018 Secure Socket 을 닫음  
SYSCALL_SocketRead 0x1019 Secure Socket 에서  메시지를  얻어옴  
SYSCALL_SocketWrite 0 x101A Secure Socket 을 이용해서  메시지를  
전송  
<표 D-2> System Call 목록  
 
[Basic Operation]  
Event handeler 등록관련  System Call, 메모리  관련 (할당 , 복사 , XOR) System Call 에 관한  
API이다 . 정보통신단체표준 
TTAK.KO-08.0023 ７７ 
 SetEventHandler 
Definition: unsigned int SYSCALL_Se tEventHandler(unsigned char *pBuf) 
Operation: pBuf 의 값을  입력  받아  Event Handler 에 대한  Function Pointer 로 
SVM내에  유지  
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_INVALIDPARAM pBuf 가 null이거나  유효한  SVM 메모리  영역
이 아닌  경우  
 
 SetEventMessageArea 
Definition: unsigned int SYSCALL_SetE ventMessageArea(unsigned char *pBuf) 
Operation: pBuf 의 값을  입력  받아  Event Handler 의 Parameter Stack 의 주소로  SVM 내에  
유지  
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_INVALIDPARAM pBuf 가 null이거나  유효한  SVM 메모리  영역
이 아닌  경우  
 
 MemAlloc 
Definition: unsigned int SYSCALL_MemAlloc(uns igned char **pBuf, unsigned int nSize) 
Operation: nSize 만큼의  메모리를  할당하여  주소를  pBuf 에 저장  
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED 메모리  할당에  실패한  경우  
 
 MemCopy 
Definition:  
unsigned int SYSCALL_MemCopy(unsigned char  *pDest, unsigned char *pSrc, unsigned int 
nLen) 
Operation: pSrc 로부터  nLen 만큼의  byte를 pDest 로 복사  pSrc에서  읽는  영역과  pDest 에 
쓰는  영역이  overlapped 되는  경우에도  안전한  동작을  보장해야  함 
Return Value : 정보통신단체표준 
TTAK.KO-08.0023 ７８SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_INVA LIDPARAM pDest 또는  pSrc가 null pointer 인 경우  
 
 MemSet 
Definition:  
unsigned int SYSCALL_Memset(unsigned char *pDest, unsigned int bValue, unsigned int nLen) 
Operation: pDest 의 시작부터  nLen 개의  byte를 bValue 의 LSB 1-byte 값으로  설정함  
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_INVA LIDPARAM pDest 가 null pointer 인 경우  
 
 BlockXor 
Definition:  
unsigned int SYSCALL_BlockXor(unsigned ch ar *pDest, unsigned char *pSrc1, unsigned 
char *pSrc2, unsigned int nLen) 
Operation: pSrc1 과 pSrc2 의 bLen byte 만큼의  XOR 결과 . pDest 는 pSrc1 또는  pSrc2 와 
동일할  수 있음  
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_INVALIDP ARAM pDest, pSrc1, 또는  pSrc2 가 null pointer 인 경우  
 
 EventProcessingComplete 
Definition: unsigned int SYSCALL_EPComplete(void) Operation: Initialize 루틴  또는  Event 처리  루틴의  수행의  끝에  호출되어서  Instruction
의 해석을  중단하고  SVM 으로  하여금  다음  Event 를 기다리는  대기상태로  가도록  함 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
 
[COPP Interoperability] 
COPP Client 관련  (CA Token) System Call 에 관한  API이다 . 
 
 GetCATokenCount 정보통신단체표준 
TTAK.KO-08.0023 ７９Definition: unsigned int SYSCALL_Ge tCATokenCount(unsigned int *pCount) 
Operation: SVM 이 접근할  수 있는  CA Token 의 개수를  pCount 에 저장한다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED CA Token 접근에  실패함  
SVM_SYSCALL_INVALIDPARAM pCount 가 null인 경우  
 
 GetCATokenSize 
Definition: unsigned int SYSCALL_GetCAToke nSize(unsigned int nIndex, unsigned int 
*pCatokenSize) 
Operation: nIndex 에 해당하는  CAT 의 byte 길이를  확인하여  nCatSize 에 저장한다 . 
nIndex 는 0부터  시작하고  SYSCALL_GetCATCount 로 얻어진  크기보다  작아야  한다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED nIndex 에 해당하는  CA Token 접근에  실패함  
SVM_SYSCALL_INVALI DPARAM pCatokenSize 가 null인 경우  
 
 ReadCAToken 
Definition: unsigned int SYSCALL_ReadCAT( unsigned int nIndex, unsigned char *pBuf) 
Operation: nIndex 에 해당하는  CA Token 을 읽어  들여  pBuf 에 저장한다 . nIndex 는 0부
터 시작하고  SYSCALL_GetCATokenCount 로 얻어진  크기보다  작아야  한다 . pBuf 는 
GetCATokenSize() 를 이용하여  알아낸  크기만큼의  메모리가  할당되어  있어야  한다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED nIndex 에 해당하는  CA Token 이 존재하지   
않음  
SVM_SYSCALL_INVALIDPARAM pBuf 가 null인 경우  
 
[Cryptographic Operation] 
암호함수  관련  (Block 암호화 , 공개키  암호화  등) System Call 에 관한  API이다 . 
 
 Random 
Definition:  정보통신단체표준 
TTAK.KO-08.0023 ８０unsigned int SYSCALL_Random( unsigned char *pDest, unsigned char *pSeed, unsigned 
nSeedLen, unsigned int nLen) 
Operation: nLen 바이트만큼의  random number 를 생성하여  pDest 에 기록 . pSeed 는 null일 
수 있으며 , random 함수  내에서  시간  변수가  추가되기  때문에  seed가 동일하더라도  
pDest에 다른  값이  기록됨 . ANSI X9.31[6] 에 정의된  RNG 와 동등  하거나  이상의  암호
학적  성능을  갖고  있는  RNG 를 사용해야  함 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_INVA LIDPARAM pDest 가 null pointer 인 경우  
 
 SHA1 
Definition:  
unsigned int SYSCALL_SHA1(unsigned char *pDest, unsigned char *pSrc, unsigned int 
nSrcLen) 
Operation: nSrcLen 바이트  길이를  갖는  pSrc의 SHA-1 hash algorithm 을 이용한  message 
digest를 얻어서  pDest 에 기록 . pDest 의 길이는  20 바이트 . SHA-1 hash algorithm 은 FIPS 
PUB 180-2 에 정의되어  있다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_INVA LIDPARAM pDest 또는  pSrc가 null pointer 인 경우  
 
 BloackCipher 
Definition:  
unsigned int SYSCALL_BlockCi pher(unsigned char *pDest, uns igned char *pSrc, unsigned 
int nSrcLen, unsigned char *pKey, unsigne d int nKeyLen, unsigned int bAlgorithm) 
Operation: pSrc 를 암호화  또는  복호화  하여  pDest에 기록 . nSrcLen 은 Block cipher 의 한 Block의 
byte 길이를  나타냄 . bAlgorithm 의 값은  다음과  같다 . 
Block Cipher Algorithm Encryption Decryption 
DES 
(8 byte, 8 byte) 0x00 0x01 
2Key-TripleDES EDE 
(8 byte, 16 byte)  0x10  0x11 
AES128 
(16 byte, 16 byte) 0x20 0x21 
       ( ( ) 안의  값은  각각의  경우의  nSrcLen 과 nKeyLen 의 값) 정보통신단체표준 
TTAK.KO-08.0023 ８１AES는 FIPS PUB 197 에, DES, Triple DES 는 FIPS-46-3 에 정의되어  있다  
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_INVALIDPAR AM pDest, pKey, pSrc 가 null pointer 인 경우  
bAlgorithm_OPMode 에서  지정한  값과  
nSrcLen, nKeyLen 의 값이  다른  경우  
 
 Digital Signature Generation 
Definition:  
unsigned int SYSCALL_GenSignature(PK_ PARAM* pParam, unsigned char *pDest, 
unsigned int *pDestLen, unsigned char *pHashedSr c, unsigned int nHashedSrcLen, unsigned int 
key_id) 
Operation: pHashedSrc 에 대한  전자  서명  값을  계산하여  pDest 에 기록함 . key_id 가 
0xFFFFFFFF 인 경우에는  pParam 내의  환경  변수와  개인키  정보를  사용하고 , 그렇지  
않은  경우에는  pParam 을 무시하고 , device 가 가지고  있는  key_id 에 해당되는  개인키  
정보를  얻어와서  사용함 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED 수행  중 memory alloCA Tokenion failure 발생한  
경우  
적절하지  않은  Key 정보를  입력하여  전자서
명 계산이  불가능한  경우  
key_id 에 해당하는  개인키  얻어오기를  실패한  
경우  
SVM_SYSCALL_INVALIDP ARAM pParam, pDest 또는  pHashedSrc 가 null pointer
인 경우  
key_id 가 0xffffffff 인 경우에  pParam 내의  환
경 변수에  대한  pointer 가 null pointer 인 경우  
 
 Digital Signature VerifiCA Tokenion 
Definition:  
unsigned int SYSCALL_VerifySignature(PK_PA RAM* pParam, unsigned char *pHashedSrc, 
unsigned int nHashedSrcLen, unsigned char *pSi gnature, unsigned int nS ignatureLen, unsigned 
int key_id)  
Operation: pHashedSrc 에 대한  정당한  전자  서명  값인지  검증함 . key_id 가 0xffffffff 인 
경우에는  pParam 내의  환경  변수와  공개키  정보를  사용하고 , 그렇지  않은  경우에는  
device 가 가지고  있는  key_id 에 해당되는  개인키  정보를  얻어와서  사용함 . key_id 는 고정보통신단체표준 
TTAK.KO-08.0023 ８２정적으로  할당된  값이며 , SYSCALL_GetPublicKey 를 통해  key_id 는 추가될  수 있다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED 수행  중 memory allocation failure 발생한  경우  
적절하지  않은  Key 정보를  입력하여  전자서
명 계산이  불가능한  경우  
key_id 에 해당하는  개인키  얻어오기를  실패한  
경우  
SVM_SYSCALL_INVALIDPAR AM pParam, pSignature 또는  pHashedSrc 가 null 
pointer 인 경우  
key_id 가 0xffffffff 인 경우에  pParam 내의  환
경 변수에  대한  pointer 가 null pointer 인 경우  
SVM_SYSCALL_INVALIDSIGN 검증  과정은  성공적으로  수행되었으나 , 유효
하지  않은  전자서명으로  판명됨  
 
 Public Key Encryption 
Definition:  
unsigned int SYSCALL_PKEncryption(PK_P ARAM* pParam, unsigned char *pDest, 
unsigned int *pDestLen, unsigned char *pSrc, unsigned int nSrcLen, unsigned int key_id) 
Operation: pMsg 에 암호화를  적용하여  pEncMsg 에 기록함 . key_id 가 0xffffffff 인 경우에
는 pParam 내의  환경  변수와  공개키  정보를  사용하고 , 그렇지  않은  경우에는  device
가 가지고  있는  key_id 에 해당되는  개인키  정보를  얻어와서  사용함 .  
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED 수행  중 memory allocation failure 발생한  경우  
적절하지  않은  Key 정보를  입력하여  전자서
명 계산이  불가능한  경우  
key_id 에 해당하는  개인키  얻어오기를  실패한  
경우  
SVM_SYSCALL_INVALIDPARAM pParam, pEncMsg 또는  pMsg 가 null pointer 인 
경우  
key_id 가 0xffffffff 인 경우에  pParam 내의  환
경 변수에  대한  pointer 가 null pointer 인 경우  
 정보통신단체표준 
TTAK.KO-08.0023 ８３ Public Key Decryption 
Definition:  
unsigned int SYSCALL_PKDecryption(PK_P ARAM* pParam, unsigned char *pDest, 
unsigned int *pDestLen, unsigned char *pSrc, uns igned int nSrcLen, unsigned int key_id)  
Operation: pEncMsg 에 대한  RSA-1024 복호화를  적용하여  pMsg 에 기록함 . key_id 가 
0xffffffff 인 경우에는  pParam 내의  환경  변수와  공개키  정보를  사용하고 , 그렇지  않은  
경우에는  device 가 가지고  있는  key_id 에 해당되는  개인키  정보를  얻어와서  사용함 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED 수행  중 memory allocation failure 발생한  경우  
적절하지  않은  Key 정보를  입력하여  전자서
명 계산이  불가능한  경우  
key_id 에 해당하는  개인키  얻어오기를  실패한  
경우  
SVM_SYSCALL_INVALIDP ARAM pParam, pMsg 또는  EncMsg 가 null pointer 인 
경우  
key_id 가 0xffffffff 인 경우에  pParam 내의  환
경 변수에  대한  pointer 가 null pointer 인 경우  
 
 GetPublicKey 
Definition:  
unsigned int SYSCALL_GetPublicKey(unsigne d int CertType, unsigned char *pCert, 
unsigned int nCertLen, unsigned int *key_id) 
Operation: 인증서가  저장된  Buffer 를 Parsing 해서  인증서에  포함된  공개키를  SVM 에 
저장하고 , 해당  key_id 를 반환함  
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_INVALIDPARAM pCert 또는  key_id 가 null pointer 인 경우  
SVM_SYSCALL_INVALIDSIGN 유효하지  않은  인증서가  입력된  경우  
 
[Device Operation] 
H/W Device Specific 관련  System Call 에 관한  API이다 . 
 
 GetTime 정보통신단체표준 
TTAK.KO-08.0023 ８４Definition: unsigned int SYSCALL_GetTime(unsigned char *timer) 
Operation : 8-byte 형식으로  현재  UTC 시간을  반환  
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED System 이 Clock 관련  API를 지원하지  않는  
경우  
SVM_SYSCALL_INVALIDPARAM timer 가 null pointer 인 경우  
 
 Map Content Buffer 
Definition: unsigned int SYSCALL_MapContentBu ffer(unsigned int Addr, unsigned int *length) 
Operation : Player 의 물리적인  컨텐츠  버퍼의  주소를  Addr 로 넘기면 , SVM 메모리  중 
Content Buffer Area (0xF0000000 번지 )에 컨텐츠  버퍼를  mapping 시킨다 . length 에는  컨텐
츠 버퍼의  길이를  넘기고 , 결과로  실제  mapping 된 길이로  반환된다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED Content Buffer 에 대한  접근이  실패한  경우  
SVM_SYSCALL_IN VALIDPARAM Addr 이 0인 경우  
Length 가 null pointer 인 경우  
 
 SetDescarmableKey 
Definition:  
unsigned int SYSCALL_SetDescr ambleKey(unsigned char * pK ey, unsigned int nKeyLen, 
unsigned int *flag)  
Operation : Type 2 Player 인 경우 , 컨텐츠  descramble 을 위한  CW를 nKenLen 의 길이를  
갖는  pKey 로 H/W에 설정하고  H/W descramble 을 활성화  시킨다 . H/W specific 한 flag로 
도 함께  전달한다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED H/W descrambler 가 사용  불가능한  경우  
Type 1 player 인 경우  
SVM_SYSCALL_IN VALIDPARAM pKey 가 null pointer 인 경우  
nKeyLen 이 암호화  알고리즘에  맞지  않는  값
인 경우  정보통신단체표준 
TTAK.KO-08.0023 ８５ 
[Network Operation] 
Network 지원을  위한  Socket 관련  System Call 에 관한  API이다 . 
 
 SocketOpen 
Definition:  
unsigned int SYSCALL_SocketOpen(unsigne d int nIPAddr, unsigned int nPort, int 
*pDescriptor) 
Operation : nIPAddr 의 IPv4 형식의  주소를  갖는  서버의  nPort 가 지정하는  포트에  TCP-
IP 연결을  시도하여  성공할  경우  pDescriptor 에 Socket Descriptor 를 반환한다 . 예를  들
어, 접속하고자  하는  서버의  IP Address 가 192.168.123.1 인 경우  nIPAddr 의 값은  
0xC0A87B01 이 된다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED 연결에  실패한  경우  
SVM_SYSCALL_INVALI DPARAM pDescriptor 가 null pointer 인 경우  
 
 SocketClose 
Definition: unsigned int SYSCA LL_SocketClose(int nDescriptor) 
Operation : nDescriptor 에 해당하는  Socket Descriptor 를 갖는  Socket 을 닫는다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED 해당  Socket Descriptor 를 닫는데  실패한  경우  
 
 SocketRead 
Definition:  
unsigned int SYSCALL_SocketRead(int nDescrip tor, unsigned char *pBuf, int *pMsgLen, 
unsigned int nBufMaxLen) 
Operation : nDescriptor 에 해당하는  소켓에서  메시지를  읽어  와서  pBuf 에 저장한다 . 읽
어온  메시지의  길이는  pMsgLen 에 저장된다 . nBufMaxLen 은 pBuf 에 저장될  수 있는  
메시지의  최대  길이이다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED Socket 에서  메시지를  읽는데  실패한  경우  정보통신단체표준 
TTAK.KO-08.0023 ８６SVM_SYSCALL_INVALIDPARAM pBuf 또는  pMsgLen 이 null pointer 인 경우  
 
 SocketWrite 
Definition:  
unsigned int SYSCALL_SocketWrite(int nDescr iptor, unsigned char *pBuf, unsigned int 
nMsgLen, int *pSendLen) 
Operation : nDescriptor 에 해당하는  소켓을  이용해서  nMsgLen byte 의 길이를  갖는  pBuf
에 저장된  메시지를  전송하고  실제로  전송에  성공한  메시지의  byte 길이를  nSendLen
에 저장한다 . 
Return Value : 
SVM_SYSCALL_SUCCESS 성공적으로  수행  
SVM_SYSCALL_FAILED Socket 에 메시지를  쓰는데  실패한  경우  
SVM_SYSCALL_INVALIDPARAM pBuf 또는  pSendLen 이 null pointer 인 경우  
 
 
  
 정보통신단체표준 
TTAK.KO-08.0023 ８７표준작성 공헌자  
표준 번호 : TTAK.KO-08.0023  
 이 표준의 제 ․개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다.   
 
구분 성명 위원회 및 직위 연락처 소속사 
과제제안  IPTV 프로젝트그룹(PG219)   
표준초안
제출 황용호 IPTV 보안 실무반(WG2194) 
위원 yongh.hwang@samsung
.com 삼성전자 
표준초안  
검토 최문영 IPTV 보안 실무반(WG2194)
의장 moonyoung@samsung.c
om 삼성전자 
 외 실무반 위원   
이근구 IPTV 프로젝트 그룹(PG219) 
의장 kklee@tta.or.kr TTA 
 외 프로젝트그룹 위원   
표준안심
의  민경선 전송통신 기술위원회 의장 Minks808@paran.com KT CS 
 외 기술위원회 위원   
사무국담
당 박정식 정보통신팀 팀장 031-724-0080 
jspark@tta.or.kr TTA 
오구영 정보통신팀 차장 031-724-0081 
ohky@tta.or.kr TTA 
 
   정보통신단체표준  
TTAS.xx-07.xxxx 88 
 
 
 
 
 
 
 
 
 
 
 
 
  
 
 
 
정보통신단체표준 
 
IPTV 용 교환 가능한 CAS(iCAS) 
(IPTV Interchangeable CAS(iCAS)) 
 
발행인:  이근협  
발행처:  한국정보통신기술협회  
463-824, 경기도 성남시 분당구 서현동 267-2  
연락처:  031-724-0114, Fax : 031-724-0019  
발행일:  2010. 03