1 / 17

Controlling Data Disclosure in Cross-domain Network Monitoring : Challenges and Approaches

Controlling Data Disclosure in Cross-domain Network Monitoring : Challenges and Approaches. Giuseppe Bianchi Giuseppe.bianchi@uniroma2.it FP7 DEMONS Integrated Project – Scientific Coordinator June 9, 2011 – PoFi Workshop, Pisa. Cross-domain data sharing.

eilis
Download Presentation

Controlling Data Disclosure in Cross-domain Network Monitoring : Challenges and Approaches

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Controlling Data Disclosure in Cross-domain Network Monitoring:Challenges and Approaches Giuseppe Bianchi Giuseppe.bianchi@uniroma2.it FP7 DEMONS Integrated Project – ScientificCoordinator June 9, 2011 – PoFi Workshop, Pisa

  2. Cross-domain data sharing • Largelyadvocated; supportfor best addressinglarge scale cross-domain threats • Botnet detection and mitigation • DDoS • … • BUT: severe deploymentissues • Business information protection • Customers’ privacyissues • Mismatchesamongtrans-nationalregulation

  3. DEMONS’ Project ChallengesTowards cross-domain cooperation • Disclaimer - technologies alone are notsufficient • Cooperationmeansmustaddresslegalconflicts • Data protectionlaws secureoperationof network services • PlayersmustestablishformalSharingAgreements • Lackof (established/deployed) standards • Cooperationmustbeintensifiedbypoliticalwill and support • Buttechnicalapproachesforsecuring and protectingcooperation and data sharingmayfostercooperation • As enablers, tobuild on top of

  4. DEMONS’ tworesearchdirections(in the secure inter-domain cooperation area) • Tailor secure multiparty computation to network monitoring • SEPIA, P4P, lightweight approaches • Scalable, efficient, suitable for monitoring tasks (mostly additions) • Cooperative Conditionally Encrypted Data Sharing • Share (very selectively) data when anomalous events emerge in multiple domains • Similar alert in multiple domains  likely a large scale cross-domain threat  permit exchange of relevant data • this talk

  5. Whatwemean(laymanexample) DOMAIN 1 4 out of 5 domains report anomalyinvolvingpxyz.biz pxyz.bizappears (to 4 out of 5 domains) involved in some sortofbotnet fast fluxing… Somethingstrangewithdomainspxyz.biz, base.com Share data relatedtopxyz.biz (data otherwiseconfidential) e.g. full listof end hostsaccessingpxyz.biz, asthesearelikelybotshare among ALL! Also Domain 2 shouldbemadeawareofthis, and Domain2’s pxyz.biz log helpfulhereaswell! DOMAIN 2 Nothingstrangetoday DO NOT share anyremaining log associatedtoother DNS names As thisincludesconfidential/business data, and thereis no evidencefor a global threat or cross-domain issue… Somethingstrangewithdomainspxyz.biz, kristin.it Somethingstrangewith domain pxyz.biz DOMAIN 3 Somethingstrangewithdomainspxyz.biz, alpha.org DOMAIN 4 DOMAIN 5 CONDITIONALLY SHARE  onlyif (consistent) anomaliesoccur

  6. Cooperative ConditionallyEncrypted Data Sharing - concept Shared (encrypted) repository DOMAIN 1 Pxyz.biz DOMAIN 2 Alpha.com Beta.it D2 logs Gamma.net … ……… DOMAIN 3 … …… DOMAIN 4 Index Related log Pxyz.biz DOMAIN 5 Alpha.com Beta.it D5 logs Gamma.net … ………

  7. Cooperative ConditionallyEncrypted Data Sharing - concept Pxyz.biz anomaly Shared (encrypted) repository DOMAIN 1 Pxyz.biz DOMAIN 2 Alpha.com Beta.it D2 logs Gamma.net … ……… Pxyz.biz anomaly DOMAIN 3 … …… Pxyz.biz anomaly DOMAIN 4 Pxyz.biz DOMAIN 5 Alpha.com Pxyz.biz anomaly Beta.it D5 logs Gamma.net … ………

  8. Cooperative ConditionallyEncrypted Data Sharing - concept Shared (encrypted) repository DOMAIN 1 Pxyz.biz DOMAIN 2 Alpha.com Beta.it D2 logs Gamma.net … ……… DOMAIN 3 … …… DOMAIN 4 Pxyz.biz DOMAIN 5 Alpha.com Beta.it D5 logs Gamma.net … ………

  9. Technicalhassles • LOTS ofpossibleindexes/logs  per name, per flow, … millions?!  forgetexplicitper-flowcooperation • Symmetricencryption performance! Tocopewith  potentially massive logs  and potentiallyhugenumber • Distinctencryptionkeys  game over, otherwise (allmightread)  mustautomate key management… • No trustedthird party control  unviable, not a real world stakeholder • Lookslike secret sharing, but..  whoprovides the secret?  one secret? or one per index?!  from secret(s) toindependentper-domain & per-indexkeys: howto?

  10. Proposedconstruction (at a glance) • Asymmetricencryptionofsymmetrickeys • Useordinarysymmetriccipherforlogs (e.g. AES-128) • Delivereachper-logAES-keycoveredbyasymmetricencryption • Problembecomes: howtoescrowsuchencryptedAES-keys • Pedersen’s Distributed Key Sharing • Setup “unknown” shared secret S amongdomains (verifiable SS) • Gettoknowrelated public valuegS • Boneh & Franklin’s Pairing-basedIdentityBasedEncryption • Use public valuegSas public IBE key (no PKG needed, obviously) • Encryptper-identity, whereidentity ID is the indexofeach log • Escrow private (per-identity) key byreleasingsharesof IDS

  11. Details (1/5): Setup • Once-for-all Domain cooperation via Pedersen DKG • Secret S generated • uniquebutunknowntoall • Domain i onlyknowsone share xiofit • gSbecomes public • gS = Pedersen’sverificationvaluewithindex 0 • Domainsagree on non degenerate computablebilinearpairing: GG G1 finite cyclic groups order q s.t.:e(ga, gb) = e(g,g)aba,bZ, gG

  12. Details (2/5): per-indexencryption • Index = arbitraryfiltering key • DNS name, IP address, Flow tuple, etc • Log = information associatedtoindex • Listofqueryinghosts, deliveredpackets, etc • Cipher = symmetric = e.g., AES-128 • Encryptall log associatedtoindex • Automatedpseudorandom key generation (stateless)onedistinct key per index ID and per domain i: Ki,ID=K(domain i, index ID)=PRF(Domain secret, ID)

  13. Details (3/5): publish IBE encryptedper-index key • Indexidentity: IDf=Hash(indexname) over G • Release in public (once per log): • gr r (pseudo)random • Again, PRF tricktomakeitstateless • Encrypted key = Ki,f e(gs, (IDf)r)= Ki,f e(g,IDf)rs • Usual public key encryption: private key neededfordecrypt • butnone hasit, at this stage

  14. Details (4/5): release key share upondetectedanomaly • Byconstruction, domain has a share xiof secret S • For the “anomalous” index, domain i derives a per-index share: (IDf)xi • RememberB&F IBE: (IDf)S is the private key forIDf • (IDf)xi = (exponent) share of private IBE key • Whentorelease share: localanomaly detection mechanism (any appropriate to the scope at hands) • Example: DNS analysis fast-flux DNS candidate

  15. Details (5/5): Escrowkeys • Anyone (in principle) in sharedrepositorymaycollectshares • Whensufficientnumberofsharesavailable, reconstruct IBE private key forIDf via (exponent) Lagrangeinterpolation • Lagrange coeff. dependingonlyupon domain indexes (known) • Decryptusingusualpairing: e(gr, IDfs)=e(g, IDf)rs

  16. Discussion • Security: founded on B&F IBE provable security under private key disclosure • Knowing private keysfor a set ofIDsdoesnotpermittodecryptanyother ID • Performance: slow pairingdone once per index • Massive log encryption via fast ordinary AES-128 symmetric • Scalability: automated (stateless) key generation, no maintenance • Overhead@setup • Notcritical, once-for-all • Allremainingoperationdoes NOT requireanycoordination • Rekeying: involvesonlysymmetrickeys, no DKG coordination

  17. Issues & nextsteps • Currently just “pure” threshold-based (t,n) approach • ongoing work: support more expressiveaccesscontrol (data sharing) policies • Decrypt on the basisofmore specificalerts (or differenttypesof) fromselectedsubsetsofdomains • generalizeto monotone accessstructures via linear secret sharingschemes • mutuate ideas/approachesfrom (decentralized) CP-ABE • Proof-of-conceptreal-worldmonitoringuse-case: long term target • Current candidate scenario: cooperative botnet detection; • Needtodevelop (complementary) DNS analysisforalert generation

More Related