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
Client 1

Client 2
Long haul
bottleneck
paths Client 3
source

Server bandwidth
(fan-out) is very Client N
limited

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
Client A1
Proxy A Client A2
Client A3

Client AN
Proxy B
source Client B1
Client B2
Client B3
Proxy P Client P1

Client P2 Client BN
Client P3

Client PN
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
Encrypt using client 1’s key
Client 1
Encrypt using clien
t 2’s key
Encryp Client 2
t using
c l i e nt
3’s key
source En
cry
pt
u sin Client 3
g c li
ent
N’
sk
ey

 Simple
Client N
 Source has very high workload.
not scalable.
Proxy Caching with Decrypted Content
Encrypt
with Client
Encrypt Proxy A A1’s key
Client A1
with
Proxy’s key
Encrypt
with Client
A2’s key
Decrypted
Content
source Client A2

 Simple
 Proxy’s storage is insecure, original content can be retrieved
by intruders
Proxy Caching with Encrypted Content
Proxy A
Encrypt
with Client A1
Proxy’s key

Client A2
source Encrypted
Content

Decrypt using proxy’s key

 Trivial Encrypt using clienti’s key
 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
Proxy

Intentionally
Corrupted
Content

source Part for reconstruction Client A1

(via secure channel)

 Protecting VoD the Easier Way,

Client A2
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
Proxy A
Encrypt
with Client A1
Proxy’s key

Client A2
source 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)
f(D-1, e0) f(D0, e1) f(D1, e2) f(DN-1, eN) f(DN, eN+1)
D-1 D0 D1 DN

f(D*0, e1*) f(D*1, e2)* * , eN*)

f(DN-1 f(D*N, eN+1
*)
D*1 DN*

 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
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, and
3. 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
D1
Video Proxy
e1 Client 1
D2
D-1 D0
e2 Client 2
e0

DN
source
eN Client N
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
Server Proxy
request request
authentication
and Ack(e1, n)
key generation
(e0, e1, d1, n, phi)
Data
encryption
D0(using e0)
caching or
relaying
 Operations between proxy and client
Server Proxy Client 1
request(eCert) Request
request(eCert)
Authentication and
key generation Ack(e1, [d1], n)
Ack([d1], n)
Data Retrieve d1
encryption D0(using e0)
Data
encryption Data
D1(using e1) decryption

eCert: public key in plaintext and public key encrypted by private

key
 Encryption Configuration Parameters
Packet 0 Packet 1 Packet 2 Packet 3
(1400 bytes) (1400 bytes) (1400 bytes) (1400 bytes)

Encryption block
Spkt = 1400 bytes, I = 2,
P = 0.5 and B = 4
Encryption sub-block
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
Server Proxy
SML_InitSession(); SML_InitSession();
SML_Accept(); SML_Connect();
SML_SendRps(); SML_ReceiveRps();
SML_SendEncryptRps(); StoreData();

Proxy Client
SML_InitSession(); SML_InitSession();
SML_ProxyAccept(); SML_ConnectProxy();
SML_SendRps(); SML_ReceiveRps();
ReadData(); SML_ReadDecryptRps();
SML_SendReEncryptRps();
Secure Multimedia Library - SML
 Client Code Example
SML_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 Example
SML_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 Parameters
P = 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

B=1
t = proxy throughput, M = Number of concurrent MPEG-1 streams that could support.
MPEG-1 Experiment
QuickTime Experiment
-End