Transcript oneM2M-SEC-2013-0018-M2M_applications_security_issues

Common issues in M2M Applications security:
Where oneM2M standards could help?
Presentation to oneM2M WG4
oneM2M TP4 – SEC#2 meeting
Francois Ennesser
Gemalto
Standardization and Technology
Introduction
Today, many existing M2M applications suffer from big security
deficiencies (see examples on slide 6)
This affects the trust of users in M2M applications, thereby hampering
the development of the M2M market
The lack of Information and Communication Technology (ICT)
expertize in many industries developing M2M applications is a
common cause for such deficiencies (industries like Energy or
Automotive still have limited history with ICT security)
As oneM2M is relying on the know-how of the ICT industry to provide
a standardized service layer for M2M applications, it makes sense to
consider how far the Service Layer can address such deficiencies
Reference, date
2
The question
How can the service layer developed by oneM2M assist in
addressing the security needs of M2M applications ?
Our ability to offer valuable services to M2M applications will be
key to the success of oneM2M specifications.
It is commonly accepted that the M2M service layer will provide
communication related services to M2M applications, but what
about security / trust services?
To answer the above question, oneM2M WG4 need to do look
beyond addressing the security needs expressed by potential
M2M Service Providers.
As a starting point, this presentation exposes experiences
gathered on the field about M2M applications security.
Reference, date
3
Convention
To assist in determining where the oneM2M service layer
could intervene in solving common M2M security issues
encountered on the field, the following slides use the following
color code:
 GREEN for issues that appear mostly relevant to access network
 BLUE for issues that could affect the Service Layer
 RED for issues that depend mostly on applications, or application provider
decision (e.g. device dependent)
Reference, date
4
Implication of the “Internet of Things”
on M2M security
Threats in the internet today
=
Threats in M2M tomorrow
Increased Security Threats
M2M vulnerabilities
Billions of targets online
More devices & value
Security breaches in software
Weak embedded Devices OS
Decreasing cost of attacks
Connectivity/Availability
Internet as source of attacks
Internet connected devices
Addressing Security threats on the Internet causes
constant challenges for the ICT industry today
The same will hold tomorrow for the Internet of Things!
Examples of M2M attacks
Lack of user authentication:
Zoombak tracking device (GPS/GPRS): http://news.cnet.com/8301-27080_3-20056540-245.html
•
•
Can be identified and tracked by non-authorized persons
Can even be impersonated!
Luxury car stolen in 3 minutes using security loophole:
http://www.networkworld.com/community/node/80983
•
No authentication required to duplicate electronic key!
Home automation: garage doors, etc.
SIM stolen from South Africa’s traffic lights: http://www.bbc.co.uk/news/world-africa-12135841
•
Not paired to the device, and usable for voice phone calls
Devices with weak security exposed to Internet:
Discovergy Smart Meter: http://nakedsecurity.sophos.com/2012/01/08/28c3-smart-meter-hacking-candisclose-which-tv-shows-and-movies-you-watch/
•
Hacked to transmit meter readings (up to every 2 seconds) via HTTP, unencrypted, without authentication!
Internet exposure of dutch water pumps: http://www.cyberwarzone.com/cyberwarfare/dutch-bridgesvulnerable-hackers
•
Could be operated by anyone from a home computer!
Use of unprotected links:
Jamming attacks e.g. preventing remote activation of car alarm systems in parking lots
Insulin pump hack Over The Air: http://www.theregister.co.uk/2011/10/27/fatal_insulin_pump_attack/
•
•
Uses unencrypted local radio link
Could deliver fatal dosage!
Heart monitor hacking: http://www.theregister.co.uk/2008/03/12/heart_monitor_hacking/
•
Can be turned off or forced to deliver impulse!
Different types of M2M security risks
 Privacy (e.g. Discovergy Smart Meter Hack):
• Personal data, relating to an individual, should be accessible only to authorized
parties (lawful purpose or user consent)
•
•
Requires identification and authentication of involved parties
Relying on local storage and processing is part of the solution
 Fraud (e.g. South African Traffic lights):
• Unattended devices deployed in unsecured environments are open to attackers
•
•
•
Access and services should be restricted to what is essential
Beware of unprotected channels, e.g. SMS in GSM / 3G
Use physical or logical pairing between M2M device and Access Subscription
 Critical Infrastructure exposure (e.g. Dutch water pump)
• Resources of attackers can be commensurate to potential damages!
•
•
•
Risk assessment is application specific, and some applications are particularly critical
In critical applications, one weak link compromises the whole chain
Need for security accreditation / certification will affect M2M Service Layer components
Frequent M2M attacks and their drivers
 Main drivers of exploit development: cf. Internet
 Fame (Hackers, white hats)
 Fun (Script kiddies)
 Profit / strategic interests (Hackers, black hats, organized crime, intelligence)
 Example of attacks on GSM / 3G networks:








Application snooping / reverse engineering
Interception
Jamming
Real-time over-the-air interception & decryption
IMSI-catcher
Protocol stack attacks through IMSI-catcher
Malformed SMS (“SMS of death”)
Denial of Service through open-source devices
Assume that Communication, even over cellular networks, is no
longer secure !
Attacks on M2M applications – 1 / 3
Jamming
Jammer
Availability
Attacks on M2M applications – 2 / 3
Interception
„IMSI catcher“
Authentication
Confidentiality
Attacks on M2M applications – 3 / 3 Multistep Attack
Access communication channel
F53A7902B2 =
identification
+ data +
commands
Reverse engineer M2M protocol
Search weakness to break Security
Hacker
Data Center
Connected Device
Attacks on M2M applications – 3 / 3 Multistep Attack “Wartexting”
Get identifications (phone numbers)
Confidential
information /
configuration
setting
Compromise devices remotely
Manipulate data + commands = Fraud
Hacker
Data Center
Authentication
Confidentiality
Integrity
Mitigating common M2M security risks
Many mitigation means rely on Access Network features.
For example:
Monitoring connections using keep-alive messages
Correlating location data with e.g. GPS tracking
Leveraging on existing trust provisioning chains (e.g. SIM) to
deploy applicative credentials securely
Enabling applications to leverage on deployed authentication and
identification infrastructures
Using secure remote management for OTA deployment of
applications, firmware upgrades, etc.
Such needs should be accounted for by the M2M Service Layer.
Reference, date
13
Common M2M threats on cellular networks
Attack
complexity
Attack
likelihood
Attack
Impact
Application
snooping
low
med/high
med
Interception
N/A
med
med
Legal implications
Impossible to detect or
prevent
Application-level encryption
Jamming
low
high
med
Easy to detect, impossible
to prevent
Jamming status detection (radio link
monitoring)
Air interface
Interception and
decryption
med
med
high
Mostly on 2G networks
Application-level encryption
Encryption status display/check
Fake networks
(„IMSI Catcher“
fake BTS)
med
med
high
Works in 2G mode only
Equipment now affordable
Possible to detect & evade
Scan frequency spectrum to detect
Encryption status display/check
Fake networks
GSM Layer 3
attacks
high
low
high
Device stack dependent
May enable code injection!
Protocol stack hardening
Fake network avoidance
Malformed SMS
low
med
med
May crash some devices!
SMS application hardening
„SMS-of-death“
Characteristics
Countermeasure
Application-level encryption
AT Command encryption
Every link in the chain must be secure
• Physical device security (e.g. tamper-resistance)
• Secrets protection: embedded Secure Element
• Application level Communication security (e.g. IP encryption end-to-end)
• Modem / communication element security
• Network security
• Application backend server / Service Infrastructure security
How secure are elements of M2M communication systems?
What makes an application “secure”?
Communication
Networks
Connected Devices
Communication
components
Security is a chain => all the links must be secured
How secure are the networks?
Cellular Networks?
There are numerous security measures built within
cellular networks:
 User identity is obscured
 Traffic is encrypted
 Use of “secure element” (e.g. UICC) protecting
secrets used for authentication
Internet?
No security by default!
 Use e.g. TLS
encryption
 Credentials must be
adequately protected
(tamper resistance /
Yes, but ...
security certification)
> Depends on MNO settings (some 2G algorithms are weak)
> Beware of SMS in particular !!! (use encryption and signature)
Device security need is application dependent
Cost
of
Attack



Security demand
Security demand = Attack probability * Potential damage
Examples of device security improvements
Goal: increase cost of attacks that are most likely to happen
Security Measures
Cost of Attack
Tamper-resistant enclosure
$€£¥$€£¥$€£¥
Authenticate via certificates
$€£¥$€£¥$€£¥
SSL/TLS encryption
$ € £ ¥ $ € £ ¥$ € £ ¥
Authenticate SMS
Protocol & data encryption
$€£¥$€£¥$€£¥
$€£¥$€£¥$€£¥
$€£¥$€£¥$€£¥
Securing the device communication chain /
modem
Modem must be secured
 against manipulation (e.g. firmware reflashing)
 against reverse engineering (e.g. through diagnostics port)
Secure communication between modem and application
 external interfaces (serial, USB) are vulnerable against tracing / reverse
engineering
 encryption may be an option (but key must be stored securely)




Internal application programming environment (e.g. Java)
Applets must be protected against manipulation & reverse engineering
Applet update must be secured
File system access must be protected as well
Rely on tamper-resistant storage/execution environment, e.g. UICC
M2M applications security requirements
The following principles are the basis of application level security
 Always use authentication on application level
 Use strong end-to-end encryption
This implies the following constraints:
• Need to deploy application specific security credentials:
• The same applies for the M2M Service layer !
• The solution deployed for addressing this problem at the service layer level could
be leveraged to offer the same service to the application
• Some applications may not trust M2M service providers for ensuring their security,
e.g. Utilities vs. Telco
• This can be addressed by dissociating at the M2M Service Layer
level the routing / data dissemination related roles from the trust
based roles (involvement of a trusted third party for security services)
Reference, date
21
Proposal
WG4 participants are asked to consider, based on this
information, to which extend the services offered by the
oneM2M service layer could address M2M applications
security needs
 This determines the WG4 scope of work !
Further contributions welcome, especially:
 Security requirements of specific M2M applications
 Vertical industries security specifications and constraints
 Contributions to provide security support within the service layer for
use by M2M applications
Thank you !
Reference, date
22