Side-Channel Attacks

A side-channel attack targets a cryptographic implementation. The methodology is to monitor the physical attributes of the system, such as power consumption, EMI emissions, or timing of various functions while the system is performing a cryptographic operation to extract information about that operation, such as the value of an encryption key.

Differential Power Analysis (DPA) is a side-channel attack technique that can be highly effective at modest cost. DPA measures the time domain response of the supply current, a “trace” (measured in-circuit or via EMI radiation) during a cryptographic operation. Changes in the trace behavior due to processing a “1” bit or a “0” bit can reveal information about the bits being processed. This is referred to as “leaking” information. The DPA resistance of an implementation can be specified by the number of traces that are required to extract a key to a specified confidence level. Cryptographic operations are based on math, and math operations such as addition and multiplication take different amounts of time and energy to process. For MCU-class systems, software implementations of crypto operations tend to be leakier than hardware implementations. Fortunately, suppliers are introducing new crypto hardware accelerators with DPA-hardening features that mask the data dependencies during the cryptographic operation, making the system much more resilient to this type of attack.

Physical Attacks

By their nature, IoT systems are often physically accessible, which leaves them vulnerable to physical attacks. A “tamper” attack is a type of hardware fault injection in which the system is exercised outside its specified limits of temperature, voltage, or clock frequency. These can also include “glitch” attacks initiated through an EMI burst or a short electrical disturbance on a pin. This precision attack occurs during a critical timing window when a security decision is being made (such as “lock flash” or “authenticate remote device”) to disable security protections or to grant access.

Tamper attacks are hard to prevent, but they can often be detected, and if detected, they can be thwarted. Many MCUs and SoCs are being provisioned with advanced tamper detection and response capabilities enabling them to either send an alert in the event of a tamper detection or erase their secrets to prevent exposure.

Highly invasive physical attack techniques include device removal, die deprocessing, netlist extraction and flash contents extraction. Unfortunately, if an attacker is willing to undertake this level of effort and investment, it’s very difficult to protect all the secrets. There are, however, some secure key storage techniques that enable keys and other sensitive data to be automatically encrypted before being written to storage using Physically Unclonable Function (PUF) technology. The PUF generates a device-unique ephemeral key that only exists while the device is powered and cannot be revealed using the physical extraction methods described above. The PUF key is used to encrypt and decrypt keys stored and read from flash memory.

Protecting an IoT device from physical attacks is often difficult and cost-prohibitive. The best defense is often to remove the incentive an attacker would gain from mounting a physical exploit. If hacking your connected porch light yields the key to unlock your connected door lock, that’s bad. If hacking a connected door lock yields the “key” to unlock all the other connected locks in an apartment complex, that’s tragic. What if hacking a connected light bulb gave access to all the connected lights in a city? What level of effort would that be worth?

The methods described above of using and verifying unique device certificates for authentication and using ephemeral derived keys for encrypting network traffic along with minimizing the amount of valuable information stored on the IoT device will help discourage physical attacks.

Conclusion and Additional Recommendations

In summary, here are best practices for addressing common IoT security pitfalls:

• 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.
• Use proven cryptography protocols -- don’t try to invent your own.
• 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 use weak ciphers, weak protocols or broken ciphers.
• 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.
• If encrypting a data stream, use AES_CCM for strong authenticated encryption. Don’t use AES_ECB.
• Use a randomly-generated initialization vector (IV) and use it only once (nonce).
• Don’t hard-code keys or sensitive data in the source code.
• Rotate keys periodically, every one to three years at least, and support key revocation.
• 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 your product is physically accessible, try to limit the incentive and increase the cost of a physical attack by limiting key usage, avoiding storing valuable information, encrypting all stored sensitive information, locking the debug interface, etc.
• 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 silicon 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.

About the Author

Brent Wilson is a Staff Security Applications Engineer for IoT products at Silicon Labs. Brent joined Silicon Labs in 2003 as part of the Cygnal acquisition and has served leadership roles in both applications and systems engineering for microcontroller and wireless products. Prior to Silicon Labs, he worked at Cirrus Logic, specializing in professional audio and seismic-class ADCs and wired and wireless communications devices. He holds a Bachelor of Science in Electrical Engineering from the University of Texas at Austin.