under signing key K
s
and Verif(K
p
,M,ϕ) denotes
the verification algorithm. P
i
need not know K
p
or
K
s
. T and R may also use a symmetric key (which
proxies need not know).
Let
M
denote the initial content that is composed
by a meta-data description (m
1
) and n − 1 media
objects(m
2
,m
3
,...,m
n
). Where convenient, we as-
sume
n
is a power of 2. In our scheme, adapting a me-
dia object means remove the corresponding leaf in the
binary tree representation of the content and replace
it by a new leaf.The intermediary may also choose to
add a new media object or remove one.
Let
h()
denote a collision resistant hash function
that takes as input a leaf
l
and a (fixed and publicly
known) v-bit initialization vector (IV), and produces
a v-bit output.
To process flow authentication, the framework con-
sists of three main steps: document preparation and
signature by transmitter, document adaptation by
proxies and document verification by end users. We
describe them as follows:
Preparation The meta-data document is first
parsed to generate an adaptive format according to
the server policy. To build an MHT from the origi-
nal content, each media is associated to a leaf, and for
each adaptive media object we join a Freeleaf as sib-
ling. The Merkle tree associated with M is a balanced
binary tree in which each node v is assigned a value
ψ
(v)
.
To sign
M
, the transmitter computes the root value
Ω of the MHT associated with
M
. The signature is
ϕ=Sign(K
s
,Ω).
Adaptation On receiving the protected document,
a proxy can apply adaptation operations to fit the doc-
ument into some different format. as we said above,
the adaptation operation for a media in our scheme is
performed by deleting this media in the MHT and in-
serting the adapted format as new leaf. Deletion and
insertion by the intermediaries are ensured like fol-
lows:
Deletion is supported by supplying some extra ver-
ification data so that the verifier can still compute the
root of the MHT, as we now describe. First, let Mi de-
note the transformed data after the removal of blocks.
Insertion of an adapted media by the intermediary
is done using freeleaves. We use conventional public-
key signatures, S places P’s public key, or instruc-
tions on where to retrieve it, in the freeleaf. S then
creates a MHT digest and signs as described above.
P, in turn, attaches its content and signs it separately.
R checks the validity of both signatures.
Verification The verification procedure is actually
reversing the above process. Suppose a receiver re-
trieves a content as well as its authentication data from
some proxy. It then analyze it. With recovered au-
thentication data, the receiver can verify the stream
integrity and signatures with proper aggregate signa-
ture verification scheme.
The verification process includes unpacking, de-
coding and verifying. At least k out of
n
initial me-
dia objects should be received in order to recover
the authentication data. Suppose
k
media objects
m
1
,m
2
,...,m
k
are received successfully.
1. For m
j
(1≤ j ≤ k), computes ψ(m
j
)=
h(IV,
m
j
)
.
2. Let {
1
,
2
,...,
k
} the set of results. If any pair
correspond to siblings, replace the pair with their
hash (which corresponds to their MHT parent). Re-
peat step 2 until only one value remains. call it Ω
.
3. Finally run Verif(K
p
, Ω
,ϕ).
We can see that Ω = Ω
, from which it is easy to
see why the above algorithm works. If one has all
the initial media objects, then the above procedure is
the standard algorithm for computing the MHT root.
Now, observe that whenever R receives some hashes
1
,
2
...,
n
these come from P running the same
algorithm on the subset of missing frames. There-
fore, Pand R have together run the algorithm on all n
blocks which yields the Merkle root value.
2.2 XSST
In order to ensure a fully secured service for adaptive
multimedia content delivery in SEMAFOR, we have
to ensure secure transactions between all parts of the
platform. In other words, all communications have to
be authenticated and encrypted.
For this purpose, we proposed XSST (Xml Se-
cure SEMAFOR Transaction) providing the user with
guarantee on the confidentiality, integrity, authenti-
cation and non-repudiation. XSST consists of three
major components: XSST Client, XSST Proxy and
XSST Server. It will firstly establish a secure tun-
nel for a real transaction before this transaction takes
place. This secure tunnel is established by using a
public-key based key exchange between the XSST
proxy and XSST server in order to derive a unique se-
cret key that can then be used to ensure data integrity
and confidentiality throughout the session. XSST al-
lows both Proxy and Server sign the messages, this
signature can be generated directly by the proxy and
server, or by other applications which the XSST in-
teracts with. More informations about XSST can be
found in (Kaced and Moissinac, 2006b).
Figure 3 illustrates the operations between the mul-
timedia server S and the proxy P, and the operations
between the proxy P and the client C for requesting
and adapting the multimedia data.
PROTECTING ADAPTIVE MULTIMEDIA DELIVERY AND ADAPTATION USING PROXY BASED APPROACH
89