Managing Device Security for LWM2M

Security is as important in the Internet of Things (IoT) as it is any other communications domain. Perhaps even more so. IoT Device often do not have clearly associated users, unlike other end point categories and often compromises are as easily recognised as they are with Devices that have interfaces designed for humans. But the damage and subsequent loss of confidence in the technology following a compromise is no less substantial.

Although security is extremely important it can also be expensive, particular when securing very large numbers of Devices as there is a logistical cost of distributing and deploying credentials in different devices, system and locations. Thus choosing a method of security is somewhat of a compromise, balancing security with cost while looking for optimum of money spent verses probability of compromise.

Why IoT Security is Different

The Open Mobile Alliance Lightweight M2M (LwM2M) protocol is widely used in the Internet of things. LwM2M originally designed to cater to devices with limited resources, ensuring minimal requirements compared to other protocols and includes multiple  "lightweight" characteristic. This means LwM2M works well on devices with restricted memory, storage, and processing power. Additionally, the high levels of standardisation of the LwM2M protocol means that it has been widely adopted for many other less constrained device types where interoperability is key.

Constraints on IoT Security Choices

LwM2M devices are often deployed en-mass as the protocol is well suited to devices such as Meters, Lighting and Smart City where the endpoints are numerous and relatively low value. These constrained economics does put pressure on the costs associated with the devices for which security is just one element. Therefore the security approach should be selected that fits the wide range of constraints of:

• Constrained Devices: The devices have limited resources in terms of battery, memory, processing power and storage. This limits what can be done from a security level as more complex security often means more computing resources.
• Constrained Networks: The networks that the device use a often optimised to match the constrained nature of the devices, so for example the network may have very good reachability but low bandwidth or vary low power requirements but high latency.
• Wide Area Deployment: The network may cover a wide area, the classic case is for a public cellular network which may cover a very large area. From a security angle this means that the device is really outside the physical control of a the device user.
• Difficult to reach places when compromised: Devices may be located in places that are difficult to reach, meaning that it is not easy to undertake security fixes or other actions physically.
• Complex Supply Chain: Getting the device to market may be complicated. With suppliers of different device elements scattered all over the planet, this complexity can mean additional vulnerabilities and cost.

LwM2M Security Modes

The LwM2M 1.1 security model provides a number of different mechanisms for security each of them with advantages and disadvantages.

• Certificates with and without Enrolment over Secure Transport: X.509 Certificate based authentication using of Public Key Infrastructure with mutual Certificate Authentication has many advantages, the technology and use cases are well understood and once the infrastructure is in place the logistical aspects are very straightforward. The challenge for many device types is that the resources needed to use Certificates can be substantial and the security provided may be more than what is needed for the types of devices that use LwM2M. Although Certificates can be used in way such that the Certificate Authentication is only used in the bootstrap phase, where the logistical benefits are needed and from that point a simpler form of security such as PSK can be used.
• Raw Public Key: This is the use of Keys in a very similar way to Certificates but without the need for Public Key Infrastructure and all the associated use cases and with the disadvantages of not having them. The resource demand with this type of security is not has high as with Certificates, but is still higher than Per-shared key.
• Pre-shared key: Pre-shared keys a very straightforward way of securing a LwM2M device. Devices and Servers have keys that are shared and used to authenticate each other. Although in one way there is no need for Public Key Infrastructure and the associated use case, the keys do need to be distributed to the devices prior to them connecting to the server and doing this in a secure way can be complex and open to compromise if not done correctly. For cellular devices it is possible to use Subscriber Identity Module based credentials such as the IMSI as an input to Pre-shared Key creation. For this to work the LwM2M Device would have to have access to the IMSI and the LwM2M Server would need to be told of IMSIs that are to be authenticated, so some integration work is needed and the Telecom operator would need to agree to allow this. Individually inserting a key for each device is a possibility but it is complicated as the keys would need to be distributed ahead of time. Alternatively determining the key for an individual device on some other characteristic such as the serial number is often used. This way the serial number is hashed with a system wide key, although very simple to deploy, it is vulnerable if the system wide key is compromised.
• NoSec: Meaning no security, which sounds quite obviously insecure, but actually can be very good choice in certain circumstances. For many devices disabling security can reduce power consumption significantly by avoiding encryption and handshake overhead. Some studies [http://dx.doi.org/10.1109/jssc.2019.2915203] have identified up to a 30% reduction in power drain when avoid the use of security. As the power use is often closely linked to the lifetime of the device this can have some significant business benefits. This can only really be done if the underlying network offers its own lever of security which is adequate for the need. For Cellular networks this can very often be possible because the Devices contain a SIM card or softer equivalent and can operate in a trusted boundary. Traffic from the Device can be identified and correlated to the SIM in a way that can be used to secure the device. A very simple way of doing this is to use a Private APN, this will create a VPN like network segmentation for the device such that within the APN domain there is an implicit level of of security, assuming the owners are confident that the device is manufactured in a secure way this may be adequate. Additionally if the LwM2M Server is within the Network Operator domain, the Network Operator has the knowledge of the identity of each device and can authenticate them implicitly with a variety of schemes, this can be done regardless of the APN.
  
  For End-to-End security, LwM2M also provides Object Security for Constrained RESTful Environments or OSCORE which can be used in conjunction with these other security types. If the payload is sensitive, it may be worthwhile using OSCORE in conjunction with No security, although the device will still be required to undertake encryption and the associated power demands due to that.

The choices of security is a pragmatic one and there is no perfect solution for any deployment.
There are a number of variables to consider when selecting the correct security method that is best for any deployment. As previously stated the decision is somewhat of a balancing act of cost verse security. Into that decision go a number of different variables including:
 - Is the device constrained, how will each security choice affect the battery life of the device, assuming it has a battery. Will the implementation of the security model be support in the constraints of the devices memory, processor and storage.

• Is the network constrained, will the selected security approach work effectively in the bandwidth and latency used by the devices.
• Is the underlying network secure and can that security be extended to the LwM2M Server.
• What level of security is required overall, is it the actual protocol or is it just the payload.
• Is it challenging to insert security credentials into the LwM2M Device and corresponding LwM2M Server