Security

Introduction

Security means different things to different people. To the programme distributor, security concerns the risk of pirating of valuable programme inventory; to the multiplex operator, security is the risk of a rogue application crashing the customer's boxes; to the customer, security is the risk of his or her credit card details being stolen during a transaction; to the merchant and bank, it is the risk of repudiation of a purchase. Security is multifaceted and complex; it is part technical and part legal, and requires commercial judgements to direct the technical aspects.

Security related to downloadable applications

For the downloadable applications, security covers the authentication of applications/data, their integrity and consequent certification. It is necessary to differentiate between the technical aspects and the policy aspects of the security model. In particular, the policy aspects have to address the way to handle authenticated applications vs non-authenticated applications.

  • Access to data in the box : some applications might be authorized to access some data while others are not authorized to do so. As an example, there is a possibility for an application to manage some memory space : save data and read data. Access to specific-application data is obviously subject to security policy : it is legitimate to think that only some applications will be authorized to access data owned by another application.
  • The broadcaster is responsible for the content he provides to the user. This means that when the user is currently watching a given service, It is legitimate that the broadcaster wishes to control what the user can access, without the service being disturbed by content being delivered by another content provider. Further, not being able to control such scenarios might possibly lead to legal issues in the future. The latter case more precisely refers to a secure signalling of application relationships (co-operative applications).

Another method for enforcing security is to use legal means, such as copyright laws, contracts between the participants in the broadcast chain, agreement between the broadcaster and the regulator, etc.

Authentication

Authentication is provided by digitally signing the content. The signature verifies that the content has not been modified after signing it. The signature can be verified by the MHP terminal by using the certificates. The certificates contain a public key that is used for verifying the signature and information about who the signing party is. In order to ensure that the certificate has not been modified, it is again signed by a higher layer Certifying Authority. The topmost certificate in the hierarchy belongs to a so-called Root Certifying Authority. There can be any number of Root Certifying Authorities; however, the certificates of the Root Certifying Authorities need to be stored in the MHP terminal, to allow for verifying that they are valid.

Now the question is what does the signing actually provide? Essentially it provides only a guarantee that the content has not been modified after signing and the certificates provide information about who signed it. It should be noted that the same content as well as the certificates may be signed by multiple parties - i.e. this is not limited to only a single signature.

What can the receiver then do with this information? Essentially this all depends on the policy of how the Root Certifying Authority issues the certificates to the different parties. There can be various policies associated with issuing the certificates. Examples of possible policies are:

  • the Root Certifying Authority only verifies that the information in the certificates about the party signing the content is accurate. This type of Root Certifying Authority does not take any measures of checking the content in any way, it only provides reliable information about who is the source of the content. Additionally, this is all subject to the trust the receiver has for the Root Certifying Authority. If the receiver can't trust the Root Certifying Authority to issue the certificates in the claimed manner, the receiver can not trust this information to be valid. Also, for this type of Root Certifying Authorities, the matter of if the receiver can trust the content source, even if reliably identified, is a totally separate decision.
  • the Root Certifying Authority verifies also the actual content somehow and issues the certificates only to content providers whose content fulfills some criteria. Different criteria can be e.g. that the content does not violate the end user's privacy and can be allowed to access some private information, or that the content does not make any expensive phone calls and can be allowed to use the return channel modem, etc. Again, this all is subject to the receiver trusting the Root Certifying Authority.

The receiver can use the authentication information for determining what kind of privileges are given to the application. The Java environment allows for very fine grained control of this. Possible choices are:

  • the application is not allowed to run at all. This is typically used for content that is signed by parties that the receiver considers hostile.
  • the application is run, but can only access a minimum set of resources and these can not harm the user in any way. This is typically used for content that is not signed at all, or is signed by a party who the receiver does not know whether to trust or not.
  • the application is run and has access to more resources, e.g. access to user's private information, the return channel, etc. There are many possibilities to define the exact access to individual resources based on the trust the receiver has for the signing party.

It should be noted that the authentication is useful only for protecting the receiver and/or the end user from possibly hostile applications; it does not provide technically viable mechanisms for any protection of the content in a unidirectional broadcast environment (this is provided by encryption which is completely separate from authentication).

Now, it is clear that the authentication information can be used for determining what to do with the content. The question that needs to be answered is: who is in control of the receiver and decides which Certifying Authorities the receiver trusts, etc. It is clear that this party that controls this aspect of the receiver is the ultimate gatekeeper that decides which content runs on the receiver and which doesn't. In the vertical markets this typically has been the operator. It should be noted that technically it is fully possible that the end user has this control and makes these decisions. Naturally, this can vary between different receivers and possibly depend on the end user's relation with the receiver (i.e. does the end user own the receiver or not, did he pay the full price for it or not, etc.). However, it should be decided which of these possible models the MHP specification should support.

Another question is: is there a limited number of Root Certifying Authorities or should anyone be allowed to become a Certifying Authority? What are the premises for a security model to be put in place ? There has to be a root certifying Authority. The certifying Authority has to provide the manufacturers with root-certificates. It is worth noting that there is no secret to be embedded in the MHP : The certificates provided to the manufacterer are public and contain public keys. Note also that the Model has to account for revokation of root/non-root certificates.

Security on the return channel

There is a need to address the security on the return channel. Before to address the technical issues, some scenarios are needed. The main applications involving the return channel are, amongst others e-commerce or telebanking. It is worth noting that the security that we have to address here relates to the security of the content.

The e-commerce field is a tremendously growing activity that involves many technical and legal aspects. It is all the more complex because :

  • A transaction involves three distinct parties : the end-user, the merchant and the financial institution.
  • It is subject to a lot of legal aspects
  • There is a lot of existing protocols and technologies, which are different depending on various factors : Country, Bank consortia ...

Debit Card Payment techniques

The user simply communicates its card number and expiration date to the server in the clear. This mechanism is obviously the simplest one. However, it has the following drawbacks :

  • The merchant can debit the user with more than was due by the user
  • The information concerning the card can be eavesdropped.
  • The merchant has no warranty as to the solvency of the user.
  • The credit card does not allow for 'micro-payment'
  • The buyer can revoke the purchase within a certain limit in time.

Electronic Purse

To solve the problem of micro-payments, some companies have created systems enabling the user to store money in an Electronic Purse. In a E-Purse transaction, only the merchant server and the end-user are involved. No authentication server is involved here.

There a several technologies of electronic purse, amongst which CEPS (Common Electronic Purse Specifications), EEP (European Electronic Purse) and a lot more.

To reduce fraud risks, the following requirements should be fulfilled.

  • Authentication of the buyer
  • Authentication of the merchant
  • Integrity of data sent over the network
  • Security of the data sent across the network

Practically, there are two ways to make the transaction secure :

  • Encryption of the banking data sent over the network - software security. (the most classical tool - and de facto standard - used across the internet is SSL : Secure Socket Layer).
  • Use of the smartcard. Harware security. Usually the smartcard takes care itself to authenticate the user (through the PinCode) and the overall security of the on-line transaction mechanisms is subject to an strict agreement by Bank consortia.

SET

SET™ (Secure Electronic Transaction) is an international standard whose aim is to provide the adequate level of security that is expected for secure transactions. It allows for use of sofware security, and also allows to integrate chip-card technologies. (SETv2)

Chip-card standards

There are a lot of chip-card technologies specified by different Bank Consortia in the various countries. Examples of these are BO' in France, WG10 or TIBC in Spain. These technologies specify application protocols on top of ISO 7816 for debit transactions, or Electronic Purse Transactions. Data to be sent to the merchant server depend on the chip-card technology.

It is worth noting that all the existing technologies do not account for micropayments yet.

EMV (Europay, MasterCard and Visa) is a new standard, whose aim is to merge the various chip-card standards, and which will be deployed around 2002.

Conclusions

The aim of this paper is to give a very brief overview of some of the existing technologies, that are sometimes orthogonal to each other. The requirements for secure electronic transactions can be found in the SET specifications. The acceptance of the SET standard is not know yet, nor is known the impact of this technology on STB implementations. SET is not incompatible with the future chip-card international standard EMV. It is not clear however how these technologies will be merged. SSL is a widely-accepted tool enabling to have a 'secure pipe' between a client and a Server. This is at the moment the tool that is the most often used tool for transaction services on Internet.

The resolution of technical / regulatory aspects of e-commerce is being driven by large interests focussing on trading from pcs. API developers cannot influence these developing standards to any great degree. The aim should be to provide a flexible and layered specification that will enable to smoothly integrate the e-commerce technologies when they are clearly specified and defined. Further, should any standard be defined that encompasses all the aspects of secure transactions, it should allow to account for the Set-Top-Box capabilities and limitations.

This document is an edited version of a paper prepared by the DVB Multimedia Home Platform Technical Group.