HKG18-219 - Threat Modeling for IoT
1 like461 views
The document discusses threat modeling for Internet of Things (IoT) security, highlighting the discovery of vulnerabilities in IoT devices, including examples like the Mirai botnet and Jeep hacking. It contrasts two threat modeling approaches: one focusing on system architecture and the other on policy and capability, emphasizing the importance of validating sensor data and secure software updates. The document concludes that threat models should be dynamic and guide development priorities as new application areas emerge.
HKG18-219 - Threat Modeling for IoT
- 1. HKG18-219: Threat Modeling for IoT David Brown
- 2. IoT Security ● 2016 DEF Con, found 47 new vulnerabilities in 23 IoT devices ● Mirai Botnet https://www.theguardian.com/technology/2016/oct/26/ddos-attack-dyn-mirai- botnet targeted DDoS attack, cameras, DVRs, etc ● TRENDnet Webcam: http://www.technewsworld.com/story/78891.html, vulnerable camera could be viewed externally
- 3. IoT Security (cont.) ● Jeep: https://blog.kaspersky.com/blackhat-jeep-cherokee-hack-explained/9493/ over cell network took control of a Jeep. ○ WiFi password wasn’t very random, guess space in the dozens ○ Chained through vulnerability in multimedia computer ○ CAN bus isolation failed with vulnerability in an MCU that could be “upgraded” without authentication ○ Total control over vehicle, including brakes and steering
- 4. Threat Modeling ● “Threat Modeling: Designing for Security”, by Adam Shostack ○ What are you building? ○ What can go wrong? ○ What should you do about those things that can go wrong? ○ Did you do a decent job of analysis?
- 5. Threat Modeling (cont.) ● Nickolai Zeldovich, https://youtu.be/GqmQg-cszw4: MIT 6.858 Computer Systems Security, Fall 2014, Introduction, Threat Models ○ Policy: What is the desired behavior (what is and isn’t allowed)? ○ Threat Model: What is the attacker capable of? ○ Mechanism: What do we do about it?
- 6. Threat Modeling (cont.) ● Two approaches ● Shostack focuses on architecture of system ● Zeldovich focuses on policy and capability ● I found Zeldovich’s approach easier to organize and follow
- 7. The example app ● Important to focus on a specific application, ● Can also focus on a specific part, such as a protocol (but be careful, see Jeep example, parts interact)
- 9. High-level example ● Policy: The data collection host should be able to determine that a given sensor device is valid, and only accept data from valid sensors ● Threat: ○ Attacker can generate arbitrary network packets ○ Attacker cannot brute-force modern crypto algorithms ○ Attacker cannot read from the device’s internal flash ● Mechanism: ○ Enforce DTLS with PSK ciphersuite ● Thoughts: ○ How do we get the secret onto the device ○ Take LWM2M: network secret negotiates device secret ○ (secrets are important, see HKG18-407)
- 10. High-level example ● Policy: The data collection host should be able to determine that a given sensor device is valid, and only accept data from valid sensors ● Threat: ○ Attacker can generate arbitrary network packets ○ Attacker cannot brute-force modern crypto algorithms ○ Attacker can read from the device’s internal flash ● Attacker can spoof device (violating policy) ● Not obvious, though: ○ Buffer overflow in a protocol allows read of arbitrary memory ○ SWD/JTAG: forget fuses, or reverse fuses ○ Flash protected from read, but CRC reads and can be watched
- 11. Policy Interaction ● Two policies: ○ Policy: The data collection host should be able to determine that a given sensor device is valid, and only accept data from valid sensors ○ Policy: When sensor data is available, it should be sent to the data collection host in a timely manner ● Not only prevent attacks, but prevent denial of service: ○ Jam network ○ Bogus packets cause device to be rejected
- 12. Lower-level example ● Concerning software update: ○ The device should accept upgrades from a valid upgrade host and run these new versions ○ The device should only accept upgrades from a valid upgrade host ● Threat: ○ The attacker can spoof network traffic from upgrade host ○ The attacker can reply old data ○ The attacker cannot break RSA ● Mechanism: ○ Digitally sign images with RSA ○ Have increase-only version numbers
- 13. Lower-level example ● Concerning software update: ○ The device should accept upgrades from a valid upgrade host and run these new versions ○ The device should only accept upgrades from a valid upgrade host ● Threat: ○ The attacker can spoof network traffic from upgrade host ○ The attacker can reply old data ○ The attacker cannot break RSA ● Attack: ○ The attacker spoofs upgrade host ○ Sends invalid upgrades, with bad signatures ○ Device drains battery, or wears out flash repeatedly rejecting the upgrade ● This one is hard
- 14. Conclusions ● Model document will be dynamic ● Use model to drive development priorities ○ e.g. storing secrets ● Will grow as we move to new application areas
- 15. Thank You #HKG18 HKG18 keynotes and videos on: connect.linaro.org For further information: www.linaro.org