Simulation to enhance secure boot defenses against fault injection attacks
•
0 likes•1,991 views
Secure Boot is widely deployed in modern embedded systems and an essential part of the security model. Even when no (easy to exploit) logical vulnerabilities remain, attackers are surprisingly often still able to compromise it using Fault Injection or a so called glitch attack. Many of these vulnerabilities are difficult to spot in the source code and can only be found by manually inspecting the disassembled binary code instruction by instruction. While the idea to use simulation to identify these vulnerabilities is not new, this talk presents a fault simulator created using existing open-source components and without requiring a detailed model of the underlying hardware. The challenges to simulate real-world targets will be discussed as well as how to overcome most of them.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Simulation to enhance secure boot defenses against fault injection attacks
Similar to Simulation to enhance secure boot defenses against fault injection attacks (20)
More from Riscure
More from Riscure (18)
Recently uploaded
Recently uploaded (20)
Simulation to enhance secure boot defenses against fault injection attacks
- 1. 1 Secure boot under attack: Simulation to enhance fault injection & defenses Niek Timmers Principal Security Analyst niek@riscure.com / @tieknimmers Martijn Bogaard Senior Security Analyst martijn@riscure.com / @jmartijnb
- 3. 3 Today’s agenda • Crash course secure boot on embedded devices
- 4. 4 Today’s agenda • Crash course secure boot on embedded devices • Crash course fault injection (FI) attacks
- 5. 5 Today’s agenda • Crash course secure boot on embedded devices • Crash course fault injection (FI) attacks • Using simulation to identify FI vulnerabilities
- 6. 6 Why do we need secure boot? Processor Boot code System-on-Chip Flash Kernel ROM OTPSRAM DDR
- 7. 7 Why do we need secure boot? Processor Boot code System-on-Chip Flash Kernel ROM OTPSRAM DDR 1
- 8. 8 Why do we need secure boot? Processor Boot code System-on-Chip Flash Kernel Boot code ROM OTPSRAM DDR 2 1
- 9. 9 Why do we need secure boot? Processor Boot code System-on-Chip Flash Kernel Boot code Kernel ROM OTPSRAM DDR 2 1 3
- 10. 10 Why do we need secure boot? Processor Boot code System-on-Chip Flash Kernel Boot code Kernel ROM OTPSRAM Threat 1: Hardware Hacker DDR 2 1 3
- 11. 11 Why do we need secure boot? Processor Boot code System-on-Chip Flash Kernel Boot code Kernel ROM OTPSRAM Threat 1: Hardware Hacker Threat 2: Malware DDR 2 1 3
- 12. 12 Why do we need secure boot? Processor Boot code System-on-Chip Flash Kernel Boot code Kernel ROM OTPSRAM Secure boot assures integrity of code/data in cold storage! Threat 1: Hardware Hacker Threat 2: Malware DDR 2 1 3
- 13. 13 The real world is more complex!
- 14. 14 The real world is more complex! ROM EL3 Secure WorldHigher privileges Lower privileges
- 15. 15 The real world is more complex! ROM BLx EL3 Secure World EL1 Higher privileges Lower privileges
- 16. 16 The real world is more complex! ROM ATFBLx EL3 Secure World EL1 EL3 Higher privileges Lower privileges
- 17. 17 The real world is more complex! ROM U-Boot ATFBLx EL3 Secure World EL1 Non-Secure World EL1 EL3 Higher privileges Lower privileges
- 18. 18 The real world is more complex! ROM U-Boot ATF TEE OS TEE Apps Boot finished! Linux Apps BLx Linux Kernel EL3 EL1 EL0 Secure World EL1 EL1 EL0 Non-Secure World EL1 EL3 The chain can break at any stage. Early is better! Higher privileges Lower privileges
- 19. 19 Breaking Secure Boot early
- 20. 20 Breaking Secure Boot early • Early boot stage run at the highest privilege • E.g. unrestricted access
- 21. 21 Breaking Secure Boot early • Early boot stage run at the highest privilege • E.g. unrestricted access • Security features often not initialized yet • E.g. access control
- 22. 22 Breaking Secure Boot early • Early boot stage run at the highest privilege • E.g. unrestricted access • Security features often not initialized yet • E.g. access control • Access assets that are not accessible after boot • E.g. ROM code and keys
- 23. 23 What makes Secure Boot secure?
- 24. 24 What makes Secure Boot secure? Unbreakable cryptography… Right?
- 25. 25 Flow of a typical boot stage
- 26. 26 Flow of a typical boot stage Start
- 27. 27 Flow of a typical boot stage Start Check this
- 28. 28 Flow of a typical boot stage Start Check this Check that
- 29. 29 Flow of a typical boot stage Start Check this Check that Configure this
- 30. 30 Flow of a typical boot stage Start Check this Check that Configure this Configure that
- 31. 31 Flow of a typical boot stage Start Check this Check that Configure this Configure that Load next stage
- 32. 32 Flow of a typical boot stage Start Check this Check that Configure this Configure that Load next stage Decrypt next stage
- 33. 33 Flow of a typical boot stage Start Check this Check that Configure this Authenticate next stage Configure that Load next stage Decrypt next stage
- 34. 34 Flow of a typical boot stage Start Check this Check that Configure this Authenticate next stage Configure that Load next stage Decrypt next stage Jump to next stage?
- 35. 35 Flow of a typical boot stage Start Check this Check that Configure this Authenticate next stage Configure that Load next stage Decrypt next stage Jump to next stage? Lots of functionality! What can go wrong?
- 36. 36 Flow of a typical boot stage Start Check this Check that Configure this Authenticate next stage Configure that Load next stage Decrypt next stage Jump to next stage? Lots of functionality! What can go wrong?goes wrong!?
- 40. 40 Why hardware attacks on secure boot?
- 41. 41 Why hardware attacks on secure boot? • Usually a small code base
- 42. 42 Why hardware attacks on secure boot? • Usually a small code base • Limited attack surface
- 43. 43 Why hardware attacks on secure boot? • Usually a small code base • Limited attack surface • Should be extensively reviewed
- 44. 44 Why hardware attacks on secure boot? • Usually a small code base • Limited attack surface • Should be extensively reviewed • Difficult / impossible to fix after deployment
- 45. 45 Why hardware attacks on secure boot? • Usually a small code base • Limited attack surface • Should be extensively reviewed • Difficult / impossible to fix after deployment Software vulnerabilities not guaranteed to be present!
- 46. 46 Voltage Fault Injection in practice
- 47. 47 Voltage Fault Injection in practice
- 48. 48 Voltage Fault Injection in practice
- 49. 49 Voltage Fault Injection in practice
- 50. 50 Voltage Fault Injection in practice
- 51. 51 Voltage Fault Injection in practice
- 52. 52 Voltage Fault Injection in practice
- 53. 53 Voltage Fault Injection in practice
- 54. 54 Voltage Fault Injection in practice
- 55. 55 USB Voltage Fault Injection in practice
- 56. 56 VCC USB Voltage Fault Injection in practice
- 57. 57 VCC USB Reset Voltage Fault Injection in practice
- 58. 58 time
- 59. 59 time
- 63. 63 Let’s do this live on stage! What could possibly go wrong….
- 65. 65 Fault Injection Demo BL1 U-Boot We do not modify U-Boot in flash.
- 66. 66 Fault Injection Demo We do modify the U-Boot in flash. BL1 U-Boot We do not modify U-Boot in flash. BL1 U-Boot
- 67. 67 Fault Injection Demo We do modify the U-Boot in flash. BL1 U-Boot We do not modify U-Boot in flash. BL1 BL1 U-Boot U-Boot
- 68. 68 Fault Injection Demo We do modify the U-Boot in flash. PWNED BL1 U-Boot We do not modify U-Boot in flash. BL1 BL1 U-Boot U-Boot
- 69. 69 Successful Glitch! Want to know more? Please meet us after the talk!
- 70. 70 Why does this work? What goes wrong? Difficult to answer. But, behaviorally we can say a lot!
- 71. 71 What can we do with our glitches?
- 72. 72 What can we do with our glitches? • Modify memory contents
- 73. 73 What can we do with our glitches? • Modify memory contents • Modify register contents
- 74. 74 What can we do with our glitches? • Modify memory contents • Modify register contents • Modify the executed instructions !!!
- 75. 75 What can we do with our glitches? • Modify memory contents • Modify register contents • Modify the executed instructions We can change the intended behavior of software! !!!
- 76. 76 What about unglitchable hardware?
- 77. 77 Yes. But… difficult & expensive. What about unglitchable hardware?
- 78. 78 What about using only software?
- 79. 79 Sure. What about using only software?
- 80. 80 Typical Software FI Countermeasures* * https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Channel_Patterns.pdf
- 81. 81 Typical Software FI Countermeasures* • Redundant checks * https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Channel_Patterns.pdf
- 82. 82 Typical Software FI Countermeasures* • Redundant checks • Defensive coding –e.g. initialize return values as ‘error’ * https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Channel_Patterns.pdf
- 83. 83 Typical Software FI Countermeasures* • Redundant checks • Defensive coding –e.g. initialize return values as ‘error’ • Code flow integrity –i.e. assure the code follows the intended path * https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Channel_Patterns.pdf
- 84. 84 Typical Software FI Countermeasures* • Redundant checks • Defensive coding –e.g. initialize return values as ‘error’ • Code flow integrity –i.e. assure the code follows the intended path • Random delays * https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Channel_Patterns.pdf
- 85. 85 Typical Software FI Countermeasures* • Redundant checks • Defensive coding –e.g. initialize return values as ‘error’ • Code flow integrity –i.e. assure the code follows the intended path • Random delays * https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Channel_Patterns.pdf This sounds easy…
- 86. 86 It is not.
- 87. 87 It is not.
- 88. 88 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches!
- 89. 89 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches!
- 90. 90 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches!
- 91. 91 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches!
- 92. 92 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches!
- 93. 93 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches!
- 94. 94 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches!
- 95. 95 Where can we bypass secure boot using a glitch?
- 96. 96 We need automation to do this efficiently.
- 97. 97 We?!?
- 98. 98 The challenges of attackers & defenders are actually very similar!
- 99. 99 How can I glitch this device? How can my code be attacked? How do I know where to glitch? How can I make my code more robust?How do I know my glitch was succesfull? How can I give an attacker as little information as possible? What is the effect of this type of glitches on my target? Which attack method is better for this target? What is the effect of these changes on the glitchability? Attackers vs Defenders
- 100. 100 • No symbols, only the binary • Limited knowledge / documentation of hardware Attackers vs Defenders • Source code and a binary with symbols • Documentation available
- 101. 101 • No symbols, only the binary • Limited knowledge / documentation of hardware Attackers vs Defenders Biggest difference: Attackers need to reverse engineer the binary! • Source code and a binary with symbols • Documentation available
- 102. 102 Our solution?
- 104. 104 • Not a new idea! • Several existing simulators already available. • Nonetheless challenging to give useful results... Simulation
- 105. 105 • Not a new idea! • Several existing simulators already available. • Nonetheless challenging to give useful results... Simulation Why? Bunch of challenges…
- 106. 106 No hardware simulator = No fault simulator Challenge #1 © Icons8.com CC BY-ND 3.0
- 107. 107 Changing the binary is no option. Challenge #2 © Icons8.com CC BY-ND 3.0
- 108. 108 Challenge #3 Detecting successful glitches. © Icons8.com CC BY-ND 3.0
- 109. 110 Challenge #4 Using reasonable computational power. © Icons8.com CC BY-ND 3.0
- 110. 111 Challenge #5 Realistic simulation. © Icons8.com CC BY-ND 3.0
- 111. 112 What type of simulator do we use?
- 112. 113 • HDL simulator? What type of simulator do we use?
- 113. 114 • HDL simulator? • Full system emulators? (Gem5, QEMU, ...) What type of simulator do we use?
- 114. 115 • HDL simulator? • Full system emulators? (Gem5, QEMU, ...) • Smartcard simulators ?!?... What type of simulator do we use?
- 115. 116 • HDL simulator? • Full system emulators? (Gem5, QEMU, ...) • Smartcard simulators ?!?... • ??? What type of simulator do we use?
- 116. 117 • HDL simulator? • Full system emulators? (Gem5, QEMU, ...) • Smartcard simulators ?!?... • ??? • Our own?!? What type of simulator do we use?
- 117. 118 • Main ideas • Shortest path to reasonable results • Speed over accuracy • Reusing existing components • Binary-based; can be used by attackers and defenders • Glitches can be modelled by their observable effects in SW • Effects described through fault models Introduction to FiSim
- 118. 119 • Unicorn & Capstone based • Implements 2 realistic* fault models • Skipping individual instructions • Flipping a bit in the instruction encoding • Many more possible, easy to add FiSim Features * https://www.riscure.com/uploads/2017/09/Controlling-PC-on-ARM-using-Fault-Injection.pdf
- 119. 120 • Unicorn & Capstone based • Implements 2 realistic* fault models • Skipping individual instructions • Flipping a bit in the instruction encoding • Many more possible, easy to add FiSim Features * https://www.riscure.com/uploads/2017/09/Controlling-PC-on-ARM-using-Fault-Injection.pdf }corruption
- 120. 121 • Unicorn & Capstone based • Implements 2 realistic* fault models • Skipping individual instructions • Flipping a bit in the instruction encoding • Many more possible, easy to add FiSim Features * https://www.riscure.com/uploads/2017/09/Controlling-PC-on-ARM-using-Fault-Injection.pdf }corruption
- 121. 122 We tested several real bootloaders successfully!
- 122. 123 We tested several real bootloaders successfully! Let’s dive into the architectural details…
- 123. 124 Icons © Font Awesome CC BY 4.0 Hardware model Engine (Unicorn) Flash dump Console output (if any) Execution trace FiSim Architecture
- 124. 125 Icons © Font Awesome CC BY 4.0 Hardware model Engine (Unicorn) Flash dump Bad signature Good signature FiSim Architecture
- 125. 126 Icons © Font Awesome CC BY 4.0 (Unicorn) (Unicorn)Engine (Unicorn) Fault generator Execution trace Hardware model FiSim Architecture Flash dump (Bad signature)
- 126. 127 Hardware Model
- 127. 128 Hardware Model
- 128. 129
- 129. 130 Hardware Model
- 130. 131 Hardware Model
- 131. 132 Hardware Model Note: attacker needs to hardcode addresses!
- 132. 133 Hardware Model
- 133. 134 FiSim DEMO #1
- 134. 135 What did we glitch in the first demo?
- 135. 136 What did we glitch in the first demo? Who knows??!
- 136. 137 What did we glitch in the first demo? Many possibilities….
- 137. 138 Let’s harden our bootloader…
- 138. 139 What if we authenticate twice? Let’s harden our bootloader…
- 139. 140 FiSim DEMO #2
- 140. 141 • Is instruction corruption the only fault model? • We do not know… • Other fault models likely applicable too! • What is the impact of instruction / data caches? Limitations / Future work
- 141. 142 • Is instruction corruption the only fault model? • We do not know… • Other fault models likely applicable too! • What is the impact of instruction / data caches? Testing remains critical! Limitations / Future work
- 142. 143 Takeaways
- 143. 144 Takeaways • Fault attacks are effective to bypass secure boot
- 144. 145 Takeaways • Fault attacks are effective to bypass secure boot • Simulating is effective for attackers and defenders
- 145. 146 Takeaways • Fault attacks are effective to bypass secure boot • Simulating is effective for attackers and defenders • Actual testing still required for assurance
- 146. 147Secure boot under attack: Simulation to enhance fault injection & defenses Thank you! Any questions? Or come to us… Martijn Bogaard Senior Security Analyst martijn@riscure.com / @jmartijnb Niek Timmers Principal Security Analyst niek@riscure.com / @tieknimmers