Defense in depth provides for multiple layers of security and thus multiple mitigations against each threat. Each layer of software in the Azure Sphere platform verifies that the layer above it is secured.
Small trusted computing base. Most of the device's software remains outside the trusted computing base, thus reducing the surface area for attacks. Only the secured Security Monitor, Pluton runtime, and Pluton subsystem—all of which Microsoft provides—run on the trusted computing base.
Dynamic compartments. Dynamic compartments limit the reach of any single error. Azure Sphere MCUs contain silicon counter-measures, including hardware firewalls, to prevent a security breach in one component from propagating to other components.
A constrained, "sandboxed" runtime environment prevents applications from corrupting secured code or data. Password-less authentication. The use of signed certificates, validated by an unforgeable cryptographic key, provides much stronger authentication than passwords.
The Azure Sphere platform requires every software element to be signed. Device-to-cloud and cloud-to-device communications require further authentication, which is achieved with certificates. Error reporting. Errors in device software or hardware are typical in emerging security attacks; errors that result in device failure constitute a denial-of-service attack. Device-to-cloud communication provides early warning of potential errors.
Azure Sphere devices can automatically report operational data and errors to a cloud-based analysis system, and updates and servicing can be performed remotely. Renewable security. The device software is automatically updated to correct known vulnerabilities or security breaches, requiring no intervention from the product manufacturer or the end user.
Working together, the Azure Sphere hardware, software, and Security Service enable unique, integrated approaches to device maintenance, control, and security. The hardware architecture provides a fundamentally secured computing base for connected devices, allowing you to focus on your product.
The software architecture, with a secured custom OS kernel running atop the Microsoft-written Security Monitor, similarly enables you to concentrate your software efforts on value-added IoT and device-specific features. The Azure Sphere Security Service supports authentication, software update, and error reporting over secured cloud-to-device and device-to-cloud channels.
The result is a secured communications infrastructure that ensures that your products are running the most up-to-date Azure Sphere OS. An Azure Sphere crossover MCU consists of multiple cores on a single die, as the following figure shows. Each core, and its associated subsystem, is in a different trust domain. The root of trust resides in the Pluton security subsystem. Each layer of the architecture assumes that the layer above it may be compromised.
Within each layer, resource isolation and dynamic compartments provide added security. The Pluton security subsystem is the hardware-based in silicon secured root of trust for Azure Sphere. As part of the secured boot process, the Pluton subsystem boots various software components. It also provides runtime services, processes requests from other components of the device, and manages critical components for other parts of the device.
It enables hardware-based compartmentalization of processes by using trust zone functionality and is responsible for running the operating system, high-level applications, and services. Your high-level applications run in NW user mode.
Such applications can map peripherals and communicate with high-level applications but cannot access the internet directly. High-level applications can configure, use, and query the wireless communications subsystem, but they cannot program it directly. In addition to or instead of using Wi-Fi, Azure Sphere devices that are properly equipped can communicate on an Ethernet network.
The firewalls impose compartmentalization, thus preventing a security threat that is localized in the high-level application core from affecting the real-time cores' access to their peripherals.
The high-level application platform runs the Azure Sphere OS along with a device-specific high-level application that can communicate both with the internet and with real-time capable applications that run on the real-time cores. After running this, the device will be unable to be moved to another tenant. After the device has been claimed, a Wi-Fi connection must be setup.
Running azsphere device wifi add — ssid — key adds new Wi-Fi credentials, where yourSSID is the network name and yourNetworkKey is the network password. Use azsphere device wifi show-status to check if the connection was successful. Setting up the Azure Sphere device is straightforward and simple to do. Running the command azsphere device prep-debug unlocks the device. To begin programming, select the sample blink program from the list of Azure Sphere example applications.
Once main. Once prompted, select yes to build the application. A blinking LED should be visible if the application was successfully flashed.
Request yours now! Log in Sign up. Please ensure that JavaScript is enabled in your browser to view this page. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. Feedback will be sent to Microsoft: By pressing the submit button, your feedback will be used to improve Microsoft products and services.
Privacy policy. To start using an Azure Sphere dev kit on Windows, you need to set up the dev kit, install the SDK, and install any additional software required for your development environment. The first time you plug in the device, the drivers should be automatically downloaded and installed. Installation can be slow. If the drivers are not installed automatically, right-click the device name in Device Manager and select Update driver.
Choose the driver that matches your Windows installation or bit. To verify installation, open Device Manager. If you've previously used this board and enabled RTApp development, you will see three converters instead of four. This is normal and does not represent an error.
If other errors occur, see Troubleshoot Azure Sphere problems for help. Download the SDK.
0コメント