Sidestepping Common Pitfalls in IoT Security

1. Sidestepping Common Pitfalls in IoT Security Brent Wilson | staff security applications engineer Embedded World: February 26-28, 2019

2. The IoT is Growing… • Source: • https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/ silabs.com | @silabs

3. And so are the Security Problems… • Sources: • http://twimgs.com/custom_content/392809_DR18_December_Tech_Digest_F.pdf • https://www.wareable.com/smartwatches/kids-smartwatch-recall-european-commission-6961 • https://thehackernews.com/2019/02/xiaomi-electric-scooter-hack.html • https://autoweek.com/article/technology/your-car-still-vulnerable-hackers • https://limitedresults.com/2019/01/pwn-the-lifx-mini-white/ • https://blog.hackster.io/the-problem-with-throwing-away-a-smart-device-75c8b35ee3c7 silabs.com | @silabs

4. At least we want to avoid this… • Source: • https://unanything.fandom.com/wiki/Teletubby_Robots silabs.com | @silabs

5. Sidestepping Security Implementation Pitfalls

6. Pitfall #1: Thinking of Security like a Product • “Security is a process, not a product” – Bruce Schneier • Security must be considered during all phases of the product lifecycle, not just Design • Security is not Binary • There is no such thing as “perfect security” • Security is never “done” • Requires continuous monitoring and adaptation • Sources: • https://www.schneier.com/essays/archives/2000/04/the_process_of_secur.html silabs.com | @silabs

7. Failure to Lock Debug Interface / Failure to Secure Data at Rest • “Trashcan attack” – secrets and sensitive data can be recovered after device disposal • Flash could be extracted via unlocked debug interface • User Wifi credentials were stored in plaintext • Debug port unlocked • Secure Boot not enabled • Firmware encryption not enabled • Countermeasures: • Lock the debug interface and access to flash memory • Encrypt sensitive data prior to storage • Support “Factory Erase” to remove sensitive data when disposed of • Use Secure Boot, firmware encryption and other features supported by the hardware • Sources: • https://limitedresults.com/2019/01/pwn-the-lifx-mini-white/ silabs.com | @silabs

8. Failure to Secure Sensitive Data in Flight • The companion Smartphone app was shown to have “unencrypted communications with its backend server and the server enables unauthenticated access to data.” • This allowed for • Commanding the watch to call a phone number • Communication with the person wearing the watch • Locating the child through GPS • Countermeasures: • Support mutual authentication between devices, applications and cloud services • Use a secure protocol (https/TLS in this example) or enable the security provided by your wireless protocol • Sources: • https://www.wareable.com/smartwatches/kids-smartwatch-recall-european-commission-6961 silabs.com | @silabs

9. Using Hard-Coded Keys • Hard to protect • Accessible from source code • Accessible from binary via reverse engineering • Hard to change • Requires recompilation of source • Requires field firmware update • Countermeasures: • Use derived keys where possible (don’t store keys) • Support key expiration and rotation methods • Store keys in secure storage • Sources: • www.silabs.com Gecko SDK 2.5.0 “SLSTK3402A_aescrypt/test/main.c” silabs.com | @silabs

10. Using Insufficient Entropy for Random Number Generation • Random numbers are used everywhere in cryptography • Generation of secret keys, nonce’s, initialization vectors, etc. • A common implementation error is to use the native “rand()” function from ‘C’ • A pseudorandom number generator (PRNG) • Often not seeded or seeded with “time” • Not designed for cryptographic purposes • Can repeat after 232 -- subject to brute force or reverse engineering • Weak random numbers can reduce the effort required for a brute-force attack • Countermeasures: • Use a True Random Number Generator (TRNG) • ADC or radio can be used as a TRNG source with care* • Use a cryptographic PRNG that is periodically seeded from a TRNG source • Sources: • https://www.sitepoint.com/risks-challenges-password-hashing/ Rand() function True Random Number Generator silabs.com | @silabs

11. Using Weak or Broken Ciphers – Key Fob Cloning Attack Example • In 2017, researchers from KU Leuven University in Belgium were able to break DST40, which is a 40-bit cipher used in the early Tesla Model S key fobs • An attacker can unlock the doors and start the car (and drive away) • Tesla has since patched the issue • Countermeasures: • Use ciphers with strong key lengths (128* bits or more) • Too big to brute-force • Don’t use broken ciphers • DST40 was originally broken in 2005 by researchers from Johns Hopkins University and RSA Labs – exploited on a 2005 Ford Escape SUV • Sources: • https://www.esat.kuleuven.be/cosic/fast-furious-and-insecure-passive-keyless-entry-and-start-in-modern-supercars/ • https://www.usenix.org/legacy/event/sec05/tech/bono/bono.pdf silabs.com | @silabs

12. Using AES Electronic Code Book Mode (AES_ECB) • In AES_ECB, each 16-byte block of plaintext is encrypted with a Key to generate a 16-byte block of ciphertext • Problem – any given 16-byte input encrypted using the same Key will result in the same cipher text output • This can reveal patterns in the input data, which violates Confidentiality • Countermeasures: • Use a different block mode such as AES Cipher Block Chaining or AES Counter mode • Sources: • https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#ECB-weakness • Acknowledgements: lewing@isc.tamu.edu and The GIMP Encrypted with AES_ECB Plaintext Encrypted with AES_CBC silabs.com | @silabs

13. Failing to Account for Side-Channel Attacks • Side channel attacks monitor the physical attributes of an implementation while it is performing a cryptographic operation in order to extract information about the operation, such as the value of an encryption key • Common physical measurements are timing and power consumption (Differential Power Analysis – DPA) • Hardware can be inexpensive, and sophisticated statistical methods can be used to recover keys • Countermeasures: • Hardware cryptographic implementations tend to be more robust against side-channel attacks than software implementations • DPA-resistant hardware implementations are available • Sources: • https://www.theregister.co.uk/2017/06/23/aes_256_cracked_50_seconds_200_kit/ • https://newae.com/tools/chipwhisperer/ silabs.com | @silabs

14. Failing to Account for Physical Attacks • Physical attacks can include environmental tamper or glitch attacks • Goal is often to generate a fault or to force a bad security decision • Physical attacks can be invasive • Netlist and flash extraction • Countermeasures: • Tamper – detect and respond • Glitch – harden code around security decisions • Invasive – secure key storage technology such as a Physically Unclonable Function (PUF) • And prayer • Sources: • https://twitter.com/foolsdelight/status/758780620470362112 silabs.com | @silabs

15. Conclusion and Recommendations • Don’t use weak ciphers, weak protocols or broken ciphers. • Use a cryptographic entropy source (TRNG) or TRNG-seeded PRNG (CTR_DRBG) for all your random number needs. Alternatively, you can use an ADC or RF receiver as an entropy source, with proper care. • If encrypting a data stream, Don’t use AES_ECB. Use AES_CBC or AES_CTR instead. • Be aware of the ease of DPA attacks to extract keys. If needed, design your system with DPA-resistant hardware crypto engines. • Be aware of tamper attacks and design the system with detection and response protocols if needed. • Also, be aware of physical attacks on the die that can be used to extract contents from flash memory. Provision your system with a device that supports secure key storage using PUF technology if needed. • Remember that Security is a Process, and it’s never “done”. • Design for resilience. Plan for vulnerabilities to be discovered, and provision your system with a secure firmware update capability. Use secure boot features to ensure that only authorized code can run on the device. Lock debug interfaces. • Never store keys or sensitive data in plaintext. Never transmit sensitive data in the clear. Ideally, support the erasure of sensitive information at the end of the product’s life. • Authenticate your device and what it connects to, ideally using a method that supports revocation such as a certificate-based public-key scheme. • Use all the security capabilities supplied by your standards-based wireless protocol. Add authentication or application-level encryption on top if needed. • Don’t hard-code keys or sensitive data in the source code. • Rotate keys periodically, every 1 to 3 years at least, and support key revocation. silabs.com | @silabs

16. Thank you