Get documents about "INTERNATIONAL TELECOMMUNICATION UNION
Document Sample
INTERNATIONA L TELECOMMUNICATION UNION FOCUS GROUP ON IPTV
TELECOMMUNICATION FG IPTV-DOC-XXXX
STANDARDIZATION SECTOR
STUDY PERIOD 2005-2008 English only
WG(s): 3 3rd FG IPTV meeting:
Mountain View, USA, 22-26 January 2007
OUTPUT DOCUMENT
Source: Editor
Title: Living list: IPTV Security Aspects
1 Scope............................................................................................................................. 2
2 References..................................................................................................................... 2
3 Definitions and Terms .................................................................................................. 2
4 Abbreviations and acronyms ........................................................................................ 3
5 Security Threats ............................................................................................................ 3
5.1 Content Security Threat.................................................................................. 5
5.2 Service Security Threat .................................................................................. 9
5.3 Network Security Threat ................................................................................ 11
5.4 Terminal Device Security Threat ................................................................... 13
5.5 Subscriber Security Threat ............................................................................. 15
6 Security Requirements .................................................................................................. 16
6.1 Content Security Requirement ....................................................................... 17
6.2 Service Security Requirement ........................................................................ 21
6.3 Network Security Requirement ...................................................................... 25
6.4 Terminal Device Security Requirement ......................................................... 28
6.5 Subscriber Security Requirement ................................................................... 31
7 Security Architecture .................................................................................................... 31
7.1 Security Trust Model ...................................................................................... 32
7.2 Security General Framework.......................................................................... 32
7.2.1 Content Protection Architecture ..................................................................... 32
7.3 Security Function Modules............................................................................. 37
7.4 Security Interfaces .......................................................................................... 41
8 Security Mechanisms .................................................................................................... 41
8.1 Content Security Mechanisms ........................................................................ 41
Mr. Weijun LEE Tel: +1 214 420 8421
Contact: ZTE Corporation Fax: +1 972 671 8333
P.R. China Email: wlee@zteusa.com
Attention: This is a document submitted to the work of ITU-T and is intended for use by the participants to the activities of ITU-T's
Focus Group on IPTV, and their respective staff and collaborators in their ITU-related work. It is made publicly available for
information purposes but shall not be redistributed without the prior written consent of ITU. Copyright on this document is owned by
the author, unless otherwise mentioned. This document is not an ITU-T Recommendation, an ITU publication, or part thereof.
-2-
FG IPTV-DOC-0045
8.1.1 Content Protection .......................................................................................... 44
8.1.2 Conditional Access ......................................................................................... 44
8.1.3 Digital Rights Management............................................................................ 45
8.2 Service Security Mechanisms......................................................................... 50
8.2.1 Service Authentication ................................................................................... 50
8.2.2 Service Authorization ..................................................................................... 50
8.3 Network Security Mechanisms....................................................................... 51
8.4 Terminal Device Security Mechanisms.......................................................... 51
8.4.1 Terminal Device Authentication .................................................................... 51
8.4.2 Terminal Device Authorization ...................................................................... 52
8.4.3 Terminal protection ........................................................................................ 52
8.5 Subscriber Security Mechanisms ................................................................... 53
8.5.1 Subscriber Authentication .............................................................................. 53
8.5.2 Subscriber Authorization ................................................................................ 54
8.5.3 Subscriber information Protection.................................................................. 54
Editors Note: The following BEGIN and END identifier is an inte rnal label that designates
materials boundary in this document. This label is expected to be used for internal tracking
purposes.
***********************From Old output Document**********************************
------------BEGIN:
1 Scope
TBD.
2 References
The following ITU-T Recommendations and other references contain provisions, which, through
reference in this text, constitute provisions of this Document. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision; all
users of this Document are therefore encouraged to investigate the possibility of applying the most
recent edition of the Recommendations and other references listed below. A list of the currently
valid ITU-T Recommendations is regularly published.
….
3 Definitions and Terms
This Document defines the following terms:
TBD.
2
-3-
FG IPTV-DOC-0045
4 Abbreviations and acronyms
This Document uses the following abbreviations.
TBD.
5 Security Threats
Editors Note: the following materials should be considered for inclusion in security threat
section of OD.
This section describes a set of identified security threats that some require ment or mechanis m
of this document addresses.
Editors Note: The following SEC_THREAD_0000 identifie r is an internal label that
designates a particular threat that is discussed by this docume nt. This label is expected to be
used for internal tracking purposes.
SEC_THREAT_0000:
The following conceptual threat model provides a classification of the related threats to the IPTV
system. This threat model requires significantly more refinement to define the complete list of
known risks and mitigations. This model does not include network security threats which exist in all
IP networks and assumes that such threats have been mitigated.
Co mpro mise
IPTV So lution
Information
Content Theft Service Theft Theft Service System Control
Disruption
Figure 1 - Compromise IPTV Solution Attack Tree
Editors Note: the following materials will not be included in OD.
SEC_THREAT_0001: Protected assets of IPTV
Editors Note: Determine level(s) and target(s) of this threat description.
Editors Note: It is felt that the description and figure below is incomplete, and does not deal
with all end-to-end issues.
The service chain of an IPTV service can be divided into four parts: Content Source, Service
Integration & Operations, Content Transport and Content Consumption, as illustrated in figure 2
below.
3
-4-
FG IPTV-DOC-0045
Note:
1) Content Source: The content providers that own or are licensed to sell content to IPTV service
providers.
Editors Note: Conve rt adopted text to acceptable English.
2) Service Integration & Operation: IPTV service platform processes (e.g. marking with a
watermark, programming, etc.) various contents gathered from the content source, and then presents
these programs through IP network to the subscribers in some certain fashions.
3) Content Transport: Transport network is usually composed of access network metro network and
core network, and often with an overlay CDN (Content Distribution Network) to enhance the IPTV
service. The IPTV transport network should deliver the packets from service provider to subscribers
transparently without modification.
4) Content Consumption: in this part, the packets received from the network are decoded to display
on the terminal. Not only the equipment such like STB and television, handset, PC may be used for
service consumption, but also a home networking of terminals and related devices can be used here.
Based on figure 2 below, the assets that need to be protected in IPTV service are:
Content Source: the original media contents owned by content providers, such as TV programs,
movies, music etc.
Service Integration & Operation: IPTV service platform (physical equipments, system and
application software), the programs, operation information (such as service log, billing
information), and subscribers’ information (login, subscriber's privacy) etc.
Content Transport: common network equipments (e.g. routers, switches), network bandwidth,
packets transport through network, multicast service, CDN (e.g. server, database) etc.
Content Consumption : terminal equipments (such as STB) or home networking (hardware and
software).
4
-5-
FG IPTV-DOC-0045
TV
Music CDN
IPTV Service IP based
Movie Platform Network
…
Content Service Integration & Content Content
Source Operation Transport Consumption
Living T V EPG based EPG based
Movie… program program
Content Service Network Subscribers
Providers Providers Operators
Figure 2 – IPTV Service chain
5.1 Content Security Threat
Editors Note: Describe category of content security threat(s).
Editors Note: Determine level(s) and target(s) of this threat description.
Editors Note: the following materials should be considered unde r subscribe r security threats.
SEC_THREAT_0002: Content Source
Editors Note: The following description of a threat appears to raise a require ment on content
itself that is external to commonly unde rstood security requirements. Pass along this to WG1
for resolution then delete from next version of this docume nt.
Here the key problem is how to ensure that the contents are compliant with law/regulatory and
business requirements (e.g. observe various copyright laws, prevent the unallowable racist or
sexually explicit materials, etc). Current technical and management protection systems can be used
as much as possible.
-----------------END
************************from old living list*************************************
5
-6-
FG IPTV-DOC-0045
------------BEGIN:
Editors Note: the following materials should be considered unde r terminal security threats.
SEC_THREAT_000x: Content consumption
The failure of the terminal equipments (hardware and software) caused by malicious
codes/viruses from the network.
Remote theft of the subscribers’ important information (e.g. login ID and password) by
malicious programs, such as Trojan horse.
Unauthorized duplication, redistribution or any other threats to the copyrights of programs
received from networks.
ID_SEC_THREAT_000x: Content Transport
Editors Note: the following materials should be considered unde r transport security threats.
Accidental threats which can result in network equipments failure or transport service
interruption: a threat without malicious intent, such as a power failure, a technical hitch of the
equipment, etc.
Intentional threats aim at the network equipments or resources (bandwidth): malicious attacks
(e.g. denial of service attack, unauthorized access) to the transport network.
Legitimate consumers abuse the service network resources, and result in huge garbage
information which is harmful to the network.
Security of multicast protocols: there are no security protections (such as authentication to the
multicast source, control of multicast group members) in the basic IP multicast protocols, so the
multicast security will be one important problem in IPTV transport network.
Unauthorized data deletion, insertion, modification, re-ordering, replay or delay.
Unauthorized data (i.e. the data come from the illegal IPTV program sources) transmission.
Masquerade IPTV service nodes in the carrier network.
Security threats to CDN.
Editors Note: consider the following 2 and 4 under security requirements section in OD,
bullets 1,3 and 5 are excluded at this time.
ID_SEC_THREAT_000x: Security Objectives
IPTV service should be high stable and high available.
Only legitimate actors can access and operate on the assets of IPTV services after be authorized.
The legitimate users’ abuse actions should be controlled to reduce garbage data.
The IPTV service should be protected against unauthorized deletion, insertion, modification or
replay attack.
The IPTV service programs should be protected by copyrights.
6
-7-
FG IPTV-DOC-0045
Editors Note: consider the following under security threats section in OD.
- ID_SEC_REQ_00xx:Security requirements against abuse and threats
There are various rights associated with content. To realize IPTV services that respect these
rights, it is necessary to protect against any perceived threats to those rights. Such perceived
threats can be broadly divided into three kinds, of three different levels.
1） Unintentional misuse by legitimate users
2） Intentional individual- level abuse by hackers or other illegitimate users
3） Deliberate efforts to influence or crack the overall system by groups with a certain degree
of financial resources
To ensure resistance against these perceived threats, a security policy needs to be established
for every IPTV system, as well as a system to implement the policy.
Furthermore, since IPTV services can include infrastructural elements that bear closely on
the lives of users, it is necessary to give this point due consideration.
-----------------END
**************************From the contributions Busan meeting*********************
----------------BEGIN
Editors Note: the following description can be moved to OD unde r architecture section or
under security threats section.
Assets to be protected in IPTV service:
The service chain of an IPTV service can be divided into four parts: Content Source, Service
Integration & Operations, Content Transport and Content Consumption.
Content Source/Content provider: T he entity that own or are licensed to sell content to IPTV
service providers. Although the Service Provider is the primary source for the client at Home, a
direct logical information flow may be set up between Content Provider and subscriber e.g. for
rights management and protection.
Service Integration & Operations/Service provider: the entity providing a service to the end-
user. The Service Provider acquires/licenses content from Content Providers and packages this
into a service. In this sense the service provider is not necessarily transparent to the application
and content information flow.
Content Transport/Delivery network: The delivery network usually is composed of access
networks and core or backbone networks, using a variety of network technologies. The deliver y
network is transparent to the IP traffic.
Content Consumption/Consumer: the domain where the IPTV services are consumed. In this
part a single terminal may be used for service consumption, but also a network of terminals and
related devices may be present for this purpose.
The assets that need to be protected in IPTV service are:
Content: broadcast TV content, VOD content, and PVR content.
7
-8-
FG IPTV-DOC-0045
IPTV service resource: servers such as media servers, AAA servers, DRM servers, ..., and
operation information such as service logs and billing information.
IPTV bearer network: equipments (e.g. routers, switches), bandwidth, multicast services, and
CDN.
Subscribers’ information: identity information, billing information, and information about
subscriber's privacy.
Content assets, which reside on transit networks controlled by IPTV businesses along the
distribution chain, on networks owned by the IPTV consumer and on the IPTV terminal
device.
Network assets, which are networks operated by entities along the distributio n chain, and
the home network of the residential consumer.
Service assets, which support network services and IPTV applications.
Terminal assets, which the residential consumer uses to process and store content works
and other information related to the IPTV service.
Subscribe r assets, which consist of information about the subscriber, the subscriber
household, and their IPTV transactions that are processed at multiple points along the IPTV
delivery chain.
Editors Note: the following materials should be considered unde r security threats section of
OD.
Threats to the digital content may include:
Interception: a breach of confidentiality of the digit content by illegal monitoring the service
networks.
Loss or corruption of the digital content: Actions to destroy the integrity of the digital content
transferred, such as unauthorized deletion, insertion, modification, re-ordering …
Unauthorized viewing.
Unauthorized copying.
8
-9-
FG IPTV-DOC-0045
Table 1: Content Work ART
ASSET RISK SEVERITY THREAT LIKELIHOOD
Compressed, Unauthorized copy High if the work is Cracker High
plaintext content obtained from within the release
work network, network window or deemed Professional
device or end highly valuable by
system the provider; Insider
Medium to Low
depending on the Consumer Medium to Low
work.
Compressed, Unauthorized Low Cracker Low unless the
encrypted content access Professional key is obtained
work and High
Insider otherwise
Consumer Low
Any content work Denial of service High Cracker Low
attack Professional Low
Insider Low
Consumer Low
--------------------END
5.2 Service Security Threat
************************from old living list*************************************
------------BEGIN
TBD.
Editors Note: the following materials should be considered unde r service security threats
section of OD.
ID_SEC_THREAT_000x:Service integration & Operation
Accidental threats which result in service interruption: threats without malicious intent, such as
a power failure, a technical hitch of an equipment, etc.
Intentional threats aiming at service platform: malicious attacks (e.g. denial of service attack,
unauthorized access) to the IPTV service platform or viruses infection.
Impingement copyrights of the programs which IPTV service platform provided to the
subscribers.
Stealing/eavesdropping subscribers’ important information (e.g. login ID or password).
Attempt to collection, spread or sale the information of subscribers’ privacy without their
permission.
-----------------------END
9
- 10 -
FG IPTV-DOC-0045
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: the following materials should be considered unde r security threats section of
OD.
Such perceived threats can be broadly divided into three kinds, of three different levels.
4） Unintentional misuse by legitimate users
5） Intentional individual- level abuse by hackers or other illegitimate users
6） Deliberate efforts to influence or crack the overall system by groups with a certain degree
of financial resources
Editors Note: the following materials should be considered unde r service security threats
section of OD.
Threats to IPTV service:
Unauthorized service access: A user attempts to access IPTV service in violation of the security
policy in force.
Masquerading / spoofing IPTV service provider.
Malicious threats aiming at the IPTV servers (AAA servers, media servers, etc…): may
include the hacking aiming at security leaks in application software or communication protocol,
denial of service attack, etc.
Theft (often use malicious programs, such as Trojan horse) of the subscribers’ information (e.g.
identity information, billing information, subscription information).
Editors Note: the following materials should be considered unde r service security threats
section of OD.
Table 2:
10
- 11 -
FG IPTV-DOC-0045
ASSET RISK SEVERITY THREAT LIKELIHOOD
Domain Name Denial of service Medium Cracker High
Server attack Professional Medium
Insider Low
Consumer Low
Unauthorized High Cracker High
access Professional Medium
Insider Low
Consumer Low
Electronic Denial of service High Cracker High
Program Guide attack Professional Medium
Insider Low
Consumer Low
Unauthorized High Cracker High
access Professional Medium
Insider Low
Consumer Low
Media Servers and Denial of service High Cracker High
multiplexers attack Professional Low
Insider Low
Consumer Low
Unauthorized High Cracker High
access Professional Low
Insider Low
Consumer Low
CAS and Denial of service High Cracker High
Subscriber attack
Professional Low
Management
Insider Low
Consumer Low
Unauthorized use High Cracker High
Professional Low
Insider Low
Consumer Low
--------------END
5.3 Network Security Threat
11
- 12 -
FG IPTV-DOC-0045
************************from old living list*************************************
------------BEGIN
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: the following materials should be considered unde r network security threats
section of OD.
Intentional threats aiming at the network equipments or resources (bandwidth): malicious
attacks such as denial of service to the bearer network.
Security threats to multicast technical used in IPTV bearer network: such as masquerading /
spoofing multicast TV sources, or illegitimate multicast group members.
Malicious attacks (like DOS, hacking) on nodes in Content Distribution Network.
Editors Note: the following materials should be considered unde r network security threats
section of OD.
The following table lists assets, risks and threats for the Core Network,.
Table 3:
12
- 13 -
FG IPTV-DOC-0045
ASSET RISK SEVERITY THREAT LIKELIHOOD
Network Denial of service Medium Cracker High
bandwidth attack Professional Medium
Insider Low
Consumer Low
Unauthorized High Cracker Medium
access or use Professional High
Insider Low
Consumer Low
Network Messages Unauthorized High Cracker High
access Professional Medium
Insider Low
Consumer Low
Unauthorized High Cracker High
modification Professional Medium
Insider Hlowigh
Consumer Low
Replay High Cracker High
Professional Medium
Insider Low
Consumer Low
Routers, Denial of service High Cracker High
intermediate attack Professional Medium
systems, access
servers and system Insider Low
hosts Consumer Low
Unauthorized use High Cracker High
Professional Medium
Insider Low
Consumer Low
--------------END
5.4 Terminal Device Security Threat
************************from old living list*************************************
------------BEGIN
--------------END
**************************From the contributions Busan meeting*********************
13
- 14 -
FG IPTV-DOC-0045
----------------------BEGIN
Editors Note: the following materials should be considered unde r terminal device security
threats section of OD.
Some security threats for IPTV terminal devices are listed as follows.
Illegally accessing clear content by tampering device hardware or software. For example,
clear contents can be copied by bus data interception or DRM software cracking.
Illegally accessing keys or other secret information in devices using software cracking or
hardware tampering. Attackers can tamper the device memory or analyze the data flow to
obtain the keys and other secrets. Content key exposure results in content leakage and
device key leakage leads to device impersonation.
Illegally accessing user private information stored in devices using hardware or software
methods. Attackers can tap part of devices to get the users’ ID or other private information.
Device malfunctioning by hardware methods, such as control of the device clock system to
disable the functions of the DRM/CAS systems, or by software methods, such as
installation of viruses to exhaust the device resources.
Accidental threats by users’ mistakes, such as unintentional deletion of system information
or sudden power off during the operation.
Editors Note: the following materials should be considered unde r terminal device security
threats section of OD.
Unauthenticated terminal devices connecting to the home network.
The failure of the receiving terminal (hardware and software) caused by malicious attacks or a
mass of unwanted traffic from the network.
Editors Note: the following materials should be considered unde r terminal device security
threats section of OD.
Table 4: Terminal
ASSET RISK SEVERITY THREAT LIKELIHOOD
Locality Fixed-location Medium Cracker Low
device that is Professional Low
outside residence
is given service Insider Low
Consumer Medium
Mobile device Medium Cracker Low
owned by non- Professional Low
subscriber is given
service Insider Low
Consumer Medium
Processor and Disk Infection by High Cracker Low unless
malware executables
downloaded from
14
- 15 -
FG IPTV-DOC-0045
the network
Professional Low
Insider Low
Consumer Low
Unauthorized use High Cracker Low
Professional Low
Insider Low
Consumer Low
Interface Subversion of Medium Cracker Low
content protection Professional Low
controls (e.g.
HDCP, HDMI) Insider Low
Consumer Low
Editors Note: the following materials should be considered unde r terminal device security
threats section of OD.
Unauthorized use by subscribers
Attacks on the home network, unknown even to the subscriber
It is thought that attacks such as viruses are usually directed at highly diffused OSs. For this
reason, in the early stages of IPTV services such attacks are not likely to be a problem.
However, as the diffusion rate increases, this issue will have to be seriously considered.
Particularly in the case when receivers have the capability of communicating with each other,
there is a risk that virus infections will be able spread. Thus, IPTV terminals will require
similar care to the PCs connected to the network.
Intentional attacks on receivers by subscribers
One type of external access that is envisaged is the unauthorized output of stored video from a
receiver to an external recording device. Once content is output from memory/HDD, it is
extremely difficult to control its copying and other manipulation, even if it is possible to
implement some kind of deterrent effect.
--------------END
5.5 Subscribe r Security Threat
************************from old living list*************************************
------------BEGIN
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
15
- 16 -
FG IPTV-DOC-0045
Editors Note: the following materials should be considered unde r subscribe r security threats
section of OD.
Threats to subscribers
Protection of personal data on the network
Protection of personal data maintained in receivers
Protection of legal minors
Editors Note: the following materials should be considered unde r subscribe r security threats
section of OD.
Table 5 : Subscriber ART wi th Severity and Likelihood of Attack
ASSET RISK SEVERITY THREAT LIKELIHOOD
Subscriber Unauthorized High Cracker Medium
information access: Disclosure Professional Medium
to unauthorized
party Insider Low
Consumer Low
Unauthorized High Cracker Medium
access: Professional Medium
Modification by
unauthorized party Insider Low
Consumer Low
Transaction Unauthorized High Cracker Medium
information access: Disclosure Professional Medium
Credit card info to unauthorized
party Insider Low
Consumer Low
Unauthorized High Cracker Medium
access: Professional Medium
Modification by
unauthorized party Insider High
Consumer Low
--------------END
6 Security Requirements
************************from old living list*************************************
------------BEGIN
Editors Note: consider the following under security re quireme nts section in OD.
- ID_SEC_REQ_00xx:Requirements for realizing the division of roles in the business model
IPTV services are realized not just by the content provider who serves as the principal agent of
the service, but rather through the coordinated efforts of multiple business players, including
also the content rights holder, the network provider, and the CPE (Consumer Premise
16
- 17 -
FG IPTV-DOC-0045
Equipment) manufacturer. Security functions need to be clear about the division of these
separate roles and the realization of these various operations. It is vital to strike a balance
between the distribution of content and the distribution of the money paid for it, in order to
enable a backwards flow of profitability, in line with the rights that each player possesses and
the costs related to service provision. The requirements for this are listed below.
- ID_SEC_REQ_00xx:Functional requirements
There are requirements other than those relating to items 1.1 and 1.2 above. IPTV services for
the home use the same CPE as current broadcasting services, so it is necessary to consider the
questions of sharing specifications and usability with broadcasting services. These functional
requirements are enumerated below.
1） Copyright of content and related data
2） Content protection, e.g. connection of external devices to CPEs, recording controls
3） Billing controls for paid content
4） Ensuring access rights to CPEs
5） Protection against unauthorized access to servers
6） Protection of personal data, etc. relating to CPEs
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
--------------END
6.1 Content Security Require ment
************************from old living list*************************************
------------BEGIN
TBD.
Editors Note: do not consider the following in OD .
ID_SEC_REQ_0000:
Content Security-Combined with business scenarios of network provide r and service
provide r:
- Separation between public free materials and secured materials
- Optionally selectable depending on materials
ID_SEC_REQ_0001:
Digital Rights Management & Content protection--Various options depending on middle ware
and application platform
- Digital Right Management and CAS (Conditional Access System)
Editors Note: do not consider the following in OD .
17
- 18 -
FG IPTV-DOC-0045
ID_SEC_REQ_000X:
Digital Rights Management (DRM) is sometimes thought of as the ―digital management of rights‖
or as the ―management of digital rights‖. In fact, DRM provides the ―digital management of rights
to digital assets‖. DRM combines Conditional Access and Copy Protection, this combination allows
the addition of richness to the policies that can be expressed and enforced on protected assets. DRM
allows assets to be protected and then a variety of policies specified by the asset owner on how the
asset may be used.
ID_SEC_REQ_000X:
- Conditional Access (CA) provides the restriction of content viewing to authorized users through
scrambling or encryption of media.
ID_SEC_REQ_000X:
-Copy Protection (CP) prevents or limits the duplication of assets.
ID_SEC_REQ_000X:
-Digital Watermarking (DM) allows for the insertion of hidden information in digital content which
allows forensic analysis to determine the source of the media if it’s copyright is violated, indicating
a path of distribution.
Editors Note: do not consider the following in OD
-Security requirements for IPTV Content Stratum
Security require ments for content provider- Copyrights protection for contents: IPTV
content provider should use digital watermark technologies to protect the copyrights of contents
they owned or sold from unauthorized duplicating or any other threats.
Security require ments for service provide r- Copyrights protection for contents: Service provider
should use some DRM technology to prevent the under way programs being spied, copied, and
redistributed illegally.
Protection for legality of contents: IPTV service providers should ensure that the media contents
broadcast via their network must be compliant with law/regulatory requirements issued by national
or local authorities, e.g. Acts about content rating or children’s protection.
Security require ments for subscriber- Copyrights protection for contents: Subscriber’s devices
must have a DRM function module which cooperates with server side DRM system to protect the
copyrights of contents.
Editors Note: do not consider the following in OD, conside r content labelling requirements.
When deploying IPTV service, it is suggested that IPTV content security should be considered,
including DRM and content surveillance(?monitoring) legitimately.
Editors Note: consider the following under the content security and service security
require ment sections in OD.
Inte roperability.
18
- 19 -
FG IPTV-DOC-0045
The following areas represent key interoperability elements that are required in the DRM-EE,
DRM-B and DRM-IX modes.
Authentication of devices, users and DRM systems
Before content can be exchanged between entities, the identity of the receiving device and possibly
its user(s) must be confidently established. Also, since content providers may not trust specific
DRM systems, it is important that it be possible to authenticate the receiving DRM system(s) or
implementation levels before exchanging content. This authentication should have a sound
cryptographic basis and may employ various well-known digital signature techniques. Public Key
cryptography in particular provides a sound mechanism for digital signatures in authentication
protocols.
Rights Expression Exchange
Different DRM systems use different rights expression languages or license formats. For DRM-B
and DRM-IX modes to function, some means for a common rights expression is required. This
could take the form of a common rights expression language (REL) or a rights expression translator.
Another possible rights expression exchange mechanism is license negotiation.
Common encryption algorithms for content exchange
For content to pass securely from the control of one DRM system to another or within the same
DRM system but on different physical devices, content encryption is required. This renders the
content unusable except for entities that possess the appropriate key or keys necessary for
decryption to occur. There are many different types of encryption algorithms (e.g. block ciphers,
stream ciphers, public-key-based, etc.) but generally those that use symmetric keys tend to be best
suited for high-speed content exchange. For interoperability purposes, some small number of
commonly agreed algorithms must be chosen. Ideally, one default algorithm would also be
specified.
Key management and/or exchange for the common encryption algorithms
Before secure content exchange can take place, keys to be used in specific instances need to be
exchanged or commonly generated by the authenticated entities. Key management is usually the
most difficult part of a security system to implement. Techniques such as Public Key cryptography
have simplified device key distribution but require an infrastructure (PKI) to establish and maintain
the validity of these keys. Such an infrastructure could be sanctioned and maintained by a license
authority which has responsibility for content protection (as opposed to general network security).
DRM Client to Receiving Device APIs
19
- 20 -
FG IPTV-DOC-0045
The DRM client on any given receiving device must interact with other hardware and software
elements on that device. Definition of a set of standard APIs can facilitate the interoperability of
the DRM client with the rest of the receiving device platform.
Secure download of DRM client
Ideally, any receiving device would be able to exchange content obtained (legitimately) through
other devices and/or using any DRM or CAS system according to the granted rights (i.e., the DRM-
IX mode). However, it is not practical to pre-load at manufacture time every receiving device with
every CAS and DRM system that market forces will demand. Thus, a secure mechanism for
downloading and executing a selected CAS or DRM system onto a receiving device is needed.
Elements such as secure bootloaders and secure download protocols play a part in this area of
interoperability.
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: consider the following under the content security and service security
require ment sections in OD.
A. DRM/CAS technology for content security should support the interoperability.
B. We should investigate in the following elements for interoperability and for other
advantages.
i. Authentication of devices, users and DRM systems
ii. Rights Expression Exchange
iii. Common encryption algorithms for content exchange
iv. Key management and/or exchange for the common encryption algorithms
v. DRM Client to Receiving Device APIs
vi. Secure download of DRM client
C. IPTV devices should have a trusted architecture to support interoperability of content
security.
Editors Note: consider the following under the content security and service security
require ment sections in OD.
IPTV content security requirements may include:
Content Access Control: Only the authorized subscribers can use the digital video content. The
rights granted may include: the receiving device (one or a group), time period for viewing,
20
- 21 -
FG IPTV-DOC-0045
watching times, output format etc. Unauthorized subscribers cannot receive the video stream,
and even if they received it, they cannot decrypt it.
Copy Protection: Protect the digit content transmitted or stored in the IPTV service network
from unauthorized duplication.
Integrity and confidentiality of the digital content: IPTV service should be able to guarantee the
integrity and confidentiality of the digital content stored or delivered in the service network.
Tracing / Non-repudiation: Digital content owner should be able to trace the illegal usage of
the content by technical methods, for example forensic digital watermarking.
Editors Note: consider the following under the content security and service security
require ment sections in OD.
IPTV system should have the ability to label contents for the filtering purposes.
(1)Mechamism should to be provided by means of which criteria for labelling
controlled contents can be defined in a flexible way.
(2)Defintion of controlled contents can vary from countries to countries
depending on local laws and cultures. And as a result, there won’t be a set
of universal criteria for identifying content contents.
(3)A general-purpose content labelling system should be able to work with
different definitions and criteria.
Editors Note: consider the following under the content security and service security
require ment sections in OD.
Key Management System and License Issuer should be defined as two separated parts and it is
proposed to add the following requirement to IPTV DRM architecture output document of WG3:
Key Management System Requirement
License Issuer Requirement
Interface Requirement between Key management system and license issuer
--------------END
6.2 Service Security Requirement
Editors Note: The following proposal from contribution FG IPTV-C-0400 in Mountain Vie w
meeting needs to be conside red.
IPTV service exchange point should protect the IPTV network and IPTV source against the
malicious traffic injection. This feature should be implemented in IPTV service exchange point.
- uRPF in exchange peer interface
- Filtering about non-approved group range, source Block and non approved application port
numbers
- PIM neighbor authentication
- TCP/ICMP message filtering for 224/4
21
- 22 -
FG IPTV-DOC-0045
- Protection against multicast source spoofing
- BSR message filtering
- Multicast Route limit
Editors Note: The following proposal from contribution FG IPTV-C-0419 in Mountain Vie w
meeting needs to be conside red.
Common Security Require ments for IPTV Network Ele ments
IPTV_SEC_XXX: Authentication and authorization shall be performed at both service and
transport strata at NGN-based IPTV network.
IPTV_SEC_XXX: The IPTV Architecture should allow provision of security measures
against unauthorized access to network resources, devices, services and subscriber data
(profile), for example, to block unwanted traffic.
IPTV_SEC_XXX: The IPTV Architecture shall ensure the confidentiality, the integrity of
the signalling/control flows and management flows transported on it
IPTV_SEC_XXX: The IPTV Architecture should ensure the confidentiality, the integrity
of the media flows transported on it
IPTV_SEC_XXX: The IPTV Architecture shall provide safe storage for security-related
data (e.g., identity and credentials data). Such storage shall be separate from the general
data repository that contains subscribers’ services-related information. The network shall
provide security policy, which includes a set of rules that determine which traffic has to be
protected based on e.g., contracts, what kind of protection shall be used, how often session
keys shall be changed, and the rules that determine security compliance of a device.
IPTV_SEC_XXX: The network shall be capable of detecting, reporting, and mitigating
occurrences of the abnormal network events.
Security policy
IPTV_SEC_XXX: Security policy is a set of rules laid down by the security authority
governing the use and provision of security services and facilities. IPTV providers shall
prepare appropriate security policy and shall be responsible for applying it to all IPTV
devices under its control.
Hardening and service disablement
IPTV_SEC_XXX: All the IPTV network elements should be capable of being configured
to support the services needed for the IPTV providers. Any service or Port that is not
required for the correct operation of the IPTV should be disabled on all IPTV network
elements.
IPTV_SEC_XXX: In addition to hardening, physical and logical access controls shall be
put in place to meet industry Best-Practices.
Audit trail, trapping and logging
IPTV_SEC_XXX: All IPTV network elements should be capable of creating an audit trail
that maintains a record of security related events in accordance with IPTV service
provider’s security policy.
22
- 23 -
FG IPTV-DOC-0045
Time stamping and time source
IPTV_SEC_XXX: The IPTV Architecture shall support use of a trusted time source for
both system clock and audit trail item stamping. A trusted time source in this case means a
time source that can be verified to be resistant to unauthorized modification. Transitive trust
is acceptable, i.e., a time source that relies on a trusted time source is itself an acceptable
trusted time source.
Code and system integrity and monitoring
IPTV_SEC_XXX: The IPTV Architecture shall be capable of monitoring 1) its
configuration and software and 2) any changes to detect unauthorized changes, both based
on the security policy. Any unauthorized changes shall allow for a log entry and cause an
alarm to be generated.
Patches, hotfixes and supplementary code
IPTV_SEC_XXX: The IPTV Architecture and systems should provide a capability to
verify and audit IPTV applications. This would allow for an analysis of the security posture
of the IPTV Architecture and provide guidance to administrators and network owners with
respect to where mitigation is necessary.
IPTV_SEC_XXX: Security patches should be obtained from the equipment vendors and
installed in a timely fashion. An automated mechanism should be prepared for installing
security patches, once the IPTV provider has certified them. The element software updates,
resource files and configuration items shall be delivered with a digital signature and the
signature must be validated before acceptance. If it is determined that the software update,
resource files or configuration items do not have a valid signature, then an alarm shall be
generated and the item rejected.
************************from old living list*************************************
------------BEGIN
TBD.
Editors Note: do not consider the following in OD.
ID_SEC_REQ_0003:
Authentication & Authorization-
- Alignment with NGN Security requirements
DOS Attacks, Password control or ID card, etc.
Editors Note: do not consider the following in OD
Controlled access and authorization of IPTV service: IPTV service should have the
capability to identify the subscribers to prohibit illegal access. Strong authentication and
strict authorization scheme are required to prevent illegal subscribers from accessing service
network and servers. Strong authentication includes digital certificate, token, smartcard,
fingerprint and other multi- factor authentication. IPTV service should also limit the access
23
- 24 -
FG IPTV-DOC-0045
abilities for the legitimate subscribers by strict access policy control (for instance, to limit the
access times for the same user, prevent any kind of unallowable upload and download data),
in order to prevent from abusing the resource of network.
Availability of IPTV service: The consumers are very sensitive to IPTV service failure. IPTV
service should reduce attack probabilities and minimize potential damage after a violation be
detected. For example, IPTV service system should have the ability to monitor the service
status, and alarm in time when some security problem is detected. IPTV service system
should have some emergency recovery schemes.
- Security requirements of subscriber
Authenticity (Reliability) of IPTV service providers: Besides a service provider should
authenticate the subscriber, IPTV service should provide capabilities to support the subscribers
to verify the claimed identity of the IPTV servers or other entities. Many authentication
methods support bi-directional authentication, such as EAP-TLS, DCE/Kerberos etc.
Protection of subscriber’s information confidentiality: IPTV service network should have
capabilities (e.g. cryptographic means) to protect subscriber’s information from being stolen or
eavesdropped.
Protection of subscribes’ right to privacy: IPTV service provider should protect subscribers’
privacy information, such as location data, identities, phone numbers, network addresses or
call-accounting data.
Editors Note: do not consider the following in OD.
When deploying IPTV service, it is suggested that IPTV service security should be considered,
including streamed audio/video and session control information security, universal policy security
and network management security and service provision security.
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: consider the following under the service security require ment s ections in OD.
IPTV service access security requirements may include:
Service authentication and authorization: IPTV service should have the ability to identity the
users and their terminal devices in order to prohibit illegal service access. Furthermore, two-
way authentication based PKI is highly recommended in order to protect the consumers from
the threats of masquerading service provider. IPTV service should also limit the access abilities
of the legitimate subscribers by strict access control policy to against abusing the service
resource. For instance, limiting the access times of the same subscriber prevents any kind of
unallowable upload and download traffic.
Protection of subscriber’s information confidentiality: Security technologies such as encryption
should be used to protect subscriber’s information (such as identity information, billing
information) against theft or eavesdropping either during authenticating and authorising or in
the database.
24
- 25 -
FG IPTV-DOC-0045
IPTV service operating security requirements are as follows:
Service availability : The users are very sensitive to the TV service failure, so high availability
is the key for a profitable IPTV service. In case of breakdown, network equipments and video
service equipments must be able to recover as quickly as possible to minimise the effects on
subscribers. There are two phase here:
1. Firstly, failure detection: the IPTV service system should have the ability to monitor the
service status. Once security problem is detected, it will set an alarm in time.
2. Secondly, a failover can guarantee non- interrupted service: ensuring that the failover would
not interrupt the subscriber’s viewing experience. A good redundancy scheme (such as hot
backup servers and emergency switch technologies) can help to ensure a failover can
guarantee seamless service delivery.
Service reliability: the IPTV service reliability refers to the ability against attacks on IPTV
servers (such as authentication servers, media servers…) and protocols.
Non-repudiation / Accountability：An IPTV service network should provide a capability so that
an entity cannot deny the responsibility for any of its performed actions as well as their effects.
IPTV broadcasting control: the IPTV service system should have the ability to monitor the service
status, and set an alarm in time when illegitimate content broadcasting is detected.
WG3 should discuss continuously the following features and other contributions.
D. We should define service security.
E. We should determine whether we use current CAS technologies or not.
F. If we choose to use the CAS for service security, we should consider the architecture
for interoperability of CAS
G. We should consider the method of subscriber authentication.
H. We should consider the method of device authentication.
Subscribe r Authentication: Unlike Internet services, the IPTV service can bind subscriber
with his terminal device(s) to simplify the use of device(s), in which , the subscriber
authentication is done once during STB installation; it can be simply implemented by provid ing
unique user code and password. Subscriber authentication can also use smartcard or SIM card,
where subscriber’s identifier is securely stored.
--------------END
6.3 Network Security Require ment
Editors Note: The following proposal from contribution FG IPTV-C-0402 in Mountain Vie w
meeting needs to be conside red.
Multicast security requirements
25
- 26 -
FG IPTV-DOC-0045
IPTV content provider network
Content provider network protection; admission control for incoming traffic into
content provider network
Interoperability domain(multicast exchange peers); security guidelines between
content providers and service providers
IPTV service provider network
Multicast network protection
- RP security; in the perspective of RP resource misuse
. RP group filtering
. PIM register filtering
. MSDP SA filtering
- Multicast routing security
. PIM router security
. RP integrity
. Multicast routing protocol authentication; protocol adjacency authentication
. Multicast route limit
. Service filtering; access control for denial of services
Interoperability domain(multicast exchange peers); security guidelines among content
service providers
IPTV network provider network
IPTV multicast backbone network
- RP security; in the perspective of RP resource misuse
. RP group filtering
. PIM register filtering
. MSDP SA filtering
- Multicast routing security
. PIM router security
. RP integrity
. Multicast routing protocol authentication; protocol adjacency authentication
. Multicast route limit
. Service filtering; access control for denial of services
IPTV multicast access network
- RP security; in the perspective of RP resource misuse
. RP group filtering
. PIM register filtering
- Multicast routing security
. PIM router security
. BSR filtering
26
- 27 -
FG IPTV-DOC-0045
. Multicast routing protocol authentication; protocol adjacency authentication
. Multicast route limit
. Service filtering; access control for denial of services
- Customer facing network
. Protection against consumers’ source spoofing
. Filtering unexpected multicast source generated by consumers
. Block unnecessary PIM neighborship with customer facing interface
Interoperability domain(multicast exchange peers); security guidelines among content
service providers
Consumers last mile network
User authentication and authorization: prevent service forgery
Customer facing network
- Protection against consumers’ source spoofing
- Filtering unexpected multicast source generated by consumers
- Block unnecessary PIM neighborship with customer facing interface
************************from old living list*************************************
------------BEGIN
TBD.
Editors Note: do not consider the following in OD.
ID_SEC_REQ_0003:
Authentication & Authorization-
- Alignment with NGN Security requirements
Security models according to information value chain
Editors Note: do not consider the following in OD.
ID_SEC_REQ_000x: Security require ments for IPTV Transport Stratum
- Security requirements for network operator
Access control and authentication: It should be implemented on the access network to
prevent unauthorized access and utilization of resources. Two kinds of resources should be
controlled in the access: the network and the services o ver the network. In network access,
the subscriber/subscriber terminal should be identified and authenticated.
Authenticity of network entities: IPTV network should have the ability to verify the identity
of each network entity participating in the IPTV service, to establish the trust relationship
among the network entities.
Protection of data integrity and availability: IPTV carrier network should guarantee the
integrity, availability of data stored or delivered in the network.
27
- 28 -
FG IPTV-DOC-0045
Accountability of data packets: Prevention of all bad behaviours is infeasible. A promising
alternative approach is to use incentives to reward good behaviours and punish bad
behaviours. If participants face a significant risk of punishment for improper actions, rational
participants will have an incentive to behave for better. Source traceability is the basis of
incentives.
Multicast security protection: Either IP multicast or application layer multicast (an overlay
multicast network) should achieve the following requirements: availability of the key
equipments (such as the multicast source, key nodes running multicast protocols etc),
verification of identities of the multicast source, the control of the multicast group members,
etc.
Security requirements about CDN: Two aspects should be considered: the protection of the
CDN nodes and the protection of distributed streaming in the CDN network.
- Security requirements for subscribers
Authenticity of subscribers’ devices: It is possible that there are more than one devices sharing
one subscriber’s account. In this case, subscribers should have the ability to verify the
authenticity of home devices. Authorization and accountability are also required.
When deploying IPTV service, it is recommended that IP-based bear network security should be
considered, including access network security, concentrated network security, bone and/or core
network security.
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: consider the following under the network security require ment sections in OD.
Multicast protocol security: IP multicast protocol used in IPTV bearer network should at least
achieve the following requirements: verification of identities of the multicast source, control of
the multicast group members, etc.
Availability and Reliability of Content Distribution Network: The nodes in the Content
Distribution Network should be resilient to malicious attacks (like DOS, leak hack).
Furthermore, it also should have a good redundancy scheme to meet an emergency.
--------------END
6.4 Terminal Device Security Require ment
************************from old living list*************************************
------------BEGIN
TBD.
Editors Note: do not consider the following in OD.
28
- 29 -
FG IPTV-DOC-0045
ID_SEC_REQ_000X:
Authentication & Authorization-
- With helps of NACF for user/terminal identifications and service profiles
- Proprietary STB system information and crypto key distribution
Editors Note: do not consider the following in OD.
When deploying IPTV service, it is recommended that Terminal Security should be considered.
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: consider the following under the terminal device security requirement section in
OD.
Authenticity of subscriber’s devices within consumer domain: It is possible that there are more
than one device sharing one subscriber’s account. In this case, the subscriber should have the
ability to verify the authenticity of home devices. Authorization and accountability should also
be required.
Reliability of the software in IPTV receiving terminal: The IPTV receiving terminal should
have the ability to against attacks and viruses.
Editors Note: consider the following under the terminal device security requirement section in
OD.
Terminal devices shall satisfy following security requirements.
Content protection
The final goal of device hacking is to steal or copy clear contents. Although content
protection systems such as CAS and DRM are used to protect the contents, they still have
limitation. DRM/CAS systems protect contents by cryptographic techniques, and the
contents must be decrypted for consumption. The contents are no more protected by
DRM/CAS systems after decryption. Then, devices should protect the decrypted contents.
Terminal devices shall meet the following requirements.
Clear contents shall not be transmitted through user accessible buses or stored into user
accessible storage or memory.
Devices shall not retransmit contents to output or display ports without the permission
of content protection systems such as DRM/CAS systems.
Content key protection
The leakage of content keys means the leakage of clear contents. Therefore, content keys
should be safely stored in devices.
Devices shall provide methods to protect content keys from unauthorized access. Only
DRM/CAS systems shall access their contents keys.
Device secret protection
29
- 30 -
FG IPTV-DOC-0045
IPTV devices will contain some values such as device secret keys. In addition to secret
keys, devices may have other secret or trust values such as secure clock state and device
ID. Malicious users can copy or modify these values to use contents illegally. For example,
they can use time expired contents by modifying clock state. Any secret values used in
IPTV devices shall be protected from unauthorized access.
Device secret keys shall be accessible only by a built- in device cryptographic module,
and all cryptographic operation with the keys shall be done through the cryptographic
module. Users and system components other than the cryptographic module shall not
be able to access the device secret keys directly. The cryptographic module and keys
shall be packaged into a tamper resistant hardware such as silicon chip so that the
device key cannot be accessed from outside.
Devices shall store secret or trust values securely so that they cannot be accessed and
modified in unauthorized way.
User information protection
Hackers can try to steal other users’ information such as ID and password. The stolen
information can be used for impersonation.
Devices shall store user information securely so that unauthorized users or software
cannot access them.
Software protection
There are many kinds of software in IPTV devices from system software to application
software. System software such as operating system, and content protection system
software, such as DRM and CAS software, are important in security aspect. Tampering
these software can cause device failure or contents leakage.
Devices shall be designed to frustrate attempts to tamper system software and content
protection system software.
Devices shall have methods to verify the integrity of system software and content
protection system software.
Hardware tamper resistance
Malicious users may replace or modify hardware components to steal clear contents, secret
information or circumvent content protection systems.
Attempts for removing, replacing, or modifying any hardware components shall cause
system failure.
Providing secure communication method and authentication
IPTV devices normally communicate with other components in the network such as content
servers to use contents. During the communication, secure channels should be established
between server and IPTV devices to exchange secure information. Mutual authentication
between device and server is also required.
Devices shall support secure communication protocols.
Devices shall support mutual authentication method.
Protection from malicious code
Malicious codes can be installed and cause various problems in the IPTV devices. Worms
can reduce device performance by occupying system resources s uch as CPU and RAM.
30
- 31 -
FG IPTV-DOC-0045
Trojan horse viruses can be installed so that hackers can manage the device or steal secret
information. IPTV devices shall provide countermeasures against the malicious codes.
During software installation, devices shall check the possibility of the danger of the
software. For example, devices can perform software authentication process before
installation.
Devices shall provide hardware or software mechanisms to detect, isolate and remove
malicious codes or viruses.
Inte roperability and rene wability support for content protection system.
Content protection systems should be interoperable and renewable. Downloadable
DRM/CAS can be a possible solution for both requirements. New DRM/CAS software can
be downloaded from servers when it is req uired to use a new type of content or when
existing DRM/CAS software is compromised. For this purpose, devices shall meet the
following requirements.
Devices shall support secure download protocol for DRM/CAS software.
Devices shall have the ability to authenticate the DRM/CAS software and servers
providing the software.
--------------END
6.5 Subscribe r Security Requirement
************************from old living list*************************************
------------BEGIN
TBD.
Editors Note: do not consider the following in OD.
Authentication & Authorization-
- With helps of NACF for user/terminal identifications and service profiles
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
--------------END
7 Security Architecture
TBD.
31
- 32 -
FG IPTV-DOC-0045
7.1 Security Trust Model
TBD.
7.2 Security Gene ral Frame work
************************from old living list*************************************
------------BEGIN
TBD.
Editors Note: to be discussed.
ID_SEC_ARCH_000X:
Here below is an entity model for the case of a CAS (Conditional Access Systems)/DRM (Digital
Rights Management) system, to illustrate system architecture and, in particular, the security
functions needed to realize the requirements explained abo ve.
Content Provider Service Provider Consumer Premise Equipment
(TV sets, STB)
CAS/DRM CAS/DRM
Network
Provider
Contents (Content
Delivery Network distribution) Home network
(B to B)
Figure 3
7.2.1 Content Protection Architecture
Editors Note: The following proposal from contribution FG IPTV-C-0390 in Mountain Vie w
meeting needs to be conside red.
Content License Management FE (CLM-FE)-Related Require ments
IPTV_SEC_002 : IPTV Architecture specification shall provide a mechanism for securing
content. [IIF.ARCH.OPERATOR.11]
IPTV_SEC_003 : The IPTV Architecture shall be compliant with the service and content
protection requirements found in ATIS-0800001, IPTV DRM Interoperability
Requirements. [IIF.ARCH.OPERATOR.31]
IIF.DRM.Genera.0600-0400 : The IPTV security solution shall have the ability to use
standard key management system (e.g., MIKE, EMM/ECM), to the extent that this is
required for interoperability.
32
- 33 -
FG IPTV-DOC-0045
IIF.DRM.General.0700 : The IPTV security solution shall support a server side DRM
interface between the middleware of the network operator’s Subscriber/Service/Asset
Management System (middleware) and the DRM System.
IIF.DRM.Tracing.0300 : The content tracing technology shall ensure the content tracing
information should not be removed by normal network functions (e.g., through
compression or error-correction technologies), or that any malicious attempt to remove
the content tracing information from the content streaming shall result in visible harm to
the content.
IIF.DRM.Operator.0900 : The IPTV security solution shall enable the operator to turn
on and off content tracing function with flexibility (e.g., based on time, and Event,
Asset, or Channel)
IIF.DRM.Operator.1000 : The IPTV security solution shall enable the operator to apply
robust content tracing to content in real-time (e.g., broadcast content)
IIF.DRM.Operator.1100 : The IPTV security solution shall enable the operator to apply
robust content tracing to content in an offline manner (e.g., VOD Content)
IPTV_SEC_004 : The IPTV Architecture may include the ability for applications to interact
with and be managed by the content management and protection capabilities.
[IIF.ARCH.OPERATOR.32]
IPTV_SEC_007: Broadcasters, content producers and 3rd party metadata providers will all
want to be able to provide information about content in a way that can be identified by the
end-user as to its source and protected from alteration by others in the value chain.
IPTV_SEC_013: The IPTV Architecture shall provide mechanisms to enable the
application of appropriate DRM on content. [IIF.ARCH.OPERATOR.08]
IPTV_ARC_084: The IPTV Architecture shall provide a mechanism that allows for service
operators to allow IPTV service delivery from a 3 rd party provider. This function should
include capabilities for exchanging settlement information between the service operator and
the 3rd party provider. [IIF.ARCH.NETWORK.09]
Content License Management FE (CLM-FE) Functions
The CLM-FE is responsible issuing license to protect content.
a) The CLM-FE provides the license key to the content encryption system and the user
terminal.
b) The CLM-FE controls content encoding process.
c) The CLM-FE provides the content tracing capability, if the network applies the content
tracing technologies.
Content Broker FE (CB-FE)-Related Requirements
IPTV_ARC_084: The IPTV Architecture shall provide a mechanism that allows for service
operators to allow IPTV service delivery from a 3 rd party provider. This function should
include capabilities for exchanging settlement information between the service operator and
the 3rd party provider. [IIF.ARCH.NETWORK.09]
33
- 34 -
FG IPTV-DOC-0045
IPTV_ARC_117: The IPTV Architecture shall support 3 rd party content providers.
[IIF.ARCH.SERVICE.13]
IPTV_SEC_007: Broadcasters, content producers and 3rd party metadata providers will all
want to be able to provide information about in a way that can be identified by the end-user
as to its source and protected from alteration by others in the value chain.
IPTV_SEC_013: The IPTV Architecture shall provide mechanisms to enable the
application of appropriate DRM on content. [IIF.ARCH.OPERATOR.08]
Content Broker FE (CB-FE)-Related Functions
The CB-FE is responsible for brokering content between domains.
a) The CB-FE provides secure interface for brokering content between domains.
b) The CB-FE gathers 3rd party service information and content profile according to the
settlement between domains.
c) The CB-FE may execute as proxy for delivering content license for 3 rd party content.
Note: some functions of the CB-FE may overlap with the functions of Service Exchange Points,
which is introduced in C-135 and discussed in the 2nd meeting.
NEED TO BE DISCUSSED AND ADD THE DELINEATION OF THIS FIGURE.
34
- 35 -
FG IPTV-DOC-0045
Editors Note: do not consider the following figure in OD
Content Service Subscriber
Provider Provider Content Security
Service Subscriber
Provider Service Security
Network Subscriber
Operator Transport Security
Content Service Content Content
Integration&
Source Operation
Transport Cons umption
Figure 4 – IPTV security architecture
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: consider the following under the security architecture section in OD.
IPTV security includes many security features, such as confidentiality, availability... All these
features can be classified into 3 stratums: Transport, Service, and Content. As illustrated in figure 5,
the security issues in different stratums are associated with different parts of the IPTV service chain.
Note: Figure5 only describes security features from consumer view and needs to be refined to
define the complete IPTV security architecture.
35
- 36 -
FG IPTV-DOC-0045
(1)
DRM Server Content DRM/CA
Side Agent Content
Management
(1’) Stratum
DRM/CAS Security
(2)
Service Service
User
Operation& Stratum
Management (3) Application
Security
(4)
Transport
Core (5) Network Access Stratum
AN
Client Security
Network
(6)
Content Source/ Service Integration & Content Transport/ Content Consumption/
Content provider Operation/ Service Provider Delivery Network Consumer
(1) (1’) Content protection (3) Service security (5) Network access security
(2) Service access security (4) Bearer network security (6) Consumer domain security
Figure 5 – IPTV security architecture (from consumer view)
In figure 5, six security feature groups are defined. Each of these feature groups accomplishes
certain security objectives.
(1) (1’) Content protection: the set of security features that ensure the digital contents be
transmitted, stored, transferred and consumed securely. For different purpose, the content
protection technologies can be used by content providers or service providers. A good
mechanism should be implemented to protect commercial digital content from interception,
replacement, unauthorized viewing, or unauthorized copying.
(2) Service access security: the set of security features that provide subscribers with secure access
to the service.The entities which involved in service access security include IPTV service
providers and consumers. The security features such as the authentication and authorization to
IPTV service users, the protection of subscribers’ information confidentiality should be
considered here. There are two types of the service authentication & authorization, one is about
multiple services (VOD, PVR, broadcast TV), and the other is about multiple service
providers.
(3) Service operating security: the set of security features that enable the IPTV service to operate
stably and securely. Main features in this group are as follows: service availability and
reliability, Non-repudiation, etc.
(4) Bearer network security: The set of security features that enable data to be transmitted securely
form IPTV service provider to receiving terminal, and protect the network against various
attacks. The following security features related to bearer network security can be provided:
availability and reliability of Content Distribution Network, multicast protocol security.
(5) Network access security: the set of security features that is implemented on the access network
to prevent unauthorized access and utilization of the IPTV bearer network. Besides the network
36
- 37 -
FG IPTV-DOC-0045
authentication and authorization, the confidentiality of the user’s ID information is needed in
this feature group.
(6) Consumer domain security: the set of security features that ensure user devices securely access
to consumer domain and to be protected against attacks. The security features such as
authenticity of home network devices and reliability of the receiving terminal can be mentioned
here.
--------------END
7.3 Security Function Modules
************************from old living list*************************************
------------BEGIN
Editors Note: consider the following under the security architecture section in OD.
TBD.
Figure 6
There are 2 categories to make this contents protection system within IPTV mechanism. First
protection the network access via AAA service. Second, the media itself protection via CA or DRM
method.
All access from the subscribers are connected to the SMS (Subscriber Management System)
and BS (Billing Server) to request the access bill to the each subscriber of IPTV.
After receiving the media, storing and re-distribution, converting to other CODEC, transfer to
the other display devices should be controlled by DRM. But for DRM control, it is needed to proxy
37
- 38 -
FG IPTV-DOC-0045
service for faster service. So, the main receiver (we guess it might be STB with HDD) should do the
role of DRM proxy server within the home.
Editors Note: to be discussed.
The specifications of a CAS/DRM system that implements all these security functions are shown
below.
Real-time
encryption
Retransmission multiplex
content Channel
services
EPG
Multicast (contents)
Scramble key selection
request On demand
services
encryption Uni-cast (contents) Portal/IPG
Self-procured selection
content
Scramble key
License issue
Figure 7
CAS/Digital Rights management
The conditions below are not necessarily exclusive requirements; they can be realized through
different means.
1） IP channel services
If a content scrambler key is used as a method of delivery, it is desirable to use ECM
(in band), which is compatible with the current streamings of the particular country
question.
In the case of free channels where content protection needs to be considered, it is desirable that
content is viewable only by means of multicast data transmission—a method that allows
content be viewed without a subscriber contract.
2） EMM/PKI (out of band)
38
- 39 -
FG IPTV-DOC-0045
As a delivery method of subscriber contract renewal information, utilizing the two-way nature
of communication, it is desirable to deliver content by a method such as PKI—which provides
a secure channel for data equivalent to EMM, an extension of current broadcasts.
3） Various VOD and download services: control by license issue
While there are many conceivable types of VOD services, it is desirable in all cases
to utilize a payment method for viewer conditions and licenses.
Content protection
1） Content encryption method
In IP channel services, it is generally expected that content is viewable immediately after
selecting a channel. For this reason, it is desirable to use a time-limited licensing that is
compatible with broadcast methods. In the case of VOD streaming and download services,
since content is delivered by unicast in response to the demand of the viewer, it is desirable to
have a license key for each item of content, for encrypting the content in advance.
2） Encryption algorithms
It is desirable to use encryption methods that are standardized, and widely respected. Based on
links IPTV service to the broadcasting of each country, it is not essential to narrow down to
one algorithm. However, when selecting new encryption algorithms, it is desirable that
encryption be at least 128 bit.
Security
Smartcard-based ―CAS‖ for Broadcasting are now widespread, so it is desirable to utilize
smartcards. However, since technology built in to CPEs is now highly advanced, if the
following conditions can be met, it is acceptable to use Download-CAS or a DRM- like
implementation of CAS/DRM built in to the CPE—without the need for smartcards. Given the
falling costs of building complex functionality into hardware, it is expected that in the coming
years CAS/DRM systems will be increasingly implemented by way of software.
1） There is compatibility between the responsibility dividing line of the service provider and the
responsibility dividing line of transmission systems and CPE functions include CAS/DRM
modules
39
- 40 -
FG IPTV-DOC-0045
2） Due consideration is given software anti-tampering measures
3） IPTV service is not completely interrupted, even to exchange a CAS/DRM module due to the
occurrence piracy has occurred
Authentication/Authorization
1) PKI base
When multiple IPTV service operators share a single CPE, it is most effective if the
CAS/DRM is also shared. If this is done, then in view of the frequent M&As that occur
between IPTV service providers, it is preferable to use PKI (Public Key Infrastructure),
whereby sharing is not necessary, instead of a common key system in which all viewers share
a private key.
2) Attacks on the systems of IPTV service providers and protection of personal data
From the perspective of attacks on the systems of IPTV service providers and protection
of personal data, it is preferable that the service provider implements, as far as possible, two-
way authentication based on PKI.
3) Validity period and renewal of public key certificate and CRL operation
Normally, in order to limit the security risk, a validity period is set for public key certificates
used for PKI. It is necessary to take care in setting validity periods, because, unlike in the case of
PCs and other devices, it is not always easy to update the certificates CPEs..
Normally, CRL operation is necessary for public key certificates. For anti-piracy measures
reason, it is necessary to take care in implementing CRL processing of CPEs and CAS/DRM
modules.
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
--------------END
40
- 41 -
FG IPTV-DOC-0045
7.4 Security Inte rfaces
TBD.
8 Security Mechanis ms
8.1 Content Security Mechanisms
Editors Note: The following proposal from contribution FG IPTV-C-0310 in Mountain Vie w
meeting needs to be conside red.
To insure the content and service security of IPTV content, this contribution proposes to introduce
the Key Management Function (KMF), and Right Issuer Function (RIF) into NGN based IPTV
architecture.
To insure the content and service security of IPTV content, this contribution proposes to introduce
the Key Management Function (KMF), and Right Issuer Function (RIF) into NGN based IPTV
architecture.
The functionality of Key Management Function (KMF) is as follows:
Generate and store the encryption keys
Provide the encryption keys to the relevant entities, e.g. RIF
The functionality of Right Issuer Function (RIF) is as follows:
Get the needed information for the Right Object, e.g. identifier of the content, encryption key and
the right information etc.
Generate the Right Object based on the information
Issue the Right Object to the user’s terminal.
Editors Note: consider the following under the content security mechanis m section in OD
from the contributions in the first IPTV meeting
41
- 42 -
FG IPTV-DOC-0045
Figure 8
IPTV is based on communication technology, and always the subscriber can interchange any
message with the server which would be logically located in broadcasting center. So, there are two
kinds of contents protection mechanism should be considered.
First, access the IPTV broadcasting network. In many case, there is already standard
mechanism for subscriber authentication, authorization and accounting, called AAA. That can do
the role of toll- gate to prohibit the entrance illegal users into the IPTV network.
Second, scrambling media stream like similar mechanism of traditional can be considered.
However, it is different from traditional broadcasting, because IPTV can confirm and acknowledge
for each packet through open but secured protocol, like SSL. In addition, the new IPTV CA system
can send to subscriber not only 2 the keywords (EMM, ECM), but also its encryption mechanism
(the encryption mechanism) for each media. If it is realized we can get 3 merits.
(1) Each medium ((multiple) audio, video, (multiple) interactive software with data, any other
information like SI) can use different encryption method according to the business model.
So, the broadcaster can sell each medium through subscriber’s request.
(2) The encryption method can be vary according to the time goes. The encryption method can
be vary even during the broadcasting is on-air. All encryption method always downloaded
to the each subscriber with the keywords.
(3) The responsibility of contents protection should be to the contents provider, because all
contents method should be transferred to the broadcasters with their A/V stream. However,
if the broadcaster wants the broadcaster can install their own contents protection system like
traditional broadcasting system.
Therefore, it is suggested the 2 mechanisms are all needed to IPTV for dual protection.
42
- 43 -
FG IPTV-DOC-0045
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: to be discussed from the contributions Busan meeting
Table6: Content protection mechanisms
ASSET RISK SECURITY MECHANISM
Plaintext content work Unauthorized modification Integrity protection of files and
streams
Plaintext content work Unauthorized access Encryption of files and streams
Content policy specification
Selectable security level
Encrypted content work Unauthorized access Strong identity and authentication
Physical security of end-systems
Documented/auditable security
system
Content work Denial of service attack See network security mechanisms
In cases where the provider of a content work does not trust the security or practices of t he recipient
of the work, ―content protection‖ mechanisms raise the bar to illegal or unauthorized uses. These
mechanisms are discussed under separate points below.
Ease and simplicity of use. According to the ―Darknet‖ paper, cumbersome and intrusive
protection mechanisms encourage circumvention of protection mechanisms and
unauthorized access to content works [Darknet]. It is therefore important that Terminal
applications make it very easy for works to be accessed by the consumer in the desired ways
but very hard to access works in unauthorized ways. For this to have the desired effect, the
types of authorized access need to meet the customer’s needs and expectations.
Limited exposure of plaintext content works. Terminal, intermediate, and server systems
should be capable of processing encrypted content works to the latest point in the rendering
process. This of course is an unnecessary requirement for unencrypted works, but all
systems that handle content works should be designed to send, receive, and store encrypted
images of those works.
Integrity protection. The system needs some means to distinguish an authorized copy of a
digital content work from a modified or derived work.
Stream- level encryption. Limited exposure of a content work in the form of a stream entails
stream- level encryption in which the work is encrypted at the point of transport and
decrypted prior to rendering at the terminal.
File- level encryption. Limited exposure of a content-work contained in a file entails file-
level encryption in which the content work can be downloaded or streamed while encrypted
as done in the MPEG-4 Encryption and Authentication standard [ISMACRYP].
Content policy specification. The types of access that the residential customer is authorized
to perform needs to be specified. This may be specified per content work, such as an XrML
rights specification that is bound to a particular content work. Or it can be bound to a class
of content works or the entire service, as is done in Apple iTunes™.
43
- 44 -
FG IPTV-DOC-0045
Protected outputs. Terminal systems that process encrypted content works must support
protected outputs such as HDCP, DTCP, and other standards that are appropriate to the type
of interface.
Digital watermarking. Forensic and copy-control watermarks are two types of content- level
protection mechanism that are widely used today. Systems that process a watermarked
content work must preserve the watermark up to and including Terminal rendering.
Protected key store. All keys need appropriate protection and a scalable level of protection
needs to be supported. Home theatre systems that process newly-released movies, for
example, may need keys stored on a secure processor or separate token card that are tamper-
resistant. At the other extreme are content works that are distributed for use on PCs, such is
the case for practically all music titles today and a secure co-processor is not generally
available. Thus, high- value content works such as newly released movies are unlikely to be
licensed for use on a PC today or in the near future. In the case of a PC, the keystore should
at least be inaccessible using the facilities of the operating system such as a text editor. In
general, the keys to valuable content works in the earlier phases of their release window
will likely require hardware- level protections such as a co-processor that does not expose
keys on the bus or system memory.
Scalable level of protection. Not all works need to be encrypted or watermarked and not all
works that are encrypted need to be encrypted in the future. The Terminal, intermediate and
server systems that process content works should support a variety of policies and
mechanisms for content protection including no content-protection mechanisms at all.
Possibly the only mechanism that is universally desirable for digital content works is
integrity protection, which is a content-security mechanism discussed above.
8.1.1 Content Protection
8.1.1.1 Signaling Process
8.1.1.2 Inte rfacing
TBD.
8.1.2 Conditional Access
TBD.
************************from old living list*************************************
------------BEGIN
Editors Note: to be discussed.
Conditional Access (CA) provides the restriction of content viewing to authorized users through
scrambling or encryption of media. CA has a long history in television broadca st via cable and
satellite television through both proprietary (e.g. DigiCypher and Nagravision) and standard means
(e.g. DVB-CA, ATSC-CA).
Common terms in CA for the control of authorization for content rights are Entitlement Control
Message (ECM) which defines a protected resource and Entitlement Management Message (EMM)
which grants rights to a given subscriber or their agent to view a set of content described by ECMs.
Both ECMs and EMMs may be transmitted with the controlled content or through a separate
channel, depending on implementation. EMMs can be delivered either through a digital
44
- 45 -
FG IPTV-DOC-0045
communication channel or on a smart card delivered to the subscriber. The former is more relevant
to the DRM discussion.
CA Server EMMs w / keys
Authentic ation
keys [ECMs]
unencrypted stream encrypted stream
Encryptor CPE
[w / embedded ECMs]
decrypted stream
Display
Device
Keys for an asset are shared across all users within the CA server domain
Figure 9 - Conditi onal Access Logical View
--------------END
8.1.3 Digital Rights Management
************************from old living list*************************************
------------BEGIN
Editors Note: to be discussed .
Digital Rights Management (DRM) is sometimes thought of as the ―digital management of rights‖
or as the ―management of digital rights‖. In fact, DRM provides the ―digital management of rights
to digital assets‖. DRM combines Conditional Access and Copy Protection, this combination allows
the addition of richness to the policies that can be expressed and enforced on protected assets. DRM
allows assets to be protected and then a variety of policies specified by the asset owner on how the
asset may be used. A DRM scheme must support the following critical attributes of rights which
may be granted:
- who has access
o a subscriber, a user, or any group or combination of these
- on which devices
o a device or a group of devices
- to which agents
o a DRM client implementation (―DRM agent‖) or group of agents
- when do they have access
45
- 46 -
FG IPTV-DOC-0045
o for what time period, how many times may access be granted
- to which features
o e.g. a set of software features, video on demand trick modes, etc.
- with what output
o what output formats (analogue and digital) are supported for this content, with what
restriction (e.g. is 1080i digital video display allowed without HDMI/HDCP support
in the display device)
o what export formats are supported (e.g. analog output must support Macrovision,
digital storage must support DVB-CPCM or digital output must support DTCP)
It must be possible to combine these attributes, such as granting the right: a particular High
Definition movie may be viewed by users with a certain subscription ID, on any trusted DRM
agent, for 1 week, as many times as they like, on TVs at 1080i, thro ugh digital output supporting
DTCP, or through analogue output supporting CGMS-A.
It is critical that a DRM solution provides protection for both the asset owner and the asset licensee,
allowing free and unencumbered use of asset within the rights of the s ubscriber. It is also beneficial
if a DRM system can support the distribution and control of assets by ―users‖ as well as traditional
service providers – this provides for a much richer content and service exchange and engenders
innovation and business.
In order to facilitate DRM, two key network services are required:
1. Trust establishment and verification between the DRM rights issuer and the DRM agent
2. A secure time source to facilitate time based rights expression
Additionally, the ability to facilitate forensic analysis and prosecution of breaches of key
information are critical to the long term success of any content licensing model, implying the
integration of Digital Watermarking technologies into DRM systems.
request or distribute license
rights request or delivery
Rights request or distribute license AAA /
Issuer Payment
keys
(either direction)
purchase
rights
definition Asset DRM
Provider Agent 1 protected
content
unprotected DRM
content ― unprotected‖ Agent 1 ― unprotected‖
content content
Asset
Owner
Display Display
User
Device Device
Keys for an asset are specific to a subscription
Figure 10 – Digital Rights Management Logical View; Rights Issuer, Asset Provi der, Asset Owner, and
AAA/Payment may be a single or any multi ple legal or business entities
46
- 47 -
FG IPTV-DOC-0045
Editors Note: to be discussed .
Inte r-working with different DRM system and
In developing interoperability specifications for CAS and DRM in the IPTV context at least three
modes of high- level DRM architecture can be identified: 1) DRM End-to-End (DRM-EE), 2) DRM
Bridging (DRM-B) and 3) DRM Interchange(DRM-IX). These elements are discussed below.
DRM End-to-End (DRM-EE)
Using a single DRM system, two or more devices exchange and access content according to granted
rights.
This mode should be the easiest to implement since only a single DRM system is involved and thus
exchange of content and rights expression license should be the most straightforward. Note that
implementation of this mode may or may not include other point-to-point security hops on the path
from the content producer to the final consumption device. A disadvantage of this mode is that all
participating devices and equipment must offer a single CAS or DRM system and this may not be
realistic in truly global networks.
DRM Bridging (DRM-B)
On a single device, two or more DRM systems are operative. Content acquired via one DRM or
CAS system (from a network for example) can be accessed via another DRM system resident on the
same device according to granted rights.
In this mode, since both DRM systems share the same storage and physical interfaces of a single
hardware device, the main challenges are in the authentication of DRM clients, transfer of rights
expression licenses and secure content exchange between the DRM systems.
DRM Interchange (DRM-IX)
This case is characterized by two or more devices, each device having one or more operative DRM
systems. Content acquired by one device through one of its DRM systems can be securely
transferred to and accessed on another device through a different DRM system according to granted
rights.
This mode presents the greatest challenges since, in addition to the interoperability issues of the
DRM systems themselves, both physical and logical inter-device interfaces must be implemented in
an interoperable and secure fashion.
47
- 48 -
FG IPTV-DOC-0045
Authorized Output
While not a DRM mode per se, DRM systems may nonetheless need to deal with authorized output.
This is content sent to a display device for direct consumer viewing or listening. Some examples of
authorized output interfaces are DTCP, HDCP, CPRM, etc.
Editors Note: consider the following under the content or service security mechanism section
in OD.
Stepwise Approach:
We need discuss on the stepwise approach for this mechanism. First step, we should make the
standard only for IPTV distribution media protection.
Figure 11
In this phase, we should define all downloadable mechanism for the CA system, from
encryption and distribution of keywords, then decryption. However, it is more important to define
all running framework on downloaded CA packets in client, because all secured keyword can be
with its encryption mechanism. The following is an example of the client CA software architecture.
48
- 49 -
FG IPTV-DOC-0045
Figure 12
In second step, we should define on DRM and media life cycle management mechanism, we
will call this mechanism as DRM.
Figure 13
--------------END
**************************From the contributions Busan meeting*********************
----------------------BEGIN
49
- 50 -
FG IPTV-DOC-0045
Editors Note: There are some potentially useful mate rials in the attachment PPT, but we
cannot include due to the copyright.
-----------------------END
8.2 Service Security Mechanis ms
8.2.1 Service Authentication
Editors Note: The following proposal from contribution FG IPTV-C-0381 in Mountain Vie w
meeting needs to be conside red.
Updates to current requirement description for authentication on document FG IPTV-C-0260:
IPTV_SEC_022: The IPTV Architecture shall provide a mechanism to allow the service provider
to force users of the service to participate in an authentication and authorization procedure with
the network, before granting access to the service. [IIF.ARCH.OPERATOR.13]
IPTV_SEC_023: The IPTV Architecture shall provide mechanisms to control unauthorized
access by unsubscribed end-users to the service. It may redirect unsubscribed end -users to a
mechanism where they may subscribe. [IIF.ARCH.CONTEXT.18]
IPTV_SEC_024: The IPTV Architecture shall provide the mechanisms to protect content where
specified by DRM. [IIF.ARCH.CONTEXT.19]
Additional requirement for authentication:
(1) In order to control unsubscribed access to IPTV service system, the IPTV service provider
shall be able to authenticate the subscriber identity and/or STB device identity.
(2) In order to provide individual Presence Management and conditional Content Channel access
according different end user in a family, the IPTV service provider shall be able to authenticate
the different end user identity.
(3) In order to prevent unsubscribed Content copying or playing in content consumption device,
the IPTV service provider shall be able to authenticate CCD device identity by collaboration
with STB device.
8.2.2 Service Authorization
TBD.
50
- 51 -
FG IPTV-DOC-0045
8.3 Network Security Mechanis ms
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: to be discussed .
Table7:
ASSET RISK SECURITY MECHANISM
Network bandwidth Denial of service Firewalled perimeter
Unauthorized use
Network messages Unauthorized access Firewalled perimeter
Access Controls
Unauthorized modification VPN
Access Controls
Replay VPN
Routers and intermediate systems Denial of Service Firewalled perimeter
Unauthorized use Access controls
Intrusion protection
Documented and auditable
security procedures
Network service information Unauthorized disclosure Access controls
Integrity protection
Unauthorized modification Documented and auditable
security procedures
-----------------------END
8.4 Terminal Device Security Mechanisms
TBD.
8.4.1 Terminal Device Authentication
TBD.
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: to be discussed .
There are two phases of terminal device authentication. In the initial device installation
phase, a PKI based challenge response model could be used to establish permanent key. The
second phase would be subsequent power-on device authentication by using the already
established permanent key after installation.
51
- 52 -
FG IPTV-DOC-0045
The permanent key should be generated during terminal installation. Once it is generated, it
should be scrambled and stored in a permanent storage inside the terminal device with basic
secured access control. The permanent key should not be changed until a new installation
process is performed. Several security measures shall be considered when establishing
permanent key.
It is preferred to use PKI mechanism to secure the channel of generating the
permanent key.
Basic challenge and response method should be adopted in the process of generating
permanent key.
It is highly recommended to have certain hardware component such as secure
processor and/or secured micro co-processor to facilitate the permanent key
generation process, message encryption and key storage.
Instead of using permanent key to secure the service channels between the terminal devices
and authentication server, a terminal device should use the permanent key to generate the
session key and use it to encrypt the communication channels with authentication servers.
And session key could be changed in operator specified interval. This will enhance
the overall security of subscriber authentication system.
A re-authentication process at a certain interval is recommended to exchange new
session key.
-----------------------END
8.4.2 Terminal Device Authorization
TBD.
8.4.3 Terminal protection
TBD.
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: to be discussed .
Table 8
ASSET RISK SECURITY MECHANISM
Terminal locality Unauthorized relocation of End-system localization
fixed- location device Visible Fingerprinting
Unauthorized sharing of mobile Household localization
device
Processor and Disk Unauthorized access such as by Signed code
malware or remote access Secure Bootloader
Secure Keystore
Network access controls
Terminal interface Circumvention of content Approved copy-protected
52
- 53 -
FG IPTV-DOC-0045
protection controls through a outputs
Terminal interface
Approved outputs to
authenticated devices
-----------------------END
8.5 Subscribe r Security Mechanis ms
TBD.
8.5.1 Subscribe r Authentication
TBD.
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: to be discussed.
The following diagram depicts a general model of the STB and subscriber authentication
based the standard Kerberos token mechanism.
1) STB and Authentication Server
STB communicates with the authentication server for initial terminal and subscriber device
installation and authentication, as well as for subsequent power on authentications. All the
service access tokens are generated by authentication server.
2) STB and application servers and other resources
The communications between STB and application servers in the IPTV system are secured
by access tokens that STB acquired in its authentication process with the authentication
server.
53
- 54 -
FG IPTV-DOC-0045
VoD EPG VAS
Authentic ation
Server
DRM Billing
1. Installation and Authentication
.
2. Token Generation
Token based service verific ation .
Authentic ation Client Service API’s
STB
Figure 14
-----------------------END
8.5.2 Subscribe r Authorization
TBD.
8.5.3 Subscribe r information Protection
**************************From the contributions Busan meeting*********************
----------------------BEGIN
Editors Note: to be discussed .
Table 9
ASSET RISK SECURITY MECHANISM
Subscriber information Unauthorized access Terminal access control
Unauthorized modification Transaction VPN
Transaction information Unauthorized access Integrity protection of subscriber
Unauthorized modification and transaction information
54
- 55 -
FG IPTV-DOC-0045
As described in the previous chapter, access to the terminal over the network needs to be strictly
controlled to prevent unauthorized remote access to subscriber information. Depending on the
nature of the service, it may be desirable to restrict the subscrib er’s information from local access to
the Terminal from the console, if there is a console on the terminal device. In general, it is prudent
to use encrypted and integrity-protected connections (such as a VPN) between the Terminal and the
service provider’s equipment when information about the subscriber and the subscriber’s
transactions is carried over the network.
-----------------------END
_________________
55
