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

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/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: vulnerable-hackershttp://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: 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

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

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