View
2
Download
0
Category
Preview:
Citation preview
Towards Name-based Trust and Security for Content-centric Network
By:
Xinwen Zhang, Guangyu Shi, GQ Wang, Huawei R&D, Santa Clara, CA
Katharine Chang, University of Michigan, Ann Arbor, MI
Huijun Xiong, Virginia Tech, Blacksburg, VA
Yonggang Wen, Nanyang Technological University, Singapore
Motivations
• Several Information Centric Network (ICN) architecture have been proposed for future Internet• Content-centric network (CCN) / named-data network (NDN)
• NetInf, PSIRP, DONA, …
• Security is a built-in feature in ICN• With the focus on content integrity and confidentiality
• Trust is a pre-requisite for security
• PKI-based trust management• Not very scalable
• S-BGP, soBGP, psBGP, SPV, …
• Certificate distribution/management is complex
• Deriving trust from key certificate is not efficient
Our Proposal
• Name-based trust and security• Leverage named content in network
• Deriving trust from existing infrastructures• Email, phone number, friend list, …
• Leveraging social/admin/owner relationships, …
• Identity-based signature (IBS) for content integrity verification• Identities as public keys
• Device id, content name/prefix, etc
• Reduce the complexity of public key certificate management
• Identity-based encryption (IBE) for content confidentiality• Flexible secure data dissemination
• No need to build a secure channel before content publish
IBC Algorithms
• A trusted entity: private key generator (PKG)• common trusted entity• but does not do certificate signing and key distribution
• id: a public identity as a string• Name, prefix, email, …
• (pb, pr): a public/private key pair generated from id
PKG: Setup: 1^k -> SP, MSK, (PKG publishes SP, and saves MSK)GeneratePrK: (id, MSK) -> pr_id
Sig: Sign: (m, id, pr_id) -> sVerify: (s, m, SP, id) -> true/false
Enc: Enc: (m, id, SP) -> cDec: (c, pr_id) -> m
Key Service(PKG)
Name Registration Service(NRS)
Extract(MSK, name) = pr_name
Publish(SP)
s = Sign(pr_name, m)Publish(m, name, s)
Verify(SP, name, m, s)
Subscribe(name)
GetPr(name)
RegisterName(name)
Data TransmissionSecure Channel Authenticated Channel
Content Network
SP=GetSP()
Name-based Signature for CON
5
pr_name
Setup( ) -> (MSK, SP)Setup( ) -> (MSK, SP)
pr_name
Name-based Encryption for CON
Publish(SP)
c=Encrypt(name, SP, m)Publish(c, name)
SP=GetSP
• m=Decrypt (c, pr_name)
Subscribe(name)
pr_name
Setup( ) -> (MSK, SP)Setup( ) -> (MSK, SP)
Data TransmissionSecure Channel Authenticated Channel
Extract(MSK, name) = pr_name
RegisterName(name)
GetPr(name)
pr_name
Key Service(PKG)
Name Registration Service(NRS)
Data Format
ccnx:/10‐digit‐phone‐number/loc sign_id TTL
enc_id: the target name prefix that can decrypt sign_id: the name prefix that used for signature verification pkg.sp: the SP of the PKG (or its hash) corresponding the name prefix sig: signed hash of the content name, metadata, and ciphertext.
pkg_sp sig
MetedataContent Name
Ciphertextenc_id
Data
A Hybrid Scheme: PKI + IBC
• Pure IBC is not scalable for Internet• Centralized PKG is not scalable• Secure distribution of private key can be an issue
• Should rely on some authentication mechanism• Authentication of PKG’s SP can be an issue
• May rely on another trust management infrastructure
• Proposal: a hybrid trust management scheme: PKI + IBC• PKG/NRS are domain/AS level services• Distribute private key within domain
• Each organization can implement its own key distribution, with authentication mechanisms• For example, in an enterpise, username/passwrod, Kerberos, IAM (LDAP/Active Directory)
• Distribute and verify SP with inter-domain PKI-based trust management• Domain level PKI is available actually:
• DNSSEC, IPSec, SSL, RPKI, etc• A content publisher or consumer only needs to trust a few PKI-CAs
Hybrid Scheme: PKI + IBC
• PKG/NRS are within domain/AS level• PKG issues private key for local names• PKG.SP is certified by PKI CA
• certificate management complexity:• Pure PKI: O(nxm)
• n - space of devices/users/hosts/services/names• m - space of domains
• Hybrid: O(m)
IBC is good for user/app/device/host/service level trust and securityWhile PKI is good for domain/AS level
Key Service
Key Service
Trust Authority
Trust Authority
Local names(users, contents, hosts, devices, users, apps,
services, …)
certify certify
Local names(users, contents, hosts, devices, users, apps,
services, …)
Name ServiceName
Service Key Service
Key Service
Name ServiceName
Service
Cert Authority
Cert Authority
Cert Authority
Cert Authority
Discussion
• Supporting flexible security policies:• Group signing
• Multiple signatures for single name
• With different prefixes
• Delegated signing
• Self PKG• Self-signed PKG.SP
• Good for P2P, social network, and ad-hoc network
• Private key revocation• Private key is built with timestamp augmented id
• Bob@huawei.com || Oct-2011
• React interests by generating content of location with name ccnx:/phone-number/loc• Encrypted with receiver’s phone-number• Signed with sender’s key• Pre-loaded to device SD card
• Periodically send interest for ccnx:/phone-number/loc
• Sig verification and decryption• Show location on map
Malicious CCNx client• Sniff location data • Publish fake location
ccndccnd
CCNx LAN
ccndAlice: SenderBob: Receiver
Implementation
• CCNx-Latitude: • A location sharing application on Android
• Over CCNx project
Alice BobInterest
name: ccnx:/1234567890/loc
Data
name: ccnx:/1234567890/locenc_id: 34569001 (Bob phone#)sign_id: 1234567890 (Alice phone#)
pkg_sp: ccnx:/latitude/pkgsig: Sign(Alice.SK, data)data: latitude: xxx, longitude: yyy
name: ATT/pbK_certsig: Sign(CA, ATT.pbK)content: xxxxxxxx (cert)
name: ccnx:/latitude/pkg/sp
name: ccnx/latitude/pkg/spsig: Sign(ATT.prK, Latitude.PKG.SP)content: xxxxxxx (Latidude.PKG.SP)
name: ccnx:/ATT/pbK_cert
CCNx-Latitude Protocols
CCN Network
ccnx:/10‐digit‐phone‐number/loc sign_id TTL
enc_id: Bob’s phone# sign_id: Alice’s phone# pkg.sp: the SP of the PKG corresponding the identity sig: IBS(Alice’s pr, ciphertext, Alice phone#)
pkg_sp sig
Data
Metedata
Phone number: 1234567890Latitude: 37373099 Longitude: -121964326
Content Name
Ciphertext
Ciphertext
Encryption
enc_id
Data
Content Name and Metadata
Signing & binding
pairing-based crypto libs: http://crypto.stanford.edu/pbc/
Evaluation
• Un-optimized implementation • Android 2.3
• Google Nexus S
• Java BF-IPC implementation: http://crypto.stanford.edu/pbc/
• BF-IBC is almost 10 times slower than RSA operations• Due to expensive paring operation
• But data size independent
• Performance improvement• key encapsulation mechanism
• IBE work on an AES key
• AES key is used for real data encryption
• For 5MB data, the performance is < 3% more than RSA
Conclusion
• We propose IBC for named content in ICN• Name/prefix as public key
• Good for CCN/NDN with user readable names
• IBS for content integrity and authenticity verification
• IBC for content encryption
• We propose a hybrid trust management scheme• IBC for intra-domain trust management
• PKI for inter-domain trust management
• We implement CCNx-Latitude for PoC: • CCNx proejct
• Secure and private location sharing with CCN
Ongoing and Future Work
• Booting trust for group communication in ICN• With hierarchical content names
• Group-based security for data sharing with ICN• Dynamic group memberships
• Multicast encryption
• Secure mobility in ICN• Enabling virtual group in ICN
• Secure routing in ICN
Recommended