Engineering Insights
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 that ease of implementation for these factors is likely to vary across larger and smaller vendors, and across types and scopes of the project; and that 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 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, to ensure that devices that 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 the 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 or 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 – 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 which secures the system in general. This is particularly so if you’re using open-source firmware, which could otherwise be undermined by querying the hardware in unexpected and malicious ways.
It’s necessary also 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 a 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 the 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, so it’s important also to automate that workflow where possible. The roll-out also needs to provide staged delivery and A/B testing to an initially limited number of end-users.