Tag: M2M

A Reference Architecture for the Internet of Things

mustnotgrumbleLeave a comment

The Internet of Things requires multiple Reference Architectures which can map capabilities to specific technology domains. This is a challenge because there is no single unifying industry definition for the Internet of Things. For the purpose of this presentation it is assumed that:

  • “Things” have semantic representation in the Internet
  • “Things” can be acted upon in a structured manner (e.g., status, capabilities, location, measurements) or can report in structured data or can communicate directly with other “Things”
  • “Things” may be active (e.g., Zigbee sensor) or passive (e.g. RFID tag)
  • Different “Things” may use multiple protocols to communicate with each other and the internet

M2M Protocols

mustnotgrumbleLeave a comment

There are many different usable protocols for communication with M2M devices for the Internet of Things. Specific protocols are more appropriate for different devices (e.g. memory & power profiles) and specific protocols are more appropriate for different communication needs (e.g. State Transfer Model & Event Based Model)

Remote Control Soufflés: Challenge of M2M Authentication & Authorisation and Mobile data offloading

mustnotgrumbleLeave a comment

Some M2M devices will always connect to the internet using a fixed network connection / Wifi and others will always connect using a mobile network connection using an eUICC but there will be some that will offer both wifi and mobile network. It is these devices that will need to support wifi offloading where possible.  It is for these devices where providing a standard API gateway and AuthN & AuthZ capability will be most complex.

For example, my oven is always positioned in my kitchen and connects to the wifi network to allow me to view inside by a mobile app so that I don’t have to open the oven door during the fifteen minutes a soufflé takes to rise that would cause the temperature to change and my soufflé to collapse. This way I can inspect and control the temperature remotely. It also mean I have an excuse to check my phone during boring dinner parties. Only my app is paired to the oven so only I am authenticated and authorised to remotely check on my soufflé thus there is no potential risk of a malicious guest could accessing my oven app and destroy the soufflé by changing the temperature.

Remote viewing would decrease flop rate
An M2M oven with embedded camera would decrease flops

The majority of my home m2m devices will be static devices, I rarely travel with my oven, and these will in the majority of cases be Wifi enabled. Unfortunately I cannot guarantee wifi coverage throughout my architect’s ivory tower so some mobile internet devices will need to connect over 3G/4G (for example the BBQ in the lower field). The problem for my oven and BBQ manufacturers is that they would need to support both Wifi and the GSMA standard for M2M / smart device SIMs (eUICC). It would then be responsibility of the m2m device to support wifi offload where available.

Authorisation may be necessary when the function of the device is shared amongst a group with one or many people acting as the super administrator. If I sell my oven all of my authentication and authorisation permissions have to be removed from the M2M device but as I will likely buy a new oven with more soufflé capacity I would like to keep my existing settings.  Furthermore if my soufflé skills increased I may take a job in Paris and would need to reregister my oven’s eUICC or wifi connection. In this case I would definitely want to keep all of my authorisation permissions and maybe grant further permissions for all the extra soufflés I’d be baking.

Device resale and device portability are supported by the eUICC specification as they are necessary for widespread adoption of M2M devices. What is less supported is a common standard for AuthN & AuthZ that would allow me to keep my device preferences when I either move with or my devices or sell them and replace them with newer devices.

This is where OpenID Connect may be useful as it enables profile information on top of the authorisation model provided by OAuth 2.0. OpenID Connect 1.0 extends OAuth 2.0 so the client can verify claims about the identity of the end user, get profile information about the end user, and log the user out at the end of the OpenAM session. OpenID Connect also makes it possible to discover the provider for an end user, and to register client applications dynamically. OpenID connect services are built on OAuth 2.0, JSON Web Token (JWT), WebFinger and well-Known URIs.

It remains to be seen whether OpenID Connect will be integrated with the standards for eUICC as part of the GSMA Mobile Connect. Furthermore it will need to be supported by the wifi offloading devices (e.g. my BBQ’s manufacturer) as the standard for all M2M AuthN & AuthZ. It seems likely at first that device authorisation and later home M2M gateways will implement proprietary technologies and will maintain identity in individual walled gardens. My architecture ivory tower has a few of those too.

Securing Smart Device Communication using ETSI M2M Service Capability Layer (SCL)

mustnotgrumbleLeave a comment

Smart M2M devices require authentication & registration with the mobile network. Standardisation of service is proposed by the ETSI Service Capability Layer deployed to the Mobile Internet Device / Gateway. Security between the network and the mobile internet device requires authentication, key agreement and establishment that enable M2M Service Bootstrap, provisioning and M2M Service Connection procedures that are grounded on a clearly defined key hierarchy of the M2M Node.

The European Telecommunications Standards Institute’s M2M Release 1 provides standardised security mechanism for the reference point mobile internet device. This architecture is based upon the following principles:

  • ETSI M2M adopted a RESTful architecture style with information represented by resources structured as a tree
  • ETSI M2M standardises resource structure that resides on an M2M Service Capability Layer (SCL) where each SCL contains a resource structure where the information is kept
  • M2M Application and/or M2M Service Capability Layer exchange information by means of these resources over the defined reference points
  • ETSI M2M standardises the procedure for handling the resources

ETSI M2M Diagram

The SCL is deployed to the M2M mobile Internet device (mId) / gateway and requires authentication & registration with the M2M network. ETSI M2M provides standardised security mechanisms for the reference point mId. Mobile Internet Devices/gateways hold secret keys protecting the connection in a “secured environment” and are provisioned with the key M2M Root Key (Kmr). 

This requires using RESTful operations over the mobile internet device:

  1. M2M Service Bootstrap:  provision M2M service provider assigned ID & M2M Root Key (Kmr)
  2. M2M Service Connection: mutual AuthN of mobile internet device end points & generation of M2M Connection Key (Kmc – derived from Kmr)
  3. (Optional) Mobile Internet Device security: establishment of secure communication over mobile internet device based on Kmc (and sub-keys)

More information:

ETSI M2M Security Standards 

A Common Service Layer for M2M & The Challenge of AAA for Smart Devices

mustnotgrumbleLeave a comment

The Internet of Things, as distinct from the internet of people, requires communication between devices to enable home automation, telematics and health care monitoring. This intercommunication is dependent upon semantically structured and shared data for enabling functions such as identification, authentication, authorisation, bootstrapping and provisioning. Standardising both the semantically structured data and the enabling functions across M2M applications and devices would reduce the cost and extend the life of M2M devices. Standardisation for the Internet of Things is the aim of a common service layer for M2M.

There is no single internet definition for the Internet of Things, but to function as a network “Things” must have representation within the Internet. This representation includes structured data (e.g., status, capabilities, location, measurements) which needs to be semantic in order to be shared, processed and acted upon. The sharing and discoverability of information requires governance according to privacy settings and access rights. Because the Internet of Things (IoT) requires M2M application and device communication within minimal or no human involvement these privacy settings and access rights need to represent the delegated authority of the human user. Therefore M2M devices require bootstrapping of provisioned M2M service credentials (e.g. identities, M2M Root Key) which can be used for connecting and registering with different service layers and service authorities.

M2M devices can be active such as Zigbee sensors or passive such as RFID tags. M2M devices can be connected to an MNOs network using eUICCs or can be connected to an IP extending personal area network (e.g. Zigbee gateway). The ETSI principles for M2M & smart device communication are RESTful resource oriented APIs that are IP based but interwork with specific IP and non IP technologies in the M2M Area networks. The variance between device communication mechanism (IP & non-IP) and behaviour (passive vs active) makes defining an embeddable M2M common service layer a challenge.

The oneM2M group aims to develop technical specifications that address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide. The common M2M Service Layer should be agnostic to underlying network technology (yet leveraging the unique features of these underlying networks), and it will use network layer services (such as security (encryption and authentication), QoS, policy, provisioning, etc.) through an adaptation layer/APIs.

The challenge for Authentication, Authorisation & Accounting in M2M will be to build trust between the human user and the delegated authority to the M2M device.  In order for an embedded common M2M service layer to operate it must support AAA (authN, authZ & accounting) for smart devices using an agreeable mechanism between multiple device manufacturers and network operators. The Telecommunications Industry Association are defining a functional standard for Authentication, Authorization and Accounting for Smart Device (AAA-SD TIA) which is encapsulated in TIA TR-50 Functional architecture for M2M Smart Device Communication System Architecture  describes AAA-SD as ” provide authentication, authorisation and accounting services to other entities in the network to establish and enforce security policies. The services may include generation of keys, generation and validation of certificates, validation of signatures, etc”. The functions proposed by the oneM2M service layer must align with TIA TR-50.

5 Key Architectural Considerations on Implementing Identity and Access Management for M2M

mustnotgrumbleLeave a comment

Identity and access management have traditionally been used to manage the identity and credentials assigned to human users.  Machine to machine devices such as Smart Metering GPRS enabled electricity meters or SIM cards in cars require their own identity and access management capabilities. These include new M2M authentication schemes because traditional authentication schemes always assume the presence of a person. This means that most authentication technologies cannot be applied in machine-centric M2M context. Following from this the following are five keys authentication and authorisation challenges posed by a non-human orientated identity and access management system.

1. M2M Security and Authorisation:

With human user password based security has specific known issues but the secure credentials remain with the individual. With M2M access management it cannot be assumed that a given M2M module assigned to an individual or a system always remains a valid and true association. M2M devices can be lost, stolen, replicated, decrypted and hacked by both well-intentioned or malicious entities. As with BYOD the identity of the M2M must be continually validated using higher levels of encryption & signature that reflect the passive state of M2M devices.

2. Directory Services for M2M:

The increase in M2M services means that the number of non-human identities is growing. This increase requires a directory of all non-human identities which can be both organisationally managed or externally managed. As with the M2M Authorisation challenge a record is required for each individual M2M module.

3. Role and Attribute Management:

M2M device identity management must include roles & attributes that encapsulate its use. This may include the end-user, the service provider, the related services, the available resources, the module’s location, the module’s potential roaming allowance and other usage based attributes. Furthermore, the M2M device may require authorisation according to the data off-load technology such as when switching from GPRS to Near Field Communication data off-load.

4. Module Provisioning:

Individual M2M modules may be assigned to a collective M2M ecosystem and/or a family / person.  Any provisioning operation would require a presumably remote M2M module to be activated as either a standalone item (e.g. single meter system) or as part of a group of items (e.g. collective security systems). Identity provisioning rules that are extensible are critical to ensure both management and maintenance of M2M devices across the ecosystem.

5. Security Updates and Control:
Making changes to M2M modules depends upon the network architecture (GPRS, wired, wireless, NFC etc) but to provide ecosystem security (e.g. security patches) it must be possible to make real-time and near real-time control changes to M2M modules when vulnerabilities and anomalies are detected. Traditional human identity and access management systems can more easily protect against cyber-attack threats by bulky applying patches. With passive authentication systems such as in certain smart meter technology it is not always possible to make an upgrade and there is always the risk that individual modules with an ecosystem can become contaminated. Therefore any architecture must work with an isolating mechanism for quarantining modules and their data.