Communicating with a machine to machine device

Abstract

The present disclosure provides methods and apparatus for administering an interface between a machine-to-machine, M2M, device and a network application function, NAF, for secure communication between the M2M device and the NAF. In one method, the M2M device comprises security information for enabling secure communication via the interface, and administers the interface by: setting a secure interface lifetime parameter based on a lifetime of at least part of the security information; and transmitting administration data to the NAF, wherein the administration data comprises the secure interface lifetime parameter.

Description

FIELD OF THE INVENTION[0001]The present invention relates to a method and system for administering an interface between a machine to machine, M2M, device and a network application function, NAF, for secure communication between the M2M device and the NAF.BACKGROUND OF THE INVENTION[0002]Machine to Machine (M2M) devices are often numerous, hard-to-reach, and have constrained capabilities (owing to low cost, small size, low processing power or limited battery life). All of this makes their management, often remote, very complicated. Moreover, M2M devices often need to be managed in a secure manner. For example, they may contain information that is commercially sensitive and / or confidential for the one or more entities that manage and / or own said devices. There is a need to remotely manage them in a secure way, while respecting these constraints.[0003]The M2M device needs to be able to contact a device management (DM) server in a secure manner. Whilst at the time of manufacture the dev...

AI Technical Summary

Benefits of technology

[0045]By setting the secure interface lifetime parameter based on a lifetime of the security information, the lifetime of the secure interface is linked to the lifetime of the security information. By linking the two lifetimes, the number of unnecessary new bootstrapping runs (for example, new bootstrapping runs that are unnecessary because there is still a large amount of time remaining before the secure interface registration expires) may be reduced or eliminated, thereby reducing the data overhead of the M2M device and / or a bootstrapping server. Furthermore, the M2M device and NAF data overheads may also be reduced as administration data may only be transmitted when there is new administration data (for example, a newly bootstrapped shared secret and / or a new identifier of the shared secret), thereby reducing or eliminating unnecessary data transfers between the M2M device and NAF for updating or refreshing the interface unnecessarily.

[0098]The NAF may additionally, or alternatively, be configured as a router to sit between the M2M device and the DM server and / or as a router to sit between the M2M device and a LWM2M server and / or as a router to sit between the M2M device and a LWM2M bootstrapping server and / or as a router to sit between the M2M device and a bootstrapping server. In this way, the NAF may pass any suitable traffic on to the DM server / LWM2M server / LWM2M bootstrapping server / bootstrapping server either encrypted or unencrypted such that the functionality of the server / LWM2M server / LWM2M bootstrapping server / bootstrapping server need not be modified in any way and the server / LWM2M server / LWM2M bootstrapping server / bootstrapping server does not need to be ‘GBA aware’.

Problems solved by technology

Machine to Machine (M2M) devices are often numerous, hard-to-reach, and have constrained capabilities (owing to low cost, small size, low processing power or limited battery life).

All of this makes their management, often remote, very complicated.

However, regular administration of the secure interface may generate additional data overheads for the M2M device and the DM server or NAF, and also for the bootstrapping server in the bootstrapping of new security information to be used in administration.

To date, most of the limited number of deployments of GBA in the world has been for mobile broadcast.

These alternatives all work well with mobile devices and operators already, so service providers use them, although they are not as secure as GBA.

Strong security is not possible with current alternatives such as a user-entered PIN or a bootstrapping message delivered by an SMS.

These alternatives would either not be feasible or they would not provide the required level of security.

First, there might not be a user around to enter a PIN (as most M2M devices operate independently from human intervention).

Second, the service provider may be likely to want strong security (e.g. because M2M devices may include critical infrastructure), whereas PIN-based bootstrapping has weaker security.

Third, if a PIN or SMS-based bootstrapping goes wrong (server connects to wrong client, client connects to wrong server, or there is a Man-In-The-Middle), then the user is likely to notice, complain and get it fixed, whereas an M2M device is unlikely to notice and complain, so may be permanently compromised.

Neither is particularly practical by way of existing methods.

Moreover, as mentioned above, the OMA Device Management is not compatible for use with an M2M device, as discussed above.

Moreover, for the reasons mentioned above, the OMA Device Management and the standard document are incompatible, and a combination of the GBA Push for OMA Device Management with the standard document is not feasible, as it would result in the wrong device management protocol (i.e. one that is not suitable for M2M devices, particularly simple M2M devices), and some very laborious effort to make the two compatible and delete the elements which are redundant.

However, coaps requires a secure association to be provisioned between a device and a network server (DM Server) while providing no strong means to provision such an association from scratch.

Images