attacker to join the network or to perform traffic analysis on remotes that have already acquired the TRANSEC network.
DVB-S2 Downstream TRANSEC
This section describes the TRANSEC feature as it relates to DVB-S2 carriers. TRANSEC on the TDMA upstream is described in Upstream TRANSEC on page 113.
With a deterministic TDMA upstream carrier such as iDirect’s, a Burst Timeplan (BTP) is transmitted from the hub on the downstream carrier at a predetermined time interval. (This predetermined interval, called a frame, is typically 125 ms in an iDirect Network.) The BTP assigns each upstream time slot on each channel to the active remotes. This information must be protected since it describes the return channel bandwidth usage for each remote.
A remote must use the upstream channel before it has the received the DCC Key in order to authenticate itself. To accommodate this, the BTP is broken into two parts: the
acquisition/authentication slots are defined in the first part, and the traffic slots for authenticated remotes are defined in the second part. The first part is encrypted with the ACC Key, and the second part is encrypted with the DCC Key.
In addition to the BTP, the authentication process itself (described later) requires use of both the downstream and the upstream channels. The authentication traffic is encrypted with the ACC Key. Once the remote is authenticated, all traffic is encrypted with the DCC Key.
In both the upstream and downstream directions, the proportion of ACC and DCC traffic is hidden by encrypting the headers with the ACC Key. The exact format differs for the downstream carrier and the upstream carrier.
Except as noted below, all downstream information is encrypted by either the ACC Key or the DCC Key. Some of the ACC-encrypted traffic, such as the DVB-S2 NCR timestamps, is
generated by the line card firmware. Other ACC-encrypted traffic, such as authentication traffic and acquisition invitations, is generated by software running on the hub servers. ACC traffic generated by server software is specifically tagged as ACC traffic, so that the line card firmware can store it in the appropriate queue.
The DVB-S2 downstream consists of a series of BBFRAMEs. Each BBFRAME is defined at the physical layer. For TRANSEC operation, the outbound operates at a fixed MODCOD, meaning that the modulation and FEC encoding for each DVB-S2 frame is the same.
A DVB-S2 frame can contain both ACC and DCC data. The proportion of each type of data is hidden from an attacker using the AES encryption. The definition of the DVB-S2 frame structure and the type of key applied to the various fields within each frame are shown in
Figure 18-1. (The exact positions and lengths of the fields may be rearranged for NOTE: All downstream multicast traffic is also encrypted with the DCC Key.
NOTE: Since DVB-S2 TRANSEC requires a fixed MODCOD, configure all TRANSEC DVB-S2 carriers to simulate CCM by setting the Maximum and Minimum MODCODs to the same value.
DVB-S2 Downstream TRANSEC
implementation purposes; however, that does not change which fields are encrypted by a given key.)
Figure 18-1. DVB-S2 TRANSEC Frame Structure
The first 21 bytes of the DVB-S2 frame are sent in the clear. These initial 21 bytes consist of: • A four-byte fixed header, which never changes
• A 16-byte Initialization Vector (IV) used by the encryption / decryption algorithm
• A single byte containing the key ring position for the ACC Key. This allows for key rolls of the ACC Key as described in ACC Key Management on page 120.
The next 16 bytes are always encrypted with the ACC Key. They contain the following information:
• The length of the ACC-encrypted data • The length of the DCC-encrypted data
• The key ring position of the DCC Key, required to allow key rolls.
Because these 16 bytes are encrypted, the proportion of the ACC to DCC data is hidden from an attacker. Compromise of the ACC Key can only jeopardize the acquisition information (i.e. who is acquiring). Once acquired, all traffic patterns are protected by the DCC Key. Because the DCC Key is protected by the RSA public/private keys, possession of the ACC Key does not allow an attacker to determine the DCC Key.
The total length of encrypted data is always the same. If there is unused space in a BBFRAME, it is filled with random data and then encrypted. In some cases, the entire BBFRAME may consist of encrypted random data.
The steps in the decryption process are:
1. The packet is recovered at the physical layer, including CRC checking.
2. The four-byte fixed header is checked. If it is not correct, the packet is discarded. 3. The 16 byte IV is loaded into the AES core.
4. The key ring position is used to select the correct ACC Key.
5. The first 16 bytes are decrypted and ACC and DCC lengths are extracted.
6. The AES core decrypts the ACC data (using CBC); the key is switched to the DCC Key; and
the DCC data is decrypted. (The DCC Key ring position is used to select the appropriate key). The last 16 bytes of the ACC data serve as the IV of the DCC encrypted data.