Applications that run on a Azure Sphere device operate in a sandboxed container. This environment is designed to maintain the security of software and data and to prevent disruption of service.
The figure shows the software elements of the application platform. Microsoft-supplied elements are gray, and manufacturer-supplied elements are white.
Azure Sphere Application Platform
The application platform supports two operating environments: Normal World and Secure World. Azure Sphere applications run in an application container in Normal World user mode and have access to the Azure Sphere libraries and a limited set of OS services. The underlying custom Linux kernel, which includes Microsoft-supplied device drivers, runs in Normal World supervisor mode, and the Security Monitor runs in Secure World. Only Microsoft-supplied code can run in supervisor mode or in Secure World.
Applications run in containers that support a subset of the POSIX environment. System functions are accessible only through the Azure Sphere libraries and run-time services; the complete set of POSIX system functions is not available.
At the hardware level (not shown in the diagram), a security subsystem provides a hardware-based secure root of trust. At device boot, the security subsystem validates overall hardware security, then brings up other components only after validating that their firmware is correctly signed. Similarly, the firmware validates the security of the next layer of software before loading it, and each subsequent layer of software validates the layer above it.
The Azure Sphere application platform is designed to ensure the security of the device, the application, and its data. Application security features include:
- Limited access to external resources
- Application capabilities
- Signing requirements
- Device capabilities
Access to resources
To prevent malicious interference from outside software, Azure Sphere applications have access only to libraries and run-time services that Microsoft provides. The libraries are restricted to ensure that the platform remains secure and can be easily updated. They do not support direct file I/O, inter-process communication (IPC), or shell access, among other constraints.
Application capabilities are the resources that an application requires. Application capabilities include the GPIO and UART peripherals that the application uses, the internet hosts to which it connects, and permission to change the Wi-Fi configuration. Every application must have an application manifest, which identifies these resources.
All image packages deployed to an Azure Sphere device must be signed. The Azure Sphere SDK and the azsphere image-package command sign image packages for testing by using an SDK signing key. Azure Sphere devices trust this key only if the appDevelopment device capability is also present.
The Azure Sphere Security Service production-signs image packages when you upload them to the cloud. Production-signed image packages can be sideloaded or loaded from the cloud.
A device capability allows a user to perform a device-specific activity. Device capabilities are granted by the Azure Sphere Security Service and are stored in flash memory on the Azure Sphere chip. By default, Azure Sphere chips have no device capabilities.
The appDevelopment device capability changes the type of signing that the device trusts. By default, Azure Sphere devices trust production-signed image packages but do not trust SDK-signed image packages. As a result, you cannot sideload an SDK-signed image package to an Azure Sphere device that does not have this capability. When the appDevelopment capability is present, however, the device trusts SDK-signed image packages. In addition, it enables a user to start, stop, debug, or remove an application from the device. In summary, the application development capability must be present on the device before you can:
- Sideload an image package that was built by Visual Studio or the azsphere image-package command.
- Start, stop, debug, or remove an image package from the Azure Sphere device, regardless of how the image package is signed.
The azsphere device enable-development command creates and applies the appDevelopment capability and prevents the device from receiving cloud application updates.