1 / 69

Key Recovery Using Noised Secret Sharing with Discounts Over Large Clouds

Key Recovery Using Noised Secret Sharing with Discounts Over Large Clouds. Sushil Jajodia 1 , W. Litwin 2 & Th. Schwarz 3.

gzifa
Download Presentation

Key Recovery Using Noised Secret Sharing with Discounts Over Large Clouds

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. Key Recovery Using Noised Secret Sharing with DiscountsOver Large Clouds Sushil Jajodia1, W. Litwin2&Th. Schwarz3 1George Mason University, Fairfax, VA {jajodia@gmu.edu}2Université Paris Dauphine, Lamsade{witold.litwin@dauphine.fr}3Thomas Schwarz, UCU, Montevideo {tschwarz@ucu.edu.uy}

  2. What ? • New schemes for an encryption key recovery • Lost key is always recoverable in practical time • From a specifically encrypted backup • UsingaNoisedSecret Sharing Scheme (NS) • Weproposedsuchschemes in 2012

  3. What ? • The schemes guaranteed • Recoverability in practical time of any key backed up using an NS-scheme • E.g. in 10 min max • But only provided a large cloud 1K – 1M nodes

  4. What ? • Such a cloud is a scarce & usually external resource • Possibly expensive & hard to use illegally • Money trail, traces in many logs… • The constraint should make backup disclosure attempt rare • But not impossible

  5. What ? After all, there is also no guarantee that someone does not pass a red light right on you Never mind, you still move around, don’t you ? 2. The schemes guaranteed also the absence of any other scheme recovering the key faster than the NS-scheme on the same cloud

  6. What ? • We now enhance the proposed schemes: • Key owner escrowing the key backup may retain a secret discount (code) • Discounted recovery may be orders of magnitude less complex than the full-cost (brute force) recovery • The only possibility for 2012 schemes • E.g. 256 times less complex for 1B code

  7. What ? • Less complex means: • Less computations all together • Faster recovery on the same cloud • E.g. 256 times for 1B code • Smaller cloud for the same time • E.g. 256 times for 1B code • In every case, cheaper in cloud cost • E.g. up to 256 times for 1B code

  8. What ? We present schemes for discounted recovery These naturally allow also the full-cost recovery But even if this case, these are not the same schemes as our earlier ones

  9. Why • Currently, it’s better to encrypt the outsourced data • Using client-side encryption • See news • Especially Big Data • If you count on server-side encryption: good luck • Also see news

  10. Why • You may also enjoy songs about privacy • By renowned CS Prof Th. Imielinski(Rutgers U) • http://www.system-crash.com/mp3/09-System%20Crash%20_%20Privacy.mp3 • http://www.system-crash.com/mp3/HackersRevenge/05_SystemCrash_HackersRevenge_WeWillForgiveYourFuture.mp3

  11. Why • Key loss danger is Achilles’ heel of modern crypto • Makes many folks refraining of any encryption • With occasionally known disclosure consequences • Other loose many tears if unthinkable happens

  12. Why • Frequent causes of key loss • Corrupted or lost memory & no backup • Sad loss of the key owner with all her/his secrets • Disgruntled employee departed with the key & backups

  13. Why • Frequent causes of key disclosure • Hacking of one among many (simple) backup copies at owner’s site • Sad loss of the key owner with all her/his secrets • Disgruntled employee departed with the key & backups

  14. Why • Frequent causes of key disclosure • Dishonest super-user / system administrator • Mandatory escrow of any key copy in many companies • Insider attack within an escrow service

  15. Why • Frequent consequences of key loss • Valuable company data • Possibly years of work by many people • Unpublished valuable manuscripts • Personally known case • Possibly critical personal health data • Time-series of CAT Scans, ECGs, Blood analysis, med. treatments…

  16. Why • Frequent consequences of key disclosure • Listen to news

  17. How ?Backup Encryption • Client (Key owner) X backs up encryption key K • X estimates 1-node inhibitive recovery timeD • Say 70 days • D measures trust to Escrow • Lesser trust ? • Choose 700 days

  18. Client SideEncryption • D determines minimal cloud size N for future recovery in any acceptable calculus time R • Chosen by recovery requestor • E.g. 10 min • X expects N > D / R but also N D / R • E.g. N 10K for D = 70 days • N 100K for D = 700 days

  19. Client SideEncryption • X creates a classical shared secret for K • Sees K as a large integer, • E.g., 256b long for AES • Basically, X creates a 2-share secret • Share s0 is a random integer • Share s1 is s1 = s0XOR K • Common knowledge: • K = s0XOR s1

  20. Client SideEncryption • X transforms the shared secret into a noised one • X makes s0 a noised share : • Chooses a 1-way hash H • E.g. SHA 256 • Computes the hint h = H (s0) • Chooses the noise space I = 0,1…,m,…M-1 • For some large M determined as we explain soon

  21. Client-SideEncryption • Each noise m and s0 define a noise share s • In a way we show soon as well • There are M different pseudo random noise shares • All but one are different from s0 • But it is not known which one is s0 • The only way to find for any s whether s =s0is to attempt the match H (s) ?= h

  22. NoisedSecret Sharing

  23. Client Side Encryption • Xestimates the 1-node throughputT • # of match attemptsH (s) ?= h per time unit • 1 Sec by default • X sets M toM = Int (DT). • M maybeexpected240 ÷ 250 in practice • M determines the worst-case and the averagecomplexity of the recovery • RespectivelyO(M) and O(M / 2) • As wewill show

  24. Client SideEncryption X formsbase noisesharef =p | 0  Hides the noisedshare as s0n= (f, M, h) in its noise share space [f, f+ M[ Sends the noised shared secret S’ = (s0n, s1) to Escrow as the key backup

  25. Client Side Encryption : Discount Code X may define some discount code d Basically, d is the m – bit suffix of s0 In practice, we expect m = 8, 16. Represented in ASCII or Unicode d is then simply one or two digits, e.g., ‘j’. X retains d secretlyfor future recovery request(or)

  26. Discount Code Action • 2m times reduced noise space I ; M’ = M / 2m • 2mtimesreduced noise share space S’

  27. Escrow-Side Recovery (Backup Decryption) • Escrow E receives legitimate request of S recovery in time R at most • E sends data S” = (s0n, R) to some cloud node C with request for processing accordingly • Keeps s1 out of the cloud • C willchoose between static or scalable recovery schemes

  28. Recovery Processing Parameters • Node load Ln : # of noises among M assigned to node n for match attempts • ThroughputTn: # of match attempts node n can process / sec • Bucket (node) capacity Bn: # of match attempts node n can process / time R • Bn = R Tn • Load factor n = Ln /Bn

  29. t Node Load α L 1 R B L B B L 1 T T T Overload Normal load Optimal load

  30. Recovery Processing Parameters • Notice the data storage oriented vocabulary • Node n respects R iffn ≤ 1 • Assuming T constant during the processing • The cloud respects R if for every n we haven ≤ 1 • This is our goal • For both static and scalable schemes we now present

  31. StaticScheme • Intended for a homogenous Cloud • All nodes provide the same throughput

  32. StaticScheme Full-CostRecoveryInit Phase • Node C that got S” from E becomes coordinator • Calculates a (M) = M/ B (C) • Usually  (M)>> 1 • Defines N asa (M) • Implicitly considers the cloud as homogenous • E.g., N = 10K or N = 100K in our ex.

  33. StaticScheme Full-CostRecoveryMap Phase • C asks for allocation of N-1 nodes • Associates logical address n = 1, 2…N-1 with each new node & 0 with itself • Sends out to every node n data (n, a0, P) • a0 is its own physical address, e.g., IP • P specifies Reduce phase

  34. StaticScheme Full-CostRecoveryReduce Phase • P requests node n to attempt matches for every noise share s = (f + m) such that n = m mod N • In practice, e.g., while m < M: • Node 0 loops over noise m = 0, N, 2N… • So over the noise shares f, f + N, f +2N… • Node 1 loops over noise m = 1, N+1, 2N+1… • ….. • Node N – 1 loops over m = (your guess here)

  35. Static Scheme : Node Load for Full Cost Recovery M …….. f + 2N f + N f …….. f + 2N + 1 f + N + 1 f + 1 …….. f + 2N + 2 f + N + 2 f + 2 …….. f + 3N - 1 f + 2N - 1 f + N - 1 α t, L R, B 1 1 T 0 1 2 N - 1

  36. StaticScheme : Termination • Node n that gets the successful match sends s to C • Otherwise node n locally terminate • C asks every node to terminate • Details depend on actual cloud • C forwards s as s0 to E

  37. StaticScheme : Termination • E discloses the secret S and sends S to Requestor • Bill included (we guess) • E.g.,up to400$ on CloudLayer for • D = 70 days • R = 10 min • Both implied N = 10K with private option

  38. StaticScheme • Observe that N ≥ D / R and N  D / R • If the initial estimate of T by S owner holds • Observe also that for every node n, we have • (n)≤ 1 • Provided the initial estimate of T by C holds in time

  39. StaticScheme • Under above assumptions maximal recovery time is indeed R • See the papers for details • Average recovery time is R / 2 • Every noise share is indeed equally likely to be the lucky one

  40. Static Scheme : Discounted Recovery • m < M’ = M / 2m : mis bit length of d M’ M’ M’

  41. StaticScheme: DiscountedRecovery If full-cost recovery needs 10K nodes for R = 10 min max. recovery calculus time and m = 8 then: The 10 min max. recovery requires only 40 – node wide cloud The 10K – node wide cloud suffices for R = 2.3 sec 1K cloud suffices for the recovery time up to 25 sec Etc

  42. StaticScheme • See papers for • Details, • Numerical examples • Proof of correctness • The scheme really partitions I • Whatever is N and s0,one and only one node finds s0

  43. StaticScheme • Safety • No disclosure method can in practice offer the (1-node) calculus faster than the scheme • Dictionary attack, inverted file of hints… • Otherproperties

  44. ScalableScheme • Heterogeneous cloud • Throughput may differ among the nodes

  45. ScalableScheme • Intended for heterogenous clouds • Different node throughputs • Basically only locally known • E.g. • Private or hybrid cloud • Public cloud without so-called private node option

  46. ScalableScheme Each node n : n = 0,1… recursively splits its load through hash partitioning Until its load factor n decreases to n ≤ 1 See our previous papers for details

  47. ScalableScheme • Init phase similar up to  (M) for full cost or  (M’) for discounted recovery calculus • Basically  (M) and  (M’) >> 1 • Also we note it now 0 • If  > 1we say that node overflows • Node 0 sets then its level j to j = 0 and splits • Requests node 2j = 1 • Sets j to j = 1 • Sends to node 1, (S”, j, a0)

  48. ScalableScheme • As result • There are N = 2 nodes • Both have j = 1 • Node 0 and node 1 should each process M / 2 match attempts • We show precisely how on next slides • Iff both 0 and 1 are no more than 1 • Usually it should not be the case • The splitting should continue as follows

  49. ScalableScheme • Recursive rule • Each node n splits until n ≤1 • Each split increases node level jn to jn+ 1 • Each split creates new node n’ = n + 2jn • Each node n’ gets jn’ = jninitially • Node 0 splits thus perhaps into nodes 1,2,4… • Until 0 ≤1 • Node 1 starts with j= 1 and splits into nodes 3,5,9… • Until 1 ≤1

  50. ScalableScheme • Node 2 startswithj = 2 and splitsinto 6,10,18… • Until2≤1 • Yourgeneralrulehere • Node with smaller T splits more times and vice versa

More Related