Upload
pptblog-pptblogcom
View
146
Download
0
Tags:
Embed Size (px)
Citation preview
A Case for a Multi-Key Secure Video Proxy: Theory, Design and
Implementation
S.F. Yeung, John C. S. Lui, David K. Y.Yau
ACM Multimedia 2002
Multi-Key Secure Video Proxy
Motivation – Why Secure Video Proxy ? Background Related Work Secure Video Proxy Requirements Our Design
Design, Implementation and Experiment Q & A Section
Why Video Proxy ?
Many multimedia contents use Internet as a mean for distribution.
1.5Mbps network bandwidth is required for VCD quality movie.
Server bandwidth and the server-client long haul path are the bottleneck. Long startup latency Network congestion problem
Client-Server Infrastructure
source
Client 1
Client 2
Client 3
Client NServer bandwidth (fan-out) is very
limited
Long haul bottleneck paths
Packets get dropped
Why Video Proxy ?
Physically proximity to the clients – instantaneous startup.
Cache data to relief server workload – about to serve more clients.
Availability of cached data even the source is down or the path is congested.
Client-Proxy-Server Infrastructure
source
Client A1
Client A2
Client A3
Client AN
Client B1
Client B2
Client B3
Client BN
Client P1
Client P2
Client P3
Client PN
Proxy A
Proxy B
Proxy P
Why Secure Video Proxy ?
Commercial multimedia contents are copyright protected, unauthorized distribution must be prohibited.
Some services, like the “Pay-per-view”, clients must pay the service so that they can access the contents.
Proxy infrastructure must support data confidentiality in conjunction with data caching.
Background
Secure Client-Server Infrastructure Secure Proxy – Caching of Decrypted Data Secure Proxy – Caching of Encrypted Data
Secure Client-Server Infrastructure
source
Client 1
Client 2
Client 3
Client N
Encrypt using client 1’s key
Encrypt using client 2’s key
Encrypt using client 3’s keyEncrypt using client N’s key
Simple Source has very high workload. not scalable.
Proxy Caching with Decrypted Content
source
Client A1
Client A2
Proxy AEncrypt with Proxy’s key
Decrypted Content
Encrypt with Client A1’s key
Encrypt with Client A2’s key
Simple Proxy’s storage is insecure, original content can be retrieved by intruders
Proxy Caching with Encrypted Content
source
Client A1
Client A2
Proxy AEncrypt with Proxy’s key
Encrypted Content
Decrypt using proxy’s keyEncrypt using clienti’s key Trivial
Proxy’s storage is secure, however the computational complexity is very high for both decryption and encryption Decryption key can be revealed when the proxy is compromised.
Related Work
Caching of Intentionally Corrupted Content VEA Encryption for MPEG-1 Movie
Proxy Caching with Corrupted Content
source Client A1
Client A2
Intentionally Corrupted
Content
Part for reconstruction(via secure channel)
Proxy
Protecting VoD the Easier Way, ACM Multimedia 98 How secure is those corrupted content ? Since server needs to perform encryption for each client, this approach is not scalable
Proxy Caching with VES Encryption
source
Client A1
Client A2
Proxy AEncrypt with Proxy’s key
Encrypted Content
Encrypt using VES encryption
A Fast MPEG Video Encryption Algorithm, ACM Multimedia 98 Enable multiple encryptions while one-time decryption, however, VEA is fragile towards plaintext attack (reveal the decryption key when both plaintext and cipher are known)
Secure Video Proxy Requirement
The proxy should be able to deliver uniquely encrypted content to each client while avoid any decryption operations.
Client can perform one-time decryption on the encrypted content to retrieve the original content.
The encryption algorithm should be computational infeasible to crack.
Definition of Asymmetric Reversible Parametric Sequence (ARPS)
Given Di-1 and Di, it is computational infeasible to find ei
For each Dj there exists a reverse function i,j such that Di = i,j(Dj)
Given {ei+1, …, ej}, it is computational infeasible to find i,j
D-1 D0 D1 DN
f(D-1, e0) f(D0, e1) f(D1, e2) f(DN-1, eN)
f(DN, eN+1)
D1 DN
f(D0, e1) f(D1, e2) f(DN-1, eN)
f(DN, eN+1)* * * * * * * ** *
Use ARPS to design proxy with the following properties Data confidentiality during transmission
(between source to proxy, proxy to clients). End-to-end confidentiality : intruder who gains
access to proxy’s or client’s storage, original data will not be revealed.
Data confidentiality against proxy intruders (when SRPS is used, given D0 and e0 one can find D-1. But if ARPS is used, this will “not” be possible.)
Use ARPS to design proxy with the following properties (Continue) Data confidentiality against member collusion :
if SRPS is used, then if 1. client j has ei and ej,2. the encrypted data Di, and3. the decrypting function -1,j
For example:1. Given ei, intruder can obtain 0,i
and D0 = 0,i(Di)2. Given ej and D0,obtain Dj = f(D0,ej)3. Given Dj, obtain D-1 = -1,j (Dj)
ARPSf sequence for the secure video proxy
e0
e1
e2
eN
Client 1
Client 2
Client Nsource
D-1 D0
D1
D2
DN
Video Proxy
Our Design
Implement APRSf using Multi-Key RSA
Architecture and Protocols Encryption Configuration Parameters
Implement ARPSf using Multi-Key RSA
Single-Key RSA Choose two large prime number p and q Compute n = pq and = (p-1)(q-1) Select e such that gcd(e, ) = 1 Select d such that ed = 1 (mod ) Encryption:
Cipher C = De mod n Decryption:
Data D = Cd mod n
Implement ARPSf using Multi-Key RSA Extend to Multi-Key RSA
Proxy generates p, q, and then n and Select e0 such that gcd(e0, ) = 1
Source encrypts data: Cipher C = Deo mod n
For each requested client, proxy selects ei such that gcd(ei, ) = 1, also select di such that (e0ei)di = 1 mod
Proxy encrypts data: Cipher Ci = Cei mod n
Client i decrypts data: Data Di = Ci di mod n
Operations between source and proxy
request
Ack(e1, n)
D0(using e0)
request
authentication and
key generation(e0, e1, d1, n, phi)
Data encryption
caching orrelaying
Server Proxy
Operations between proxy and client
request(eCert)
Ack(e1, [d1], n)
D0(using e0)
Authentication andkey generation
Data encryption
D1(using e1)
Server Proxy Client 1
Requestrequest(eCert)
Data encryption Data
decryption
Ack([d1], n)Retrieve d1
eCert: public key in plaintext and public key encrypted by private key[d1]: d1 encrypted by client’s public key in eCert
Encryption Configuration Parameters
Packet 0(1400 bytes)
Packet 1(1400 bytes)
Packet 2(1400 bytes)
Packet 3(1400 bytes)
Encryption block
Encryption sub-block
Spkt = 1400 bytes, I = 2, P = 0.5 and B = 4
Secure Multimedia Library - SML Implementation of the Multi-key RSA with ECP
Structure C language API
Data type SML_SESSION session
Functions SML_InitSession(), SML_DestroySession() SML_NewKeyPair(), SML_LoadKeyPair(), SML_SaveKeyPair() SML_Connect(), SML_Accept() SML_ConfigureRps(), SML_SaveRps(), SML_LoadRps() SML_SendRps(), SML_ReceiveRps() SML_SendEncryptRps(), SML_ReceiveDecryptRps()
Secure Multimedia Library - SML Programming Paradigm
SML_InitSession();SML_Accept();SML_SendRps();SML_SendEncryptRps();
SML_InitSession();SML_Connect();SML_ReceiveRps();StoreData();
Server Proxy
SML_InitSession();SML_ProxyAccept();SML_SendRps();ReadData();SML_SendReEncryptRps();
ProxySML_InitSession();SML_ConnectProxy();SML_ReceiveRps();SML_ReadDecryptRps();
Client
Secure Multimedia Library - SML Client Code ExampleSML_InitSession(&session); SML_NewKeyPair(&session, 512, 65537, CRYPTO_KEY_RSA);SML_SaveKeyPair(&session, "key.rsa", "passwd"); if (SML_Connect(&session)) { SML_ReceiveRps(&session); for (i=0; i<total_pkt; i++) { SML_ReadDecryptRps(&session, buffer, buf_size); }}
SML_DestroySession(&session);
Secure Multimedia Library - SML Server Code ExampleSML_InitSession(&session); SML_LoadKeyPair(&session, “key.rsa”, “passwd”, CRYPTO_KEY_RSA); if (SML_Accept(&session)) { SML_LoadRps(&session, “movie_0.rps”); SML_SendRps(&session); for (i=0; i<total_pkt; i++) { SML_SendEncryptECP(&session, buffer, buf_size); }}
SML_DestroySession(&session);
Encryption Configuration ParametersP = 0.257 P = 0.214 P = 0.171 P = 0.120 P = 0.086 P = 0.043
t M t M t M t M t M T M
I = 1 2.13 11.36 2.53 13.5 3.11 16.60 4.05 21.60 5.8 30.90 10.10 53.90
I = 2 4.10 21.87 4.84 25.81 5.91 32.52 7.54 40.20 10.16 54.19 11.77 62.77
I = 5 9.06 48.32 10.17 52.24 11.56 61.66 11.64 62.08 11.76 62.72 11.78 62.82
I = 10 11.64 62.08 10.7 57.10 11.70 62.40 11.73 62.56 11.73 62.56 11.82 63.04
t = proxy throughput, M = Number of concurrent MPEG-1 streams that could support.
B = 1
MPEG-1 Experiment
QuickTime Experiment
-End