SLIDE 1 Securing Content Sharing over ICN
Nikos Fotiou, George C. Polyzos
fotiou@aueb.gr, polyzos@acm.org
Mobile Multimedia Laboratory, Department of Informatics School of Information Sciences and Technology Athens University of Economics and Business 113 62 Athens, Greece
http://mm.aueb.gr/
SLIDE 2 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
– 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
SLIDE 3
BACKGROUND
SLIDE 4 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
SLIDE 5
Identity-based encryption
SLIDE 6 Identity-based encryption
System Parameters (SP) Public! (k) Master Secret Key
SLIDE 7
Identity-based encryption
SLIDE 8
Identity-based encryption
SLIDE 9
Identity-based encryption
SLIDE 10
Identity-based encryption
SLIDE 11 Proxy Re-Encryption
– 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
- r the secret keys of the user
SLIDE 12 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
SLIDE 13
Identity-based proxy re-encryption
SLIDE 14
Identity-based proxy re-encryption
SLIDE 15
Identity-based proxy re-encryption
SLIDE 16
SYSTEM DESIGN
SLIDE 18 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
SLIDE 19
First construction
SLIDE 20
First construction
SLIDE 21
First construction
SLIDE 22
Content request
SLIDE 23
Content request
SLIDE 24
Content request
SLIDE 25
Content request
SLIDE 26
Content request
SLIDE 27
Content request
SLIDE 28
Content request
SLIDE 29 We need trusted proxies
- … a malicious proxy can use a re-encryption
key no matter whether the user is authorized
- r not to access a content item
SLIDE 30 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
SLIDE 31
Second construction
SLIDE 32
Second construction
SLIDE 33
Second construction
SLIDE 34
Content request
SLIDE 35
Content request
SLIDE 36
Content request
SLIDE 37
Content request
SLIDE 38 Trust to proxies is relaxed
- … a re-encryption key can be used only for
authorized users
SLIDE 39 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
node
- > Possible privacy risk
- Secure the communication
channel
SLIDE 40 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
SLIDE 41 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
SLIDE 42
DISCUSSION
SLIDE 43 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
SLIDE 44 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
SLIDE 45
Thank you
fotiou@aueb.gr polyzos@acm.org
