HKG18-219: Threat Modeling for IoTDavid Brown

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

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

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?

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?

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

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)

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)

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

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

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

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

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

Thank You

#HKG18HKG18 keynotes and videos on: connect.linaro.orgFor further information: www.linaro.org