GENERAL
What is KeyFly2.0Xtreme?
KeyFly2.0Xtreme (or just KeyFly) is a conditional access by SIDSA for content protection on DVB broadcast networks. It is based on K1 security chip, also by SIDSA, which can be found in CAM modules or embedded in Set-Top-Boxes. K1 allows the implementation of a conditional access within a single chip with no need for external smart card. This revolutionary approach will avoid the mayor drawbacks of smart card based licensed CAS.
Secure environment for CA software: anti reverse-engineering.
Robust anti card-sharing solution.
Innovative countermeasures and traitor-tracing techniques.
Cost saving: no need for smart card.
No certification process for manufacturers, which implies revealing CAS secrets to third parties.
But security is not the only strong point of KeyFly2.0Xtreme. An efficient management of rights provisioning helps operator in saving bandwidth and provide an excellent service by addressing a single user or the totality of subscriber base in a very short time.
Which broadcast networks are supported by KeyFly?
KeyFly is oriented to DVB broadcast networks: DVB-S, DVB-T and DVB-C (also DVB-S2, DVB-T2 and future DVB-C2).
Does KeyFly support smartcards?
KeyFly 2.0Xtreme is based on a single security chip, the K1, for the complete rights management, keys storage and management, and the decryption (aka. unscrambling) of protected contents. In this sense it is like having a virtual smart card inside K1 chip. This is the great difference between KeyFly 2.0Xtreme 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 external devices (such as smart cards) for transporting the control words.
Integration of cryptographic algorithms in hardware, some of which are proprietary, which prevents their reverse 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.
KeyFly has a real smartcard implementation, but it is not commercially deployed.
Which are the elements of KeyFly in head-end?
KeyFlyCORE is considered as the encryption part and supports the ECM and EMM encryption and generation, upgrading system, SAS and monitoring system. KeyFlyCORE is the interface with multiplexer.
KeyFly Manager implements management CAS operations, such as configuration of rights, assignment of rights to a service, key rotation and load balancing. Furthermore, KeyFly Manager is used to decide the most suitable policy of EMM generation in order to allow an efficient bandwidth usage. KeyFly Manager utilizes a database server for information storage; “data mining” operations are possible by accessing this database. KeyFly Manager is also the interface between KeyFly System and the Subscriber Management System (e.g. Graphite Subscriber Manager).
KeyFlyCORE and KeyFly Manager are joined into KeyFly System.
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.
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 extremely improbable: there is no CAS software that can be easily 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 deployed devices.
In the hypothetical case of a penetration in the K1, as there is only one single execution platform, the complete, frequent OTA updating of the conditional access is possible hence discouraging further attacks. 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 K1 serial number (found in CAM or embedded STB) as identification for purchasing by any payment channel; however, the serial number can be associated with a mobile telephone number in case of purchasing through GSM-SMS, so that the SMS 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 GSM-SMS to request access to a content. The system sends to the user device an EMM, enabling the decryption of the content. 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 supported by KeyFly. The Pay Per Time 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. For example, discounts or 2x1 are configured as offers of various products with a specific price.
How can KeyFly be integrated with existing or third party SMS/CRM/BSS/Billing system?
The integration with external CRM, SMS, billing system or business support system, is recommended to be done at KeyFly Manager level. 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. Alternatively, KeyFly Manager provides SOAP interface as an API, where the management functions are offered as Web Services.
The APIs use technologies that are widely used in the computer industry and supported in the J2EE, .NET or other programming environments. KeyFly Manager is implemented in J2EE.
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.
KeyFly is especially suitable for PPV events by means of an extremely efficient EMM management in order to save bandwidth while addressing a huge number of subscribers in a very short period of time.
As an example, 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, the totality of subscribers can receive rights in 16 seconds.
KEYFLY SECURITY
How does KeyFly provide security?
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).
The renewal of the security of KeyFly is done through OTA (Over-The-Air upgrade):
- Renewability of software: Upgrade of the conditional Access software and its software algorithms.
- Renewability of hardware: Selective usage and reconfiguration of the different internal cryptographic processors.
- Upgrades are transparent for the end user without service interruption.
- Upgrades are encrypted and signed, using the same proprietary cryptographic processors of K1.
- Upgrades are done simultaneously in all devices: saves bandwidth and facilitates the logistic of receiver deployment.
How does KeyFly avoid card sharing or control word sharing?
The latest techniques used in conditional access attacks are based on the publication of the control words that protect the encrypted content over the Internet. This technique is based on attacking the system's 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 for smartcard-based broadcast systems.
Are there any countermeasures?
KeyFly provides, between others, the following countermeasures: key renewal, substitution and reconfiguration of hardware cryptographic algorithms and downloading/upgrading of CAS software with frequent updates and specific countermeasures.
INTEGRATION IN HEADENS
Is simulcrypt supported?
KeyFly interfaces with multiplexer/scrambler in head-end through simulcrypt interface standard v1.3.1
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’s VegaMux. It has integration certificates with Thomson and Tandberg.
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 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 solution normally involves the installation of basic KeyFly servers (KeyFlyCORE) on the remote headends.
Does KeyFly need a specific EPG? Is it necessary to enter proprietary information in the tables or generate proprietary tables?
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.
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 Graphite Operator Portal to perform the operation required by the user.
Can information be preloaded in devices (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. 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.
How is KeyFly managed and supervised?
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 JBOSS 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.
Which manufacturers and models are compatible with 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.
Is KeyFly supported in CAM? Is CI+ supported?
Yes. SIDSA designs and manufacturers Alhena CAM with support of KeyFly2.0Xtreme.
CI+ provides copy protection mechanisms, encryption of the communication between the CAM and the iDTV/STB and MHEG5 interactivity.
SIDSA will support CI+ in the next generation of devices as long as there are deployed iDTV and STB with support of CI+ in the market.
Yes. Alhena Professional CAM allows the description of a complete transport stream within a single device. Other devices (K1 embedded STB and Alhena CAM for end users) support 2 services.
How can KeyFly be integrated into a receiver?
The implementation of KeyFly CAS system into a receiver is done by integrating K1 chip inside, and the implementation in the middleware of STB of a simple control protocol for communication between decoder chip and K1. Since all CAS software is inside K1, there is no need to develop and certificate conditional access in the middleware of the STB.
This approach will minimize the integration time to one or two months, including hardware and software developments.
Can KeyFly operate in receivers with MHP?
Yes, as long as the receiver has a common interface bay or has K1 chip embedded integrated with MHP middleware machine.
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 a receiver is 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 include a PC program 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.
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.
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 encrypted. 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 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.
