Security for DVB-RCS at Control and Management Planes

  • Status
    Completed
  • Status date
    2010-05-27
  • Activity Code
    1D.002
Objectives

The main objectives of the project are:

  • To define application (or reference) scenarios associated with various user groups (e.g. Military, Government, Consumer and Professional), to identify their security objective / requirements and to define the corresponding security architectures.
  • To perform an in-depth risk analysis of DVB-RCS-based satellite systems, covering the management, control and data planes, in order to identify the security threats to the satellite links and to derive security requirements for combating these threats, while accounting for satellite links vulnerabilities.
  • To provide a high level design of the security architectures and of the countermeasure techniques capable of satisfying the security requirements.
  • To identify specific requirements and make technical recommendations for normative provisions as well as for guidelines, for the extension of the DVB-RCS Next Generation (NG) standard to support the TRANSEC feature.
Challenges

The key issues associated with the implementation of transmission security are as follows:

  • Identification of all threats that might affect the security of the management and control information (and also of user data) transmitted over the satellite links, while accounting for the vulnerabilities specific to DVB-RCS systems,
  • Derivation of security requirements and identification / specification (at high level) of adequate countermeasure techniques to mitigate the threats,
  • Definition of security architectures, while considering a typical implementation of a DVB-RCS system (including a hub and terminals) as reference architecture,
  • Identification of the TRANSEC-related functionality that need to be supported by exiting functional blocks in Hub and terminals,
  • Identification of new functional blocks (e.g. TRANSEC Cryptographic Unit) and their interfaces (“hooks”) to the existing network components (e.g. FLSS, RLSS in the Hub, functional blocks in terminal).
Benefits

The main benefit from the project is the proposition of a solution for supporting transmission security in the DVB-RCS networks, which would increase the appeal of such networks to a broader market (e.g. including Military and Government applications).

While the solution may include implementation-specific elements, the project has endeavoured to define, as a minimum, an overall security architecture (figure below) identifying the interfaces (“hooks”) between the existing DVB-RCS elements (seen as COTS) and the new TRANSEC-specific functional blocks, primarily the TRANSEC Cryptographic Unit, responsible for link layer encryption / decryption – the main transmission security countermeasure. Other countermeasures can be implemented by enhancing the functionality of existing DVB-RCS elements. The defined security architecture / interfaces can be used as a basis for the evolution of the DVB-RCS NG standard to include the TRANSEC feature.

Figure 1. TRANSEC system architecture


click for larger image

Features

The most common security threats encountered in the DVB-RCS networks, the associated risks and the envisaged countermeasures are summarised in the Table 1 below.


click for larger image

The main countermeasure technique consists in link layer encryption of control and management messages and also of user traffic, provided by a new functional block – the TRANSEC Cryptographic Unit (TCU), which also has key management responsibilities. TCU is implemented in both hub and satellite terminal, where it interacts with other DVB-RCS network elements for message flows (plain text, encrypted) and also for local control. TCU “hook-up” points are identified in the relevant security architectures and generic interfaces are defined, capable of accommodating various encryption algorithms / operation modes.

The majority of other countermeasure techniques are specified (at high level) as enhancements to the existing DVB-RCS network elements / functional blocks.

Plan

The project work extends over a 6-month period and is divided in four separate tasks:

  • Task 1: Reference scenarios definition,
  • Task 2: Security risk analysis and requirements definition,
  • Task 3: Security architecture definition,
  • Task 4: Recommendation for standardisation.
Current status

The project has successfully finished all tasks. All technical notes, the final report and the executive summary have been submitted and accepted by the customer, and the final review / presentation took place successfully. Moreover, a TRANSEC proposal for DVB-RCS NG standard evolution has been submitted to DVB-RCS NG group, and a presentation has been made at RCS#61 meeting.

By finishing all tasks the project team has satisfied all project objectives.

  • Definition of reference scenarios / user groups and the identification of their security objectives and architectural components (Table 2).


    click for larger image

  • Risk analysis, customised to the security threats and vulnerabilities specific to the DVB-RCS satellite links.
  • Derivation of security requirements, resulting from risk analysis (“basic” requirements) and from system / network operation considerations, cryptographic & air interface considerations, and certification considerations (“other” requirements).
  • High level design of countermeasure techniques. The countermeasures, the threats they are combating and the associated risks are summarised in Table 1.
  • Definition of security architectures at different levels, allowing to position the TRANSEC-related functions in new / existing functional blocks, and to determine the corresponding interfaces. The detailed system security architecture is illustrated in Figure 1. It applies to all applications scenarios, though for the consumer / corporate the external networks may be simplified (i.e. there are no per-enclave partitions).

Subcontractors