Secure boot under attack: Simulation to enhance fault injection & defenses

Transcription

1 Secure boot under attack: Simulation to enhance fault injection & defenses Martijn Bogaard Senior Security Analyst Niek Timmers Principal Security Analyst 1

2 Today s agenda 2

3 Today s agenda Crash course secure boot on embedded devices 3

4 Today s agenda Crash course secure boot on embedded devices Crash course fault injection (FI) attacks 4

5 Today s agenda Crash course secure boot on embedded devices Crash course fault injection (FI) attacks Using simulation to identify FI vulnerabilities 5

6 Why do we need secure boot? System-on-Chip Boot code Processor Kernel SRAM ROM OTP Flash DDR 6

7 Why do we need secure boot? System-on-Chip Boot code Processor Kernel SRAM ROM OTP Flash 1 DDR 7

8 Why do we need secure boot? System-on-Chip Boot code Processor Kernel SRAM ROM OTP Flash Boot code 2 1 DDR 8

9 Why do we need secure boot? System-on-Chip Boot code Processor Kernel Flash SRAM Boot code ROM 2 1 OTP Kernel 3 DDR 9

10 Threat 1: Hardware Hacker Why do we need secure boot? System-on-Chip Boot code Processor Kernel Flash SRAM Boot code ROM 2 1 OTP Kernel 3 DDR 10

11 Threat 1: Hardware Hacker Why do we need secure boot? System-on-Chip Threat 2: Malware Boot code Processor Kernel Flash SRAM Boot code ROM 2 1 OTP Kernel 3 DDR 11

12 Threat 1: Hardware Hacker Why do we need secure boot? System-on-Chip Threat 2: Malware Boot code Processor Kernel Flash SRAM Boot code ROM 2 1 OTP Kernel 3 DDR Secure boot assures integrity of code/data in cold storage! 12

13 The real world is more complex! 13

14 The real world is more complex! Higher privileges ROM Secure World Lower privileges EL3 14

15 The real world is more complex! Higher privileges ROM BLx Secure World Lower privileges EL3 EL1 15

16 The real world is more complex! Higher privileges ROM EL3 EL1 BLx Secure World EL3 ATF Lower privileges 16

17 The real world is more complex! Higher privileges ROM BLx Secure World ATF Lower privileges EL3 EL1 EL3 EL1 U-Boot Non-Secure World 17

18 The real world is more complex! Higher privileges ROM BLx Secure World ATF TEE OS TEE Apps Lower privileges EL3 EL1 EL3 EL1 EL0 EL1 EL1 EL0 Boot finished! U-Boot Non-Secure World Linux Kernel Linux Apps The chain can break at any stage. Early is better! 18

19 Breaking Secure Boot early 19

20 Breaking Secure Boot early Early boot stage run at the highest privilege E.g. unrestricted access 20

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 21

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 22

23 What makes Secure Boot secure? 23

24 What makes Secure Boot secure? Unbreakable cryptography Right? 24

25 Flow of a typical boot stage 25

26 Flow of a typical boot stage Start 26

27 Flow of a typical boot stage Start Check this 27

28 Flow of a typical boot stage Start Check that Check this 28

29 Flow of a typical boot stage Start Check that Check this Configure this 29

30 Flow of a typical boot stage Start Check that Configure that Check this Configure this 30

31 Flow of a typical boot stage Start Check that Configure that Check this Configure this Load next stage 31

32 Flow of a typical boot stage Start Check that Configure that Decrypt next stage Check this Configure this Load next stage 32

33 Flow of a typical boot stage Start Check that Configure that Decrypt next stage Check this Configure this Load next stage Authenticate next stage 33

34 Flow of a typical boot stage Start Check that Configure that Decrypt next stage Jump to next stage? Check this Configure this Load next stage Authenticate next stage 34

35 Flow of a typical boot stage Start Check that Configure that Decrypt next stage Jump to next stage? Check this Configure this Load next stage Authenticate next stage Lots of functionality! What can go wrong? 35

36 Flow of a typical boot stage Start Check that Configure that Decrypt next stage Jump to next stage? Check this Configure this Load next stage Authenticate next stage Lots of functionality! What can goes go wrong!? wrong? 36

37 No authentication! 37

38 Software vulnerabilities! 38

39 Hardware vulnerabilities! eu-16-timmers-bypassing-secure-boot-using-fault-injection.pdf 39

40 Why hardware attacks on secure boot? 40

41 Why hardware attacks on secure boot? Usually a small code base 41

42 Why hardware attacks on secure boot? Usually a small code base Limited attack surface 42

43 Why hardware attacks on secure boot? Usually a small code base Limited attack surface Should be extensively reviewed 43

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 44

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! 45

46 Voltage Fault Injection in practice 46

47 Voltage Fault Injection in practice 47

48 Voltage Fault Injection in practice 48

49 Voltage Fault Injection in practice 49

50 Voltage Fault Injection in practice 50

51 Voltage Fault Injection in practice 51

52 Voltage Fault Injection in practice 52

53 Voltage Fault Injection in practice 53

54 Voltage Fault Injection in practice 54

55 Voltage Fault Injection in practice USB 55

56 Voltage Fault Injection in practice USB VCC 56

57 Voltage Fault Injection in practice USB VCC Reset 57

58 time 58

59 time 59

60 1.2 V 0.9 V time 60

61 1.2 V 0.9 V time 61

62 1.2 V 0.9 V time 62

63 Let s do this live on stage! What could possibly go wrong. 63

64 Fault Injection Demo 64

65 Fault Injection Demo BL1 U-Boot We do not modify U-Boot in flash. 65

66 Fault Injection Demo BL1 U-Boot We do not modify U-Boot in flash. BL1 U-Boot We do modify the U-Boot in flash. 66

67 Fault Injection Demo BL1 U-Boot We do not modify U-Boot in flash. BL1 U-Boot We do modify the U-Boot in flash. BL1 U-Boot 67

68 Fault Injection Demo BL1 U-Boot We do not modify U-Boot in flash. BL1 U-Boot We do modify the U-Boot in flash. BL1 U-Boot PWNED 68

69 Successful Glitch! Want to know more? Please meet us after the talk! 69

70 Why does this work? What goes wrong? Difficult to answer. But, behaviorally we can say a lot! 70

71 What can we do with our glitches? 71

72 What can we do with our glitches? Modify memory contents 72

73 What can we do with our glitches? Modify memory contents Modify register contents 73

74 What can we do with our glitches? Modify memory contents Modify register contents Modify the executed instructions!!! 74

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! 75

76 What about unglitchable hardware? 76

77 What about unglitchable hardware? Yes. But difficult & expensive. 77

78 What about using only software? 78

79 What about using only software? Sure. 79

80 Typical Software FI Countermeasures* * 80

81 Typical Software FI Countermeasures* Redundant checks * 81

82 Typical Software FI Countermeasures* Redundant checks Defensive coding e.g. initialize return values as error * 82

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 * 83

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 * 84

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 This sounds easy * 85

86 It is not. 86

87 It is not. 87

88 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches! 88

89 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches! 89

90 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches! 90

91 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches! 91

92 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches! 92

93 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches! 93

94 It is not. Redundant checks needs multiple glitches? Remember, we can modify instructions using glitches! 94

95 Where can we bypass secure boot using a glitch? 95

96 We need automation to do this efficiently. 96

97 We?!? 97

98 The challenges of attackers & defenders are actually very similar! 98

99 Attackers vs Defenders How can I glitch this device? How do I know my glitch was succesfull? Which attack method is better for this target? How do I know where to glitch? How can my code be attacked? How can I make my code more robust? What is the effect of these changes on the glitchability? How can I give an attacker as little information as possible? What is the effect of this type of glitches on my target? 99

100 Attackers vs Defenders No symbols, only the binary Limited knowledge / documentation of hardware Source code and a binary with symbols Documentation available 100

101 Attackers vs Defenders No symbols, only the binary Limited knowledge / documentation of hardware Source code and a binary with symbols Documentation available Biggest difference: Attackers need to reverse engineer the binary! 101

102 Our solution? 102

103 Our solution? Simulation! 103

104 Simulation Not a new idea! Several existing simulators already available. Nonetheless challenging to give useful results

105 Simulation Not a new idea! Several existing simulators already available. Nonetheless challenging to give useful results... Why? Bunch of challenges 105

106 Challenge #1 No hardware simulator = No fault simulator Icons8.com CC BY-ND

107 Challenge #2 Changing the binary is no option. Icons8.com CC BY-ND

108 Challenge #3 Detecting successful glitches. Icons8.com CC BY-ND

109 Challenge #4 Using reasonable computational power. Icons8.com CC BY-ND

110 Challenge #5 Realistic simulation. Icons8.com CC BY-ND

111 What type of simulator do we use? 112

112 What type of simulator do we use? HDL simulator? 113

113 What type of simulator do we use? HDL simulator? Full system emulators? (Gem5, QEMU,...) 114

114 What type of simulator do we use? HDL simulator? Full system emulators? (Gem5, QEMU,...) Smartcard simulators?!?

115 What type of simulator do we use? HDL simulator? Full system emulators? (Gem5, QEMU,...) Smartcard simulators?!?...??? 116

116 What type of simulator do we use? HDL simulator? Full system emulators? (Gem5, QEMU,...) Smartcard simulators?!?...??? Our own?!? 117

117 Introduction to FiSim 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 118

118 FiSim Features Unicorn & Capstone based Implements 2 realistic* fault models Skipping individual instructions Flipping a bit in the instruction encoding Many more possible, easy to add * 119

119 FiSim Features Unicorn & Capstone based Implements 2 realistic* fault models Skipping individual instructions Flipping a bit in the instruction encoding Many more possible, easy to add } corruption * 120

120 FiSim Features Unicorn & Capstone based Implements 2 realistic* fault models Skipping individual instructions Flipping a bit in the instruction encoding Many more possible, easy to add } corruption * 121

121 We tested several real bootloaders successfully! 122

122 We tested several real bootloaders successfully! Let s dive into the architectural details 123

123 FiSim Architecture Hardware model Flash dump Engine (Unicorn) Console output (if any) Execution trace Icons Font Awesome CC BY

124 FiSim Architecture Hardware model Flash dump Engine (Unicorn) Good signature Bad signature Icons Font Awesome CC BY

125 FiSim Architecture Execution trace Hardware model Flash dump (Bad signature) Fault generator (Unicorn) (Unicorn) Engine (Unicorn) Icons Font Awesome CC BY

126 Hardware Model 127

127 Hardware Model 128

128 129

129 Hardware Model 130

130 Hardware Model 131

131 Hardware Model Note: attacker needs to hardcode addresses! 132

132 Hardware Model 133

133 FiSim DEMO #1 134

134 What did we glitch in the first demo? 135

135 What did we glitch in the first demo? Who knows??! 136

136 What did we glitch in the first demo? Many possibilities. 137

137 Let s harden our bootloader 138

138 Let s harden our bootloader What if we authenticate twice? 139

139 FiSim DEMO #2 140

140 Limitations / Future work 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? 141

141 Limitations / Future work 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! 142

142 Takeaways 143

143 Takeaways Fault attacks are effective to bypass secure boot 144

144 Takeaways Fault attacks are effective to bypass secure boot Simulating is effective for attackers and defenders 145

145 Takeaways Fault attacks are effective to bypass secure boot Simulating is effective for attackers and defenders Actual testing still required for assurance 146

146 Thank you! Any questions? Or come to us Martijn Bogaard Senior Security Analyst Niek Timmers Principal Security Analyst Secure boot under attack: Simulation to enhance fault injection & defenses 147