Silicon Labs Silicon Labs Community
silabs.com
Language
  • 简体中文
  • 日本語
  • MCUs
    • 8-bit MCU
    • 32-bit MCU
  • Wireless
    • Bluetooth
    • Proprietary
    • Wi-Fi
    • Zigbee & Thread
    • Z-Wave
  • More Products
    • Interface
    • Isolation
    • Power
    • Sensors
    • Timing
  • Development Tools
    • Simplicity Studio
    • Third Party Tools
    • Thunderboard
  • Expert's Corner
    • Announcements
    • Blog
    • General Interest
    • Projects
  1. Community - Silicon Labs
  2. Blog

IoT Security: Encryption Strength

03/74/2016 | 01:37 PM
Lance Looper
Employee

Level 5


What is Encryption?

Encryption is the process of encoding a message so that only an authorized person may read it. This provides the tools to implement the security primitives for confidentiality and authentication.

 

Data is encrypted for various reasons in an embedded IoT system. Wireless or wired communication systems encrypt the data payload to prevent eavesdropping. Computer systems often encrypt data stored on hard drives to prevent data theft. Likewise, embedded systems might encrypt data stored in flash memory. While internal flash memory might contain some physical security protection, external flash memory usually does not, because the bus between the main processor and the external component is inevitably exposed. Thus, it is common to encrypt external flash memory. Embedded code is encrypted to protect intellectual property and prevent someone from copying your software.

 

Symmetric Encryption uses the same key for both encryption and decryption. Because the key is the same, both parties must have access to the same secret key. If the key is compromised, the encryption is worthless. This is also called private key encryption, in contrast to public key encryption which has a public non-secret key.

 

Considerations when choosing key length

Most AES hardware encryption supports 128-bit and 256-bit keys. When discussing key lengths, it is common to measure the strength of the key based on the number of trials necessary to find the correct key. Thus, if no shortcuts or weaknesses in a cipher exists, this means that breaking 128-bit or 256-bit encryption involves a brute-force attack with 2^128 or 2^256 number of trials respectively. There are a number of theoretical attacks on AES that reduce the number of trials slightly. Meanwhile, none of these attacks allows breaking AES for either key-length.

 

Thus, considering only currently publicly known attacks, both 128-bit and 256-bit keys will provide adequate security. While 128-bit encryption might be perfectly secure today, no one knows what the future might hold. Today, DES with a 56-bit key is widely considered insecure. In ten years, it is possible that a 128-bit key might be considered too small, or weaknesses might have been discovered that compromise 128-bit keys but not 256-bit keys. Thus, it might be prudent to use 256-bit encryption for anything that requires long term security over 10 years. This is likely why the US National Security Agency (NSA) recommends 256-bit encryption to protection US government information up to the TOP SECRET classification level. This is part of the NSA Suite B guidelines.

 

As a final note on key lengths, the reality is that most systems are hacked not by cracking the encryption, but by gaining access to the secret key. Protecting the secret key is the Achilles’ heel of symmetric encryption.

 

While it is possible to implement encryption/decryption in software, it will be much faster to use an MCU with hardware AES. Hardware encryption using a 128-bit key is typically 128 clock cycles or less. It is as low as 54 clock cycles on some EFM32 devices. Software encryption is more than ten times slower.

The AES cipher has a fixed block size of 128-bits or 16-bytes. This is just fine if your data was always 16-bytes. But what should you do if you have 64 bytes of data, or 59 bytes of data, or only 9 bytes of data?

If your data is shorter than 16 bytes, it is common practice to pad the data with zeros. So if you have nine bytes of data, the remaining seven bytes are all zeros. This might seem wasteful to spend effort and energy to encrypt zeros, but it is necessary for the encryption. Each bit of the encrypted output depends on all 128 bits of input data. This means that a wireless network must transmit at least 16-bytes of encrypted data even if the payload is only one byte.

 

Some security experts will caution against padding data with zeros. There are known attacks against authenticated encryption modes such as the padding oracle attack. However, this attack really does not apply to the basic AES cipher. It depends on getting feedback from the recipient on whether the padding is correct or not. In any case, the solution is to pad with random data instead of zeros.

 

When the unencrypted data (plaintext) length is greater than 16 and not a multiple of 16, there will be a number of whole blocks and one fractional block. Only the last block is padded with zeros.

 

While it is possible to use the basic AES cipher to encrypt many blocks of data, it easily introduces other security issues. For instance, if the plaintext is identical for two block, the ciphertext would be as well, and an attacker would know. Therefore, it is necessary to use a cipher block mode that effectively uses a different secret key for every block. The various cipher block modes will be discussed over the next blog posts.

 

Check out the previous blog in this series here.

  • Blog Posts
  • Internet Infrastructure
  • Timing
  • Internet of Things

Tags

  • Wireless
  • High Performance Jitter Attenuators
  • EFR32MG21 Series 2 SoCs
  • Blue Gecko Series 2
  • Zigbee SDK
  • ZigBee and Thread
  • Internet Infrastructure
  • Sensors
  • Blue Gecko Bluetooth Low Energy SoCs
  • Z-Wave
  • Micrium OS
  • Blog Posts
  • Low Jitter Clock Generators
  • Bluetooth Classic
  • Makers
  • Flex SDK
  • Tips and Tricks
  • Smart Homes
  • IoT Heroes
  • Reviews
  • RAIL
  • Simplicity Studio
  • Mighty Gecko SoCs
  • Timing
  • Blue Gecko Bluetooth Low Energy Modules
  • Clocks
  • Ultra Low Jitter Clock Generators
  • General Purpose Clock Generators
  • Industry 4.0
  • Giant Gecko
  • 32-bit MCUs
  • blue-gecko-xpress-modules
  • Bluetooth Low Energy
  • 32-bit MCU SDK
  • Gecko
  • Microcontrollers
  • News and Events
  • Industrial Automation
  • Wi-Fi
  • Bluetooth SDK
  • Community Spotlight
  • Biometric Sensors
  • General Purpose Jitter Attenuators
  • Giant Gecko S1
  • Flex Gecko
  • Internet of Things
  • 8-bit MCUs
  • Isolation
  • Powered Devices

Top Authors

  • Avatar image Mark Mulrooney
  • Avatar image Siliconlabs
  • Avatar image Nari Shin
  • Avatar image lynchtron
  • Avatar image deirdrewalsh
  • Avatar image Lance Looper
  • Avatar image lethawicker

Archives

  • 2014 December
  • 2015 January
  • 2015 February
  • 2015 March
  • 2015 April
  • 2015 May
  • 2015 June
  • 2015 July
  • 2015 August
  • 2015 September
  • 2015 October
  • 2015 November
  • 2015 December
  • 2016 January
  • 2016 February
  • 2016 March
  • 2016 April
  • 2016 May
  • 2016 June
  • 2016 July
  • 2016 August
  • 2016 September
  • 2016 October
  • 2016 November
  • 2016 December
  • 2017 January
  • 2017 February
  • 2017 March
  • 2017 April
  • 2017 May
  • 2017 June
  • 2017 July
  • 2017 August
  • 2017 September
  • 2017 October
  • 2017 November
  • 2017 December
  • 2018 January
  • 2018 February
  • 2018 March
  • 2018 April
  • 2018 May
  • 2018 June
  • 2018 July
  • 2018 August
  • 2018 September
  • 2018 October
  • 2018 November
  • 2018 December
  • 2019 January
  • 2019 February
  • 2019 March
  • 2019 April
  • 2019 May
  • 2019 June
  • 2019 July
  • 2019 August
  • 2019 September
  • 2019 October
  • 2019 November
Silicon Labs
  • About Us
  • In the News
  • Email Newsletter
  • Cookies
  • Contact Us
  • Community
  • Site Feedback
  • Investor Relations
  • Blog
  • Privacy and Terms
  • Corporate Citizenship
Copyright © Silicon Laboratories. All rights reserved.
粤ICP备15107361号-1