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/
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 Master Secret Key (k) System Parameters (SP) Public!
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 Does NOT • Content confidentiality is • Authenticate subscribers protected -> May result in unnecessary transmissions, re-encryptions • If content confidentiality is • Authenticate the storage the only requirement then node no further mechanisms are -> Possible privacy risk required • Secure the communication – Even if a subscriber lies about his identity he won’t be able channel to decrypt the file -> 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 SK F 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 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 Storage overhead Computational overhead – size of SP: 2048 bits – encryption of key: 40 ms – size of C ID (key): 2048 bits – re-encryption key creation: 20 ms – size of re-encryption key: 3027 bits – re-encryption of a ciphertext: 31 ms – decryption of a ciphertext: 28 ms
Per user PKG vs. (almost) Global PKG Per user PKG Global PKG + When a private key is lost + No need for SP retrieval updating SP is enough + No need for SP storage + No key escrow - When a private key is lost - Need for SP storage identity needs to change - Need for SP resolution - Key escrow problem – some keys share the same SP, e.g., same owner keys
Thank you fotiou@aueb.gr polyzos@acm.org
Recommend
More recommend
