mentor.com/embedded
Comprehensive Security for
Internet-of-Things Devices
With ARM
®
TrustZone
®
Internet-of-Things Trends
The world is more connected
Exposure via many
connectivity options
increases attack surfaces and jeopardizes reliable system function.
Widespread use of Open Source Software
Ecosystems of applications offer consumer demanded experiences. Open
standards increase adoption of technology.
IoT devices are smarter and more complex
Highly integrated systems
need separation and
protection of the sensitive data.
Separation, Security and Performance
are increasingly important for the embedded devices driven to a large extent by the Intelligent and Open Devices in the Internet of Things world
Defining Internet-of-Things Devices
Standalone
– For purpose built device without network connection
Connected
– Networked device with limited capabilities
and one way access
Managed
– Monitor
– Configure
Securing Internet-of-Things Devices
Data at Rest: when device is off, how is it protected
– Anti-tampering, encrypted files and databases, trusted boot
Data in Use: while generated or processed
– Obfuscation, chain of trust, attestation, ADRNG, TrustZone, MMU
based protection methods, user privileges and secure file systems
Data in transit: as it leaves the device
– Encryption, tunneling protocols, VPN, SSL, IKE/IPSEC, denial of
How much security is enough?
Economic Security: approach to allow for a cost
effective security enhancement
– Identify level of protection
– Define adequate level of security
– Describe countermeasures against weakness
– Focus on cost-efficient realization
– Build upon existing processes
Engineering Leadership and Business Managers
could be confused about the technology and
standards, but they care about:
When to address device security?
Securing IoT device is not just a matter of selecting
the right processor and software, one has to be
concerned with many aspects of device lifecycle!
Design Design Production Production Deployment Deployment Operation & Maintenance Operation & Maintenance Destruction or disposal Destruction or disposalWhen to address device security?
Data needs to be protected at rest, use and transit
during all phases!
Cryptography ≠ Security!
Design Design Production Production Deployment Deployment Operation & Maintenance Operation & Maintenance Destruction or disposal Destruction or disposalImportant Security Terms
Secure by Default
– is one of the principles of CLASP (Comprehensive, Lightweight Application Security Process) which provides a well-organized and
structured approach for moving security concerns into the early stages of the software development lifecycle, whenever possible.
CVE ®
– International in scope and free for public use, CVE is a dictionary of
publicly known information security vulnerabilities and exposures. CVE’s common identifiers enable data exchange between security products and provide a baseline index point for evaluating coverage of tools and
services.
US-CERT
– is part of DHS' National Cyber-security and Communications Integration Center (NCCIC). Computer Emergency Readiness Team (US-CERT) leads efforts to improve the nation's cyber-security posture, coordinate cyber information sharing, and proactively manage cyber risks while protecting the constitutional rights of Americans.
Important Security Terms
Security Development Lifecycle (SDL)
– is a software development process that helps developers build more
secure software and address security compliance requirements while reducing development cost.
Identifying vulnerabilities
1 Account lockout attack
2 Asymmetric resource consumption (amplification)
3 Binary planting
4 Blind SQL Injection
5 Blind XPath Injection
6 Brute force attack
7 Buffer overflow attack
8 Cache Poisoning
9 Cash Overflow
10 Code Injection
11 Command Injection
12 Comment Injection Attack
13 Content Security Policy
14 Content Spoofing
15 CORS OriginHeaderScrutiny
16 CORS RequestPreflighScrutiny
17 Cross Frame Scripting
18 Cross Site History Manipulation (XSHM)
19 Cross Site Tracing
20 Cross-Site Request Forgery (CSRF)
21 Cross-site Scripting (XSS)
22 Cross-User Defacement
23 Cryptanalysis
24 CSRF
25 Custom Special Character Injection
26 Denial of Service
27 Direct Dynamic Code Evaluation ('Eval Injection')
28 Direct Static Code Injection
29 Double Encoding
30 Execution After Redirect (EAR)
31 Forced browsing
32 Format string attack
33 Full Path Disclosure
34 HTTP Request Smuggling 35 HTTP Response Splitting 36 Inyección SQL 37 LDAP injection 38 Man-in-the-browser attack 39 Man-in-the-middle attack
40 Mobile code: invoking untrusted mobile code
41 Mobile code: non-final public field
42 Mobile code: object hijack
43 One-Click Attack
44 Overflow Binary Resource File
45 Page Hijacking
46 Parameter Delimiter
47 Path Manipulation
48 Path Traversal
49 Reflected DOM Injection
50 Regular expression Denial of Service - ReDoS
51 Relative Path Traversal
52 Repudiation Attack
53 Resource Injection
54 Server-Side Includes (SSI) Injection
55 Session fixation
56 Session hijacking attack
57 Session Prediction
58 Setting Manipulation
59 Special Element Injection
60 Spyware
61 SQL Injection
62 Traffic flood
63 Trojan Horse
64 Unicode Encoding
65 Web Parameter Tampering
66 Windows ::DATA alternate data stream
67 XPATH Injection
68 XPATH Injection Java
69 XSRF Categories of Attacks
1 7Abuse of Functionality
2 3Data Structure Attacks 3 4Embedded Malicious Code 4 9Exploitation of Authentication 5 26Injection
6 1Path Traversal Attack
7 4Probabilistic Techniques 8 3Protocol Manipulation 9 3Resource Depletion 10 10Resource Manipulation 11 Sniffing Attacks 12 4Spoofing total 74 Types of Attacks 1 Access Attacks 2 Modification Attacks 3 Repudiation Attacks
4 Denial of Service Attacks 5 Information Theft
Embedded Device Attack Vectors
Loading valid software on unauthorized device
Hacking the boot process to load unauthorized OS + App Hacking the device by loading unautharised App
Taking over the device to access data at rest
Intercepting communications to access data in transit Uploading malware to prevent device from operating
Subjecting device to denial of service attacks to affect its operation Preventing user, device or service authentication
Root of Trust
Establishing Hardware and Software Chain of Trust from the root – HARDWARE!
Device Hardware to Boot Boot to OS ApplicationOS to Execution
Prevent untrusted OS from launching Prevent untrusted Application from executing Prevent attacks Authorized Access Prevent untrusted boot
Before loading any software, ask:
• Did it come from the OEM?
• Has it been tampered with?
Hardware should be used for:
• Crypto Key Storage
• Signature Generation, Comparison
• Signature Storage
Security 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”.
Security 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 NS NS NS NS S NS NS NS
Security 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 NS NS NS NS S NS NS NS
Security 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 NS NS NS NS S NS NS NS
ARM TrustZone worlds
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”.
Normal World applications is assumed to be flawed from a safety
and security perspective. This software is expected to contain bugs, exploits, hacks, faults, or irregularities that could expose sensitive information or functions.
Secure World applications have complete access to the hardware
and resources that are associated with both worlds.
TrustZone does nothing to improve the safety or security of the
Trusted software itself which must be explicitly tested and
ARM TrustZone & Multicore
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”.
Secure World Apps run on each core Secure World Apps run on dedicated core
TrustZone without Virtualization can not separate and secure
multiple operating systems running on multicore silicon!
Security via Virtualization
Embedded hypervisors
— High performance, e.g. runtime and boot time
— Strong isolation
— Highly robust
Hypervisor Security
— Strong isolation and containment of guests
— Secure critical information and software
Consolidation and Widespread use of open source software
— Embedded Linux gaining widespread adoption
— System robustness allowed by separation
— IP protection provided through system partitioning
Mem Dev App RTOS Mem Dev App BME vCPU vCPU Memory Devices CPU Hypervisor Mem vDev Apps Linux vCPU vCPU CPU
Virtualization benefits
Security and Robustness
— Isolation of critical software from the rest of the code and reducing the
burden of testing and re-certification
Licensing and IP Separation
— Partitioning of the software with incompatible licensing terms and
protecting of proprietary IP from open source licensing terms
Software Reuse
— Upgrade path from an RTOS based device to the one that incorporate
Linux, allowing to leverage Linux software ecosystem while preserving legacy investment
Real Time Performance
— Devices that take advantage of Linux ecosystem and wealth of existing
functionality could benefit from real time responsiveness of BM guest
Fast Startup
Virtualization and ARM TrustZone
Hypervisor Apps Guest kernel & drivers Apps Guest kernel & drivers Secure Apps TEE Kernel Mode User ModeNormal World Secure World
Hypervisor
Secure Apps
TEE
Normal World Secure World
User Mode Kernel Mode Cortex-A9 core(s) Cortex-A9 core(s) Guest kernel & drivers Apps Apps Guest kernel & drivers
Combining Virtualization with ARM TrustZone hardware
enabled capabilities present in Cortex®-A9 and Cortex®-A15
cores creates secure and robust application environment. Apps Guest kernel & drivers Apps Guest kernel & drivers Hypervisor HYP Mode Kernel Mode User Mode Secure Apps Cortex-A15 core(s) TEE Secure World Normal World
Virtualization and ARM TrustZone
Combining Virtualization with ARM TrustZone hardware
enabled capabilities present in Cortex®-A9 and Cortex®-A15
cores creates secure and robust application environment.
When using ARMv8-A devices such as A53 or A57, a starting point should be ARM Trusted Firmware. It runs in the new Secure EL3 mode and provides low level 64-bit Secure World code such as SMC Calling convention, Power State Coordination Interface and other low level functions.
Apps Guest kernel & drivers Apps Guest kernel & drivers Hypervisor HYP Mode Kernel Mode User Mode Secure Apps Cortex-A53 core(s) TEE Secure World Normal World
ARM Trusted Firmware
SEL3 SEL1 SEL0
Virtualization and ARM TrustZone
CPU
Memory Devices
CPU CPU CPU
Hypervisor Mem Dev App RTOS DRM vCPU
Device A Device B Memory Memory
Normal World Secure World
Encryption Secure Boot Key Mgmt Mem Dev App Linux vCPU CPU Memory Devices
CPU CPU CPU
Hypervisor Mem Dev App RTOS DRM vCPU
Device A Device B Memory Memory Encryption Secure Boot Key Mgmt Mem Dev App Linux vCPU
Normal and Secure World interaction
Hypervisor Normal World Guest 1 Secure World Guest 0 Linux App Linux App Requiring Secure World SupportMulticore ARM® SOC with TrustZone® Technology
Memory Devices
Device A Device B Memory Memory
Scheduler Linux Kernel TrustZone Kernel Module TEE Internal API Secure App 1 Cores TrustZone Kernel Module Secure App 2 Secure App 3 Dispatcher Monitor Shared Memory Linux App Linux App Requiring Secure World Support TEE Client API
Linux Kernel
TEE Client API
Kernel Space User Space Hypervisor Space FIQ IRQ FIQ IRQ