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 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
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
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".
Cheers,
Ken
0
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
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:
Top Three Security Concerns for IoT Applications
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:
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.
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:\
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
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".
Cheers,
Ken
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?
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