Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Io t security and azure sphere
Similar to Io t security and azure sphere (20)
Recently uploaded
Recently uploaded (20)
Io t security and azure sphere
- 1. IoT Security and Azure Sphere Pune DevCon 2018 Pushkar Saraf #PuneDevCon 1
- 2. History Why consider security Device Attacks and its effects Principles of highly secured devices Azure and IoT the Love Birds Azure Sphere overview Getting Started with VS Azure Sphere SDK Connecting your Sphere to IoT Hub Agenda
- 3. IoT applications across domains
- 5. Agenda
- 7. 240 102 570 912 302 138 734 1174 373 186 946 1506 459 251 1221 1931 541 327 1589 2457 631 415 2071 3118 0 500 1000 1500 2000 2500 3000 3500 Endpoint Security Gateway Security Professional Services Total IoT Security Growth Potential : Gartner 2016 2017 2018 2019 2020 2021
- 8. General types IoT attacks BoTNets Man in the Middle Data and Identity Thefts DDos Jamming
- 9. Disastrous Attacks BrickerBoT – Hardware devices Botnet Barrage – Network Infra Finland Cold – Infrastructure Fishtank Jumpbox – Casino Hackable Cardiac Devices - HealthCare TrendNet WebCam Hack – Monitoring and Surveillance The Jeep Hack – Automotive
- 10. How to Crack a Rpi Use your own Rpi Get the SD Card Edit the file cmdline.txt | Append ‘init=/bin/sh’ Remount the drive in in RW ( Read write) mode Enter your desired password as the Super user Done! the device is compromised
- 11. What is Azure’s offering
- 12. Spoofing - Steal credentials and use them as your own Tampering - Modification of the source information/ flowing information between devices Repudiation- Associated with users who deny performing an action without other parties having any way to prove otherwise Information Disclosure -Involves the exposure of information to individuals who are not supposed to have access to it Denial of Service - Denial of service (DoS) attacks deny service to valid users. Elevation of Privilege -An unprivileged user gains privileged access and gradually gains access to all other systems STRIDE
- 13. Properties of Highly Secure Devices Hardware Root of Trust Small Trusted Computing Base Defense in Depth Compartmentalization Certificate Based Authentication Renewable Security Failure Reporting Device Identity secured by hardware Security breach and Device Integrity TCB protection Post facto Security Improvisation Certificate instead of password Auto Updates Compromised device reporting
- 14. • Hardware to protect Device Identity • Hardware to Secure Boot • Hardware to attest System Integrity • Hardware to Create Barriers • Security Configured compartmentsegrity • Updates Pushed through Cloud • In-built update manager • Hardware to Roll Back Integrity Azure Sphere
- 15. Azure Sphere MCU Overview • CONNECTED with built-in networking • SECURED with built-in Microsoft silicon security technology including the Pluton Security Subsystem • CROS SOVER Cortex-A processing power brought to MCUs for the first time
- 16. Secure Application Sandboxes Compartmentalize code for agility, robustness & security On-chip Cloud Services Provide update, authentication, and connectivity Custom Linux kernel Empowers agile silicon evolution and reuse of code Security Monitor Guards integrity and access to critical resources Azure Sphere OS Architecture
- 17. hardware-based root of trust; device secrets are protected in the Pluton security subsystem provides a small trusted computing base; for most operations supports certificate-based authentication; for example, private keys stored in the Pluton security subsystem can form the basis of a secure per-device certificate chain compartmentalization; for example, separate compartments can be implemented using isolated address spaces enabled by the upgraded CPU. supports renewable security; use the multiple layers of hardware-protected defense in depth to implement renewable security supports failure reporting; for example, failure handling code that runs on the it can collect data about failures and relay that information to a failure analysis service
- 18. How to get Started Experimenting MT3620 Brush up your C skills Order a Dev Kit : Seeed Studio Get Azure Sphere SDK for Visual Studio
- 19. Hands on with MT3620 Azsphere login - > Login to your Org Account azsphere tenant create --name <my-tenant> | azsphere device claim azsphere device wifi show-status azsphere device wifi add --ssid <yourSSID> --key <yourNetworkKey> azsphere device prep-debug | Ataches a debug server to your device Connect to IoT Hub Refer Development Board user guide for detailed control Get Grove shield to experiment more on device capabilities
- 20. Hands on with MT3620
- 23. Celebrating 14 glorious years of sharing passion 23 PUG Technology Foundation
Editor's Notes
- 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
- 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.
- 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.
- 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.
- 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.