And now for something completely different: Azure Sphere GA, Security and a 2Do List
Well not completely different. Just had to use the Monty Python phrase! Of late I have delved deep into getting hardware connected to the Raspberry Pi communicating with an IoT Hub, using .Net Core. Telemetry to a user as well as command and control from the user. GPIO, Leds, buttons, motors; I2C and 1-wire environment sensors. Now lets do all of that again with the Azure Sphere.
 |
 |
|
 |
 |
 |
Some Bullet Points:
- Az Sphere has gone GA, it’s publicly available and supported
- Az Sphere is all about security for IoT Devices.
- The security is baked into the hardware.
- An Azure Sphere MCU consists of multiple cores on a single die
- Microsoft Pluton security subsystem
- High-level application core
- Real-time core(s)
- Connectivity and communications (Networking)
- It has Multiplexed (Reconfigurable) I/O that can be shared by the cores.
- Az Sphere MCUs has a minimum of 4MB of integrated RAM and 16MB of integrated flash memory
- High level apps run on a modified Linux Kernel that communicates with the lower level units
- Build using CMake
- I previously posted a list of Az Sphere Sample Projects
- In getting set up you can install the SDK for Visual Studio or the SDK for Windows
- You don’t need both
- The VS SDK works for VS Code
- The Windows one is for Command line builds only.
- There are two Az Sphere templates in Visual Studio when installed:
- A Blank Project
- The Blinky Led app
- For more guidance you have to look at the Samples
- It would be useful if some of these could be templated.
- I had an Az Sphere set up with an IoT Hub but I deleted the hub etc. Is the device lost?
- No your tenant is still there.
Security
The Seven Properties of Highly Secured Devices
- Hardware-based root of trust This guarantees that a device is running only genuine, up-to-date software before it can connect to the rest of the internet.
- Defence in depth More layers of defence make it harder for an attacker to gain access to a device’s most sensitive secrets. More sensitive areas are put behind greater layers of defence.
- Small trusted computing base A trusted computing base should be kept as small as possible to minimize the surface that’s exposed to attackers and to reduce the probability that a bug or feature can be used to compromise it.
- Dynamic compartmentalization Boundaries between software components can prevent a breach in one component from propagating to others. Dynamic boundaries can be moved and redrawn safely.
- Certificate-based authentication Passwords can be the weakest link in many security systems. Certificate-based authentication eliminates the need for passwords to manage a device.
- Error reporting Early detection, analysis, and response to errors is critical to stopping threats before they cause significant damage.
- Renewable security The ability to deploy ongoing software updates is essential to tightening a device’s defences and shutting down vulnerabilities.
The RPi Articles
2Do List
What is proposed here is to use the same IoT Hub with the same User level service communicating with that. The IoT Device previously a RPi is replaced by an Az Sphere. The same hardware is connected to the Az Sphere GPIO 1-wire and I2C pins. The Telemetry GPIO example will be used.
So what is required:
- Reproducing the Telemetry device functionality on the Az Sphere for:
- Using the backend .NET Core projects running on the desktop and IoT Hub unchanged.
| Topic | Subtopic | |
| < Prev: | .Net Interactive and Try .Net | |
| This Category Links | ||
| Category: | Azure Sphere Index: | Azure Sphere |
| Next: > | Azure Sphere Sample Projects V2 | |
| < Prev: | Azure Sphere Sample Projects |
