Using ARM TrustZone Technology for Securing Embedded Devices Running Applications of Mixed Criticality Presenter: Felix Baum, Mentor

Transcription

1 Using ARM TrustZone Technology for Securing Embedded Devices Running Applications of Mixed Criticality Presenter: Felix Baum, Mentor

2 Agenda Objectives Describe the need for hardware enforced security Outline the use cases for the ARM TrustZone deployments Highlight the pros and cons of various options Results Provide a better understanding of how to secure embedded devices by utilizing the ARM Cortex-A hardware and software capabilities Mentor Embedded products

3 Why Secure the Device Devices are everywhere: outside traditional security perimeter Perimeter security is not enough Perimeter can be compromised Insider attacks account for ~70% of threats Your PC is on a secure network but still has endpoint security Embedded devices need the same protection Security of the software in the consolidated multicore device has a new meaning

4 Security starting point: Root of Trust Device Hardware to Boot Boot to OS OS to Application Execution Authorized Access Prevent untrusted boot Prevent untrusted OS from launching Prevent untrusted Application from executing Prevent attacks Establishing Software Chain of Trust from the root HARDWARE! 1. Hardware to Bootrom 2. Bootrom to Operating System 3. Operating System to Application

5 Security starting point: Chain of Trust Before loading any software, ask: Did it come from the OEM? Has it been tampered with? App 1 App 2 App N First Stage Boot Loader Signature Crypto Key Second Stage Boot Loader Signature Crypto Key Operating System(s) Signature Crypto Key ARM TrustZone can be used for: Crypto Key Storage Signature Generation and Comparison Signature Storage Loading OS and Apps Proprietary and Confidential 2014 Mentor Graphics

6 Securing Multicore Devices Linux or RTOS (master) Linux or RTOS or BME Hypervisor Cortex A Cortex A 14 use cases

7 Securing Multicore Devices Linux or RTOS (master) Linux or RTOS or BME RTOS or BME RTOS or BME Hypervisor Cortex A Cortex A Cortex M Cortex M 14 use cases * N use cases

8 Securing Multicore Devices Linux or RTOS (master) Linux or RTOS or BME RTOS or BME RTOS or BME RTOS or BME Hypervisor Cortex A Cortex A Cortex M Cortex M Soft Core 14 use cases * N use cases * M use cases

9 Security and Safety via Separation Safety: Protecting the world from the device Security: Protecting the device from the world Mixed criticality: Protecting of security or safety critical parts of the device from other parts of the device ISO requires freedom from interference. If two systems can interfere with each other, they must be certified to the highest ASIL level of the two. Secure separation aims to eliminate such interference.

10 Use Case 1: Physical Separation aka AMP

11 What the system looks like today Graphics or Web Real Time App SMP Linux A9 A9 Multicore Device running one Operating System Migrating to multicore device for the next generation or project Need to consolidate applications that require real time and determinism with applications requiring Linux networking or graphics services Addressing performance constrains of existing design

12 What the system will look like Graphics or Web Real Time App Linux RTOS A9 A9 or M4 Multicore Device running multiple Operating Systems Single user interface for Configure, Edit, Debug, Optimize work Framework to configure, boot, execute and communicate across cores and Operating Systems Take full advantage of the underlying silicony goodness

13 How this could be accomplished Sourcery CodeBench IDE Floor 5 Room 304 Patient Name: Jan Facility: Clinic User Applications Webserver rpmsg virtio Qt HMI Mentor Embedded Linux Core Lifecycle Management Remote Firmware Patient Sensor Data Acquisition Application Mentor Embedded Multicore Framework remoteproc Nucleus RTOS rpmsg virtio ARM Cortex -A9 IPC Freescale i.mx6 SoloX ARM Cortex -M4

14 Use Case 2: Separation via Virtualization

15 What the system looks like today Cluster App Infotainment App ECU App OS OS Autosar SoC SoC SoC Multiple boards running various Operating Systems and dedicated applications Migrating to multicore device for the next generation or project Need to consolidate applications that require real time with Linux Must share displays and other resources

16 What the system will look like Cluster App Infotainment App ECU App RTOS Linux Autosar A15 Hypervisor A15 M4 Consolidation to a single Heterogeneous Multicore SoC running multiple Operating Systems and Applications Virtualizing GPU to either control multiple displays per application or layer multiple applications on a single display (1:1, 1:N, N:1) Framework to configure, boot, execute and communicate across domains in safe and reliable matter

17 How this could be accomplished Infotainment Display Cluster Display FPD-Link Touch Display 10 (1280x800 ) FPD-Link Display 12 (1280x480 ) BusMaster CAN Vehicle Simulator USB 2CAN CAN BUS AUTOSAR & CAN stack on M4 AXSB J6 IVI Linux Nucleus Hypervisor (2xA15) + GPU sharing

18 Use Case 3: Separation via ARM TrustZone

19 Separation via ARM TrustZone ARM TrustZone can be thought of as a hardware-based solution that can be used to define a subset of the SoC for access by software. Software that is designated as Secure World software has access to ALL of the SoC, while software that is designated as Normal World can access only those HW elements that are defined as Non-Secure.

20 Separation via ARM TrustZone ARM TrustZone can be thought of as a hardware-based solution that can be used to define a subset of the SoC for access by software. Software that is designated as Secure World software has access to ALL of the SoC, while software that is designated as Normal World can access only those HW elements that are defined as Non-Secure. S S

21 Separation via ARM TrustZone ARM TrustZone can be thought of as a hardware-based solution that can be used to define a subset of the SoC for access by software. Software that is designated as Secure World software has access to ALL of the SoC, while software that is designated as Normal World can access only those HW elements that are defined as Non-Secure. S S

22 Separation via ARM TrustZone ARM TrustZone can be thought of as a hardware-based solution that can be used to define a subset of the SoC for access by software. Software that is designated as Secure World software has access to ALL of the SoC, while software that is designated as Normal World can access only those HW elements that are defined as Non-Secure. S S

23 What the system looks like today App 1 App 2 App 1 App 2 RTOS RTOS RTOS A9 A9 A9 One or more cores running applications of various security or robustness levels Migrating to multicore or more powerful device for the next project Need to consolidate applications that require secure and non secure apps

24 What the system will look like Secure App nonsecure App Secure App nonsecure App RTOS RTOS Linux A9 A9 A9 One or more cores running applications of various security or robustness levels Migrating to multicore or more powerful device for the next project Need to consolidate applications that require secure and non secure apps

25 How this could be accomplished Secure App nonsecure App Secure App nonsecure App Nucleus RTOS Data Control Nucleus RTOS or Linux Nucleus RTOS Data Control Nucleus RTOS or Linux TrustZone TrustZone A9 A9 A9 Using the ARM TrustZone capabilities of the SoC separating secure or robust applications from the rest of the system Control only flows from Secure World to Normal World Data could flow either way

26 Use Case 4: Separation via Virtualization and TEE

27 GlobalPlatform and TEE GlobalPlatform.org identifies, develops and publishes specifications for secure and interoperable deployment and management of multiple embedded applications on secure chip technology. The TEE is a secure area within the main processor of a embedded device ensuring that sensitive data is stored, processed and protected in a trusted environment. The TEE offers safe execution of authorized security software and enables it to provide end-to-end security by enforcing protection, confidentiality, integrity and data access rights.

28 What the system looks like today Non-secure Apps Linux A9 Single or Multicore Device running one Operating System Migrating to multicore device for the next generation or project Need to consolidate applications that require real time and determinism with applications requiring Linux networking or graphics services Must address security!!!

29 What the system will look like Real Time App Graphics or Web Secure Apps RTOS Linux Secure OS Cortex A Cortex A Cortex A Multicore Device running multiple Operating Systems Must run Operating Systems reliably and robustly Must have a dedicated context to run secure applications

30 How this could be accomplished Secure App Real Time App Graphics or Web TEE RTOS Linux TrustZone Hypervisor Cortex A Cortex A Multicore Device running multiple Operating Systems Hypervisor supports running Operating Systems reliably and robustly TrustZone and TEE provide a dedicated context to run secure applications according GlobalPlatform specifications

31 Summary Analyze your specific requirements to determine which use case outlined in this session makes sense for your device Integrate security into the device itself don t just rely on a secure perimeter Develop solutions that integrate hardware specific capabilities along with software framework that relies on it

32 The World of Embedded Devices The is no silver bullet or one single button to push to adequately protect an embedded device! Consider using ARM TrustZone and Mentor Graphics products to meet security and regulatory requirements!