How to protect Automotive systems with ARM Security Architecture

Size: px

Start display at page:

Download "How to protect Automotive systems with ARM Security Architecture"

Cassandra Rose
5 years ago
Views:

1 How to protect Automotive systems with ARM Security Architecture Thanks to this app You can manoeuvre The new Forpel Using your smartphone! Too bad it s Not my car

Successful products will be attacked Attack surface is ever expanding More networked MCUs are interacting Cars are becoming more vulnerable: Greater computer interaction with steering, brakes Remote

2 Successful products will be attacked Attack surface is ever expanding More networked MCUs are interacting Cars are becoming more vulnerable: Greater computer interaction with steering, brakes Remote wireless connectivity and remote interaction Bridges to Controller Area Network (CAN) 2 Attackers have the privilege of selecting where to attack Security researchers willing to spend years on high profile attacks Since these remote attacks will necessarily be multi-stage, we recommend a defense in depth strategy Survey of remote automotive attack surfaces: Miller & Valasek

3 Connected to the Internet & CAN 3

4 Security principles for automotive Lifecycle Security non-trusted Communications Security trusted Device Security Crypto Root of Trust trusted software trusted hardware secure system secure storage 4

5 Layers of security to protect your system Cost/Effort To Attack Trusted Execution Environment (TEE) Security Subsystem & HSM Secure Element Transport Layer Security (TLS) SW & HW Attacks Physical access to device JTAG, Bus, IO Pins, Time, money & equipment. Software Attacks Buffer overflows Interrupts Malware Communication Attacks Man In The Middle Weak RNG (Random Number Generator) Code vulnerabilities 5 Cost/Effort to Secure H S M = Hardware Security Module

6 Layers of security to protect your system Cost/Effort To Attack TrustZone TEE or SPM* CryptoCell SecurCore mbed TLS SW & HW Attacks Physical access to device JTAG, Bus, IO Pins, Time, money & equipment. Communication Attacks Man In The Middle Weak RNG Code vulnerabilities Software Attacks Buffer overflows Interrupts Malware 6 Cost/Effort to Secure * SPM = Secure Partitioning Manager

7 Establishing trust and integrity based on hardware Apps OS/RTOS Trusted Software TrustZone SPM or TEE irot TrustZone CryptoCell Keys RTOS Trusted Apps/Libs Extended Root of Trust e.g. TrustZone based Secure Partitioning Manager or TEE Initial Root of Trust: Dependable Security functions Provisioned keys/certs 7

8 Ideally a RoT lives in a isolated security subsystem Security Subsystem Security subsystem Highly evaluated code developed by security specialists & built in by silicon vendor 8

platform or ISV + Trusted hardware TrustZone Security Subsystem Security subsystem Implemented as

9 and provides trustworthy services to a hardware isolated TEE (TCB) Normal World IoT developer writes Apps On top of his/her chosen RTOS Secure World = Trusted code (mostly libs) Provided by MDK, IoT platform or ISV + Trusted hardware TrustZone Security Subsystem Security subsystem Implemented as Trusted Peripheral Highly evaluated code developed by security specialists & built in by silicon vendor 9

10 ARM TrustZone Technology in 3 Steps 1. Define secure hardware architecture Two separate domains: normal and secure Extends across system Processor, interrupts, peripherals, memory, key storage, counters 2. Implement in silicon System on Chip (SoC) Enforcing secure/normal separation in hardware 3. Combine SoC with Trusted Software Trusted Boot & Firmware Trusted OS / Secure Partitioning Manager Result: A Trusted Execution Environment (TEE) Ready to develop and deploy trusted services CPU CPU NORMAL SECURE Rich OS Trusted OS Trusted Execution Environment 10

11 Security on Apps processors (e.g.ivi): Defence in depth Normal World Code Trusted Software Apps EL0 EL1 EL2 Apps/User Comms Stack Device Drivers Rich OS Hypervisor FIDO Trusted_Apps Integrity Secure Device Drivers Trusted OS GlobalPlatform Standardisation TrustZone based TEE EL3 SMCCC PSCI Trusted Boot Payload Dispatcher Trusted Firmware Hardware Interfaces ARM Cortex-A SoC System Physical IP CryptoCell Security Services Platform Initial ROT & Security subsystem 11

12 SW platforms require security functions Graphics By Genivi Cooperation 12

Security functions are mapped to security layers Normal World Code Trusted Software Apps EL0 Apps/User Comms Stack FOTA Anomaly Trusted_Apps EL1 Device Drivers Rich OS Secure Device

13 Security functions are mapped to security layers Normal World Code Trusted Software Apps EL0 Apps/User Comms Stack FOTA Anomaly Trusted_Apps EL1 Device Drivers Rich OS Secure Device Drivers Trusted OS EL2 Hypervisor Anomaly EL3 SMCCC PSCI Trusted Boot Payload Dispatcher Crypto Hardware Interfaces HSM ARM Cortex-A SoC System Physical IP CryptoCell Security Services Platform 13

Example: Strong Authentication via FIDO* Only allow authenticated users

can protect integrity/crypto on FIDO server in car TrustZone based TEE

User verification FIDO Authentication TLS secure channel 14 User

14 Example: Strong Authentication via FIDO* Only allow authenticated users to interact No passwords or secrets for the user TrustZone based TEE can protect integrity/crypto on FIDO server in car TrustZone based TEE can protect private keys/crypto and FPS on phone Challenge FIDO Server User verification FIDO Authentication TLS secure channel 14 User gesture e.g. FP Before key can be used * Signed Response

15 Example: Movies & TrustZone Media Protection TrustZone Protected container Protected container Decryption keys Plaintext compressed video stream Working memory Plaintext uncompressed video stream Working memory Frame buffer TrustZone CryptoCell Mali V550 Mali T8xx Mali DP550 Crypto VPU GPU Display Encrypted compressed video stream Non-trusted container UI content Shader programs

16 Next generation TrustZone enabled MCUs TrustZone for ARMv8-M Normal World Code Trusted Software Unprivileged Apps/User Comms Stack Crypto CAN Monitor Trusted Libs TLS/Crypto Libs CMSIS API Privileged RTOS Device Drivers SPM Platform Code TrustZone based Secure Partitioning Manager Hardware Interfaces ARM Cortex -M v8-m Microcontroller Physical IP CryptoCell Security Services Platform Initial ROT & Security subsystem 16

17 Practical steps for designing-in security today Build in layers of hardware based security Unique keys / identities Security subsystems or HSMs TrustZone based TEE or TrustZone based SPM Secure/authenticated debug CAN gateways for isolation and anomaly detection Consider advanced authentication such as FIDO (no passwords) Use end to end encryption TLS for Internet Enable secure OTA updates Have your system/platform penetration tested (e.g. whitebox testing) 17

18 Security Summary The automotive attack surface is expanding with the spread of connected MCU s & at the same time vulnerability is increasing due to the growing autonomous nature of cars Defence in depth is needed TrustZone and CryptoCell provide layers of hardware based security ARM is helping by supplying security architecture, subsystems, TrustZone system IP and open source software to the partnership ARM is accelerating investment in security solutions and OSS 18

19 Thank you! The trademarks featured in this presentation are registered and/or unregistered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners. Copyright 2015 ARM Limited

Trustzone Security IP for IoT

Trustzone Security IP for IoT Udi Maor CryptoCell-7xx product manager Systems & Software Group ARM Tech Forum Singapore July 12 th 2017 Why is getting security right for IoT so important? When our everyday