Key Fly 2.

0Xtreme

Conditional Access System

Document Reference: MPKF-WP-08001v1.7

SIDSA

Key Fly 2.0Xtreme

KeyFly 2.0 Xtreme

SIDSA, 2008. All rights reserved According to the laws of Spain, this document and the information contained therein are confidential and valuable trade secrets of SIDSA. This document shall not be used for commercial purposes other than for supporting internal discussions between SIDSA and the Company. This document cannot be copied, disclosed, reproduced, stored in a retrieval system or transmitted in any form or by any means or otherwise used, whether in whole or in part, except in accordance with the prior written agreement of SIDSA. The information contained in this document shall not be understood in any case as being legally or contractually binding for SIDSA in any manner whatsoever. SIDSA shall be entitled to modify the contents of this document, in whole or in part, at any time, without the other party or any third party holding any right to seek compensation for those changes or compliance from SIDSA with its terms.

Table of Contents

NAMING CONVENTIONS ----------------------------------------------------------------INTRODUCTION -------------------------------------------------------------------------------

4 4

Present situation of conditional access systems (CAS) ------------------------4 Main hacks --------------------------------------------------------------------------------------- 5 Market trends ----------------------------------------------------------------------------------8 Smartcard systems vs. systems without smartcards ----------------------------9 Breakdown of CA costs in receivers --------------------------------------------------- 10 ABOUT KEYFLY 2.0XTREME --------------------------------------------------------------- 12 Description of the System -----------------------------------------------------------------Architecture ----------------------------------------------------------------------------End client devices -------------------------------------------------------------------Security ---------------------------------------------------------------------------------Scalability ------------------------------------------------------------------------------Modularity -----------------------------------------------------------------------------Types of rights -----------------------------------------------------------------------KeyFly business model development ----------------------------------------Product generation system ------------------------------------------------------KeyFly support in the set-top box ---------------------------------------------KeyFly commercial parameters -------------------------------------------------Central server architecture -------------------------------------------------------KeyFly 2.0Xtreme FAQ -----------------------------------------------------------------------Conditional access system specifications ----------------------------------General ----------------------------------------------------------------------------------Integration in DVB-T headends -------------------------------------------------Support for receivers ------------------------------------------------------------------------Which manufacturers and models support KeyFly? --------------------How is a receiver certified and how long does the process take? -What does the receiver require to support KeyFly? --------------------Can the terminal software be updated? -------------------------------------Can information banners or messages be sent to the user? ---------KeyFly security ---------------------------------------------------------------------------------How is security implemented in KeyFly CAM? ---------------------------How does KeyFly avoid piracy? ------------------------------------------------Are there any countermeasures? ----------------------------------------------What is KeyFlys roadmap? -----------------------------------------------------13 13 16 17 17 17 18 19 19 20 20 20 21 21 21 23 26 26 26 27 27 27 27 27 28 28 29

GLOSSARY -------------------------------------------------------------------------------------- 30

SIDSA

4
Naming Conventions / Introduction

In this document, the names KeyFly, KeyFly 2.0 and KeyFly 2.0Xtreme are used to describe KeyFly 2.0Xtreme CAS.

Smartcard-based CAS
Almost all the traditional CAS providers use smartcards. Basically, the smartcard stores the secret of the CAS (i.e. the code for opening the content and the algorithmics). The smartcard communicates either directly with the STB or with a conditional access module (CAM), which houses the smartcard and is inserted in a PCMCIA slot available in certain STBs and iDTVs. If the communication is direct with the STB and the decryption function available in the decoder chips is used, CAS software is required in the STB that is capable of communicating with the smartcard to carry the keys, programme information, etc. In the case of a CAM, the entire TS (transport stream) reaches the CAM, which communicates with the smartcard, decrypts the corresponding programmes and supplies them to the decoder chip (the new CI+ standard protects this communication between the CAM and the decoder chip with a copy protection system).

Present situation of conditional access systems (CAS)

At present, the conditional access market is highly fragmented. Although the DVB forum has created a standard, it is limited to interfaces and basic communication protocols between standard equipment (such as multiplexers) and CAS proprietary equipment, e.g. Simulcrypt (between the multiplexer-encoder and the CAS), CA message containers (EMM, ECM), common interface, etc. Basically, broadcasters marry a proprietary security solution, which has its advantages and disadvantages. One fundamental advantage is that the more proprietary the solution, the more guaranteed the security and in the event of a security breach, there is always a company to turn to. The main disadvantage is that a relevant part of the business depends on another company. It is true that a company can have two CAS providers, but that also increases the possibilities of a security breach. It is important to note that a CASs capacity for resisting hacks depends on how good the CAS devices in the receivers are. At present, there are three trends in security issues (according to the philosophy in the receiver): Traditional smartcard-based CAS. SW-based CAS. CAS based on proprietary HW (i.e. chip).

SW-based CAS
SW-based CASs are beginning to be accepted in IPTV environments since, as there is bidirectional communication, authentication mechanisms can be established that are not possible in a pure broadcast environment. The main problem of a SW-based system is the difficulty involved in providing horizontal solutions, since it is basic for the STB MW (where the SW-based CAS works) to be closely controlled (a CAS must be continuously updated to avoid pirac; in other words, it is much easier to break pure SW-based CASs, where there is no HW to hide secret codes).

SIDSA

5
Naming Conventions / Introduction

Basically, they are working in operating environments with middle-to-top-of-therange controlled STBs.

CAS based on proprietary HW (chip)

This is undoubtedly the most secure solution. It is based on the TS being inserted in a security chip and, with no exchange of codes with the exterior (i.e. with a smartcard), it comes out decrypted (in the future, when CI+ becomes available, even with copy-protection mechanisms). SIDSAs KeyFly 2.0 system works with a high-security chip, the K1, which can be found either embedded in an STB or in a CAM. This chip decrypts the programmes users have the right to watch, by processing the ECM (carrying the keys for opening the programmes) and the EMMs (carrying the users rights) that are included in the TS itself.
This document will show the advantages of using a solution based on a security chip and will perform a benchmark test with other CASs, demonstrating that, in many cases, the solution is cheaper than smartcard-based solutions and infinitely more secure.
STB Vendors
Subscribers

Comp

Prices

CAS

Pay TV Industry Market STB SHR

Content

Comp

Tech

STB Industry Market Pay TV SHR

STB

The Hacker industry is very powerful indeed. Price competition (and this also applies to the issue of card-sharing) is very intense and manufacturers and distributors need strong sales arguments. A STB that opens many channels free is a good sales argument.

Piracy
Importers Distributors Dealers End Users PC/CS

Main hacks
Nowadays, there are two typical types of hacking: Discovering how the CAS works (with access to the CAS program and keys). Card-sharing. The breach of the CAS usually occurs due to inverse engineering processes (less and less frequent) or due to the multiple integrations CAS manufacturers make with STB, often manufactured in China, which sooner or later reveal key parts of the CAS, making it possible for it to be opened.

Introducing sharing as value added Feature

STB Market

Potential customers find it attractive offer, many go for it Noticeable shift of current subscribers to sharing

Card-sharing is worse. It is an atomic bomb for the industry. It is based on sharing smartcards. Basically, the CAS is not breached; what happens is that the communication (which has a very low bitrate) between the smartcard and the STB, carrying the keys, is intercepted and sent over the Internet to other STBs (in some cases, they are sent on data channels by satellite or by using card-sharing gadgets at home).

SIDSA

6
Naming Conventions / Introduction

Transport Stream scrambled

STB with Smart Encrypted keys Card reader Clear keys

SmartCard

CARD SHARING

INTERCEPTABLE: REVERSE ENGINNERING

Although breaching the communication between the STB and the smartcard is a complex business, it is possible and the problem would remain. It would either require OTA to change the protocol or the smartcard would have to be changed. Pairing the STB with the smartcard is not useful for horizontal markets; it is useful only for vertical markets, where the STBs are strictly controlled. CAM with smartcard: The CAM requires a safe area to securitise the communications between the smartcard and the CAM; although not all the CAMs have this function, in general it is possible. Using a CAM does open up horizontal markets, since all it needs is for the STB (or the iDTV) to include a common interface slot (which is a standard feature, except for implementation errors). Although breaking into the communication between the CAM and the smartcard is a complex business, it is possible and the problem would remain. It would either require OTA to change the protocol or the smartcard would have to be changed. In greater detail: Smartcard-based systems suffer from a potentially serious security problem. The problem lies in the communication between the transport stream decryption unit located in the decoder in an insecure environment and the smartcard, which is, in principle, a secure environment, but with a very simple physical interface. A hacker could obtain the keys and algorithms that determine the encoding of the communications in a hired receiver by reverse engineering and ultimately be capable of obtaining the control words used to encrypt the transport stream, which

INTERNET

Card-sharing scheme

There are only two ways of fighting against card-sharing: A solution without a smartcard, e.g. the SIDSA solution based on a security chip. If there is no exchange of keys, there can hardly be any sharing. Pairing the STB (or the CAM) with the smartcard.
What features customers look for?
Other 13% Friendly user 16% Built-in cam 25% Sharing 33%

Which comes first?

Brand 31%

Price 29%

Features 40%

PRV 13%

Survey on satellite STB dealers in the Middle East Source: Non-disclosable SIDSA partner

Problems with pairing

STB with smartcard: The STB requires a safe area to securitise communications between the smartcard and the STB, but not all the decoder chips have this function. Therefore, it is not a universal solution. Furthermore, it could force STB manufacturers to use a specific decoder chip in accordance with the agreements between the manufacturer and the CAS provider.

SIDSA

7
Naming Conventions / Introduction

are unique. The control words are known with a typical anticipation of approximately 10 seconds, just enough time for a pirate server on the Internet to publish them for its subscribers. Basically, these subscribers have systems connected to the Internet that use the appropriate programmes to receive the control words in real-time and apply them to the decryption process of the transport stream without the need for any conditional access or contents provider device. If the pirate subscriber uses a PC with a fast Internet connection, penetration is unstoppable. The so-called pairing between the receiver and the smartcard would not represent an effective countermeasure on the above scenario. The existence of these so-called key servers is well known, albeit true that they have not attained popularity owing to the existence of other alternatives. The above system reveals several security problems: 1) Security is not actually end to end since the transport stream deciphering device is located in an insecure environment. The transport stream decryption process cannot be performed in the smart card owing to its huge bandwidth requirements. The communication can be protected only with reduced security means as far as the decoder software is concerned. 2) In the above system, there is no breach of the smartcard, but rather of the decoder software, which is much more insecure. Replacing the smartcard does not prevent the aforementioned attack. 3) The smartcard interface is the easiest option for reverse engineering operations, for being copied by very cheap illegal devices and for modifying the smartcard contents with special commands.

4) The conditional access software can only be fully renewed if it is done in the smartcard and in the decoder ; normally, there are several decoder models deployed, typically with different hardware and software versions. In practice, in a traditional software plus smartcard system, it is extremely difficult to change the software in all the components. Only the software in the smartcard can be changed. However, with the K 1 technology of KeyFly 2.0, all the security functions are executed in a protected environment. Even if there is communication with an external card for any reason (note that in KeyFly 2.0, there is no need for this since all CAS function runs inside K 1), it is made between two protected environments. The only input and output points of the K 1 are the transport stream and the user interface; there are no keys or rights on open user interfaces. Furthermore, since conditional access in KeyFly 2.0 is completely independent from the decoder software, there is real independence from the manufacturer of the decoder. Even with different brands of decoder, exactly the same software can be used to change the full conditional access on all the decoders. Finally, KeyFly maintains the concept of renewable security. Secured OTA upgrade is done in order to update CAS software in end-user devices (e.g. to add further security processing of keys) and to modify hardware configuration of K1 (e.g. modify configuration of decryption algorithms). These two methods ensure renewable security at no cost.

Market trends
The figures given here are taken from various market studies, mainly from IMS research.

SIDSA

8
Naming Conventions / Introduction

600 500 400 300 200 100 0 2004

600

iDTV vs STB in spanish market (monthly sales, in thousands)

429 161 109 219 132 202 111 junio07 248 129 julio07 207 129 ago07 225 154 sep07 314 166 oct07 291 127 nov07 257 dic07 252 ene08 433 337 141 feb08

iDTV STB DVD

2005 2006 2007 2008 2009 2010 2011 2012

400 200 191 186 0

118 feb07 133 mar07

abril07 mayo07

STB

iDTV

iDTV vs STB in spanish market: accumulated sales per year (in thousands)
4341 4000 3000 2000 1000 0 2560 858 2500 2600 2700 3789 4734 4559

Prediction of worldwie receiver grown

STB or iDTV
Integrated digital televisions (iDTV) are gaining ground on STBs. The new plasma technologies, LCD and DLP allow screen sizes and quality levels that are far superior to traditional television sets, which makes people buy them (the push from DVDs and HD DVD/Blu-ray is also important for the purchase of an iDTV) and the integration of digital receivers is simple (a near insignificant cost in comparison with the other electronics and the screen). Besides the adoption of TDT, government mandates (in Europe, it is obligatory for iDTVs to include TDT) and falling technology prices have boosted sales. 113.1 million units are expected to have been sold by 2012, with Western Europe taking a share of 31.6%. However, iDTVs are still limited by the entry barrier of cost and there is a great possibility of only the TV set in the living room being an iDTV while the others are much cheaper traditional TVs with a STB. There are also STBs that involve a higher value-added than iDTVs, such as PVR functions, programme recommenders/ finders, interactive services, etc. In addition, certain STBs are evolving into home media centres, which is a complicated goal for iDTVs in the short-mid term.

Feb 2008

STB

iDTV

H264.AVC and HDTV

Europe and the Middle East are expected to become the second-largest HDTV market in the world thanks to satellite on the one hand and to the planned launches of HD in TDT in Europe. H264.AVC will gradually replace MPEG-2 over the next five years, although many new launches of TDT have already begun with H264.AVC. High-definition TV marks the difference with multichannel standard-definition TV. The best content is therefore expected to move over to HDTV (sports, film premieres, etc.) and, in many cases, the content will possibly be pay television.

The common interface (CI)

The CI is enjoying a second youth and, as will be shown in later chapters, it is beginning to be more interesting for manufacturers to include a CI rather than a smartcard reader and reach agreements with CAS providers to include their proprietary protocols. In addition, the price of CAM in comparison with middle- or top-of-the-range

SIDSA

9
Naming Conventions / Introduction

STBs or iDTVs is beginning to become irrelevant (as happened with middle- or low-range STBs or zappers).

break easily). In addition, smartcard-based CASs are prone to card-sharing. Security chip: unlike smartcards, which require communication with the devices (CAM or STB), the security chip contains all the elements in the chip itself, which prevents reverse engineering (apart from tamper-resistant mechanisms). Besides, the fact that both its HW (part of it) and SW can be reconfigured by OTA, there are virtually millions of countermeasures (for possible hacking) that can be applied without the need for any physical change. In addition, the system is completely immune to card-sharing.

CI+
The strength of the common interface (in general, iDTVs incorporate CI bays and not smartcard readers) is making the industry take the current voids of the CI standard very seriously. Basically, the TS (transport stream) arrives encoded from the CAM (through the CI) and leaves clear from the CAM to the decoder (through the CI). Nowadays, it would be more than possible to capture the TS and resend it over the Internet. Accordingly, CI+ is being standardised. By means of a copy protection mechanism, it encodes the communication between the CAM and the decoder chip. The industry is waiting for CI+ to make a firm commitment to value contents, such as high-definition content (which, in any case, also requires new equipment in homes).

OTA (over-the-air updating)

Both systems can perform OTA. However, once the keys have been discovered, the smartcard needs to be replaced, but the chip HW can be reconfigured and a new CAS loaded and no replacement is necessary to set up a new CAS system.

Smartcard systems vs. systems without smartcards

Basically, this section compares smartcardbased CASs with CASs based on security chips, such as KeyFly 2.0. We do not make a comparison with software CASs (such as DCAS, i.e. downloadable CAS).

Business models: PPV, subscriptions, etc.

Both support all models.

Embedded rights
Both support embedded rights.

Security
Smartcard-based: traditionally, all the smartcard-based CASs have been hacked. The solution involves changing all the smartcards. Examples: some CAS vendors recommends changing them every 18 months while other systematically recommends changing the older smartcards (to avoid macro-substitutions); furthermore, on markets where smartcards are continuously being taken out and inserted in the STB, there is a high fault rate (they

Single multi-operator card

Both support single multi-operator cards, although the system without a smartcard is a virtual card.

Value-added applications with electronic IDs

Systems that use smartcards cannot perform simultaneous value-added applications that use electronic IDs since the SIM reader is occupied by the CAS. However,

SIDSA

10
Naming Conventions / Introduction

with a system based on the security chip, such as KeyFly, it is possible, since the reader is not used (e.g. the smartcard reader in the CAM, although a KeyFly CAM without a smartcard reader is possible to reduce costs).

Cost
See the following section; however, by way of summary, the systems based on a security chip are generally cheaper than those based on a smartcard.

or have any contact with CA vendors at all. All that is necessary is a CAM, a CA module that is generally available with a smartcard reader and is capable of communicating with the smartcard. In this case, the CA vendor only has to provide an interface with the CAM manufacturer instead of with all the STB manufacturers (or iDTV manufacturers). The situation is much more controlled. Pairing is much easier and the possibility of horizontal markets is also opened. In the CAM, there is a TS processor chip with a decrypter (DVB CSA: common scrambling algorithm). The SW that communicates with the smartcard runs in the said chip. Depending on the CAM, the STB will have more or fewer capacities: it will be able to perform multi-descrambling, have a dual or single smartcard reader, etc. There are CAMs that support several CASs at the same time. In a system without a smartcard, such as KeyFly 2.0, the said chip, which in the case of SIDSA is called K1, also includes highly protected internal memories and a greater processing capacity to include the CAS without the need for a smartcard. In other words, it is like a CAM chip with a SIM in it.

Breakdown of CA costs in receivers

What consumer equipment is necessary to watch pay-TV? STB with embedded CAS (+ smartcard) STB with CI plus a CAM (+ smartcard) iDTV plus a CAM (+ smartcard) STB with a patch hacked to watch free
pay-TV

STB-sharing generally with an Internet connection to obtain the keys. NB: the pirate systems are in italics... No further details will be given...

A STB with an embedded CAS must have implemented the CAS in the STB SW; in other words, the manufacturer must purchase a licence, pass the certification tests and pay a licence for each unit sold to the CA provider. Furthermore, the CAS software must be regularly updated (as a countermeasure) and the service is also usually charged (maintenance). Of course, the STB must include at least one smartcard reader. For including a CI Bay, the manufacturer does not have to pay any licence

Cost comparisons in reception:

(these comparisons exclude platform logo costs, which are commercial opportunity costs). Costs are calculated for minimum quantity of 100.000 ud.

STBs with smartcard vs. STBs with CI

STB with smartcard reader

SIDSA

11
Naming Conventions / Introduction

NRE certification CAS: between 200,000 and 15,000 (plus the cost of own development staff). This cost may be negligible when considering big quantities. Upgrades, CAS support: between 10,000 and 3000 per annum. CAS licence per unit: between $0 and $10 (depends largely on the market). Smart Card renewal is estimated each 18 months. Smart card cost depends on quantities and other commercial factors. Smartcard reader: approximately $1.30. STB with CI CI bay: approximately $2. CAM: CAM cost depends on quantities. CAM cost includes CAS license. In other words, for an extra 0.70 USD in HW, the manufacturer avoids all the integration problems with CAS vendors. However, for the pay-TV operator, the most secure option is undoubtedly the inclusion of the STB with CI.

Overall CAS cost in reception, solution with KeyFly 2.0 CAM

STB or iDTV STB (or iDTV): CI bay CAM.

Overall CAS cost in reception, solution with embedded KeyFly 2.0 (K1 chip)
STB NRE: Integration of K1 in STB. The reference design is similar to a CI, but with the SIDSA chip instead of the CI. As in the case of the smartcard system, the cost in the bill will be negligible if considering big quantities. STB: K1 chip cost and related circuitry. Smartcard reader (optional, not necessary with KeyFly CAS).
Overall cost calculated after 24 months business plan (typical renewal of SC every 18 months) KeyFly 2.0 CAS
Smarth Card Based CAS KeyFly 2.0 embedded in STB STB/iDTV CAM KeyFly 2.0 (CI) STB with Smart Card STB/iDVT with CAM (CI)

Overall CAS device Cost

Overall CAS cost in reception, solution with smartcard

STB STB: Smart card reader. CAS license. Smart card: two units, after 18 months. CAM STB (or iDTV): CI bay. CAM Smart card: two units, after 18 months.

Cost comparative table (after 18 months service and for large sales of devices). NB: Does not include the cost of the STB or the iDTV itself, only the extra charge of the CA. To conclude, systems based on a security chip are cheaper than those based on a smartcard reader and they also have a greater level of security.

SIDSA

12
About KeyFly 2.0Xtreme

KeyFly 2.0Xtreme (herinafter KeyFly 2.0 or KeyFly) is an advanced conditional access system that can be adapted to the various technical and commercial operating environments required by digital television broadcasting systems. KeyFly is particularly adapted to horizontal markets, such as TDT. The system is based on SIDSAs broad experience in the development of ASICs for cryptographic applications, conditional access and digital television. SIDSA is a conditional access provider capable of developing its own in-house ASIC hardware solutions for the problem of piracy that affects digital TV. KeyFly has been designed specifically to support the following specifications: Multiple client-side solutions. KeyFly supports smartcards, CAMs with integrated security (without smartcard), STB receivers with integrated security. Interoperable and independent from headend equipment manufacturers and based on open standards. Easily extendable, with support starting from a reduced number of subscribers and fully scalable. Supports distributed subscriber management, allowing another organisation to assume responsibility for distributing the access system (billing, etc.). Modular, with support ranging from simple subscription systems (not based on subscriber identity) to PPV. Interfaces with flexible subscription, including the Internet, SMS messages, call centers, etc. Multiple client-deployment options, from

support for common interface technology to integrated decoders. Implementation of scalable security. Brands: - KeyFly 1.0: CAS currently being discontinued, with devices based on MACtsp I chip. - KeyFly 2.0Xtreme: CAS that incorporates CAM devices or the embedded K1 chip only. - KeyFly+: future CAS (roadmap Q42008/Q1-2009) compatible with CI+. It will use the K2 chip. - KeyFly CI ready: If the product incorporates a common interface port that has been tested by SIDSA as compatible with our CAMs. - KeyFly empowered: The product incorporates the Kx chip inside (both STBs and CAMs). CAS devices: - MACtsp I: TS processing chip. Discontinued except for KeyFly 1.0. - Kx: family of conditional access chips. Current chip: K1. Scheduled for Q3 2008, the K2 supporting CI+. - Easy CAM: CAM that does not include a smartcard reader, only supports KeyFly 2.0. Decrypts two services. - Single CAM: CAM that only incorporates KeyFly 2.0 and a smartcard reader to support electronic ID reading. Decrypts two services. - Dual CAM: CAM that includes KeyFly 2.0 and the CAS of a licensed manufacturer. Decrypts two services.

SIDSA

13
About KeyFly 2.0Xtreme

- Triple CAM: (roadmap Q4-2008) CAM that includes KeyFly 2.0 and supports two licensed CASs. Incorporates a dual smartcard reader. Decrypts two services. - CAM PRO: Professional CAM, decrypts all the TS services simultaneously. All the CAMs support HDTV, MPEG-2 and H264/AVC. They also incorporate secure OTA.

Besides the proprietary hardware technology as a security support, KeyFly uses cryptographic algorithms and proprietary keys management systems, as well as an innovative traitor-tracing technique, which enables the rapid identification of compromised devices and their rejection in the system, excluding them from key renewals. KeyFly also uses cutting-edge technology for system and database management, using Web interfaces and XML-SOAP technologies to allow the integration with third-party systems for business management. The interfaces with purchasing channels and other systems are managed with separate modules, which means that the system can be configured to meet the operators requirements.

Description of the System

KeyFly has been designed as a modern, flexible conditional access system that adapts to the various technical and commercial operating environments required by digital TV broadcasting systems. KeyFly follows the definition of the DVB for conditional access systems, i.e. security divided between a common scrambling algorithm, approved by the DVB and safeguarded by the ETSI, which SIDSA is authorised to use accordingly, and a high-security encryption system developed and owned by SIDSA. On the receiver side, the KeyFly system is based on hardware circuits designed specifically by SIDSA for this purpose. The circuits allow the deployment of the system without the need for smartcards, but retaining all their flexibility. The K1 is the latest security device for procesing DVB Digital video developed by SIDSA. It is the only solution on the market in which all the security operations on the client side, from right-management to the decryption of the DVB stream, are carried out in one single tamper-resistant chip with RAM and internal FLASH and proprietary algorithms directly on the hardware. The K1 can be used embedded in the decoder or in a common interface module.

Architecture
The figure shows KeyFlys main software modules. The figure is used as a reference only for the dependencies and communications between the different modules and does not indicate the number of machines or instances of modules on which they run. Depending on the size of the system, all the modules can run on one single server or be distributed on several machines for performance reasons. The ECMG and the EMMG are the two components that connect with the multiplexer. The connection interface they follow is Simulcrypt, which allows other conditional accesses to coexist with KeyFly and not restrict the operator who wishes to migrate to other systems, which would require a change of equipment. In addition, the Simulcrypt standard ensures compatibility for a wide range of headend equipment available on the market. The function of the ECMG is to transmit the ECMs, right-control messages that indicate the access conditions that apply to

SIDSA

14
About KeyFly 2.0Xtreme

a specific content and the keys with which it is encrypted. The EMMG transmits the EMMs, right-management messages that transmit the new access conditions (aka. rights) to a client device or a group of client devices. The cryptoserver (CS) is a centralised cryptographic operations unit. All the cryptographic operations on the system are carried out by this module, which also has tamper-resistant devices to prevent the illegal extraction of keys by employees who are disloyal to the operator. The cryptoserver uses techniques established in the field of banking for operation security. The SAS is the component that builds the EMMs and manages the ECM-generation conditions. Unlike other conditional accesses, the SAS does not have databases. The DS is the component responsible for the software downloads on the client devices. The KeyFly monitor is an application that can be executed remotely on any machine and monitors the status of the above components. The said above components (SAS, DS, CS, ECMG, EMMG and KM) constitute the KeyFlyCORE, which is essential for operating a conditional access system in its most basic configuration. This configuration does not handle client databases (anonymous users) and the rights are awarded for a set period when the decryption device is purchased. The channels are not managed dynamically and only their basic configuration is accepted. In a distributed environment, such as DTT networks, each headend would include a KeyFlyCORE that would communicate with a KeyFlyCORE master and the KeyFly CRM for user control, etc.

SIDSA

15

This figure depicts the dependencies among components. Actual system may vary in number of instances of components and machines. Graphite Customers Web Portal Graphite SMS Mobile Gateway Graphite Operator Portal

Graphite Banking Interface

Third party CRM/BSS

Graphite Subscriber Manager

Data base: Customer info CA info OPS tracking...

Customer permises components

Horizontal market (common interface) CAM IDTV/STB with CI

Vertical market: Embedded STB STB Keyfly Embedded

KeyFly System KeyFly Manager

Headed components
MODULATION and DISTRIBUTION CHANNEL (DVB-S, DVB-C, DVB-T)

Crypto Server

SAS

ECMG EMMG

SIMULCRYPT MULTIPLEXER SCRAMBLER

DS KeyFly Monitor
ENCORER CONTRIBUTION VIDEOSERVER

16
About KeyFly 2.0Xtreme

KeyFlyCORE and KeyFly Manager makes up KeyFly System, which provides a complete set of features that enable operators to protect their content and to manage KeyFly CAS. KeyFly Manager is a module that enables the tracing of all the operations performed on the client devices. It allows the management of rights and the creation of products, but it does not have commercial information about the client. With KeyFly Manager, it is possible to know everything that happens in the conditional access system and it also provides an additional level of system control. Graphite Subscriber Manager increase functionality by providing additional management and business models and purchasing interfaces. Technologies based on application servers and Web servers with XML-soap interfaces are used to enable customisation tasks, improve the user interface (which does not require specific interface applications) and scale up performance. These technologies are also widely adopted for the development of business applications. Graphite Subscriber Managerenables the commercial operation of the system itself, including the management of operations with the client, package definition and data use. It is readily adaptable and can assume business rules and connect with other interfaces on interactive application servers and return channels. Several interfaces are provided for operating Graphite. Graphite Operator Portal for distributors or call center agents, Graphite Customer Web Portal, for end users that perform basic operations, and Graphite SMS Mobile Gateway, for managing operations coming from Mobile phone such us scratch-card activation. Finally, Graphite Banking Interface is used for connecting Graphite Customer Web Portal to a Bank Gateway for credit card purchase. A database ser-

ver provides storage services for Graphite Subscriber Manager and KeyFly Manager. It is also possible to carry out data-mining operations with the information available in this database. On the other hand, integration between KeyFly System and existing Business Support Systems (BSS, aka. Back Office) or thirdparty Subscriber Manager is straightforward due to standard XML interface. As indicated earlier, depending on the size of the system, all the modules can run on one single server or be distributed on different machines for performance reasons. KeyFly is perfectly scalable in accordance with the operators requirements. KeyFly has been designed in modules that can be added to a basic configuration to provide more features. These features make KeyFly particularly attractive for TV operators that are entering the market and want an alternative that is independent from existing CAS operators and plan to introduce new business models in the future.

End client devices

KeyFly is supported on ASICs (Application-Specific Integrated Circuits), developed by SIDSA itself, which permits to take advantage of microelectronic technology for system usability and security. SIDSA has developed the following ASICs for conditional access support: MACtsp I (in phase-out). This was the first-generation device for CAMs. The first to have an internally embedded 32-bit microprocessor. K1. The first device for common interface modules and receivers to include integrated RAM and Flash, with internal proprietary cryptographic devices and a

SIDSA

17
About KeyFly 2.0Xtreme

capacity for processing the entire conditional access from rights management to transport stream decryption without delegating in third-party hardware or reducing security due to the fact that it is a tamper-resistant system. The K1 is integrated in a STB without affecting system security since no information is provided to the receiver on how to decrypt the content or how to send messages (ECMs or EMMs) to the smart card, as occurs in traditional conditional access systems. CAMWatch. Integrated circuit for integrating the common interface (CI) in the receivers. In other words, it allows a dual CI. K2 (at design stage; scheduled for Q3-2008). The next generation of the Kx introduces support for CI+, Opencard, MHEG-5 interactivity. The final market format includes a very wide range of system implementations: In CAMs (PCMCIA) that allow any STB or iDTV receiver fitted with a common interface bay to support KeyFly. The Kx-based CAMs do not require the use of smart cards (even though they could be deployed as an option, since it is a CAM chip; indeed, SIDSA has a line of business for the sale of CAMs for other CAS providers), with the consequent reduction in the price of the system, in its deployment on horizontal markets. Embedded in STBs. The K1 is integrated in the receivers. Indicated especially for vertical markets or for a very low-cost STB with conditional access.

access system is only as secure as the security of the software in the receiver. The receiver is exposed to anybody who wants to change the software to obtain protected content illegally. KeyFly 2.0 is based on the K1 MPEG processor chip, designed and developed entirely by SIDSA. The chip has been designed from the experience obtained by SIDSAs engineers in the field of cryptography and conditional access over the last 10 years. The K1 in the receiver, whether in a CAM or embedded in STB, provides a fully protected environment for conditional access software. The K1 has internal FLASH and RAM memory that is protected from illegal access. This means that to change the software inside the chip, you must have the cryptographic tools required for the system to accept new software; this means that changing the software illegally is almost impossible. The K1 architecture is such that access to the internal chip memory is virtually impossible. This feature has been widely tested to ensure a very high level of trust in the chips capacity for protecting the internal memory from hackers.

Scalability
Scalability is the capacity for adjusting the system based on the continuous growth of client subscriptions. The basic system configuration is limited in the maximum number of subscribers supported. This limitation is based on physical limitations of the database system and system performance. The physical limitations are the encryptors processing capacities, the server running all the KeyFly System software and the server running the Subscriber Manager. KeyFly is completely scalable and supports multiple instances of its elements to improve performance.

Security
Security is the main feature on which the KeyFly conditional access system is based. A smart card based conditional

SIDSA

18
About KeyFly 2.0Xtreme

Modularity
KeyFly is modular in that certain functions can be implemented depending on the clients requirements. If the client requires minimum functionality, there is no need to deploy all the KeyFly systems modules.

channel, he authorises the deduction of 1 event of this type. c) He has sufficient credit in his purse. When he turns to the channel, he authorises the charge. The charges are authorised through a specific menu. Subscription Accordingly, the user can watch the content if he has the right on the date on which the content is broadcasted. Subscription is determined by an identifier, a start date and an end date. The user pays for the viewing period and there is no control over whether he views everything or nothing during the term of validity. Rights for consumption during subscription can only be awarded from Subscriber Manager or third party BSS. Once special subscription system is autosubscription, in which the main parameter is the term of the subscription. The start date is set when the consumer uses the content for the first time and the end date is set automatically in accordance with the term. This special type of right can only be awarded when the card is issued. This right cannot be sent from an SMS. Pay per view (session) In this mode, users can view content specified by sessions. Session is the content viewing unit, e.g. a complete film or a chapter of a serial. Each viewing unit is marked by an identifier (event-ID). The user is charged for the number of viewing units consumed. The user can change to another channel and return to the pay channel without being charged again if the content corresponds to the one he was charged for previously. This mode of consumption has maximum dates for consuming the purchased content.

Types of rights
From the point of view of the conditional access system, there are three types of rights over product consumption: Subscription. Pay per view (session). Pay as you watch. There are also two sources for awarding rights: Subscriber Manager (by means of any of its gateways) or electronic purse or (which is also reloaded from the Subscriber Manager). Contents can be watched simultaneously using various forms of consumption as chosen by the channel operator. For example, content could be watched because it forms part of the subscription or, at the same time, because the viewer pays using his purse (i.e. iPPV). From the users point of view, there are three types of purchases (which are carried out on the Subscriber Manager): Subscription to one or more channels for a specific period. Purchase of a number of events of a certain type (e.g. purchase of 10 action films). Reloading the purse with a certain amount. When viewing, the viewer can see a channel because: a) He has a valid subscription. b) He has events of this type available (he bought 10 films). When he turns to the

SIDSA

19
About KeyFly 2.0Xtreme

This mode of consumption has two subtypes: impulsive and non-impulsive. In the impulsive subtype, the product is contracted from the purse, which discounts the corresponding value. In the non-impulsive subtype, a number of viewing sessions are charged exclusively from the Subscriber Manager. The content is not automatically purchased simply because the user has credit. The system asks the user for express permission to purchase this type of content. The system asks the user for permission to watch a purchased event or for acquiring the rights for the viewing, charging the cost to the electronic purse. Pay as you watch In this mode, users can watch an event and pay as they watch it, e.g. if they watch 5 minutes, they pay 5 cents and if they watch 10 minutes, they pay 10 cents. The cost is charged exclusively to the electronic purse while the content is being viewed. The content indicates the costs per ECM (time unit) charged to the user. The content is not automatically purchased simply because the user has credit. The system asks the user for express permission to purchase this type of content.

CAM devices as virtual cards): Completely anonymous users with subscription rights or tokens on the virtual card with no update. User who is anonymous with regard to the operator but who reloads rights with a credit card on a bank gateway. User who is anonymous with regard to the operator but who reloads rights using a mobile telephone. User known by the operator with a classic subscription, interactive access to contents via a return channel and charge to a bank account. KeyFly has a mechanism for awarding rights that is particularly appropriate for managing requests under low EMM bandwidth requirements and cryptographic processing. This provides technological support for business models based on the PPV purchase of contents, with a short response time between the request and the right being awarded. Besides straightforward conditional access support, KeyFly supports the option for implementing messaging and bartering services without the need for deploying middleware in the decoders. Users can receive messages and view them on their own receivers. These messages are usually sent from the operator to the end user or to groups of users.

KeyFly business model development

With its modular structure and particularities that can be performed on Graphite Subscriber Manager or, in some cases, only on a third party Business Support System, the KeyFly architecture allows the development of different business models in accordance with the type of rights indicated above, but with interfaces with different means of payment. The following are a few examples (NB: hereinafter, we refer to embedded K1 and

Product generation system

The products are generated preferably on the CRM and, if the CRM is not available, on the SMS. The products are configured in order of hierarchy: definition of services, definition of product patterns, definition of product and definition of offer.

SIDSA

20
About KeyFly 2.0Xtreme

A service is a channel that is to be encrypted. A product pattern corresponds to a combination of services linked to a right or purse consumption. A product is a refined product pattern with expiry or duration dates. An offer is a product with a price. The end clients purchase offers, whereas system administrators define the purchasing conditions and hierarchy that ultimately define a product. This system affords great flexibility to the creation of the commercial terms and conditions for a product.

These parameters can be adjusted before production.

Central server architecture

As indicated previously, all the management software uses application server and web server technology, which makes it easy to increase the number of features and also provide a unique interface for other applications and for a human interface. The system can be controlled simply with a web browser with access to the KeyFly network. A username and password system controls the operations that can be performed by each user. The Web communications are protected by https.

KeyFly support in the set-top box

KeyFly uses the K1 chip as a security support, embedded in the STB. The K1 is the only device that handles the decryption, rights and all the cryptographic operations. It has embedded RAM and Flash, as well as proprietary cryptographic elements for maximum security. The STB manufacturer has no information about the procedures that control the encryption of the content.

KeyFly commercial parameters

The typical commercial specifications are as follows: Number of providers: 4 Number of subscription rights per provider: 21 Number of PPV rights per provider: 10 Number of associable rights per stream (service): 30 Number of different rights: 65,536 Number of different events for the same right: 65,536

SIDSA

21
KeyFly 2.0Xtreme FAQ

Conditional access system specifications

General
Does KeyFly support smartcards? Yes, KeyFly 2.0 has a smartcard implementation, but it is not the recommended method. KeyFly 2.0 is based mainly on a cryptographic chip, the K1, for the complete rights management and the decryption of protected contents. This is the great difference between KeyFly 2.0 and other conditional access providers. The K1 is a chip developed by SIDSA with the following specifications: Integration of Flash and RAM in the device. The chip has securitisation mechanisms similar to those used in smartcards, but also based on proprietary systems. Decryption of the transport stream in the device, without the need for communication with other devices for transporting the control words. Integration of cryptographic algorithms in hardware, some of which are proprietary, which prevents their reserve engineering. Common interface support and support for communications with smartcards. The K1 is supplied embedded in a common interface module or it can be integrated in the STB. When do the client devices have to be replaced? Intrusion in the K1 chip is considered almost impossible due to its specifications. The K1 is not a generic smartcard device, but rather it has been specifically designed to protect the transport stream. The control words are protected by proprietary

algorithms implemented directly on the hardware, as well as others implemented in software. SIDSA considers the reverse engineering of the said hardware algorithms almost impossible: there is no CAS software that can be read and ported to another processor. In addition, part of the HW can be reconfigured by OTA so that, even if the HW was emulated, SIDSA could change it through OTA on all the devices deployed. The latest techniques used in hacking conditional access systems are based on the publication of the control words that protect the encrypted content over the Internet. This technique is based on attacking the systems weakest point, which is the communication of the control words between the smartcard and the STB. As the STB is not an intrinsically secure device, it is relatively easy to extract the algorithms and keys that protect the said communication. Once the communication in one single device has been broken (note the number of receiver manufacturers and models), the entire system is seriously compromised. There are specially designed receivers that connect to the Internet to download these keys and apply them to the transport stream they receive. The popularity of ADSL lines means that this attack is very viable. The replacement of the cards does not solve the problem because to change the algorithms that protect the communication with the smartcard it would be necessary to update the receiver firmware, which is not viable as there is no one common model of machine (as is the case with standard Windows-PC architecture). Replacing the cards could only solve the vulnerable points of the card itself. The use of the K1 avoids the communication of control words and, therefore, eradicates the main weakness that affects all conditional access systems

SIDSA

22
KeyFly 2.0Xtreme FAQ

for smartcard-based broadcast systems. In the hypothetical case of a penetration in the K1, as there is only one single execution platform, the complete, continuous OTA updating of the conditional access is possible and makes life very difficult for hackers. In practice, this increases the service life of the system, avoiding the need for renewing the devices that have been deployed. How is the user identified for purchases? The system uses the card serial number as identification for purchasing by any payment channel; however, the card serial number can be associated with a mobile telephone number so that the SMS purchase message is shorter. In addition, the same mobile telephone number can be used as an identifier for purchases by other payment means. The association with the mobile telephone number enables the identification of the device that is to be reloaded. Which commercial models are supported? Subscription, PPV...? How are the products organised? KeyFly supports the following commercial models depending on the Business Support System or Subscriber Manager used. KeyFly supports PPV (also referred to as ordered PPV), i.e. the sending of a GSMSMS to request access to a content. The system sends to the user device an EMM, enabling the decryption of the content for him. This method provides exhaustive control over the real audience of the contents. In addition, PPV by electronic purse (iPPV) is also supported. This does not require the sending of EMMs for consuming the event, but it does require EMMs to be sent for reloading the purse on the client device.

The subscriber subscription model is also supported by KeyFly. With KeyFly, an offer can group together several products, which are assigned a price. The prices do not apply to the products, but rather to the offers, as an aggregation of products. Discounts or 2x1 are configured as offers of various products with a specific price. Can different commercial models be supported on the same channel? KeyFly is capable of offering the same event under subscription and by PPV. It can apply up to three commercial models to the same event. How much bandwidth is taken up by the EMMs? Can I send EMMs to user groups? KeyFly allows the sending of rights to client devices in groups or individually. The EMMs to one single user have a typical length of 376 bits, whereas the EMMs sent to a group have a length of 1193 bits. The use of one type of routing or another is fully configurable in the system. The criteria for using one or the other depends on the population to which the right is sent. A group EMM can be sent to 1024 users directly. In this group, each user can be distinguished individually. On a scenario with 2 million users, assuming a bit rate of 150 Kbps for EMMs by multiplex and 1 PPV service operating on the multiplex, assuming that all the rights are sent by group EMMs: Number of group EMMs =
Numbers UsersxNumber Rights 1024

2000000x1 = 1,954 1024

SIDSA

23
KeyFly 2.0Xtreme FAQ

Bit rate to be sent: 1,954x1,193=2,330,078 bits. Delay time in sending the EMM carousel = 18,640,625/150,000 = 16 seconds. What effect does the number of users and channels have on KeyFly? Is KeyFly scalable? The number of subscribers does not have a significant effect on the system due to the low storage requirements per system user. The number of channels does not have a significant effect on the size of the system. What actually determines the size of the system is the number of transactions per second that have to be processed. This is the most critical element of the system configuration. The number of requests per second also affects the GSM-SMS service provider for the size of his system.

of previous experience, SIDSA considers that there should be no integration problems regarding other manufacturers not included on the above list. KeyFly does not need to generate proprietary describers in the EIT tables. There are two methods for controlling open-to-closed transitions and vice versa: The multiplexers have multiplexer configuration scheduling applications, including whether the programme is encrypted or not and the access criteria that affects the service. These applications are the multiplexer manufacturers proprietary applications. The multiplexers implement the extensions laid down in Simulcrypt 1.3.1 for an external management system to command the access criteria and the open-toclosed transitions and vice versa. KeyFly does not control open-to-closed transitions at any time. This is carried out by the Event Information System (in the case of Simulcrypt) or the multiplexer configuration scheduling applications. KeyFly does not restrict the combination of PPV events with free broadcast events in the multiplexer. Can KeyFly manage several headends at the same time? The KeyFly platform is capable of simultaneously managing several headends. However, the only interface supported is the one laid down in Simulcrypt v1.3.1. Other interfaces would require specific development. Does KeyFly support distributed multiplexing? KeyFly supports distributed multiplexing models in such a way that a central

Integration in DVB-T headends

Which multiplexers can work with KeyFly? KeyFly has been approved by the following multiplexer manufacturers: Harmonic, Thomson-Nextream, Tandberg, Scopus, Streamtel, Adtec and, of course, SIDSA itself. It has integration certificates with Thomson and Tandberg. However, the capacities of the units made by the aforementioned manufacturers may vary significantly with regard to the number of conditional accesses per service, number of conditional accesses supported and the dynamic access criteria management or encryption (scheduling). With all the abovementioned manufacturers, the SI tables are generated in the multiplexer. As no proprietary signalling is used in the transport stream, KeyFly does not require specific table generators. On the basis

SIDSA

24
KeyFly 2.0Xtreme FAQ

infrastructure can establish communications with other headends that operate with provincial, regional or local cover, as well as a headend at state level. In the case of distributed headends, the proposal normally involves the installation of servers with ECMG, CS and EMMG functions on the remote headends. This is due to the following reasons. The EMM carousel for the local headend is generated on an EMMG that is adjacent to the local multiplexer. The central headend sends the individual EMMs to the local EMMG without generating the data carousel itself. This reduces connection requirements between the central and regional headends considerably and makes the system very robust. A loss of connection between the regional headend and a central headend would not momentarily affect users. The EMMs would continue to be sent normally, although, obviously, new requests could not be processed until the communication is restored. The EMMs from the national headend could be multiplexed with those generated locally. The ECMs are generated locally, but under the access conditions laid down by the central headend. In the event of connection loss with the local headend, the system could continue to encrypt and change the control words. To provide the local ECMG with a service, a cryptographic service based on smartcard is included (not high-performance co-processors). The local CS keys are updated from the central CS. The cryptographic operations for generating the EMMs are carried out on the central servers. Although, in principle, a completely centralised ECM and EMM management model can be used on the central headend, maintaining IP connections with the

local multiplexers, such a model would be highly sensitive to connection losses between both headends and there would be a considerable aggregation of IP traffic on the central server to support all the local EMM and ECM carousels. The proposed solution works well because the local headend servers do not have excessive performance requirements. The communication between the local and central headends is protected by a VPN or an SSH tunnel if the Internet is used. Is there any limitation to the future addition of new headends? KeyFly accepts the possibility of the progressive addition of new headends. The only requirement is the installation of a KeyFlyCORE adjacent to the headend multiplexer and IP connectivity between the said server and the conditional access management system. There are no restrictions to the number of headends that can be installed. Can I issue permission without sending an EMM? One method for drastically reducing EMM bandwidth and the reception of permission without the need for tuning the multiplexer is as follows: - When the user wants to buy an event, the STB or iDTV, following instructions given by KeyFly, presents a code the user must include in the GSM-SMS message, the Internet page or the telephone order for purchasing the event. - In the return SMS message, Internet confirmation page or when the telephone order is confirmed, the user is given a PIN number which, once entered in a menu on the receiver, activates the purchase of the requested event. The PIN number

SIDSA

25
KeyFly 2.0Xtreme FAQ

is cryptographically linked to the user device serial number and is different for each event and serial number. There is a limited number of times a PIN number can be entered, after which the method is blocked and has to be unblocked by an operator. With the above method, EMMs would not be strictly necessary to activate the rights and, consequently, event request peaks can be absorbed. However, user intervention is necessary. Of course, it would be possible to combine both methods (PIN and EMM) to cover different types of users. This method is included in KeyFly 2.0. Does KeyFly need a specific EPG? Is it necessary to enter proprietary information in the tables or generate proprietary tables? KeyFly does not have a system for sending EPG information and does not impose one. KeyFly does not need to generate proprietary tables or proprietary describers in the EIT tables. The only proprietary describers are located in the CAT. How is the transport stream encrypted? At transport level, the encryption is performed in DVB-CSA-v1. This task is performed by the multiplexer, with which KeyFly communicates using the Simulcrypt protocol (version 1.3.1) defined by the DVB. What bitrate overhead applies to the encryption process? Encryption overheads. Signalling. CAT: 7 bytes + (4 bytes * number of providers). PMT: Per encrypted service, 7 bytes. ECM bitrate. Depends on Simulcrypt parameters. Con-

sumption of 7 kbit/s per service, supposing a repetition period of 250 ms. What APIs are used to control KeyFly? The integration can be performed at KeyFly Manager level or at Subscriber Managerlevel. KeyFly Manager uses an HTTP interface as an API, on which XML documents are sent with a description of the transaction that is to be made. The Subscriber Manager uses a SOAP interface as an API, where the Subscriber Manager functions are offered as web services. The two APIs use technologies that are widely used in the computer industry and supported in the J2EE, .NET or other programming environments. However, both KeyFly Manager and Subscriber Managerare implemented in J2EE. How do users process registrations and removals in KeyFly? The registrations and removals can be carried out by a mobile text message (SMS), a telephone call to a call centre or via an Internet portal. The Graphite Customer Web Portal and Graphite SMS Gateway modules support the registration and removal function over the Internet and by SMS, respectively. For telephone calls, an operator accesses the Graphite Subscriber Manager via the Operator Portalto perform the operation required by the user. Can information be preloaded in virtual cards (CAM, Kx)? During the manufacture of client devices and the phase referred to as personalisation, any additional information that can be transmitted as an EMM can be included. This includes rights, electronic purse, expiry dates, etc. The only requirement is for the personalisation phase to be unique.

SIDSA

26
KeyFly 2.0Xtreme FAQ

Subsequently, any updating of this information would require the sending of an EMM. What format is used for billing? The results of the billing queries are delivered in XML, which can be transformed into another format using an XSLT transformation to another XML format that can be used by the entity using the payment collection data. Does the KeyFly management include user access profiles? The implementation of the access profile function differs in accordance with each KeyFly module. In the Graphite Subscriber Manager, the administrator can define the operations that define a profile. For example, the commercial profile can be defined to allow the definition of products, but not access to the queries or the screens that allow the processing of a purchase. The profiles can be fully customised. Of course, various users can then be defined with the profile. Other applications limit access to only the type of user that is going to access. For example, the Customer Web Portal only has the end client user type. Other information that may require access uses another interface or the Subscriber Manager. How can I supervise and manage KeyFly? The CAS platform has web interfaces or remote access available (IP-based proprietary interface). The SAS, CAS, ECMG and EMMG modules have a specific monitoring and management interface that can be used with a higher hierarchy management system. The protocol used is proprietary protocol. The KeyFly monitor tool enables the continuous monitoring and management of these modules.

The Graphite Subscriber Manager, and interfacing modules are controlled from the Tomcat application server manager itself. There are also applications that check the status of these applications and send an e-mail to report when the applications have crashed or generate an error message. The manager can indicate the required logging level. These logs are stored in a conventional text file.

Support for receivers

Which manufacturers and models support KeyFly?
KeyFly devices have proven compatibility with the majority of the STB and iDTV with Common Interface in the market. Interoperability with leading IRD manufacturers ensures high-performance high-availability professional applications. KeyFly devices support latest broadcast technologies, such as H.264/ AVC, Dolby digital and High Definition, opening new markets for broadcasters and content providers. Can KeyFly operate in receivers with MHP? Yes, as long as the receiver has a common interface bay. However, the new K2 chip will include MHEG-5 support, as indicated in the CI+ standard. Tested receivers include iDTV with MHP (Sony), iDTV without MHP (Panasonic, Sony, Samsung), CI STB without MHP and CI STB with MHP.

How is a receiver certified and how long does the process take?
Support is provided with the integration. It includes schematics, layout tips and automatic protocol test suites, which

SIDSA

27
KeyFly 2.0Xtreme FAQ

include a PC programme and transport streams. Once the automatic test has been passed, the receiver is subjected to certification tests in our offices. Integration times vary greatly depending on the resources used by the manufacturer. Full integration times vary between three weeks and two months.

the message is free, but the presentation format is limited by the receiver specifications (especially those with a common interface). This service can be used, for example, for messaging or chats, as well as for providing information about special offers, etc. There may be interoperability problems with the presentation of messages in some (only a few) receivers with a common interface, due exclusively to receiver limitations. This problem is common to all the CAMs, regardless of the manufacturer.

What does the receiver require to support KeyFly?

No special processing requirements are made of the receiver terminal since all the transport stream decryption task is performed in the K1, which has all the necessary memory and CPU.

KeyFly security
How is security implemented in KeyFly CAM?
The K1 has internal flash that provides a secure execution environment. It also has a keys repository with hardware support whose content cannot be directly accessed by the applications, and standard and hardware-implemented proprietary cryptographic co-processors. Each K1 has a unique identifier in a write-protected area that prevents the cloning of the device. This set of measures is not only capable of protecting the smartcard communication keys (as in the case of smart card based CAS), but also allows full KeyFly support. The CAMs can be updated by OTA, which allows the deployment of countermeasures. KeyFly has a traitor-tracing system that determines the origin of the device that may have been hacked. Once identified, the keys can be changed to exclude the devices that have been identified as compromised. This system can be repeated indefinitely. Parental control is set on a specific menu that sets the assigned age above which

Can the terminal software be updated?

Traditionally, the updating of terminal (STB) software on a horizontal market is almost impossible in view of the large number of models on the market and the fact that their architectural models are not compatible. The terminal software can only be updated on vertically integrated platforms where there are only a few models deployed. However, in KeyFly, all the client devices with K1 support the OTA updating of the internal firmware. This software is updated as EMMs sent to the cards. These EMMs are digitally signed and encripted. By reducing the number of architectures to be supported, software updating is perfectly viable in KeyFly. This is particularly important for the deployment of service improvements and countermeasures.

Can information banners or messages be sent to the user?

On all the KeyFly client devices, it is possible to present pop-up messages generated by client devices. These pop-up messages can be sent from the headend and controlled by the operator. The text of

SIDSA

28
KeyFly 2.0Xtreme FAQ

an event cannot be seen in the parental control. Parental control is transmitted in the ECMs. The parental control configuration is changed by a PIN number.

5. Constant renewal of cryptographic keys. This makes the cryptanalysis task even more difficult due to the short service life of the keys. 6. Embedded cryptographic software renewal (moving target). This works in conjunction with the previous measure. The idea is not only to resort to armour plating as measure of protection, but also to have the system continuously evolving in its execution environment. 7. Minimum number of possible intrusion channels. As there are no communication channels available for the user (smartcard), the possibility of implementing cheap illegal decryption solutions is reduced. In any case, as a secure platform, the K 1 can process external communication with the smartcard without the keys that protect the communication being easily revealed. All the security, from the processing of rights and purses to the decryption of the transport stream, is processed in one single hardware unit. 8. Tamper-resistant headend cryptographic devices. To prevent possible security breaches by disloyal headend operators, the headend cryptographic devices also have tamper-resistant measures.

How does KeyFly avoid piracy?

KeyFly security is based on a series of cryptographic techniques with hardware and software support. The hardware support (led by the K1) is a differentiating specification offered by SIDSA in its conditional access. The hardware provides a secure execution environment that is unbeatable in comparison with those offered by software solutions (which can always be emulated). KeyFly security is implemented using the following techniques: 1. Tamper-resistant execution means with protected RAM/flash. The K1 is the first device to decrypt the transport stream directly in a secure execution environment. The flash/RAM embedded in the chip ensures zero user intervention/modification and makes reverse engineering extremely difficult. 2. Hardware-embedded customised cryptographic processes. Besides standard algorithms, the K1 has its own batch of hardware-implemented proprietary cryptographic algorithms in which the processor does not have direct access to the keys. 3. Cryptographic implementation with maximum diversification by device. High-security keys. All the K1 chips are diversified to prevent cloning. The length of the keys has been increased to maintain the inviolability level of the algorithms. 4. Intrusion detection with identification (traitor-tracing). The diversification of the cryptographic devices can be seen in their execution profile. This makes it possible to identify which chips have been attacked and apply specific countermeasures.

Are there any countermeasures?

KeyFly includes the following countermeasures: 1. Key renewal. In the case of intrusion, the continuous renewal of keys can adopt a more selective system to eliminate the cards that were originally used to cryptanalyse the system. There are 6 key renewal profiles, depending on the compromise between EMM traffic and security. In the case of intru-

SIDSA

29
KeyFly 2.0Xtreme FAQ

sion, the continuous renewal of keys can adopt a more selective system to eliminate the cards that were originally used to cryptanalyse the system. 2. Substitution of hardware cryptographic algorithms. There are various proprietary hardware cryptographic algorithms that can be selected at any time (K1). 3. Downloading/upgrading of CAS software with frequent updates and specific countermeasures. The devices accept sw-downloading (as long as it is from appropriately certified sources) that enables the deployment of effective countermeasures. KeyFly is based on the idea that the conditional access system must be economically unviable for large-scale hacking. An extremely limited level of hacking could be viable for hackers with a very high level of technology who are committed to making high investments, but the popularisation of the pirate version of the system is not possible under any circumstances.

and advanced Business Support Systems.

What is KeyFlys roadmap?

The following are the most significant elements of SIDSAs conditional access roadmap. K2, new generation of ASIC for conditional access, supporting CI+, MHEG-5 interactivity, Ethernet. It will also include price improvements in comparison with K1. It is anticipated for Q3/4 of 2008. Devices based on K2: CAM, USB-CAM, interactive CAM. Q1/2009. Support for new business models in KeyFly, PIN-based to reduce EMM bandwidth. Q2/3 2008. Integration with different payment platforms

SIDSA

30
Glossary

CAS CRM CS DS DVB DVB-ASI DVB-H DVB-S DVB-T DVD ECM ECMG EMM EMMG IP KeyFly OTA SAS SMS

Conditional Access System Customer Rights Management Cryptoserver Downloading System Digital Video Broadcasting DVB Asynchronous Serial Interface DVB Handheld DVB Satellite DVB Terrestrial Digital Versatile Disk Entitlement Control Management ECM Generator Entitlement Message Management EMM Generator Internet Protocol SIDSA product. CAS system Over The Air. Mechanism to upload new firmware versions Subscriber Authorization System Subscriber Management System

SIDSA