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 Part 3: What’s the Deal with Block Cipher Block Modes?

03/84/2016 | 07:44 PM
kberringer
Employee

Level 4


A cipher block mode is a method of manipulating blocks of data using the AES cipher to improve security. The AES cipher is an atomic operation on 128-bits of data. Normally the plaintext goes into the cipher and the ciphertext comes out of the cipher. But there are other ways to use the cipher.

 

Why should we use a block cipher mode? First, consider the case where we are encrypting many blocks of data. If we encrypt data using the same key every time and using the same method, we give a clue about the encryption. If we just use the basic cipher in the electronic code book mode using the same key, we are opening ourselves up to a black box brute force attack.

 

The block cipher modes mix it up a bit. Each block of data is encrypted differently than the last block. This makes it harder to guess the encryption key. It is effectively like using a different key each time. For data security encryption, the most commonly used cipher block mode is the counter (CTR) mode.

 

The counter mode uses the basic cipher in a convoluted way. Instead of encrypting the plaintext, the cipher encrypts the counter value. The counter value is concatenated together with a Nonce before encryption. A Nonce is a “number used once” and is similar to an initialization value. Both the sender and the recipient must use the exact same Nonce for it to work. The output from the cipher is exclusive OR’ed with the plaintext.

 

Counter Mode Encryption.png

 

The exclusive OR operation is very commonly used in block cipher modes. Any time plain text is exclusive ORed with some secret key, it is impossible to determine the original key from the ciphertext. This is known in cryptography as a One Time Pad.

 

The counter mode potentially improves the security of the system by extending the 16-byte AES cipher to an arbitrary long cipher. It converts a block cipher to a stream cipher. To decrypt data encrypted using the counter mode, we need to know the key, the Nonce, and the block count.

 

Because the block count changes each time, the encrypted data for each block is unique. Suppose we encrypted the same 16 bytes of data repeating four times. The electronic code book (ECB) mode would be to just apply the AES cipher to each block of code. When using the ECB mode, if the data repeats, then the encrypted data will also repeat. Unlike the electronic code book mode, the counter mode encrypted data would not repeat.

 

Encrypted Data.png

 

If data changed only one bit each time, the ECB mode might give use information that will help us guess the key. Changing one bit each time using the counter mode will not give us much information. The CTR mode provides protection against a Replay attack. A replay attack is a systematic cryptographic attack that involves eaves dropping on a conversation, and then playing back part of the encrypted conversation, a password for example. If the counter value is different each time, this ensures uniqueness.

 

In IEEE802.15.4 networks, the counter value starts at zero and increments for each block in the payload. The Nonce security material includes the frame counter and the key sequence counter. The frame counter increments with each frame transmitted. Thus, it is the Nonce and not really the counter value that establishes a session and ensures session uniqueness.

 

Theoretically, the counter mode allows random access. Suppose we encrypt data and store it in an external Flash using CTR mode. We don’t have to decrypt the entire Flash from the beginning. We can just read out the block we want, use the address for the counter value, and decrypt it.

 

There are several different methods to implement counter mode on an MCU with built in AES encryption. The method will depend on the hardware resource of the particular MCU. The Gecko devices have an AES block with XOR capability. The AN0033 explains the Block Cipher Modes in detail and how to implement them on EFM devices.

 

The new Wireless Gecko EFR32 SoCs and the Pearl and Jade Gecko 32-bit microcontrollers have a Crypto module, which has programmable hardware to implement the different block cipher modes. This improves performance and minimized the amount of software computation required.

 

Most authenticated block cipher modes use the counter mode for encryption and the cipher block chaining mode for authentication. The CBC mode for authentication will be the subject of the next blog, and don't forget to check out the previous installment in this series. 

  • Blog Posts
  • 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