Session ID: HKG18-219 Session Name: HKG18-219 - Threat Modeling for IoT Speaker: David Brown Track: Iot, Security ★ Session Summary ★ Security is important for IoT. This presentation will cover security threat modeling LITE has been doing. --------------------------------------------------- ★ Resources ★ Event Page: http://connect.linaro.org/resource/hkg18/hkg18-219/ Presentation: http://connect.linaro.org.s3.amazonaws.com/hkg18/presentations/hkg18-219.pdf Video: http://connect.linaro.org.s3.amazonaws.com/hkg18/videos/hkg18-219.mp4 --------------------------------------------------- ★ Event Details ★ Linaro Connect Hong Kong 2018 (HKG18) 19-23 March 2018 Regal Airport Hotel Hong Kong --------------------------------------------------- Keyword: Iot, Security 'http://www.linaro.org' 'http://connect.linaro.org' --------------------------------------------------- Follow us on Social Media https://www.facebook.com/LinaroOrg https://www.youtube.com/user/linaroorg?sub_confirmation=1 https://www.linkedin.com/company/1026961

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