a system for end-to-end authentication of adaptive multimedia content t. suzuki 1, z. ramzan 2, h....
Post on 28-Dec-2015
213 Views
Preview:
TRANSCRIPT
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.
top related