Presentation is loading. Please wait.

Presentation is loading. Please wait.

Common issues in M2M Applications security Group Name: WG4 Source: Francois Ennesser, Gemalto, Meeting Date: 2013-04-15 Agenda.

Similar presentations

Presentation on theme: "Common issues in M2M Applications security Group Name: WG4 Source: Francois Ennesser, Gemalto, Meeting Date: 2013-04-15 Agenda."— Presentation transcript:

1 Common issues in M2M Applications security Group Name: WG4 Source: Francois Ennesser, Gemalto, Meeting Date: 2013-04-15 Agenda Item: SEC#2

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

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

4 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

5 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

6 Lack of user authentication: Zoombak tracking device (GPS/GPRS): Can be identified and tracked by non-authorized persons Can even be impersonated! Luxury car stolen in 3 minutes using security loophole: No authentication required to duplicate electronic key! Home automation: garage doors, etc. SIM stolen from South Africa’s traffic lights: Not paired to the device, and usable for voice phone calls Devices with weak security exposed to Internet: Discovergy Smart Meter: disclose-which-tv-shows-and-movies-you-watch/ 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: vulnerable-hackers 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: Uses unencrypted local radio link Could deliver fatal dosage! Heart monitor hacking: Can be turned off or forced to deliver impulse! Examples of M2M attacks

7 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

8 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 !

9 Attacks on M2M applications –1 / 3 Jamming Jammer Availability

10 Attacks on M2M applications – 2 / 3 Interception „IMSI catcher“ Authentication Confidentiality

11 Attacks on M2M applications – 3 / 3 Multi-step Attack F53A7902B2 = identification + data + commands Data Center Hacker Access communication channel Reverse engineer M2M protocol Search weakness to break Security Connected Device

12 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 Authentication Confidentiality Integrity

13 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

14 Cellular Networks M2M threats Attack complexity Attack likelihood Attack Impact CharacteristicsCountermeasure Application snooping lowmed/highmedApplication-level encryption AT Command encryption InterceptionN/Amed Legal implications Impossible to detect or prevent Application-level encryption JamminglowhighmedEasy to detect, impossible to prevent Jamming status detection (radio link monitoring) Air interface Interception and decryption med highMostly on 2G networksApplication-level encryption Encryption status display/check Fake networks („IMSI Catcher“ fake BTS) med highWorks 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 highlowhighDevice stack dependent May enable code injection! Protocol stack hardening Fake network avoidance Malformed SMS „SMS-of-death“ lowmed May crash some devices!SMS application hardening

15 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

16 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

17 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 authentication Yes, but...

18  Device security need is application dependent Security demand Cost of Attack  Security demand = Attack probability * Potential damage

19 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

20 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

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

22 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

Download ppt "Common issues in M2M Applications security Group Name: WG4 Source: Francois Ennesser, Gemalto, Meeting Date: 2013-04-15 Agenda."

Similar presentations

Ads by Google