Upload
others
View
11
Download
0
Embed Size (px)
Citation preview
Securing Content Sharing over ICN
Nikos Fotiou, George C. [email protected], [email protected]
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