Silicon Labs
|
Silicon Labs Community Silicon Labs Community
  • Products
    1. 8-bit MCU
    2. 32-bit MCU
    3. Bluetooth
    4. Proprietary
    5. Wi-Fi
    6. Zigbee & Thread
    7. Z-Wave
    8. Interface
    9. Isolation
    10. Power
    11. Sensors
    12. Timing
  • Development Tools
    1. Simplicity Studio
    2. Third Party Tools
  • Expert's Corner
    1. Announcements
    2. Blog
    3. General Interest
    4. Projects
How to Buy
English
  • English
  • 简体中文
  • 日本語
//
Community // Blog

Top Three Security Concerns for IoT Applications

02/60/2016 | 02:43 PM
Lance Looper
Employee

Level 5


What is Security?

A few weeks ago, Lars Lydersen shared his thoughts on steps the industry needed to take to improve IoT security, and this week applications engineer Ken Berringer kicks off an ongoing series focused on how we can do that.

As an embedded engineer at Silicon Labs, I know that everyone is concerned about security; however, their concerns and needs depend on what they are trying to protect. When it comes to wireless Internet of Things (IoT) devices, I can group most of the security concerns into three categories:

  • Encrypted Communications
  • Physical Flash Security
  • Software Application Security

My team works on adding security features to address this concerns on all of our low-energy microcontrollers (MCUs) and wireless systems-on-a-chip (SoCs). Let’s dive into these three concerns.

 

1. Encrypted Communications

Encrypted Communications protects the information transmitted over wires, or wirelessly over the air. Most wireless IoT protocols use some form of the Advanced Encryption Standard (AES) cipher. Encrypting sensitive information transmitted over the air will protect against eavesdropping or someone hacking into the network.

Over-the-air encryption is built into the ZigBee, Bluetooth Smart, and Thread protocol stacks. Therefore, if you’re working on top of a wireless stack, you don’t need to know all of the gory details of things like the cipher block mode.

However, it is helpful to have a fundamental understanding of why it’s important. The basic AES cipher has a block size of 16-bytes. To improve security for message longer than 16-bytes, many protocols use a cipher block mode, such as the counter mode, to improve security. This effectively changes the cipher for each block and adds an additional measure of security.

To ensure that a message is not tampered with, many protocols use an authenticated block cipher mode. This mode includes an authentication code for each message to ensure data integrity and provide a fingerprint that is unique to the originator’s key.

Bluetooth Smart, ZigBee, IEEE-802.15.4, and Thread all use some form of the counter cipher block mode for encryption and CBC-MAC (Cipher Block Chaining Message Authentication Code) for authentication.

 

2.  Physical Flash Security

Physical Flash Security for an embedded processor, this is the degree of protection against someone physically connecting to the pins of the device and reading out the code. For a low-energy microcontroller or wireless SoC with embedded Flash, there is a three-step process for physical security.

  • Lock the entire Flash
  • Disable the normal debug connection
  • Use a secure bootloader to upload encrypted firmware.

If these three steps are followed, the firmware on the device is very secure. Once the Flash is locked and the debug connection is disabled, even the manufacturer will not be able to read out the Flash contents. (This may limit Silicon Labs' ability to process a Return Materials Authorization.)

Physical security is not quite as secure as encrypted code. If the Flash contents are not encrypted, it is theoretically possible that someone with expert knowledge and sparing no expense might read out the Flash contents. Even for someone with expert knowledge and the expensive equipment required, this is still an expensive proposition. The economic deterrent is high enough to dissuade most hackers.

A higher level of security is possible by encrypting the code in Flash and using a run-time decryption algorithm to decrypt the code from Flash and run from RAM. However, run-time decryption is difficult to manage, requires a lot of RAM, and will have a performance/energy penalty.

 

3.  Software Application Security

Software Application Security is the ability to secure some portion of the software against other software running on the same platform. This is important if one person develops the communication stack and someone else develops the application. If the stack provider delivers source code or a linker library, it is easy for the application developer to develop application code on top of the stack. However, this also exposes the stack assembler code to the application developer.

Often there are more than two parties involved. For example, the stack developer might want to use a third party library. However, the stack developer needs to protect the third-party library code from the application code.

A secure application environment, would allow an untrusted application developer to develop an application on top of secured code. The untrusted developer would not have access to the secured assembler code or be able to reverse engineer the secured code. The ARM mbed OS provides this kind of application security using the mbed OS uVisor. Future microcontrollers will improve the performance of this solution.

What are your thoughts? What is the biggest security concern keeping you up at night?

 

Coming Up on this Blog

This is the first blog of a series on security. Upcoming blogs will go into more detail on these topics:\

 

  • Encryption and cipher block modes for data security
  • Secure Hash Algorithms and Authenticated Modes
  • Galois Counter Mode
  • Key Exchange using Elliptical Curve Cryptography
  • Digital Signatures using Elliptical Curve Cryptography

  • Blog Posts
  • Internet of Things
  • tonybarry

    Level 3


    Replied Mar 30 2016, 8:37 PM

    Hi Ken,

     

    In my experience the biggest issue for security is default logins and passwords.  Yes, this is a long way "below" your three big concerns, but in terms of "holes" this one needs filling.

     

    Perhaps you could fix your micros so that - before a user can fill them up with program, he or she HAS TO overwrite the default admin login and password.

     

    Small thing, but if you want to know what keeps me up at night ... this is it.

     

    Regards,

    Tony Barry

    Westmead Research Services

    0
  • kberringer
    Employee

    Level 4


    Replied Mar 30 2016, 11:14 PM

    Thanks for the comment.

     

    Yes. I agree that default passwords are a big concern.

     

    We have 256-bit AES encrpytion on our MCUs, but an application will not be secure if the password is left as "admin". Smiley Happy

     

    Cheers,

    Ken

     

    0
  • AlexSneedMiller

    Level 3


    Replied Apr 04 2016, 7:29 PM

    Do the BGM111/113 allow for encrypted OTA updates and any other sort of application layer encryption in case your transport layer encryption gets compromised? 

    0
  • kberringer
    Employee

    Level 4


    Replied Apr 06 2016, 4:45 PM

    Alex,

     

    Thanks for your comment.

     

    For BTLE, normally security is handled at the Application layer. The BTLE stack can provide AES-128 encryption services, but only if the Application layer uses it.

     

    This means that the low-level MAC header and address are sent in plain text, but the application data payload may be encrypted.

     

    We provide a basic OTA bootloader with our BTLE stack. If the OTA bootloader is used with Application layer security, then the over-the-air data is encrypted.

     

    BTLE uses AES-128 with CBC-MAC for encryption and authentication. So the encryption is 128-bit strong and the authentication prevents message tampering.

     

    We are working on more advanced solutions for OTA and firmware bootloaders with encryption, authentication, and digital signatures.

     

    If you need more details or help with the Blue Gecko products, please create a support ticket:

    https://www.silabs.com/support/pages/contacttechnicalsupport.aspx

     

    Cheers,

    Ken

     

    0

Tags

  • Wireless
  • High Performance Jitter Attenuators
  • EFR32FG22 Series 2 SoCs
  • EFR32MG21 Series 2 SoCs
  • Security
  • Bluegiga Legacy Modules
  • Zigbee SDK
  • ZigBee and Thread
  • EFR32BG13 Series 1 Modules
  • Internet Infrastructure
  • Sensors
  • Wireless Xpress BGX13
  • Blue Gecko Bluetooth Low Energy SoCs
  • Z-Wave
  • Micrium OS
  • Blog Posts
  • Low Jitter Clock Generators
  • Bluetooth Classic
  • Makers
  • Flex SDK
  • Tips and Tricks
  • timing
  • Smart Cities
  • Smart Homes
  • IoT Heroes
  • Reviews
  • RAIL
  • Simplicity Studio
  • Tiny Gecko
  • EFR32MG22 Series 2 SoCs
  • Mighty Gecko SoCs
  • Timing
  • Temperature Sensors
  • Blue Gecko Bluetooth Low Energy Modules
  • Ultra Low Jitter Clock Generators
  • General Purpose Clock Generators
  • EFR32BG22 Series 2 SoCs
  • Industry 4.0
  • Giant Gecko
  • 32-bit MCUs
  • Bluetooth Low Energy
  • 32-bit MCU SDK
  • Gecko
  • Microcontrollers
  • Jitter Attenuators
  • EFR32BG21 Series 2 SoCs
  • News and Events
  • Wi-Fi
  • Bluetooth SDK
  • Community Spotlight
  • Clock Generators
  • Biometric Sensors
  • General Purpose Jitter Attenuators
  • Giant Gecko S1
  • WF200
  • Flex Gecko
  • Internet of Things
  • 8-bit MCUs
  • Wireless Jitter Attenuators
  • Isolation
  • Powered Devices
  • Power

Top Authors

  • Avatar image Siliconlabs
  • Avatar image Jackie Padgett
  • Avatar image Nari Shin
  • Avatar image lynchtron
  • Avatar image deirdrewalsh
  • Avatar image Lance Looper
  • Avatar image lethawicker

Archives

  • 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
  • 2019 December
  • 2020 January
  • 2020 February
  • 2020 March
  • 2020 April
  • 2020 May
  • 2020 June
  • 2020 July
  • 2020 August
  • 2020 September
  • 2020 October
  • 2020 November
  • 2020 December
  • 2021 January
  • 2021 February
Silicon Labs
Stay Connected With Us
Plug into the latest on Silicon Labs products, including product releases and resources, documentation updates, PCN notifications, upcoming events, and more.
  • About Us
  • Careers
  • Community
  • Contact Us
  • Corporate Responsibility
  • Privacy and Terms
  • Press Room
  • Investor Relations
  • Site Feedback
  • Cookies
Copyright © Silicon Laboratories. All rights reserved.
粤ICP备15107361号
Also of Interest:
  • Bring Your IoT Designs to Life with Smart,...
  • A Guide to IoT Protocols at Works With...
  • IoT Hero Rainus Enhances the In-Store Shopping...