Controlling Data Disclosure in Cross-domain Network Monitoring:

Challenges and Approaches

Giuseppe BianchiGiuseppe.bianchi@uniroma2.it

FP7 DEMONS Integrated Project – Scientific Coordinator

June 9, 2011 – PoFi Workshop, Pisa

Cross-domain data sharing

• Largely advocated; support for best addressing large scale cross-domain threats

• Botnet detection and mitigation• DDoS• …

• BUT: severe deployment issues• Business information protection• Customers’ privacy issues• Mismatches among trans-national regulation

DEMONS’ Project ChallengesTowards cross-domain cooperation

• Disclaimer - technologies alone are not sufficient• Cooperation means must address legal conflicts

– Data protection laws secure operation of network services

• Players must establish formal Sharing Agreements• Lack of (established/deployed) standards• Cooperation must be intensified by political will and support

• But technical approaches for securing and protecting cooperation and data sharing may foster cooperation

• As enablers, to build on top of

DEMONS’ two research directions(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

What we mean (layman example)

DOMAIN 2

DOMAIN 5DOMAIN 3 DOMAIN 4

DOMAIN 1

4 out of 5 domains report anomaly involving pxyz.biz pxyz.biz appears (to 4 out of 5 domains) involved in some sort

of botnet fast fluxing…Something strange with

domains pxyz.biz, base.com

Something strange with domains pxyz.biz, kristin.it Something strange with

domains pxyz.biz, alpha.org

Nothing strange today

Something strange with domain pxyz.biz

Share data related to pxyz.biz (data otherwise confidential) e.g. full list of end hosts accessing pxyz.biz, as these are likely bot share among ALL! Also Domain 2 should be made aware of this,

and Domain2’s pxyz.biz log helpful here as well!

DO NOT share any remaining log associated to other DNS namesAs this includes confidential/business data, and there is no

evidence for a global threat or cross-domain issue…

CONDITIONALLY SHARE only if (consistent) anomalies occur

Cooperative Conditionally Encrypted Data Sharing - concept

DOMAIN 2

Pxyz.bizAlpha.com

Beta.itGamma.net

… … … …

D2 logs

DOMAIN 5

Pxyz.bizAlpha.com

Beta.itGamma.net

… … … …

D5 logs

… … …DOMAIN 3

DOMAIN 4

Shared (encrypted) repositoryDOMAIN 1

Index Related log

Cooperative Conditionally Encrypted Data Sharing - concept

DOMAIN 2

Pxyz.bizAlpha.com

Beta.itGamma.net

… … … …

D2 logs

DOMAIN 5

Pxyz.bizAlpha.com

Beta.itGamma.net

… … … …

D5 logs

… … …DOMAIN 3

DOMAIN 4

Shared (encrypted) repositoryDOMAIN 1 Pxyz.biz

anomaly

Pxyz.bizanomaly

Pxyz.bizanomaly

Pxyz.bizanomaly

Cooperative Conditionally Encrypted Data Sharing - concept

DOMAIN 2

Pxyz.bizAlpha.com

Beta.itGamma.net

… … … …

D2 logs

DOMAIN 5

Pxyz.bizAlpha.com

Beta.itGamma.net

… … … …

D5 logs

… … …DOMAIN 3

DOMAIN 4

Shared (encrypted) repositoryDOMAIN 1

Technical hassles• LOTS of possible indexes/logs per name, per flow, … millions?!

forget explicit per-flow cooperation

• Symmetric encryption performance! To cope with potentially massive logs and potentially huge number

• Distinct encryption keys game over, otherwise (all might read) must automate key management…

• No trusted third party control unviable, not a real world stakeholder

• Looks like secret sharing, but.. who provides the secret? one secret? or one per index?! from secret(s) to independent per-domain & per-index keys: howto?

Proposed construction (at a glance)

• Asymmetric encryption of symmetric keys• Use ordinary symmetric cipher for logs (e.g. AES-128)• Deliver each per-log AES-key covered by asymmetric encryption• Problem becomes: how to escrow such encrypted AES-keys

• Pedersen’s Distributed Key Sharing• Setup “unknown” shared secret S among domains (verifiable SS)• Get to know related public value gS

• Boneh & Franklin’s Pairing-based Identity Based Encryption

• Use public value gS as public IBE key (no PKG needed, obviously)• Encrypt per-identity, where identity ID is the index of each log• Escrow private (per-identity) key by releasing shares of IDS

Details (1/5): Setup• Once-for-all Domain cooperation via Pedersen DKG

– Secret S generated• unique but unknown

to all

– Domain i only knows one share xi of it

– gS becomes public• gS = Pedersen’s

verification value with index 0

• Domains agree on non degenerate computable bilinear pairing:GG G1 finite cyclic groups order q

s.t.: e(ga, gb) = e(g,g)ab a,bZ, gG

S) of shareth -(j construct : EACH

key) (public construct : EACH

optional) -cation for verifiother all and(

)(:,

)(

j

sec

,2

,2,1,0

,0

,0

i ijj

aSj

abroadcast

i

iijj

ure

i

qt

itiiii

R

i

sxD

ggD

gD

jfsjDD

zazazaazfDDomain

i

i

Details (2/5): per-index encryption

• Index = arbitrary filtering key• DNS name, IP address, Flow tuple, etc

• Log = information associated to index• List of querying hosts, delivered packets, etc

• Cipher = symmetric = e.g., AES-128• Encrypt all log associated to index• Automated pseudorandom key generation (stateless)

one distinct key per index ID and per domain i:

Ki,ID=K(domain i, index ID)=PRF(Domain secret, ID)

Details (3/5): publish IBE encrypted per-index key

• Index identity: IDf= Hash(index name) over G

• Release in public (once per log):– gr r (pseudo)random

• Again, PRF trick to make it stateless

– Encrypted key = Ki,f e(gs, (IDf)r)= Ki,f e(g,IDf)rs

• Usual public key encryption: private key needed for decrypt– but none has it, at this stage

Details (4/5): release key share upon detected anomaly

• By construction, domain has a share xi of secret S

• For the “anomalous” index, domain i derives a per-index share: (IDf)xi

– Remember B&F IBE: (IDf)S is the private key for IDf

– (IDf)xi = (exponent) share of private IBE key

• When to release share: local anomaly detection mechanism (any appropriate to the scope at hands)– Example: DNS analysis fast-flux DNS candidate

Details (5/5): Escrow keys

• Anyone (in principle) in shared repository may collect shares

• When sufficient number of shares available, reconstruct IBE private key for IDf via (exponent) Lagrange interpolation

• Lagrange coeff. depending only upon domain indexes (known)

• Decrypt using usual pairing: e(gr, IDfs)=e(g, IDf)rs

)0(

1

)0()( kkkk xf

t

k

xf

Sf IDIDID

Discussion• Security: founded on B&F IBE provable security under private

key disclosure – Knowing private keys for a set of IDs does not permit to decrypt any

other ID

• Performance: slow pairing done once per index– Massive log encryption via fast ordinary AES-128 symmetric

• Scalability: automated (stateless) key generation, no maintenance

• Overhead@setup– Not critical, once-for-all– All remaining operation does NOT require any coordination– Rekeying: involves only symmetric keys, no DKG coordination

Issues & next steps

• Currently just “pure” threshold-based (t,n) approach• ongoing work: support more expressive access control (data

sharing) policies • Decrypt on the basis of more specific alerts (or different types of) from

selected subsets of domains

– generalize to monotone access structures via linear secret sharing schemes

– mutuate ideas/approaches from (decentralized) CP-ABE

• Proof-of-concept real-world monitoring use-case: long term target– Current candidate scenario: cooperative botnet detection;– Need to develop (complementary) DNS analysis for alert generation