Ask The IoT Expert: Azure Sphere, Embedded Hardware, and IoT Security

[glovebox]

Are you running into questions while working on projects built around Azure Sphere and embedded hardware like the Raspberry Pi? Do you have ideas that you want to share around IoT security in general or the projects you are working on? Today we are kicking off an Ask The Expert series where a variety of Microsoft Azure IoT experts will be starting a conversation to answer any questions you may have.

This week I’m leading the #JulyOT conversation where we are showcasing content on building projects using Azure Internet of Things services, specifically having to do with microcontrollers and embedded hardware.

I’m Dave Glover, a Cloud Developer Advocate, based in Sydney, Australia, with a focus on the Internet of Things. I’m fascinated by the possibilities of embedded, communications, AI, and cloud technologies. I am known to dream in C/C++, C# and Python, and I post on GitHub at https://github.com/gloveboxes, everything is Open Source with an MIT licence.

What has captured my attention is embedded development with Azure Sphere as it addresses IoT security. IoT security is without a doubt the biggest challenge facing the IoT industry and often the most overlooked. IoT solutions built on Azure Sphere are secure by default enabling you to focus on your business opportunity with confidence knowing that security is baked in.

I wrote the Azure Sphere Developer Learning Path which is now published on MS Learn: “Develop secure IoT Solutions for Azure Sphere with IoT Central” and “Develop secure IoT Solutions for Azure Sphere with IoT Hub”. I learned a lot of lessons and you will find my learnings and best practices embedded in the MS Learn modules.

I’ve also just published two “embedded” articles as part of #JulyOT. Both expand on the Azure Sphere Developer Learning path.  The topics might be a bit cheesy, but the objective is to illustrate how you can build secure IoT solutions with Azure Sphere and Azure IoT.

1. How to build a healthier working environment by monitoring CO2, temperature, and humidity levels wit...
   
2. Build a Rover combining the best of Azure Sphere security with FreeRTOS
   
   

I’m looking forward to hearing your ideas and questions – please post them as comments and I’ll do my best to help you answer them!

Cheers Dave

[#2]

For me as security conscious developer the Azure Sphere security story is still not to be trust.

While  Microsoft Security Response Center 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.

[#3 · Accepted solution]

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.

1. Azure Sphere Security Research Challenge 
2. Azure Sphere 20.07 Security Enhancements
3. How Azure Sphere prevents rollback attacks

A couple of projects that you might be interested in.

1. 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. 
2. There are a couple of community-based RUST initiatives that we are excited to see. 
   • https://github.com/vhnatyk/rust-hello-azure-sphere
   • https://github.com/bjoernQ/rust_azure_sphere_advanced
3. 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

[#4]

@glovebox 

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 Azure Sphere Security Research Challenge.