Fault attack vulnerability assessment of binary code Cryptography - PowerPoint PPT Presentation

Fault attack vulnerability assessment of binary code Cryptography and Security in Computing Systems [CS2’19], Valencia, Spain January 21, 2019 Jean-Baptiste Bréjon Emmanuelle Encrenaz Karine Heydemann Quentin Meunier Son-Tuan Vu Sorbonne Université, CNRS, Laboratoire d’Informatique de Paris 6, F-75005 Paris, France JB. Bréjon CS2’19 January 21, 2019 1 / 21

Plan Context Fault Attacks Protections Vulnerability Assessment Security Metrics Use-Case: VerifyPin Conclusion JB. Bréjon CS2’19 January 21, 2019 2 / 21

Context The number of embedded systems keeps growing and their uses diversify Sensitive data are increasingly manipulated by embedded systems → Need to secure them and thus guarantee the effectiveness of protection mechanisms The case of physical attacks: requires physical access to the chip Side-channel: the attacker deduces secret information by exploiting caracteristics of the software or hardware implementation Fault attacks: the attacker perturbs the program behavior by using physical means to obtain secret information JB. Bréjon CS2’19 January 21, 2019 3 / 21

Fault Attacks Means Clock glitch, voltage glitch [B AR -E L et al. 2006] Laser beam [K ARAKLAJIC et al. 2013] Electromagnetic pulse [D EHBAOUI et al. 2012; M ORO et al. 2013] ... Goals Bypass security mechanisms [V ASSELLE et al. 2017] Privilege escalation [T IMMERS et al. 2017] Obtain sensitive information Effects Permanent (bond wire fuse), transient (bit flip) [B AR -E L et al. 2006; B ONEH et al. 2001; O RDAS et al. 2015] Fault effects representation at a specific code level → fault model → How can we protect from them? JB. Bréjon CS2’19 January 21, 2019 4 / 21

Protections Can be implemented on both hardware (costly, cannot be adapted) and software (cheaper, easily adaptable) Software protections Add pieces of code Can be implemented at all code levels Trial-and-error process Designed against fault models Issues with the process of protecting software Ensure protections effectiveness Ensure the final code is well protected, especially considering the effects of compiler optimisations → Need to assess the security of the code at low level JB. Bréjon CS2’19 January 21, 2019 5 / 21

Vulnerability Assessment Goal: assess the robustness of a binary program to fault attacks Why binary code? → Allows to take into account the effects of the optimization process on protections implemented at source-level → Have access to the final binary instructions and code layout Formal verification → requires to formally model code and faults Implemented in a tool → RobustB 3 supported fault models Instruction skip Register corruption Instruction replacement JB. Bréjon CS2’19 January 21, 2019 6 / 21

Overview (vulnerabilities) Initialization Binary Original Faulted Vulnerability Code Code + RobustB Initialization Original Path Faulted Path Final values Final values list Target region Comparison Final values Final values ≠ Comparison From a code region in a binary Vulnerability detection: difference in final values of the original code and a faulted code version Outputs a description of the vulnerabilities found: vulnerability list JB. Bréjon CS2’19 January 21, 2019 7 / 21

Overview (process steps) Initialization Original Faulted Binary Vulnerability Code Code + RobustB Initialization Original Faulted Path Path Target region Final values Final values list Comparison Final values Final values ≠ Comparison 1 - Extract a representation of the target region 2 - Determine the possible execution paths within the target region 3 - Single fault injection on the possible execution paths 4 - Search for vulnerabilities by formal verification of a non-equivalence property (SMT) Satisfiable → the fault induces a vulnerability Unsatisfiable → the fault has no effect ⇒ Vulnerability list including their locations JB. Bréjon CS2’19 January 21, 2019 8 / 21

Information Extraction From the Binary CFG Binary A Other area block Block A B 1 Block B Target Region Block D 1 C Block C Other area block D Dynamic/symbolic analysis Extracts execution contexts of Static analysis the target region CFG construction + Blocks order Extracts loop bounds within the target region JB. Bréjon CS2’19 January 21, 2019 9 / 21

Determining the Possible Execution Paths Structural bounded unfolding of the CFG CFG EFG A A B B C 1 C B D C D 1 D D D JB. Bréjon CS2’19 January 21, 2019 10 / 21

Determining the Possible Execution Paths Structural bounded unfolding of the CFG CFG EFG A A B B C 1 C B D C D 1 D D D Resulting paths accessibility test (SMT) → Each instruction is modeled regarding its effect on a machine state model Conditions : accessibility cmp cmp add Branch add Branch S0 S1 S2 S3 S4 S5 S6 Initial state Final state JB. Bréjon CS2’19 January 21, 2019 10 / 21

Determining Faulty Execution Paths EFG A EFG CFG A A B C Binary 1 + 1 B Other area block B D C D Block A 1 Block B C D D Block D Block C D Induced EFG Other area block A A fault may alter the execution flow B → Possible execution paths are recomputed after a fault injection B D CFG unfolding after the fault Takes into account the code layout Relaxed loop bounds B D Resulting paths are checked for accessibility D JB. Bréjon CS2’19 January 21, 2019 11 / 21

Robustness Analysis P _ Orig → Original execution path P _ Faulted → Faulty execution path Context Registers Memory locations P_Orig P_Faulted ≠ Registers Same context (C) Registers When the final values of some Memory locations Memory locations memorizing elements differ , a vulnerability is detected Formula: Access ( P _ Orig , C ) ∧ Access ( P _ Faulted , C ) ∧ Vuln → SAT : The fault in P _ Faulted leads to a Security Property vulnerability Repeating this process for all faults on all injection points produces a vulnerability list JB. Bréjon CS2’19 January 21, 2019 12 / 21

Results Synthesis Vulnerability list is not easy to analyse (manual evaluate each vulnerability) How dangerous is each vulnerability? How to compare the vulnerabilities of two different implementations? Need for a synthetic view Introduction of three security metrics Instruction sensitivity level Average number of vulnerabilities in paths Vulnerabilities density JB. Bréjon CS2’19 January 21, 2019 13 / 21

Paths Probabilities A vulnerability appearing on a path should be weighted differently than one appearing on another path depending on the likelihood of their path . CFG EFG A A 0.5 0.5 B B C 1 1 0 0.5 0.5 C B D C D 1 p3 D D D p1 p2 By default: paths have equal Path Blocks P(path) probability p1 A - B - B - D 0.5 p2 A - C - C - D 0.25 Ideally: user can define the branches probability p3 A - C - D 0.25 JB. Bréjon CS2’19 January 21, 2019 14 / 21

Instruction Sensitivity (IS) IS(i): score reflecting instruction i sensitivity Each vulnerable instruction occurence is weighted relatively to the likelihood of the path it appears on IS ( i ) = � p ∈ Paths P ( p is taken ) × NV i ( p ) *3 I0 A 0.5 0.5 NV i ( p ) : Instruction i #Vulnerabilities on I1 path p B C 1 0 0.5 0.5 Inst Score I1 I2 B D C D I0 1 = P ( p 1 ) + P ( p 2 ) + P ( p 3 ) p3 1 = 2 ∗ P ( p 1 ) I1 P(p3)=0.25 I2 D D I2 0.5 = P ( p 2 ) + P ( p 3 ) p1 p2 P(p1)=0.5 P(p2)=0.25 Rank the instructions according to their sensitivity → helps the designer to focus on the most sensitive instructions JB. Bréjon CS2’19 January 21, 2019 15 / 21

Attack Surface (AS) AS: average number of vulnerabilities on an execution path AS = � p ∈ Paths P ( p is taken ) × NV ( p ) NV(p) : #Vulnerabilites appearing on path p 4 vulnerabilities , on each example, weigthed by paths probabilities 4 0.5 0.5 1 4 p1 p2 p1 P(p1)=0.5 P(p2)=0.5 P(p1)=0.5 AS = 4 ∗ 0 . 5 = 2 AS = 4 ∗ 1 = 4 2 vulnerabilities found on average 4 vulnerabilities found on average The higher the attack surface , the more the attacker will be able to inject a fault leading to a vulnerability JB. Bréjon CS2’19 January 21, 2019 16 / 21

Normalized Attack Surface (NAS) NAS: Average density of vulnerabilities p ∈ Paths P ( p is taken ) × NI ( p ) = AS AS NAS = � ANI NI(p) : Path p #Instructions ANI : Average number of instructions per path Same vulnerabilities but different amount of instructions : affects vulnerability density x2 100 10 x2 0.5 0.5 0.5 0.5 100 100 10 10 p1 p2 p1 p2 P(p1)=0.5 P(p2)=0.5 P(p1)=0.5 P(p2)=0.5 AS = 2 ∗ 0 . 5 + 2 ∗ 0 . 5 = 2 AS = 2 ∗ 0 . 5 + 2 ∗ 0 . 5 = 2 NAS = 2 / ( 100 + 100 ) = 0.01 NAS = 2 / ( 10 + 10 ) = 0.1 Odds for a randomly timed fault injection to Odds for a randomly timed fault injection to lead to a vulnerability: 1% lead to a vulnerability: 10% JB. Bréjon CS2’19 January 21, 2019 17 / 21

Use-Case: VerifyPin Description Belongs to the FISCC (Fault Injection and Simulation Secure Code Collection) benchmarks, dedicated to fault injection analysis Compares a user PIN with a predefined PIN Authentication “OK” if PINs are identical, “KO” otherwise Several versions of the function, each one combining different source-level protections Analysis Security property: user PIN and predefined PIN different with Authentication “OK” 4 versions: 1 unprotected, 3 protected 2 optimisation levels: O0, O2 Fault model: instruction skip JB. Bréjon CS2’19 January 21, 2019 18 / 21