Recoverable Encryption through Noised Secret over Large Cloud
Recoverable Encryption through Noised Secret over Large Cloud
Sushil Jajodia1, W. Litwin2 & Th. Schwarz3
1George Mason University, Fairfax, VA {[email protected]}2 Presenter, Universit Paris Dauphine, Lamsade {[email protected]}3Thomas Schwarz, UCU, Montevideo {[email protected]}1
Welcome messageWhat ?New schemes for encryption key backup at Escrows siteBack up of high quality encryption keysE.g. AES (256b)Brute-force recovery intentionally possibleIn the absence of key creator (owner)But only over a large cloud10K+ nodes Thus not at Escrows own site2What ?Legal recovery can be fastE.g. Max 10 min on 10K-node cloudOnce all nodes are availableUnwelcome recovery is unlikelyE.g. 70 days at escrows processor Illegal use of 10K-nodes is implausibleCloud providers do everything they can againstEasily traceable if happens
3WhyHigh quality key loss danger is Achilles heel of modern cryptoMakes many folks refraining of any encryptionOther loose many tears if unthinkable happensThe schemes should benefit numerous applications4HowKey owner chooses inhibitive timing of 1-node (brute-force) recovery Presumably unwelcome at escrows own siteE.g. 70 daysConsequently , fixes a large integer M called backup decryption complexityCreates the backup as 2-share noised secretOne actual share of a noised secret is hidden among a large number of fake noise sharesSends the backup to Escrow 5HowKey requestor asks Escrow to recover data in acceptable max recovery time ROnce all requested nodes are available E.g. R = 10 minEscrow sends R and the noised share (within the noise) to the cloudThe cloud cannot disclose the keyRENS scheme at the cloud partitions the recovery calculation over the cloudTo fit the timing for sure Say partitions it over 10K nodes6HowThe cloud reports back to Escrow the actual share(s)Escrow recovers the key from both sharesClasical XORing Send the recovered key to RequestorNot forgetting the bill E.g. 150$ at Amazon for 10K-node wide EMR calculus (mid-2012)7What Else ?Client Side EncryptionServer Side RecoveryStatic SchemeScalable SchemeRelated WorkConclusion
Details in Res. Rep. :http://www.lamsade.dauphine.fr/~litwin/Recoverable%20Encryption_10.pdf8Client Side EncryptionClient X backs up key SX estimates 1-node inhibitive time DSay 70 daysD depends on trust to EscrowD also determines minimal cloud size N for future recovery in any time acceptable time R Fixed by recovery requestorE.g. 10 min X expects N > D / R9Client Side Key EncryptionX creates a shared secret for SBasically 2-share secret with share s0 random and s1 = s0 XOR S Common knowledge S = s0 XOR s1 X transforms the secret into a noised oneX makes s0 a noised share in noise space I = 0,1M-1For some M that X chooses as follows M is Encryption Complexity10Shared Secret / Noised (Shared) Secret11=SS0XORS=S0XORNoise sharesNoise sharesNoised shareNoise in IHint H (s0)S1S1H is one way hashSHA 256 by defaultClient Side EncryptionChoice of Encryption ComplexityX determines throughput T # of match attempts H (s) ?= h = H (s0) per time unit1 Sec by defaultX sets M to M= Int(DT). M= 240 250 in practice12Client Side EncryptionX randomly chooses m I = [0,1M[Calculates base noise share f = s0 mCreates noised share s0n = (f, M, h). Sends backup S = (s0n, s1) to Escrow
13Escrow Side RecoveryEscrow E receives legitimate request of S recovery in time R at mostE chooses either static or scalable schemeE sends data S=(s0n, R) to some cloud node with request for processing accordinglyKeeps s1 out of the cloud 14Static SchemeNode Load Ln : # of noises among M assigned to node n for match attemptsThroughput Tn : # of match attempts node n can process / secBucket (node) capacity Bn : # of match attempts node n can process / time RBn = R TnLoad factor n = Ln / Bn15Static SchemeNotice our data storage oriented vocabularyObserve that node n respects R iff n 1Observe that the cloud respects R iff for every n we have n 1This is true for both static and scalable scheme presented later on
16Static SchemeInit PhaseNode C that got S from E becomes coordinator Calculates a (M) = L (M) / B (C) Usually (M) >> 1Defines N asa (M) Implicitly considers the cloud as homogenous
17Static Scheme18Intended for a homogenous CloudAll nodes provide the same throughput
Static SchemeMap PhaseNode C asks for allocation of N-1 nodes Associates logical address n = 1, 2N-1 with each node & 0 for itselfSends out for each node n data (n, a0, P) a0 is its own physical address, e.g., IPP specifies Reduce phase19Static SchemeReduce PhaseP requests node n to attempt matches for every noise share s = (f + m) such that n = m mod NIn practice, e.g., while m < M: Node 0 loops over m = 0, N, 2NNode 1 loops over m = 1, N+1, 2N+1..Node N 1 loops over m = (you guess) 20Static SchemeNode n that gets the successful match sends s to COtherwise node n enters Termination C asks every node to terminate Details depend on actual cloud C forwards s as s0 to E21Static SchemeE discloses the secret S and sends S to Requestor Bill includedE.g., up to 400$ on CloudLayer for D = 70 daysR = 10 min Both implied N = 10K with private option
22Static SchemeObserve N D / R and N D / R If the initial estimate of T by key owner holdsAverage recovery time on the lucky node is R / 2 Since every noise is equally likely to be the lucky oneIndividual cost can be offset by key insurance servicePerhaps 4$/y per key per subscriber in our ex., i.e., peanuts.Assuming 1% of clients performs actual recovery per year 23Static SchemeSee Res. Report for details, i.e.,Numerical examples CorrectnessThe scheme really partitions I.Whatever is N and s0, one and only one node finds s0 Average recovery time is R/224Static Scheme SafetyNo disclosure method can in practice be faster than the schemeDictionary attack, inverted file of hintsOther properties
25Scalable SchemeIntended for heterogenous clouds different node throughputs basically only locally known E.g. Private or hybrid cloudPublic cloud without so-called private node option 26Scalable SchemeHeterogeneous cloudNode throughputs may differ27
Scalable SchemeInit phase similar up to (M) calculus Basically (M) >> 1 Also we note it now 0IIf > 1 we say that node overflowsNode 0 sets then its node level j to j = 0 and splits Requests node 2j = 1 Sets j to j=1 Sends to node1, (S, j, a0) 28Scalable SchemeAs result There are N = 2 nodesNode 0 and node 1 have each M / 2 match attempts to process Iff both load factors are no more than 1Usually it would not be the case29Scalable SchemeRecursive distributed rule Each node n splits until n 1 Each split increases node level jn to jn + 1 Each new node n gets jn = jn initiallyNode 0 splits thus perhaps into 1,2,4 until 0 1Node 1 starts with j= 1 and splits into 3,5,9until 1 1Node 2 starts with j= 1, splitting into 4,6,10 until 2 1Your general rule here Node with smaller T splits more times and vice versa30Scalable SchemeIf cloud is homogenous, the address space is contiguousOtherwise, it is not No problem Unlike for a extensible or linear hash data structure31Scalable SchemeReduce phase Every node n at level j attempts matches for every k[0, M-1] such that n = k mod 2j. If node 0 split three times, in Reduce phase it will attempt to match noised shares (f + k) with k = 0, 8, 16If node 1 split four times, it will attempt to match noised shares (f + k) with k = 1, 17, 33Etc32Scalable SchemeN D / R If S owner initial estimate holds For homogeneous cloud it is 30% greater on the average and twice as big at worstCloud cost may still be cheaper No need for private optionVersatility may still make it preferable besidesAverage recovery time remains R /2
33Scalable SchemeSee again Res. Report for Numerical ex. Correctness Safety Details of perf. analysis remain future work
34Related WorkRE for outsourced LH* files CSCP for outsourced LH* records sharingSharePointCrypto puzzlesOne way hash with trapdoor30-year old excitement around Clipper chipBotnets35ConclusionKey safety is Achilles heel of cryptographyKey loss or key disclosure ? That is The QuestionRENS schemes alleviate the dilemma Future work Deeper formal analysisExperimentsVariantsEspecially that called multiple noisingRaising average recovery time towards R Other consequences of principle Big Calculations = Big Data ?
36Thanksfor Your Attention37Witold LITWIN & al ** Early stage discussions with J. Katz, UMD, helped to shape the noised secret idea
