Most network operators will scramble at least some of their services, in order to protect their pay-TV operations. This means, of course, that most receivers will contain some descrambling software for accessing these services. There are exceptions – some low-cost receivers will only receive free-to-air signals. MHP services will ususally be scrambled (or will include some scrambled channels), and so there will sometimes be a need to deal with the conditional access (CA) system that is used to descramble signals. The CA API is designed to provide the access that these applications need.
Many applications won’t need to know about this API – most won’t care about the CA system, and it’s really only EPGs and other related types of application that will use this API.
From the MHP perspective, the CA system consists of two main parts:
- The CA hardware modules that are used to descramble a stream. This includes the classes representig the modules themselves and the infrastructure needed to manage their resources and use them to actually descramble a signal.
- The man-machine interface that communicates with the user about CA-related issues. This includes on-screen dialogs and messages and the events associated with these.
We’ll look at each of these separately later in this tutorial, but first, let’s review how the CA system works.
The operation of the CA system
In a digital TV system, scrambling can work at either the level of the entire transport stream, or on the level of individual elementary streams. There’s no provision for scrambling a service in its own right, but the same affect is achieved by scrambling all of the elementary streams in a service. In the case of scrambled elementary streams, not all of the data is actually scrambled – the packet headers are left unscrambled so that the decoder can work out their contents and handle them correctly. In the case of transport stream scrambling, only the headers of the transport packets are left unencrypted – everything else is scrambled.
As well as encrypting the data that’s supposed to be encrypted, the CA system adds two types of data to the stream. These are known as CA messages, and consist of Entitlement Control Messages (ECM) and Entitlement management Messages (EMM). Together, these control the ability of individual users (or groups of users) to watch scrambled content. The scrambling (and descrambling) process relies on three pieces of information:
- The control word
- The service key
- The user key
The control word is encrypted using the service key, providing the first level of scrambling. This service key may be common to a group of users, and typically each encrypted service will have one service key. This encrypted control word is broadcast in an ECM approximately once every two seconds, and is what the decoder actually needs to descramble a service.
Next, we have to make sure that authorized users (i.e. those who have paid) can decrypt the control word, but that only authorized users can decrypt it. To do this, the service key is itself encrypted using the user key. Each user key is unique to a single user, and so the service key must be encrypted with the user key for each user that is authorized to view the content. Once we’ve encrypted the service key, it is broadcast as part of an EMM. Since there is a lot more information to be broadcast (the encrypted service key must be broadcast for each user), these are broadcast less frequently – each EMM is broadcast approximately every ten seconds.
Encapsulating code words and service keys in ECMs and EMMs.
One thing to note is that the encryption algorithms used may not be symmetrical. To make things easier to understand we’re assuming that the same key is used for encryption and decryption in the case of the service and user keys, but this may not be the case.
When the receiver gets a CA message, it’s passed to the CA system. In the case of an EMM, the receiver will check whether the EMM it intended for that receiver (usually by checking the CA serial number or smart card number), and if it is, it will use its copy of the user key to decrypt the service key.
The service key is then used to decrypt any ECMs that are received for that service and recover the control word. Once the receiver has the correct control word, it can use this to initialize the descrambling hardware and actually descramble the content.
While not all CA systems use the same algorithms (and it’s impossible to know, because technical details of the CA algorithms aren’t made public), they all work in basically the same way. There may be some differences, and the EMMs may or instance be used for other CA-related tasks besides decrypting service keys, such as controlling the pairing of a smart card and an STB so that the smart card will work correctly in that receiver.
In order to generate the EMMs correctly, the CA system needs to know some information about which subscribers are entitled to watch which shows. The Subscriber Management System, or SMS, is used to set which channels (or shows) an individual subscriber can watch. This is typically a large database of all the subscribers that is connected to the billing system and to the CA system, and is used to control the CA system and decide which entitlements should be generated for which users. The SMS and CA system are usually part of the same package from the CA vendor, and are tied together pretty closely.
The ECMs and EMMs are broadcast as part of the service (see the introduction to MPEG if you’re unclear on the concept of a service). The PIDs for the CA data are listed in the Conditional Access Table (CAT), and different PIDs can be used for ECMs and EMMs. This makes it easier for remultiplexing, where some of the CA data (the ECMs) may be kept, while other data (the EMMs) may be replaced.
A DVB receiver may contain several descrambling modules, each of which takes a transport stream as input. Each module is logically the same, as we have described above, but different modules may be capable of handling different CA systems. The DVB Common Interface (CI) allows a receiver to swap CA modules by defining a standard interface for the CA system. The DVB Common Interface uses a PCMCIA interface for the CA module – any module that complies with the DVB CI specification will work in any receiver equipped with a DVB Common Interface slot.
DVB Common Interface is not the only stand interface for scrambling systems the OpenCable POD interface is also in use, and in some cases is more popular that DVB-CI. Some companies (such as NDS) believe that POD is more secure against hacking, and so will only support this interface.
While MHP doesn’t insist that the DVB Common Interface is used as the interface to the descrambling module, using a standardised interface makes sense for receivers that target a horizontal market.
The interface to the descrambling hardware
To descramble a stream, we need to use some special hardware and a special software algorithm for decrypting that stream. Most CA systems today use a smart card to handle the decryption, and the software for communicating with this smart card and for handling CA messages is implemented as part of the middleware. Smart cards a a relatively cheap solution, which is important given the number of boxes that will be deployed.
In some cases, though, a system based around smart cards is not the answer – this approach ties the user to sa single CA system, which is a problem if they want to move their receiver to a region operated by a different broadcaster who uses a different CA system. To solve this, both DVB and CableLabs have defined a standard for pluggable CA modules – CableCARD in the case of CableLabs, and DVB Common Interface (DVB-CI) in the case of DVB. Both solutions use a module with the same format as a PCMCIA card that can be plugged in to the receiver and removed at any time. This allows the CA module to be sold separately from the receiver, and so it is much easier for a consumer to move their receiver to a network that uses a different CA system – all they have to do is get a CA module for the new network. The downside of this approach is that pluggable CA modules are significantly more expensive thana smart card, and so this is slowing deployment in the cases where pluggabel CA systems are not mandatory.
From the point of view of the CA API, both approaches are identical since either type of CA module can only decrypt one service at a time. Each physical module is represented by an instance of the CAModule class. This provides (mostly) read-only access to the module, and provides only those functions that don’t need any resources to complete. These are mostly concerned with telling the application whether a particular stream can be descrambled by the module, or whether a particular entitlement is available.
The isConnectable() method allows the application to find out if a given transport stream can be connected to a given CA module. Some CA systems such as the NDS VideoGuard system need special hardware (the TDA8004 chip in the case of the NDS CA system) to descramble the stream. In other cases, the hardware design may only allow some streams to be routed to some CA modules because they are connected to different front-ends.
The application can also find out which entitlements a module currently holds. The listEntitlements() method returns an array of strings containing descriptions of the entitlements. It’s not specified exactly what these strings should look like – this is left up to the CA system and the API implementation. The queryEntitlement() method takes an org.davic.net.Locator as a parameter and checks if an entitlement is avaialble for that service or event. The return value will be one of the following contants, depending on the availability of the entitlement:
ENTITLEMENT_AVAILABLEENTITLEMENT_NOT_AVAILABLEENTITLEMENT_UNKNOWNMMI_DIALOG_REQUIRED
If the application needs to descramble a stream, then the DescramblerProxy class provides access to the resources needed to do this. This is a resource proxy, and so many instances of this class can be created by the application – there is no one-to-one correspondence between DescramblerProxy objects and physical CA modules.
Once the application has created a DescramblerProxy, it can use it to descramble a stream. The startDescrambling() method will start descrambling a stream if the resources are available, or throw an error if they are not. There are several variants of this method, taking different sets of parameters. Basically, this method can take either an org.davic.mpeg.Service or an array of org.davic.mpeg.ElementaryStream objects, and may also take a parameter representing the CA module to use for the descrambling. In the versions of the method that don’t take this parameter, the method returns a CAModule object representing the module that is used for the actual descrambling. The startDescramblingDialog() method is similar, but it displays any MMI dialogs that are needed before descrambling can start. All of these methods will stop any existing descrambling before they start descrambling the new service.
Unlike many APIs which deal with scarce resources, the CA API does not require the application to reserve the resource first. Instead, the resources are reserved when the startDescrambling() method is called – if the resources aren’t available, then an exception is thrown.
No matter what variant of the startDescrambling() method is used, the CAModuleManager class is responsible for managing the descrambling resources and deciding whether a descrambling request can be met. It’s also responsible for dispatching events related to the CA system or the MMI interactions of the CA system. It also provides a way for an application to enumerate the available CA modules and find which module can descramble a given service.
There is also a set of events that are generated by the CA system to describe the descrambling process and the state of the hardware. The DescramblerProxy class allows the application to register one or more DescramblerListener objects, which will receive messages specific to the descrambling carried out by that proxy. Similarly, the CAModuleManager class allows the application to register one or more CAListener objects. These receive more general CA-related events relating to the availability (or othewise) of CA modules and to the interactions between the CA system and the user. These MMI events are very general, and do not describe specific interactions: other eents take care of these, and are described in more detail in the next section.
The man-machine interface
In some cases, the CA system may need to communicate with the user in order to descramble a stream. This may be to confirm the purchase of a pay-per-view event, or to enter a PIN or something similar. In any case, some interaction is needed, and this is usually dialog-based. While the CA API doesn’t define these dialogs in any detail, it does provide a way for the application to display the MMI for the CA system in the most appropriate way.
If an application class implements the MMIListener interface and is registered with the CAModuleManager as an MMI Listener, it will receive events from the CA system that describe the MMI interaction that should take place with the user. These events are all subclasses of the MMIEvent class, and they describe one of three
The StartMMIEvent tells the application that the CA system needs to communicate with the user. While the application controls the look and feel for this communication, the CA system tells the aplication what type of interaction is needed. Each StartMMIEvent contains an MMIObject that can be accessed by calling the getMMIObject() method. This MMIObject represents the type of dialog that the CA system wants to provide. This can fall into one of the followign classes:
- Menu
- Text
- Enquiry
- List
Each of these objects has a number of fields that the CA system uses to provide data to the application, such as the contents of a text field or whether the answer to an enquiry should be visible. The application can render these MMI dialogs with the appropriate look and feel, enabling CA system messages to be displayed in a way that best suits the application. Each object also has a set of methods for setting the values that the user has specified, which are used for communicating these values back to the CA system.
To see this, let’s take a look at the Enquiry class. This represents a dialog where the user is expected to enter some information in response to a question:
public class Enquiry extends org.davic.net.ca.Text {
public String getText();
public short getAnswerLength();
public boolean getBlindAnswer();
public void setAnswer(String answer);
public void close();
}
The getText() method allows the application to get the text that should be displayed for the enquiry. The getAnswerLength() method lets the application get the expected length of the answer – e.g. for a PIN or other identification. This enables the applicaiton to limit the length of the answer, to stop the user entering too many digits, for instance. Once the user has entered their response, the application should call the setAnswer() method to tell the CA system what value has been entered.
When the user has completed the dialog, the application should call the close() method. This is a method common to all MMIObject subclasses, and it tells the CA system that the application has set all the data that the user has filled in and that this part of the dialog is complete. At this point, one of two things can happen. Either the CA system has all the information it needs, in which case it sends a CloseMMIEvent that tells the application the interaction is over, or it sends another StartMMIEvent indicating the start of the next dialog that it wants the application to present.