1 / 39

MARKS: Zero side-effect M ulticast key mgmt using A rbitrarily R evealed K ey S equences

MARKS: Zero side-effect M ulticast key mgmt using A rbitrarily R evealed K ey S equences. Bob Briscoe BT Research 7 Nov 1999. context. key mgmt: the problem. member. time. context. application data unit (ADU). wrt security/charging.

yagil
Download Presentation

MARKS: Zero side-effect M ulticast key mgmt using A rbitrarily R evealed K ey S equences

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. MARKS:Zero side-effect Multicast key mgmt usingArbitrarily Revealed Key Sequences Bob Briscoe BT Research 7 Nov 1999

  2. context key mgmt: the problem member time

  3. context application data unit (ADU) wrt security/charging see taxonomy of large-scale multicast requirements [Bagnall] MARKS; (c) British Telecommunications plc 1999

  4. context key mgmt: ADUs member time

  5. context m'cast key mgmt: state of the art • not suitable for large-scale deployment • re-keying traffic rate of same order as join/leave rate • re-keying requires reliable multicast • hence Internet research task force, not IETF • MARKS: redefine problem • arbitrary eviction, but pre-planned • mainly commercial scenarios (pre-pay)e.g. pay-per-view-TV, usage-charged network games • zero side-effect on other receivers and sender • one small unicast set up message per session MARKS; (c) British Telecommunications plc 1999

  6. solution lateral thinking member time

  7. solution loose coupling to senders multicast data R KM unicast set-up S R R S R KM S R sender S R KM receiver R KM key manager reliable multicast keying not req'd MARKS; (c) British Telecommunications plc 1999

  8. solution two blinding functions from one s0,0 r0 r1 b b b0 b1 s1,0 s1,1 MARKS; (c) British Telecommunications plc 1999

  9. solution indexing arranged so even  left min=3 max=9 binary hash tree s0,0 b0 b1 s1,0 s1,1 s2,0 s2,1 s2,2 s2,3 s3,0 s3,1 s3,2 s3,3 s3,4 s3,5 s3,6 s3,7 s4,0 = k0 s4,1 = k1 s4,2 = k2 s4,3 = k3 s4,4 = k4 s4,5 = k5 s4,6 = k6 s4,7 = k7 s4,8 = k8 s4,9 = k9 s4,10 = k10 s4,11 = k11 s4,12 = k12 s4,13 = k13 s4,14 = k14 s4,15 = k15

  10. solution algorithm to reveal intermediate seeds for(d=D; ; d--) { // working from leaves... // move up tree 1 level ea loop if (min == max) { // min & max have converged... reveal(d,min); // ...so reveal sub-tree root.. break; // ...and quit } if odd(min) { // odd min never left child... reveal(d,min); // ...so reveal odd min seed min++; // and step min in 1 to right } if !odd(max) { // even max never right child.. reveal(d,max); // ...so reveal even max seed max--; // and step max in 1 to left } if (min > max) break; // min & max cousins, so quit min/=2; // halve min ... max/=2; // ... & halve max ready for... } // ... next level round loop MARKS; (c) British Telecommunications plc 1999

  11. solution BHT - per ADU key calculation s0,0 b0 b1 s1,0 s1,1 s2,0 s2,1 s2,2 s2,3 s3,0 s3,1 s3,2 s3,3 s3,4 s3,5 s3,6 s3,7 s4,0 = k0 s4,1 = k1 s4,2 = k2 s4,3 = k3 s4,4 = k4 s4,5 = k5 s4,6 = k6 s4,7 = k7 s4,8 = k8 s4,9 = k9 s4,10 = k10 s4,11 = k11 s4,12 = k12 s4,13 = k13 s4,14 = k14 s4,15 = k15

  12. solution BHT processing efficiency • receiver & sender: (mean no. of hashes per key) = (no. of branches) / (no. of leaves) = (2(D+1) - 1) / 2D < 2 • key manager: • it depends... • store all intermediate seeds, or cache & re-hash? MARKS; (c) British Telecommunications plc 1999

  13. solution BHT efficiency independent of n, #rcvrs truly zero side effect N: length of the range of keys req'd ws: size of seed (typically 128b) wh: KM protocol header overhead ts: processor time to blind a seed MARKS; (c) British Telecommunications plc 1999

  14. solution BHT security • as secure as the chained hash function • max attacker gain • doubles accessible value / hash • 1025 years for lone attacker? • …collusion or arbitrage far easier • usual caveats about due care: • randomness of seed • security of announcements and set up messages • (SDP & SSL-based example in paper) MARKS; (c) British Telecommunications plc 1999

  15. variants variations • multi-sender multicast • all use same seeds - network game example in paper • combination with other schemes • storage/complexity costs sum of combined schemes • bandwidth cost of each only when necessary • unplanned eviction • (BHT aux. keys) XOR (Chang99 aux. keys) • but lose advantage of decoupling • watermarking... MARKS; (c) British Telecommunications plc 1999

  16. summary limitations • receiver collusion & arbitrage • (strength of hash chain of length D)= D(hash strength)? MARKS; (c) British Telecommunications plc 1999

  17. audit trail watermark without smartcard? Chameleon [Anderson97] long-term watermarked key block watermarks secondary keys - XOR cipherstream partial flaw: no protection against leaks to recent group members variants sto len MARKS; (c) British Telecommunications plc 1999

  18. summary wider context • valid non-multicast scenarios for MARKS • DVD: digital video disk • VPN: virtual private network • dynamic stack creation • Flexinet, Mware • software engineering rather than protocol engineering (SMuG) frameworks (longer term focus) • cover reliable multicast, unicast etc. • declarative: cf. LSMA requirements taxonomy 'RFC'draft-ietf-lsma-requirements-04.txt MARKS; (c) British Telecommunications plc 1999

  19. summary summary • no limit on MARKS scalability • completely decoupled • esp. if scenario allows stateless key manager replication • extremely low set up and running costs • no (reliable) multicast re-keying • arbitrary eviction • unplanned far more difficult than planned • cost difference worth business model distortion • can usefully combine planned & unplanned MARKS; (c) British Telecommunications plc 1999

  20. summary where now? • current plan • license technology in short term? • will fit into SMuG framework • public domain & standardise medium term? • is SMuG chartered for RFCs on mechanisms? MARKS; (c) British Telecommunications plc 1999

  21. more info further information • Mware project • http://www.labs.bt.com ...… /projects/mware/ • this presentation and paper • … /people/briscorj/papers.html#MARKS • Bob Briscoe • … /people/briscorj/ • Flexinet • http://www.ansa.co.uk/ common model MARKS; (c) British Telecommunications plc 1999

  22. variants bi-directional hash chain v0,0  vG,1 = k0 v2,0  vG-2,1 = k2 … vm,0  vG-m,1 = km … vi,0  vG-i,1 = ki … vn,0  vG-n,1 = kn … vG-1,0  v1,1 = kG-1 vG,0  v0,1 = kG v1,0  vG-1,1 = k1 … … … … v0,0 v1,0represents v(1,0) = b(v(0,0)) v0,0 vG,1 = k0represents k0 = c( v(0,0) , v(G,1) ) MARKS; (c) British Telecommunications plc 1999

  23. variants continuous BHT D0 M

  24. variants s0,0 s0,1 s0,2 b) s1,0 s1,1 s1,2 s1,3 hash chain-tree hybrid element s0,0  v1,1 = s1,0 s0,1  v1,0 = s1,1 s0,1  v1,2 = s1,2 s0,2  v1,1 = s1,3 a) s0,0 v1,0represents v(1,0) = b( s(0,0) ) s0,0 v1,1 = s1,0represents s(1,0) = c( s(0,0) , b( s(0,1) ) )

  25. variants hash chain-tree hybrid s0,0 s0,1 s0,2 s1,1 s1,2 s1,3 s1,0 s2,0 s2,1 s2,2 s2,3 s2,4 s2,5 s3,0 s3,1 s3,2 s3,3 s3,4 s3,5 s3,6 s3,7 s3,8 s3,9 s4,0 = k0 s4,1 = k1 s4,2 = k2 s4,3 = k3 s4,4 = k4 s4,5 = k5 s4,6 = k6 s4,7 = k7 s4,8 = k8 s4,9 = k9 s4,10 = k10 s4,11 = k11 s4,12 = k12 s4,13 = k13 s4,14 = k14 s4,15 = k15 s4,16 = k16 s4,17 = k17 MARKS; (c) British Telecommunications plc 1999

  26. variants hash chain-tree hybrid s0,1 s0,0 s0,2 s1,1 s1,2 s1,0 s1,3 s2,0 s2,1 s2,2 s2,3 s2,4 s2,5 s3,0 s3,1 s3,2 s3,3 s3,4 s3,5 s3,6 s3,7 s3,8 s3,9 s4,0 = k0 s4,1 = k1 s4,2 = k2 s4,3 = k3 s4,4 = k4 s4,5 = k5 s4,6 = k6 s4,7 = k7 s4,8 = k8 s4,9 = k9 s4,10 = k10 s4,11 = k11 s4,12 = k12 s4,13 = k13 s4,14 = k14 s4,15 = k15 s4,16 = k16 s4,17 = k17

  27. variants BHC-T per ADU key calculation s0,1 s0,0 s0,2 s1,1 s1,2 s1,0 s1,3 s2,0 s2,1 s2,2 s2,3 s2,4 s2,5 s3,0 s3,1 s3,2 s3,3 s3,4 s3,5 s3,6 s3,7 s3,8 s3,9 s4,0 = k0 s4,1 = k1 s4,2 = k2 s4,3 = k3 s4,4 = k4 s4,5 = k5 s4,6 = k6 s4,7 = k7 s4,8 = k8 s4,9 = k9 s4,10 = k10 s4,11 = k11 s4,12 = k12 s4,13 = k13 s4,14 = k14 s4,15 = k15 s4,16 = k16 s4,17 = k17

  28. variants hash chain-tree twist s0,1 = v1,0  s1,1 s0,0  v1,1 = s1,0 MARKS; (c) British Telecommunications plc 1999

  29. variants hash chain-tree hybrid growth 10 9 6 5 11 3 2 7 12a 12b 0 1 4 8a 8b 13a 13b 13c 13d MARKS; (c) British Telecommunications plc 1999

  30. variants continuous hashchain-tree 2M M M

  31. variants revealing and blinding pairs in BHC-T s0,0 s0,1 s1,1 s1,2 MARKS; (c) British Telecommunications plc 1999

  32. variants s0,0 s0,1 s0,2 b) s1,0 s1,1 s1,2 s1,3 hash chain-tree hybrid II element s0,0 v1,0  v1,2 = s1,0 s0,1 v1,3  v1,1 = s1,1 s0,1 v1,2  v1,4 = s1,2 s0,2 v1,5  v1,3 = s1,3 b1 b1 b0 b0 b1 b1 b0 b0 a) b0 s0,0 v1,0represents v1,0 = b0(s0,0) b1 s0,0 v1,1represents v1,1 = b1(s0,0) v1,0  v1,2 = s1,0represents s1,0 = c(b0(s0,0), b0(s0,1))

  33. variants revealing and blinding pairs in BHT2 s0,0 s0,1 s1,1 s1,2 MARKS; (c) British Telecommunications plc 1999

  34. variants common model • general form • two co-ordinate planes • blinding • combining • tree 'molecules' in blinding plane • molecule leaves map down into combining plane • results mapped back into blinding plane • next blinding molecule starts • 3 general mapping formulae • expressions specialise formulae for each scheme MARKS; (c) British Telecommunications plc 1999

  35. variants j 5 BHT2 4 3 2 b1 1 b0 b1 0 0 v(h, j) b0 i 1 4 2 3 3 h 2 4 1 0 s(d, i) 0 1 d MARKS; (c) British Telecommunications plc 1999 2

  36. variants j BHT 4 3 2 1 b1 0 0 v(h, j) b0 i 1 2 3 h 2 4 1 0 s(d, i) 0 1 d MARKS; (c) British Telecommunications plc 1999 2

  37. variants BHC j 2 v(h, j) 1 0 0 i 5 1 4 2 3 3 h 4 2 s(d, i) 1 0 0 MARKS; (c) British Telecommunications plc 1999 d 1

  38. variants j 5 BHC-T 4 3 2 1 0 0 v(h, j) i 1 4 2 3 3 h 2 4 1 0 s(d, i) 0 1 d MARKS; (c) British Telecommunications plc 1999 2

  39. variants j 4 BHC3-T 3 v(h, j) 2 1 0 i 0 5 1 4 2 3 3 h 4 2 5 1 0 s(d, i) 1 d MARKS; (c) British Telecommunications plc 1999 2

More Related