6th International Conference on Internet Technology and Secured Transactions, 11-14 December 2011, Abu Dhabi, United

Arab Emirates

Multicast Security Protocol over Satellite DVB Based

on Chaotic Sequences
Kassem Ahmad, Bassem Bakhache,

Safwan El Assad, Daniel Caragata, Maryline Chetto

IREENA: Institut de Recherche en lectronique et

lectrotechnique de Nantes Atlantiques
Ecole polytechnique de luniversit de Nantes,
B.P 50609 Nantes Cedex 3, France
Kassem.ahmad@univ-nantes.fr

LASTRE: Laboratoire des Systmes lectroniques,

Tlcommunications et Rseaux
EDST, Lebanese University, Tripoli, Lebanon
bbakhache@ul.edu.lb,
Safwan.elassad@univ-nantes.fr

Providing security and scalability is the most challenging

problems in satellite multicast systems. A security protocol
must take these problems into account, in particular the need
for confidentiality and efficient usage of the satellite resources.

AbstractThe major problems of

multicast satellite
communications are the security and the scalability. The
multicast protocols in digital video broadcasting via satellite
(DVB-S) cause a massive load on the system resources, and create
performance deterioration. In this paper, we propose a new
encapsulation method derived from the unidirectional
lightweight encapsulation (ULE) standard method, called
enhanced ULE (EULE). The latter relies on the spot beam
technology and the label-switching approach in order to ensure
an efficient filtering and multicast forwarding. Additionally, we
propose a new multicast security protocol in DVB-S which uses
the EULE and provides all security services. The idea of our
proposed protocol consists of using a 2-tiered architecture of
independent logical key hierarchy (LKH), a satellite-layer and a
terrestrial-layer. All the keys of both layers are obtained by
chaotic generators. The chaos is also used to encrypt the keys and
the transmitted multicast data in our system. The analysis of the
proposed protocol shows that it can handle a very large multicast
system securely and effectively. Simulated results reveal a low
cost for data overhead and more than twofold reduction in
bandwidth consumption for the key management data versus the
best competitive method.

The particular issue that limits scalability is the key

management which is complicated and expensive (bandwidth
and processing power) [3] due to the rekeying process. When
the number of members of multicast group is large and when
these members are very dynamic (high join/leave frequency)
the cost becomes very high and it limits the network resources.
In fact when a new member joins a group or when an existing
member departs from a group, the group key has to be updated
and redistributed with a large number of keys to all authorized
members (to maintain security). Thus, it is particularly
important to minimize the key management traffic costs. A
number of key management schemes have been proposed [4]
including a Flat system, LKH, Iolus and Kronos It has been
proven that Logical Key Hierarchy (LKH) is the most suitable
key management system that can handle large and dynamic
groups successfully [5].
On other hand, the study and the contribution of chaos have
attracted many interests by researchers in various scientific
fields, including the telecommunications field. In fact, its
important characteristics such as the good cryptographic
properties, the very high sensitivity to initial conditions and the
non linear dynamics behavior of chaotic maps, encourage their
use in crypto-systems or in new communication protocols for
data security. So, we will try to use chaos to enhance the
security of multicast transmissions over DVB.

Keywords- Security; DVB-S; multicast; Logical Key Hierarchy

(LKH); Group key Management; Chaos.

I.

INTRODUCTION

During the past years, the demand to use satellites for

Internet access is vastly growing because satellite
communication can deliver Internet services to consumers and
institutions in remote areas with limited or no terrestrial
connectivity. Multicast communications over satellite networks
provide effective means of broadcasting information to
geographically dispersed groups of users [1]. The multicast
packets are expected to be forwarded by the satellite only to the
spot beams that contain at least one member.

To
ensure
efficient
multicast
forwarding
via
Geosynchronous Earth Orbit (GEO) satellite, we firstly
propose in this paper an Enhanced Unidirectional Lightweight
Encapsulation (EULE) derived from ULE method. It relies on
label-switching approach [6] for the switching of MPEG-2
segments based on a switching table. Secondly, for solving the
frequently rekeying problem, we also propose the usage of two
independent LKH key distribution layered architecture [7]: a
satellite-layer and a terrestrial layer. In both levels, and for
more security, the keys are generated by chaotic sequences and
are transmitted in particular packets defined for this purpose.
Data and keys encryption is also provided by chaotic
algorithms.

IP multicast over Digital Video Broadcasting-Satellite

(DVB-S) [2] uses the MPEG-2 transport stream (TS) for the
transport of multicast data frames on the satellite link with a
fixed length of 188 bytes. In this context, the issue of IP
multicast packets encapsulation and efficient segmentation
arises in order to allow the on-board satellite processor (OBP)
to switch received MPEG-2 segments to the appropriate spot
beams.

978-1-908320-00-1/11/$26.00 2011 IEEE

97

Protocol Encapsulation (MPE) [8]. If additional services are to

be provided, such as security, ULE allows a flexible
mechanism by adding a little information on its original header
called the extension header.

This paper is organized as follows. In Section II we present

the Internet multicast transmission over GEO satellite and its
security requirements. In Section III we propose a new
multicast security protocol based on two key management
LKH layers. The analysis of the proposed key management
system is detailed in Section IV. In Section V we evaluate the
performance of our proposed protocol in terms of bandwidth
consumption. In section VI we present our conclusion.
II.

Fig. 2 shows this ULE data frame with an extension,

called Sub-Network Data Unit (SNDU). It is made up of four
fields: a header, an extension header, a Network level Protocol
Data Unit (PDU), and a trailer.

IP MULTICAST OVER GEO SATELLITE

A. System Architecture
As shown in Fig. 1, two main entities provide the transfer
of data and the connection with the GEO satellite DVB-S: the
Network Control Center (NCC) and the Return Channel via
Satellite Terminal (RCST). The NCC is the core of the satellite
network. It controls all the RCSTs in the network. The RCST is
the terrestrial terminal that provides a bidirectional link with
GEO satellite with a return channel via satellite (DVB-RCS).

Figure 2. SNDU with extension header

The header consists of four fields which are:

The D field, composed of one bit (0 or 1) indicating the
presence of the optional field NPA@ (Network Point
of Attachment address), or no.

The Internet Service Provider, ISP, has access to the

internet and sends IP packets to his clients (RCSTs) using the
satellite link. The IP packets need to be encapsulated and are
carried by a MPEG-2 stream. The satellite forwards the
MPEG-2 data by supporting two technologies: the spot beams
and the on-board switching (OBS).

The length field L1, composed of 15 bits, indicating

the length of the SNDU frame in bytes.

The Type field T1, composed of 16 bits, indicating the

type of PDU being carried by the original SNDU or the
type of extension header if exists (assigned by IANA).

The optional field NPA@ (6 bytes), carries the SNDU

destination address (usually MAC address).

GEO satellite

Spot beam 1

IP
IP Packet

ISP/
Internet

RCST
Sender

NCC

RCST

The field H1 is the extension header and its structure is

determined by the type T1. There are predefined extension
headers [9] and unassigned values of extension header types
that can be used for new extension headers. The field T2
indicates the type of PDU that is being carried, similar to the
field T1 of the ULE without the extension header.

Spot beam 2

RCST

RCST
Receiver

RCST

C. Security requirements
The multicast transmission over satellite DVB is vulnerable
to various attacks listed in [10]. The security services that have
been derived to counteract these attacks are:

Member

Figure 1. DVB-S system architecture and multicast transmission

Instead of covering the entire footprint of a satellite by a

wide global beam, the spot beams technology consists of
dividing the beam into a number of spot beams. This provides
two important benefits: 1) reducing the power requirements of
RCSTs, thus allowing the use of smaller antennas and 2)
reusing the frequency in different beams, thus increasing the
capacity of the space segment. Additionally, the number of
persons who can receive information not intended to them, is
dramatically reduced, thereby increasing the security mainly
against the passive threat.
On the other hand, the OBS provides a method for
switching and routing data on board the satellite. The on-board
processor (OBP) switches the received MPEG-2 segments to
the appropriate destination ports (spot beams).
B. ULE encapsulation and extension header
The encapsulation of IP packets is achieved through the
ULE protocol. This latter is the predominant method of
encapsulation in DVB-S/DVB-RCS and presents many
advantages over the other competing protocols such as Multi

Data confidentiality: is the most important security

service against passive threats because any
unauthorized receiver can access the transmitted PDU.

Data integrity and authentication: are required to

defeat active threats.

Protection against replay attacks: we suggest sequence

numbers to prevent these attacks.

Link layer terminal authentication: it is required by the

key management protocol, and applied during the
initial key exchange.

Forward secrecy: is required to prevent a departing

member access to future multicast traffic.

Backward secrecy: is required to prevent a joining

member access to past multicast traffic.

Attempting to respond to these security requirements,

different security systems have been proposed in [11], [12] and

98

the appropriate spots. Therefore, each MPEG segment should

contain obvious information that helps the OBP to handle the
switching. As the ULE standard does not provide this kind of
information, and with the intention of including them into the
transmitted frame (and for multiple reasons cited in [6]), we
propose a new encapsulation method, called EULE. This latter,
is an enhanced ULE encapsulation consisting of slightly
modifiying the ULE header to take into consideration the
requirements of the multicast transmissions. This modification
consists of replacing the NPA@ field by three new fields: the
first field is formed of a constant byte = 0x01 which means that
it is a multicast frame [9], the second field is the Session-id (3
bytes), it is an identifier whose role is to identify the multicast
session and therefore the multicast group, and it is the mapping
of the pair (source IP@, multicast IP@) [6]. The last field is the
FEC (Forward Error Correction), of 2 bytes, whose role is to
guarantee a reliable transmission of the optimized header.
Thus, an RCST sender, that has a multicast source behind him
and wishes to send his multicast traffic to the GEO satellite,
has to use the EULE to encapsulate the IP packets.

[13]. We have used the advantages of such systems in order to

submit a new enhanced security system for multicast
transmissions.
D. LKH Key Management
In multicast communication systems, there is always a
group key controller (GKC) that is responsible for generating
and distributing keys. In a particular group, we assume that
there are N group members (GM) who have access to the
information and group key (GK). Each GM has its own secret
key called unique key (UK) shared with the GKC, and all the
GMs share a common key with the GKC, the GK, in which the
encryption/decryption of the multicast traffic is performed
within the group.
In the simplest approach, a flat protocol, each member is
directly connected to GKC and has only a unique key. So,
when a GK update occurs, the GK is then sent to each member
one by one encrypted by the UK of each member. Thus, the
rekeying and storage cost of Flat protocol is N.
The LKH protocol designed for handling large groups uses
a tree structure to reduce rekeying cost. Fig. 3 shows an
example of LKH with three layers of keys where the circles
represent members GM, numbered from 1 to 27. The GKC
generates the tree of keys {A, B H} and each member will
have knowledge of the keys concerning him, namely the Key
Encryption Keys (KEK) that form a path between its UK and
GK. The GM10 holds the keys {UK10, the KEK D, K and GK
H}. If GM10 wants to leave his multicast group (rekey event),
the GKC must change all the keys {D, K, H} possessed by
him. The change is done from the bottom up, i.e. the GKC
starts by generating a new key for D and then transmits it to
GM11 encrypted with UK11 and to GM12 encrypted with
UK12. Then a new value for K is generated and sent encrypted:
with the new key D to GM11 and 12, with E to GM13-15 and
with F to GM16-18, and so forth. In general,
1
transmissions via GEO satellite are required to make this keys
modifications [5] in order to provide forward secrecy, where
is the tree outdegree ( =3 in our example). Similarly,
transmissions are done when a new member joins the group to
ensure backward secrecy. Hence the very high cost for each
change in group membership is the cost that we are seeking to
reduce in this paper.

It should be noted that in our new proposed header we did

not add any additional bit to the ULE header. Moreover, the
EULE has been adapted to the label-switching approach [6]
which makes the data forwarding and filtering much more
effective by using a set of tables. In fact, five tables are used: a
mapping table at the RCST sender, two switching tables at the
satellite (one temporary and one permanent) and two tables at
the RCST receiver (one for subscription and the other for
filtering). Therefore, the enhanced encapsulation with the
different tables, ensures an efficient support, facilitates the
forwarding of packets, and also allows the RCST receivers to
filter the incoming packets in order to reduce useless traffic.
B. Proposed Security System
To respond to the security requirements by taking into
consideration the characteristics of satellite communications,
we propose a new multicast security protocol. It consists of
ensuring secure EULE frames by improving all security
services and by adding an extension header.
To provide data integrity and data authenticity, we propose
to replace the CRC trailer of the EULE frame by a Message
Authentication Code, MAC as shown in Fig. 4. The MAC
will not protect only the PDU but also the EULE header, thus
providing protection against a wider range of active attacks. All
the transmitted PDUs should be encrypted. We suggest a key
derivation system that allows the encryption of each PDU with
a different key TK (Transient Key). To reinforce the security,
the encryption does not cover only the PDU but also the MAC.

GKC
GK (Group key)

H
1

100

101

110

10000

10001

10010

10100

10101

10110

11000

11001

11010

10 11 12

13 14 15 16 17 18

19 20 21

22 23 24 25 26 27

Figure 3. LKH key tree structure

III.

PROPOSED MULTICAST SECURITY PROTOCOL

Figure 4. Secured EULE frame

A. Proposed Encapsulation Method EULE

The satellite receives MPEG-2 data segments and treats
them on-board in order to route and switch these segments to

Additionally, we propose a new extension header to the

EULE header which contains: a PN field of 32 bits, called
Packet Number; and a T2 field of 16 bits, carrying the type of

99

the encapsulated PDU. The PN field provides protection

against replay attacks and is used as a nonce in the key deriving
process. It is to be noted that the type of the extension header is
defined by T1 and its value must be assigned by the Internet
Assigned Numbers Authority (IANA).

KV, Key Version: an 8-bit field identifying the security

association that is being created. It allows members in
both LKH layers to restore key synchronization, if they
have lost it, by sending alarm messages indicating the
last synchronized key version.

C. Proposed Key Management System

The modification of keys, when there is a change in group
membership, spreads over the whole tree, and causes a high
load on all of the system resources (GKC, satellite and
bandwidth of the satellite link). The higher the members
dynamicity is, the larger the load and cost are. In objective to
reduce these latter, we propose a new key management system
with two independent LKH layers. The first layer is between
the GKC and RCSTs where the GMs represent the RCSTs, and
the second layer between each RCST and its local group of
members. Using both layers, a member who belongs to any
RCST and wants to join or leave a group, requires only the
modifications of keys in his local group without affecting other
RCST groups and satellite transmissions. We thus assume that
the GKC must be placed with the NCC (connected or
integrated) [10] instead of putting it on-board the satellite [7].

HCS, Header Check Sum: an 8-bit field to protect the

various fields of the KPDU header against corruption.

Key ID (i): a 16-bit field identifying the ith key

KEKe(i) (or GKe) which is found encrypted in the
payload.

For the identification of keys (Key ID), we use a numbering

system inspired from CDMA (Code Division Multiple Access)
which consists of assigning a number (series of bits) for each
logical node of the tree see Fig. 3. In this manner, each
parent node ID identifies one child member or all child
members.
Finally, the KPDU will be encapsulated and transported
like any other network PDU.
IV.

Each multicast packet is encrypted and authenticated with a

transient key (TK). This key is derived from applying a hash
function (e.g. SHA-512) to the GK, session-id and Packet
Number (PN). All keys of the tree are generated by a chaotic
generator [14], and the data are also encrypted by a chaotic
algorithm [15]. The size of keys GK, KEK and UK is chosen in
order to have a good compromise between security and
processing cost. We recommend a length of 128 bits [16] for
the GK and KEK and a length of 1024 bits for the UK.

A. Advantages of the Proposed Key Management System

In this section we will compare the performance of our
proposed key management system to the Flat and LKH
protocols for several criteria. The most important criterion is
the rekeying cost over satellite link. This criterion also
determines computational effort and workload of the system
components (GKC and satellite).
We define the volatility (or dynamicity)
as the mean
number of rekeys per GM. Thus a value of =1 indicates that,
on average, there is one rekey operation per GM during the
lifetime of the secure group; Thus with N members, the number
of rekeying is given by N .

D. Key PDU
A new type of packet KPDU is proposed to transport the
new generated keys and to choose the algorithms that will be
used for key deriving, encryption and authentication. The
structure of the KPDU depicted in Fig. 5, is similar to the
structure of a normal network PDU. It consists of a header that
will carry information about the current security association,
and a payload that will carry the new keys. The transported
keys KEKe and/or GKe are encrypted with one of the keys of
the lower level of the tree.

Rekeying cost of Flat and LKH protocols are given as N

and
respectively [5]. Since the members are only
managed by a centralized group controller (GKC) in both
protocols, the satellite link and the system components will be
affected by each rekeying operation. Thus, for N rekeying,
the total rekeying cost over the satellite becomes N and
(
) for Flat and LKH protocols respectively.

NK HF EA AA KV HCS Key ID (1) ---- Key ID (NK)KEKe (1) --- GKe (NK)
Header

In our proposed system, GKC is only responsible for

rekeying RCSTs and not directly the members. Thus, satellite
resources are nearly not affected by the rekeying caused by
members. This situation significantly reduces the rekeying cost
over satellite link and workload of the system components.
Also, unlike to members, RCSTs do not show dynamic
join/leave characteristic and rekeying workload coming from
RCSTs is nearly negligible.

Payload

Figure 5. KPDU structure

The header contains the following fields:

NK, Number of keys: a 4-bit field indicating the

number of keys being transported by the KPDU.

HF, Hash Function: a 4-bit field indicating the hash

function used in the transient key derivation.

EA, Encryption Algorithm: a 4-bit field specifying the

encryption algorithm to be used.

AA, Authentication Algorithm: a 4-bit field indicating

the authentication algorithm to be applied.

SIMULATION RESULTS

Having L RCST, rekeying cost over satellite in our system

is(
) , where m represents the dynamicity of
RCSTs (similar to parameter ). It is clear that it is very
smaller than , in order of /10, /50 or /100.
Fig. 6 shows the rekeying cost over satellite link as a
function of
for the three protocols, Flat, LKH and our
proposed protocol. To plot these curves we took the values N
=10 (for a very large multicast system), k=3 and L=500. For

100

KM = [(TNK)*(KL + KIS) + (NT)* (FKH + EH)*8]/8

our proposed system, we selected three values for m: /10, /50

and /100.

Where:
TNK, Total Number of Keys: is the number of
transmitted keys (which is equal to the number of
transmissions performed within LKH).

12

Rekeying cost over satellite link

10

Flat System
LKH
2-tiered LKH, m= /10
2-tiered LKH, m= /50
2-tiered LKH, m= /100

10

10

(2)

KL, Key Length: is the length of each of the transmitted

keys (we recommend a length of 128 bits for all the
keys KEK and GK).

KIS, Key ID Size: is the size of Key ID in bits (16 bits).

FKH, Fixed KPDU Header length: is the length of the

fixed portion of the header.

EH, Extension Header: is the length of extension

header (6 bytes).

10

10

10

10

0.1

0.5

1.5

2.5

3.5

4.5

dynamicity ()

To show the superiority of our proposed protocol in terms

of key management transmitted data KM (which represents the
bandwidth consumption), a comparison is made with the
ECPVSS (Elleptic Curve Pintsov-Vanstone Signature Scheme)
method. This method has proved excellent performance [18]
since it consumes the minimal bandwidth compared with the
best competitive method. It offers a minimum average size of
approximately 50 bytes for a rekeying message.

Figure 6. Different systems rekeying cost over satellite link

When increases the cost in the three protocols increases,

but it is clear that there is a large difference among these
protocols. For example, for =1.5, the cost of Flat protocol is
close to 10 , that of LKH is close to 10 and the cost of our
system varies approximately between 100 (for m= /100) and
1350 (for m= /10). It is clear therefore that our system
significantly reduces the rekeying cost due to the dynamicity of
the members. This shows that, the impact of join/leave of
members on the satellite link is negligible in our system.

We have simulated the total transmitted key management

data KM, for our proposed method and for the ECPVSS, as a
function of the number of members N. The obtained results are
presented in Fig. 7. We notice that the difference between the
two curves is very large and it is almost constant. The KM in
the ECPVSS exceeds the double of that of our proposed
method. Using k=3 and L=500, the KM for N=10 for example,
is 1000 bytes for the ECPVSS and 410 bytes approximately for
our method.

The number of keys stored in GKC is an another important

criterion to be studied. In Flat protocol, the GKC has to store
unique keys for each member with the GK, then the storage
load is N+1, but in LKH protocol, the GKC stores (kN-1)/(k-1)
keys [17]. In our key management system, GKC stores the
KEKs, a key for each RCST, and the group key, GK. Thus, the
number of keys stored in GKC is (kL-1)/(k-1) ~ 3L/2 which is
much smaller than Flat and LKH protocols.

Total Key Mangement Data over link [bytes]

V.

1200

BANDWIDTH CONSUMPTION ANALYSIS

A. Key Management Data

The required keys for a rekeying are shared in a set of
KPDU packets transmitted over the satellite or terrestrial link.
NT represents the number of these packets and equals to
,
where Nt is given by:
Nt =

(k-1) +
k+

logk N -1

2
logk N -1
2

3
1000
10

LKH with ECPVSS

Our protocol (KPDU)

900
800
700
600
500

400

300

200

(Leave)

174
4
10

(1)

2.5*104

10

2.5*105

10

3*106

Number of Members (N)

(Join)

Figure 7. Total transmitted data for one rekeying

This is the number of transmissions, but let us see how the

keys are distributed into the transmitted packets. If Nt is an
integer, the keys will be distributed as follows: (k-1) packets
where each packet contains only one key, and ( log

1)/2 packets with 2k keys each. If Nt is a non-integer, the keys

will be distributed in the following manner: (k-1) packets with
2)/2 packets each containing 2k
only one key, ( log
keys and the last packet with k keys. For one rekeying, the total
key management data KM transmitted over one of the two
layers, satellite or terrestrial, is given by:

This proves that our method offers an approximate

reduction of 59% on the added overhead as well as on
bandwidth consumption. This can be explained by the fact that
only one overhead is added to the KPDU packet which
transmits a set of keys against one overhead for each
transmitted key in an ECPVSS packet.
B. Secure Multicast Data
In our multicast security protocol, an additional quantity of
6 bytes as an extension header is added to the header of each

101

protocol on all levels. Our protocol has finally shown that it is

capable of reducing the bandwidth consumption of the
transmitted key management data to more than 58% compared
to the best existing approach.

EULE frame sent. The resulting cost is the price paid to

provide the security requirements for multicast transmission.
This quantity is represented by the two fields T2 and PN
having a constant size of 6 bytes. The percentage of the added
overhead relative to the quantity of transmitted multicast data is
given by:

REFERENCES
[1]

EHO=100.EH / l(EULE)

(3)

Where EH is the length of the extension header (6 bytes)

and l(EULE) is the medium length of the EULE frames.

[2]

This term EHO expresses the quantity of added information

by the use of an extension header. Thus, it is only a function of
the IP packet length. We have simulated the EHO for average
packet lengths between 22 bytes and 1500 bytes. The obtained
result is presented in Fig. 8.

[3]

[4]

16

[5]

14

Data Overhead

12

10

[6]

[7]

0
0

200

400

600

800

1000

1200

1400

1600

1800

[8]

Average PDU length [bytes]

Figure 8. Extension Header of Data Overhead

[9]

We have noticed that for big values of IP packet length

(more than 500 bytes), the added extension header is not
important and represents less than 1% of the IP packet length.
VI.

[10]

CONCLUSION

In this paper we have proposed a multicast security

protocol for IP over DVB that respects all the security
requirements. This protocol relies on a new encapsulation
method enhanced from ULE (EULE) in order to ensure an
efficient multicast forwarding reaching only the spot beams
containing members. The proposed EULE requires a slight
modification on the ULE and a 6-byte extension header.

[11]

[12]

[13]

The proposed approach offers data confidentiality which is

the main objective of IP multicast over DVB-S, data
authenticity, data integrity, protection against replay attacks,
traffic backward secrecy, forward secrecy, fast rekeying and
scalable key management. We suppose that chaos is used to
generate the keys and to encrypt the data and the transmitted
keys. To reduce the rekeying load on all of the system
resources and especially on the satellite link, an architecture of
two LKH layers is used. Consequently, the rekeying for a
member affects only the terrestrial LKH and has a negligible
impact on the satellite link. Additionally, the KPDU packet
which transmits the keys sends a set of keys with a small
header. The performed simulations and comparisons that have
been made with the existing approaches: flat, original LKH and
the ECPVSS, have shown the superiority of the proposed

[14]

[15]

[16]
[17]

[18]

102

V. P. Hubenko jr. et al. Improving the Global information Grids

Performance through Satellite Communications Layer Enhacements ,
IEEE commun. Mag., vol. 44, no. 11, Nov. 2006, pp. 66-72.
Digital Video Broadcasting (DVB); DVB Specification for Data
Broadcasting, European Telecommunication Standards Institute (ETSI),
EN 301 192 v1.2.1, June 1999.
Hubenko, V.P., Jr., Raines, R.A., Baldwin, R.O., Mullins, B.E., Mills,
R.F., and Grimaila, M.R., Improving Satellite Multicast Security
Scalability by Reducing Re-keying Requirements, IEEE Network,
Special Issue on Advances in Network Systems Architecture, Vol. 21,
No. 4, August 2007, pp. 51-56.
S. Rafaeli and D. Hutchison, A Survey of Key Management for Secure
Group Communication, ACM Computing Surveys, vol.35, no.3, 2003,
pp. 309-329.
M. P.Howarth, S. Iyengar, Z. Sun, H.Cruickshank, 2004. Dynamics of
Key Management in Secure Satellite Multicast, IEEE Journal on
Selected Areas in Communications, vol. 22, no. 2, Feb. 2004, pp. 308319.
F. Filali, G. Aniba, W. Dabbous Efficient support of IP Multicast in the
Next Generation of GEO satellites, IEEE Journal on Selected Areas in
Communications , vol. 22, No. 2, Feb. 2004, pp. 413-425.
Altay Yavuz, F. Alagoz, E. Anarim. A new Satellite Multicast Security
Protocol Based on Elliptic Curve signatures. IEEE International
Conference on Information Communication Technologies, April 2006.
Hong T.C., Chee W.C., Budiarto R., 2005. A comparison of IP
Datagrams Transmission using MPE and ULE over MPEG/DVB
Networks, Fifth International Conference on Information,
Communications and Signal Processing, Bangkok, Thailand.
G. Fairhurst, B. Collini-Nocker, Unidirectional Lightweight
Encapsulation (ULE) for Transmission of IP Datagrams over MPEG-2
Transport Stream (TS), IETF RFC 4326, December 2005.
S. Iyengar, H. Cruickshank, P. Pillai, G. Fairhurst and L.Duquerroy,
Security requirements for IP over satellite DVB networks, Mobile and
wireless Communications Summit, 16th IST, Budapest, July 2007.
P. Pillai and Y.F.Hu, Design and Analysis of Secure Transmission of IP
over DVB-S/RCS Satellite Systems, Wireless and Optical
Communications Networks, 2006.
D. Caragata S. El assad, I. Tutanescu and E. Sofron, Secure TCP/IP
Communications over DVB-S/DVB-RCS Using Chaotic Sequences,
the 4th International Conference for Internet Technology and Secured
Transactions, November 2009.
D. Caragata, S. El Assad, B. Bakhache, I. Tutanescu, Secure IP over
Satellite DVB Using Chaotic Sequences, Engineering Letters journal,
Vol. 18, no. 2, May 2010, pp. 135-146.
S. El Assad, H. Noura, I. Taralova, 2008, Design and analyses of
efficient chaotic generators for crypto-systems, Advances in Electrical
and Electronics Engineering- IAENG Special Edition of the World
Congress on Engineering and Computer Science 2008, vol. I, pp. 3-12.
Noura H, El Assad S, Vladeanu C. Design of a Fast and Robust ChaosBased Crypto-System for image encryption, MTA Review, ISSN 18433391, Vol. XXI, No. 1, Mars 2011, pp. 67-80.
ECRYPT II Network of Excellence, 2010, Yearly Report on
Algorithms and Keysizes (2009-2010).
W.H.D. Ng, and Z. Sun, Multi-Layers Balanced LKH. IEEE
International Conference on Communications, Vol. 2, pp. 1015-1019,
August 2005.
L. A. Pintsov and S. A. Vanstone, Postal revenue collection in the digital
age., Proceedings of Financial Cryptography, FC'00, number 1962 in
LNCS, pp. 105- 120. Springer- Verlag, 2000.