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