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

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

Tier-1 Provider Tier-2 Provider Content UserOriginalContent

DerivedContent

Benefit of content adaptation services for Tier-1 providers

Revenue from both original and derived content Content reuse

for Tier-2 providers 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-to-end 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, signingve

v00

v0

v000 v001

v01

v010 v011

v10

v1

v100 v101

v11

v110 v111

Signature = <ve, Sig0(ve)>

Construct

vi = hash ( xi + vi0 + vi1 )

Verify

x000 x001 x010 x011 x100 x101 x110 X111X=

Merkle tree, deletionve

v00

v0

v000 v001

v01

v010 v011

v10

v1

v100 v101

v11

v110 v111

Signature = <ve, Sig0(ve)>

Construct

vi = hash ( xi + vi0 + vi1 )

Verify

x000 x001 x010 x011 x100 x101 x110 X111X=

Merkle tree, placeholder extension Signer allocates placeholder in hash tree, so

that Proxy can insert content and commit to it.

Placeholder

vn

vn0 vn1

ve

Information specifying the placeholder

Signature = <ve, Sig0(ve)>

Realization using conventional signature scheme (CS) Signer places Proxy’s public key in the placeholder. Proxy attaches its content and signs it separately.

Placeholder

vn

vn0 vn1

ve

Public key of Proxy

Signature = <ve, Sig0(ve)>

Placeholder

vn1 Public key of Proxy

m

+ <Proxy’s sign>Signer Proxy

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.

Placeholder

vn

vn0 vn1

ve

TH and Y generated by Proxy

Signature = <ve, Sig0(ve)>

Placeholder

vn1TH and Y generated

by Proxy

m

+ rSigner Proxy

Block diagram of HSS schemeTier-2 providerTier-1 provider

SetPlaceholderin hash tree

Sign

Commitment r :TH = HY(m, r)

X, r’, m’

m

TH

GenerateparametersX, Y, r’, m’

TH, Y, r’, m’ Trapdoor Hash

TH = HY(m’, r’)

Sign [ TH ]+

TH

r

End User

Verify

Sign [ TH ] + r

TH

m

rSign[TH]

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) byr2 = ( 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

Apply the proposed signature scheme for meta-data level adaptation

Tier-1 Provider

Content User

Media Servers

Tier-2 Provider

OriginalMeta-data

PrimaryMedia File

SecondaryMedia File

Meta-data level adaptationMeta-data level adaptation

ModifiedMeta-data

ModifiedMedia File/Stream

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 flowTier-2 providerTier-2 providerTier-2 providerTier-2 providerTier-1 providerTier-1 provider

Placeholder provisioning service

Build hash treewith placeholder

データデータメニューメニュー 電話帳電話帳 データデータメニューメニュー 電話帳電話帳

Space for Ad.phid=n

Space for Ad.phid=m

Tier-2 providerTier-2 provider

RequestPlaceholder

Information forplaceholder

Insertelements

Commit

User deviceUser device

Sign Verify

Equivalent to SMIL document structure

Implementation

Content of meta-data Scene description written in W3C/SMIL

Usage policy and evaluation of modification OASIS/XACML

Signature on meta-data W3C/XML-DSIG with extension to support hash tree and

placeholder extension Placeholder request from tier-2 to tier-1 provider

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>

<video src=“rtsp://tyer-1/video1.rm”/><video src=“rtsp://tyer-1/music1.rm”/>

</par><par>

<video phid=“1”/></par>

</seq></body>

</smil>

URLs of multimedia content which construct the scene

Placeholder with ID (phid) of “1”

Signed SMIL document<?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>

Contains XACML policy document

XML-DSIGwith extension

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) 3GHZ Pentium 4 with 1GB memory, running Redhat Linux

2.4.20. Modules in user device (signature and commitment

verification, policy check) 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

0

200

400

600

800

1000

XML-DSIG XML-DSIG(hash tree)

One"delete"

One "add"(Conv.)

One "add"(Trapdoor)

Del

ay [

mse

c]

commitmentpolicy checkadaptation

Computational overhead in user device The verification overhead of HSS is higher

than CS by 32%.

Steps in user device

0

200

400

600

800

1000

XML-DSIG XML-DSIG(hash tree)

One"delete"

One "add"(Conv.)

One "add"(Trapdoor)

Del

ay [

mse

c]

Commitment verificationSignature verificationpolicy check

Overall computational overhead

0.0

200.0

400.0

600.0

800.0

1000.0

1200.0

XML- DSIG (hashtree)

One "delete" One "add"(Conv.)

One "add"(Trapdoor)

Del

ay [

mse

c]

Commitment verificationSignature verificationpolicy checkcommitmentpolicy checkadaptation

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.