Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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