Forum Discussion
MicrosoftAsk The IoT Expert: Azure Sphere, Embedded Hardware, and IoT Security
Hey pjmlp Paul, thank you for your question
I would like to frame my response within two constraints, the first technical, the second business.
I am sure you appreciate the realities of embedded systems, resources are scarce, particularly memory, there is limited space for the OS and applications. There is not the luxury of being able to load memory managed, type-safe systems such as the Android JVM, or .NET. All of the Azure Sphere system components are highly optimized to ensure they can run within the memory constraints of the MCU.
The other reality is that customers have years of investments in C drivers and applications and they are not willing to rewrite, debug, and test these. If they were forced to choose between rewriting or an alternate C based platform then they will likely choose the path of least resistance and forego security. Customers are balancing investments in code, skills, the cost of silicon, and the cost of security.
The focus of Azure Sphere is to protect the system, this includes protecting buggy code to ensure the system cannot be compromised and abused. The system is secure by default, all resources are locked down unless explicitly “allowed”.
Here for completeness. Azure Sphere compromises of three major components.
Hardware which is inherently more difficult to hack. A certified Azure Sphere MCU includes hardware root of trust ensuring an unforgeable device identity. An MMU to ensure hardware protected memory spaces for the OS and applications, a “sticky” silicon firewall ensuring only “allowed” peripherals can be accessed and cores are isolated. The silicon firewall cannot be altered after boot. There is a true random number generator, critical for cryptography, and protection against various attack vectors.
The Operating system, a custom hardened Linux kernel with measured boot. The Pluton security subsystem runs on an isolated core, an isolated security monitor, “no execute memory” support, preventing memory an application writes being executed, address space layout randomization (ASLR), heap and stack protections. Add network endpoint protection, ensuring only access to “allowed” endpoint, mitigating against DOS attacks, as well as OS and App update and error reporting services.
The cloud-based Azure Sphere Security Service, provides an aggregate view of the ecosystem, helping to spot, patch, and update against emerging security threats, application error reporting, and OTA OS and app update services.
There is an appreciation of the benefits of RUST, and I see that you have raised RUST on Azure Sphere user voice, thank you. For now, and within the constraints of the MCU, and customers’ existing investment in C, the focus is building a secure by default platform, with ongoing security updates and protection.
Do check out the following links for more on Azure Sphere security.
- Azure Sphere Security Research Challenge
- Azure Sphere 20.07 Security Enhancements
- How Azure Sphere prevents rollback attacks
A couple of projects that you might be interested in.
- CheckedC (https://github.com/microsoft/checkedc). CheckedC adds static and dynamic checking to C to detect or prevent common programming errors such as buffer overruns and out-of-bounds memory accesses.
- There are a couple of community-based RUST initiatives that we are excited to see.
- Azure Sphere Micropython.
The IoT Technical Community blog is the place to be to track Azure Sphere. There is a constant stream of new articles related to security, or more developer-oriented posts like mine.
Cheers Dave
For me as security conscious developer the Azure Sphere security story is still not to be trust.
While https://msrc-blog.microsoft.com/writes about the need to move away from unsafe systems programming languages:
https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/
Google writes about the same in regards to Chrome and Android,
https://www.chromium.org/Home/chromium-security/memory-safety
https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-extension.html
The only feedback that Azure Sphere team members provide when questioned about the use of C based SDK, it that we should take care and use static analyzers, and most react amazed that it is even a problem to start with.
Additionally there isn't even any mention that at least adopting hardware memory tagging and pointer validation as mitigations, nor a roadmap pointing to future adoption of such capabilities.
Too much marketing about the seven necessary properties of highly secure and too little about C based exploits, UB and memory corruption. Maybe ensure safe C code, by whatever means, should be the missing eight property.
As such, as advocate for secure computing platforms I cannot seriously consider Azure Sphere as possible candidate, when even Android takes C based exploits more seriously than what Azure Sphere is willing to discuss.
MicrosoftHey pjmlp Paul, thank you for your question
I would like to frame my response within two constraints, the first technical, the second business.
I am sure you appreciate the realities of embedded systems, resources are scarce, particularly memory, there is limited space for the OS and applications. There is not the luxury of being able to load memory managed, type-safe systems such as the Android JVM, or .NET. All of the Azure Sphere system components are highly optimized to ensure they can run within the memory constraints of the MCU.
The other reality is that customers have years of investments in C drivers and applications and they are not willing to rewrite, debug, and test these. If they were forced to choose between rewriting or an alternate C based platform then they will likely choose the path of least resistance and forego security. Customers are balancing investments in code, skills, the cost of silicon, and the cost of security.
The focus of Azure Sphere is to protect the system, this includes protecting buggy code to ensure the system cannot be compromised and abused. The system is secure by default, all resources are locked down unless explicitly “allowed”.
Here for completeness. Azure Sphere compromises of three major components.
Hardware which is inherently more difficult to hack. A certified Azure Sphere MCU includes hardware root of trust ensuring an unforgeable device identity. An MMU to ensure hardware protected memory spaces for the OS and applications, a “sticky” silicon firewall ensuring only “allowed” peripherals can be accessed and cores are isolated. The silicon firewall cannot be altered after boot. There is a true random number generator, critical for cryptography, and protection against various attack vectors.
The Operating system, a custom hardened Linux kernel with measured boot. The Pluton security subsystem runs on an isolated core, an isolated security monitor, “no execute memory” support, preventing memory an application writes being executed, address space layout randomization (ASLR), heap and stack protections. Add network endpoint protection, ensuring only access to “allowed” endpoint, mitigating against DOS attacks, as well as OS and App update and error reporting services.
The cloud-based Azure Sphere Security Service, provides an aggregate view of the ecosystem, helping to spot, patch, and update against emerging security threats, application error reporting, and OTA OS and app update services.
There is an appreciation of the benefits of RUST, and I see that you have raised RUST on Azure Sphere user voice, thank you. For now, and within the constraints of the MCU, and customers’ existing investment in C, the focus is building a secure by default platform, with ongoing security updates and protection.
Do check out the following links for more on Azure Sphere security.
- Azure Sphere Security Research Challenge
- Azure Sphere 20.07 Security Enhancements
- How Azure Sphere prevents rollback attacks
A couple of projects that you might be interested in.
- CheckedC (https://github.com/microsoft/checkedc). CheckedC adds static and dynamic checking to C to detect or prevent common programming errors such as buffer overruns and out-of-bounds memory accesses.
- There are a couple of community-based RUST initiatives that we are excited to see.
- Azure Sphere Micropython.
The IoT Technical Community blog is the place to be to track Azure Sphere. There is a constant stream of new articles related to security, or more developer-oriented posts like mine.
Cheers Dave
Thanks for taking the time to reply to me, as the Azure Sphere 20.07 Security Enhancements blog post proves, those security measures to tame C still fall short of having proper secure devices in 2020.
Checked C still seems a MSR research project that can be abandoned at any time, and while Rust is indeed desired, and it is nice that the community is working on it, not having something like those languages on the SDK renders them not a viable option in security conscious environments.
MCUs can also be programmed in languages like Ada/SPARK, the option that NVidia is pursuing for its autonomous driving project, where human lifes are at stake. They explicitly rejected C for the project due to its known weakness for writing secure code.
So thanks for the lengthy reply, I will keep following up the fixes coming out of https://www.microsoft.com/en-us/msrc/azure-security-lab