Io t security and azure sphere

Editor's Notes

1. Spoofing Involves illegally accessing and then using another user's authentication information, such as username and password Tampering Involves the malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet Repudiation Associated with users who deny performing an action without other parties having any way to prove otherwise—for example, a user performs an illegal operation in a system that lacks the ability to trace the prohibited operations. Non-Repudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package Information Disclosure Involves the exposure of information to individuals who are not supposed to have access to it—for example, the ability of users to read a file that they were not granted access to, or the ability of an intruder to read data in transit between two computers Denial of Service Denial of service (DoS) attacks deny service to valid users—for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability Elevation of Privilege An unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself, a dangerous situation indeed
2. Highly secure devices have a hardware-based root of trust. Device secrets are protected by hardware and the hardware contains physical countermeasures against side-channel attacks. Unlike software, hardware has two important properties that may be used to establish device security. First, single-purpose hardware is immune to reuse by an attacker for unintended actions. Second, hardware can detect and mitigate against physical attacks; for example, pulse testing the reset pin to prevent glitching attacks is easily implemented in hardware. When used to protect secrets and device correctness, hardware provides a solid root of trust upon which rich software functionality can be implemented securely and safely. 4 Highly secure devices have a small trusted computing base. The trusted computing base (TCB) consists of all the software and hardware that are used to create a secure environment for an operation. The TCB should be kept as small as possible to minimize the surface that is exposed to attackers and to reduce the probability that a bug or feature can be used to circumvent security protections. On the contrary, in less secure systems, all security enforcement is implemented in a software stack that contains no protection boundaries. Highly secure devices have defense in depth. In these devices, multiple mitigations are applied to each threat. In systems with only a single layer of defense, just a single error in design or implementation can lead to catastrophic compromise. Attackers are creative; threats are often not completely anticipated, so having multiple countermeasures often becomes the difference between a secure or compromised system. Highly secure devices provide compartmentalization. Compartments are protected by hardware enforced boundaries to prevent a flaw or breach in one software compartment from propagating to other software compartments of the system. Compartmentalization introduces additional protection boundaries within the hardware and software stack to create additional layers of defense in depth. For example, a common technique is to use operating systems processes or independent virtual machines as compartments. On the contrary, many low-cost devices employed an RTOS design with no software separation. Highly secure devices use certificate-based authentication. Certificates, instead of passwords, are used to prove identities for mutual authentication when communicating with other local devices and with servers in the cloud. A certificate is a statement of identity and authorization that is signed with a secret private key and validated with a known public key. Unlike passwords or other authentication mechanisms that are based on shared secrets, certificates can’t be stolen, forged, or otherwise used to authenticate an impostor. Highly secure devices have renewable security. A device with renewable security can update to a more secure state automatically even after the device has been compromised. Security threats evolve and attackers discover new attack vectors. To counter emerging threats, device security must be renewed regularly. In extreme cases, when compartments and layers of a device are compromised by zero-day exploits, lower layers must rebuild and renew the security of higher levels of the system. Remote attestation and rollback protections guarantee that once renewed, a device cannot be reverted to a known vulnerable state. A device without renewable security is a crisis waiting to happen. Highly secure devices have failure reporting. When a failure occurs on these devices, a failure report is collected automatically and sent to a failure analysis system in a timely manner. In the best case, a failure is triggered by imperfect programming for an extremely rare sequence of events. In the worst case, a failure is triggered by attackers probing for new attack vectors. Whatever the case, a failure analysis system correlates failure reports that have similar root causes. With a sufficiently large reporting base, even extremely rare failure events can be diagnosed and corrected, and new attack vectors can be identified and isolated before they are widely exploited. Failure reporting creates a global ‘immune system’ for highly secure devices. Without failure reporting, device manufacturers are left in the dark as to the device failures experienced by their customers and may be caught off guard by emerging attacks.
3. Azure Sphere certified microcontrollers (MCUs): Basically, an MCU functions as the brain of the device. It is in the form of a tiny chip. Azure Sphere certified MCUs are another class of MCUs that has both real-time and application processors with built-in Microsoft security innovation and network. Each chip incorporates custom silicon security innovation from Microsoft, propelled by 15 years of experience and learnings from Xbox, to secure this new class of MCUs and the devices they control.   Azure Sphere Operating System: This Operating System is a purpose-built Operating System that offers unequalled security and capability. Dissimilar to the RTOSes regular to MCUs today, the defense-in-depth IoT OS offers multiple layers of security. It combines security developments in Windows, a security screen, and a custom Linux part to make a profoundly secured programming condition and a reliable stage for new IoT encounters.   Azure Sphere Security Service: A turnkey is a cloud service that protects each Azure Sphere device, handling trust for device to-device and device to-cloud communication through certificate-based authentication validation, distinguishing rising security threats over the whole Azure Sphere environment through online failure reporting, and re-establishing security through software updates. It brings the accuracy and scale Microsoft has worked over decades ensuring their devices and information in the cloud to MCU controlled devices. Microsoft is working specifically with pioneers in the MCU space to construct a wide ecosystem of silicon partners and will be joining Microsoft’s silicon security innovations with their unique capacities to convey Azure Sphere certified chips. With these silicon partners, they have made a progressive new age of MCUs. These chips have connectivity, unequalled security and advanced processing power to empower new customer experiences. Each Azure Sphere chip incorporates Microsoft Pluton security subsystem, run the Azure Sphere OS, and associate with the Azure Sphere Security Service for basic and secure updates, failure reporting, and authentication. The first Azure Sphere chip will be the MediaTek MT3620. Other early accomplices incorporate Arm, who worked intimately with Microsoft to fuse their Cortex-An application processors into Azure Sphere MCUs.
4. The Pluton security subsystem forms the hardware root of trust for Sopris. Unlike the much more primitive memory protection unit (MPU) found in most microcontrollers, the MMU on the Sopris processor supports multiple levels of isolation and multiple independent address spaces from which an OS can create process-isolation compartments. The addition of on-die SRAM allows easy experimentation with many OS configurations while maintaining the security of on-die memory. Central to our work is the belief that practically any type of device can be converted into a highly secure device with a set of modest changes. We hypothesize that this can be done by including in the device an isolated hardware security module to provide a hardware-based secure root of trust and modifying the rest of the device hardware architecture to allow defense in depth and compartmentalization. We have created a hardware security module we call Pluton.3 We believe that adding Pluton, or an equivalently-featured security module, to a device design is a significant necessary step towards creating highly-secure devices. The Pluton security subsystem includes a Security Processor (SP) CPU, cryptographic engines, a hardware random number generator (RNG), a key store, and a cryptographic operation engine (COE). The cryptographic engines in Pluton include an AES [10] symmetric-key decryption and encryption engine, a SHA [11] hashing engine used for measuring code and checking certificates, and a public key engine for accelerating RSA [12] and ECC [13] public key operations. The hardware RNG is used to randomize the execution of the boot firmware so an adversary can’t easily precisely time an attack, and for key generation and other cryptographic needs. The COE performs operations that require more than one cryptographic engine. An example of a COE command includes an attestation where a code measurement register is appended with a challenge from another device using the SHA engine, and the result is signed using the attestation private key in the key store using the public key engine.
5. The Pluton security subsystem forms the hardware root of trust for Sopris. Unlike the much more primitive memory protection unit (MPU) found in most microcontrollers, the MMU on the Sopris processor supports multiple levels of isolation and multiple independent address spaces from which an OS can create process-isolation compartments. The addition of on-die SRAM allows easy experimentation with many OS configurations while maintaining the security of on-die memory. Central to our work is the belief that practically any type of device can be converted into a highly secure device with a set of modest changes. We hypothesize that this can be done by including in the device an isolated hardware security module to provide a hardware-based secure root of trust and modifying the rest of the device hardware architecture to allow defense in depth and compartmentalization. We have created a hardware security module we call Pluton.3 We believe that adding Pluton, or an equivalently-featured security module, to a device design is a significant necessary step towards creating highly-secure devices. The Pluton security subsystem includes a Security Processor (SP) CPU, cryptographic engines, a hardware random number generator (RNG), a key store, and a cryptographic operation engine (COE). The cryptographic engines in Pluton include an AES [10] symmetric-key decryption and encryption engine, a SHA [11] hashing engine used for measuring code and checking certificates, and a public key engine for accelerating RSA [12] and ECC [13] public key operations. The hardware RNG is used to randomize the execution of the boot firmware so an adversary can’t easily precisely time an attack, and for key generation and other cryptographic needs. The COE performs operations that require more than one cryptographic engine. An example of a COE command includes an attestation where a code measurement register is appended with a challenge from another device using the SHA engine, and the result is signed using the attestation private key in the key store using the public key engine.