Over a million developers have joined DZone.

Top Three Considerations in Securing an IoT Infrastructure Framework

DZone's Guide to

Top Three Considerations in Securing an IoT Infrastructure Framework

Check out this post on the top considerations for securing your IoT infrastructure framework, taking a look at authentication, authenticity, and more!

· Security Zone ·
Free Resource

Mobile is increasingly becoming a part of every consumers’ identity, but the increasing use of this digital channel is escalating the security risks faced by consumers and institutions.

We closed the previous article about choosing a framework for IoT infrastructure with some indications of some of the requisite security considerations for this type of project. This time, we’ll examine three specific aspects of IoT infrastructure security.

It’s worth considering the ease of implementation for these factors, which are likely to vary across larger and smaller vendors, as well as across types and scopes of the project. Those custom solutions are losing ground to emergent standard protocols and frameworks. However, these are some of the key pre-emptive areas to address during the establishment of network-facing, live IoT infrastructure.

Ensuring Certificate Authenticity

Client certificates installed at manufacturing time are the dominant way IoT devices authenticate themselves to the IoT platform. A less secure alternative for power and cost-constrained hardware is to have a simple, shared secret or ‘fingerprint’ on the device; however, this is increasingly frowned upon. In both cases, those keys may be exposed via a QR code on the packaging, meaning that users with physical access to the appliances can scan it and log on to it using their mobile phones.

Certificate integrity is susceptible to compromise from several quarters, though in recent years those authority breaches made for political or commercial advantage have gained the most media traction. IoT infrastructure will, therefore, need its own proprietary dedicated to Certification Authority.

There are several core aspects to establishing a ‘hermetic’ certification system. In the event of certificates being compromised, the framework will need a reliable certificate revocation method that’s capable of propagating quickly across the field network — and to be backward-compatible and to ensure that devices may not have received the latest software or firmware updates are not left out of the chain.

The revocation system should also be granular, with the ability to isolate certificates for individual devices or production batches. To this end, it’s also essential to set up a certificate hierarchy and to ensure that root certificates aren’t provided to any of the system’s hardware production facilities. A breach of this type at the device manufacturing level is far more difficult to recover from than a similar leak anywhere else in the chain (see ‘hardware-based authentication’ below).

This doesn’t remove the need for additional oversight when dealing with browser-based certificates, but it does provide continuity in the event of another breach of a public CA. In cases where an open source or proprietary browser is integrated into the system UI, it’s also worth considering implementing Online Certificate Status Protocol (OCSP), which can help determine the revocation state of any active certificate.

Securing Hardware-Based Authentication

The unique ID numbers of CPUs, network cards, MAC addresses, and other components in a device can secure local authentication procedures, but they can also potentially be ‘spoofed.' The integrity of these IDs can be compromised either at the manufacturing level or, in cases where the device is getting repaired, it has been tampered with.

Cloning is a genuine risk in the out-of-jurisdiction East Asian tech manufacturing sector, both at a hardware and software level. This is a reality that has to factor into the security design of IoT networks of this nature. This situation has arisen in Asia primarily due to the lack of agreements (or poor enforcement of such agreements that there may be) over the reproduction of copyrighted technology between the two hemispheres and is difficult to change because of mutual economic co-dependence between east and west in the tech manufacturing and Maker sectors.

CPU IDs and other hardware-based identifiers are more likely to be cloned accidentally than with malicious intent. But, in either case, an IoT system cannot fully trust the manufacturing system, and an established remedial procedure will be required to cover this eventuality.

The local hardware identifiers, which you might depend on in your authentication procedures, are only as reliable as the uncompromising code-signing and end-to-end encryption that secures the system in general. This is done particularly so that, if you’re using open source firmware, it could be undermined by querying the hardware in unexpected and malicious ways.

It’s also necessary to account for the possibility of a change in local hardware-based IDs, which may be essential to authentication if you’re anticipating the repair (rather than replacement) of faulty devices.

This can happen when the user is able to swap out faulty LTE and WLAN cards, for instance, and is a strong argument for tracking the device history from factory to all the clients that may use it in its operational lifetime.

Security Considerations in the Update Stream

One of the most vulnerable windows for an IoT-based network is at the point of pushing out updates. Here, the system is most exposed to new vulnerabilities that may have slipped past development and staging.

Therefore, a reliable delivery mechanism is essential. If the device is Linux-based, software distribution should be handled via standard Linux package managers or frameworks such as Resin.io rather than custom proprietary solutions. All connections to the update servers should be SSL by default, in any case, with all code signed and all signatures checked throughout the rollout.

A project at this scale also needs a smooth continuous integration/delivery pipeline from dev to staging to production. It’s important to automate that workflow wherever possible. The roll-out also needs to provide staged delivery and A/B testing to an initially limited number of end-users.

Explore the authentication advancements that are designed to secure accounts and payments—without overburdening consumers with a friction-laden experience.

security ,iot infrastructure ,hardware ,open source ,iot framework ,networks ,connected devices ,iot

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}