ETSI TS 187 021 V3.1.1 (2011-09)

Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Security services and mechanisms for customer premises networks connected to TISPAN NGN

DTS/TISPAN-07047-NGN-R3

General Information

• Status: Published
• Publication Date: 11-Sep-2011
• Technical Committee: TISPAN 7 - TISPAN Security
• Current Stage: 12 - Completion
• Due Date: 31-Aug-2011
• Completion Date: 12-Sep-2011

Standards Content (Sample)

Technical Specification
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Security services and mechanisms for customer premises
networks connected to TISPAN NGN

2 ETSI TS 187 021 V3.1.1 (2011-09)

Reference
DTS/TISPAN-07047-NGN-R3
Keywords
gateway, IP, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 187 021 V3.1.1 (2011-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 General overview . 8
5 Firewalling . 9
5.1 Firewalling: basic description. 9
5.2 Firewalling: architecture . 9
5.3 Firewalling: implementation details . 10
6 SP and/or CP secure upgrade . 12
6.1 SP and/or CP secure upgrade: introduction and scope . 12
6.1.1 Introduction. 12
6.1.2 Scope . 13
6.2 SP and/or CP secure upgrade: architecture . 13
6.2.1 SP and/or CP upgrade stakeholders . 13
6.2.1a CND secure upgrade trust hierarchy . 15
6.2.1a.1 IPTV trust authority . 15
6.2.1a.2 Registration operator trust authority . 16
6.2.1a.3 ISP trust authority . 16
6.2.1a.4 IPTV service provider trust authority . 16
6.2.1a.5 SP/CP trust authority . 16
6.2.1a.6 CND trust authority . 16
6.2.1a.7 Chip manufacturer trust authority . 16
6.2.1a.8 IPTV service provider specific trusted platform software and applications . 17
6.2.1a.9 IPTV service provider common applications . 17
6.2.2 SP and/or CP upgrade architecture . 17
6.2.2.1 Overview . 17
6.2.2.2 Functional entities . 17
6.2.2.3 Affected interfaces and reference points . 18
6.2.3 SP and/or CP upgrade use cases . 19
6.2.3.1 General . 19
6.2.3.2 User changes service provider. 19
6.2.3.3 A stakeholder X requests to be firmware owner . 20
6.2.3.4 Firmware owner requests upgrade of firmware. 21
6.2.3.5 A stakeholder Y requests to be SP owner . 21
6.2.3.6 SP owner requests upgrade of SP software module . 22
6.2.3.7 A stakeholder Y requests to be CP owner . 22
6.2.3.8 CP owner requests upgrade of CP software module . 23
6.2.4 SP and/or CP upgrade security architecture . 23
6.2.4.1 Trusted environment architecture for SP/CP . 23
6.2.4.1.1 Hardware supported trusted environment preventing Hi-Jacking . 23
6.2.4.1.2 Hardware supported trusted environment, protecting the key flow . 27
6.3 SPCP secure upgrade: implementation details . 27
7 Network Access Control (NAC) . 28
8 Hosted-NAT solution for RTSP based services . 30
8.1 Hosted-NAT for RTSP: basic description . 31
ETSI
4 ETSI TS 187 021 V3.1.1 (2011-09)
8.2 Hosted-NAT for RTSP: architecture . 31
Annex A (informative): Example of a secure boot protocol . 33
A.1 Type 1 STB architecture. 33
A.1.1 Primary boot loader . 33
A.1.2 Secondary boot loader . 34
A.1.3 Secure boot process flow . 35
A.1.4 Error handing and recovery procedures . 35
A.1.4.1 General . 35
A.1.4.2 Recovery sources . 35
A.1.4.3 Recovery success verification & re-try . 36
A.1.4.4 Recovery firmware . 36
A.1.4.5 Automated re-imaging of 'recovery partition' . 36
A.1.4.6 Recovery user interface . 37
A.1.4.7 Recovery functionality . 37
A.1.4.8 UI fecovery screen . 37
A.1.4.9 Start-up animation sequence . 37
A.1.4.10 Start-up scripts & driver initialization . 37
Annex B (informative): Examples of a secure run time protocols . 38
B.1 Type 1 STB architecture. 38
B.1.1 Secure CND run time protocol . 38
B.1.2 Kernel™ signing patch . 38
Annex C (informative): Example of a secure package download protocol . 40
C.1 Type 1 STB architecture. 40
C.1.1 Secure package download overview. 40
C.1.2 Secure package download protocol . 41
Annex D (informative): Bibliography . 45
History . 46

ETSI
5 ETSI TS 187 021 V3.1.1 (2011-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
ETSI
6 ETSI TS 187 021 V3.1.1 (2011-09)
1 Scope
The present document specifies the functional models and information flows (stage 2) and protocols (stage 3) which
implement the security services and mechanisms required to provide security in a Customer Premises Network (CPN)
to support the overall security architecture for NGN release 3. CPN security services and mechanisms are used either
singly or in combination to realize the CPN security requirements specified in TS 187 001 [1] (NGN Security
requirements). Reference will be made to TR 185 012 [i.1] for security mechanisms that have been shown to be
appropriate for CPN environment.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 187 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN SECurity (SEC); Requirements".
[2] ETSI TS 185 006: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Customer Devices architecture and Reference Points".
[3] ETSI TS 185 003: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Customer Network Gateway (CNG) Architecture and
Reference Points".
[4] ETSI TS 187 003: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Security; Security Architecture".
[5] Broadband Forum TR-069 Amendment 3: "CPE WAN Management Protocol", November 2010.
[6] Broadband Forum TR-157 Amendment 3: "Component Objects for CWMP", November 2010.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 185 012: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN) Feasibility study of security mechanisms for customer premises
networks connected to TISPAN NGN".
[i.2] IETF RFC 5209 (June 2008): "Network Endpoint Assessment (NEA): Overview and
Requirements".
[i.3] ETSI ES 282 003: "Telecommunications and Internet converged Services and Protocols for
advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS):
Functional Architecture".
ETSI
7 ETSI TS 187 021 V3.1.1 (2011-09)
[i.4] ETSI TS 102 825 (all parts): "Digital Video Broadcasting (DVB); Content Protection and Copy
Management (DVB-CPCM)".
[i.5] ETSI TS 183 065: "Telecommunications and Internet converged Services and Protocols for
Advanced Networks(TISPAN); Customer Network Gateway Configuration Function; e3 Interface
based upon CWMP".
[i.6] Broadband Forum TR-069: "CPE WAN Management Protocol".
[i.7] IEEE 802.16: "IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for
Broadband Wireless Access Systems".
[i.8] IEEE 802.1b: "IEEE Standard for Local and Metropolitan Area Networks - Local and
Metropolitan Area Network: LAN/MAN Management".
[i.9] Home Gateway Initiative: "Home Gateway Technical Requirements V.1.0".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TS 187 003 [4] and Broadband Forum
TR-157 [6] apply.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACS Auto-Configuration Server
AKA Authentication and Key Agreement
ALG Application Level Gateway
API Application programming Interface
B2BUA Back to back User Agent
BGF Border Gateway Function
BL1 Boot Loader image
CA Conditional Access
C-BGF Core- Border Gateway Function
CND Customer Network Device
CND-CMF CND-Configuration and Management Function
CND-CPF CND-Content Protection Function
CND-CSMF CND-Communication Service Media Function
CND-SPF CND-Service protection Function
CNG Customer Network Gateway
CP Content Protection
CPE Consumer Premise Equipment
CPN Customer Premises Network
CW Control Words
DLNA Digital Living Network Alliance
DMZ Demilitarized Zone
DOS Denial of Service
DRM Digital Right Management
DSL Digital Subscriber Line
DVB Digital Video Broadcasting
DVB-CPCM DVB Content Protection & Copy Management
FW Firmware
HGI Home Gateway Initiative
HTTP Hyper Text Transfer Protocol
ICMP Internet Control Message Protocol
IMS IP Multimedia Subsystem
ETSI
8 ETSI TS 187 021 V3.1.1 (2011-09)
IPSEC Internet Protocol SECurity
IPTV SP IPTV Service Provider
IPTV Internet Protocol TeleVision
IPv6 Internet Protocol version 6
ISP Internet Service Provider
MCF Media Control Function
MDF Media Delivery Function
MF Media Function
MFC Media Control Function
NAC Network Access Control
NAT Network Address Translation
NEA Network Endpoint Assessment
OMA Open Mobile Alliance
PAT Port Address Translation
PC Protection Client
PCL Protection Client Loader
PCO Protection Client Owner
P-CSCF Proxy-Call Session Control Function
PDA Personal digital assistant
PPP Point to Point Protocol
QoS Quality of Service
ROM Read Only Memory
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
SMS Short Message Service
SOC Security-on-Chip
SP Service Protection
SP/CP Service Protection and/or Content Protection
SSL Secure Socket Layer
STB Set Top Box
TCP Transmission Control Protocol
TLS Transport Layer Security
UC Unsolicited Communication
UDP Datagram Protocol
UE User Equipment
UICC Universal Integrated Circuit Card
UPnP Universal Plug and Play
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTM Unified Threat Management
VOD Video On Demand
VPN Virtual Private Network
WFA Wi-Fi Alliance
Wi-Fi Wireless Fidelity
WPA2 Wi-Fi Protected Access 2
4 General overview
This clause introduces the subset of security mechanisms to be evaluated and specified in details within the present
document. The security mechanisms has been selected mainly (but not only) from the contents of the TR 185 012 [i.1].
ETSI
9 ETSI TS 187 021 V3.1.1 (2011-09)
5 Firewalling
The main mechanism to perform Network Access Control is a firewall, i.e. a system designed to permit, deny or proxy
data traffic to or from the customer's network. A firewall is positioned to control all incoming and outgoing traffic;
hence the CNG is the perfect candidate to perform the firewall functions.
5.1 Firewalling: basic description
There are several approaches to implements firewall functionalities, such as:
• Packet Filtering: the simplest one inspects each incoming or outgoing IP packet permitting, dropping or
rejecting it on the basis of simple policies (usually defined as access control list) such as the IP address and the
protocol type.
• Stateful Firewall: in addition to a Packet Filter, keeps track on IP packets belonging to the same connection
thereby detecting whether a packet is part of an existing connection or a start of a new connection.
• Application Level Gateway: In addition to a stateful firewall can understand the behaviour of some
applications and can detect e.g. if an illegal protocol is used for a given application or dynamically open ports
for additional sessions belonging to a flow.
Firewalls can divide the network into subnets each one with a different level of security and different security policy as
for example a demilitarized zone.
The firewall could have several configuration alternatives.
• A basic/minimum configuration to ensure a minimum level of security.
• One or several default configurations provided and managed by the operator/service provider through a remote
management system.
• Additional alternative configurations that can depend on the user (e.g. there can be different configurations for
parents and children). These user specific configurations could be managed by the same entity managing the
user identity (e.g. the UICC).
5.2 Firewalling: architecture
In the CPN context, the CNG sits between the NGN and the internal network and this aspect makes the CNG as the
perfect candidate to host the firewall functions. Figure 1 shows a typical scenario where the CNG and the Firewall are
co-located on the same device. The external interface is the one that is connected to the NGN via e.g. xDSL,
IEEE 802.16 [i.7] wireless modem, FTTx, etc., and is often referred to as the unsecure (red) interface. The secure
(black) internal interfaces are connected to the CNDs and can be based on ethernet, IEEE 802.1b [i.8] and other wired
or wireless communication technologies. The firewall may also implement a DMZ.
ETSI
10 ETSI TS 187 021 V3.1.1 (2011-09)

Figure 1: Firewall in the CPN
The advantages of using a Firewall as shown in the picture (i.e. co-located on the CNG) is that the CNG appears to the
external network (i.e. NGN) as the only point of contact for the CPN, simplifying the protection of the CNDs against
threats that originate on the NGN.
5.3 Firewalling: implementation details
For the protection of the CPN, a firewall should support some basic features, such as security policy definition and
enforcing, firewall management, logging functions and so on. The following clause describes in details such features.
5.3.1 Stateful inspection
The stateful firewall function is mandatory for the protection of the CPN, such a firewall function may be implemented
in the CNG. While a packet filter decides whether or not to drop a packet based on few information contained in the
packet headers (e.g. addressing information), a stateful packet filter takes its decisions also on the state information that
the firewall keeps in memory about all active connections travelling across it.
For connection-oriented protocols, such as TCP, the state of the connection is equivalent to the protocols definition of a
connection (i.e. three-way handshake), whereas for a connection-less protocol, such as UDP, the state of the connection
is the set of packets that are sent between common endpoints (i.e. source IP address/port and destination IP
address/port) without interruption, i.e. the lack of any packets matching that flow for a given period of time. For the
CPN context such a period of time shall be one minute.
The stateful firewall shall also perform additional structural checks on network packets. These checks include
e.g. quickly dropping of malformed packet and enforcing the TCP three-way handshake to establish and teardown
network connections.
5.3.2 Communication technologies
The Firewall shall be enabled on the local CPN network including all kind of wired and wireless connectivity used on
the CPN, as well as remote access connections such as PPP over Ethernet and Virtual Private Network on the WAN
side of the CNG. Note however that the firewall cannot be enabled when the CNG acts as a network bridge.
IPv6 firewalling shall be implemented in case the CNG supports IPv6 traffic.
ETSI
11 ETSI TS 187 021 V3.1.1 (2011-09)
5.3.3 Security policy
The firewall could have several configuration alternatives. In order to simplify the management of the security policy
and still provide a basic level of security to the CPN it is proposed to define one or more security profiles.
As defined by HGI in [i.9] at least the following basic configurations shall be supported by the firewall: HIGH security
configuration and LOW security configuration.
The HIGH security configuration foresees the following behaviour:
• For the traffic originated from the NGN toward the CPN (inbound): to refuse connections in TCP, UDP and
ICMP; to authorize already established connections only (and known by the stateful firewall).
Based on the Operator/Service Provider local policy, the firewall could accept incoming connections for
specific services/ports, such as 5 060 for SIP (e.g. inbound SIP calls).
• For the traffic originated from the CPN toward the NGN (outbound): to authorize only well known ports, such
as:
- 25 - SMTP
- 80 - HTTP
- 443 - SSL
- 554 - RTSP
- 995 - POP3
- 123 - NTP
- 5 060 - SIP
A second alternative basic firewall configuration shall be supported by the firewall, the LOW security configuration: all
traffic (inbound and outbound) is authorized by default. Anyway the stateful firewall still performs the security check
on the TCP/UDP active sessions.
Also Internet Control Message Protocol (ICMP) messages should be managed because these messages can be used in
hacking and DOS attacks. The firewall should block or allow specific ICMP options (e.g. Echo Requests, destination
unreachable).
Additional alternative configurations can depend on the user preferences and/or Operator/Service Provider local policy.
5.3.4 ALG for standard protocols support
Also a stateful firewall is not effective or could limit specific services with applications that include IP addresses and
TCP/UDP port information in the payload (e.g. FTP, SIP protocols, peer to peer applications). To filter these protocols,
and at the same time permit the access to such services, the firewall has to be augmented by specific Application Level
Gateway.
The firewall should contain support for the NGN standard protocols, such as SIP and RTSP, for the pinholing of the
media ports so that the inbound and outbound traffic could flow through the CNG.
Note that when B2BUA is implemented inside the CNG, TS 185 003 [3], it acts as a SIP ALG; in this case the B2BUA
shall interact with the firewall.
5.3.5 Firewall management
The firewall should be manageable from the CPN and by the IPS/Operator and it should enable the ISP/Operator also to
upgrade the firewall functionality via download of a new configuration file. To implement this operation, the
management centre downloads to the CNG firewall the configuration file. This file integrates the basic firewall
configuration that includes the HIGH and LOW configurations. As described by HGI in [i.9], DSL Forum TR-069 [i.6]
provides mechanisms for configuration file downloads. The TISPAN CPN firewall should support TR-069 [i.6].
However, some additional mechanisms and specifications could be needed to fully support the CPN security
requirements, for example OMA device management which supports also the security of the management.
ETSI
12 ETSI TS 187 021 V3.1.1 (2011-09)
The management features should permit the upgrade of the software firewall, the management of the security policy and
the access to the logging information.
5.3.6 Logging
The firewall should have the ability to log network traffic and main security events. Basic logging options should be
supported (by default all logging options should be disabled). The logging function should capture at least the following
events:
• Log of changes to firewall policy.
• Network connection logs, which include dropped and rejected connections (for both inbound and outbound
packets).
• Log of software firewall upgrade events.
The log files should be accessible from the remote management.
6 SP and/or CP secure upgrade
6.1 SP and/or CP secure upgrade: introduction and scope
6.1.1 Introduction
Interoperability of the CPE (IPTV CND or CNG) means that the end user can switch the CPE to another IPTV service
provider without having to change the CPE (assuming that the transmission technology does not change).
IPTV Provider 1
Change
Access Provider
of
WAN
IPTV
Legacy
IPTV Provider 2
TV
DLNA
devices
IPTV enabled
Figure 2: SP & CP architecture
An IPTV specific requirement which has a strong influence on interoperability is the use of service and/or content
protection (SP/CP) systems aka CA/DRM systems.
Service Protection/Content Protection Interoperability (in short SP/CP Interoperability) of CPE with a IPTV Service
Providers offering means that an end user can switch to another Service Provider (using a different SP/CP system) to
obtain service from whilst retaining his CPE equipment.
In order for CPE not to have to implement every (possibly proprietary) SP/CP system that exists, for such kind of
interoperability CPE is required to support upgrade/renewal of its SP/CP software and potentially the cryptographic
algorithms used by the SP/CP system for scrambling content.
NOTE 1: This type of interoperability does not solve the reuse of previously bought protected content, when the
SP/CP system changes. Frameworks like DVB-CPCM (see all parts of TS 102 825 [i.4]) solve that inter
CP interoperability problem on the CPE side, this is also an important topic but it is complementary to the
CPE - service provider interoperability addressed in this clause.
NOTE 2: Once a SP/CP software is upgraded and taken into operation there is no further dependency on the SP/CP
upgrade mechanism.
ETSI
13 ETSI TS 187 021 V3.1.1 (2011-09)
The requirements that the secure SP/CP upgrade mechanism needs to comply with are specified in TS 187 001 [1],
clause 4.19.5. The subsystem in CND that implements the CPN side of the mechanism is specified in TS 185 006 [2].
6.1.2 Scope
The scope of this clause is to describe a solution that enables "Secure upgrade of Service Protection and/or Content
Protection" software. The solution has to be generalisable to other types of software.
The following will be covered to specify a solution to "Secure upgrade of Service Protection and/or Content
Protection":
• stakeholder model;
• trust hierarchy model;
• upgrade use cases;
• functional architecture;
• threats;
• security architecture;
• upgrade protocol details.
The solution for "Secure upgrade of Service Protection and/or Content Protection software" will have to cover different
aspects to achieve a trusted platform for Firmware, service protection and/or content protection, or other software.
These aspects are:
• Secure loading of software by the CND. This enables secure boot time and runtime loading of software, to
achieve a trusted environment for SP and/or CP or other software at all times.
• Secure upgrade of software on the CND. This enables secure upgrade of software, to achieve a trusted
environment for SP and/or CP or other software.
6.2 SP and/or CP secure upgrade: architecture
6.2.1 SP and/or CP upgrade stakeholders
The following stakeholders in the CND upgrade process have been identified:
CND Custodian: A CND custodian would act as a trust authority for CND's and certify all public device keys of
compliant devices. With them a service provider can verify that a connected device is authorized to download a new SP
and/or CP implementation. A CND provider or chip(-set) provider can obtain public-private key pairs from the
Custodian for use in production of certified implementations of the CND upgrade system, the security of this process
shall be under contractual agreements between the custodian and the CND provider.
Internet Service Provider Custodian: An ISP custodian would act as a trust authority for ISP's certify all public
device keys of trusted Internet Service Providers. With them a CND can verify that an Internet Service Provider is
authentic and authorized to download new CND software. Once connected to the Internet Service Provider, a CND
obtains Internet Service Provider's public key with a valid certificate from that Custodian and can proof it.
IPTV Service Provider Custodian: An IPTV Service Provider custodian would act as a trust authority for IPTV
Service Providers and certify all public device keys of trusted IPTV Service Providers. With them a CND can verify
that an IPTV Service Provider is authentic and authorized to download a new CND implementation. Once connected to
the IPTV Service Provider, a CND obtains IPTV Service Provider's public key with a valid certificate from that
Custodian and can proof it.
ETSI
14 ETSI TS 187 021 V3.1.1 (2011-09)
SP/CP Custodian: An SP/CP custodian would act as a trust authority for SP providers and CP providers and certify all
public keys used during the SP or CP software upgrades for validation of the software upgrade signatures. The
validation of the signed software download can be performed through the SP provider or CP Provider to be sure that the
software download has been performed properly. An SP provider or CP provider will obtain certified public keys
needed for the validation of the CND.
Internet Service Provider: The Internet Service Provider is the actual provider of the IP connectivity service that a
user wants to use. The Internet Service Provider can use remote management interface with the connected CND that it
is entitled to manage in order to upgrade the CND software or security credentials on the CND side in order to match
the network side of the IP connectivity service offering.
IPTV Service Provider: The IPTV Service Provider is the actual provider of the IPTV service that a user wants to use.
The IPTV Service Provider can use remote management interface with the connected CND that it is entitled to manage
in order to upgrade the CND software or security credentials on the CND side in order to match the network side of the
IPTV service offering.
SP Provider: The provider of the end-to-end service protection system that the service provider uses. The SP provider
could for example provide the actual SP software and upgrades to be loaded by the CND in order to interoperate with
the IPTV Service Providers service offering.
CP Provider: The provider of the end-to-end content protection system that the service provider uses. The CP provider
could for example provide the actual CP software and upgrades to be loaded by the CND in order to interoperate with
the IPTV Service Providers service offering.
CND Manufacturer: Fabricates the equipment that complies with the CND upgrade mechanism.
Chip Manufacturer: Fabricates the chip-set that complies with the CND upgrade mechanism.
User: The consumer of the service that the Service Provider offers. Normally the user is not aware of the upgrade
mechanism; this should normally not need any user interaction. The only case where user consent might be needed is
the Service Provider handover case, where the user needs to confirm that it is OK that a second Service Provider gets
entitled to perform software upgrades in order to allow the CND to be used with this second Service Provider.
Figure 3 shows the an example case when the CND upgrade is for Service Protection and/or Content
protection (SP/CP).
devicecertificates &
private keys &
custodiancer tificate
Custodian
CND
(3rd Party Trust Provider)
Manufacturer
serviceprovidercertificate &
production/
custodiancer tificate &
factory configuration
verification
( deviceID + private key + certificates)
remote management &
deviceauth. &
IPTV SP/ CP softwareauth.
Secure hardware/
Service
device ID + private key
Provider
user
Software Loader
interaction
SP/CP cert. & SP/ CP systems&
User
custodiancert. SP/CP CND software+
SP or CP execution
signature
container
SP/ CP Decryption
CND
Provider Security Processor
Actor/ Stakeholder
Figure 3: CND upgrade for SP CP example
ETSI
15 ETSI TS 187 021 V3.1.1 (2011-09)
Other concepts depicted in figure 3:
Secure hardware with device ID and private key: Secure hardware implementation of the software upgrade system
in the CND which contains a tamper-proof burned-in private key that is used in the process whereby a service provider
verifies that this is a trusted implementation.
Software loader: A build-in bootstrap loader that loads the SP or CP system software and additional decryption
algorithms from the service provider at first startup or during upgrade.
SP/CP execution container: SP/CP system software will be loaded into a secure hardware execution environment.
Security processor: An on-chip security processor that has some build-in hardwired or software decryption algorithms.
6.2.1a CND secure upgrade trust hierarchy

Figure 4: X CND secure upgrade trust hierarchy
6.2.1a.1 IPTV trust authority
This is root of trust that will ensure that only an authorised Registration Operator can add new trust authorities for:
• Internet Service Provider.
• IPTV Service Provider.
• SP provider or CP Provider.
• CND Manufacturer.
• Chip Manufacturer.
It will also allow the Registration Operator to be changed at any time by revoking and replacing the certificate issued to
the Registration Operator.
ETSI
16 ETSI TS 187 021 V3.1.1 (2011-09)
6.2.1a.2 Registration operator trust authority
The role of the Registration Operator is day to day adding and removing Internet Service Provider, IPTV Service
Provider, SP provider, CP Provider, CND Manufacturer and Chip-set Manufacturer trust authorities by registering and
deregistering them and providing the necessary credentials to communicate securely with the CND and subscribers.
While the number of IPTV Service Providers and CND providers may be small, the number and amount of change in
common applications may eventually be very large, so it is important to isolate the higher Trust Authorities from day to
day operational role.
6.2.1a.3 ISP trust authority
The service may be dependent on agreement with certain ISP's to provide, say, a minimum level of QoS which requires
a secure distribution of configuration parameters to the CND and possibly IPTV Service Provider. This branch provides
ISP and CND specific security credentials for this configuration
6.2.1a.4 IPTV service provider trust authority
Many aspects of end to end security are critically dependent on ensuring that the confidentiality and integrity of the
IPTV Service Providers CND software and applications is ensured at:
• each and every service invocation;
• during run time of the CND software;
• before and after any remote upgrade to such software.
This branch provides IPTV Service Provider specific security credentials to ensure this confidentiality and integrity.
6.2.1a.5 SP/CP trust authority
Many aspects of end to end security are critically dependent on ensuring that the confidentiality and integrity of the SP
or CP software ensured at:
• each and every service invocation;
• during run time of the CND software;
• before and after any remote upgrade to such software.
This branch provides SP and CP specific security credentials to ensure this confidentiality and integrity.
6.2.1a.6 CND trust authority
Many aspects of end to end security are critically dependent on ensuring that the integrity of the CND is ensured at:
• each and every boot;
• during run time of the CND operating system;
• during run time of CND specific applications;
• before and after any remote upgrade to such software.
This branch provides CND specific security credentials to ensure this integrity. For example, CND specific Boot,
Kernel™ and Root File system access keys.
6.2.1a.7 Chip manufacturer trust authority
Many aspects of end to end security are critically dependent on ensuring that the integrity of the processor chip or
security chips. This branch provides chip manufacturer specific security credentials to ensure this integrity. For example
SOC specific identities and access keys.
ETSI
17 ETSI TS 187 021 V3.1.1 (2011-09)
6.2.1a.8 IPTV service provider specific trusted platform software and applications
There will be applications that are specific to a particular IPTV Service Provider.
6.2.1a.9 IPTV service provider common applications
As well as IPTV Service Provider specific trusted platform software and apps, there will be applications that are
common to all IPTV Service Providers but need to be restricted to certain IPTV Service Providers only. These would
include standardised VOD applications, etc.
6.2.2 SP and/or CP upgrade architecture
6.2.2.1 Overview
Figure 5 is a depiction of a CND architecture that shows the typical functions needed in an IPTV CND that supports
consumption of protected linear TV content and allows upgrade of the SP and/or CP or other software to enable change
of IPTV service provider.
S
CPE
Applications
User
S (X ,G , U T ,C ) IPTV
ServiceSelectionandPTV-Control a m t or r t2 SP CP
APIs
API API
Configuration &
Management
Middlewa
...