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

THANKS!QA: xinwen.zhang@huawei.com