Common issues in M2M Applications security

Group Name: WG4Source: Francois Ennesser, Gemalto, francois.ennesser@gemalto.comMeeting Date: 2013-04-15Agenda Item: SEC#2

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

2

The questionHow 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.

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)

4

Implication of the “Internet of Things” on M2M security

Threats in the internet today

M2M vulnerabilities

More devices & value

Weak embedded Devices OS

Connectivity/Availability

Increased Security Threats

Security breaches in software

Decreasing cost of attacks

Internet as source of attacks

Threats in M2M tomorrow=

Addressing Security threats on the Internet causes constant challenges for the ICT industry today

The same will hold tomorrow for the Internet of Things!

Billions of targets online

Internet connected devices

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-can-disclose-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-bridges-vulnerable-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!

Examples of M2M attacks

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

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

Attacks on M2M applications – 2 / 3 Interception

„IMSI catcher“

Attacks on M2M applications – 3 / 3Multi-step Attack

F53A7902B2 = identification + data + commands

Data Center

Hacker

Access communication channel

Reverse engineer M2M protocol

Search weakness to break Security

Connected Device

Attacks on M2M applications – 3 / 3 Multi-step Attack “Wartexting”

Confidential information / configuration setting

Data Center

Get identifications (phone numbers)

Compromise devices remotely

Manipulate data + commands = Fraud

Hacker

Mitigating 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.

13

Cellular Networks M2M threatsAttack

complexityAttack

likelihoodAttack Impact

Characteristics Countermeasure

Application snooping

low med/high med Application-level encryption

AT Command encryption

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

„SMS-of-death“

low med med May crash some devices! SMS application hardening

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?

Communication Networks

Connected Devices Communication components

What makes an application “secure”?

Security is a chain => all the links must be secured

How secure are the networks?

Cellular Networks? Internet?

> Depends on MNO settings (some 2G algorithms are weak)

> Beware of SMS in particular !!! (use encryption and signature)

No security by default!

Use e.g. TLS encryption

Credentials must be adequately protected (tamper resistance / security certification)

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 authenticationYes, but ...

Device security need is application dependent

Security demand

Cost ofAttack

Security demand = Attack probability * Potential damage

Cost of Attack

Examples of device security improvements

Security Measures

Authenticate SMS

Tamper-resistant enclosure

Authenticate via certificates

SSL/TLS encryption

Protocol & data encryption $ € £ ¥ $ € £ ¥ $ € £ ¥$ € £ ¥ $ € £ ¥ $ € £ ¥

$ € £ ¥ $ € £ ¥$ € £ ¥

$ € £ ¥ $ € £ ¥ $ € £ ¥

$ € £ ¥ $ € £ ¥ $ € £ ¥

$ € £ ¥ $ € £ ¥ $ € £ ¥

Goal: increase cost of attacks that are most likely to happen

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 encryptionThis 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)

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 !

22