Masking Proofs are Tight (and How to Exploit it in Security - PowerPoint PPT Presentation

Masking Proofs are Tight (and How to Exploit it in Security Evaluations) Vincent Grosso, François-Xavier Standaert Radbout University Nijmegen (The Netherlands), UCL (Belgium) EUROCRYPT 2018, Tel Aviv, Israel

Motivation (side-channel security evaluation) 1 current practice (simplified) attack-based evaluations 2 128 computation 2 64 2 0 2 10 2 20 𝟑 𝟒𝟏 measurements

Motivation (side-channel security evaluation) 1 current practice (simplified) > 𝟑 𝟒𝟏 = 𝟑 𝟓𝟏 ? = 𝟑 𝟗𝟏 ? attack-based evaluations 2 128 computation 2 64 2 0 2 10 2 20 𝟑 𝟒𝟏 measurements

Motivation (side-channel security evaluation) 1 current practice proposed approach (simplified) open designs ( Kerckhoffs ) attack-based evaluations proof-based evaluations 2 128 2 128 computation computation computation 2 64 2 64 2 0 2 0 2 10 2 20 2 30 2 60 𝟑 𝟒𝟏 𝟑 𝟘𝟏 measurements measurements

Example: masked encoding 2 • Probing security ( Ishai, Sahai, Wagner 2003 ) 𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒) ?

Example: masked encoding 2 • Probing security ( Ishai, Sahai, Wagner 2003 ) 𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒) ? • 𝑒 − 1 probes do not reveal anything on 𝑧

Example: masked encoding 2 • Probing security ( Ishai, Sahai, Wagner 2003 ) 𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒) y • But 𝑒 probes completely reveal 𝑧

Example: masked encoding 2 • Probing security ( Ishai, Sahai, Wagner 2003 ) 𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒) ? • Noisy leakage security ( Prouff, Rivain 2013 )

Example: masked encoding 2 • Probing security ( Ishai, Sahai, Wagner 2003 ) 𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒) noise and independence (Duc, Dziemb., Faust 2014) • Noisy leakage security ( Prouff, Rivain 2013 )

Example: masked encoding 2 • Probing security ( Ishai, Sahai, Wagner 2003 ) 𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒) noise and independence (Duc, Dziemb., Faust 2014) • Noisy leakage security ( Prouff, Rivain 2013 ) 𝑑 MI( 𝑍, 𝑴) < MI( 𝑍(𝑘), 𝑴(𝑘)) 𝑒 𝑂 ∝ and MI (𝑍;𝑴)

Contributions 3 • Previous work: masking proofs are tight for the encodings (Duc, Faust, Standaert, EC15/JoC18)

Contributions 3 • Previous work: masking proofs are tight for the encodings (Duc, Faust, Standaert, EC15/JoC18) • This work: 1. The same holds for circuits (e.g., S-boxes) made from simple gadgets (e.g., add. & mult.)

Contributions 3 • Previous work: masking proofs are tight for the encodings (Duc, Faust, Standaert, EC15/JoC18) • This work: 1. The same holds for circuits (e.g., S-boxes) made from simple gadgets (e.g., add. & mult.) 2. Proofs can considerably simplify evaluations • Under noise & independence assumptions • Limited to divide & conquer attacks

Outline 1. Evaluation settings 2. Case studies w.c. eval. time complexity • Case #1: low 𝑒 , one-tuple vs. multi-tuples • Independent Operation’s Leakages (IOL) • Case #2: higher 𝑒 , single-tuple • Independent Shares Leakages (ISL), DFS bound • Case #3: multiplication leakages • ISL assumption + PR bound • Case #4: higher 𝑒 , worst-case attacks • Shares repetition, security graphs 3. Concrete attacks (i.e., why worst-case data comp. needed) 4. Conclusions & future research

Outline 1. Evaluation settings 2. Case studies w.c. eval. time complexity • Case #1: low 𝑒 , one-tuple vs. multi-tuples • Independent Operation’s Leakages (IOL) • Case #2: higher 𝑒 , single-tuple • Independent Shares Leakages (ISL), DFS bound • Case #3: multiplication leakages • ISL assumption + PR bound • Case #4: higher 𝑒 , worst-case attacks • Shares repetition, security graphs 3. Concrete attacks (i.e., why worst-case data comp. needed) 4. Conclusions & future research

Evaluation settings (I) 4 • Target implementation:

Evaluation settings (I) 4 • Target implementation: • C1 Adv: one 𝑒 -tuple, 𝑴 = 𝑀 10 = [𝑀 10 1 , … , 𝑀 10 𝑒 ] leakage matrix leakage vector leakage sample ( one 𝑒 -tuple ) ( all leaks ) ( one share )

Evaluation settings (I) 4 • Target implementation: • C2 Adv: ten 𝑒 -tuples, 𝑴 = [𝑀 1 , 𝑀 2 , … , 𝑀 10 ]

Evaluation settings (I) 4 • Target implementation: C3 Adv: multiplication leaks, some • 𝑀 𝑗 ’s become 𝑒 2 -tuples - or even 2 𝑒 2 -tuples ( log/alog tables ) compression 𝑑 1 𝑏 1 𝑐 1 𝑏 1 𝑐 2 𝑏 1 𝑐 3 0 𝑠 𝑠 1 2 𝑑 2 −𝑠 0 𝑠 𝑏 2 𝑐 1 𝑏 2 𝑐 2 𝑏 2 𝑐 3 + ⇒ 1 3 𝑑 3 −𝑠 𝑠 0 𝑏 3 𝑐 1 𝑏 3 𝑐 2 𝑏 3 𝑐 3 2 3 refreshing partial products

Evaluation settings (I) 4 • Target implementation: C3 Adv: multiplication leaks, some • 𝑀 𝑗 ’s become 𝑒 2 -tuples - or even 2 𝑒 2 -tuples ( log/alog tables ) • 8-bit 𝑧 = 𝑧(1) … 𝑧 𝑒 , 𝑚(𝑘) = HW 𝑧(𝑘) + 𝑜 2 , SNR = 𝜏 2 (8−bit HW) = 2 • Noise variance 𝜏 𝑜 2 2 𝜏 𝑜 𝜏 𝑜 • ( Correlated noise analyzed in the paper )

Evaluation settings (II) 5 • Exact worst-case evaluations ≈ computing: MI 𝐿; 𝑌, 𝑴 = H 𝐿 + Pr[𝑙] ∙ Pr 𝑦 𝑙 𝑦 ∙ Pr[𝑧] ∙ Pr 𝒎 𝑙, 𝑦, 𝒛 ∙ log 2 (Pr 𝑙 𝑦, 𝒎 ) 𝒛 𝒎 shares vectors 𝜀 -dimension integral ⇒ 𝑃(2 𝑒 ) • Which can be computationally hard…

Outline 1. Evaluation settings 2. Case studies w.c. eval. time complexity • Case #1: low 𝑒 , one-tuple vs. multi-tuples • Independent Operation’s Leakages (IOL) • Case #2: higher 𝑒 , single-tuple • Independent Shares Leakages (ISL), DFS bound • Case #3: multiplication leakages • ISL assumption + PR bound • Case #4: higher 𝑒 , worst-case attacks • Shares repetition, security graphs 3. Concrete attacks (i.e., why worst-case data comp. needed) 4. Conclusions & future research

Case #1 6 • 𝑒 = 1,2 , C1 Adv ⇒ exhaustive analysis possible

Case #1 6 • 𝑒 = 1,2 , C2 Adv ⇒ exhaustive analysis possible

Case #1 6 • 𝑒 = 1,2 , C2 Adv ⇒ exhaustive analysis possible • But IOL assumption leads to faster evaluation 𝑗 , • i.e., MI 𝐿; 𝑌, 𝑴 ≈ 10 ∙ MI(𝑍 𝑀 𝑗 )

Case #1 6 • 𝑒 = 1,2 , C2 Adv ⇒ exhaustive analysis possible • But IOL assumption leads to faster evaluation • Conservative ( dependencies linearly decrease the MI )

Case #2 7 • Larger 𝑒 ’s, C1 Adv ⇒ exhaustive analysis hard

Case #2 7 • Larger 𝑒 ’s, C1 Adv ⇒ exhaustive analysis hard • But ISL assumpt. leads to much faster eval. 𝑀 𝑗 (𝑘)) 𝑒 [DFS15,18] 𝑗 , 𝑗 (𝑘), • i.e., MI( 𝑍 𝑀 𝑗 ) < MI( 𝑍

Case #2 7 • Larger 𝑒 ’s, C1 Adv ⇒ exhaustive analysis hard • But ISL assumpt. leads to much faster eval. • Critical ( dependencies exponentially increase the MI )

Case #3 8 • Mult. leaks ⇒ analysis even harder ( 2-bit example )

Case #3 8 • Mult. leaks ⇒ analysis even harder ( 2-bit example ) • ISL assumpt. leads to much faster eval. [PR13] MI( 𝑒 2 partial prod.) ≈ 1,72 ∙ 𝑒 ∙ MI(𝑒 -tuple) •

Case #4: putting things together (I) 9 • Full S-box analysis, large 𝑒 ’s, C1 & C3 Adv

Case #4: putting things together (I) 9 • Full S-box analysis, large 𝑒 ’s, C1 & C3 Adv • C1 → C3: MI increases linearly in # of tuples 𝑀 𝑗 (𝑘)) 𝑒 ≈ 𝑒 ∙ MI( 𝑍 𝑗 (𝑘), 𝑗 (𝑘), 𝑀 𝑗 (𝑘)) 𝑒 • i.e., MI( 𝑍

Case #4: putting things together (I) 9 • Full S-box analysis, large 𝑒 ’s, C1 & C3 Adv • C1 → C3: MI increases linearly in # of tuples • ∝ “circuit size” parameter of masking proofs

Case #4: putting things together (II) 10 • Things get (much) worse if shares re-used 𝑏 1 𝑐 1 𝑏 1 𝑐 2 𝑏 1 𝑐 3 • e.g., ISW each share used 𝑒 times: 𝑏 2 𝑐 1 𝑏 2 𝑐 2 𝑏 2 𝑐 3 𝑏 3 𝑐 1 𝑏 3 𝑐 2 𝑏 3 𝑐 3

Case #4: putting things together (II) 10 • Things get (much) worse if shares re-used Adv. can average the • 𝑀 𝑗 (𝑘) ’s & increases MI exp. in 𝑒

Case #4: putting things together (II) 10 • Things get (much) worse if shares re-used Adv. can average the • 𝑀 𝑗 (𝑘) ’s & increases MI exp. in 𝑒 𝑀 𝑗 (𝑘)) 𝑒 ≈ (𝑒 ∙ MI( 𝑍 𝑗 (𝑘), 𝑗 (𝑘), 𝑀 𝑗 (𝑘))) 𝑒 • i.e., MI( 𝑍

Case #4: putting things together (II) 10 • Things get (much) worse if shares re-used Adv. can average the • 𝑀 𝑗 (𝑘) ’s & increases MI exp. in 𝑒 • ∝ “noise condition” of masking security proofs

Case #4: putting things together (II) 10 • Things get (much) worse if shares re-used Adv. can average the • 𝑀 𝑗 (𝑘) ’s & increases MI exp. in 𝑒 • ∝ “noise condition” of masking security proofs

Link to the bigger picture 11 • From MI 𝐿; 𝑌, 𝑴 one can directly obtain a bound on the attack’s overall complexity • Example for MI 𝐿; 𝑌, 𝑴 = 10 −7