Do you think IIT Guwahati certified course can help you in your career?
Introduction
Azure Sphere is a set of Microsoft services and products that enables manufacturers of internet of things devices to improve security by combining a particular system on a chip, Azure Sphere OS, with a cloud environment built on the Azure platform for ongoing monitoring.
For more information about Azure sphere deployment, let's dive into the article.
Deployment basics
When deploying, Azure Sphere devices that should run the same software and OS versions are grouped, the applications you want to run on each group of devices are packaged, the packages are uploaded to the Azure Sphere Security Service, and the deployment is then assigned to a particular group of devices. The fundamental components of deployment are defined in this article.
Naming conventions
Only alphanumeric characters and spaces may be used in the names of product and device groupings. There is a 50-character limit. When using words in a command, wrap them in double quotation marks if they contain spaces.
Device IDs
An Azure Sphere device ID identifies an individual Azure Sphere chip. The gadget itself retains the device ID. The Azure Sphere Security Service houses all the other components of a deployment.
Spoofing, counterfeiting, or abusing a device's ID is simple. To protect sensitive data, you should only allow devices whose identities can be verified and validated to access and connect to your services.
Products
An Azure Sphere MCU integrated into a connected device to carry out a specified function is known as a product. The manufacturer produces a product for each model of related equipment, such as a coffee maker or dishwasher. For instance, Contoso builds a product specifically for its DW100 dishwashers during manufacture and allocates it to each DW100 dishwasher. Every product has a GUID that is fixed and unchangeable within the tenant. Each connected device has a single product, although multiple devices can be linked to a single product. Each product has a name and a description, both of which must be distinct within its tenancy. A human-readable technique to distinguish one product from another is through the product name and description. You can change the product's name and description as frequently as possible.
Device groups
A named set of devices belonging to the same product type is a device group. An approach to scale application distribution to numerous devices is through device groups. Every device is a part of precisely one device group, and every product is a part of exactly one. Default device groups are generated when you build a product to help with basic functionality, such as testing and production deployment. The device groups are distinct even if the names of the default groups are the same across all products. These are the standard device groups:
Development: As part of the development process, developers who sideload programs are to use the Development group. Devices in this category only get system software updates by default; application updates are not enabled.
Field Test: Developers testing gadgets in a lab or during field trials should use the Field Test group. Devices in this category automatically get all application updates and the Retail OS feed.
Production: The Production category is designed for equipment used in a specific product's production. Devices in this category automatically get all application updates and the Retail OS feed.
Field Test OS Evaluation: Application compatibility testing for new versions of the Azure Sphere OS on test devices in a lab or field trial is done by developers using the Field Test OS Evaluation group. Devices in this category automatically get all application updates and the Retail Evaluation OS feed.
Production OS Evaluation: The purpose of the Production OS Evaluation group is to test whether new versions of the Azure Sphere OS are compatible with real-world applications. Devices in this category automatically get all application updates and the Retail Evaluation OS feed. To organize your products, you can decide to create more device groupings.
Contoso, for example, might employ the Development group for the equipment in its engineering lab and the Field Test group for the equipment that its deployment team uses at the corporate operations center. To simply deploy regionalized versions of its apps, Contoso can decide to build groups for devices in various geographical locations rather than placing all production devices in the Production group. Assigning programs to device groups will allow you to deploy them to Azure Sphere devices. The applications allocated to each device within a device group will be downloaded automatically; any additional applications will be removed.
Applications
A program known as an application handles specialized functions for particular linked devices. The application is distributed through a deployment to the items connected to those devices.
Images and image packages
A binary file known as an image represents a single configuration of a board or application. Images are unchangeable; they cannot be changed after being submitted. The image for an application also contains the application's binaries and picture information. An image package is created during the build process when an image and its associated metadata are combined. A new, distinct picture ID is used each time the SDK creates or reconstructs an Azure Sphere image package.
The SDK generates an image package that can be deployed to any device group when Contoso writes an application for its DW100 dishwashers.
Chip SKUs and system software
You create and maintain programs as a product creator, whereas Microsoft creates and manages system software components. Chip SKUs are the focus of system software components. The chip SKU (stock keeping unit) designates a particular class of MCU that is appropriate for Azure Sphere. Microsoft has given the chip SKU, and it cannot be modified. Microsoft uses this SKU to provide each Azure Sphere device with the proper system software upgrades.
Deployment
In its most basic form, a deployment transmits a collection of image packages to one or more devices. Deployment is made by:
Using azsphere product generate to develop a product.
Using azsphere device-group create to add more device groups, as required.
Using azsphere device update to assign devices to device groups.
Using the Azure Sphere SDK to use to build image packages.
Using azsphere image add to upload the image package to your Azure Sphere tenant.
Using azsphere device-group deployment, create a new deployment for a device group for the images.
All of the members of device group are targeted by the deployments associated with that group by the Azure Sphere Security Service, and only those deployments. This means that if you move a device from one group to another, the device will only receive the deployment (if any) that is connected with the new device group; any other image packages (or board configurations) currently on the device will be destroyed. As a result, the Security Service ensures that each device only contains the pictures specified by its deployment.
For a device group, deployments cannot be disabled or withdrawn, but you can update an existing deployment by making a new deployment for the group. You can transfer a device to another device group without a deployment associated if you wish to remove a deployment from a specific device.
Using Azure Sphere classic CLI and Azure Sphere CLI
On both Windows and Linux, the Azure Sphere CLI is installed alongside the Azure Sphere traditional CLI, giving you access to either interface. Use Azure Sphere CLI as follows:
Use PowerShell or a regular Windows command prompt when using Windows.
Use any command shell on Linux. If you chose to install the Azure Sphere traditional CLI as the default during SDK installation, use the azsphere command; otherwise, enter azsphere_v2.
About tenants
An Azure Sphere tenancy allows you to arrange your devices and separate your Azure Sphere devices from those that belong to other companies. Metadata, functional organization, and details about images, deployments, users, and roles are gathered under your Azure Sphere tenant.
A GUID is used to identify each tenant. You will specify product and device groupings in your tenant. For your organization, device groupings organize individual devices into functional domains.
Most businesses just require one Azure Sphere tenant. On the other hand, large enterprises may prefer to administer devices per division if they have numerous divisions based on brands or location, for instance. These businesses can establish distinct Azure Sphere tenants if they make sense.
Note: An Azure tenant is different from an Azure Sphere tenant. You will still build an Azure Sphere tenancy to manage your Azure Sphere devices even if your company already has an Azure tenant.
Deployment history and security
The security features integrated into Azure Sphere depend heavily on the capability to track and reverse deployments. The Azure Sphere Security Service can keep track of the photos that have been added to each device group, thanks to the definition of products, images, and device groups. By identifying the device group to which a specific device belongs and the current images aimed at the device, you may pinpoint precisely which set of software has previously been targeted to the device. The history is accessible through the Azure Sphere CLI.
Levels of restarting on a device
On an Azure Sphere device, restarting can take place at two different levels:
Device reboot: Rebooting the device causes the MCU to restart peripherals, reconnect to the network layer, restart apps, and start the Azure Sphere operating system (OS).
Application restart: The application starts again while the operating system, peripherals, and connection to the network layer all stay in place.
When one of the following situations occurs, a device reboots:
The Azure Sphere OS has been updated and installed.
An application update alters the peripheral configuration, which is locked.
The USB port is opened, and the gadget is plugged back in.
The device's reset button is pressed.
Run the azsphere device and restart the CLI command.
From a high-level application, the PowerManagement_ForceSystemReboot function is used.
A high-level application or a real-time capable application restarts under the following conditions:
The application has a new update installed.
Unexpectedly, the application terminates.
A hardware or OS event has happened.
The CLI commands azsphere device app stop and azsphere device app start are executed.
In Initialization and Terminating, tasks a high-level program should carry out upon beginning or terminating are listed.
Peripheral configuration locking
A mapping of peripherals to cores is known as a peripheral configuration, and they can now be locked on Azure Sphere chips to increase security. Peripheral configuration locking will be a feature of all following Azure Sphere chips.
The Azure Sphere runtime configures the hardware firewall during system startup, which also assigns the peripherals to a core by reading the application manifest to determine which peripherals an application is permitted to utilize. An attacker may be able to change the core assignments of the peripherals and get access to any peripheral when the peripheral configuration is not locked. However, even if the code is compromised, an attacker cannot reassign peripherals when the peripheral configuration is closed.
When the peripheral configuration is locked
After all, programs have been initialized, and during system startup, the Azure Sphere runtime locks the peripheral configuration if the following two circumstances hold true:
DeviceComplete is the state specified for the production of devices.
The device does not have the appDevelopment device capability.
Defense-in-depth, one of the seven characteristics necessary for highly secure systems, is strengthened by peripheral configuration locking, which provides even another degree of protection. The peripheral configuration cannot be changed after it has been locked without restarting the device.
Application updates and device reboot
When the peripheral configuration is locked, a device reboot is triggered by an application update that necessitates a change in the peripheral configuration. The device must reboot once the configuration is closed for the peripheral configuration to be updated to reflect the application update.
The peripheral configuration is altered when a program update necessitates the release or purchase of peripherals. Examples of application changes that result in a device reboot while the peripheral configuration is locked include the following:
A sideload or cloud update may include the installation of a new program that makes use of peripherals. A new core and peripherals must be purchased in this situation.
A newer version of an application calls for a different set of peripherals than its predecessor. In this situation, it is necessary to release some peripherals while acquiring others.
As part of a cloud update, a peripheral-using program is removed. In this scenario, the application must release all peripherals it has been using.
Examples of program upgrades that don't require a device reboot because the peripheral setup is still the same include the following:
A new application that doesn't depend on any peripherals is installed
as part of a sideload or cloud update.
A program that doesn't require any peripherals gets erased as part of a cloud update.
The new version requires the same peripherals as the application's prior version.
Device identity and security
Many devices can be deployed and managed simultaneously. The foundation of device management is recognizing and accessing each device separately as needed. Each Azure Sphere device receives a unique internal device ID that endures through all upgrades to the device, including recovery operations, to allow you to do this.
However, a device's ID can be readily faked, fabricated, or misappropriated in digital networks. As a result, you should only let devices whose identities can be confirmed and validated access your essential data and connect to your services.
Azure Sphere offers a method for enabling a device to authenticate itself and verify its identification (attestation). The Azure Sphere Security Service combines pre-known keys, secure communications, and specialized hardware to confirm a device's identity during the authentication and attestation process. A certificate is issued to the device after successful device authentication and attestation. A legitimate certificate proves that:
The identity of the device has been confirmed.
The device is reliable.
With Azure Sphere, the device certificates are linked first to a tenant-level certificate (making it simple for an organization to trust just devices from its tenants) and then to a Microsoft certificate. This certificate shows that Microsoft has confirmed that the hardware in question is a verified instance of an Azure Sphere chip running a secured Microsoft OS.
To use device identity in the safest and most productive methods possible, consider the following ideas:
Trust is transient It is possible to lose and then gain trust in a system. Verifying explicitly is one of the tenets of a Zero Trust architecture implementation in an IoT system. This means that every time you engage with a device, you must explicitly confirm its validity and demonstrate the reliability of the data exchange. With the help of Azure Sphere cloud security services, Azure Sphere devices automatically execute an authentication and attestation procedure once every 24 hours. A cryptographically signed certificate rooted in the Microsoft Azure Sphere Cloud Security Service indicates that a device's identity has been successfully validated.
Identity = identifiers + attestation Identifiers are transferable and reproducible. Therefore, a gadget cannot just be identified by its identifier. The identification of a device (or a user) must be viewed as a composite of an identifier and an assertion that the identifier is legitimate in the given situation. Device identifiers shouldn't be assigned and used separately from the attestation procedure. At every level of interaction inside your systems, combine IDs with proof of attestation whenever it is practical.
Identifiers + trust certificates A unique identification should only be regarded as a reference. It shouldn't be thought that by itself. It says anything about how reliable the thing it relates is. Use identifiers, for instance, to subscribe to MQTT messages, group reliable data together in a portal, and route traffic and data in a system. But when it comes to confidence, rely on a chained, cryptographically signed certificate rather than the identifier. Certificates are evidence of identification that has been evaluated and confirmed to be trustworthy within a particular environment and are especially useful for password-less data flow between system components.
These ideas are already included when utilizing Azure IoT Hub, implementing a secure and robust system that is more straightforward if configured following the recommended configuration guidelines.
You must also use these notions when connecting to non-Azure endpoints or services that you have direct control over. For instance, if a device is utilizing MQTT, it might include its identification in the MQTT topic it broadcasts. However, the MQTT server must first confirm that the device's certificate authenticates it to publish to this particular topic before receiving an update from it.
Azure Sphere device certificate and device ID access
Use the DeviceAuth_GetCertificatePath function in your program to access a device certificate.
Use the wolfSSL_X509_get_subject_name function to extract the subject from the certificate returned by the DeviceAuth_GetCertificatePath() function to retrieve the device's distinct Device ID.
The high-level program Get Azure Sphere Device ID shows how to obtain the Azure Sphere Device ID. The Device ID is returned as a 128-character character buffer. This code snippet instructs wolfSSL to start a session with the specified certificate, retrieve the context and certificate, extract the certificate's subject ID—which corresponds to the Device ID for Azure Sphere Devices—and return it as a char pointer.
About over-the-air updates
As they represent the quality of renewable security, updates play a significant role in the Azure Sphere security paradigm. Maintaining regular upgrades keeps your devices compatible with the seven properties. When turned on for the first time or after pressing the Reset button, Azure Sphere devices check for updates. After that, periodic checkups take place (currently 20 hours).
Prerequisite updates, OS updates, and deployment updates are the three different categories of updates. Prerequisite updates are used to ensure that the Trusted Key Store (TKS) and certificate store, which are currently dependent on the update process itself, are up to date. The certificate store verifies internet connections, while the TKS authenticates the images that must be downloaded and installed. A device's operating system update (OS update) targets all Microsoft-supplied software on the system, including the operating system that your applications use in the real world and lower-level firmware like the Pluton subsystem and the Security Monitor. Deployment updates target your software, including your powerful apps that may operate in real-time and your board configuration images (if any). Azure Sphere handles the management of prerequisite and OS updates, and the coordination of application updates is dealt with by Azure Sphere based on deployments made by your company.
Any device must meet prerequisite requirements to receive OS updates:
It must have an internet connection.
Networking requirements need to be set up correctly.
Any device's application and board configuration images must be updated in the following ways:
It must not be capable of developing applications.
A tenant must claim for it.
It has to be a member of a device group.
A deployment must target it to the device group to which it belongs.
The deployment must include application images (and, at your option, a board configuration image) made by your company or on its behalf.
The UpdateAll update policy must be applied to the device group. Using the azsphere device-group update command, you can prevent application updates for a specific device group.
Deployments targeting that device group are regarded as the trustworthy source for imaging all the devices in that group. The device will be cleared of any images not part of the deployment. As of Azure Sphere OS 21.04, the only exception is that board configuration pictures are not deleted unless they are swapped for fresh ones.
There are three phases to the device update check that correspond to the three types of updates:
Azure Sphere acquires a manifest containing the most recent iterations of the TKS and certificate store at the first stage. The update's second part begins if the device's TKS and certificate storage are current. The present images are downloaded and installed if not.
The current versions of the various OS component images are listed in a manifest Azure Sphere acquired in the second stage. The most recent and rollback images, which can be used to roll back the device to a known good state if the update process fails, are downloaded if any photos on the device are outdated. The OS images are downloaded, installed, and the device is rebooted after being saved in a staging region on the device.
In the third stage, Azure Sphere determines whether the device group accepts deployment updates. Rollback images for the applications are likewise staged as necessary, just like the OS upgrade. The application images are installed when the application and rollback images have been downloaded and saved in the staging area.
Update rollback
There is a rollback option available for every step of the updating procedure. The rollback image in the prerequisite update is merely a backup of the pre-update state. The pre-update status is reinstated if the update fails.
The firmware and application partitions are rolled back if any firmware image fails to boot. Rollback at any level forces rollback at all higher levels.
A rollback for the OS update might be caused by either a runtime issue or a failed signature verification. When a signature verification fails, an effort is made to fix the image; if this is unsuccessful, a complete rollback is started. The staged rollback images are set up for the operating system and the applications during a full rollback.
Multiple deployments may occur between OS upgrades because OS updates and deployments have separate release cycles. If this happens, it's crucial to understand that the deployment's rollback targets aren't the most current deployments but rather the deployments made at the time of the most recent OS update. By doing this, the OS and application are guaranteed to function together in the rolled-back state.
Interrupted updates
For each update type, there are four potential outcomes if an update is interrupted, such as by a power outage or a lack of connectivity:
When power is restored, an installation successfully downloaded and staged but not yet finished will be finished.
The update would continue downloading the missing images and then install if some but not all images were downloaded and staged.
If an update installation is halted after the download is finished, the installation will resume upon boot.
When power is restored, the update procedure will start over from scratch if no image was fully downloaded because there won't be anything available for installation.
Updates in power-down scenarios
Low-power scenarios are supported by Azure Sphere, allowing for prolonged periods of device inactivity to preserve battery life. In such cases, allowing the device to check for updates is crucial. The Power Down sample application shows how to correctly cut down on power usage while ensuring the device occasionally stays awake to check for OS and app updates.
Deferred updates
High-level programs can include deferred update functionality to stop updates from interfering with crucial processes. This feature enables the application to finish its essential functions before getting ready to shut down so the update may start.
Azure Sphere OS feeds
Microsoft uses system software streams to distribute cloud upgrades for the Azure Sphere OS. Our software, prepared for production usage, is provided by the Retail OS feed. For you to check compatibility before widespread deployment, the RetailEval OS feed delivers OS software two weeks before its release to the Retail OS feed. You will receive notice through the conventional means each time we release the OS to either stream.
Updated OS releases are compatible with applications created using production APIs. Beta features, however, could alter between updates.
An OS feed has default device groups attached to it. You can specify the necessary OS feed when creating your device group using the azsphere device-group create command. The Retail feed should always be used for cloud application deployments to connected devices at end-user locations.
To ensure that your production-signed applications continue to function correctly while running on the Retail Evaluation OS during the two weeks, we advise you to assign devices to a device group that depends on the RetailEval OS feed. To ensure a high-quality Retail OS release at this time, Microsoft will be checking the device telemetry for quality. Any issues you submit to Microsoft will be resolved.
Display device information
Thousands of devices may be present in an Azure Sphere tenant, and managing those devices necessitates a way to get comprehensive data on each device. You may list details about a tenant's devices, products, and device groups using CLI commands. Additionally, you can direct a command's standard output to a file for more in-depth analysis.
Additionally, you can retrieve diagnostic and configuration data, information on faults, and other events that impact your devices using the CLI commands.
Redirect or paginate results
The following commands can list details about a tenant's devices, products, and device groups using the Azure Sphere command-line interface (CLI).
All devices included in a particular device group are shown in the azsphere device-group device list.
All of the devices in a tenancy are visible in the Azsphere device list.
The list of devices in an Azsphere product provides access to every device.
These commands can return a lengthy list of things that can be paginated or redirected. The many redirection and pagination options for both CLI outputs are covered in this section.
Azure Sphere CLI
Azure Sphere CLI does not support interactive pagination. The output on the screen can be paginated, though, by piping to already-existing pagination tools.
For example:
In PowerShell (Windows):
azsphere device list | Out-Host –Paging
In the command prompt (Windows):
azsphere device list | more
In Bash shell (Linux):
azsphere device list | less
Note: The amount of data returned will determine whether this procedure will be slow. Additionally, you can direct a command's standard output to a file. The expected outcome and standard error are delivered to output.txt and logs.txt,
Azure Sphere CLI
azsphere device list --verbose > output.txt 2> logs.txt
Azure Sphere Classic CLI
These instructions typically return a page of records at once, with the page size being set to 100 records by default. A prompt to hit any key to see the following results page is located at the bottom of each results page. The page size is automatically modified based on variables such as database activity and available network capacity.
By adding the --noninteractive parameter to the list command and providing a path and file name for the --output parameter, you can direct the output of the list command to a comma-separated values (CSV) file for in-depth analysis. The pagination from the results is removed with the --noninteractive parameter, allowing the whole list to be saved in the CSV file without manually navigating to the next page's conclusion.
Display information for support
The commands required to acquire support information may vary depending on whether you are returning data on error situations involving the applications running on devices inside a tenant or gathering customer support data for a single Azure Sphere device when dealing with Microsoft support. Typically, you will use the azsphere tenant download-error-report command to query the tenant for error conditions on all devices. This method will rely on the devices' internet-connected interactions with the Azure Sphere Security Service to gather the matching events.
get-support-data
The azsphere get-support-data command collects and creates log files from your PC, the cloud, and the connected Azure Sphere device that contain diagnostic and configuration data. You or the technical support staff can utilize the data in these log files to evaluate and troubleshoot issues. To specify the location and name of the.zip file to save the supporting data, use the --destination parameter. A relative or absolute path might be given.
download-error-report
The azsphere tenant download-error-report command returns information about errors reported by devices inside a tenant. Event data can be retrieved without a physical connection to a specific device using the Azure Sphere Security Service cloud. The command operates within the current tenant's context and returns error reports for each device in that tenant.
To specify the location and name of the.csv file to save the supporting data, use the --destination parameter. A relative or absolute path might be given.
Azure Sphere CVEs
Microsoft wants to reward security researchers interested in Azure Sphere for identifying potential flaws and responsibly disclosing them following the Microsoft Azure Bounty Program and the Coordinated Vulnerability Disclosure concept. The Azure Sphere team appreciates the work of the security research community and invites their participation in maintaining the security of our product.
We want to be open about the security upgrades we've made. For vulnerabilities patched in current or earlier versions of the Azure Sphere OS, we collaborate with the CVE Program to disclose common vulnerabilities and exposures (CVEs).
Customer impact of publishing CVEs
Only after a fix is ready is the CVE for the OS released. Updates are carried out automatically on any Azure Sphere-powered device linked to the internet. Therefore, devices that are running the most recent version are always secured. We advise joining the device to a secure, private local network with Internet connectivity and enabling the device to automatically update itself for new or recently disconnected devices (i.e., when the OS version is older than the OS version that has the repair).
Principles for publishing CVEs
For vulnerabilities in the Azure Sphere OS that can be used "out of the box" throughout a prolonged period of offline use or before connecting to the Azure Sphere Security Service, CVEs may be provided. Customer application vulnerabilities are not eligible for a CVE designation. Manufacturers are responsible for creating CVEs for third-party software.
There are three categories of vulnerabilities for which we disclose CVEs:
Pre-emptive Impact: Vulnerabilities connected to when an Azure Sphere device is shut off and not in use that may be accessed while setting up and configuring the device.
Invisible Impact: When an Azure Sphere device is actively executing a task but is not connected to the Azure Sphere Security service for updates, vulnerabilities exist that could be taken advantage of without impairing the primary device performance.
Disruptive Impact: Vulnerabilities that could force an update rollback or stop an Azure Sphere device from automatically getting updates.
Contents of Azure Sphere CVEs
The Common Vulnerability Enumeration (CVE) for Azure Sphere consists of a brief explanation, a CVSS score, an evaluation of the exploitability index, an Azure Sphere-specific FAQ, and an acknowledgment of the discoverer. Every CVE must contain this information, and all CVEs for Microsoft products do.
When Azure Sphere CVEs are published
After a fix has been made available to customers, CVE records will be released on the second Tuesday of every month (also known as Microsoft Patch Tuesday). Every time a vulnerability is reported to us, satisfies the criteria outlined above, and is patched in the Azure Sphere OS's most recent release, we anticipate that CVEs will be published irregularly. Before a patch is made public, we won't publish CVEs.
Certificate use with Azure Sphere
This subject gives a general overview of the "landscape" of certificates used by the various Azure Sphere components, including the many types of certificates they use, where they originate, where they are kept, how they are updated, and how to access them when needed. It also explains how certificate management is made more straightforward for you by the Azure Sphere OS, SDK, and services. We presume you are somewhat aware of the chain of trust and certificate authority.
Azure Sphere devices
The Trusted Root store, a component of the Azure Sphere OS, is used by every Azure Sphere device. When a device connects for device authentication and attestation (DAA), over-the-air (OTA) update, or problem reporting, the Trusted Root store contains a list of root certificates used to verify the identity of the Azure Sphere Security Service. The OS comes with these certificates.
A client and update certificates are both given to the device when daily attestation is successful. The Azure Sphere Update Service is unavailable through programs or the command line; the updated certificate allows the device to connect to it to get software updates and upload error reports. Applications can connect to TLS-enabled third-party services like wolfSSL using the customer certificate, also known as the DAA certificate (TLS). This document is good for 24 hours. Applications can obtain it by using the DeviceAuth_GetCertificatePath function to access it programmatically.
Devices must display their Azure Sphere tenant CA certificate to verify their Azure Sphere tenant when connecting to Azure-based services like Azure IoT Hub, Azure IoT Central, and Azure IoT Edge. The CLI's azsphere ca-certificate download command returns the tenant CA certificate for these purposes.
EAP-TLS network connections
To authenticate with the network's RADIUS server, devices connected to an EAP-TLS network require certificates. The device must provide a client certificate to RADIUS to authenticate as a client. The device additionally needs a root CA certificate for the RADIUS server to authenticate the server to execute mutual authentication. Microsoft does not provide either of these certificates; it is up to you or your network administrator to identify the proper certificate authority for the RADIUS server on your network and buy the required certifications from the issuer.
You must establish your identity with the certificate authority to receive the certificates for the RADIUS server. The DAA certificate can be used for this, as was already explained. After obtaining the RADIUS server's certificates, you should keep them in the device certificate store. The device certificate store is only usable when using EAP-TLS for network authentication. (The DAA certificate is safely stored in the OS and not kept in the device certificate storage.) You can manage the certificate store using the CLI's azsphere device certificate command. Azure Sphere apps can use the device certificate store to store, retrieve, and manage certificates. To help apps prepare for certificate expiration and renewal, the CertStore API also has functions that retrieve details about specific certificates.
Azure Sphere applications
Applications running on Azure Sphere require certificates to connect to some networks and web services. An app may use either the DAA certificate or a certificate from an external certificate authority, depending on the needs of the service or endpoint.
The DeviceAuth_GetCertificatePath function can be used by applications to obtain the DAA certificate for authentication when connecting to a third-party service using wolfSSL or a similar library. The 20.10 SDK's deviceauth.h header introduced this method.
Apps that utilize the Azure IoT library integrated into Azure Sphere to access Azure IoT services (Azure IoT Hub, Azure IoT Central, device provisioning service) do not need any additional certificates because the library already trusts the relevant root CA.
If your apps use other Azure services, consult their documentation to determine which certificates are necessary.
Azure Sphere Public API
To request and obtain data on deployed devices, the Azure Sphere Public API (PAPI) communicates with the Azure Sphere Security Service. These connections are authenticated by the Security Service using a TLS certificate. This means that to connect to the Security Service, any code or scripts using the Public API, as well as any other Security Service clients like the Azure Sphere SDK (including both the Azure Sphere classic CLI and Azure Sphere CLI), must trust this certificate. As with many Public API apps, the SDK leverages the credentials in the host machine's system certificate store for Azure Sphere Security Service certification.
The Security Service upgraded its Public API TLS certificate on October 13, 2020, to one generated by the DigiCert Global Root G2. Because the DigiCert Global Root G2 certificate is already present in Linux and Windows operating systems, the necessary certificate is easily accessible. To accommodate this update, however, only customer cases involving subject, name, or issuer (SNI) pinning necessitated changes, as we explained in an earlier blog post.
Azure Sphere Security Service
Numerous certifications used in secure service-to-service communication are managed by Azure Sphere cloud services in general and the Security Service in particular. Microsoft coordinates changes as needed because most certificates are internal to the services and clients. For instance, the Azure Sphere Security Service upgraded its TLS certificates for the DAA service and Updated the service in October in addition to updating the Public API TLS certificate. Devices previously got an OTA update to the Trusted Root store that contained the updated necessary root certificate. Maintaining device connectivity with the Security Service required no client intervention.
How does Azure Sphere make it simpler for users to change certificates?
IoT device failures frequently result from certificate expiration, which Azure Sphere helps stop. The OS and Security Service are both included in the Azure Sphere package. Therefore, Microsoft manages the certifications used by each of these parts. Applications need not be changed for devices to receive new certificates through the DAA process, OS and application updates, and error reporting. For DAA, updates, or problem reports to continue, Microsoft installed the DigiCert Global Root G2 certificate; no consumer changes were necessary. When an update was released, offline devices got the update as soon as they returned to the internet.
The Azure IoT library is also part of the Azure Sphere OS, so if Microsoft changes the certifications that the Azure IoT libraries depend on in the future, we will update the library in the OS so that your applications won't need to be modified. Additionally, if any edge cases or exceptional situations might call for alterations to your apps or scripts, we'll let you know through extra blog articles.
These examples demonstrate how Azure Sphere streamlines application management by eliminating the requirement for application maintenance updates to address certificate changes. You can easily manage to update any locally-managed certificates your devices and applications use because every device receives an updated certificate as part of its daily attestation. You can deploy a new application image package with updated certificates, for instance, if your application verifies the identity of your line-of-business server (as it should). The Azure Sphere platform's application update services offer those updates, eliminating the possibility that the update service may experience certificate expiration issues on its own.
Frequently Asked Questions
What is the Azure deployment process?
Your application code is located in a deployment source. The deployment source for production apps is typically a repository maintained by version control software like GitHub, BitBucket, or Azure Repos. The deployment source for development and test scenarios could be a local machine project.
What is the deployment model for Azure?
When configuring a cloud solution, Azure has several deployment methods to consider. There are three different deployment types: Public Cloud, Private Cloud, and Hybrid Cloud. Depending on the objectives of the business use case, each deployment methodology has benefits and drawbacks.
How many different deployment models does Azure use?
The Azure cloud platform from Microsoft provides four deployment strategies.
What components comprise the Azure sphere?
The Azure Sphere Security Service has three parts: password-less authentication, updates, and problem reporting. Without a password, the authentication component provides remote authentication attestation and password-less authentication.
Conclusion
In this article, we have extensively discussed the Deployment basis in Azure Sphere. We will discuss deployment basis, tenants, deployment history and security, device entity and security, Azure sphere OS feeds, and more in detail.
34+ registered 
