Transcript Document

A System for End-to-end
Authentication of Adaptive
Multimedia Content
T. Suzuki1, Z. Ramzan2, H. Fujimoto1, C.
Gentry2, T. Nakayama1, and R. Jain2
1NTT DoCoMo, Inc.
2DoCoMo Communication Laboratories, USA
Background

Adaptive (derivative) content distribution systems
Tier-1 Provider

Original
Content
Tier-2 Provider
Derived
Content
Content User
Application examples
 Content customization



Based on preference, device capability, location, etc…
Personalized advertisement insertion
Content creation

Create original content using commercially available content


Add Flash/movie clip to music clip
Extract movie/music clip for audio/visual ring tone
Benefit of content adaptation services

for Tier-1 providers



for Tier-2 providers



Revenue from both original and derived content
Content reuse
High quality content from tier-1 providers
Revenue from value-added content
for End-user

Value-added content from tier-2 provider
Objective of this study

Achieve adaptive content distribution, with end-toend authenticity of content.

Tier-1 provider can protect original content and its
usage policy from illegitimate modification.
Tier-2 provider can protect value-added content and
additional policy.
End-user can verify the authenticity of both original
and derived content.


Challenge & contribution

Challenge:





Achieve end-to-end authenticity while allowing insertion of
content as well as deletion by authorized tier-2 providers
Control the place for content insertion
Avoid deletion of the inserted content without detection
Low communication and computation overhead
Contribution:


Place-holder extension to Merkle-tree based signature
scheme
Embodiment of the extension using trapdoor hash function
Merkle tree, signing
ve
vi = hash ( xi + vi0 + vi1 )
v0
Construct
v1
v00
X=
Signature = <ve, Sig0(ve)>
v01
Verify
v10
v11
v000
v001
v010
v011
v100
v101
v110
v111
x000
x001
x010
x011
x100
x101
x110
X111
Merkle tree, deletion
ve
vi = hash ( xi + vi0 + vi1 )
v0
Construct
v1
v00
X=
Signature = <ve, Sig0(ve)>
v01
Verify
v10
v11
v000
v001
v010
v011
v100
v101
v110
v111
x000
x001
x010
x011
x100
x101
x110
X111
Merkle tree, placeholder extension

Signer allocates placeholder in hash tree, so
that Proxy can insert content and commit to it.
ve
Signature = <ve, Sig0(ve)>
vn
vn0
vn1
Information specifying the placeholder
Placeholder
Realization using conventional signature
scheme (CS)


Signer places Proxy’s public key in the placeholder.
Proxy attaches its content and signs it separately.
Signer
Signature = <ve, Sig0(ve)>
Proxy
+ <Proxy’s sign>
ve
vn
vn0
vn1
Public key of Proxy
vn1
Placeholder
Public key of Proxy
Placeholder
m
Realization using hash-sign-switch (HSS)

Trapdoor hash function:



A special type of hash functions
The owner of trapdoor key can find collision of hash.
Trapdoor hash TH= HY(m, r)



Trapdoor key X and public key Y
If X is unknown, there is no efficient algorithm
 to find (m1, r1) and (m2, r2), (m1≠m2)
 such that HY(m1, r1) = HY(m2, r2)
If X is known, there is an efficient algorithm given m1,
m2(≠m1), r2
 to find r2
 such that HY(m1, r1) = HY(m2, r2)
Realization using hash-sign-switch


Signer places TH and Y generated by Proxy in the
placeholder.
Proxy attaches its content m and its commitment r.
Signer
Proxy
+r
Signature = <ve, Sig0(ve)>
ve
vn
vn0
vn1
TH and Y generated
by Proxy
Placeholder
vn1
m
TH and Y generated
by Proxy
Placeholder
Block diagram of HSS scheme
Tier-1 provider
Tier-2 provider
Trapdoor
Hash
TH = HY(m’, r’)
TH, Y, r’, m’
Set
Placeholder
in hash tree
End User
X, r’, m’
TH
m
Generate
parameters
X, Y, r’, m’
Commitment r :
TH = HY(m, r)
r
Sign
Sign [ TH ]
+
Verify
Sign [ TH ] + r
Sign[TH]
TH
r
TH
m
Construction of a trapdoor hash function

Based on discrete logarithm assumption
(DLA)






Let q, p be primes such that q | p-1
Let g be an element of order q in Z*p
Trapdoor key x is random number from Z*q
Public key y = gx mod p
Hy(m, r) = gmyr
To find r2 such that Hy(m1, r1) = Hy(m2, r2) by
r2 = ( m1 - m2 ) x -1 + r1
Limited reuse of placeholder

In DLA based hash-sign-switch, a placeholder can
be used only once, otherwise trapdoor key x leaks.

Modification to enable k-time reuse




Generate k public keys:
yi = gxi (mod p) 1 ≤ i ≤ k
Compute hash:
TH = gm’y1r’ (mod p)
To insert i-th content mi, Proxy computes:
ri = (m’ + r’x1 – mi) xi-1 mod q
Verifier checks:
gmiyiri = TH
Preventing removal of inserted content m

Proxy signs each of its placeholders regardless of
whether it wishes to insert content into it.


Then, any placeholder without a signature constitutes
evidence that Proxy’s content was illegitimately deleted.
Proxy aggregates its signature with Signer’s
signature.


Since it is impossible for a third party to disaggregate the
signatures, Proxy can ensure that m cannot be removed
without detection.
Example: BGLS aggregate signature scheme [19]
Prototype System
Meta-data level
adaptation
Original
Meta-data
Tier-1 Provider
Tier-2 Provider
Modified
Meta-data
Primary
Media File
Secondary
Media File
Media Servers

Modified
Media File/Stream
Content User
Apply the proposed signature scheme for
meta-data level adaptation
Assumptions in our prototype

User device (e.g., mobile phone) is trusted by tier-1,
tier-2 providers, and end users.
 To detect modification against usage rule.
 To detect modification against commitment.
 To verify content authenticity.
 To take appropriate response upon detection of .
Information flow
Tier-1 provider
Tier-2
provider
Tier-2
Tier-2provider
provider
User device
Placeholder provisioning service
Space for Ad.
phid=m
Request
Placeholder
Information for
placeholder
Insert
elements
Commit
Space for Ad.
phid=n
メニュー
データ
電話帳
メニュー
データ
電話帳
Build hash tree
with placeholder
Sign
Equivalent to SMIL
document structure
Verify
Implementation

Content of meta-data


Usage policy and evaluation of modification


W3C/XML-DSIG with extension to support hash tree and
placeholder extension
Placeholder request from tier-2 to tier-1 provider


OASIS/XACML
Signature on meta-data


Scene description written in W3C/SMIL
W3C/SOAP
Verification module

HTTP proxy which evaluates a signed SMIL document, and
outputs a normal SMIL document.
SMIL document to be signed
<?xml version=“1.0”?>
<smil>
<head/>
<body>
<seq>
<par>
URLs of multimedia content
<video src=“rtsp://tyer-1/video1.rm”/>
which construct the scene
<video src=“rtsp://tyer-1/music1.rm”/>
</par>
<par>
<video phid=“1”/>
Placeholder with ID (phid) of “1”
</par>
</seq>
</body>
</smil>
Signed SMIL document
Contains XACML
policy document
XML-DSIG
with extension
<?xml version=“1.0”?>
<DocumentRoot>
<Policy/>
<smil/>
<Signature>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
<Reference URI=/DocumentRoot/Policy />
<Reference URI=/DocumentRoot/smil/head />
<Reference URI=/DocumentRoot/smil/body>
<DigestMethod Algorithm=“HashTreeConstruction”/>
<DigestValue> root_node_of_hash_tree </DigestValue>
</Reference>
<TrapdoorHashMethod Algorithm=“Discrete Log” phid=“1”>
<PublicValue> public_values_of_trapdoor_hash </PublicValue>
<TrapdoorHashValue> trapdoor_hash_value </TrapdoorHashValue>
</TrapdoorHashMethod>
</SignedInfo>
<SignatureValue> Signature </SignatureValue>
</Signature>
</DocumentRoot>
SMIL element after adaptation


One video URL is deleted
One video URL is inserted
<smil>
<head/>
<body> <seq>
<par>
<video src=“rtsp://tyer-1/video1.rm”/>
<video adaptation=“delete”/>
</par>
<par>
<video phid=“1” src=“rtsp://tyer-2/xxx.rm” adaptation=“add”/>
</par>
</seq> </body>
</smil>
Signature element after commitment

Add commitment value corresponding to the
inserted content (identified by phid)
<Signature>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
<Reference URI=/DocumentRoot/Policy />
<Reference URI=/DocumentRoot/smil/head />
<Reference URI=/DocumentRoot/smil/body />
<TrapdoorHashMethod Algorithm=“Discrete Log” phid=“1”/>
</SignedInfo>
<SignatureValue/>
<AdditiveSignature phid=“1”>
<CommitmentValue>Commitment_Value_of_TrapdoorHash </CommitmentValue>
</AdditiveSignature>
</Signature>
Performance evaluation

Platforms

Modules in tier-2 provider (SMIL document adaptation,
policy check, commitment)


Modules in user device (signature and commitment
verification, policy check)


3GHZ Pentium 4 with 1GB memory, running Redhat Linux
2.4.20.
866MHz Pentium III machine with 512 MB memory, running
Windows XP.
Parameter of public key signature


1024-bit DSA-SHA1 in XML-DSIG
1024-bit modulus for trapdoor hash (DLA)
Computational overhead in tier-2 provider
HSS can reduce commitment overhead by
95% compared to CS.
Steps in tier-2 provider
1000
800
D elay [m sec]

com m itm ent
policy check
adaptation
600
400
200
0
XM L-D SIG
XM L-D SIG
(hash tree)
O ne
"delete"
O ne "add" O ne "add"
(C onv.) (Trapdoor)
Computational overhead in user device
The verification overhead of HSS is higher
than CS by 32%.
Steps in user device
1000
800
D elay [m sec]

C om m itm ent verification
Signature verification
policy check
600
400
200
0
XM L-D SIG
XM L-D SIG
(hash tree)
O ne
"delete"
O ne "add" O ne "add"
(C onv.) (Trapdoor)
Overall computational overhead
1200.0
1000.0
D elay [m sec]
800.0
C om m itm ent verification
Signature verification
policy check
com m itm ent
policy check
adaptation
600.0
400.0
200.0
0.0
XM L-D SIG (hash
tree)
O ne "delete"
O ne "add"
(C onv.)
O ne "add"
(Trapdoor)
Alternative approach for secure adaptive
content distribution

Trusted content sharing system[10]: Content
adaptation on a trusted host



Tier-1 provider trusts the host to enforce access policy.
Tier-1 provider trusts the host to sign the content on its
behalf.
In our system, we assume weak trust between tier-1
and tier-2 providers.



Tier-2 buys original content subject to its usage rule.
Tier-1 presumes tier-2 might try to perform illegal
modification of content and its usage rule.
(We assume strong trust on user devices.)
Related works

Homomorphic signature scheme [12]




Permit selective content removal
Merkle trees are used to create message digest
Deletions involve creating a small cover for the
subset of the removed data items
We proposed placeholder extension to the
Merkle tree based signature scheme, and
proposed two schemes to realize the
placeholder.
Future works

Other components to realize adaptive content
protection




Content encryption
Key management
Media data protection (streaming, mp4 file, etc…)
Etc…
Conclusion



Presented adaptive content distribution
system with end-to-end authenticity.
Proposed a Merkle tree based signature
scheme with placeholder extension.
Proposed two scheme to realize the
placeholder



Conventional signature (CS)
Hash-sign-switch (HSS)
HSS can reduce commitment overhead at
Proxy at the cost of verification overhead.