The document discusses securing the Internet of Things. It begins by describing common constraints of IoT devices like limited RAM, flash, and CPU capabilities. It then summarizes lessons learned from real-world attacks on IoT systems, including limited software update mechanisms, missing key management, inappropriate access control, lack of communication security, and vulnerability to physical attacks. The document advocates following security best practices like integrating software updates, using modern OS concepts, automated key management, and considering physical attacks in threat analyses. It also describes ARM's contributions to improving IoT security through its mbed platform, libraries, and involvement in standards organizations.
3. 3
§ Ubuntu Core devices will require a
600MHz processor with 128MB
RAM and a 4GB flash for factory
reset and system rollback.
§ Ubuntu Core itself will only take
up 40MB RAM leaving the rest for
applications.
Recent IoT Announcement
5. 5
ARM Processors in Smartphones
§ Cortex-A family:
§ Applications processors
for feature-rich OS
§ Cortex-R family:
§ Embedded processors for
real-time signal processing
and industrial control
applications
§ Cortex-M family:
§ Microcontroller-oriented
processors for low-power
applications.
6. 6
Cortex-M Processors
Lowest cost
Low power
Example:Touchscreen
Controller
Lowest power
Outstanding energy efficiency
Example: Sensor node
Bluetooth Smart
Performance & efficiency
Feature rich connectivity
Example:Weables,
Activity trackers,Wifi receiver
Digital Signal Control (DSC)/
Processor with DSP
Accelerated SIMD
Floating point (FP)
Example: Sensor fusion,
motor control
Processors use the 32-bit RISC architecture
http://www.arm.com/products/processors/cortex-m/index.php
Maximum Performance
Flexible Memory Cache
Single & Double Precision FP
Examples:Automotive,
High-end audio set
7. 7
IoT Device Constraints
§ Common limitations of IoT devices, as described in RFC 7228 on
“Terminology for Constrained-Node Networks”
§ RAM
§ Flash
§ Energy consumption (including sleeping nodes)
§ CPU capabilities
§ Radio technologies with low bitrate, high loss, and small frame sizes (e.g., Bluetooth
Smart, IEEE 802.15.4).
§ also focus on cost reduction.
8. 8
Cost Distribution
Reducing total system cost by enabling better system tradeoffs
We care about this.
… if it results in savings here …
(e.g. sophisticated power management)
But it can make sense to spend more here …
(e.g., on flash/RAM, CPU, BOM)
= + +
Total Cost Hardware Cost Energy Cost Development Cost
(amortized, inc. deployment cost)
… and here.
(e.g. firmware update,
manageability)
More detailed treatment of this topic in a webinar by Peter Aldworth about
“How to Select Hardware for Volume IoT Deployments?”
11. 11
The Internet:A Distributed Design Story
Deployment
Implementation
Protocol Specifications and
Architecture
Cryptographic Primitives
Improved algorithms for integer
factorization, too small key size.
Missing end-to-end security story,
complexity
Buffer overflow attacks, poor UI or
other usability problems, poor choice
of hardware
Enabled debug ports, unfortunate
default settings
Examples of Problems
Understanding the distributed nature of the development process is essential for tackling security problems.
Depending on your role you are a consumer of various technologies and you might be able to influence one or several areas.11
12. 12
Follow Design Patterns
Learn from Attacks
Following Security Recommendations
Perform Classical Threat Analysis
How to Secure IoT?
12
See IETF#92 plenary talk with Dave Thaler and Mary Barnes (Internet Architecture Board).
13. 13
Learn from Attacks
§ Survey of attacks revealed a series of problems:
1. Limited software update mechanism
2. Missing key management
3. Inappropriate access control
4. Missing communication security
5. Vulnerability to physical attacks
§ Looking at real-world attacks allows us to easily see the need for security (and to
convince others to take action).
§ Don’t forget to secure the mobile/cloud interfaces as well, as discussed in the
Open Web Application Security Project (OWASP) Internet of Things Top-10 2014* list.
13
(*) Note: OWASP might be biased in their assessment since the organization deals mostly with Web-based vulnerabilities.
14. 14
Limited Software Update Mechanism
§ In a presentation at the Chaos Communication Congress in December 2014 a security vulnerability of
devices implementing the TR69 protocol, which also provides a software update mechanism, was
disclosed.
§ Real problem: Fix released in 2005 by AllegroSoft already but has not been distributed along the value
chain of chip manufacturers, gateway manufacturers, Internet service providers.
§ What happens when vendors do not support certain products anymore? Do IoT devices need a “
time-to-die”/”shelf-life”?
14
• In January 2014 Bruce Schneier published an article where he expresses concerns
about the lack of software update mechanisms in IoT deployments.
15. 15
§ Example: LIFX - Internet connected light bulb
§ The attack revealed that an AES key shared among all devices to simplify key management.
§ The firmware image was extracted via JTAG using a Bus Blaster.Then, the firmware was analyzed using IDA
Pro.
§ Mistakes only made by startups? See BMW ConnectedDrive
Pictures
taken
from
h1p://contex6s.co.uk/resources/blog/hacking-‐internet-‐connected-‐light-‐bulbs
15
Missing Key Management Problem
16. 16
Insteon LED Bulbs
§ To find IoT devices connected to the Internet global scans have been used, for example,
using ZMap.
§ Similar problems have been seen with various other appliances, such as
surveillance cameras, baby monitoring cameras and gas stations.
§ Lacking access control to configuration files can cause problems for the entire system, as
demonstrated with attacks against industrial control systems.
16
§ Insecure default settings have caused problems with Insteon
LED Bulbs, as reported in
“
When 'Smart Homes' Get Hacked: I Haunted A Complete
Stranger's HouseVia The Internet”
Inappropriate Access Control
17. 17
§ In “Green Lights Forever:Analyzing the Security of Traffic Infrastructure” Ghena,et al. analyzed
the security of the traffic infrastructure.
§ Results:
§ “The wireless connections are unencrypted and
the radios use factory default usernames and
passwords.”
§ “All of the settings on the controller may be configured
via the physical interface on the controller, but they may
also be modified though the network.An FTP connection
to the device allows access to a writable configuration
database.This requires a username and password, but
they are fixed to default values which are published online
by the manufacturer.”
§ A similar attack also exploited the unencrypted communication.
§ “I even tested the attack launched from a drone flying at over 650 feet, and it worked!”
17
Missing Communication Security
18. 18
§ Physical access to IoT devices introduces a wide
range of additional attack possibilities.
§ In some cases it might be necessary to extract keys
contained on chip.This can be accomplished using
power analysis, or fault injection (glitching) attacks.
§ Tools for physical attacks decrease in cost and
become easier to use.
§ Important to keep these attacks in mind since we will
see more of them in the future.
Chip
Whisperer
JTAGulator
18
Vulnerability to Physical Attacks
19. 19
Not all “hacks” are security attacks
§ Example: iRobot Create 2
§ The 2007 release Create was a closed system and researchers
“hacked it” to use it for educational purposes.
§ Create 2 is the programmable version.
§ Many border-line cases:
§ Nest devices at
http://venturebeat.com/2014/08/10/hello-dave-i-control-your-thermostat-googles-nest-gets-hacked/
and http://www.engadget.com/2014/06/23/nest-thermostat-rooted/
§ Remotely controlling cars using wireless dongles:
http://hackaday.com/2015/01/21/remotely-controlling-automobiles-via-insecure-dongles/
§ Hacking a toaster: https://www.youtube.com/watch?v=vI7tWd7B3iI
§ Hacking your printer:
http://contextis.co.uk/resources/blog/hacking-canon-pixma-printers-doomed-encryption/
20. 20
§ Integrate a software update mechanism and leave enough “head room”.
§ Use modern operating system concepts to avoid system-wide compromise
due to a single software bug.
§ Use an automated key management protocol with proper authentication and
authorization (access control).
§ Threat analysis must take physical attacks into account.
§ Use Internet security protocols offering communication security.
§ Take security into account during the software development lifecycle and in the
deployment phase.
20
Learn from Attacks, cont.
21. 21
§ Internet of Things security today is like PC security 20 years ago.
§ Most attacks on consumer-oriented IoT systems fall under the ”script
kiddie” category.
§ For industrial control systems many attacks are already scary
(see DragonFly, and attack against German steel factory).
§ Risk analysis is often complex since hacked devices may be used for
further attacks. Hence, indirect consequences also need to be taken into
account.
§ Examples: DDoS attacks using SNMP (used in printers),
hacked Femto home router used for spying
21
Remarks
22. 22
Relationship Management
Services
Identified using
resource identifiers
Users
Identified using existing identity
management techniques
Devices
Identified using non-cryptographic
identifiers and cryptographic
Keying material (certificates,
raw public keys)
Relationship
creation and
orchestration
23. 23
Device Management with OMA LWM2M
Mobile Device
Management
Device
Management
Bootstrapping
Device
Configuration
Firmware
Update
Fault
Management
§ Key management
§ Service provisioning
§ Access Control
§ Changes to settings
§ Changes to parameters of the
device
§ Update application and system software
§ Bug fixes
§ Report Errors from devices
§ Query about status of devices
Application Configuration
& Control
Reporting
§ Configure settings of the application
§ Send control commands
§ Notify changes in sensor values
§ Notify alarms and events
24. 24
Going beyond OMA LWM2M
§ New IETF working group on “
Authentication and Authorization for Constrained Environments” (ace)
§ Use Cases document available
§ Architecture specification in progress.
§ Various solutions being discussed, including profiled version of UMA/OAuth.
§ Wider range of use cases to manage device, users, and services and their access
control decisions.
§ Example: Employee demands access to enterprise building using their smart phone. Can we
integrate existing enterprise user identity management solutions with door locks?
§ Focuses on the constraints of IoT devices.
26. 26
8+ years of IoT products
30+ official mbed boards
5+ years 24/7
70,000+ developers
9,000+ projects
1M+ builds/year
Today at https://mbed.org
27. 27
ARM Cortex®-M
-based MCU
mbed Ecosystem
• Partners
• Developers
• Enabled Services
• Enabled Products
mbed Device Server
• Freemium model to enable startups
• Application data and device management
• Growth market access for cloud platforms
and operators
mbed OS
• Free for use on ARM architecture
• Leading connectivity standards
• Productivity, minimized costs
• Built-in management
• Security
28. 28
Lifecycle Security
Communication
Security
Device Security
mbedTLS
IPv6, 6LoWPANIPv4
Cryptobox
Device Management: LWM2M
mbed OS
mbed Device Interface using Web Standards
Directory and Subscription
ApplicationTransfer Protocols – CoAP, HTTP, MQTT
mbedTLS
Admin and Multi-tenancy
Data Flow Management – RESTful and Publish/Subscribe
Device Management – Lightweight M2M (LWM2M)
mbed Device Server
29. 29
§ Few developers have strong security experience.We want to help them!
§ mbed helps developers to accomplish their goals faster with less pain.
§ Offers operating systems
§ Internet protocol stack
§ Comprehensive security foundation
§ We are contributing in global standards organizations together with our partners to
develop solutions for linking device and user identity management (such as IETF
ACE).
Summary