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)

attack-based evaluations

computation 𝟑𝟒𝟏 220 210 measurements 2128 264 20

current practice

(simplified)

1

Motivation (side-channel security evaluation)

attack-based evaluations

computation 𝟑𝟒𝟏 220 210 measurements 2128 264 20 > 𝟑𝟒𝟏 = 𝟑𝟓𝟏? = 𝟑𝟗𝟏?

current practice

(simplified)

1

Motivation (side-channel security evaluation)

attack-based evaluations proof-based evaluations

• pen designs

(Kerckhoffs)

computation computation 𝟑𝟒𝟏 220 210 measurements 2128 264 20 computation 2128 264 20 𝟑𝟘𝟏 260 230 measurements

proposed approach current practice

(simplified)

1

Example: masked encoding

• Probing security (Ishai, Sahai, Wagner 2003)

𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒)

?

2

Example: masked encoding

• Probing security (Ishai, Sahai, Wagner 2003)
• 𝑒 − 1 probes do not reveal anything on 𝑧

𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒)

?

2

Example: masked encoding

• Probing security (Ishai, Sahai, Wagner 2003)
• But 𝑒 probes completely reveal 𝑧

𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒)

y

2

Example: masked encoding

?

𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒)

• Probing security (Ishai, Sahai, Wagner 2003)
• Noisy leakage security (Prouff, Rivain 2013)

2

Example: masked encoding

𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒)

• Probing security (Ishai, Sahai, Wagner 2003)
• Noisy leakage security (Prouff, Rivain 2013)

noise and independence

(Duc, Dziemb., Faust 2014)

2

Example: masked encoding

𝑧 = 𝑧 1 ⊕ 𝑧 2 ⊕ ⋯ ⊕ 𝑧(𝑒 − 1) ⊕ 𝑧(𝑒)

• Probing security (Ishai, Sahai, Wagner 2003)
• Noisy leakage security (Prouff, Rivain 2013)

𝑂 ∝

𝑑

MI(𝑍;𝑴) and MI(𝑍, 𝑴) < MI(𝑍(𝑘), 𝑴(𝑘))𝑒 noise and independence

(Duc, Dziemb., Faust 2014)

2

Contributions

• Previous work: masking proofs are tight for the

encodings (Duc, Faust, Standaert, EC15/JoC18)

3

Contributions

• 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.)

3

Contributions

• 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

3

Outline

• 1. Evaluation settings
• 2. Case studies
• 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

w.c. eval. time complexity

Outline

• 1. Evaluation settings
• 2. Case studies
• 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

w.c. eval. time complexity

Evaluation settings (I)

• Target implementation:

4

Evaluation settings (I)

• Target implementation:
• C1 Adv: one 𝑒-tuple, 𝑴 = 𝑀10 = [𝑀10 1 , … , 𝑀10 𝑒 ]

4

leakage matrix (all leaks) leakage vector (one 𝑒-tuple) leakage sample (one share)

Evaluation settings (I)

• Target implementation:
• C2 Adv: ten 𝑒-tuples, 𝑴 = [𝑀1, 𝑀2, … , 𝑀10]

4

Evaluation settings (I)

• Target implementation:
• C3 Adv: multiplication leaks, some

𝑀𝑗’s become 𝑒2-tuples - or even 2𝑒2-tuples (log/alog tables) 4

𝑏1𝑐1 𝑏1𝑐2 𝑏1𝑐3 𝑏2𝑐1 𝑏2𝑐2 𝑏2𝑐3 𝑏3𝑐1 𝑏3𝑐2 𝑏3𝑐3 + 𝑠

1

𝑠

2

−𝑠

1

𝑠

3

−𝑠

2

𝑠

3

⇒ 𝑑1 𝑑2 𝑑3 partial products refreshing compression

Evaluation settings (I)

• Target implementation:
• C3 Adv: multiplication leaks, some

𝑀𝑗’s become 𝑒2-tuples - or even 2𝑒2-tuples (log/alog tables)

• 8-bit 𝑧 = 𝑧(1) … 𝑧 𝑒 , 𝑚(𝑘) = HW 𝑧(𝑘) + 𝑜
• Noise variance 𝜏𝑜

2, SNR = 𝜏2(8−bit HW) 𝜏𝑜

2

= 2

𝜏𝑜

2

• (Correlated noise analyzed in the paper)

4

Evaluation settings (II)

• Exact worst-case evaluations ≈ computing:
• Which can be computationally hard…

MI 𝐿; 𝑌, 𝑴 = H 𝐿 +

𝑙

Pr[𝑙] ∙

𝑦

Pr 𝑦 ∙

𝒛

Pr[𝑧] ∙

𝒎

Pr 𝒎 𝑙, 𝑦, 𝒛 ∙ log2(Pr 𝑙 𝑦, 𝒎 )

shares vectors ⇒ 𝑃(2𝑒) 𝜀-dimension integral

5

Outline

• 1. Evaluation settings
• 2. Case studies
• 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

w.c. eval. time complexity

Case #1

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

6

Case #1

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

6

Case #1

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

𝑗,

𝑀𝑗) 6

Case #1

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

6

Case #2

• Larger 𝑒’s, C1 Adv ⇒ exhaustive analysis hard

7

Case #2

• Larger 𝑒’s, C1 Adv ⇒ exhaustive analysis hard
• But ISL assumpt. leads to much faster eval.
• i.e., MI(𝑍

𝑗,

𝑀𝑗) < MI(𝑍

𝑗(𝑘),

𝑀𝑗(𝑘))𝑒 [DFS15,18] 7

Case #2

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

7

Case #3

• Mult. leaks ⇒ analysis even harder (2-bit example)

8

Case #3

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

8

Case #4: putting things together (I)

• Full S-box analysis, large 𝑒’s, C1 & C3 Adv

9

• Full S-box analysis, large 𝑒’s, C1 & C3 Adv
• C1 → C3: MI increases linearly in # of tuples
• i.e., MI(𝑍

𝑗(𝑘),

𝑀𝑗(𝑘))𝑒 ≈ 𝑒 ∙ 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 (I)

9

• e.g., ISW each share used 𝑒 times:

Case #4: putting things together (II)

• Things get (much) worse if shares re-used

10

𝑏1𝑐1 𝑏1𝑐2 𝑏1𝑐3 𝑏2𝑐1 𝑏2𝑐2 𝑏2𝑐3 𝑏3𝑐1 𝑏3𝑐2 𝑏3𝑐3

• Adv. can average the

𝑀𝑗(𝑘)’s & increases MI exp. in 𝑒

Case #4: putting things together (II)

• Things get (much) worse if shares re-used

10

• Adv. can average the

𝑀𝑗(𝑘)’s & increases MI exp. in 𝑒

• i.e., MI(𝑍

𝑗(𝑘),

𝑀𝑗(𝑘))𝑒 ≈ (𝑒 ∙ MI(𝑍

𝑗(𝑘), 𝑀𝑗(𝑘)))𝑒

Case #4: putting things together (II)

• Things get (much) worse if shares re-used

10

• Adv. can average the

𝑀𝑗(𝑘)’s & increases MI exp. in 𝑒

• ∝ “noise condition” of masking security proofs

Case #4: putting things together (II)

• Things get (much) worse if shares re-used

10

• Adv. can average the

𝑀𝑗(𝑘)’s & increases MI exp. in 𝑒

• ∝ “noise condition” of masking security proofs

Case #4: putting things together (II)

• Things get (much) worse if shares re-used

10

Link to the bigger picture

• From MI 𝐿; 𝑌, 𝑴 one can directly obtain a

bound on the attack’s overall complexity

• Example for MI 𝐿; 𝑌, 𝑴 = 10−7

11

Outline

• 1. Evaluation settings
• 2. Case studies
• 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

w.c. eval. time complexity

From evaluations to attacks

• Exact worst-case evaluations can be hard
• Time complexity may be beyond reach
• IOL and ISL assumptions lead to easy bounds
• Is the worst-case data complexity an overkill?
• Short answer: no (∃ efficient attacks close to worst-case)

12

From evaluations to attacks

• Exact worst-case evaluations can be hard
• Time complexity may be beyond reach
• IOL and ISL assumptions lead to easy bounds
• Is the worst-case data complexity an overkill?
• Short answer: no (∃ efficient attacks close to worst-case)

12

Examples:

• Horizontal attacks

(Battistello et al., CHES16)

• SASCA aka belief

propagation (this paper)

• Machine learning?
• Black box (!)

Outline

• 1. Evaluation settings
• 2. Case studies
• 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

w.c. eval. time complexity

Conclusions (I)

• Analogy: security against linear cryptanalysis
• Trying attacks with bounded complexity
• Use S-boxes / diffusion properties & state

bounds based on the wide-trail strategy

13

Conclusions (I)

• Analogy: security against linear cryptanalysis
• Trying attacks with bounded complexity
• Use S-boxes / diffusion properties & state

bounds based on the wide-trail strategy

• General message: the same (should) hold(s) for

implementations (this paper ≈ one step in this direction) 13

Conclusions (I)

• Analogy: security against linear cryptanalysis
• Trying attacks with bounded complexity
• Use S-boxes / diffusion properties & state

bounds based on the wide-trail strategy

• General message: the same (should) hold(s) for

implementations (this paper ≈ one step in this direction)

• Methodology applied to a real world 32-share

masked AES implementation at CHES 2017

• Allows claiming security beyond 260 measurements

13

Conclusions (II)

• Limitations
• Results are only tight in log-scale plots
• Hence only apply to high-security evaluations
• ∃ more accurate evaluations for low 𝑒’s

14

Conclusions (II)

• Limitations
• Results are only tight in log-scale plots
• Hence only apply to high-security evaluations
• ∃ more accurate evaluations for low 𝑒’s
• Strong (noise and independence) assumptions
• Orthogonal but important issue!
• See for example threshold implementations

14

Conclusions (II)

• Limitations
• Results are only tight in log-scale plots
• Hence only apply to high-security evaluations
• ∃ more accurate evaluations for low 𝑒’s
• Strong (noise and independence) assumptions
• Orthogonal but important issue!
• See for example threshold implementations
• Only Divide-and-Conquer attacks
• Problem 1: extend to analytical attacks

14

Conclusions (II)

• Limitations
• Results are only tight in log-scale plots
• Hence only apply to high-security evaluations
• ∃ more accurate evaluations for low 𝑒’s
• Strong (noise and independence) assumptions
• Orthogonal but important issue!
• See for example threshold implementations
• Only Divide-and-Conquer attacks
• Problem 1: extend to analytical attacks
• Concrete conclusion: shares’ leakage averaging

implies and exponential security loss!

• Problem 2: analyze/generalize & fix this threat

14

THANKS

http://perso.uclouvain.be/fstandae/