Sidestepping Common Pitfalls in IoT SecurityB R E N T W I L S O N | S T A F F S E C U R I T Y A P P L I C A T I O N S E N G I N E E R

E M B E D D E D W O R L D : F E B R U A R Y 2 6 - 2 8 , 2 0 1 9

The IoT is Growing…

§ Source:§ https://www.statista.com/statistics/471264/iot-number-of-

connected-devices-worldwide/

silabs.com | @silabs

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

At least we want to avoid this…

§ Source:§ https://unanything.fandom.com/wiki/Teletubby_Robots

silabs.com | @silabs

Sidestepping Security Implementation Pitfalls

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_proce

ss_of_secur.html

Analyze

Architect

ImplementManage

Adapt

silabs.com | @silabs

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

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

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

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/

True Random Number Generator Rand() function

silabs.com | @silabs

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

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

Plaintext Encrypted with AES_ECB Encrypted with AES_CBC

silabs.com | @silabs

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_5

0_seconds_200_kit/§ https://newae.com/tools/chipwhisperer/

silabs.com | @silabs

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

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

Thank you