MHP Security

It’s probably no understatement to say that digital TV broadcasters, conditional access providers, and receiver manufacturers are paranoid about security. There are two major parts to this:

• Making sure that unauthorized people don’t get access to content that they haven’t paid for.
• Making sure that no-one can tamper with the content before it is broadcast.

In web terms, this is like making sure that only registered users can access the paid-for sections of your web site, while at the same time keeping your site secure so that it can’t be cracked or defaced.

The first of these issues is a fairly well-known problem that the TV industry (analog as well as digital) has been aware of for many years. Encryption and scrambling techniques are used in almost all digital TV systems, and this will not significantly change with MHP. The main place where MHP-specific security applies is when dealing with interactive applications in an MHP receiver.

As we’ve already seen from looking at the various MHP APIs, security is a major consideration that is behind many design decisions. In consumer applications it is important for the platform to be as reliable as possible, and this is doubly true when third parties can execute code on that platform. While people will tolerate problems with a PC, they are much less likely to tolerate problems with a consumer device. This is why an MHP receiver has several different security mechanisms built-in.

The first of these security mechanisms is application authentication. A broadcaster can digitally sign an application so that the receiver can be sure the application has not been tampered with. This signing process has three components:

Hash files

A broadcaster can use a hash file to provide a checksum for files or directories, thus ensuring that the contents have not been corrupted. This hash file has the name dvb.hashfile, and each directory containing files with associated hash values will contain one hash file. These hashes may be computed using either the MD5 or SHA-1 algorithms.

Signature files

The actual signing process takes the master hash file for the subdirectory containing the application as input. This hash file is the hash for all files in that directory and subdirectories (calculated using other hash files for those directories). To sign an application, the broadcaster calculates the hash value for this hash file, then encrypts the resulting hash using a public-key algorithm. The broadcaster uses their private key to encrypt this data and includes the corresponding public key in the broadcast filesystem (see below).

In order to sign a directory tree, the broadcaster places this signature in a file called dvb.signature.<id_number> where <id_number> is a decimal integer with no leading zeroes. This ID number allows a directory tree to be signed by several different authorities.

Of course, signing an application is no use if the receiver doesn’t know which applications should be signed – otherwise, we could simply remove any signature information. The receiver can tell which applications are signed and which are not simply be looking at the Application ID that is signalled in the AIT. The address space for an application ID is split into two ranges. Any application ID in the range 0x000 to 0x3FFF is considered to be an unsigned application. Applications with an application ID in the range 0x4000 to 0x7FFF is considered to be signed with a digital signature. Any application with an ID in the signed ID range must have a valid signature or it will nto be authorised..

Certificate files

As we’ve already seen, the broadcaster must include their public key in the filesystem so that the digital signature can be decrypted. This is contained in the certificate file, which has the name dvb.certificate.<id_number>. Any directory containing a signature file must also contain certificate file with the same ID number so that particular signature can be authenticated. Each certificate must itself be certified, in a hierarchy leading back to a root certification authority.

The format of the hash, signature and certificate files is covered in detail in section 12.4 of the MHP specification. We won’t examine this in any detail here, because it’s pretty straightforward to understand.

The signing process takes place as follows. Consider the following directory tree:

The security-related files in an MHP filesystem.

In this case, we wish to sign all the files highlighted in red (i.e just the class files). Files shown with dashed lines are not present in the filesystem at first – these are added by the signing process.

To sign this directory tree, this is what happens:

1. Certificates from each of the authorities that will sign the directory tree are added to the root directory. Since in this case we are the only authority who will sign these files, we only have one certificate. This is stored in the file dvb.certificate.1.
2. The lowest-level directories are checksummed first. In this case, this means the subdir directory. Only the two class files are included in the resulting hash, since we are not authenticating the JPEG file. This results in a new file, dvb.hashfile, being added to the subdir directory.
3. Next, the parent directory is checksummed. This is done by taking the hash value of the files in that directory and the dvb.hashfile file only from any subdirectories. This then generates a dvb.hashfile file for the parent directory.
4. In our case, the top of the directory tree has now been reached and so now we can sign the hashfile. The contents of this file (i.e. the actual hash value) are taken and encrypted using the RSA algorithm with the public key given in the file dvb.certificate.1 in the root directory. This encrypted hash value is then stored in the file dvb.signature.1
5. Processing is complete and the files can be broadcast.

We are skipping over some of the details of the various files that we add – the format if these files is not quite this simple. As stated above, the MHP specification gives the full format of these files.

Broadcasters should be careful when signing applications to make sure that they do so in an efficient way. The format of the hash file format allows us to group several files or directories together and use one digest value for all of the objects in the group, which may seem efficient in theory but which has a big problem in practise.

While generating the digest values is a quick process at the head-end, checking them at the receiver is normally much harder because of the CPU power fo the receiver and because of the time needed to load the hash files from the object carousel. If we have grouped several objects together and used a single digest value, the receiver has to load all of the objects in the group in order to check the hash value for any object in that group. Since DSM-CC filesystems can have a very high latency, this can take a long time and cause big delays in loading the application. In most cases, using a separate digest value for each object is no more difficult, and it can greatly improve performance.

The application security model

From the application point of view, the security model is basically that of PersonalJava, with a few restrictions. Many of the APIs introduced by MHP define a number of security related exceptions, which may get thrown when an application does not have sufficient rights to perform certain operations. For instance, applications do not by default have permission to use the application listing and launching API to control other applications – they only have the rights to get information about those applications.

Unsigned applications have only the basic set of rights. Signed applications also only have this basic set by default, but broadcasters and application developers may include a permission request file which the system can use to grant more rights. This permission request file is an XML document with the format given in part 12.6.2 of the MHP specification. This file is stored in the same directory as the main file for the application (either the initial class file for a DVB-J application or the first HTML file for a DVB-HTML application), and has the name dvb.<initial_file_name>.perm, where <initial_file_name> is the name of the main file of the application.

An example permission request file is shown below, taken from the MHP specification.

<?xml version="1.0"?>
<!DOCTYPE permissionrequestfile
  PUBLIC "-//DVB//DTD Permission Request File 1.0//EN"
  "http://www.dvb.org/mhp/dtd/permissionrequestfile-1-0.dtd">
  
<permissionrequestfile 
  orgid="0x000023d2" 
  appid="0x0020">

  <file value="true"></file>

  <capermission>
    <casystemid
      id="0x1111" messagepassing="true"
      entitlementquery="true" mmi="false">
    </casystemid>
  </capermission>	
  
  <applifecyclecontrol 
    value="true">
  </applifecyclecontrol>
  
  <returnchannel>
    <defaultisp></defaultisp>
    <phonenumber>+3583111111</phonenumber>
    <phonenumber>+3583111112</phonenumber>
    <phonenumber></phonenumber>
  </returnchannel>

  <tuning value="false"></tuning>
  <servicesel value="true"></servicesel>
  <userpreferences 
    read="true" 
    write="false">
  </userpreferences>
  
  <network>
    <host action="connect">hostname</host>
  </network>
  
  <persistentfilecredential>
    <grantoridentifier id="0x0202030">
    </grantoridentifier>
    <expirationdate date="24/12/2032">
    </expirationdate>
    <filename read="true" write="false">
      5/15/dir1/scores
	</filename>
    <filename read="true" write="false">
      5/15/dir1/names
    </filename>
    <signature>
      023203293292932932921493143929423943294239432
    </signature>
    <certchainfileid>3</certchainfileid>
  </persistentfilecredential>
  
</permissionrequestfile>

The fact that an application requests these permissions is no guarantee that it will get them, however – the user must explicitly grant an application these permissions. Exactly how this is done will vary from receiver to receiver – some may set these values as part fo the user preferences, some may ask the user every time, some may take yet another approach. In every case, however, the application should always be aware that it may only get some of the permissions that it requested.