The document discusses various topics related to security for Internet of Things (IoT) systems. It begins with an overview of the types of markets and applications that IoT spans. It then discusses secure data storage and transmission, authentication methods like secure boot, and threats faced by IoT devices at boot-time and run-time. Finally, it discusses approaches to enhance security including using ARM TrustZone and virtualization with a hypervisor.

1. mentor.com/embedded
Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
A Live Google+ On-Air Hangout
April 29th, 2014
Security Strategies for
IoT Systems from
Devices to the Cloud

2. 2
mentor.com/embedded
22
The Internet of Things Spans Markets
Smart Parking
Monitoring of parking spaces availability in the
city.
Structural health
Monitoring of vibrations and material conditions
in buildings, bridges and historical monuments.
Noise Urban Maps
Sound monitoring in bar areas and centric zones
in real time.
Traffic Congestion
Monitoring of vehicles and pedestrian levels to
optimize driving and walking routes.
Smart Lighting
Intelligent and weather adaptive lighting in street
lights.
Waste management
Detection of rubbish levels in containers to
optimize the
trash collection routes.
Intelligent Transportation Systems
Smart Roads and Intelligent Highways with
warning messages and diversions
according to climate conditions and
unexpected events like accidents
or traffic jams.
Forest Fire Detection
Monitoring of combustion
gases and preemptive
fire conditions to define alert
zones.
Air Pollution
Control of CO2 emissions of
factories, pollution
emitted by cars and toxic
gases generated in farms.
Landslide and Avalanche
Prevention
Monitoring of soil moisture,
vibrations and earth
density to detect dangerous
patterns in land
conditions.
Earthquake Early
Detection
Distributed control in specific
places of tremors
Smart Cities Smart Environment Smart Energy
Smart Grid
Energy consumption monitoring
and
management.
M2M Applications
Machine auto-diagnosis and assets control.
Indoor Air Quality
Toxic gas and oxygen levels gas levels in chemical
plants.

3. 3
mentor.com/embedded
33
SERVICES
LAN
WAN
CLOUD
PAN
Open fridge
– remind
me to track
food eaten

4. 4
mentor.com/embedded
4
Secure Data, Applications and Services
 Secure data storage and transmission
— Encryption algorithmic
— Cryptography
— Network security with both IP Security (IPsec/IKE) and SSL
 Enhanced security options through ARM TrustZone®
— Secure boot
— Secure data storage
– secure data storage
— Application download/updating
— Secure event logging
 Secure Lifecycle through US
Computer Emergency Readiness
Team (CERT) monitoring and patch
support
 Web service permissions, authorization and validation

5. 5
mentor.com/embedded
5
Security Needs Vary by Application
Acute Care
Proactive Health
Monitoring
Fitness
Healthy
Lifestyle
Clinic
Hospital
ICU
Home Care
Chronic Disease
Management
Doctor’s Office
Community Clinic
Residential Care
Assisted Living
Skilled Nursing
Facility
Diagnostics and Therapy Devices and Procedures moving away from Traditional Hospital

6. 7
mentor.com/embedded
7
Security vs. Reliability
Negative vs. Positive Goal

7. 8
mentor.com/embedded
8
Threats Faced by IoT Devices
 Boot-time Threats
— Trust
— Authentication
 Run-time Threats
— User space
— Networking

8. 9
mentor.com/embedded
9
Root of Trust
Establishing SW / HW Trust
1. Hardware to BootROM
2. BootROM to Operating System
3. Operating System to Application
Device
Hardware
to Boot
Boot to
OS
OS to
Application
Execution
Prevent
untrusted OS
from launching
Prevent
untrusted
Application
from executing
Prevent
attacks
Authorized
Access
Prevent
untrusted boot

9. 10
mentor.com/embedded
10
Boot-Time Authentication
 Binary OS image authentication
— Did it originate from OEM?
— Has it been modified?
Memory
Nucleus Image

10. 11
mentor.com/embedded
11
Boot-Time Authentication
Private Key Public Key
SignatureSignature Generation
Signature Verification
Nucleus RTOS

11. 12
mentor.com/embedded
12
Boot-Time Authentication
 Binary OS image authentication
— Did it originate from OEM?
— Has it been modified? Memory
Nucleus
RTOS
Signature
MatchLoad Load

12. 13
mentor.com/embedded
First Stage
Boot Loader
Signature
Crypto Key
Establishing Root of Trust
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
App 1
App 2
App NBefore loading any software, ask:
• Did it come from the OEM?
• Has it been tampered with?

13. 14
mentor.com/embedded
14
Boot-Time Protection
Freescale i.MX example
 High Assurance Boot (HAB)
— Services to ROM to authenticate software that executes immediately after ROM
(typically Boot code)
— Uses Digital Signatures
 Used to authenticate boot code in external memory image prior to
execution
 Boot modes controlled by fuse setting
— NAND, SD/MMC card, EEPROM, USB
 HAB library contains functions to authenticate
— Authentication based on public keys using RSA algorithm
– Signed off line using private keys
– Image verified using public keys
— Encryption AES-128
Enable Features offered by silicon vendors to provide layered security

14. 15
mentor.com/embedded
15
BootROM to Operating System and App
Signature Generation
• Hash using SHA-1
• RSA (Rivst-Shamir-Adelman) used for signature generation with
manufacturer private key
• Signature and product software downloaded into external flash
memory
SHA-1 ZQ*&@Q310
RSA – private key
signature
Signature Verification
SHA-1 ZQ*&@Q310
RSA – Public Key
signature
ZQ*&@Q310
Product
Software
Compare

15. 16
mentor.com/embedded
16
User Space Threats
 Memory Protected
Modules
 Prevents sub-systems
from bringing down
the system
 No virtual addressing
 Multiple Types
 Application, Libraries,
Hybrids
 Memory Protection for
 Text
 Data
 Stack
 Kernel Isolation
Memory Protected
Memory
Protected
Memory
Protected
Memory
Protected
File
Systems
Peripheral
Bus Drives
GUI
Power-aware Kernel
StorageLCD
Ethernet/
Wireless
Devices
Memory
Protected
Application 1
Task 1
Task 2
…
Task n
Library 1
Function 1
Function 2
…
Function n
Hybrid 1
Task 1
Function 1
…
Task n
Function n
Application 2
Task 1
Task 2
…
Task n
Networking

16. 17
mentor.com/embedded
17
Networking Threats
 Device Network testing
— Tests Devices with millions of attack
packets to flood and stress device
— Monitor failures in protocol stack and
process control functions
— Determine the functional health of the
device during attack
 Types of Tests
— Storms
– Denial of Service tests that send
packages at high rates
— Fuzzers/grammars
– Invalid packets that do not conform to
protocols specifications
– Fragmented packets
– Overlapping packets or most but not all
of packets
— Known vulnerabilities
– Packets that exploit particular
vulnerabilities

17. 18
mentor.com/embedded
1818
Nucleus RTOS for IoT
Hypervisor Trusted Execution Environment

18. 19
mentor.com/embedded
19
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 can be further enhanced via
– Trusted boot
– Software security through separation

19. 20
mentor.com/embedded
20
ARM TrustZone Worlds
Software that runs in the Normal World 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 independently
validated.
1 2 3
4 5 6
7 8 9
* 0 #
Secure Element
(SecurCore)

20. 21
mentor.com/embedded
21
Secure World Apps
run on each core
Secure World Apps
run on dedicated core
ARM TrustZone Configurations

21. 22
mentor.com/embedded
22
ARM TrustZone deficiencies
TrustZone includes features that may be helpful to Multi-Core and Multi-
OS support, but it alone fails to provide some fundamental capabilities
typically required by an embedded system:
— No separation of Normal World resources from Secure World
— No Separation of multiple,
non-Secure Domains
— Limited Device Register Data
Save/Restore Function
A full safe and secure solution needs a combination of
hardware and software elements using virtualization!

22. 23
mentor.com/embedded
23
A Solution Approach: 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
 Widespread use of open source software
— Embedded Linux gaining widespread adoption
— System robustness allowed by separation
— IP protection provided through system
partitioning
RTOS
SW Stack 1 SW Stack 2
CPU Core
Memory
Peripherals
Hypervisor
CPU Core
CPU Core CPU Core
RTOS
RTOS
Bare-Metal

23. 24
mentor.com/embedded
24
ARM TrustZone Environment
ARM TrustZone supported features
CPU
MemoryDevices
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
MemoryDevices
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

24. 25
mentor.com/embedded
25
Hypervisor and TrustZone combined
Apps
Guest
kernel &
drivers
Apps
Guest
kernel &
drivers
HypervisorHYP
Mode
Kernel
Mode
User
Mode
Normal World
Secure
Apps
Cortex A15 core(s)
TEE
Secure World
Hypervisor
Apps
Guest
kernel &
drivers
Apps
Guest
kernel &
drivers
Secure
Apps
TEE
Kernel
Mode
User
Mode
Normal 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 A15 cores
creates secure and robust
application environment.

25. 26
mentor.com/embedded
26
BACKUP SLIDES

26. 27
mentor.com/embedded
27
Hypervisor
Normal World
Guest 1
Secure World
Guest 0
Normal and Secure World interaction
Linux App
Linux App
Requiring Secure
World Support
Multicore ARM® SOC with TrustZone® Technology
MemoryDevices
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
IRQFIQ
IRQ

27. 28
mentor.com/embedded
28
Virtualization: Secure Consolidation
CPU
MemoryDevices
CPU CPU CPU
Hypervisor
Mem vDev
Apps
Linux
vCPU vCPU
Mem vDev
Apps
Android
vCPU vCPU
CPU
MemoryDevices
CPU CPU CPU
Hypervisor
Mem vDev
Apps
Linux
vCPU vCPU
Mem vDev
Apps
Linux
vCPU vCPU
CPU
MemoryDevices
CPU CPU CPU
Hypervisor
Mem vDev
Apps
Linux
vCPU vCPU
Mem vDev
Apps
RTOS/BM
vCPU vCPU
Reliably run multiple of the same or different guests

28. 29
mentor.com/embedded
29
List of attacks
29
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

29. 30
mentor.com/embedded
30
More on Attacks
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
1Access Attacks
2Modification Attacks
3Repudiation Attacks
4Denial of Service Attacks
5Information 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

30. 31
mentor.com/embedded
31
Security Framework for End Device
1. Assured data-in-transit protection
2. Assured data-at-rest protection
3. Authentication:
1. User to device
2. User to service
3. Device to service
4. Secure boot
5. Platform integrity and application sandboxing
6. Application whitelisting
7. Malicious code detection and prevention
8. Security policy enforcement
9. External Interface protection
10. Device update policy
11. Event collection for analysis
12. Incident response
CESG = UK Government's National Technical Authority
Guidance document

31. 32
mentor.com/embedded
32
Hardware Traits of Secure Platform
1. Processor Security Controls Limit Access and can not be Bypassed
2. Direct Memory Access (DMA) is Limited and Controlled
3. DMA from External Devices is Additionally Protected
4. Central Processor Access From Other Processing Elements is Minimized and
Controlled
5. Tasks Consuming Platform Resources can be Identified and Controlled
6. Debug Functionality Does Not Compromise Security
7. I/O Control
8. Secure Device Identity
9. Secure Credential Storage
10. Measured/Verified Boot
11. Secure Update/Recovery
12. Control Flow Integrity
13. Security Primitives

32. 33
mentor.com/embedded
33
Communicating with the cloud
 Happens via web services.
 Multiple protocols in use including HTTP(s), Socket Based,
MQTT.
 HTTP based Web Services:
— Representational State Transfer (REST)
— Simple Object Access Protocol (SOAP)
— Remote Procedure Call (RPC)
 Recommendation: use REST style services
— Easy to consume
— Easier to implement

33. 34
mentor.com/embedded
34
Authentication versus Authorization
 So you get a request from a device with some data in the
cloud…
 Need to know 3 things:
— Identification: Who is sending the data?
— Authentication: Are they actually who they say they are?
— Authorization: What are they allowed to do?
 Identification and authentication go hand in hand.
 Authentication is typically necessary, authorization is
optional.

34. 35
mentor.com/embedded
35
Authentication Mechanisms
 Step 1: Decide on what kind of authentication you will
need. This depends on application, and data being stored
— User based (example: OAuth login with Facebook)
— Device based (API Keys)
 Benefits of OAuth:
— Better UX: Lesser accounts that the user has to create/
passwords to remember.
— Reduced complexity: someone else handles authentication.
— Reduced risk: Do not have to store usernames and passwords in
your datastores.
 API Keys:
— API keys are created in the cloud and stored on the device.
— API keys are sent with each request to authenticate device.

35. 36
mentor.com/embedded
36
Authentication with API Keys
Client
Application
Internet Cloud
Web Service
Data
Client
API Key

36. 37
mentor.com/embedded
37
Authentication with API Keys
Client
Application
Internet Cloud
Web Service
API Key in header
Transmit via HTTPS
Data
Client transmits
data to the cloud

37. 38
mentor.com/embedded
38
Authentication with API Keys
Client
Application
Internet Cloud
Web Service
API Key in header
Transmit via HTTPS
Data
Client transmits
data to the cloud
1. Validate API key
sent in request
2. If validated,
store data
3. Respond with
success
HTTP Response 200 OK
Client response
received

38. 39
mentor.com/embedded
39
Best Practices from a cloud standpoint
 Keep web services stateless
— Each request from the client has all the necessary information to
process the request and session state is held on the device.
— Easy to scale and cache requests/responses
 Decide on type of authentication up front
(User/OAuth/Key based).
— Depends on the usecase
 Always use HTTPS.
— You can encrypt your request with private keys that are
understood by the cloud and client, but never sent over the wire.
 Send API keys as an HTTP Header.
— Put your API keys in the HTTP Headers. Putting these in the URL
makes them cacheable and loggable

39. 40
mentor.com/embedded
Rugged Software Development
 Rugged Software movement began in 2010 as a response to
the proliferation of weak and insecure software
 Rugged core values:
— Repeatable
— Limited attack surface
— Automated configuration
— Control instrumentation built-in
 Applicable in cloud and web environments, but also in IoT
backend services

40. 41
mentor.com/embedded
Generic Backend IoT Architecture
Communication Layer
Network (wifi, 3g, 4g)
API Support
Rules and Control Engine
Visualization
Logging Monitoring
Device Mgmt
Node A Node B Node n
Alerting
Applications
Mobile
Web
Node

41. 42
mentor.com/embedded
Threats Faced by Cloud Services
 The backend services that IoT devices consume can be
spoofed
 DDOS against cloud services can be used to make IoT
devices inoperable
 Weak security in multi-tenant environments can expose
data and information
 General web application security challenges (OWASP)

42. 43
mentor.com/embedded
Agile, DevOps and Rugged
 Emphasis on testing and monitoring
 Treat server infrastructure as code and version control it
 Automate tests and integrate with monitoring
 DevOps == CAMS (Culture, Automation, Measurement and
Sharing)
 Use security tools as part of build candidate validation
BuildDev Test Deploy Security Testing
~12 mos later

43. 44
mentor.com/embedded
Agile, DevOps and Rugged
 Emphasis on testing and monitoring
 Treat server infrastructure as code and version control it
 Automate tests and integrate with monitoring
 DevOps == CAMS (Culture, Automation, Measurement and
Sharing)
 Use security tools as part of build candidate validation
BuildDev
Test
Deploy
Security Testing

44. 45
mentor.com/embedded
Expressive tooling for Security and
Rugged Testing
Scenario: Using arachni, look for cross site scripting and
verify no issues are found
Given "arachni" is installed
And the following profile:
| name | value |
| url | http://localhost:80 |
When I launch an "arachni-simple_xss" attack
Then the output should contain "0 issues were detected.”

45. 46
mentor.com/embedded
46
Security Strategies for IoT: From Devices to the Cloud
Thank you for attending. The archived video of this
hangout will be available on this event page shortly.
For any questions email us at embedded_software@mentor.com or visit
us at http://www.mentor.com/embedded .