Securing Content Sharing over ICN

Nikos Fotiou, George C. Polyzosfotiou@aueb.gr, polyzos@acm.org

Mobile Multimedia Laboratory, Department of Informatics

School of Information Sciences and TechnologyAthens University of Economics and Business

113 62 Athens, Greece

http://mm.aueb.gr/

At a glance

• We consider a network of storage nodes

interconnected using an ICN network

• Content owners store content items in storage nodes

in order to share them with subscribers

• We provide

– Content confidentiality using Identity-Based Encryption

– Low overhead per user using Proxy Re-Encryption

– Protection against malicious proxies

– Subscriber authentication and

– A novel form of storage node authentication

BACKGROUND

Identity-Based Encryption

• A public key encryption scheme in which an

arbitrary string can be used as a public key

• Keys are generated by a Private Key Generator

(PKG)

– Key escrow problem

Identity-based encryption

Identity-based encryption

System

Parameters

(SP)

Public!

(k)

Master Secret Key

Identity-based encryption

Identity-based encryption

Identity-based encryption

Identity-based encryption

Proxy Re-Encryption

• A semi-trusted proxy

– is allowed to alter a ciphertext

– encrypted with the public key of user A

– in a way that another user B can decrypt it

• The proxy learns nothing about the plaintext

or the secret keys of the user

Identity-based Proxy Re-Encryption*

* Our system uses M. Green, G. Ateniese, “Identity-Based Proxy Re-encryption,” in Applied Cryptography and

Network Security, Katz, J., Yung, M. (eds.), Lecture Notes in Computer Science, vol. 4521, pp. 288-306, 2007

Identity-based proxy re-encryption

Identity-based proxy re-encryption

Identity-based proxy re-encryption

SYSTEM DESIGN

Entities

Known

First construction

• Content owners encrypt items using

symmetric encryption and a key K

– Each item is encrypted with a different key

• Each key is encrypted using IBE with the

identity of the content owner as key

First construction

First construction

First construction

Content request

Content request

Content request

Content request

Content request

Content request

Content request

We need trusted proxies

• … a malicious proxy can use a re-encryption

key no matter whether the user is authorized

or not to access a content item

Second construction

• Content owners encrypt items using

symmetric encryption and a key K

– Each item is encrypted with a different key

• Each key is encrypted using IBE with the

name of the policy that protects the item

as key

Second construction

Second construction

Second construction

Content request

Content request

Content request

Content request

Trust to proxies is relaxed

• … a re-encryption key can be used only for

authorized users

Security properties

Does

• Content confidentiality is

protected

• If content confidentiality is

the only requirement then

no further mechanisms are

required

– Even if a subscriber lies about

his identity he won’t be able

to decrypt the file

Does NOT

• Authenticate subscribers

-> May result in unnecessary

transmissions, re-encryptions

• Authenticate the storage

node

-> Possible privacy risk

• Secure the communication

channel

-> Possible privacy risk

Endpoints authentication

and secure channel setup*

• It leverages existing IBE mechanisms

• It provides subscriber authentication

• It enables the creation of an ephemeral

symmetric encryption key

• It provides a proof that a storage node is

authorized to store a particular content item

* High level description

Endpoints authentication and secure

channel setup

• Let F be the name of a content item

• Content owner generates SKF and stores it in

the proxy

• A subscriber encrypts using IBE and F as key,

some D-H key exchange parameters

• Only “authorized” nodes are able to decrypt

the parameters and proceed with the D-H key

establishment

DISCUSSION

Performance considerations

Storage overhead

– size of SP: 2048 bits

– size of CID(key): 2048 bits

– size of re-encryption key: 3027 bits

Computational overhead

– encryption of key: 40 ms

– re-encryption key creation: 20 ms

– re-encryption of a ciphertext: 31 ms

– decryption of a ciphertext: 28 ms

Python-based implementation in a single core of an Intel i5-4440 3.1 GHz processor and

with 2GB of RAM with security equivalent to RSA 1024 bits and 128 bit symmetric keys

Per user PKG vs. (almost) Global PKG

Per user PKG

+ When a private key is lost

updating SP is enough

+ No key escrow

- Need for SP storage

- Need for SP resolution

– some keys share the same SP,

e.g., same owner keys

Global PKG

+ No need for SP retrieval

+ No need for SP storage

- When a private key is lost

identity needs to change

- Key escrow problem

Thank you

fotiou@aueb.gr

polyzos@acm.org